diff --git a/Documentation/NuttxPortingGuide.html b/Documentation/NuttxPortingGuide.html index f31d0d8fdb..8fceef9c1d 100644 --- a/Documentation/NuttxPortingGuide.html +++ b/Documentation/NuttxPortingGuide.html @@ -12,7 +12,7 @@

NuttX RTOS Porting Guide

-

Last Updated: February 4, 2019

+

Last Updated: February 18, 2019

@@ -97,94 +97,99 @@ 4.2.19 up_prioritize_irq()
4.2.20 up_putc()
- 4.3 System Time and Clock + 4.3 APIs Exported by Board-Specific Logic to NuttX - 4.4 Work Queues + 4.4 System Time and Clock + 4.5 Work Queues + - 4.5 Address Environments + 4.6 Address Environments - 4.6 APIs Exported by NuttX to Architecture-Specific Logic + 4.7 APIs Exported by NuttX to Architecture-Specific Logic - 4.7 Application OS vs. Internal OS Interfaces
- 4.8 boardctl() Application Interface
- 4.9 Symmetric Multiprocessing (SMP) Application Interface + 4.8 Application OS vs. Internal OS Interfaces
+ 4.9 boardctl() Application Interface
+ 4.10 Symmetric Multiprocessing (SMP) Application Interface - 4.10 Shared Memory + 4.11 Shared Memory - 4.11 On-Demand Paging
- 4.12 LED Support + 4.12 On-Demand Paging
+ 4.13 LED Support - 4.13 I/O Buffer Management + 4.14 I/O Buffer Management 5.0 NuttX File System
@@ -1742,13 +1747,8 @@ The specific environmental definitions are unique for each board but should incl

  • Common Board Interfaces. - Any interface that is common to all boards should be prefixed with board_ and should also be prototyped in include/nuttx/arch.h. - These board_ definitions provide the interface between the board-level logic and the architecture-specific logic. -

    -

    - There is also a configs/<board>/include/board.h header file that can be used to communicate other board-specific information between the architecture logic and even application logic. - Any definitions which are common between a single architecture and several boards should go in this board.h header file; - include/nuttx/arch.his reserved for board-related definitions common to all architectures. + Any interface that is common to all boards should be prefixed with board_ and should also be prototyped in include/nuttx/board.h. + These board_ definitions provide the interface between the board-level logic and the commaon and architecture-specific logic.

  • @@ -2272,9 +2272,62 @@ The specific environmental definitions are unique for each board but should incl Output one character on the console

    -

    4.3 System Time and Clock

    +

    4.3 APIs Exported by Board-Specific Logic to NuttX

    -

    4.3.1 Basic System Timer

    +

    + Exported board-specific interfaces are prototyped in the header file include/nuttx/board.h. + There are many interfaces exported from board- to architecture-specific logic. + But there are only a few exported from board-specific logic to common NuttX logic. + Those few will be discussed in this paragraph. +

    +

    + All of the board-specific interfaces used by the NuttX OS logic are for controlled board initialization. + There are three points in time where you can insert custom, board-specific initialization logic: +

    +

    + First, <arch>_board_initialize(): This function is not called from the common OS logic, but rather from the architecture-specific power on reset logic. + This is used only for initialization of very low-level things like configuration of GPIO pins, power settings, DRAM initialization, etc. + The OS has not been initialized at this point, so you cannot allocate memory or initialize device drivers. +

    +

    + The other two board initialization hooks are called from the OS start-up logic and are described in the following paragraphs: +

    + +

    4.3.1 board_early_initialize()

    + +

    + The next level of initialization is performed by a call to up_initialize() (in arch/<arch>/src/common/up_initialize.c). The OS has been initialized at this point and it is okay to initialize drivers in this phase. + up_initialize() is not a board-specific interface, but rather an architecture-specific, board-independent interface. +

    +

    + But at this same point in time, the OS will also call a board-specific initialization function named board_early_initialize() if CONFIG_BOARD_EARLY_INITIALIZE=y is selected in the configuration. + The context in which board_early_initialize() executes is suitable for early initialization of most, simple device drivers and is a logical, board-specific extension of up_initialize(). +

    +

    + board_early_initialize() runs on the startup, initialization thread. + Some initialization operations cannot be performed on the start-up, initialization thread. + That is because the initialization thread cannot wait for event. + Waiting may be required, for example, to mount a file system or or initialize a device such as an SD card. + For this reason, such driver initialize must be deferred to board_late_initialize(). +

    + +

    4.3.2 board_late_initialize()

    + +

    + And, finally, just before the user application code starts. + If CONFIG_BOARD_LATE_INITIALIZE=y is selected in the configuration, then an final, additional initialization call will be performed in the boot-up sequence to a function called board_late_initialize(). + board_late_initialize() will be called well after up_initialize() and board_early_initialize() are called. + board_late_initialize() will be called just before the main application task is started. + This additional initialization phase may be used, for example, to initialize more complex, board-specific device drivers. +

    +

    + Waiting for events, use of I2C, SPI, etc are permissable in the context of board_late_initialize(). + That is because board_late_initialize() will run on a temporary, internal kernel thread. +

    + +

    4.4 System Time and Clock

    + +

    4.4.1 Basic System Timer

    System Timer In most implementations, system time is provided by a timer interrupt. @@ -2357,7 +2410,7 @@ else In this way, the timer interval is controlled from interrupt-to-interrupt to produce an average frequency of exactly 100Hz.

    -

    4.3.2 Hardware

    +

    4.4.2 Hardware

    To enable hardware module use the following configuration options:

    @@ -2421,7 +2474,7 @@ else

    • -

    4.3.3 System Tick and Time

    +

    4.4.3 System Tick and Time

    The system tick is represented by::

    @@ -2444,8 +2497,8 @@ else To retrieve that variable use:

    -

    4.3.4 Tickless OS

    -

    4.3.4.1 Tickless Overview

    +

    4.4.4 Tickless OS

    +

    4.4.4.1 Tickless Overview

    Default System Timer. @@ -2484,13 +2537,13 @@ else Using an interval timer, one can anticipate when the next interesting OS event will occur, program the interval time and wait for it to fire. When the interval time fires, then the scheduled activity is performed.

    -

    4.3.4.2 Tickless Platform Support

    +

    4.4.4.2 Tickless Platform Support

    In order to use the Tickless OS, one must provide special support from the platform-specific code. Just as with the default system timer, the platform-specific code must provide the timer resources to support the OS behavior. Currently these timer resources are only provided on a few platforms. An example implementation is for the simulation is at nuttx/arch/sim/src/up_tickless.c. There is another example for the Atmel SAMA5 at nuttx/arch/arm/src/sama5/sam_tickless.c. These paragraphs will explain how to provide the Tickless OS support to any platform. -

    4.3.4.3 Tickless Configuration Options

    +

    4.4.4.3 Tickless Configuration Options

    -

    4.3.4.4 Tickless Imported Interfaces

    +

    4.4.4.4 Tickless Imported Interfaces

    The interfaces that must be provided by the platform specified code are defined in include/nuttx/arch.h, listed below, and summarized in the following paragraphs:

    @@ -2603,7 +2656,7 @@ config ARCH_SIM -
    4.3.4.4.1 <arch>_timer_initialize()
    +
    4.4.4.4.1 <arch>_timer_initialize()

    Function Prototype:

    -
    4.3.4.4.2 up_timer_gettime()
    +
    4.4.4.4.2 up_timer_gettime()

    Function Prototype:

    -
    4.3.4.4.3 up_alarm_cancel()
    +
    4.4.4.4.3 up_alarm_cancel()

    Function Prototype:

    -
    4.3.4.4.4 up_alarm_start()
    +
    4.4.4.4.4 up_alarm_start()

    Function Prototype:

    -
    4.3.4.4.5 up_timer_cancel()
    +
    4.4.4.4.5 up_timer_cancel()

    Function Prototype:

    -
    4.3.4.4.6 up_timer_start()
    +
    4.4.4.4.6 up_timer_start()

    Function Prototype:

    -

    4.3.5 Watchdog Timer Interfaces

    +

    4.4.5 Watchdog Timer Interfaces

    NuttX provides a general watchdog timer facility. This facility allows the NuttX user to specify a watchdog timer function @@ -2753,16 +2806,16 @@ int up_timer_start(FAR const struct timespec *ts); or kill() to communicate with NuttX tasks.

    -

    4.3.5.1 wd_create/wd_static

    +

    4.4.5.1 wd_create/wd_static

    Function Prototype: @@ -2802,7 +2855,7 @@ Differences from the VxWorks interface include: initialization time). -

    4.3.5.2 wd_delete

    +

    4.4.5.2 wd_delete

    Function Prototype: @@ -2847,7 +2900,7 @@ Differences from the VxWorks interface include: before deallocating it (i.e., never returns ERROR). -

    4.3.5.3 wd_start

    +

    4.4.5.3 wd_start

    Function Prototype: @@ -2905,7 +2958,7 @@ to wdentry; VxWorks supports only a single parameter. The maximum number of parameters is determined by -

    4.3.5.4 wd_cancel

    +

    4.4.5.4 wd_cancel

    Function Prototype: 

    @@ -2938,7 +2991,7 @@ VxWorks provides the following comparable interface:
     STATUS wdCancel (WDOG_ID wdog);
    -

    4.3.5.5 wd_gettime

    +

    4.4.5.5 wd_gettime

    Function Prototype:

    @@ -2962,7 +3015,7 @@ VxWorks provides the following comparable interface: means either that wdog is not valid or that the wdog has already expired.

    -

    4.3.5.6 Watchdog Timer Callback

    +

    4.4.5.6 Watchdog Timer Callback

    When a watchdog expires, the callback function with this type is called:

    @@ -2992,18 +3045,18 @@ typedef uint32_t wdparm_t; #endif -

    4.4 Work Queues

    +

    4.5 Work Queues

    Work Queues. NuttX provides work queues. Work queues are threads that service a queue of work items to be performed. They are useful for off-loading work to a different threading context, for delayed processing, or for serializing activities.

    -

    4.4.1 Classes of Work Queues

    +

    4.5.1 Classes of Work Queues

    Classes of Work Queues. There are three different classes of work queues, each with different properties and intended usage. These class of work queues along with the common work queue interface are described in the following paragraphs.

    -

    4.4.1.1 High Priority Kernel Work queue

    +

    4.5.1.1 High Priority Kernel Work queue

    High Priority Kernel Work queue. The dedicated high-priority work queue is intended to handle delayed processing from interrupt handlers. This work queue is required for some drivers but, if there are no complaints, can be safely disabled. The high priority worker thread also performs garbage collection -- completing any delayed memory deallocations from interrupt handlers. If the high-priority worker thread is disabled, then that clean up will be performed either by (1) the low-priority worker thread, if enabled, and if not (2) the IDLE thread instead (which runs at the lowest of priority and may not be appropriate if memory reclamation is of high priority) @@ -3049,7 +3102,7 @@ typedef uint32_t wdparm_t; -

    4.4.1.2 Low Priority Kernel Work Queue

    +

    4.5.1.2 Low Priority Kernel Work Queue

    Low Priority Kernel Work Queue. This lower priority work queue is better suited for more extended, application oriented processing such as file system clean-up, memory garbage collection and asynchronous I/O operations. @@ -3090,7 +3143,7 @@ typedef uint32_t wdparm_t; -

    4.4.1.3 User-Mode Work Queue

    +

    4.5.1.3 User-Mode Work Queue

    Work Queue Accessibility. The high- and low-priority worker threads are kernel-mode threads. In the normal, flat NuttX build, these work queues are are useful to application code and may be shared. However, in the NuttX protected and kernel build modes, kernel mode code is isolated and cannot be accessed from user-mode code. @@ -3111,8 +3164,8 @@ typedef uint32_t wdparm_t; The stack size allocated for the lower priority worker thread. Default: 2048. -

    4.4.2 Common Work Queue Interfaces

    -

    4.4.2.1 Work Queue IDs

    +

    4.5.2 Common Work Queue Interfaces

    +

    4.5.2.1 Work Queue IDs

    Work queue IDs. @@ -3141,7 +3194,7 @@ typedef uint32_t wdparm_t; -

    4.4.2.2 Work Queue Interface Types

    +

    4.5.2.2 Work Queue Interface Types

    -

    4.4.2.3 Work Queue Interfaces

    -
    4.4.2.3.1 work_queue()
    +

    4.5.2.3 Work Queue Interfaces

    +
    4.5.2.3.1 work_queue()

    Function Prototype:

    -
    4.4.2.3.2 work_cancel()
    +
    4.5.2.3.2 work_cancel()

    Function Prototype: #include <nuttx/wqueue.h> @@ -3260,7 +3313,7 @@ int work_cancel(int qid, FAR struct work_s *work); -

    4.4.2.3.3 work_signal()
    +
    4.5.2.3.3 work_signal()

    Function Prototype: #include <nuttx/wqueue.h> @@ -3291,7 +3344,7 @@ int work_signal(int qid);

    -
    4.4.2.3.4 work_available()
    +
    4.5.2.3.4 work_available()

    Function Prototype:

    -
    4.4.2.3.5 work_usrstart()
    +
    4.5.2.3.5 work_usrstart()

    Function Prototype:

    -
    4.4.2.3.6 lpwork_boostpriority()
    +
    4.5.2.3.6 lpwork_boostpriority()

    Function Prototype:

    -

    4.12.3 Common LED interfaces

    +

    4.13.3 Common LED interfaces

    The include/nuttx/board.h has declarations like: @@ -4488,7 +4541,7 @@ void board_autoled_off(int led); -

    4.13 I/O Buffer Management

    +

    4.14 I/O Buffer Management

    NuttX supports generic I/O buffer management (IOB) logic. This logic was originally added to support network I/O buffering, but has been generalized to meet buffering requirements by all device drivers. @@ -4520,7 +4573,7 @@ This objectives of this feature are: -

    4.13.1 Configuration Options

    +

    4.14.1 Configuration Options

    CONFIG_MM_IOB @@ -4552,12 +4605,12 @@ This objectives of this feature are: NOTE that this selection is not available if DEBUG features are not enabled (CONFIG_DEBUG_FEATURES) with IOBs are being used to syslog buffering logic (CONFIG_SYSLOG_BUFFER).
    -

    4.13.2 Throttling

    +

    4.14.2 Throttling

    An allocation throttle was added. I/O buffer allocation logic supports a throttle value originally for read-ahead buffering to prevent the read-ahead logic from consuming all available I/O buffers and blocking the write buffering logic. This throttle logic is only needed for networking only if both write buffering and read-ahead buffering are used. Of use of I/O buffering might have other motivations for throttling. -

    4.13.3 Public Types

    +

    4.14.3 Public Types

    This structure represents one I/O buffer. A packet is contained by one or more I/O buffers in a chain. The io_pktlen is only valid for the I/O buffer at the head of the chain. @@ -4620,33 +4673,33 @@ struct iob_queue_s #endif /* CONFIG_IOB_NCHAINS > 0 */ -

    4.13.4 Public Function Prototypes

    +

    4.14.4 Public Function Prototypes

    -

    4.13.4.1 iob_initialize()

    +

    4.14.4.1 iob_initialize()

    Function Prototype: 

     #include <nuttx/mm/iob.h>
