Interest in DOC and YAFFS?

Thomas Gleixner tglx at
Wed Sep 25 03:33:46 EDT 2002

On Wednesday 25 September 2002 00:46, Christian Gan wrote:
> MTD Changes:
> ============
> - Finally, the current MTD uses the OOB to write the ECCs and also a "valid
> ECC" byte.  YAFFS tags has no room for the valid ECC byte in the OOB so I
> had to ignore it, which is not exactly ideal.  The byte location that the
> MTD writes to the OOB for ECC also must be changed (by defining the ecc_pos
> in the oob config).
The current nand.c in MTD CVS supports not longer a ECC-valid byte.

Further changes:
Use buffered read/write only for non pagealigned access, speed up the
aligned path by using the filesystem-buffer.

Reset chip removed from nand_select(), implicit done only, when erase is

waitfuntion use yield, instead of schedule_timeout

support for 6byte/512byte hardware ECC

read_ecc, write_ecc extended for different oob-layout selections: 
fs-driver gives one of these constants to select the oob-layout fitting
the filesystem.I have added int oobsel as parameter to each function.
oobdata can be read together with the raw data, when the fs-driver
supplies a big enough buffer. 
size = 12 * number of pages to read (256B pagesize) 
       24 * number of pages to read (512B pagesize)
The buffer contains 8/16 byte oobdata and 4/8 byte returncode from
oobbuf [0-15] oob-data 1st read page 
oobbuf [16-19] return code from correct_ecc byte 0-255
oobbuf [20-23] return code from correct_ecc byte 256-511
oobbuf [24-39] oob-data 2nd read page
oobbuf [40-31] return code from correct_ecc byte 0-255
The returnvalue of read_ecc is -EIO, if any correct_ecc returned -1. But
retlen is equal to the requested length, so fs-driver can decide what to

oobdata can be given from filesystem to program them in one go together
with the raw data. ECC codes are filled in at the place selected by
This supports multipage programming. 
oobbuf[0-15] 1st page to write
oobbuf[16-31] 2nd page to write
ECC is filled in at the selected place.

I hope these changes are a good compromise for YAFFS folks. In this way
we enable YAFFS support and do not break anything. And you have HW-ECC
support out of the box. Maybe the multipage write/read is useful for you

It's not the maximum speedup, which could be done with a YAFFS-specific
layer, but it enables people to use YAFFS and JFFS2 on the same machine,
even on the same flash chip. 

I started already to write a DOC hardware driver, but at the moment it's 
stucked, because I have to do some paid work :). It's not a really big 
problem to write a DOC driver  for nand.c now.

linutronix - competence in embedded & realtime linux
mail: tglx at

More information about the linux-mtd mailing list