diff --git a/Documentation/NuttXNxFlat.html b/Documentation/NuttXNxFlat.html
index 622953b2167..3a593978712 100644
--- a/Documentation/NuttXNxFlat.html
+++ b/Documentation/NuttXNxFlat.html
@@ -10,7 +10,7 @@
     <td>
       <h1><big><font color="#3c34ec"><i>NXFLAT</i></font></big></h1>
       <h2><font color="#dc143c">&gt;&gt;&gt; Under Construction &lt;&lt;&lt;</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>