[ECOS] NAND support

[ECOS] NAND support

[Simon Kallweit]

Hi there

I was wondering what the current state of the NAND subsystem from Rutger 
Hofman is. I'm currently working on a port of the UFFS filesystem 
(http://gouffs.googlepages.com/) which is intended to work on NAND 
flash. Are there any major arguments against merging his code into the 
eCos trunk? Anything that needs to be addressed? I would be willing to 
contribute a synth NAND driver as well as support for the STM32 target.

Simon


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: NAND support

[John Dallaway]

Hi Simon

Simon Kallweit wrote:

> I was wondering what the current state of the NAND subsystem from Rutger
> Hofman is. I'm currently working on a port of the UFFS filesystem
> (http://gouffs.googlepages.com/) which is intended to work on NAND
> flash. Are there any major arguments against merging his code into the
> eCos trunk? Anything that needs to be addressed? I would be willing to
> contribute a synth NAND driver as well as support for the STM32 target.

UFFS looks like a good fit for eCos. However, it is licensed under the
LGPL. I wonder if the authors would be willing to license the filesystem
under the eCos public license (dual license) and make a copyright
assignment to the FSF. Is this something you have discussed with them?
Our current policies do not allow us to accept LPGL run-time code into
the eCos repository.

I assume that your port would sit under the standard eCos Flash I/O
layer (CYGPKG_IO_FLASH). As with all imported packages, it would also be
important to:

* Minimise changes to the imported source code so it is as easy as
possible to keep the eCos port up to date.

* Provide all the configurability offered within the imported code as
eCos CDL options.

John Dallaway

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NAND support

[Simon Kallweit]

John Dallaway wrote:
> 
> UFFS looks like a good fit for eCos. However, it is licensed under the
> LGPL. I wonder if the authors would be willing to license the filesystem
> under the eCos public license (dual license) and make a copyright
> assignment to the FSF. Is this something you have discussed with them?
> Our current policies do not allow us to accept LPGL run-time code into
> the eCos repository.

Well, I have not yet discussed this with the author. Might be a good 
idea to do this ASAP. Well, even if the code cannot be merged into eCos 
trunk it would be nice to have a package for it.

> I assume that your port would sit under the standard eCos Flash I/O
> layer (CYGPKG_IO_FLASH). As with all imported packages, it would also be
> important to:

UFFS is not yet great for NOR flash, as every file/directory uses at 
least a complete block. That's why I was asking for the NAND package. 
The port could support both NOR and NAND flash, but until UFFS is 
upgraded to handle NOR better, it's quite useless in production.

> * Minimise changes to the imported source code so it is as easy as
> possible to keep the eCos port up to date.

Agreed.

> * Provide all the configurability offered within the imported code as
> eCos CDL options.

Agreed.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] NAND support

[Rutger Hofman]

Simon Kallweit wrote:
> Hi there
> 
> I was wondering what the current state of the NAND subsystem from Rutger 
> Hofman is. I'm currently working on a port of the UFFS filesystem 
> (http://gouffs.googlepages.com/) which is intended to work on NAND 
> flash. Are there any major arguments against merging his code into the 
> eCos trunk? Anything that needs to be addressed? I would be willing to 
> contribute a synth NAND driver as well as support for the STM32 target.

There have been 2 test platforms:
1) I have a BlackFin EZ-Kit BF548
      - this type of BlackFin has an on-board NFC (NAND Flash 
Controller), with support for ECC
      - it has one NAND flash chip of the regular class
2) Televic's custom board
      - Atmel AT91SAM9260 with an on-board NFC. Although it has hardware 
ECC support of the "syndrome", Televic used software ECC
      - it has one NAND flash chip of the regular class
      - Televic didn't publish their NFC driver

Both platforms use YAFFS with the interface layer that I wrote.

Televic didn't report any errors (except one place w/ a wrongly assigned 
value -- which wasn't used).

Both Televic and I exercised the YAFFS file-system tests that I copied 
to YAFFS from other file system implementations.

The status therefore is:

