Update README and a Document

Documentation/NuttxPortingGuide.html

@@ -180,7 +180,6 @@
     </ul>
     <a href="#iobs">4.12 I/O Buffer Management</a>
     <ul>
-      <a href="#iobconfig">4.12.1 Configuration Options</a><br>
       <a href="#iobconfig">4.12.1 Configuration Options</a><br>
       <a href="#iobthrottle">4.12.2 Throttling</a><br>
       <a href="#iobtypes">4.12.3 Public Types</a><br>
@@ -4185,6 +4184,7 @@ void board_autoled_off(int led);
 NuttX supports generic I/O buffer management (IOB) logic.
 This logic was originally added to support network I/O buffering, but has been generalized to meet buffering requirements by all device drivers.
 At the time of this writing, IOBs are currently used not only be networking but also by logic in <code>drivers/syslog</code> and <code>drivers/wireless</code>.
+NOTE that some of the wording in this section still reflects those legacy roots as a part of the networking subsystem.
 This objectives of this feature are:
 
 <ol>

configs/stm32f0discovery/README.txt

@@ -0,0 +1,17 @@
+STATUS
+======
+
+05/17: The basic NSH configuration is functional and shows that there is
+       3-4KB of free heap space.  However, attempts to extend this have
+       failed.  I suspect that 8KB of SRAM is insufficient to do much
+       with the existing NSH configuration.  Perhaps some fine tuning
+       can improve this situation but at this point, I think this board
+       is only useful for the initial STM32 F0 bring-up, perhaps for
+       embedded solutions that do not use NSH and for general
+       experimentation.
+
+       There is also support for the Nucleo boards with the STM32 F072
+       and F092 MCUs.  Those ports do not suffer from these problems and
+       seem to work well in fairly complex configurations.  Apparently 8KB
+       is SRAM is not usable but the parts with larger 16KB and 32KB SRAMs
+       are better matches.