Re: NAND flash and JFFS(2)

[Thomas.Gleixner@t-online.de (Thomas Gleixner)]

On Wednesday,  6. February 2002 05:54, David Woodhouse wrote:
>
> We should be able to use their ECC hardware. As with the DiskOnChip, this
> effectively limits us to one write per page, even if the NAND chip can do
> more than that.
The ECC hardware does not limit us to one write. The ECC hardware just 
calculates the ECC if requested and you must read it back out of the CPLD. 
Then you program it into the spare area. On read you must also enable the ECC 
hardware, read the page, read the ECC .... You can do also read/write without 
ECC.There are no restrictions which part of the spare area to use. You can 
also do everything in software. Anyway we need a different driver for this 
adaptors, because they implement the access to the select lines in their 
CPLD.

> > Maybe we can use the SmartMedia scheme for ECC placement in general for
> > all NAND chips.
> Except DiskOnChip, which has its own layout.
OK

> > I have a look on the data sheets again. I know only about 2 writes/page
> > limit. But maybe we need this, when we have a less smart adaptor with ECC
> > hardware.
> Yes, the ECC makes supporting multiple writes quite hard. We could invent
> new node types and do ECC per-node, but I think it would be better to do
> block-based ECC and use the hardware capabilities, as we have to do write
> batching into blocks anyway.
See above

> OK. Could you show me the changes you had to make?
Should i put them into CVS to jffs-nand-branch or send them by mail ?

> OK, I'll have a go at it. I was leaving it till last, because it's not
> particularly likely to happen in real life. Once the rest works, I'll be
> all happy and motivated to do the evil bits of the error handling :)
sounds good to me

> OK. It would be nice if we could trigger GC to fill the wbuf, rather than
> padding - and only pad it if we really can't use up the space with GC
> writes.
Sure, but we must have something, that makes sure that data is written 
immidiatly to the flash, if we have sensitive data loggers or configuration 
data, where a loss is not acceptable.
 
Another thought about cleanmarker nodes. If we keep them in the page, we can 
easy burn a jffs2-image into a raw flash. This makes life easier for 
bootloaders....

Thomas
__________________________________________________
Thomas Gleixner, autronix automation GmbH
auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: gleixner@autronix.de, http://www.autronix.de