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 interrupted waitfuntion use yield, instead of schedule_timeout support for 6byte/512byte hardware ECC read_ecc, write_ecc extended for different oob-layout selections: Implemented NAND_NONE_OOB, NAND_JFFS2_OOB, NAND_YAFFS_OOB. 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 correct_ecc 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 do. 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 oobsel. 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 too. 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. -- Thomas ____________________________________________________ linutronix - competence in embedded & realtime linux http://www.linutronix.de mail: tglx@linutronix.de --------------------------------------------------------------------------------------- This mailing list is hosted by Toby Churchill open software (www.toby-churchill.org). If mailing list membership is no longer wanted you can remove yourself from the list by sending an email to yaffs-request@toby-churchill.org with the text "unsubscribe" (without the quotes) as the subject.