diff --git a/TODO b/TODO
index b202e9690a..219ba83441 100644
--- a/TODO
+++ b/TODO
@@ -1,4 +1,4 @@
-NuttX TODO List (Last updated September 13, 2014)
+NuttX TODO List (Last updated September 16, 2014)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This file summarizes known NuttX bugs, limitations, inconsistencies with
@@ -12,7 +12,7 @@ nuttx/
   (2)  Memory Managment (mm/)
   (3)  Signals (sched/, arch/)
   (2)  pthreads (sched/)
-  (9)  Kernel/Protected Builds
+  (8)  Kernel/Protected Builds
   (4)  C++ Support
   (6)  Binary loaders (binfmt/)
  (13)  Network (net/, drivers/net)
@@ -471,34 +471,6 @@ o Kernel/Protected Build
                improvement.  However, there is no strong motivation now do
                do that partitioning work.
 
-  Title:       ARMVv7-A STACK ISSUE
-  Description: Currently a program running as a process in the kernel build mode
-               cannot run other programs that reside on the file system.  Why?
-               Because in order to run those other programs, the new program's
-               address environment must be instantiated in memory to load the
-               .text and .data and to allocate the initial user space components
-               from the new user heap.
-
-               However, the previous program's stack currently resides in its
-               heap.  So when a process tries to run another program, its heap
-               is unmapped and the system crashes.
-
-               The fix is to add a separate stack in a separate memory region
-               that does not get unmapped when creating new processes.  There
-               are hooks in place to do this; I just need to get time to get
-               that done.
-
-               UPDATE: I don't think it is that simple.  Startup logic will need
-               to access the new stack in its correct location to do things like
-               setup task arguments.  So I don't think that there is anyway to
-               do that without losing the current stack.
-
-               I may have to do the Linux solution:  Two stacks for each thread:
-               The main user stack, and a tiny kernel mode stack.
-  Status:      Open
-  Priority:    Pretty high... the kernel build is useless without this
-               capability.
-
 o C++ Support
   ^^^^^^^^^^^
 
diff --git a/configs/sama5d4-ek/README.txt b/configs/sama5d4-ek/README.txt
index 1c612e1b3b..084c09e0b2 100644
--- a/configs/sama5d4-ek/README.txt
+++ b/configs/sama5d4-ek/README.txt
@@ -3930,23 +3930,10 @@ Configurations
        file system.  A considerable amount of testing has been done and
        there are no known defects as of this writing.
 
-    2014-9-13: Currently a program running as a process in the kernel build
-       mode cannot run other programs that reside on the file system.  Why?
-       Because in order to run those other programs, the new program's
-       address environment must be instantiated in memory to load the .text
-       and .data and to allocate the initial user space components from the
-       new user heap.
-
-       However, the previous program's stack currently resides in its heap.
-       So when a process tries to run another program, its heap is unmapped
-       and the system crashes.  The fix is to add a separate stack in a
-       separate memory region that does not get unmapped when creating new
-       processes.  There are hooks in place to do this; I just need to get
-       time to get that done.
-
-       To see the bug in action:
-
-         nsh> /bin/hello
+    2014-9-16: After some substantial effort, I think I may have resolved
+       the last of the mainstream bugs that prevented from executing other
+       user processes from a user processes.  Long story but I am glad to
+       haave that done.
 
   nsh: