diff --git a/Documentation/NXGraphicsSubsystem.html b/Documentation/NXGraphicsSubsystem.html index 27ef359b4a..6dbb7be3df 100644 --- a/Documentation/NXGraphicsSubsystem.html +++ b/Documentation/NXGraphicsSubsystem.html @@ -13,7 +13,7 @@

NX Graphics Subsystem

-

Last Updated: May 16, 2019

+

Last Updated: August 8, 2019

@@ -960,7 +960,7 @@ struct nx_callback_s

  • The NX server may be started in your board startup logic by simply calling the function nxmu_start(). - The board startup logic usually resides the the boards/board/src directory. + The board startup logic usually resides the the boards/arch/chip/board/src directory. The board startup logic can run automatically during the early system if CONFIG_BOARD_LATE_INITIALIZE is defined in the configuration. Or, the board startup logic can execute under control of the application by calling the boardctl(BOARDIOC_INIT, arg) OS interface.

    @@ -4203,13 +4203,13 @@ static FAR const struct nx_fontpackage_s *g_fontpackages[] =

    Building apps/examples/nx. NX testing was performed using apps/examples/nx with the Linux/Cygwin-based NuttX simulator. - Configuration files for building this test can be found in boards/sim/configs/nx - and boards/sim/configs/nx11. + Configuration files for building this test can be found in boards/sim/sim/sim/configs/nx + and boards/sim/sim/sim/configs/nx11. There are two alternative configurations for building the simulation:

    1. - The configuration using the configuration file at boards/sim/configs/nx/defconfig. + The configuration using the configuration file at boards/sim/sim/sim/configs/nx/defconfig. This default configuration exercises the NX logic a 8 BPP but provides no visual feedback. In this configuration, a very simple, simulated framebuffer driver is used that is based upon a simple region of memory posing as video memory. @@ -4222,7 +4222,7 @@ make

    2. - The preferred configuration is at boards/sim/configs/nx11/defconfig. + The preferred configuration is at boards/sim/sim/sim/configs/nx11/defconfig. This configuration extends the test with a simulated framebuffer driver that uses an X window as a framebuffer. This is a superior test configuration because the X window appears at your desktop @@ -4266,7 +4266,7 @@ sudo ln -s libXext.so.6.4.0 libXext.so

    3. Refer to the readme file in sim configuration - README.txt file for additional information. + README.txt file for additional information.

      4. diff --git a/Documentation/NuttShell.html b/Documentation/NuttShell.html index f98a82f235..a31b286abd 100644 --- a/Documentation/NuttShell.html +++ b/Documentation/NuttShell.html @@ -628,7 +628,7 @@

      NuttShell (NSH)

      -

      Last Updated: February 11, 2019

      +

      Last Updated: August 8, 2019

      @@ -1164,8 +1164,8 @@ mount -t vfat /dev/ram1 /tmp

      NOTE: apps/nshlib/rcS.template generates the standard, default nsh_romfsimg.h file. - If CONFIG_NSH_ARCHROMFS is defined in the NuttX configuration file, then a custom, board-specific nsh_romfsimg.h file residing in boards/<board>/include will be used. - NOTE when the OS is configured, include/arch/board will be linked to boards/<board>/include. + If CONFIG_NSH_ARCHROMFS is defined in the NuttX configuration file, then a custom, board-specific nsh_romfsimg.h file residing in the boards/<arch>/<chip>/<board>/include directory will be used. + NOTE when the OS is configured, include/arch/board will be linked to boards/<arch>/<chip>/<board>/include.

      All of the startup-behavior is contained in rcS.template. The @@ -4022,7 +4022,7 @@ nsh>

      The behavior of NSH can be modified with the following settings in - the boards/<board-name>/defconfig file: + the boards/<arch>/<chip>/<board>/defconfig file:

      @@ -4545,7 +4545,7 @@ set FOOBAR ABC_${FOO}_${BAR} @@ -4652,7 +4652,7 @@ set FOOBAR ABC_${FOO}_${BAR}

    4. If you have C++ static initializers, it will call your implementation of up_cxxinitialize() which will, in turn, call those static initializers. - For the case of the STM3240G-EVAL board, the implementation of up_cxxinitialize() can be found at nuttx/boards/stm3240g-eval/src/up_cxxinitialize.c. + For the case of the STM3240G-EVAL board, the implementation of up_cxxinitialize() can be found at nuttx/boards/arm/stm32/stm3240g-eval/src/up_cxxinitialize.c.

    5. @@ -4758,7 +4758,7 @@ mount -t vfat /dev/ram1 /tmp

      board_app_initialize(): Next any architecture-specific NSH initialization will be performed (if any). - For the STM3240G-EVAL, this architecture specific initialization can be found at boards/stm3240g-eval/src/stm32_appinit.c. + For the STM3240G-EVAL, this architecture specific initialization can be found at boards/arm/stm32/stm3240g-eval/src/stm32_appinit.c. This it does things like: (1) Initialize SPI devices, (2) Initialize SDIO, and (3) mount any SD cards that may be inserted.

    6. @@ -5156,7 +5156,7 @@ CONFIG_SCHED_WAITPID=y

      1. - You can extend the initialization logic in boards/stm3240g-eval/src/stm32_appinit.c. + You can extend the initialization logic in boards/arm/stm32/stm3240g-eval/src/stm32_appinit.c. The logic there is called each time that NSH is started and is good place in particular for any device-related initialization.

      2. @@ -5273,13 +5273,13 @@ mount -t vfat /dev/ram1 /tmp They might provide useful examples:

          - boards/hymini-stm32v/nsh2
          - boards/ntosd-dm320/nsh
          - boards/sim/nsh
          - boards/sim/nsh2
          - boards/sim/nx
          - boards/sim/nx11
          - boards/sim/touchscreen
          +
        • boards/arm/stm32/hymini-stm32v/nsh2
          • +
        • boards/arm/dm320/ntosd-dm320/nsh
          • +
        • boards/sim/sim/sim/nsh
          • +
        • boards/sim/sim/sim/nsh2
          • +
        • boards/sim/sim/sim/nx
          • +
        • boards/sim/sim/sim/nx11
          • +
        • boards/sim/sim/sim/touchscreen

        In most of these cases, the configuration sets up the default /etc/init.d/rcS script. @@ -5338,7 +5338,7 @@ mount -t vfat /dev/ram1 /tmp

        To generate a custom rcS file a copy of rcS.template needs to be placed at tools/ and changed according to the desired start-up behaviour. - Running tools/mkromfsimg.h creates nsh_romfsimg.h which needs to be copied to apps/nshlib OR if CONFIG_NSH_ARCHROMFS is defined to boards/<board>/include. + Running tools/mkromfsimg.h creates nsh_romfsimg.h which needs to be copied to apps/nshlib OR if CONFIG_NSH_ARCHROMFS is defined to boards/<arch>/<chip>/<board>/include.

      @@ -5348,8 +5348,8 @@ mount -t vfat /dev/ram1 /tmp

      - If CONFIG_NSH_ARCHROMFS is defined in the NuttX configuration file, then a custom, board-specific nsh_romfsimg.h file residing in boards/<board>/includewill be used. - NOTE when the OS is configured, include/arch/board will be linked to boards/<board>/include. + If CONFIG_NSH_ARCHROMFS is defined in the NuttX configuration file, then a custom, board-specific nsh_romfsimg.h file residing in boards/<arch>/<chip>/<board>/includewill be used. + NOTE when the OS is configured, include/arch/board will be linked to boards/<arch>/<chip>/<board>/include.

      @@ -5693,7 +5693,7 @@ xxd -i romfs_img >nsh_romfsimg.h

      7. - There is a good example of how to do this in the NSH simulation configuration at boards/sim/nsh. The ROMFS support files are provided at boards/sim/include and the README.txt file at the location provides detailed information about creating and modifying the ROMFS file system. + There is a good example of how to do this in the NSH simulation configuration at boards/sim/sim/sim/configs/nsh. The ROMFS support files are provided at boards/sim/include and the README.txt file at the location provides detailed information about creating and modifying the ROMFS file system.

      CONFIG_NSH_ARCHROMFS - May be defined to specify an alternative ROMFS image that can be found at boards/<board>/include/nsh_romfsimg.h. + May be defined to specify an alternative ROMFS image that can be found at boards/<arch>/<chip>/<board>/include/nsh_romfsimg.h.
      diff --git a/Documentation/NuttxPortingGuide.html b/Documentation/NuttxPortingGuide.html index 7ca8c851a4..25488ac929 100644 --- a/Documentation/NuttxPortingGuide.html +++ b/Documentation/NuttxPortingGuide.html @@ -240,7 +240,7 @@

      NuttX RTOS Porting Guide

      -

      Last Updated: August 5, 2019

      +

      Last Updated: August 8, 2019

      @@ -310,16 +310,20 @@ | | | `-- (binfmt-specific source files) | | `-- (common binfmt source files) | |-- boards/ -| | |-- <board-name>/ -| | | |-- include/ -| | | | `-- (other board-specific header files) -| | | |-- src/ -| | | | `-- (board-specific source files) -| | | `- configs/ -| | | |---<config-name>/ -| | | | `-- (board configuration-specific source files) -| | | `---(other configuration sub-directories for this board)/ -| | `-- <(other board directories)>/ +| | |-- <architecture-name>/ +| | | |-- <chip-name>/ +| | | | |-- <board-name>/ +| | | | | |-- include/ +| | | | | | `-- (other board-specific header files) +| | | | | |-- src/ +| | | | | | `-- (board-specific source files) +| | | | | `- configs/ +| | | | | |---<config-name>/ +| | | | | | `-- (board configuration-specific source files) +| | | | | `---(other configuration sub-directories for this board)/ +| | | | `-- <(other board directories)>/ +| | | `-- <(other chip directories)>/ +| | `-- <(other architecture directories)>/ | |-- crypto | | |-- Makefile | | |-- Kconfig @@ -527,11 +531,11 @@

      These board-specific configuration files can be found in the - boards/<board-name>/ sub-directories and are discussed + boards/<arch-name>/<chip-name>/<board-name>/ sub-directories and are discussed in a paragraph below.

      - The directory boards/stm32f4disovery/, as an example, holds board-specific logic for the STM32F4 Discovery board and is selected via the CONFIG_ARCH_BOARD="stm32f4discovery" configuration setting. + The directory boards/arm/stm32/stm32f4disovery/, as an example, holds board-specific logic for the STM32F4 Discovery board and is selected via the CONFIG_ARCH_BOARD="stm32f4discovery" configuration setting.

      @@ -794,15 +798,14 @@

      2.5 nuttx/boards

      - The boards/ subdirectory contains configuration data for each board. - These board-specific configurations plus the architecture-specific configurations in - the arch/ subdirectory complete define a customized port of NuttX. + The boards/ subdirectory contains custom logic and board configuration data for each board. + These board-specific configurations plus the architecture-specific configurations in the arch/ subdirectory complete define a customized port of NuttX.

      2.5.1 Subdirectory Structure

      The boards/ directory contains board specific configuration files. Each board must - provide a subdirectory <board-name> under boards/ with the following characteristics: + provide a sub-directory <board-name> under boards/<arch-name>/><chip-name>/ with the following characteristics: 

         <board-name>
