On Wed, 2014-01-22 at 13:38 +0100, Jonas Gorski wrote: > 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
Thanks for the detailed explanation. So squashfs on nand is definitely a bad thing. For the same reasons surely loading the firmware straight from raw nand flash is a bad thing too. But the only alternative is to have a layer (ubi or a nand-aware filesystem) between the nand and the firmware image as well, which then means that the bootloader has be able to handle that layer. Have I understood correctly? Ben _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