+ runs for BlackFin NFC
+ runs for AT91SAM9260 NFC
+ runs for one regular NAND chip
+ runs for YAFFS
+ no open issues

- no tests for multiple or heterogeneous chips
- no tests for multiple or heterogeneous chips
- no tests for "syndrome" ECC
- no tests for small-page chips -- they have a different command set
- no tests for ONFI chips -- I still have to see one!

In conclusion, the status is that I would love to see more and varied 
tests before the package could be declared stable. Also, feedback on the 
design is still very welcome. Televic reported that implementing an NFC 
driver for their AT91SAM9260 was rather troublesome, although I don't 
know what kind of problems they had to solve. I tried to improve my 
documentation when I heard that :-).

I intend to merge this package into mainline eCos. I don't know what a 
good time is: now, or when it has been stressed a bit more.

Rutger

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] NAND support

[Rutger Hofman]

Simon Kallweit wrote:
> Hi there
> 
> I was wondering what the current state of the NAND subsystem from Rutger 
> Hofman is. I'm currently working on a port of the UFFS filesystem 
> (http://gouffs.googlepages.com/) which is intended to work on NAND 
> flash.

What made you select UFFS? It licence, or its properties? Care to share 
your reasons to not use YAFFS?

I would be interested to see a UBI/UBIFS port too. My guess is that the 
NAND flash interface required by UBI is very small, and it might turn 
out that porting it to use eCos NAND is trivial. This would mean a 
UBI/UBIFS in user space though, and I don't know how much work that 
would mean, and whether it would be supported by the MTD people.

Rutger

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] NAND support

[Rutger Hofman]

Simon Kallweit wrote:
> I was wondering what the current state of the NAND subsystem from Rutger 
> Hofman is. ...  I would be willing to
> contribute a synth NAND driver as well as support for the STM32 target.

What kind of NFC (NAND Flash Controller) would you use for the STM32 
target? Their FSMC (Flexible Static Memory Controller) is embedded on 
some STM32s. It has a NAND flash controller with hardware ECC support; 
the NFC itself appears to just offer access to the NAND control/data 
lines, so a driver might be based on my example GPIO NFC implementation. 
Or would you choose some other option than FSMC, like some separate NFC 
chip, or doing NFC with GPIOs?

I am most willing to support you during development, as best as I can of 
course. Caveat: I never did anything with synth. How would one go about 
a synth NAND driver?

Rutger

P.S. I am glad to hear that there more interest in NAND flash.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NAND support

[John Dallaway]

Hi Simon

Simon Kallweit wrote:

> John Dallaway wrote:
>>
>> UFFS looks like a good fit for eCos. However, it is licensed under the
>> LGPL. I wonder if the authors would be willing to license the filesystem
>> under the eCos public license (dual license) and make a copyright
>> assignment to the FSF. Is this something you have discussed with them?
>> Our current policies do not allow us to accept LPGL run-time code into
>> the eCos repository.
> 
> Well, I have not yet discussed this with the author. Might be a good
> idea to do this ASAP.

Yes, it would be a good idea to discuss this with the author ASAP. You
might wish to refer to Jonathan Larmour's discussion of the LGPL in
relation to the eCos public license:

  http://sources.redhat.com/ml/ecos-discuss/2002-05/msg00206.html

Note also that every individual who has made a significant contribution
to the UFFS code would be required to sign a copyright assignment for
acceptance of the code into the eCos repository. Not just the original
author.

> Well, even if the code cannot be merged into eCos
> trunk it would be nice to have a package for it.

Yes, much better than nothing!

John Dallaway

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] NAND support

[Simon Kallweit]

Rutger Hofman wrote:
> What made you select UFFS? It licence, or its properties? Care to share 
> your reasons to not use YAFFS?

A bit of both I guess. As I'm developing a platform which will be used 
for proprietary products, so I have to make sure we have the freedom to 
keep the application closed. We could always get a license for YAFFS, 
but I'd rather use something without the need for licensing. Second, it 
seems YAFFS is quite a bit more heavyweight than UFFS. As we're rather 
tight on ROM/RAM, I'm looking for a really lightweight FS, and UFFS 
seems to fit the bill rather nicely.

