AW: NAND Flash filesystem

[Johannes Schock]

Do you need real FileIO? Or is something like writenandflash(location,size)
and readnandflash(location,size) sufficient?
If this is sufficient, try getting Atmel Softpack 1.4 for at91sam9263-ek.
You get a full featured Managed and Translated Nandflash System with
wearleveling and error-correction. In Softpack 1.5 they removed the
wearleveling code (I think because it isn't used in any demo application in
the package).
I use these drivers in my closed source Keil-RTX based at91sam9263-system.
As I remember there were one or two little bugs but I have to look up.
If you can't find the package any more contact me, I'll load it to my
company's webspace.

Regards
Johannes Schock

Stiefel GmbH
Allmend 7/2
75038 Oberderdingen
Webseite: www.stiefelgmbh.de

-----Ursprüngliche Nachricht-----
Von: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] Im
Auftrag von Mick Davis
Gesendet: Freitag, 10. September 2010 06:10
An: RTEMS Users
Betreff: NAND Flash filesystem

I'm looking at implementing a NAND flash filesystem for the 
at91sam9263-ek, and hoped there might be some advice available.

The raw flash chip is connected to the processor's on-chip static memory 
controller.

I'm not keen to use GPL sources, but I can share my own results.

JFFS2 has a license exception which might make it OK, but porting it 
away from Linux seems like an excessive amount of work. Has anyone 
succeeded with this?   I'd want it to integrate with RTEMS for use with 
ordinary system calls.

The most likely option looks like something of my own creation using the 
RTEMS block and disk device drivers, along the lines of the existing 
RTEMS flashdisk driver.

 From what I understand, the flashdisk driver is for NOR flash, and NAND 
is quite different.  NAND requires that you only program entire pages 
sequentially in the block.  You can't change the state of an individual 
word, even progressively from FFs down to 00s, as the flashdisk driver 
does for the page state indications, or for appending new page 
descriptors at the start of a block.

For NAND, only whole blocks are erasable, which are much larger than the 
programmable pages.  The device on the eval board is smaller than the 
product I'm developing for, but as an indication it is a 256Mb chip of 
128kb blocks, 2kb pages.

I guess a NAND driver might put a descriptor at the start of each page. 
  Each page would map to a filesystem block (as in filesystem minimum 
unit) and use a sequence number to determine the latest version of that 
block.

I think its worth considering a new simple implementation because I 
don't mind if the chip is under-utilized. Writes are infrequent, so wear 
leveling can be crude.  The working copy of most file data is kept by my 
app in memory anyway, so high speed is not a big requirement either.

Thanks for any input.

-- 

Mick Davis
Goanna Technologies Pty Ltd

_______________________________________________
rtems-users mailing list
rtems-users at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-users