Add LPC43xx pin configuration header files
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@4885 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo
parent
53b3f26f19
commit
8f27eec24d
@ -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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user