On Wednesday 11 December 2002 21:17, Christian Gan wrote:
> Ah.... just found this in an old yaffslist email. There are actually two
> ints tagged onto the end of each read obb, so that makes it 16+4+4 bytes.
> A snippet is included below.
>
> The easiest method around this is probably to have a temp oobbuf in the
> dev->ReadChunkFromNand function that is 24 bytes, then copy the first 16
> bytes to the original buffer supplied. The eccstatus is only useful for
> system calling read_ecc for multiple pages at a time, i.e. the return value
> will tell you at least one ECC failed but the eccstatus will tell you which
> page failed. But in YAFFS's case, since only one page is read a a time, we
> can probably ignore eccstatus and just look at the return value.
>
> From Thomas:
> "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
This was done on a request of Charles - if I understood him right - as he
wants to have control over the ecc results in YAFFS.
In my patch "yaffs.diff", submitted on 11-24-2002 to this list, I took care of
this 16 + x buffer issue.
Citation tglx : " A penalty is that I have to copy oob data around on read,
because NAND driver returns 16Byte OOB data and 2 x 4 Byte ECC correction
result. This was a request of Charles, when we discussed some YAFFS issues
before I did the big nand.c overhaul. This behaviour is a subject, which
could be changed, as the only user would be YAFFS at the moment, AFAIK. "
> 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.
The result value in combination withhretlen gives you a hint, if ECC failed or
a severe I/O problem was detected.
-EIO && retlen == requested length -> no I/O problem, just ECC failure
-EIO && retlen != requested length -> severe I/O problem
> 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."
That means that the fs layer provides a oob buffer, where the nand layer fills
in the ecc data at the appropriate place. See also patch "yaffs.diff"
submitted on 11-24-2002 to this list
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.
(text/plain)