Re: NAND flash and JFFS(2)

David Woodhouse
2002-02-06T22:45:36Z

On Wed, 6 Feb 2002, Thomas Gleixner wrote:

> 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.

True - but in order to implement ECC we have to either write partial
blocks _without_ ECC, until we fill the block and write the ECC data with
the 512nd byte, or batch the writes into pages.

> Should i put them into CVS to jffs-nand-branch or send them by mail ?

Mail's probably best at this stage - thanks.

> > 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.

We can do that. Triggering a GC pass to try to fill the wbuf won't take
long - it can be done in the context of a fsync() call, and if we can't
find anything else to write out, _then_ we pad it and still return
(almost) immediately.

We probably need to rethink our (ab)use of the s_dirt member of the
superblock, and actually make write_super() do the sync too.

> 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....

Bootloaders need to know about JFFS2 anyway - currently they erase
blocks without putting a cleanmarker in, then Linux will re-erase all
those blocks again on first mount.

--
dwmw2