From 95b4a0ba81fa63c99fce8878aea55bf96103c162 Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Sun, 1 Dec 2013 20:17:09 -0600 Subject: NXFFS: When dumping the MTD content, don't abort on a read error. For NAND, the read error probably just means that an uncorrectable ECC was encountered --- nuttx/ChangeLog | 3 +++ nuttx/configs/sama5d3x-ek/README.txt | 12 ++++++++++-- nuttx/fs/nxffs/nxffs_dump.c | 38 +++++++++++++++++++++++------------- nuttx/fs/nxffs/nxffs_initialize.c | 2 +- 4 files changed, 38 insertions(+), 17 deletions(-) diff --git a/nuttx/ChangeLog b/nuttx/ChangeLog index 9f15e1314..1d89f4496 100644 --- a/nuttx/ChangeLog +++ b/nuttx/ChangeLog @@ -6146,4 +6146,7 @@ * drivers/mtd/mtd_nand* and arch/arm/src/sama5/sam_nand.c: NAND accesses now work (at least with software ECC and now DMA). Still lots of testing to be done (2013-11-30). + * fs/nxffs/nxffs_dump.c: Do not abort on a read error. Just not + the error and continue. Otherwise, we would not be able to dump + NAND FLASH (2013-11-30). diff --git a/nuttx/configs/sama5d3x-ek/README.txt b/nuttx/configs/sama5d3x-ek/README.txt index 115d4934b..12de1a462 100644 --- a/nuttx/configs/sama5d3x-ek/README.txt +++ b/nuttx/configs/sama5d3x-ek/README.txt @@ -2529,6 +2529,10 @@ Configurations Since you will not be able to re-enable the watchdog later, you may need to set CONFIG_SAMA5_WDT=y in the NuttX configuration file. + 4. If you put norboot on the Serial FLASH, you can automatically + boot to NOR on reset. See the section "Creating and Using NORBOOT" + above. + STATUS: See the To-Do list below @@ -2852,7 +2856,8 @@ To-Do List initializing .bss and .data. 4) Neither USB OHCI nor EHCI support Isochronous endpoints. Interrupt - endpoint support in the EHCI driver is untested. + endpoint support in the EHCI driver is untested (but works in similar + EHCI drivers). 5) HSCMI TX DMA support is currently commented out. @@ -2874,8 +2879,11 @@ To-Do List layers and other features of the LCDC. 10) I have a Camera, but there is still no ISI driver. I am not sure what to - do with the camera. NuttX needs something liek V4L to provide the + do with the camera. NuttX needs something like V4L to provide the definition for what a camera driver is supposed to do. + I will probably develop a test harness for ISI, but it is of only + minimal value with no OS infrastructure to deal with images and video. + 11) GMAC has only been tested on a 10/100Base-T network. I don't have a 1000Base-T network to support additional testing. diff --git a/nuttx/fs/nxffs/nxffs_dump.c b/nuttx/fs/nxffs/nxffs_dump.c index 032c5f875..a86fd0c2d 100644 --- a/nuttx/fs/nxffs/nxffs_dump.c +++ b/nuttx/fs/nxffs/nxffs_dump.c @@ -1,7 +1,7 @@ /**************************************************************************** * fs/nxffs/nxffs_dump.c * - * Copyright (C) 2011 Gregory Nutt. All rights reserved. + * Copyright (C) 2011, 2013 Gregory Nutt. All rights reserved. * Author: Gregory Nutt * * References: Linux/Documentation/filesystems/romfs.txt @@ -138,7 +138,7 @@ static inline ssize_t nxffs_analyzeinode(FAR struct nxffs_blkinfo_s *blkinfo, return ERROR; } - + /* Can we verify the inode? We need to have the inode name in the same * block to do that (or get access to the next block) @@ -169,7 +169,7 @@ static inline ssize_t nxffs_analyzeinode(FAR struct nxffs_blkinfo_s *blkinfo, nextblock = blkinfo->offset + blkinfo->geo.blocksize; if (noffs > nextblock) { - /* Not than we cannot verify the inode header */ + /* Note than we cannot verify the inode header */ if (blkinfo->verbose) { @@ -281,6 +281,7 @@ static inline ssize_t nxffs_analyzedata(FAR struct nxffs_blkinfo_s *blkinfo, { fdbg(g_format, blkinfo->block, offset, "DATA ", "OK ", datlen); } + return SIZEOF_NXFFS_DATA_HDR + datlen; } #endif @@ -322,6 +323,7 @@ static inline void nxffs_analyze(FAR struct nxffs_blkinfo_s *blkinfo) fdbg(g_format, blkinfo->block, 0, "BLOCK", "ERASED ", blkinfo->geo.blocksize); } + return; } #if 0 /* Too much output, to little information */ @@ -365,6 +367,7 @@ static inline void nxffs_analyze(FAR struct nxffs_blkinfo_s *blkinfo) { i = hdrndx + nbytes - 1; } + inndx = 0; } } @@ -381,6 +384,7 @@ static inline void nxffs_analyze(FAR struct nxffs_blkinfo_s *blkinfo) { i = hdrndx + nbytes - 1; } + datndx = 0; } } @@ -427,7 +431,7 @@ int nxffs_dump(FAR struct mtd_dev_s *mtd, bool verbose) if (ret < 0) { fdbg("ERROR: MTD ioctl(MTDIOC_GEOMETRY) failed: %d\n", -ret); - goto errout; + return ret; } /* Save the verbose output indication */ @@ -440,8 +444,7 @@ int nxffs_dump(FAR struct mtd_dev_s *mtd, bool verbose) if (!blkinfo.buffer) { fdbg("ERROR: Failed to allocate block cache\n"); - ret = -ENOMEM; - goto errout; + return -ENOMEM; } /* Now read every block on the device */ @@ -459,20 +462,27 @@ int nxffs_dump(FAR struct mtd_dev_s *mtd, bool verbose) ret = MTD_BREAD(mtd, blkinfo.block, 1, blkinfo.buffer); if (ret < 0) { - fdbg("ERROR: Failed to read block %d\n", blkinfo.block); - goto errout_with_block; + /* A read error is probably fatal on all media but NAND. + * On NAND, the read error probably just signifies a block + * with an uncorrectable ECC failure. So, to handle NAND, + * just report the read error and continue. + */ + + fdbg(g_format, blkinfo.block, 0, "BLOCK", "RD FAIL", + blkinfo.geo.blocksize); } + else + { + /* Analyze the block that we just read */ - /* Analyze the block */ - - nxffs_analyze(&blkinfo); + nxffs_analyze(&blkinfo); + } } + fdbg("%d blocks analyzed\n", blkinfo.nblocks); -errout_with_block: kfree(blkinfo.buffer); -errout: - return ret; + return OK; #else return -ENOSYS; diff --git a/nuttx/fs/nxffs/nxffs_initialize.c b/nuttx/fs/nxffs/nxffs_initialize.c index 390b03bcd..5c40b7e96 100644 --- a/nuttx/fs/nxffs/nxffs_initialize.c +++ b/nuttx/fs/nxffs/nxffs_initialize.c @@ -415,7 +415,7 @@ int nxffs_limits(FAR struct nxffs_volume_s *volume) return OK; } - // No? Then it is some other failure that we do not know how to handle + /* No? Then it is some other failure that we do not know how to handle */ fdbg("ERROR: nxffs_getc failed: %d\n", -ch); return ch; -- cgit v1.2.3