Hi,
Please dont break the mtd interface, make it compatible with the
previous one.
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
