Hi Xiang Xiao, This is a great news, but I'm afraid yaffs is not a good option for everybody because it uses GPL license.
But yes, it could be an option for people and companies that can release all their software as open-source. PX4 project for example could use it. BR, Alan On 2/28/23, Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > 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 >> >
