Re: Anyone using mtd on NAND flash?

["Stéphane Laroche" <stephane.laroche@colubris.com>]

On the subject of NAND flash, could some JFFS expert point me on where I should
look for those multiple writes to the same page?

I am currently working on a NAND driver for MTD that takes care of bad blocks
and virtual mapping.  It does ECC, keeps a bad block table and does the virtual
mapping of blocks so that MTD sees a linear block device with 100% good
blocks.  I'm using AMD which actually claims they'll have no bad blocks for the
specified amount of writes (100,000).  For Samsung or Toshiba parts (and AMD,
just to be safe), the driver reserves a certain number of blocks (35) to be
able to remap bad blocks dynamically.

So I think that JFFS should work with such a driver, if we make sure than no
more than 1 write occurs on the same 512-byte page.  [ AMD recommends writing
only once to a page, while Samsung/Toshiba talk of 10 writes ].

Is this a big task (JFFS design affected)?

Thanks,

-Stephane

David Woodhouse wrote:

> bjorn@brannstrom.se said:
> >  I've just been across the hall to strangle our hardware engineer (who
> > happens to also be my boss). He /intended/ to use the AM29LV640 part
> > but had problems finding a reliable source for them so we're using
> > Samsungs KM29U128 part instead.
>
> Don't strangle him. Have him hung, drawn and quartered.
>
> The KM29U128 is an _entirely_ different beast. NAND flash is quite
> different to NOR flash.
>
> With NOR flash, you can keep clearing bits individually until they're all
> zero. With NAND flash you can only do 10 write cycles in each 512-byte page
> before it becomes unreliable and you have to erase it again. JFFS currently
> exceeds that number.
>
> Also, NAND flash is permitted to ship with bad blocks and you're expected to
> work round them. JFFS doesn't, and JFFS-on-NAND should probably use an error
> correcting checksum rather than the simple checksum it currently uses.
>
> He's just replaced something you could use with the current code with
> something we're not going to support for some time, unless you care to do
> the necessary work yourself.
>
> You can't use NFTL, as we do on the DiskOnChip, because it's patented, and
> even if you were only going to distribute within the Free World, the NFTL
> code requires the built-in ECC support provided by the DiskOnChip ASIC.
>
> --
> dwmw2
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org