From d764942e9d74da8bb37daeb5daa5fa1b80c5e846 Mon Sep 17 00:00:00 2001
From: Gregory Nutt <gnutt@nuttx.org>
Date: Sat, 20 May 2017 16:36:55 -0600
Subject: [PATCH] Update README and a Document

---
 Documentation/NuttxPortingGuide.html |  2 +-
 configs/stm32f0discovery/README.txt  | 17 +++++++++++++++++
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/Documentation/NuttxPortingGuide.html b/Documentation/NuttxPortingGuide.html
index 58bc32c041..ce18662b6d 100644
--- a/Documentation/NuttxPortingGuide.html
+++ b/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>
diff --git a/configs/stm32f0discovery/README.txt b/configs/stm32f0discovery/README.txt
index e69de29bb2..243dee3376 100644
--- a/configs/stm32f0discovery/README.txt
+++ b/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.