diff options
Diffstat (limited to 'nuttx/Documentation/NuttXNxFlat.html')
-rw-r--r-- | nuttx/Documentation/NuttXNxFlat.html | 87 |
1 files changed, 54 insertions, 33 deletions
diff --git a/nuttx/Documentation/NuttXNxFlat.html b/nuttx/Documentation/NuttXNxFlat.html index 622953b21..3a5939787 100644 --- a/nuttx/Documentation/NuttXNxFlat.html +++ b/nuttx/Documentation/NuttXNxFlat.html @@ -10,7 +10,7 @@ <td> <h1><big><font color="#3c34ec"><i>NXFLAT</i></font></big></h1> <h2><font color="#dc143c">>>> Under Construction <<<</font></h2> - <p>Last Updated: May 8, 2011</p> + <p>Last Updated: June 29, 2012</p> </td> </tr> </table> @@ -193,43 +193,64 @@ <a name="limitations"><h2>1.3 Limitations</h2></a> <ul> - <li><b>ROMFS (or RAM maps) Only</b>. - The initial NXFLAT release will work only with wither (1) executable modules residing on a ROMFS - file system, or (2) executables provided on other file systems provided that <code>CONFIG_FS_RAMMAP</code> - is defined. - That is because the loader depends on the capability to <code>mmap()</code> the code segment. - See the <a href="NuttxUserGuide.html#mmapxip">NuttX User Guide</a> for further information. - 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><b>ROMFS (or RAM mapping) Only</b> + <ul> + <p> + The current NXFLAT release will work only with either (1) NXFLAT executable modules residing on a ROMFS file system, or (2) executables residing on other file systems provided that <code>CONFIG_FS_RAMMAP</code> is defined. + This limitation is because the loader depends on the capability to <code>mmap()</code> the code segment. + See the <a href="NuttxUserGuide.html#mmapxip">NuttX User Guide</a> for further information. + </p> + <p> + NUTTX does not provide any general kind of file mapping capability. + In fact, <i>true</i> file mapping is only possible with MCUs that provide an MMU<sup>1</sup>. + Without an MMU, file system may support eXecution In Place (XIP) to mimic file mapping. + Only the ROMFS file system supports that kind of XIP execution need by NXFLAT. + </p> + <p> + It is also possible to <i>simulate</i> file mapping by allocating memory, copying the NXFLAT binary file into memory, and executing from the copy of the executable file in RAM. + That capability can be enabled with the <code>CONFIG_FS_RAMMAP</code> configuration option. + With that option enabled, NXFLAT will work that kind of file system but will require copying of all NXFLAT executables to RAM. + </p> + </ul> </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><b>GCC/ARM/Cortex-M3/4 Only</b> + <ul> + <p> + At present, the NXFLAT toolchain is only available for ARM and Cortex-M3/4 (thumb2) targets. + </p> + </ul> </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>. + <ul> + <p> + 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>. + </p> + </ul> </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>. + <ul> + <p> + 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>. + </p> + </ul> </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><b>Special Handling of Callbacks</b> + <ul> + <p> + 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 correctly access data memory. + Special logic is in place to handle some NuttX callbacks: Signal callbacks and watchdog timer callbacks. + But other callbacks (like those used with <code>qsort()</code> must be avoided in an NXFLAT module. + </p> + </ul> </li> </ul> @@ -240,7 +261,7 @@ 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> + That work around is still a topic of investigation at this time.</small> </p></ul> <a name="supported"><h2>1.4 Supported Processors</h2></a> |