SAMA5 NAND: Only CS3 can have NAND

1 files changed, 51 insertions, 10 deletions

diff --git a/nuttx/configs/sama5d3x-ek/README.txt b/nuttx/configs/sama5d3x-ek/README.txt
index d0eb2ace4..99f83ebe9 100644
--- a/nuttx/configs/sama5d3x-ek/README.txt
+++ b/nuttx/configs/sama5d3x-ek/README.txt
@@ -1352,6 +1352,9 @@ SDRAM Support
 NAND Support
 ============
 
+  NAND Support
+  ------------
+
   NAND Support can be added to the NSH configuration by modifying the
   NuttX configuration file as follows:
 
@@ -1393,19 +1396,25 @@ NAND Support
       Other file systems are not recommended because only NXFFS can handle
       bad blocks and only NXFFS performs wear-leveling.
 
-      NOTE:  NXFFS is very slow.  The first time that you start the system,
-      be prepared for a long wait; NXFFS will need to format the NAND
+      NOTE:  NXFFS can be very slow.  The first time that you start the
+      system, be prepared for a wait; NXFFS will need to format the NAND
       volume.  I have lots of debug on so I don't yet know what the
-      optimized wait would be.  But with debug ON, software ECC, and no
-      DMA the wait is in many tens of minutes, even hours if many debug
-      options are enabled.
+      optimized wait will be.  But with debug ON, software ECC, and no
+      DMA the wait is in many tens of minutes (and substantially  longer
+      if many debug options are enabled.
+
+      [I don't yet have data for the more optimal cases. It will be
+       significantly less, but still not fast.]
 
       On subsequent boots, after the NXFFS file system has been created the
-      delay will be less.  But the NAND-related boot time can still be
-      substantial.  This is because NXFFS needs to scan the NAND device
-      and build the in-memory dataset needed to access NAND.  It is
-      recommended you create a separated thread at boot time to bring up
-      NXFFS so that you don't delay the boot-to-prompt time excessively.
+      delay will be less.  When the new file system is empty, it will be
+      very fast.  But the NAND-related boot time can become substantial when
+      there has been a lot of usage of the NAND.  This is because NXFFS
+      needs to scan the NAND device and build the in-memory dataset needed
+      to access NAND and there is more that must be scanned after the device
+      has been used.  You may want tocreate a separate thread at boot time
+      to bring up NXFFS so that you don't delay the boot-to-prompt time
+      excessively in these longer delay cases.
 
       NOTE:  There is another NXFFS related issue:  When the FLASH is
       fully used, NXFFS will restructure the entire FLASH, the delay to
@@ -1433,6 +1442,38 @@ NAND Support
     Application Configuration -> NSH Library
      CONFIG_NSH_ARCHINIT=y              : Use architecture-specific initialization
 
+    Using NAND
+    ----------
+
+    With the options CONFIG_SAMA5_NAND_AUTOMOUNT=y and
+    CONFIG_SAMA5_NAND_NXFFS=y, the NAND FLASH will be mounted in the NSH
+    start-up logic before the NSH prompt appears.  There is no feedback as
+    to whether or not the mount was successful.  You can, however, see the
+    mounted file systems using the nsh 'mount' command:
+
+      nsh> mount
+      /mnt/nand type nxffs
+
+    Then NAND can be used like any other file system:
+
+      nsh> echo "This is a test" >/mnt/nand/atest.txt
+      nsh> ls -l /mnt/nand
+      /mnt/nand:
+       ---x--x--x      16 atest.txt
+      nsh> cat /mnt/nand/atest.txt
+      This is a test
+
+    The NAND volume can be un-mounted with this comment:
+
+      nsh> umount /mnt/nand
+      nsh> mount
+
+    And re-mounted with this command:
+
+      nsh> mount -t nxffs /mnt/mystuff
+      nsh> mount
+        /mnt/mystuff type nxffs
+
 AT24 Serial EEPROM
 ==================