On Wed, Mar 1, 2023 at 10:44 PM Sebastien Lorquet <sebast...@lorquet.fr> wrote:
> Also, sorry for the multiple messages, but why is that not new IOCTL > calls (used to "Support other, less frequently used commands") so the > structure is not modified ? > > Because the design mimic Linux mtd interface: https://github.com/torvalds/linux/blob/master/include/linux/mtd/mtd.h#L352-L353 > That would be a much more compatible way of doing things. Devices that > dont implement this would just automatically return -ENOSYS or -ENXIO > (cant remember). > > Yes, it could be. It's better to comment in the PR. before merging. But, anyway you can provide a patch. > Sebastien > > Le 01/03/2023 à 15:41, Sebastien Lorquet a écrit : > > > > the callbacks are not activated by conditional compilation and are in > > the middle of struct mtd_dev_s , so how are these optional? > > > Yes, it's betteer to move to the end of struct. > > Sebastien > > > > Le 01/03/2023 à 15:36, Xiang Xiao a écrit : > >> > >> > >> On Wed, Mar 1, 2023 at 10:26 PM Sebastien Lorquet > >> <sebast...@lorquet.fr> wrote: > >> > >> Hi, > >> > >> Please dont break the mtd interface, make it compatible with the > >> previous one. > >> > >> > >> The new callbacks are optional: > >> https://github.com/apache/nuttx/pull/8683. > >> > >> > >> Sebastien > >> > >> Le 01/03/2023 à 14:53, Xiang Xiao a écrit : > >> > On Wed, Mar 1, 2023 at 8:43 PM Alan C. Assis > >> <acas...@gmail.com> wrote: > >> > > >> >> 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. > >> >> > >> >> > >> > Yes, but you can pay some money to switch to a more friendly > >> 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. > >> >> > >> >> > >> > The enhancement in mtd_s is decoupled from yaffs, actually the new > >> > interface follows Linux MTD model. > >> > BTW, We plan to improve LittleFS to utilize the new interface. > >> > > >> > > >> >> 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 > >> >>>> > >>
