Mirrors_Framework/nuttx
1
0
Fork 0
mirror of https://github.com/apache/nuttx.git synced 2026-06-04 23:03:27 +08:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Documentation: Update some documents affected by the change in the organization of the boards/ sub-directory.

Browse Source
This commit is contained in:
Gregory Nutt
2019-08-08 10:05:34 -06:00
parent 2730714774
commit 74c17076c7
3 changed files with 63 additions and 60 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/NXGraphicsSubsystem.html
+7 -7
View File
@@ -13,7 +13,7 @@
<h1><big><font color="#3c34ec"> <h1><big><font color="#3c34ec">
<i>NX Graphics Subsystem</i> <i>NX Graphics Subsystem</i>
</font></big></h1> </font></big></h1>
<p>Last Updated: May 16, 2019</p> <p>Last Updated: August 8, 2019</p>
</td> </td>
</tr> </tr>
</table> </table>
@@ -960,7 +960,7 @@ struct nx_callback_s
<li> <li>
<p> <p>
The NX server may be started in your board startup logic by simply calling the function <code> nxmu_start()</code>. The NX server may be started in your board startup logic by simply calling the function <code> nxmu_start()</code>.
The board startup logic usually resides the the <code>boards/<i>board</i>/src</code> directory. The board startup logic usually resides the the <code>boards/<i>arch</i>/<i>chip</i>/<i>board</i>/src</code> directory.
The board startup logic can run automatically during the early system if <code>CONFIG_BOARD_LATE_INITIALIZE</code> is defined in the configuration. The board startup logic can run automatically during the early system if <code>CONFIG_BOARD_LATE_INITIALIZE</code> is defined in the configuration.
Or, the board startup logic can execute under control of the application by calling the <code>boardctl(BOARDIOC_INIT, arg)</code> OS interface. Or, the board startup logic can execute under control of the application by calling the <code>boardctl(BOARDIOC_INIT, arg)</code> OS interface.
</p> </p>
@@ -4203,13 +4203,13 @@ static FAR const struct nx_fontpackage_s *g_fontpackages[] =
<p><b>Building <code>apps/examples/nx</code></b>. <p><b>Building <code>apps/examples/nx</code></b>.
NX testing was performed using <code>apps/examples/nx</code> with the NX testing was performed using <code>apps/examples/nx</code> with the
Linux/Cygwin-based NuttX simulator. Linux/Cygwin-based NuttX simulator.
Configuration files for building this test can be found in <code>boards/sim/configs/nx</code> Configuration files for building this test can be found in <code>boards/sim/sim/sim/configs/nx</code>
and <code>boards/sim/configs/nx11</code>. and <code>boards/sim/sim/sim/configs/nx11</code>.
There are two alternative configurations for building the simulation: There are two alternative configurations for building the simulation:
</p> </p>
<ol> <ol>
<li> <li>
The configuration using the configuration file at <code>boards/sim/configs/nx/defconfig</code>. The configuration using the configuration file at <code>boards/sim/sim/sim/configs/nx/defconfig</code>.
This default configuration exercises the NX logic a 8 BPP but provides no visual feedback. 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 In this configuration, a very simple, simulated framebuffer driver is used that is
based upon a simple region of memory posing as video memory. based upon a simple region of memory posing as video memory.
@@ -4222,7 +4222,7 @@ make
</li> </li>
<li> <li>
<p> <p>
The preferred configuration is at <code>boards/sim/configs/nx11/defconfig</code>. The preferred configuration is at <code>boards/sim/sim/sim/configs/nx11/defconfig</code>.
This configuration extends the test with a simulated framebuffer driver This configuration extends the test with a simulated framebuffer driver
that uses an X window as a framebuffer. that uses an X window as a framebuffer.
This is a superior test configuration because the X window appears at your desktop 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
</li> </li>
<li><p> <li><p>
Refer to the readme file in sim configuration Refer to the readme file in sim configuration
<a href="https://bitbucket.org/nuttx/nuttx/boards/src/master/sim/README.txt" target="_blank">README.txt</a> file for additional information. <a href="https://bitbucket.org/nuttx/nuttx/src/master/boards/sim/sim/sim/README.txt" target="_blank">README.txt</a> file for additional information.
</p></li> </p></li>
</ul> </ul>
</p> </p>
Documentation/NuttShell.html
+19 -19
View File
@@ -628,7 +628,7 @@
<tr align="center" bgcolor="#e4e4e4"> <tr align="center" bgcolor="#e4e4e4">
<td> <td>
<h1><big><font color="#3c34ec"><i>NuttShell (NSH)</i></font></big></h1> <h1><big><font color="#3c34ec"><i>NuttShell (NSH)</i></font></big></h1>
<p>Last Updated: February 11, 2019</p> <p>Last Updated: August 8, 2019</p>
</td> </td>
</tr> </tr>
</table> </table>
@@ -1164,8 +1164,8 @@ mount -t vfat /dev/ram1 /tmp
<p> <p>
<b>NOTE</b>: <b>NOTE</b>:
<code>apps/nshlib/rcS.template</code> generates the standard, default <code>nsh_romfsimg.h</code> file. <code>apps/nshlib/rcS.template</code> generates the standard, default <code>nsh_romfsimg.h</code> file.
If <code>CONFIG_NSH_ARCHROMFS</code> is defined in the NuttX configuration file, then a custom, board-specific <code>nsh_romfsimg.h</code> file residing in <code>boards/&lt;board&gt;/include</code> will be used. If <code>CONFIG_NSH_ARCHROMFS</code> is defined in the NuttX configuration file, then a custom, board-specific <code>nsh_romfsimg.h</code> file residing in the <code>boards/&lt;arch&gt;/&lt;chip&gt;/&lt;board&gt;/include</code> directory will be used.
NOTE when the OS is configured, <code>include/arch/board</code> will be linked to <code>boards/&lt;board&gt;/include</code>. NOTE when the OS is configured, <code>include/arch/board</code> will be linked to <code>boards/&lt;arch&gt;/&lt;chip&gt;/&lt;board&gt;/include</code>.
</p> </p>
<p> <p>
All of the startup-behavior is contained in <code>rcS.template</code>. The All of the startup-behavior is contained in <code>rcS.template</code>. The
@@ -4022,7 +4022,7 @@ nsh&gt;
<p> <p>
The behavior of NSH can be modified with the following settings in The behavior of NSH can be modified with the following settings in
the <code>boards/&lt;board-name&gt;/defconfig</code> file: the <code>boards/&lt;arch&gt;/&lt;chip&gt;/&lt;board&gt;/defconfig</code> file:
</p> </p>
<center><table width="100%"> <center><table width="100%">
@@ -4545,7 +4545,7 @@ set FOOBAR ABC_${FOO}_${BAR}
<tr> <tr>
<td valign="top"><b><code>CONFIG_NSH_ARCHROMFS</code></b></td> <td valign="top"><b><code>CONFIG_NSH_ARCHROMFS</code></b></td>
<td> <td>
May be defined to specify an alternative ROMFS image that can be found at <code>boards/&lt;board&gt;/include/nsh_romfsimg.h</code>. May be defined to specify an alternative ROMFS image that can be found at <code>boards/&lt;arch&gt;/&lt;chip&gt;/&lt;board&gt;/include/nsh_romfsimg.h</code>.
</td> </td>
</tr> </tr>
<tr> <tr>
@@ -4652,7 +4652,7 @@ set FOOBAR ABC_${FOO}_${BAR}
<li> <li>
<p> <p>
If you have C++ static initializers, it will call your implementation of <code>up_cxxinitialize()</code> which will, in turn, call those static initializers. If you have C++ static initializers, it will call your implementation of <code>up_cxxinitialize()</code> which will, in turn, call those static initializers.
For the case of the STM3240G-EVAL board, the implementation of <code>up_cxxinitialize()</code> can be found at <code>nuttx/boards/stm3240g-eval/src/up_cxxinitialize.c</code>. For the case of the STM3240G-EVAL board, the implementation of <code>up_cxxinitialize()</code> can be found at <code>nuttx/boards/arm/stm32/stm3240g-eval/src/up_cxxinitialize.c</code>.
</p> </p>
<li> <li>
<p> <p>
@@ -4758,7 +4758,7 @@ mount -t vfat /dev/ram1 /tmp
<p> <p>
<code>board_app_initialize()</code>: <code>board_app_initialize()</code>:
Next any architecture-specific NSH initialization will be performed (if any). Next any architecture-specific NSH initialization will be performed (if any).
For the STM3240G-EVAL, this architecture specific initialization can be found at <code>boards/stm3240g-eval/src/stm32_appinit.c</code>. For the STM3240G-EVAL, this architecture specific initialization can be found at <code>boards/arm/stm32/stm3240g-eval/src/stm32_appinit.c</code>.
This it does things like: (1) Initialize SPI devices, (2) Initialize SDIO, and (3) mount any SD cards that may be inserted. This it does things like: (1) Initialize SPI devices, (2) Initialize SDIO, and (3) mount any SD cards that may be inserted.
</p> </p>
<li> <li>
@@ -5156,7 +5156,7 @@ CONFIG_SCHED_WAITPID=y
<ol> <ol>
<li> <li>
<p> <p>
You can extend the initialization logic in <code>boards/stm3240g-eval/src/stm32_appinit.c</code>. You can extend the initialization logic in <code>boards/arm/stm32/stm3240g-eval/src/stm32_appinit.c</code>.
The logic there is called each time that NSH is started and is good place in particular for any device-related initialization. The logic there is called each time that NSH is started and is good place in particular for any device-related initialization.
</p> </p>
<li> <li>
@@ -5273,13 +5273,13 @@ mount -t vfat /dev/ram1 /tmp
They might provide useful examples: They might provide useful examples:
</p> </p>
<ul> <ul>
<code>boards/hymini-stm32v/nsh2<br> <li><code>boards/arm/stm32/hymini-stm32v/nsh2</code></li>
boards/ntosd-dm320/nsh<br> <li><code>boards/arm/dm320/ntosd-dm320/nsh</code></li>
boards/sim/nsh<br> <li><code>boards/sim/sim/sim/nsh</code></li>
boards/sim/nsh2<br> <li><code>boards/sim/sim/sim/nsh2</code></li>
boards/sim/nx<br> <li><code>boards/sim/sim/sim/nx</code></li>
boards/sim/nx11<br> <li><code>boards/sim/sim/sim/nx11</code></li>
boards/sim/touchscreen<br> <li><code>boards/sim/sim/sim/touchscreen</code></li>
</ul> </ul>
<p> <p>
In most of these cases, the configuration sets up the <i>default</i> <code>/etc/init.d/rcS</code> script. In most of these cases, the configuration sets up the <i>default</i> <code>/etc/init.d/rcS</code> script.
@@ -5338,7 +5338,7 @@ mount -t vfat /dev/ram1 /tmp
</p> </p>
<p> <p>
To generate a custom <code>rcS</code> file a copy of <code>rcS.template</code> needs to be placed at <code>tools/</code> and changed according to the desired start-up behaviour. To generate a custom <code>rcS</code> file a copy of <code>rcS.template</code> needs to be placed at <code>tools/</code> and changed according to the desired start-up behaviour.
Running <code>tools/mkromfsimg.h</code> creates <code>nsh_romfsimg.h</code> which needs to be copied to <code>apps/nshlib</code> OR if <code>CONFIG_NSH_ARCHROMFS</code> is defined to <code>boards/&lt;board&gt;/include</code>. Running <code>tools/mkromfsimg.h</code> creates <code>nsh_romfsimg.h</code> which needs to be copied to <code>apps/nshlib</code> OR if <code>CONFIG_NSH_ARCHROMFS</code> is defined to <code>boards/&lt;arch&gt;/&lt;chip&gt;/&lt;board&gt;/include</code>.
</p> </p>
</ol> </ol>
@@ -5348,8 +5348,8 @@ mount -t vfat /dev/ram1 /tmp
</p> </p>
<p> <p>
If <code>CONFIG_NSH_ARCHROMFS</code> is defined in the NuttX configuration file, then a custom, board-specific <code>nsh_romfsimg.h</code> file residing in <code>boards/&lt;board&gt;/include</code>will be used. If <code>CONFIG_NSH_ARCHROMFS</code> is defined in the NuttX configuration file, then a custom, board-specific <code>nsh_romfsimg.h</code> file residing in <code>boards/&lt;arch&gt;/&lt;chip&gt;/&lt;board&gt;/include</code>will be used.
NOTE when the OS is configured, <code>include/arch/board</code> will be linked to <code>boards/&lt;board&gt;/include</code>. NOTE when the OS is configured, <code>include/arch/board</code> will be linked to <code>boards/&lt;arch&gt;/&lt;chip&gt;/&lt;board&gt;/include</code>.
</p> </p>
<p> <p>
@@ -5693,7 +5693,7 @@ xxd -i romfs_img >nsh_romfsimg.h
</li> </li>
</ol> </ol>
<p> <p>
There is a good example of how to do this in the NSH simulation configuration at <a href="https://bitbucket.org/nuttx/nuttx/boards/src/master/sim/nsh/">boards/sim/nsh</a>. The ROMFS support files are provided at <a href="https://bitbucket.org/nuttx/nuttx/boards/src/master/sim/include/">boards/sim/include</a> and the <a href="https://bitbucket.org/nuttx/nuttx/boards/src/master/sim/include/README.txt">README.txt</a> 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 <a href="https://bitbucket.org/nuttx/nuttx/src/master/boards/sim/sim/sim/configs/nsh/">boards/sim/sim/sim/configs/nsh</a>. The ROMFS support files are provided at <a href="https://bitbucket.org/nuttx/nuttx/boards/src/master/sim/sim/sim/include/">boards/sim/include</a> and the <a href="https://bitbucket.org/nuttx/nuttx/src/master/boards/sim/sim/sim/include/README.txt">README.txt</a> file at the location provides detailed information about creating and modifying the ROMFS file system.
</p> </p>
<table width ="100%"> <table width ="100%">
Documentation/NuttxPortingGuide.html
+37 -34
View File
@@ -240,7 +240,7 @@
<h1><big><font color="#3c34ec"> <h1><big><font color="#3c34ec">
<i>NuttX RTOS Porting Guide</i> <i>NuttX RTOS Porting Guide</i>
</font></big></h1> </font></big></h1>
<p>Last Updated: August 5, 2019</p> <p>Last Updated: August 8, 2019</p>
</td> </td>
</tr> </tr>
</table> </table>
@@ -310,16 +310,20 @@
| | | `-- <i>(binfmt-specific source files)</i> | | | `-- <i>(binfmt-specific source files)</i>
| | `-- <i>(common binfmt source files)</i> | | `-- <i>(common binfmt source files)</i>
| |-- <a href="#DirStructConfigs">boards</a>/ | |-- <a href="#DirStructConfigs">boards</a>/
| | |-- <i>&lt;board-name&gt;</i>/ | | |-- <i>&lt;architecture-name&gt;</i>/
| | | |-- include/ | | | |-- <i>&lt;chip-name&gt;</i>/
| | | | `-- <i>(other board-specific header files)</i> | | | | |-- <i>&lt;board-name&gt;</i>/
| | | |-- src/ | | | | | |-- include/
| | | | `-- <i>(board-specific source files)</i> | | | | | | `-- <i>(other board-specific header files)</i>
| | | `- configs/ | | | | | |-- src/
| | | |---<i>&lt;config-name&gt;</i>/ | | | | | | `-- <i>(board-specific source files)</i>
| | | | `-- <i>(board configuration-specific source files)</i> | | | | | `- configs/
| | | `---<i>(other configuration sub-directories for this board)</i>/ | | | | | |---<i>&lt;config-name&gt;</i>/
| | `-- <i>&lt;(other board directories)&gt;</i>/ | | | | | | `-- <i>(board configuration-specific source files)</i>
| | | | | `---<i>(other configuration sub-directories for this board)</i>/
| | | | `-- <i>&lt;(other board directories)&gt;</i>/
| | | `-- <i>&lt;(other chip directories)&gt;</i>/
| | `-- <i>&lt;(other architecture directories)&gt;</i>/
| |-- crypto | |-- crypto
| | |-- Makefile | | |-- Makefile
| | |-- Kconfig | | |-- Kconfig
@@ -527,11 +531,11 @@
</p> </p>
<p> <p>
These board-specific configuration files can be found in the These board-specific configuration files can be found in the
<code>boards/</code><i>&lt;board-name&gt;</i><code>/</code> sub-directories and are discussed <code>boards/</code><i>&lt;arch-name&gt;</i><code>/</code><i>&lt;chip-name&gt;</i><code>/</code><i>&lt;board-name&gt;</i><code>/</code> sub-directories and are discussed
in a paragraph <a href="#boardsdirectorystructure">below</a>. in a paragraph <a href="#boardsdirectorystructure">below</a>.
</p> </p>
<p> <p>
The directory <code>boards/stm32f4disovery/</code>, as an example, holds board-specific logic for the STM32F4 Discovery board and is selected via the <code>CONFIG_ARCH_BOARD=&quot;stm32f4discovery&quot;</code> configuration setting. The directory <code>boards/arm/stm32/stm32f4disovery/</code>, as an example, holds board-specific logic for the STM32F4 Discovery board and is selected via the <code>CONFIG_ARCH_BOARD=&quot;stm32f4discovery&quot;</code> configuration setting.
</p> </p>
</li> </li>
</ul> </ul>
@@ -794,15 +798,14 @@
<h2>2.5 <a name="DirStructConfigs">nuttx/boards</a></h2> <h2>2.5 <a name="DirStructConfigs">nuttx/boards</a></h2>
<p> <p>
The <code>boards/</code> subdirectory contains configuration data for each board. The <code>boards/</code> subdirectory contains custom logic and board configuration data for each board.
These board-specific configurations plus the architecture-specific configurations in These board-specific configurations plus the architecture-specific configurations in the <code>arch/</code> subdirectory complete define a customized port of NuttX.
the <code>arch/</code> subdirectory complete define a customized port of NuttX.
</p> </p>
<h3><a name="boardsdirectorystructure">2.5.1 Subdirectory Structure</a></h3> <h3><a name="boardsdirectorystructure">2.5.1 Subdirectory Structure</a></h3>
<p> <p>
The <code>boards/</code> directory contains board specific configuration files. Each board must The <code>boards/</code> directory contains board specific configuration files. Each board must
provide a subdirectory &lt;board-name&gt; under <code>boards/</code> with the following characteristics: provide a sub-directory &lt;board-name&gt; under <code>boards/</code><i>&lt;arch-name&gt;</i><code>/</code>><i>&lt;chip-name&gt;</i><code>/</code> with the following characteristics:
</p> </p>
<ul><pre> <ul><pre>
<i>&lt;board-name&gt;</i> <i>&lt;board-name&gt;</i>
@@ -852,7 +855,7 @@
</ul> </ul>
<h4><a name="boardconfigsubdirs">2.5.2.2 Board Specific Configuration Sub-Directories</a></h4> <h4><a name="boardconfigsubdirs">2.5.2.2 Board Specific Configuration Sub-Directories</a></h4>
<p> <p>
The <code>boards/</code><i>&lt;board-name&gt;</i><code>/configs</code> sub-directory holds all of the The <code>boards/</code><i>&lt;arch-name&gt;</i><code>/</code><i>&lt;chip-name&gt;</i><code>/</code><i>&lt;board-name&gt;</i><code>/configs</code> sub-directory holds all of the
files that are necessary to configure NuttX for the particular board. files that are necessary to configure NuttX for the particular board.
A board may have various different configurations using the common source files. A board may have various different configurations using the common source files.
Each board configuration is described by two files: <code>Make.defs</code> and <code>defconfig</code>. Each board configuration is described by two files: <code>Make.defs</code> and <code>defconfig</code>.
@@ -922,7 +925,7 @@
<h3><a name="supportedboards">2.5.3 Supported Boards</a></h3> <h3><a name="supportedboards">2.5.3 Supported Boards</a></h3>
<p> <p>
All of the specific boards supported by NuttX are identified in the <a href="https://bitbucket.org/nuttx/nuttx/boards/src/master/README.txt" target="_blank">README.txt</a> file. All of the specific boards supported by NuttX are identified in the <a href="https://bitbucket.org/nuttx/nuttx/src/master/boards/README.txt" target="_blank">README.txt</a> file.
</p> </p>
<h3><a name="newboardconfig">2.5.4 Adding a New Board Configuration</a></h3> <h3><a name="newboardconfig">2.5.4 Adding a New Board Configuration</a></h3>
<p> <p>
@@ -932,7 +935,7 @@
<p> <p>
You will need modify the file <code>boards/Kconfig</code>. You will need modify the file <code>boards/Kconfig</code>.
Let's look at the STM32F4-Discovery configuration in the <code>Kconfig</code> file and see how we would add a new board directory to the configuration. Let's look at the STM32F4-Discovery configuration in the <code>Kconfig</code> 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 <code>boards/myboard</code>; For this configuration let's say that you new board resides in the directory <code>boards/myarch/mychip/myboard</code>;
It uses an MCU selected with <code>CONFIG_ARCH_CHIP_MYMCU</code>; and you want the board to be selected with <code>CONFIG_ARCH_BOARD_MYBOARD</code>. It uses an MCU selected with <code>CONFIG_ARCH_CHIP_MYMCU</code>; and you want the board to be selected with <code>CONFIG_ARCH_BOARD_MYBOARD</code>.
Then here is how you can clone the STM32F4-Discovery configuration in <code>boards/Kconfig</code> to support your new board configuration. Then here is how you can clone the STM32F4-Discovery configuration in <code>boards/Kconfig</code> to support your new board configuration.
</p> </p>
@@ -982,7 +985,7 @@ config ARCH_BOARD
</pre></ul> </pre></ul>
<p> <p>
This logic will assign string value to a configuration variable called <code>CONFIG_ARCH_BOARD</code> that will name the directory where the board-specific files reside. This logic will assign string value to a configuration variable called <code>CONFIG_ARCH_BOARD</code> that will name the directory where the board-specific files reside.
In our case, these files reside in <code>boards/myboard</code> and we add the following to the long list of defaults (again in alphabetical order): In our case, these files reside in <code>boards/myarch/mychip/myboard</code> and we add the following to the long list of defaults (again in alphabetical order):
</p> </p>
<ul><pre> <ul><pre>
default "myboard" if ARCH_BOARD_MYBOARD default "myboard" if ARCH_BOARD_MYBOARD
@@ -991,15 +994,15 @@ config ARCH_BOARD
Now the build system knows where to find your board configuration! Now the build system knows where to find your board configuration!
</p> </p>
<p> <p>
And finally, add something like this near the bottom of <code>boards/myboard</code>: And finally, add something like this near the bottom of <code>boards/myarch/mychip/myboard</code>:
</p> </p>
<ul><pre> <ul><pre>
if ARCH_BOARD_MYBOARD if ARCH_BOARD_MYBOARD
source "boards/myboard/Kconfig" source "boards/myarch/mychip/myboard/Kconfig"
endif endif
</pre></ul> </pre></ul>
<p> <p>
This includes additional, board-specific configuration variable definitions in <code>boards/myboard/Kconfig</code>. This includes additional, board-specific configuration variable definitions in <code>boards/myarch/mychip/myboard/Kconfig</code>.
</p> </p>
<h2>2.6 <a name="DirStructCrypto">nuttx/crypto</a></h2> <h2>2.6 <a name="DirStructCrypto">nuttx/crypto</a></h2>
@@ -1557,8 +1560,8 @@ tools/
This could be done manually as follows: This could be done manually as follows:
</p> </p>
<ul> <ul>
<li>Copy <code>boards/</code><i>&lt;board-name&gt;</i>/<code>configs/[</code><i>&lt;config-dir&gt;</i><code>/]Make.defs</code> to <code>${TOPDIR}/Make.defs</code> (see NOTE below),</li> <li>Copy <code>boards/</code><i>&lt;arch-name&gt;</i><code>/</code><i>&lt;chip-name&gt;</i><code>/</code><i>&lt;board-name&gt;</i><code>/configs/[</code><i>&lt;config-dir&gt;</i><code>/]Make.defs</code> to <code>${TOPDIR}/Make.defs</code> (see NOTE below),</li>
<li>Copy <code>boards/</code><i>&lt;board-name&gt;</i>/<code>configs/[</code><i>&lt;config-dir&gt;</i><code>/]defconfig</code> to <code>${TOPDIR}/.config</code></li> <li>Copy <code>boards/</code><i>&lt;arch-name&gt;</i><code>/</code><i>&lt;chip-name&gt;</i><code>/</code><i>&lt;board-name&gt;</i><code>/configs/[</code><i>&lt;config-dir&gt;</i><code>/]defconfig</code> to <code>${TOPDIR}/.config</code></li>
</ul> </ul>
<p> <p>
@@ -1570,7 +1573,7 @@ tools/
And &lt;app-dir&gt; is the location of the optional application directory. And &lt;app-dir&gt; is the location of the optional application directory.
</p> </p>
<p> <p>
NOTE: Recall that the <code>Make.defs</code> file may reside in either the <code>boards/</code><i>&lt;board-name&gt;</i>/<code>configs/[</code><i>&lt;config-dir&gt;</i></code> directory or in the <code>boards/</code><i>&lt;board-name&gt;</i>/<code>scripts</code>. NOTE: Recall that the <code>Make.defs</code> file may reside in either the <code>boards/</code><i>&lt;arch-name&gt;</i><code>/</code><i>&lt;chip-name&gt;</i><code>/</code><i>&lt;board-name&gt;</i>/<code>configs/[</code><i>&lt;config-dir&gt;</i></code> directory or in the <code>boards/</code><i>&lt;arch-name&gt;</i><code>/</code><i>&lt;chip-name&gt;</i><code>/</code><i>&lt;board-name&gt;</i>/<code>scripts</code>.
</p> </p>
<p> <p>
<b>Automated Configuration</b>. <b>Automated Configuration</b>.
@@ -1717,8 +1720,8 @@ The specific environmental definitions are unique for each board but should incl
<li>Auto-generating the file <code>${TOPDIR}/.version</code> with version 0.0 if one does not exist.</li> <li>Auto-generating the file <code>${TOPDIR}/.version</code> with version 0.0 if one does not exist.</li>
<li>Auto-generating the file <code>include/nuttx/version.h</code> using the <code>${TOPDIR}/.version</code> file.</li> <li>Auto-generating the file <code>include/nuttx/version.h</code> using the <code>${TOPDIR}/.version</code> file.</li>
<li>Creating a link to <code>${TOPDIR}/arch/</code><i>&lt;arch-name&gt;</i><code>/include</code> at <code>${TOPDIR}/include/arch</code>.</li> <li>Creating a link to <code>${TOPDIR}/arch/</code><i>&lt;arch-name&gt;</i><code>/include</code> at <code>${TOPDIR}/include/arch</code>.</li>
<li>Creating a link to <code>${TOPDIR}/boards/</code><i>&lt;board-name&gt;</i><code>/include</code> at <code>${TOPDIR}/include/arch/board</code>.</li> <li>Creating a link to <code>${TOPDIR}/boards/</code><i>&lt;arch-name&gt;</i><code>/</code><i>&lt;chip-name&gt;</i><code>/</code><i>&lt;board-name&gt;</i><code>/include</code> at <code>${TOPDIR}/include/arch/board</code>.</li>
<li>Creating a link to <code>${TOPDIR}/boards/</code><i>&lt;board-name&gt;</i><code>/src</code> at <code>${TOPDIR}/arch/</code><i>&lt;arch-name&gt;</i><code>/src/board</code></li> <li>Creating a link to <code>${TOPDIR}/boards/</code><i>&lt;arch-name&gt;</i><code>/</code><i>&lt;chip-name&gt;</i><code>/</code><i>&lt;board-name&gt;</i><code>/src</code> at <code>${TOPDIR}/arch/</code><i>&lt;arch-name&gt;</i><code>/src/board</code></li>
<li>Creating a link to <code>${APPDIR}/include</code> at <code>${TOPDIR}/include/apps</code></li> <li>Creating a link to <code>${APPDIR}/include</code> at <code>${TOPDIR}/include/apps</code></li>
<li>Creating make dependencies. <li>Creating make dependencies.
</ul> </ul>
@@ -1774,7 +1777,7 @@ The specific environmental definitions are unique for each board but should incl
<b>Board-Specific Interfaces</b>. <b>Board-Specific Interfaces</b>.
Any interface which is unique to a board should be prefixed with the board name, for example <code>stm32f4discovery_</code>. Any interface which is unique to a board should be prefixed with the board name, for example <code>stm32f4discovery_</code>.
Sometimes the board name is too long so <code>stm32_</code> would be okay too. Sometimes the board name is too long so <code>stm32_</code> would be okay too.
These should be prototyped in <code>boards/&lt;board&gt;/src/&lt;board&gt;.h</code> 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 <code>boards/&lt;arch&gt;/&lt;chip&gt;/&lt;board&gt;/src/&lt;board&gt;.h</code> and should not be used outside of that directory since board-specific definitions have no meaning outside of the board directory.
</li> </li>
<li> <li>
<p> <p>
@@ -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 <i>not</i> export platform-specific definitions; Only platform-specific realizations of standardized declarations should be visible. Keeping in the spirit of the layered architecture, these publicly visible header files must <i>not</i> export platform-specific definitions; Only platform-specific realizations of standardized declarations should be visible.
Those <i>standardized declarations</i> should appear in common header files such as those provided by <code>include/nuttx/arch.h</code> and <code>include/nuttx/board.h</code>. Those <i>standardized declarations</i> should appear in common header files such as those provided by <code>include/nuttx/arch.h</code> and <code>include/nuttx/board.h</code>.
Similarly, these publicly visible header file must <i>not</i> include files that reside in the inaccessible platform-specific source directories. Similarly, these publicly visible header file must <i>not</i> include files that reside in the inaccessible platform-specific source directories.
For example, the board-specific <code>boards/&lt;board&gt;/include/board.h</code> header file must never include microcontroller-specific header files that reside in <code>arch/&lt;arch&gt;/src/&lt;mcu&gt;</code>. For example, the board-specific <code>boards/&lt;arch&gt;/&lt;chip&gt;/&lt;board&gt;/include/board.h</code> header file must never include microcontroller-specific header files that reside in <code>arch/&lt;arch&gt;/src/&lt;mcu&gt;</code>.
That practice will cause inclusion failures when the publicly visible file is included in common logic outside of the platform-specific source directories. That practice will cause inclusion failures when the publicly visible file is included in common logic outside of the platform-specific source directories.
</p> </p>
</li> </li>
@@ -5216,7 +5219,7 @@ void iob_dump(FAR const char *msg, FAR struct iob_s *iob, unsigned int len,
The controller-specific, &quot;upper half&quot; touchscreen drivers reside in the directory <code>drivers/input</code>. The controller-specific, &quot;upper half&quot; touchscreen drivers reside in the directory <code>drivers/input</code>.
</li> </li>
<li><b>&quot;Lower Half&quot; Drivers</b>. <li><b>&quot;Lower Half&quot; Drivers</b>.
Platform-specific touchscreen drivers reside in either: (1) The <code>arch/</code><i>&lt;architecture&gt;</i><code>/src/</code><i>&lt;hardware&gt;</i> directory for the processor architectures that have build in touchscreen controllers or (2) the <code>boards/</code><i>&lt;board&gt;</i><code>/src/</code> directory for boards that use an external touchscreen controller chip. Platform-specific touchscreen drivers reside in either: (1) The <code>arch/</code><i>&lt;architecture&gt;</i><code>/src/</code><i>&lt;hardware&gt;</i> directory for the processor architectures that have build in touchscreen controllers or (2) the <code>boards/</code><i>&lt;arch&gt;</i><code>/</code><i>&lt;chip&gt;</i><code>/</code><i>&lt;board&gt;</i><code>/src/</code> directory for boards that use an external touchscreen controller chip.
</li> </li>
</ul> </ul>
@@ -6086,7 +6089,7 @@ int kbd_decode(FAR struct lib_instream_s *stream, FAR struct kbd_getstate_s *sta
<li> <li>
<p> <p>
<b>Examples</b>: <b>Examples</b>:
<code>drivers/lcd/p14201.c</code>, <code>boards/sam3u-ek/src/up_lcd.c.</code> <code>drivers/lcd/p14201.c</code>, <code>boards/arm/sam34/sam3u-ek/src/up_lcd.c.</code>
See also the usage of the LCD driver in the <code>graphics/</code> directory. See also the usage of the LCD driver in the <code>graphics/</code> directory.
</p> </p>
</li> </li>
@@ -6378,7 +6381,7 @@ int kbd_decode(FAR struct lib_instream_s *stream, FAR struct kbd_getstate_s *sta
</p> </p>
<p> <p>
<b>Examples</b>: <b>Examples</b>:
The function <code>nsh_waiter()</code> in the file <code>boards/olimex-lpc1766stk/src/lpc17_40_appinit.c</code>. The function <code>nsh_waiter()</code> in the file <code>boards/arm/lpc17xx_40xx/olimex-lpc1766stk/src/lpc17_40_appinit.c</code>.
</p> </p>
</li> </li>
<li> <li>