> I would be interested to see a UBI/UBIFS port too. My guess is that the 
> NAND flash interface required by UBI is very small, and it might turn 
> out that porting it to use eCos NAND is trivial. This would mean a 
> UBI/UBIFS in user space though, and I don't know how much work that 
> would mean, and whether it would be supported by the MTD people.

I was thinking about this too, but again, I think UFFS is a lot more 
lightweight than UBI/UBIFS.

The nice thing about eCos is it's configurability. More options cannot 
really hurt IMHO as long as share code and subsystems (NAND) wherever 
possible.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: NAND support

[John Dallaway]

Hi Simon

Simon Kallweit wrote:

>> I assume that your port would sit under the standard eCos Flash I/O
>> layer (CYGPKG_IO_FLASH). As with all imported packages, it would also be
>> important to:
> 
> UFFS is not yet great for NOR flash, as every file/directory uses at
> least a complete block. That's why I was asking for the NAND package.
> The port could support both NOR and NAND flash, but until UFFS is
> upgraded to handle NOR better, it's quite useless in production.

Yes, I see now. UFFS would be implemented as an eCos file system exposed
via CYGPKG_IO_FILEIO, talking to a separate NAND flash layer via
CYGPKG_IO_FLASH.

John Dallaway

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] NAND support

[Simon Kallweit]

Rutger Hofman wrote:
> What kind of NFC (NAND Flash Controller) would you use for the STM32 
> target? Their FSMC (Flexible Static Memory Controller) is embedded on 
> some STM32s. It has a NAND flash controller with hardware ECC support; 
> the NFC itself appears to just offer access to the NAND control/data 
> lines, so a driver might be based on my example GPIO NFC implementation. 
> Or would you choose some other option than FSMC, like some separate NFC 
> chip, or doing NFC with GPIOs?

As we have an STM32 with FSMC I would go for a solution using the FSMC, yes.

> I am most willing to support you during development, as best as I can of 
> course. Caveat: I never did anything with synth. How would one go about 
> a synth NAND driver?

I do everything with synth :) It's really great for development and 
testing. I still have to get into the whole NAND architecture but 
ultimately the synth NAND driver would just simulate a NFC/NAND combo 
and read/write to a file on the host.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] NAND support

[Rutger Hofman]

Simon Kallweit wrote:
> Rutger Hofman wrote:
>> What made you select UFFS? It licence, or its properties? Care to 
>> share your reasons to not use YAFFS?
> 
> A bit of both I guess. As I'm developing a platform which will be used 
> for proprietary products, so I have to make sure we have the freedom to 
> keep the application closed. We could always get a license for YAFFS, 
> but I'd rather use something without the need for licensing. Second, it 
> seems YAFFS is quite a bit more heavyweight than UFFS. As we're rather 
> tight on ROM/RAM, I'm looking for a really lightweight FS, and UFFS 
> seems to fit the bill rather nicely.

When I do a YAFFS/direct library build with -Os on my x86:
-rw-r--r-- 1 rutger rutger 81768 2009-05-05 13:42 libyaffs.a
After stripping:
-rw-r--r-- 1 rutger rutger 56016 2009-05-05 13:40 libyaffs.a

Comparable output from 'size libyaffs.a'.
I've seen worse...

> The nice thing about eCos is it's configurability. More options cannot 
> really hurt IMHO as long as share code and subsystems (NAND) wherever 
> possible.

I agree completely!

Rutger

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: NAND support

[Simon Kallweit]

John Dallaway wrote:
> Note also that every individual who has made a significant contribution
> to the UFFS code would be required to sign a copyright assignment for
> acceptance of the code into the eCos repository. Not just the original
> author.

He is the only author so far, and applied for the FSF assignment right 
away. I'm not the guru when it comes to licenses, but I think he would 
like to have UFFS on a dual license, an eCos license and a separate LGPL 
version for the current users to continue with. Is there a problem with 
this?

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss