On Wed, Jan 22, 2014 at 1:02 PM, Ben Mulvihill <ben.mulvih...@gmail.com> wrote: > On Wed, 2014-01-22 at 00:42 +0100, John Crispin wrote: >> On 21/01/2014 21:55, David Lang wrote: >> > On Tue, 21 Jan 2014, Ben Mulvihill wrote: >> > >> >> The nand driver currently in trunk works fine, provided ... >> > >> > what is the current status of nand flash support? I asked about this >> > within the last couple of weeks and was told that supporing devices >> > with nand flash would require major surgery to the squashfs code to >> > allow it to deal with badblocks. >> > >> > has this been done? was I misinformed on what the problem is? or is >> > this still a problem and devices with nand flash can work, but only if >> > they avoid squashfs? >> > >> >> >> Hi David, >> >> Daniel is working on splitting the mount_root, block, extroot and all >> the other mtd/block related tools to a new repo called fstools. While >> doing so we are doing some cleanup of the code. i expect this to hit >> trunk within the next week. Once this is done we will add nand specific >> features to the repo. Once that is done, openwrt should have proper >> support for ubi including functional sysupgrade support (using >> ubi-format) ... >> >> John >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > How critical is the bad blocks problem in practice? The above will > solve the lack of bad block handling in squashfs, but unless I've > missed the point, on a typical board won't the kernel itself still > be loaded directly from flash? Or do you assume that the bootloader > will be able to handle ubi as well?
SLC NAND usually is rather stable, but bad blocks exist, and bit flips do happen from time to time, so you need to relocate blocks then. MLC NAND is much worse, there bitflips are rather common, and you need to actually use a threshold of how many correctable bitflips you accept before you move the block somewhere else. To make matters worse, MLC NANDs support a lot less erase cycles than SLC NANDs (1000+ vs. 100k+), so using ubi-format more than once for initial format is a bad idea there (as it will cause all blocks to get erased once). A NAND capable Filesystem needs to be capable of three things: a) Be aware that blocks might be bad and skip them (and not just fail if it encounters them) b) Be aware that blocks might get bit flips just from reading, and be prepared to move the contents to a "fresh" block c) Not rely on the order of the blocks on the flash And squashfs fails for all three. There's of course the possibility of using a flash translation layer like UBI, that will take over all three things and hide all the NAND quirks from filesystems using it. Jonas _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
