[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NAND flash and JFFS(2)

On Tuesday,  5. February 2002 22:18, David Woodhouse wrote:
> I was assuming the existence of SmartMedia adaptors which do only the ECC,
> allowing you do to the rest of the SmartMedia format in software. In that
> case, it would be best to allow the ECC to go where SmartMedia wants it to
> go, so we don't _have_ to do software ECC.
There are different types of adaptors available:
- Very smart with controller (Useless they force this DOS/FAT style fs)
- Less smart with ECC hardware (OK, but we should have a close look on it, 
regarding ECC stuff, especially write to the ecc area and consecutive writes 
to a page). I have schematics and CPLD code. I try to figure it out.
- simple without anything, like on the Cirrus evaluation boards is exactly 
the same as a soldered NAND chip. (No restrictions)

Maybe we can use the SmartMedia scheme for ECC placement in general for all 
NAND chips.

> This would be feasible. I thought I'd heard of NAND flash devices
> which only allowed one write per page though - and I've already
> written the code to move the cleanmarker.
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.
I had already a look on your changes. 
Is there a possibility to get a mail, when CVS updates are done ?

> > > I've done some of the write batching too - we have code to set up a
> Cool.
tricky hack, but now oops is gone.

> > That's a bit of headache i don't know exactly how to handle. The only
> > tricky thing is a write error when we flush the buffer and have data of
> > the previous write in the buffer. A write error, which occures on non
> > buffered data can be handled by the existing JFFS2 code already. When we
> > crash in the flush buffer write, then we must return retlen = 0. The
> > upper layer in write.c can then check, if c->wbuf_len is > 0 and start
> > data rescuing.
> The comments say what you need to do in that case - still a PITA to
> actually write though.
I know, but I'm not deep enough inside the jffs2 stuff to do this. If you 
provide a basic implementation, i could do the same as to the wbuf stuff.

> > > and I haven't implemented fsync().
> > I implemented it basicly and it works.
> How did you implement this?
I look, if the inode of the file, which has to be synced, is partially or 
full in the writebuffer. Then i pad and flush the buffer and adjust the 
c->nextsize->free_size and dirty_size. Is simple but works.

> > I tried it already and it does work, as long you have enough free space
> > on the chip and you don't run into garbage collection. If you do a copy,
> > remove, copy loop, your filesystem is totaly corrupted after the first
> > block wraparound.
> This is JFFS1, yes?

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

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com