@@ -852,7 +855,7 @@

      2.5.2.2 Board Specific Configuration Sub-Directories

      - The boards/<board-name>/configs sub-directory holds all of the + The boards/<arch-name>/<chip-name>/<board-name>/configs sub-directory holds all of the files that are necessary to configure NuttX for the particular board. A board may have various different configurations using the common source files. Each board configuration is described by two files: Make.defs and defconfig. @@ -922,7 +925,7 @@

      2.5.3 Supported Boards

      - All of the specific boards supported by NuttX are identified in the README.txt file. + All of the specific boards supported by NuttX are identified in the README.txt file.

      2.5.4 Adding a New Board Configuration

      @@ -932,7 +935,7 @@

      You will need modify the file boards/Kconfig. Let's look at the STM32F4-Discovery configuration in the Kconfig file and see how we would add a new board directory to the configuration. - For this configuration let's say that you new board resides in the directory boards/myboard; + For this configuration let's say that you new board resides in the directory boards/myarch/mychip/myboard; It uses an MCU selected with CONFIG_ARCH_CHIP_MYMCU; and you want the board to be selected with CONFIG_ARCH_BOARD_MYBOARD. Then here is how you can clone the STM32F4-Discovery configuration in boards/Kconfig to support your new board configuration.

      @@ -982,7 +985,7 @@ config ARCH_BOARD

      This logic will assign string value to a configuration variable called CONFIG_ARCH_BOARD that will name the directory where the board-specific files reside. - In our case, these files reside in boards/myboard and we add the following to the long list of defaults (again in alphabetical order): + In our case, these files reside in boards/myarch/mychip/myboard and we add the following to the long list of defaults (again in alphabetical order): 

             default "myboard"             if ARCH_BOARD_MYBOARD
