We are working on yaffs porting, mtd_s need a little bit of extension to support NAND flash. Here is the patch: https://github.com/apache/nuttx/pull/8670 LittleFS needs some modification to get the benefit.
On Sun, Feb 26, 2023 at 10:14 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > On Sat, Feb 25, 2023 at 8:53 AM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > > Maybe LittleFS or SmartFS could be extended to handle NAND. > > > > I believe that LittleFS has been used with NAND with a NAND FLASH > > translation layer. I am not sure of the state of that work, but I know > > that people have tried it. Google "LittleFS on NAND flash" and see the > > hits. > > > > If a NAND flash translation layer (NFTL) were ported to NuttX, then you > > should be able to use almost any file system, although some would be > > extremely inefficient with NAND. The NAND flash layer would need to do > > sparing, wear-leveling, ECC calculations, etc. as needed by NAND. > > > > I have used NXFFS with NAND and it /almost /works. > > > > The basic filesystem issue is that all available filesystems need to do > > read-modify-write operations on flash sections. And they assume that > > you can always write a '1' bit to a '0' bit. SmartFS and NXFFS both > > assume this behavior explicitly. It is a good assumption with NOR > > flash. The problem is that NAND can only be written a whole sector at a > > time. This is because the error correction coding (ECC): If you change > > even one bit in the NAND sector, you have to re-write the whole sector > > with new ECC (because you can't change the '0' bits in the ECC back into > > '1''s without erasing the sector). > > > > Since SmartFS and NXFFS both do bit twiddling in the sectors they would > > be very inefficient with an NFTL: Each bit twiddle would cause a whole > > sector re-write. The same is probably true for LittleFS. Other file > > systems like FAT could also be used if there were an NFTL, however, FAT > > would also be inefficient (each directory update or FAT update and each > > file data size change would cause another sector write). > > > > So the only real solution to support NAND efficiently is use a file > > system that is designed specifically around the peculiarities of NAND. > > That would require some research (Alan has suggested a couple of places > > to start). > > > > I seem to recall reading that in NAND flash, one of the challenges is that > modifying a bit causes a disturbance that can corrupt other bits, even in > unrelated sectors, and that even reading can have this effect. The > disturbance only affects bits a little at a time, but after some number of > accesses, the affected sectors need to be written to new sectors, keeping > track of bad sectors formed in the process, to avoid data loss. This may > lead to a cascade effect in which reading a sector may cause numerous > sectors to be re-written. This phenomenon is called write amplification. > The takeaway from a usage perspective is that you want to over-provision > the amount of NAND flash you install, to leave plenty of room for all this > swapping, and plenty of extra sectors to increase the amount of accesses > before failure. The greater the over-provisioning, the longer until > failure. > > I haven't tried yet, but I would like at some point to support a micro-SD > and/or micro-MMC card as the backing store and use one that has built in > hardware wear leveling, with some appropriate file system of course. This > may add $50 or more to the bill of materials depending on the card > capacity, but makes it possible for users to replace the card if it fails, > in contrast to soldered-on flash chips, which can be replaced too, but only > with the appropriate tools and skills. > > Cheers > Nathan >