@@ -4657,7 +4710,7 @@ void iob_initialize(void);
   Set up the I/O buffers for normal operations.
 
    
 
-
    4.13.4.2 iob_alloc()
    
+
    4.14.4.2 iob_alloc()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4668,7 +4721,7 @@ FAR struct iob_s *iob_alloc(bool throttled);
   Allocate an I/O buffer by taking the buffer at the head of the free list.
 
    
 
-
    4.13.4.3 iob_tryalloc()
    
+
    4.14.4.3 iob_tryalloc()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4679,7 +4732,7 @@ FAR struct iob_s *iob_tryalloc(bool throttled);
   Try to allocate an I/O buffer by taking the buffer at the head of the free list without waiting for a buffer to become free.
 
    
 
-
    4.13.4.4 iob_free()
    
+
    4.14.4.4 iob_free()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4690,7 +4743,7 @@ FAR struct iob_s *iob_free(FAR struct iob_s *iob);
    Free the I/O buffer at the head of a buffer chain returning it to the free list.  The link to  the next I/O buffer in the chain is return.
 
    
 
-
    4.13.4.5 iob_free_chain()
    
+
    4.14.4.5 iob_free_chain()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4701,7 +4754,7 @@ void iob_free_chain(FAR struct iob_s *iob);
   Free an entire buffer chain, starting at the beginning of the I/O buffer chain
 
    
 