@@ -991,15 +994,15 @@ config ARCH_BOARD
   Now the build system knows where to find your board configuration!
 
        
 
        
-  And finally, add something like this near the bottom of boards/myboard:
+  And finally, add something like this near the bottom of boards/myarch/mychip/myboard:
 
        
 
           if ARCH_BOARD_MYBOARD
-source "boards/myboard/Kconfig"
+source "boards/myarch/mychip/myboard/Kconfig"
 endif
 
        
 
        
-  This includes additional, board-specific configuration variable definitions in boards/myboard/Kconfig.
+  This includes additional, board-specific configuration variable definitions in boards/myarch/mychip/myboard/Kconfig.
 
        
 
 
        2.6 nuttx/crypto
        
@@ -1557,8 +1560,8 @@ tools/
   This could be done manually as follows:
 
        
 
          
-  
        • Copy boards/<board-name>/configs/[<config-dir>/]Make.defs to ${TOPDIR}/Make.defs (see NOTE below),
          • 
-  
        • Copy boards/<board-name>/configs/[<config-dir>/]defconfig to ${TOPDIR}/.config
          • 
+  
        • Copy boards/<arch-name>/<chip-name>/<board-name>/configs/[<config-dir>/]Make.defs to ${TOPDIR}/Make.defs (see NOTE below),
          • 
