Re: NAND flash and JFFS(2)

Thomas Gleixner
2002-02-05T17:16:31Z

On Tuesday, 5. February 2002 16:30, David Woodhouse wrote:
> I've had a go at some of these - I got terminally bored on the plane to
> linux.conf.au so 've just checked in code to the experimental
> jffs2-nand-branch in CVS which does the CLEANMARKER bit, although we
> probably want to check where we should put the cleanmarker in NAND flash
> to avoid all the hardware ECC arrangments. I know this one is OK with the
> DiskOnChip but don't remember offhand where SmartMedia puts its ECC data.
The SmartMedia is nothing else than a raw NAND chip assembled into a thin
plastic card. The "Smart" thing is the adaptor they sell for the PC. This
adaptor simulates a DOS-FAT filesystem. The filesystem on the SMartCard
itself is simliar to DOS-FAT with some extensions for bad block management. I
doubt, if it's possible to put jffs2 on top of this adapters. If you use a
SmartMediaCard direct in your hardware as a removable NAND-chip with software
ECC you can put the ECC data into the spare area where you like.

I think we can keep the cleanmarker where it is. The code actualy writes the
next inode after the cleanmarker, and there is no problem. All NAND devices i
reviewed allow min 2 consecutive writes to a page. If we use different
writemodes for cleanmarker and full page (what we actually do), we can skip
the ECC for cleanmarker writing and write the ECC, when we write the page
data. I spent a additional byte in the ECC area, which determines, if ECC is
available or not.
This byte is 0xff, when we have written the cleanmarker, after writing the
page data with ECC i write it to 0. On read i check, if the ECC available
flag is != 0xff.

> I've done some of the write batching too - we have code to set up a write
> buffer, flush it when it's full, etc., do the erase_pending_wbuf_list
> thing, etc.
I got this out of CVS yesterday and made it running.

> It doesn't yet deal nicely with write errors, although we know how,
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.

> and I haven't implemented fsync().
I implemented it basicly and it works.

> > I read also in the archive that JFFS should support NAND. Is this true?
> JFFS ought to be OK on chips that can take ten write cycles per 512-byte
> page, because it uses writev to ensure that nodes are written in one go,
> and no node will be less than 52 bytes.
> On NAND flash chips which can do fewer than ten writes per page, JFFS
> probably won't work either.
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.