-
    4.13.4.6 iob_add_queue()
    
+
    4.14.4.6 iob_add_queue()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4714,7 +4767,7 @@ int iob_add_queue(FAR struct iob_s *iob, FAR struct iob_queue_s *iobq);
   Add one I/O buffer chain to the end of a queue.  May fail due to lack of resources.
 
    
 
-
    4.13.4.7 iob_tryadd_queue()
    
+
    4.14.4.7 iob_tryadd_queue()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4727,7 +4780,7 @@ int iob_tryadd_queue(FAR struct iob_s *iob, FAR struct iob_queue_s *iobq);
   Add one I/O buffer chain to the end of a queue without waiting for resources to become free.
 
    
 
-
    4.13.4.8 iob_remove_queue()
    
+
    4.14.4.8 iob_remove_queue()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4744,7 +4797,7 @@ FAR struct iob_s *iob_remove_queue(FAR struct iob_queue_s *iobq);
   Returns a reference to the I/O buffer chain at the head of the queue.
 
    
 
-
    4.13.4.9 iob_peek_queue()
    
+
    4.14.4.9 iob_peek_queue()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4761,7 +4814,7 @@ FAR struct iob_s *iob_peek_queue(FAR struct iob_queue_s *iobq);
   Returns a reference to the I/O buffer chain at the head of the queue.
 
    
 
