diff --git a/ChangeLog b/ChangeLog
index c0e2a2e9a0bc6c140b00cd5a72f6d60aa31c2cc6..65fcd4ebd4f2871125077434753ed89a2c43ee6c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -773,7 +773,7 @@
* The NXP LPC2148 and STR711 targets can now also be built using the CodeSourcery
or devkitARM Windows native toolchains.
-0.4.8 2009-xx-xx Gregory Nutt <spudmonkey@racsa.co.cr>
+0.4.9 2009-06-26 Gregory Nutt <spudmonkey@racsa.co.cr>
* Add strtoll() and strtoull(); Add macros for atol() and atoll().
* dup() and dup2() will now clone socket descriptors
@@ -802,6 +802,7 @@
This file has been around for a long time, but I don't think it has
every been used before (i.e., prior to the NXFLAT logic)
+0.4.10 2009-xx-xx Gregory Nutt <spudmonkey@racsa.co.cr>
diff --git a/Documentation/NuttX.html b/Documentation/NuttX.html
index 0dfc4d0e0aedf80ca2012e1189c4696066e19346..36eba419bad3ee370c403d901d013c13e7b4e6ea 100644
--- a/Documentation/NuttX.html
+++ b/Documentation/NuttX.html
@@ -8,7 +8,7 @@
<tr align="center" bgcolor="#e4e4e4">
<td>
<h1><big><font color="#3c34ec"><i>NuttX RTOS</i></font></big></h1>
- <p>Last Updated: June 25, 2009</p>
+ <p>Last Updated: June 26, 2009</p>
</td>
</tr>
</table>
@@ -411,6 +411,15 @@
<li>ROMFS filesystem support.</li>
</p>
</tr>
+<tr>
+ <td><br></td>
+ <td>
+ <p>
+ <li><a href="NuttXNxFlat.html">NXFLAT</a>.
+ A new binary format call NXFLAT that can be used to
+ execute separately linked programs in place in a file system.
+ </p>
+</tr>
<tr>
<td valign="top" width="22"><img height="20" width="20" src="favicon.ico"></td>
@@ -687,8 +696,8 @@
</tr>
</table>
-<p><b>nuttx-0.4.8</b>.
- This 40<sup>th</sup> release of NuttX (nuttx-0.4.8) was made on June 13, 2009
+<p><b>nuttx-0.4.9</b>.
+ This 41<sup>st</sup> release of NuttX (nuttx-0.4.9) was made on June 26, 2009
and is available for download from the
<a href="http://sourceforge.net/project/showfiles.php?group_id=189573">SourceForge</a>
website.
@@ -698,21 +707,16 @@
</p>
This release adds:
<ul>
- <li>
- Support for the Olimex STRP711 board. That board is based on the STMicro
- STR711 MCU (ARM7TDMI). Integration is complete on the basic port (boot logic,
- system time, serial console). Two configurations have been verified: (1) The
- board boots and passes the OS test with console output visible on UART0, and
- the NuttShell (NSH) is fully functional with interrupt driven serial console.
- An SPI driver is available but untested (because the Olimex card slot appears
- to accept only MMC cards; I have only SD cards). Additional needed: USB and
- driver, MMC integration.
- </li>
- <li>
- Support for the CodeSourcery and devkitARM Windows-native GNU toolchains.
- Makefiles have been modified for the LM3S6918, LPC2148, and STR711 to support
- these toolchains under Cygwin.
- </li>
+ <li>
+ Support for a new binary format call NXFLAT that can be used to
+ execute separately linked programs in place in a file system.
+ See <a href="NuttXNxFlat.html">NXFLAT Documentation</a>
+ for detailed information.
+ </li>
+ <li>
+ Several important bugs were files related to networking and ROMFS
+ (see the <a href="#currentrelease">ChangeLog</a> for a complete list).
+ </li>
</ul>
</p>
@@ -1418,57 +1422,7 @@ Other memory:
</table>
<pre><ul>
-nuttx-0.4.8 2009-06-13 Gregory Nutt <spudmonkey@racsa.co.cr>
-
- * lib/lib_*stream.c: Extend internal stream logic to support incoming streams.
- * arch/arm/src/str71x: Serial output is now correct and timer interrupts are
- working. The test at configs/olimex-strp711/ostest passes. This means that
- the basic STR-P711 port is complete.
- * configs/olimex-strp711/nsh: Add and verifed a NuttShell (NSH) configuration
- for the STR-P711.
- * arch/arm/str71x/str71x_serial.c: The STR711 interrupt driven serial driver
- finally works after some extradinary measures to handle missed interrupts.
- NSH is fully functional on the Olimex STR-P711 board.
- * example/nsh: Moved architecture specific files from NSH directory to board-
- specific directories.
- * config/olimex-strp711/src/up_nsh.c: Add an NSH board specific directory for
- for the Olimex STR7P11 board.
- * Fixed build of LM3X6918 using the CodeSourcery Windows native toolchain. There
- were lots of issues with Cygwin paths and Cygwin symbolic links. These changes
- may work with the devarmKIT as well, but that remains untested.
- * The NXP LPC2148 and STR711 targets can now also be built using the CodeSourcery
- or devkitARM Windows native toolchains.
-
-pascal-0.1.2 2008-02-10 Gregory Nutt <spudmonkey@racsa.co.cr>
-
- * Add logic to build and link with the ZDS-II toolchain
- use with the z16f.
- * Make sure that POFF header structures are aligned
- * Standardized POFF file format to big-endian
- * Break up large switch statements to lower complexity
- and eliminate a compiler bug
- * Changes so that runtime compiles with SDCC.
-
-buildroot-0.1.6 2009-xx-xx <spudmonkey@racsa.co.cr>
-
- * Added config/arm7tdmi-defconfig-4.2.4
- * Added config/arm920t-defconfig-4.3.3
- * Correct error in arm-defconfig gcc-3.4.6 build. The gcc-3.4.6 configuration
- does not not take --with-abi
- * Correct error in gcc-3.4.6/gcc/collect.c. Calls open with O_CREAT but
- does not specify mode. Newer host compilers can error out on this.
-</pre></ul>
-
-<table width ="100%">
- <tr bgcolor="#e4e4e4">
- <td>
- <a name="pendingchanges">Unreleased Changes</a>
- </td>
- </tr>
-</table>
-
-<pre><ul>
-nuttx-0.4.9 2009-xx-xx Gregory Nutt <spudmonkey@racsa.co.cr>
+nuttx-0.4.9 2009-06-26 Gregory Nutt <spudmonkey@racsa.co.cr>
* Add strtoll() and strtoull(); Add macros for atol() and atoll().
* dup() and dup2() will now clone socket descriptors
@@ -1494,9 +1448,17 @@ nuttx-0.4.9 2009-xx-xx Gregory Nutt <spudmonkey@racsa.co.cr>
This file has been around for a long time, but I don't think it has
every been used before (i.e., prior to the NXFLAT logic)
-pascal-0.1.3 2009-xx-xx Gregory Nutt <spudmonkey@racsa.co.cr>
+pascal-0.1.2 2008-02-10 Gregory Nutt <spudmonkey@racsa.co.cr>
+
+ * Add logic to build and link with the ZDS-II toolchain
+ use with the z16f.
+ * Make sure that POFF header structures are aligned
+ * Standardized POFF file format to big-endian
+ * Break up large switch statements to lower complexity
+ and eliminate a compiler bug
+ * Changes so that runtime compiles with SDCC.
-buildroot-0.1.7 2009-xx-xx <spudmonkey@racsa.co.cr>
+buildroot-0.1.7 2009-06-26 <spudmonkey@racsa.co.cr>
* configs/avr-defconfig-4.3.3: Added support for AVR to support a NuttX
port of the ATmega128.
@@ -1504,6 +1466,24 @@ buildroot-0.1.7 2009-xx-xx <spudmonkey@racsa.co.cr>
* toolchain/genromfs: Added support for the genromfs tool
</pre></ul>
+<table width ="100%">
+ <tr bgcolor="#e4e4e4">
+ <td>
+ <a name="pendingchanges">Unreleased Changes</a>
+ </td>
+ </tr>
+</table>
+
+<pre><ul>
+nuttx-0.4.10 2009-xx-xx Gregory Nutt <spudmonkey@racsa.co.cr>
+
+nuttx-0.4.10 2009-xx-xx Gregory Nutt <spudmonkey@racsa.co.cr>
+
+pascal-0.1.3 2009-xx-xx Gregory Nutt <spudmonkey@racsa.co.cr>
+
+buildroot-0.1.8 2009-xx-xx <spudmonkey@racsa.co.cr>
+</pre></ul>
+
<table width ="100%">
<tr bgcolor="#e4e4e4">
<td>
@@ -1539,6 +1519,10 @@ buildroot-0.1.7 2009-xx-xx <spudmonkey@racsa.co.cr>
<td valign="top" width="22"><img height="20" width="20" src="favicon.ico"></td>
<td><a href="NuttShell.html">NuttShell (NSH)</a></td>
</tr>
+<tr>
+ <td valign="top" width="22"><img height="20" width="20" src="favicon.ico"></td>
+ <td><a href="NuttXNxFlat.html">NXFLAT</a> Binary Format</td>
+</tr>
<tr>
<td valign="top" width="22"><img height="20" width="20" src="favicon.ico"></td>
<td><a href="NXGraphicsSubsystem.html">NX Graphics Subsystem</a></td>
diff --git a/Documentation/NuttXNxFlat.html b/Documentation/NuttXNxFlat.html
new file mode 100644
index 0000000000000000000000000000000000000000..289c8a35c16e5afdc96a39bc457f6b49f326cddc
--- /dev/null
+++ b/Documentation/NuttXNxFlat.html
@@ -0,0 +1,549 @@
+<html>
+<head>
+<title>NXFLAT</title>
+</head>
+<body background="backgd.gif">
+
+<hr><hr>
+<table width ="100%">
+ <tr align="center" bgcolor="#e4e4e4">
+ <td>
+ <h1><big><font color="#3c34ec"><i>NXFLAT</i></font></big></h1>
+ <h2><font color="#dc143c">>>> Under Construction <<<</font></h2>
+ <p>Last Updated: June 26, 2009</p>
+ </td>
+ </tr>
+</table>
+<hr><hr>
+<table width ="100%">
+ <tr bgcolor="#e4e4e4">
+ <td>
+ <h1>Table of Contents</h1>
+ </td>
+ </tr>
+</table>
+
+<center><table width ="80%">
+<tr>
+<td>
+<table>
+<tr>
+ <td valign="top" width="22"><img height="20" width="20" src="favicon.ico"></td>
+ <td>
+ <a href="#overview">1.0 Overview</a>
+ </td>
+</tr>
+<tr>
+ <td><br></td>
+ <td>
+ <a href="#functionality">1.1 Functionality</a>
+ </td>
+</tr>
+<tr>
+ <td><br></td>
+ <td>
+ <a href="#background">1.2 Background</a>
+ </td>
+</tr>
+<tr>
+ <td><br></td>
+ <td>
+ <a href="#limitations">1.3 Limitations</a>
+ </td>
+</tr>
+<tr>
+ <td><br></td>
+ <td>
+ <a href="#supported">1.4 Supported Processors</a>
+ </td>
+</tr>
+<tr>
+ <td><br></td>
+ <td>
+ <a href="#status">1.5 Development Status</a>
+ </td>
+</tr>
+<tr>
+ <td valign="top" width="22"><img height="20" width="20" src="favicon.ico"></td>
+ <td>
+ <a href="#toolchain">2.0 NXFLAT Toolchain</a>
+ </td>
+</tr>
+<tr>
+ <td><br></td>
+ <td>
+ <a href="#building">1.2 Building the NXFLAT Toolchain</a>
+ </td>
+</tr>
+<tr>
+ <td><br></td>
+ <td>
+ <a href="#mknxflat">1.2 mknxflat</a>
+ </td>
+</tr>
+<tr>
+ <td><br></td>
+ <td>
+ <a href="#ldnxflat">1.3 ldnxflat</a>
+ </td>
+</tr>
+<tr>
+ <td><br></td>
+ <td>
+ <a href="#making">1.4 Making an NXFLAT module</a>
+ </td>
+</tr>
+<tr>
+ <td valign="top" width="22"><img height="20" width="20" src="favicon.ico"></td>
+ <td>
+ <a href="#nogot">Appendix A. No GOT Operation</a>
+ </td>
+</tr>
+<tr>
+ <td valign="top" width="22"><img height="20" width="20" src="favicon.ico"></td>
+ <td>
+ <a href="#pictext">Appendix B. PIC Text Workaround</a>
+ </td>
+</tr>
+</table>
+</td>
+</tr>
+</table></center>
+
+<table width ="100%">
+ <tr bgcolor="#e4e4e4">
+ <td>
+ <a name="overview"><h1>1.0 Overview</h1></a>
+ </td>
+ </tr>
+</table>f
+
+<a name="functionality"><h2>1.1 Functionality</h2></a>
+
+<p>
+ NXFLAT is a customized and simplified version of binary format implemented a few years ago called
+ <a HREF="http://xflat.sourceforge.net/">XFLAT</A>
+ With the NXFLAT binary format you will be able to do the following:
+</p>
+<ul>
+ <li>Place separately linked programs in a file system, and</li>
+ <li>Execute those programs by dynamically linking them to the base NuttX code.</li>
+</ul>
+<p>
+ This allows you to extend the NuttX base code after it has been written into FLASH.
+ One motivation for implementing NXFLAT is support clean CGI under an HTTPD server.
+</p>
+<p>
+ This feature is especially attractive when combined with the NuttX ROMFS support:
+ ROMFS allows you to execute programs in place (XIP) in flash without copying anything
+ other than the .data section to RAM.
+ In fact, the initial NXFLAT release will work only on ROMFS.
+</p>
+<p>
+ This NuttX feature includes:
+</p>
+<ul>
+ <li>
+ A dynamic loader that is built into the NuttX core
+ (See <a href="http://nuttx.cvs.sourceforge.net/viewvc/nuttx/nuttx/binfmt/">CVS</a>).
+ </li>
+ <li>
+ Minor changes to RTOS to support position independent code, and
+ </li>
+ <li>
+ A linker to bind ELF binaries to produce the NXFLAT binary format
+ (See <a href="http://nuttx.cvs.sourceforge.net/viewvc/nuttx/misc/buildroot/toolchain/nxflat">CVS).
+ </li>
+</ul>
+
+<a name="background"><h2>1.2 Background</h2></a>
+
+<p>
+ NXFLAT is derived from <a href="http://xflat.sourceforge.net/">XFLAT</a>.
+ XFLAT is a toolchain add that provides full shared library and XIP executable
+ support for processors that have no Memory Management Unit (MMU).
+ NXFLAT is greatly simplified for the deeply embedded environment targeted by Nuttx:
+</p>
+<ul>
+ <li>NXFLAT does not support shared libraries, because</li>
+ <li>NXFLAT does not support <i>exportation</i> of symbol values from a module</li>
+</ul>
+<p>
+ Rather, the NXFLAT module only <i>imports</i> symbol values.
+ In the NXFLAT model, the (PIC<sup>1</sup>) NXFLAT module resides in a FLASH file system and
+ when it is loaded at run time, it is dynamically linked only to the (non-PIC) base NuttX
+ code:
+ The base NuttX <i>exports</i> a symbol table; the NXFLAT module <i>imports</i> those symbol value
+ to dynamically bind the module to the base code.
+</p>
+<p><sup>1</sup><small>"Position Independent Code"</small></p>
+
+<a name="limitations"><h2>1.3 Limitations</h2></a>
+
+<ul>
+ <li><b>ROMFS Only</b>.
+ The initial NXFLAT release will work only with executable modules residing on a ROMFS
+ file system.
+ That is because the loader depends on the capability to <code>mmap()</code> the code segment.
+ NUTTX does not provide any general kind of file mapping capability.
+ In fact, <i>true </i>file mapping is only possible with RTOSs and MCUs that provide an MMU<sup>1</sup>
+ and only ROMFS supports that kind of XIP execution from FLASH.
+ It is possible to simulate file mapping by allocating memory and copy the file into memory.
+ NXFLAT would work that kind of file mapping to and that feature could easily be added to NuttX.
+ </li>
+ <li><b>GCC/ARM/Cortex-M3 Only</b>
+ At present, the NXFLAT toolchain is only available for ARM and Cortex-M3 (thumb2) targets.
+ </li>
+ <li><b>Read-Only Data in RAM</b>
+ Read-only data must reside in RAM.
+ In code generated by GCC, all data references are indexed by the PIC<sup>2</sup> base register
+ (that is usually R10 or <i>sl</i> for the ARM processors).
+ The includes read-only data (<code>.rodata</code>).
+ Embedded firmware developers normally like to keep <code>.rodata</code> in FLASH with the code sections.
+ But because all data is referenced with the PIC base register, all of that data must lie in RAM.
+ A NXFLAT change to work around this is under investigation<sup>3</sup>.
+ </li>
+ <li><b>Globally Scoped Function Function Pointers</b>
+ If a function pointer is taken to a statically defined function, then (at least for ARM) GCC will
+ generate a relocation that NXFLAT cannot handle.
+ The workaround is make all such functions global in scope.
+ A fix would involve a change to the GCC compiler as described in <a href="#pictext">Appendix B</a>.
+ </li>
+ <li><b>No Callbacks</b>
+ Callbacks through function pointers must be avoided or, when then cannot be avoided, handled very specially.
+ The reason for this is that the PIC module requires setting of a special value in a PIC register.
+ If the callback does not set the PIC register, then the called back function will fail because
+ it will be unable to correct access data memory.
+ Special logic is in place to handle: Signal callbacks, watchdog timer callbacks.
+ But other callbacks (like those used with <code>qsort()</code> must be avoided in an NXFLAT module.
+ </li>
+</ul>
+
+<ul><p>
+ <sup>1</sup><small>"Memory Management Unit"</small><br>
+ <sup>2</sup><small>"Position Independent Code"</small><br>
+ <sup>3</sup><small>A work around is under consideration:
+ At run time, the <code>.rodata</code> offsets will be indexed by a RAM address.
+ If the dynamic loader were to offset those <code>.rodata</code> offsets properly, it
+ still might be possible to reference <code>.rodata</code> in ROM.
+ That work around is still a top of investigation at this time.</small>
+</p></ul>
+
+<a name="supported"><h2>1.4 Supported Processors</h2></a>
+
+<p>
+ As mentioned <a href="#limitations">above</a>, the NXFLAT toolchain is only available for ARM and
+ Cortex-M3 (thumb2) targets.
+ Furthermore, NXFLAT has only been tested on the Eagle-100 LMS6918 Cortex-M3 board.
+</p>
+
+<a name="status"><h2>1.5 Development Status</h2></a>
+
+<p>
+ The initial release of NXFLAT was made in NuttX version 0.4.9.
+ Testing is limited to the tests found under <code>examples/nxflat</code> in the source tree.
+ Some known problems exist
+ (see the <a href="http://nuttx.cvs.sourceforge.net/*checkout*/nuttx/nuttx/TODO">TODO</a> list).
+ As such, NXFLAT is currently in an early alpha phase.
+</p>
+
+<table width ="100%">
+ <tr bgcolor="#e4e4e4">
+ <td>
+ <a name="toolchain"><h1>2.0 NXFLAT Toolchain</h1></a>
+ </td>
+ </tr>
+</table>
+
+<a name="building"><h2>1.2 Building the NXFLAT Toolchain</h2></a>
+
+<p>
+ In order to use NXFLAT, you must use special NXFLAT tools to create the binary module in FLASH.
+ To do this, you will need to download the buildroot package and build it on your Linux or Cygwin machine.
+ The buildroot can be downloaded from
+ <a https://sourceforge.net/project/showfiles.php?group_id=189573&package_id=224585">Sourceforge</a>.
+ You will need version 0.1.7 or later.
+</p>
+<p>
+ Here are some general build instructions:
+</p>
+<ul>
+
+ <li>
+ You must have already configured Nuttx in <code><some-dir>/nuttx</code>
+ <li>
+ <li>
+ Download the buildroot package <code>buildroot-0.x.y</code> into <code><some-dir></code>
+ <li>
+ <li>
+ Unpack <code><some-dir>/buildroot-0.x.y.tar.gz</code> using a command like <code>tar zxf buildroot-0.x.y</code>.
+ This will result in a new directory like <code><some-dir>/misc/buildroot-0.x.y</code>
+ </li>
+ <li>
+ Move this into position: <code>mv <some-dir>/misc/buildroot-0.x.y <code><some-dir>/buildroot</code>
+ </li>
+ <li>
+ <code>cd <code><some-dir>/buildroot</code>
+ </li>
+ <li>
+ Copy a configuration file into the top buildroot directory: <code>cp configs/abc-defconfig-x.y.z .config</code>.
+ </li>
+ <li>
+ Enable building of the NXFLAT tools by <code>make menuconfig</code>.
+ Select to build the NXFLAT toolchain with GCC (you can also select omit building GCC with and only build the
+ NXFLAT toolchain for use with your own GCC toolchain).
+ </li>
+ <li>
+ Make the toolchain: <code>make</code>.
+ When the make completes, the tool binaries will be available under
+ <code><some-dir>/buildroot/build_abc/staging_dir/bin</code>
+ </li>
+</ul>
+
+<a name="mknxflat"><h2>1.2 mknxflat</h2></a>
+
+<p>
+ <code>mknxflat</code> is used to build a <i>thunk</i> file.
+ See <a href="#making">below</a> for usage.
+
+<ul><pre>
+Usage: mknxflat [options] <bfd-filename>
+
+Where options are one or more of the following. Note
+that a space is always required between the option and
+any following arguments.
+
+ -d Use dynamic symbol table. [symtab]
+ -f <cmd-filename>
+ Take next commands from <cmd-filename> [cmd-line]
+ -o <out-filename>
+ Output to <out-filename> [stdout]
+ -v Verbose output [no output]
+ -w Import weakly declared functions, i.e., weakly
+ declared functions are expected to be provided at
+ load-time [not imported]
+</pre></ul>
+
+<a name="ldnxflat"><h2>1.3 ldnxflat</h2></a>
+
+<p>
+ <code>ldnxflat</code> is use to link your object files along with the <i>thunk</i> file
+ generated by <a href="#mknxflat"><code>mknxflat<code></a> to produce the NXFLAT binary module.
+ See <a href="#making">below</a> for usage.
+</p>
+
+<ul><pre>
+Usage: ldnxflat [options] <bfd-filename>
+
+Where options are one or more of the following. Note
+that a space is always required between the option and
+any following arguments.
+
+ -d Use dynamic symbol table [Default: symtab]
+ -e <entry-point>
+ Entry point to module [Default: _start]
+ -o <out-filename>
+ Output to <out-filename> [Default: <bfd-filename>.nxf]
+ -s <stack-size>
+ Set stack size to <stack-size> [Default: 4096]
+ -v Verbose output. If -v is applied twice, additional
+ debug output is enabled [Default: no verbose output].
+</pre></ul>
+
+<a name="making"><h2>1.4 Making an NXFLAT module</h2></a>
+
+<p>
+ Below is a snippet from an NXFLAT make file (simplified from NuttX
+ <a href="http://nuttx.cvs.sourceforge.net/viewvc/*checkout*/nuttx/nuttx/examples/nxflat/tests/hello/Makefile?revision=1.6">
+ Hello, World!</a> example.
+<p>
+<ul><table width="50%">
+
+<ul><table>
+ <tr>
+ <th>Target 1</th>
+ <td><code>hello.r1:</code></td>
+ <td><code>hello.o</code></td>
+ </tr>
+ <tr>
+ <td><br></td>
+ <td><br></td>
+ <td><code>abc-elf-ld -r -d -warn-common -o $@ $^</code></td>
+ </tr>
+ <tr>
+ <th>Target 2</th>
+ <td><code>hello-thunk.S:</code></td>
+ <td><code>hello.r1</code></td>
+ </tr>
+ <tr>
+ <td><br></td>
+ <td><br></td>
+ <td><code>mknxflat -o $@ $^</code></td>
+ </tr>
+ <tr>
+ <th>Target 3</th>
+ <td><code>hello.r2:</code></td>
+ <td><code>hello-thunk.S</code></td>
+ </tr>
+ <tr>
+ <td><br></td>
+ <td><br></td>
+ <td>
+ <code>abc-elf-ld -r -d -warn-common -T binfmt/libnxflat/gnu-nxflat.ld -no-check-sections -o $@ hello.o hello-thunk.o</code>
+ </td>
+ </tr>
+ <tr>
+ <th>Target 4</th>
+ <td><code>hello:</code></td>
+ <td><code>hello.r2</code></td>
+ </tr>
+ <tr>
+ <td><br></td>
+ <td><br></td>
+ <td><code>ldnxflat -e main -s 2048 -o $@ $^</code></td>
+ </tr>
+ <tr>
+</table></ul>
+
+<p><b>Target 1</b>.
+ This target links all of the object files together into one relocation object.
+ In this case, there is only a single object file, <code>hello.o</code>, and it is linked to produce <code>hello.r1</code>.
+</p>
+
+<p><b>Target 2</b>.
+ Given <code>hello.r1</code>, this target will invoke <a href="#mknxflat"><code>mknxflat</code></a>
+ to make the <i>thunk</i> file, <code>hello-thunk.S</code>.
+ This <i>thunk</i> contains all of the information needed to create the imported function list.
+</p>
+
+<p><b>Target 3</b>
+ This this target is similar to <b>Target 1</b>.
+ In this case, it will link together the object file, <code>hello.o</code> along with the assembled <i>thunk</i> file,
+ <code>hello-thunk.o</code> to create another, single relocatable object, <code>hello.r2</code>.
+ The linker script, <code>gnu-nxflat.ld</code> is required at this point to correctly position the sections.
+</p>
+
+<p><b>Target 4</b>.
+ Finally, this target will use the <code>hello.r2</code> relocatable object to create the final, NXFLAT module
+ <code>hello</code> by calling <a href="#ldnxflat"><code>ldnxflat</code></a>.
+</p>
+
+<table width ="100%">
+ <tr bgcolor="#e4e4e4">
+ <td>
+ <a name="nogot"><h1>Appendix A. No GOT Operation</h1></a>
+ </td>
+ </tr>
+</table>
+
+<p>
+ When GCC generate position independent code, new code sections will appear in your programs.
+ One of these the the GOT (Global Offset Table) and, in ELF environments, the PLT (Procedure
+ Lookup Table.
+ For example, if your C code generated (ARM) assembly language like this without PIC:
+<p>
+<ul><pre>
+ ldr r1, .L0 <-- Fetch the offset to 'x'
+ ldr r0, [r10, r1] <-- Load the value of 'x' with PIC
+ offset
+ ...
+.L0: .word x <-- Offset to 'x'
+</pre></ul>
+
+<p>
+ Then when PIC is enabled (say with the -fpic compiler option), it will generate code like
+ this:
+</p>
+
+<ul><pre>
+ ldr r1, .L0 <-- Fetch the offset to the GOT entry
+ ldr r1, [r10,r1] <-- Fetch the (relocated) address
+ of 'x' from the GOT
+ ldr r0, [r1, #0] <-- Fetch the value of 'x'
+ ...
+.L1 .word x(GOT) <-- Offset to entry in the GOT
+</pre></ul>
+
+<p>See <a href="http://xflat.sourceforge.net/NoMMUSharedLibs.html#shlibsgot">reference</a></p>
+
+<p>
+ Notice that the generates an extra level of indirection through the GOT.
+ This indirection is not needed by NXFLAT and only adds more RAM usage and
+ execution time.
+</p>
+<p>
+ NXFLAT (like <a href="http://xflat.sourceforge.net/">XFLAT</a>) can work even better with
+ the GOT.
+ Patches again older version of GCC exist to eliminate the GOT indirections.
+ Several are available <a href="http://xflat.cvs.sourceforge.net/viewvc/xflat/xflat/gcc/">here</a>
+ if you are inspired to port them to a new GCC version.
+</p>
+
+
+<table width ="100%">
+ <tr bgcolor="#e4e4e4">
+ <td>
+ <a name="pictext"><h1>Appendix B. PIC Text Workaround</h1></a>
+ </td>
+ </tr>
+</table>
+
+<p>
+ There is a problem with the memory model in GCC that prevents it from
+ being used as you need to use it in the NXFLAT context.
+ The problem is that GCC PIC model assumes that the executable lies in a flat, contiguous (virtual) address space like:
+<p>
+<ul><table width="15%">
+ <tr><th>Virtual</th></td>
+ <tr>
+ <td align="center" bgcolor="#e4e4e4"><code>.text</code></td>
+ </tr>
+ <tr>
+ <td align="center" bgcolor="#e4e4e4"><code>.got</code></td>
+ </tr>
+ <tr>
+ <td align="center" bgcolor="#e4e4e4"><code>.data</code></td>
+ </tr>
+ <tr>
+ <td align="center" bgcolor="#e4e4e4"><code>.bss</code></td>
+ </tr>
+</table></ul>
+<p>
+ It assumes that the PIC base register (usually r10 for ARM) points to the base of <code>.text</code>
+ so that any address in <code>.text</code>, <code>.got</code>, <code>.data</code>, <code>.bss</code>
+ can be found with an offset from the same base address.
+ But that is not the memory arrangement that we need in the XIP embedded environment.
+ We need two memory regions, one in FLASH containing shared code and on per task in RAM containing task-specific data:
+</p>
+
+<ul><table width="30%">
+ <tr><th>Flash</th><th>RAM</th></td>
+ <tr>
+ <td align="center" bgcolor="#e4e4e4"><code>.text</code></td>
+ <td align="center" bgcolor="#e4e4e4"><code>.got</code></td>
+ </tr>
+ <tr>
+ <td bgcolor="#e4e4e4"><br></td>
+ <td align="center" bgcolor="#e4e4e4"><code>.data</code></td>
+ </tr>
+ <tr>
+ <td bgcolor="#e4e4e4"><br></td>
+ <td align="center" bgcolor="#e4e4e4"><code>.bss</code></td>
+ </tr>
+</table></ul>
+
+<p>
+ The PIC base register needs to point to the base of the <code>.got</code> and only
+ addresses in the <code>.got</code>, <code>.data</code>, and <code>.bss</code>
+ sections can be accessed as an offset from the PIC base register.
+ See also this
+ <a href="http://xflat.cvs.sourceforge.net/viewvc/*checkout*/xflat/xflat/gcc/README?revision=1.1.1.1">XFLAT discussion</a>.
+</p>
+<p>
+ Patches again older version of GCC exist to correct this GCC behavior.
+ Several are available <a href="http://xflat.cvs.sourceforge.net/viewvc/xflat/xflat/gcc/">here</a>
+ if you are inspired to port them to a new GCC version.
+</p>
+
+</body>
+</html>
diff --git a/ReleaseNotes b/ReleaseNotes
index f421c5365e2944dcedfed60c5c9ea4191c174fac..d8c04ed2ad29f861dfcba1198f399d753718477a 100644
--- a/ReleaseNotes
+++ b/ReleaseNotes
@@ -923,3 +923,17 @@ This is the 40th release of NuttX. This release adds:
This tarball contains a complete CVS snapshot from June 13, 2009.
+nuttx-0.4.9
+^^^^^^^^^^^
+
+This is the 41st release of NuttX. This release adds:
+
+ * Support for a new binary format call NXFLAT that can be used to
+ execute separately linked programs in place in a file system.
+ See http://www.nuttx.org/NuttXNxFlat.html.
+
+ * Several important bugs were files related to networking and ROMFS
+ (see the ChangeLog for a complete list).
+
+This tarball contains a complete CVS snapshot from June 26, 2009.
+
diff --git a/TODO b/TODO
index da9356e26aeec97336b8c2f57d7d9251d2247206..3370e58c0cbae5120d852555ff4556741aeacf2e 100644
--- a/TODO
+++ b/TODO
@@ -1,4 +1,4 @@
-NuttX TODO List (Last updated June 19, 2009)
+NuttX TODO List (Last updated June 26, 2009)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(5) Task/Scheduler (sched/)
@@ -6,15 +6,16 @@ NuttX TODO List (Last updated June 19, 2009)
(1) Signals (sched/, arch/)
(1) pthreads (sched/)
(1) C++ Support
+ (5) Binary loaders (binfmt/)
(12) Network (net/, netutils/)
(1) USB (drivers/usbdev)
(4) Libraries (lib/)
(8) File system/Generic drivers (fs/, drivers/)
(2) Graphics subystem (graphics/)
(1) Pascal add-on (pcode/)
- (0) Documentation (Documentation/)
+ (2) Documentation (Documentation/)
(6) Build system / Toolchains
- (2) NuttShell (NSH) (examples/nsh)
+ (3) NuttShell (NSH) (examples/nsh)
(3) Other Applications & Tests (examples/)
(2) Linux/Cywgin simulation (arch/sim)
(3) ARM (arch/arm/)
@@ -102,6 +103,39 @@ o C++ Support
constructor logic will probably have to be performed by
user logic in user_start().
+o Binary loaders (binfmt/)
+ ^^^^^^^^^^^^^^^^^^^^^^^^
+
+ Description: Not all of the NXFLAT test under examples/nxflat are working.
+ Most simply do not compile yet. tests/mutex runs okay but
+ outputs garbage on completion.
+ Status: Open
+ Priority: High
+
+ Description: The ARM up_getpicbase() does not seem to work. This means
+ the some features like wdog's might not work in NXFLAT modules.
+ Status: Open
+ Priority: Medium-High
+
+ Description: At present, all .rodata must be put into RAM. There is a
+ tentative design change that might allow .rodata to be placed
+ in FLASH (see Documentation/NuttXNxFlat.html).
+ Status: Open
+ Priority: Medium
+
+ Description: If the function pointer to a statically defined function is
+ taken, then GCC generates a relocation that cannot be handled
+ by NXFLAT. There is a solution described in Documentataion/NuttXNxFlat.html,
+ by that would require a compiler change (which we want to avoid).
+ The simple workaround is to make such functions global in scope.
+ Status: Open
+ Priority: Low (probably will not fix)
+
+ Description: In the NXFLAT symbol tables... Using a 32-bit hash value instead
+ of a string to identify a symbol should result in a smaller footprint.
+ Status: Open
+ Priority: Low
+
o Network (net/, netutils/)
^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -325,6 +359,10 @@ o Documentation (Documentation/)
Status: Open
Priority: Low
+ Description: Need to document binary loader APIs
+ Status: Open
+ Priority: Low
+
o Build system
^^^^^^^^^^^^
@@ -378,6 +416,10 @@ o NuttShell (NSH) (examples/nsh)
Status: Open
Priority: Med-High
+ Description: Add support to NSH to run NXFLAT programs from a ROMFS file system
+ Status: Open
+ Priority: Low
+
o Other Applications & Tests (examples/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/examples/README.txt b/examples/README.txt
index b31c3749089ea419b8c3022f5dd25fe4a7ff1563..e228de2070ac8abc72fe7826302476c181538953 100644
--- a/examples/README.txt
+++ b/examples/README.txt
@@ -143,7 +143,7 @@ examples/nxflat
This example builds a small NXFLAT test case. This includes several
test programs under examples/nxflat tests. These tests are build using
the NXFLAT format and installed in a ROMFS file system. At run time,
- each program int eh ROMFS file system is executed.
+ each program in the ROMFS file system is executed. Requires CONFIG_NXFLAT.
examples/null
^^^^^^^^^^^^^