diff --git a/Documentation/NXGraphicsSubsystem.html b/Documentation/NXGraphicsSubsystem.html
index 7aa8ab03cd..743e0368aa 100644
--- a/Documentation/NXGraphicsSubsystem.html
+++ b/Documentation/NXGraphicsSubsystem.html
@@ -326,7 +326,7 @@
 <p>
   NX is organized into 6 (and perhaps someday 7 or 8) logical modules.
   These logical modules also correspond to the directory organization.
-  That NuttX directory organization is discussed in 
+  That NuttX directory organization is discussed in
   <a href="#grapicsdirs">Appendix B</a> of this document.
   The logic modules are discussed in the following sub-paragraphs.
 </p>
@@ -622,7 +622,7 @@ void nxgl_rectunion(FAR struct nxgl_rect_s *dest,
 </pre></ul>
 <p>
   <b>Description:</b>
-  Given two rectanges, <code>src1</code> and <code>src2</code>, return the larger rectangle that 
+  Given two rectanges, <code>src1</code> and <code>src2</code>, return the larger rectangle that
   contains both, <code>dest</code>.
 </p>
 
@@ -766,7 +766,7 @@ int nxgl_splitline(FAR struct nxgl_vector_s *vector, FAR struct nxgl_trapezoid_s
   <b>Description:</b>
   In the general case, a line with width can be represented as a parallelogram with a triangle at the top and bottom.
   Triangles and parallelograms are both degenerate versions of a trapezoid.
-  This function breaks a wide line into triangles and trapezoids. 
+  This function breaks a wide line into triangles and trapezoids.
   This function also detects other degenerate cases:
 </p>
 <ol>
@@ -801,7 +801,7 @@ int nxgl_splitline(FAR struct nxgl_vector_s *vector, FAR struct nxgl_trapezoid_s
 </p>
 <ul>
   <p>
-    <code>0</code>: Line successfully broken up into three trapezoids. 
+    <code>0</code>: Line successfully broken up into three trapezoids.
     Values in <code>traps[0]</code>, <code>traps[1]</code>, and <code>traps[2]</code> are valid.
   </p>
   <p>
@@ -1551,7 +1551,7 @@ int nx_setposition(NXWINDOW hwnd, FAR struct nxgl_point_s *pos);
   <ul><dl>
     <dt><code>hwnd</code>
     <dd>The handle returned by <a href="#nxopenwindow"><code>nx_openwindow()</code></a>.
-      This handle must not have been created by 
+      This handle must not have been created by
       <a href="#nxrequestbkgd"><code>nx_requestbkgd()</code></a>.
     <dt><code>pos</code>
     <dd>The new position of the window
@@ -1579,7 +1579,7 @@ int nx_setsize(NXWINDOW hwnd, FAR struct nxgl_size_s *size);
   <ul><dl>
     <dt><code>hwnd</code>
     <dd>The handle returned by <a href="#nxopenwindow"><code>nx_openwindow()</code></a>.
-      This handle must not have been created by 
+      This handle must not have been created by
       <a href="#nxrequestbkgd"><code>nx_requestbkgd()</code></a>.
     <dt><code>size</code>
     <dd>The new size of the window (in pixels).
@@ -1607,7 +1607,7 @@ int nx_raise(NXWINDOW hwnd);
   <ul><dl>
     <dt><code>hwnd</code>
     <dd>The handle returned by <a href="#nxopenwindow"><code>nx_openwindow()</code></a>.
-      This handle must not have been created by 
+      This handle must not have been created by
       <a href="#nxrequestbkgd"><code>nx_requestbkgd()</code></a>.
     <dt><code></code>
     <dd>
@@ -1635,7 +1635,7 @@ int nx_lower(NXWINDOW hwnd);
   <ul><dl>
     <dt><code>hwnd</code>
     <dd>The handle returned by <a href="#nxopenwindow"><code>nx_openwindow()</code></a>.
-      This handle must not have been created by 
+      This handle must not have been created by
       <a href="#nxrequestbkgd"><code>nx_requestbkgd()</code></a>.
     <dt><code></code>
     <dd>
@@ -3132,7 +3132,7 @@ int nxf_convert_32bpp(FAR uint32_t *dest, uint16_t height,
 
 <p><b>Building <code>apps/examples/nx</code></b>.
   Testing was performed using the Linux/Cygwin-based NuttX simulator.
-  Instructions are provided for building that simulation are provided in 
+  Instructions are provided for building that simulation are provided in
   <a href="#testcoverage">Appendix C</a> of this document.
 </p>
 
@@ -3299,7 +3299,7 @@ int nxf_convert_32bpp(FAR uint32_t *dest, uint16_t height,
       <dd>Specify the colors of the border used with framed windows.
     <dt><code>CONFIG_NXTK_BORDERCOLOR2</code>
       <dd>The shadow side color and so is normally darker.
-    <dt><code>CONFIG_NXTK_BORDERCOLOR3</code> 
+    <dt><code>CONFIG_NXTK_BORDERCOLOR3</code>
       <dd>The shiny side color and so is normally brighter.
       The default is medium, dark, and light grey, respectively
     <dt><code>CONFIG_NXTK_AUTORAISE</code>:
@@ -3426,7 +3426,7 @@ int nxf_convert_32bpp(FAR uint32_t *dest, uint16_t height,
     <dt><code>CONFIG_NXCONSOLE_NXKBDIN</code>:
       <dd>Take input from the NX keyboard input callback.
       By default, keyboard input is taken from stdin (<code>/dev/console</code>).
-      If this option is set, then the interface<code>nxcon_kdbin()</code> is enabled. 
+      If this option is set, then the interface<code>nxcon_kdbin()</code> is enabled.
       That interface may be driven by window callback functions so that keyboard input <i>only</i> goes to the top window.
     <dt><code>CONFIG__NXCONSOLE_KBDBUFSIZE</code>:
       <dd>If <code>CONFIG_NXCONSOLE_NXKBDIN</code> is enabled, then this value may be used to
@@ -3467,7 +3467,7 @@ int nxf_convert_32bpp(FAR uint32_t *dest, uint16_t height,
     <p>
       Locate a font in BDF format.
       There are many good BDF bitmap fonts bundled with X-11.
-      See <a href="http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html">this link</a>, as an example, 
+      See <a href="http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html">this link</a>, as an example,
     </p>
   </li>
   <li>
@@ -3703,7 +3703,7 @@ sudo ln -s libXext.so.6.4.0 libXext.so
           This is because the sim target is based upon some assembly language setjmp/longjmp logic that only works on 32-bit systems.
         </p>
         <p><small>
-          <b>NOTE</b>: There is a workaround in this case: 
+          <b>NOTE</b>: There is a workaround in this case:
           You can build for 32-bit execution on a 64-bit machine by adding <code>-m3</code> to the <code>CFLAGS</code> and <code>-m32 -m elf_i386</code> to the <code>LDFLAGS</code>.
           See the patch file <code>0001-Quick-hacks-to-build-sim-nsh-ostest-on-x86_64-as-32-.patch</code>
           that can be found in NuttX <a href="http://tech.groups.yahoo.com/group/nuttx/files">files</a>.
diff --git a/Documentation/NXOrganization.gif b/Documentation/NXOrganization.gif
index 6bae8e5529..1039d30bd8 100644
Binary files a/Documentation/NXOrganization.gif and b/Documentation/NXOrganization.gif differ
diff --git a/Documentation/NuttX2-a.png b/Documentation/NuttX2-a.png
index 20c2fd6e71..f0b1abfd2a 100644
Binary files a/Documentation/NuttX2-a.png and b/Documentation/NuttX2-a.png differ
diff --git a/Documentation/NuttXBinfmt.html b/Documentation/NuttXBinfmt.html
index 0dd5665871..3f3bdbc0aa 100644
--- a/Documentation/NuttXBinfmt.html
+++ b/Documentation/NuttXBinfmt.html
@@ -107,7 +107,7 @@
 
 <h2>2.1 <a name="binfmthdr">Binary Loader Header Files</a></h2>
 <p>
-  The interface to the binary loader is described in the header file 
+  The interface to the binary loader is described in the header file
   <a href="http://sourceforge.net/p/nuttx/git/ci/master/tree/nuttx/include/nuttx/binfmt/binfmt.h">
   <code>include/nuttx/binfmt/binfmt.h</code></a>.
   A brief summary of the data structurs and interfaces prototyped in that header file are listed below.
@@ -457,7 +457,7 @@ void exepath_release(EXEPATH_HANDLE handle);
 
 <h2>3.1 <a name="symtabhdr">Symbol Table Header Files</a></h2>
 <p>
-  The interface to the symbol table logic is described in the header file 
+  The interface to the symbol table logic is described in the header file
   <a href="http://sourceforge.net/p/nuttx/git/ci/master/tree/nuttx/include/nuttx/binfmt/symtab.h">
   <code>include/nuttx/binfmt/symtab.h</code></a>.
   A brief summary of the data structurs and interfaces prototyped in that header file are listed below.
@@ -477,7 +477,7 @@ struct symtab_s
 </pre></ul>
 
 </p>
-  A symbol table is a fixed size array of <code>struct symtab_s</code>. 
+  A symbol table is a fixed size array of <code>struct symtab_s</code>.
   The information is intentionally minimal and supports only:
 </p>
 <ol>
diff --git a/Documentation/NuttXCCodingStandard.html b/Documentation/NuttXCCodingStandard.html
index 0693efc50f..4cb4a9517d 100755
--- a/Documentation/NuttXCCodingStandard.html
+++ b/Documentation/NuttXCCodingStandard.html
@@ -136,7 +136,7 @@
 </p>
 <ul>
   <li>
-    A line that consists of the opening C comment (<code>/*</code>) followed by a series of asterisks extending to the length of the line (usually to column 78). 
+    A line that consists of the opening C comment (<code>/*</code>) followed by a series of asterisks extending to the length of the line (usually to column 78).
   </li>
   <li>
     The name of the grouping, starting at column 4.
@@ -310,7 +310,7 @@
     /*  The forward link to the next instance of struct
      * some_long_struct_name_s in a singly linked list
      */
-  
+
     struct some_long_struct_name_s *flink;
     int short_name1;   /* Short comment 1 */
     int short_name2;   /* This is a very long comment describing subtle
@@ -2157,7 +2157,7 @@ x++;
     {
       ptr++;
     }
- 
+
 </ul></pre></font>
 </td></tr>
 </table></center>
diff --git a/Documentation/NuttXDemandPaging.html b/Documentation/NuttXDemandPaging.html
index e1ef29b245..2e1ebaf3e1 100644
--- a/Documentation/NuttXDemandPaging.html
+++ b/Documentation/NuttXDemandPaging.html
@@ -243,7 +243,7 @@
      </li>
      <li>
        <b>Boost the page fill worker thread priority</b>.
-       Check the priority of the task at the head of the <code>g_waitingforfill</code> list. 
+       Check the priority of the task at the head of the <code>g_waitingforfill</code> list.
        If the priority of that task is higher than the current priority of the page fill worker thread, then boost the priority of the page fill worker thread to that priority.
        Thus, the page fill worker thread will always run at the priority of the highest priority task that is waiting for a fill.
      </li>
@@ -370,7 +370,7 @@
   The architecture-specific functions, <code>up_checkmapping()</code>, <code>up_allocpage(tcb, &vpage)</code> and <code>up_fillpage(page, pg_callback)</code>
   will be prototyped in <code>include/nuttx/arch.h</code>
 </p>
- 
+
 <a name="FillComplete"><h2>Fill Complete</h2></a>
 
 <p>
@@ -379,7 +379,7 @@
 <p>
   For the non-blocking <code>up_fillpage()</code>, the architecture-specific driver call the <code>pg_callback()</code> that was provided to <code>up_fillpage()</code> when the fill completes.
   In this case, the <code>pg_callback()</code> will probably be called from driver interrupt-level logic.
-  The driver will provide the result of the fill as an argument to the callback function. 
+  The driver will provide the result of the fill as an argument to the callback function.
   NOTE: <code>pg_callback()</code> must also be <a href="#MemoryOrg">locked</a> in memory.
 </p>
 <p>
@@ -404,7 +404,7 @@
     </li>
   </ul>
 </p>
- 
+
 <a name="TaskResumption"><h2>Task Resumption</h2></a>
 
 <p>
@@ -600,7 +600,7 @@
     <li>
       In the first phase, create a partially linked objected containing all interrupt/exception handling logic, the page fill worker thread plus all parts of the IDLE thread (which must always be available for execution).
     </li>
-    <li>    
+    <li>
        All of the <code>.text</code> and <code>.rodata</code> sections of this partial link should be collected into a single section.
     </li>
     <li>
@@ -625,7 +625,7 @@
     The currently executing task at the head of the ready to run list must be stopped.
     Save its context and move it to the inactive list specified by task_state.
     This function is called by the on-demand paging logic in order to block the task that requires the
-    page fill, and to 
+    page fill, and to
   </dd>
   <dt>
     <code>void up_unblock_task(FAR struct tcb_s *tcb);</code>
@@ -671,4 +671,4 @@
 </dl></ul>
 </body>
 </html>
-        
+
diff --git a/Documentation/NuttXNxFlat.html b/Documentation/NuttXNxFlat.html
index 55280ad44e..2036cc723e 100644
--- a/Documentation/NuttXNxFlat.html
+++ b/Documentation/NuttXNxFlat.html
@@ -229,7 +229,7 @@
   <li><b>Read-Only Data in RAM</b>
     <ul>
       <p>
-        With older GCC compilers (at least up to 4.3.3), read-only data must reside in RAM.  
+        With older GCC compilers (at least up to 4.3.3), 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.
@@ -304,7 +304,7 @@
 <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 
+  The buildroot can be downloaded from
   <a https://sourceforge.net/projects/nuttx/files/">Sourceforge</a>.
   You will need version 0.1.7 or later.
 </p>
@@ -486,7 +486,7 @@ cat ../syscall/syscall.csv ../libc/lib.csv | sort >tmp.csv
 <p><b>Target 1</b>.
   This target links all of the module's object files together into one relocatable object.
   Two relocatable objects will be generated; this is the first one (hence, the suffic <code>.r1</code>).
-  In this &quot;Hello, World!&quot; case, there is only a single object file, <code>hello.o</code>, 
+  In this &quot;Hello, World!&quot; case, there is only a single object file, <code>hello.o</code>,
   that is linked to produce the <code>hello.r1</code> object.
 </p>
 
@@ -553,7 +553,7 @@ cat ../syscall/syscall.csv ../libc/lib.csv | sort >tmp.csv
 <p><b>Relevant Header Files:</b></p>
 <ul>
   <li>
-    The interface to the binary loader is described in the header file 
+    The interface to the binary loader is described in the header file
     <a href="http://sourceforge.net/p/nuttx/git/ci/master/tree/nuttx/include/nuttx/binfmt/binfmt.h">
     <code>include/nuttx/binfmt/binfmt.h</code></a>.
     A brief summary of the APIs prototyped in that header file are listed below.
@@ -787,7 +787,7 @@ cat ../syscall/syscall.csv ../libc/lib.csv | sort >tmp.csv
   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 
+  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>
diff --git a/Documentation/NuttxPortingGuide.html b/Documentation/NuttxPortingGuide.html
index 5155294c5b..dad21f6cdf 100644
--- a/Documentation/NuttxPortingGuide.html
+++ b/Documentation/NuttxPortingGuide.html
@@ -1620,7 +1620,7 @@ The system can be re-made subsequently by just typing <code>make</code>.
     <p>
       There is also a <code>arch/<architecture>/include/<chip>/chip.h</code> header file that can be used to communicate other microprocessor-specific information between the board logic and even application logic.
       Application logic may, for example, need to know specific capabilities of the chip.
-      Prototypes in that <code>chip.h</code> header file should follow the microprocessor-specific naming convention. 
+      Prototypes in that <code>chip.h</code> header file should follow the microprocessor-specific naming convention.
     </p>
   </li>
   <li>
diff --git a/Documentation/UsbTrace.html b/Documentation/UsbTrace.html
index 767b587369..7efb7ebccb 100644
--- a/Documentation/UsbTrace.html
+++ b/Documentation/UsbTrace.html
@@ -107,7 +107,7 @@
 </p>
 <ul>
   <li>
-    For the USB serial and mass storage class, the 8-bit event data is provided in <code>include/nuttx/usb/usbdev_trace.h</code>. 
+    For the USB serial and mass storage class, the 8-bit event data is provided in <code>include/nuttx/usb/usbdev_trace.h</code>.
   </li>
   <li>
     For the USB device driver, that 8-bit event data is provided within the USB device driver itself.
diff --git a/Documentation/pm.png b/Documentation/pm.png
index d84d8642dc..febece0f56 100644
Binary files a/Documentation/pm.png and b/Documentation/pm.png differ