Re: NAND Flash supported Board suggestion

[Alan C. Assis]

Hi Saurav,

AFAIK, the only MCUs with NAND Flash controllers supported on NuttX are
samv3 and sama5.

Mr. Greg Nutt implemented it for Atmel about 10 years ago, but if I
remember correctly, he never got it well tested because there is no FS for
NAND on NuttX.

I think if you decide to use an SPI NAND Flash with ECC and bad block
support in HW it will be easier to test your FS, in this case even LittleFS
could work:
https://github.com/littlefs-project/littlefs/issues/11

But later on we will need to get ECC and bad block table support on NuttX
to validate your FS with some native NAND Flash controller.

Best Regards,

Alan

On Fri, May 24, 2024 at 12:09 PM Saurav Pal  wrote:

> Hi all,
>
> I'm working on creating a file system for NAND Flash for NuttX as part of
> GSoC '24. I would be thankful of any suggestions that you might have for
> the type of board that I should use and the NAND flash as well.
>
> Thank you in advance.
> Regards,
> Saurav Pal
>

Re: NAND Flash supported Board suggestion

[Gregory Nutt]

> Mr. Greg Nutt implemented it for Atmel about 10 years ago, but if I
> remember correctly, he never got it well tested because there is no 
FS for

> NAND on NuttX.

I did test the FS's that were available and they mostly worked on these 
platforms.  I could actually run nxffs and smartfs for a long while 
before they failed. They failed because the FSs that I looked at assumed 
that you can always write a "1" to a "0". Actually, you can do that but 
this then results in ECC error. Even a single bit 1=>0 change requires a 
full  erase, re-writing the ECC, and a full sector write.


As I recall, nxffs would write some single "0" bits to indicate sector 
state changes; SmartFS had a small counter that was used to manage wear 
leveling.


> I think if you decide to use an SPI NAND Flash with ECC and bad block
> support in HW it will be easier to test your FS, in this case even 
LittleFS

> could work:
> https://github.com/littlefs-project/littlefs/issues/11

Sparing and wear-leveling would also be needed.

> But later on we will need to get ECC and bad block table support on NuttX
> to validate your FS with some native NAND Flash controller.

I think that software bad block and ECC are already supported and 
verified (but it has been awhile since I used them).  Sparing, and 
wear-leveling are normally done by an FTL, but can be done by the file 
system.  Bad block detection and ECC may be done by hardware, FTL, or 
higher level software.  Then the only outstanding issues are finding 
such an FTL and a file system that does not do read-modify-write 
operations without updating the ECC.


LittleFS was a candidate a few years ago and required a special FTL to 
get all of these features.  Maybe that has changed in more recent versions.

Re: NAND Flash supported Board suggestion

[Alan C. Assis]

Thank you Greg for clarifying!

I think Xiang Xiao and guohao15 also worked with NAND recently (DHARA and
YAFFS).

Seems like dhara.c was integrated into mainline, but they didn't submit
support to YAFFS (if I remember correctly it was because YAFFS requires
license payment for commercial usage).

Best Regards,

Alan

On Sat, May 25, 2024 at 4:38 PM Gregory Nutt  wrote:

>  > Mr. Greg Nutt implemented it for Atmel about 10 years ago, but if I
>  > remember correctly, he never got it well tested because there is no
> FS for
>  > NAND on NuttX.
>
> I did test the FS's that were available and they mostly worked on these
> platforms.  I could actually run nxffs and smartfs for a long while
> before they failed. They failed because the FSs that I looked at assumed
> that you can always write a "1" to a "0". Actually, you can do that but
> this then results in ECC error. Even a single bit 1=>0 change requires a
> full  erase, re-writing the ECC, and a full sector write.
>
> As I recall, nxffs would write some single "0" bits to indicate sector
> state changes; SmartFS had a small counter that was used to manage wear
> leveling.
>
>  > I think if you decide to use an SPI NAND Flash with ECC and bad block
>  > support in HW it will be easier to test your FS, in this case even
> LittleFS
>  > could work:
>  > https://github.com/littlefs-project/littlefs/issues/11
>
> Sparing and wear-leveling would also be needed.
>
>  > But later on we will need to get ECC and bad block table support on
> NuttX
>  > to validate your FS with some native NAND Flash controller.
>
> I think that software bad block and ECC are already supported and
> verified (but it has been awhile since I used them).  Sparing, and
> wear-leveling are normally done by an FTL, but can be done by the file
> system.  Bad block detection and ECC may be done by hardware, FTL, or
> higher level software.  Then the only outstanding issues are finding
> such an FTL and a file system that does not do read-modify-write
> operations without updating the ECC.
>
> LittleFS was a candidate a few years ago and required a special FTL to
> get all of these features.  Maybe that has changed in more recent versions.

Re: NAND Flash supported Board suggestion

[Gregory Nutt]

Seems like dhara.c was integrated into mainline, but they didn't submit
support to YAFFS (if I remember correctly it was because YAFFS requires
license payment for commercial usage).


There no references to either under fs/.

The YAFFS website is not responding.  This is what I get about licensing 
from Wikipedia:


"The YAFFS codebase is licensed both under the GPL 
 and under 
per-product licenses available from Aleph One." 
https://en.wikipedia.org/wiki/YAFFS


Neither of those are compatible with NuttX in the source tree.

Re: NAND Flash supported Board suggestion

[Nathan Hartman]

On Sat, May 25, 2024 at 8:58 PM Gregory Nutt  wrote:

> > Seems like dhara.c was integrated into mainline, but they didn't submit
> > support to YAFFS (if I remember correctly it was because YAFFS requires
> > license payment for commercial usage).
>
> There no references to either under fs/.
>
> The YAFFS website is not responding.  This is what I get about licensing
> from Wikipedia:
>
> "The YAFFS codebase is licensed both under the GPL
>  and under
> per-product licenses available from Aleph One."
> https://en.wikipedia.org/wiki/YAFFS
>
> Neither of those are compatible with NuttX in the source tree.
>


The apps repo has some configurations to build with 3rd party projects,
where we don't include the 3rd party sources in our repo.

Instead, we only develop a build script and Kconfig. It's a sort of "stub"
(for lack of a better term).

If that item is configured, our build script will download the sources from
the 3rd party (I think the URL is configured in Kconfig, so developers can
locally host all their dependencies) and then compile it with the rest of
their build.

See, for example, in the nuttx-apps repo: math/libtommath.

In the case of YAFFS, if someone wants to implement such a stub, it should
depend on ALLOW_GPL_COMPONENTS, so that the developer who chooses to use it
will first have to explicitly accept that license.

Cheers,
Nathan