-
    4.13.4.10 iob_free_queue()
    
+
    4.14.4.10 iob_free_queue()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4774,7 +4827,7 @@ void iob_free_queue(FAR struct iob_queue_s *qhead);
   Free an entire queue of I/O buffer chains.
 
    
 
-
    4.13.4.11 iob_copyin()
    
+
    4.14.4.11 iob_copyin()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4786,7 +4839,7 @@ int iob_copyin(FAR struct iob_s *iob, FAR const uint8_t *src,
   Copy data len bytes from a user buffer into the I/O buffer chain, starting at offset, extending the chain as necessary.
 
    
 
-
    4.13.4.12 iob_trycopyin()
    
+
    4.14.4.12 iob_trycopyin()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4798,7 +4851,7 @@ int iob_trycopyin(FAR struct iob_s *iob, FAR const uint8_t *src,
  Copy data len bytes from a user buffer into the I/O buffer chain, starting at offset, extending the chain as necessary BUT without waiting if buffers are not available.
 
    
 
-
    4.13.4.13 iob_copyout()
    
+
    4.14.4.13 iob_copyout()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4810,7 +4863,7 @@ int iob_copyout(FAR uint8_t *dest, FAR const struct iob_s *iob,
  Copy data len bytes of data into the user buffer starting at offset in the I/O buffer, returning that actual number of bytes copied out.
 
    
 
-
    4.13.4.14 iob_clone()
    
+
    4.14.4.14 iob_clone()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4821,7 +4874,7 @@ int iob_clone(FAR struct iob_s *iob1, FAR struct iob_s *iob2, bool throttled);
   Duplicate (and pack) the data in iob1 in iob2.  iob2 must be empty.
 
    
 
-
    4.13.4.15 iob_concat()
    
+
    4.14.4.15 iob_concat()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4832,7 +4885,7 @@ void iob_concat(FAR struct iob_s *iob1, FAR struct iob_s *iob2);
   Concatenate iob_s chain iob2 to iob1.
 
    
 
-
    4.13.4.16 iob_trimhead()
    
+
    4.14.4.16 iob_trimhead()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4843,7 +4896,7 @@ FAR struct iob_s *iob_trimhead(FAR struct iob_s *iob, unsigned int trimlen);
   Remove bytes from the beginning of an I/O chain.  Emptied I/O buffers are freed and, hence, the beginning of the chain may change.
 
    
 
-
    4.13.4.17 iob_trimhead_queue()
    
+
    4.14.4.17 iob_trimhead_queue()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4864,7 +4917,7 @@ FAR struct iob_s *iob_trimhead_queue(FAR struct iob_queue_s *qhead,
   The new iob at the head of the queue is returned.
 
    
 
-
    4.13.4.18 iob_trimtail()
    
+
    4.14.4.18 iob_trimtail()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4875,7 +4928,7 @@ FAR struct iob_s *iob_trimtail(FAR struct iob_s *iob, unsigned int trimlen);
   Remove bytes from the end of an I/O chain.  Emptied I/O buffers are freed NULL will be returned in the special case where the entry I/O buffer chain is freed.
 
    
 
-
    4.13.4.19 iob_pack()
    
+
    4.14.4.19 iob_pack()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4886,7 +4939,7 @@ FAR struct iob_s *iob_pack(FAR struct iob_s *iob);
   Pack all data in the I/O buffer chain so that the data offset is zero and all but the final buffer in the chain are filled.  Any emptied buffers at the end of the chain are freed.
 
    
 
-
    4.13.4.20 iob_contig()
    
+
    4.14.4.20 iob_contig()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
@@ -4897,7 +4950,7 @@ int iob_contig(FAR struct iob_s *iob, unsigned int len);
   Ensure that there is len bytes of contiguous space at the beginning of the I/O buffer chain starting at iob.
 
    
 
-
    4.13.4.21 iob_dump()
    
+
    4.14.4.21 iob_dump()
    
 
    Function Prototype:
 
     #include <nuttx/mm/iob.h>
diff --git a/include/nuttx/arch.h b/include/nuttx/arch.h
index e80e4a2570..772fcbe639 100644
--- a/include/nuttx/arch.h
+++ b/include/nuttx/arch.h
@@ -72,19 +72,10 @@
  * 3. Common Board Interfaces.
  *
  *    Any interface that is common across all boards should be prefixed
- *    with board_ and should be prototyped in this header file. These
- *    board_ definitions provide the interface between the board-level
+ *    with board_ and should be prototyped in the board.h header file.
+ *    These board_ definitions provide the interface between the board-level
  *    logic and the architecture-specific logic.
  *
- *    Board related declarations are retained the file include/nuttx/board.h.
- *
- *    There is also a configs//include/board.h header file that
- *    can be used to communicate other board-specific information between
- *    the architecture logic and even application logic.  Any definitions
- *    which are common between a single architecture and several boards
- *    should go in this board.h header file; this file is reserved for
- *    board-related definitions common to all architectures.
- *
  * 4. Board-Specific Interfaces.
  *
  *    Any interface which is unique to a board should be prefixed with
diff --git a/sched/Kconfig b/sched/Kconfig
index f2696b5896..9fb6fe9dbd 100644
--- a/sched/Kconfig
+++ b/sched/Kconfig
@@ -1151,8 +1151,8 @@ config BOARD_EARLY_INITIALIZE
 	bool "Custom board early initialization"
 	default n
 	---help---
-		By default, there are three points in time where you can insert
-		custom initialization logic:
+		There are three points in time where you can insert custom,
+		board-specific initialization logic:
 
 		1) _board_initialize():  This function is used only for
 		initialization of very low-level things like configuration of
@@ -1167,7 +1167,7 @@ config BOARD_EARLY_INITIALIZE
 
 		At this same point in time, the OS will also call a board-
 		specific initialization function named board_early_initialize()
-		if CONFIG_BOARD_EARLY_INITIALIZE is selectd.  The context in
+		if CONFIG_BOARD_EARLY_INITIALIZE is selected.  The context in
 		which board_early_initialize() executes is suitable for early
 		initialization of most, simple device drivers and is a logical,
 		board-specific extension of up_initialize().
@@ -1199,8 +1199,8 @@ config BOARD_LATE_INITIALIZE
 	bool "Custom board late initialization"
 	default n
 	---help---
-		By default, there are three points in time where you can insert
-		custom initialization logic:
+		There are three points in time where you can insert custom,
+		board-specific initialization logic:
 
 		1) _board_initialize():  This function is used only for
 		initialization of very low-level things like configuration of
@@ -1215,7 +1215,7 @@ config BOARD_LATE_INITIALIZE
 
 		At this same point in time, the OS will also call a board-
 		specific initialization function named board_early_initialize()
-		if CONFIG_BOARD_EARLY_INITIALIZE is selectd.  The context in
+		if CONFIG_BOARD_EARLY_INITIALIZE is selected.  The context in
 		which board_early_initialize() executes is suitable for early
 		initialization of most, simple device drivers and is a logical,
 		board-specific extension of up_initialize().
diff --git a/sched/init/nx_start.c b/sched/init/nx_start.c
index 9a5eef4d3f..1989477d00 100644
--- a/sched/init/nx_start.c
+++ b/sched/init/nx_start.c
@@ -573,6 +573,7 @@ void nx_start(void)
   g_nx_initstate = OSINIT_TASKLISTS;
 
   /* Initialize RTOS facilities *********************************************/
+
   /* Initialize the semaphore facility.  This has to be done very early
    * because many subsystems depend upon fully functional semaphores.
    */
@@ -711,6 +712,8 @@ void nx_start(void)
   net_initialize();
 #endif
 
+  /* Initialize Hardware Facilities *****************************************/
+
   /* The processor specific details of running the operating system
    * will be handled here.  Such things as setting up interrupt
    * service routines and starting the clock are some of the things
@@ -732,6 +735,8 @@ void nx_start(void)
 
   g_nx_initstate = OSINIT_HARDWARE;
 
+  /* Setup for Multi-Tasking ************************************************/
+
 #ifdef CONFIG_MM_SHM
   /* Initialize shared memory support */