+  
        • Copy boards/<arch-name>/<chip-name>/<board-name>/configs/[<config-dir>/]defconfig to ${TOPDIR}/.config
          • 
 
        
 
 
        
@@ -1570,7 +1573,7 @@ tools/
   And <app-dir> is the location of the optional application directory.
 
        
 
        
-  NOTE:  Recall that the Make.defs file may reside in either the boards/<board-name>/configs/[<config-dir> directory or in the boards/<board-name>/scripts.
+  NOTE:  Recall that the Make.defs file may reside in either the boards/<arch-name>/<chip-name>/<board-name>/configs/[<config-dir> directory or in the boards/<arch-name>/<chip-name>/<board-name>/scripts.
 
        
 
        
   Automated Configuration.
@@ -1717,8 +1720,8 @@ The specific environmental definitions are unique for each board but should incl
   
      • Auto-generating the file  ${TOPDIR}/.version with version 0.0 if one does not exist.
        • 
   
      • Auto-generating the file include/nuttx/version.h using the ${TOPDIR}/.version file.
        • 
   
      • Creating a link to ${TOPDIR}/arch/<arch-name>/include at ${TOPDIR}/include/arch.
        • 
-  
      • Creating a link to ${TOPDIR}/boards/<board-name>/include at ${TOPDIR}/include/arch/board.
        • 
-  
      • Creating a link to ${TOPDIR}/boards/<board-name>/src at ${TOPDIR}/arch/<arch-name>/src/board
        • 
+  
      • Creating a link to ${TOPDIR}/boards/<arch-name>/<chip-name>/<board-name>/include at ${TOPDIR}/include/arch/board.
        • 
+  
      • Creating a link to ${TOPDIR}/boards/<arch-name>/<chip-name>/<board-name>/src at ${TOPDIR}/arch/<arch-name>/src/board
        • 
   
      • Creating a link to ${APPDIR}/include at ${TOPDIR}/include/apps
        • 
   
      • Creating make dependencies.
      @@ -1774,7 +1777,7 @@ The specific environmental definitions are unique for each board but should incl Board-Specific Interfaces. Any interface which is unique to a board should be prefixed with the board name, for example stm32f4discovery_. Sometimes the board name is too long so stm32_ would be okay too. - These should be prototyped in boards/<board>/src/<board>.h and should not be used outside of that directory since board-specific definitions have no meaning outside of the board directory. + These should be prototyped in boards/<arch>/<chip>/<board>/src/<board>.h and should not be used outside of that directory since board-specific definitions have no meaning outside of the board directory.

    7. @@ -1799,7 +1802,7 @@ The specific environmental definitions are unique for each board but should incl Keeping in the spirit of the layered architecture, these publicly visible header files must not export platform-specific definitions; Only platform-specific realizations of standardized declarations should be visible. Those standardized declarations should appear in common header files such as those provided by include/nuttx/arch.h and include/nuttx/board.h. Similarly, these publicly visible header file must not include files that reside in the inaccessible platform-specific source directories. - For example, the board-specific boards/<board>/include/board.h header file must never include microcontroller-specific header files that reside in arch/<arch>/src/<mcu>. + For example, the board-specific boards/<arch>/<chip>/<board>/include/board.h header file must never include microcontroller-specific header files that reside in arch/<arch>/src/<mcu>. That practice will cause inclusion failures when the publicly visible file is included in common logic outside of the platform-specific source directories.

      8. @@ -5216,7 +5219,7 @@ void iob_dump(FAR const char *msg, FAR struct iob_s *iob, unsigned int len, The controller-specific, "upper half" touchscreen drivers reside in the directory drivers/input.
    8. "Lower Half" Drivers. - Platform-specific touchscreen drivers reside in either: (1) The arch/<architecture>/src/<hardware> directory for the processor architectures that have build in touchscreen controllers or (2) the boards/<board>/src/ directory for boards that use an external touchscreen controller chip. + Platform-specific touchscreen drivers reside in either: (1) The arch/<architecture>/src/<hardware> directory for the processor architectures that have build in touchscreen controllers or (2) the boards/<arch>/<chip>/<board>/src/ directory for boards that use an external touchscreen controller chip.
      9. @@ -6086,7 +6089,7 @@ int kbd_decode(FAR struct lib_instream_s *stream, FAR struct kbd_getstate_s *sta

    9. Examples: - drivers/lcd/p14201.c, boards/sam3u-ek/src/up_lcd.c. + drivers/lcd/p14201.c, boards/arm/sam34/sam3u-ek/src/up_lcd.c. See also the usage of the LCD driver in the graphics/ directory.

      10. @@ -6378,7 +6381,7 @@ int kbd_decode(FAR struct lib_instream_s *stream, FAR struct kbd_getstate_s *sta

      Examples: - The function nsh_waiter() in the file boards/olimex-lpc1766stk/src/lpc17_40_appinit.c. + The function nsh_waiter() in the file boards/arm/lpc17xx_40xx/olimex-lpc1766stk/src/lpc17_40_appinit.c.