NAND flash and JFFS(2)

[David Woodhouse]

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