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
.....
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."
> -----Original Message-----
> From: Christian Gan [mailto:cgan@iders.ca]
> Sent: Wednesday, December 11, 2002 2:02 PM
> To: tglx@linutronix.de; manningc2@actrix.gen.nz; yaffs list
> Subject: RE: [YAFFS] Latest CVS ==> Interaction with mtd
>
>
> I think there may be a problem in the yaffs mtdif, I'm hoping you
> guys can verify.
>
> 1. First off, since ECC is being done on the nand mtd level,
> YAFFs should be looking at the return values of write_ecc and
> read_ecc to see if anything has failed, currently that is not so
> in the mtdif.
>
> 2. Second, looking at read_ecc in nand.c, it seems that an
> '(int)eccstatus' is being added to the end of the oob_buf
> supplied after it is read... but what that means is that the
> supplied oob_buf must be (16 + sizeof(int)) bytes (in my case
> 16+4=20). I'm pretty sure YAFFS is only supplying an oob buf
> that is 16 bytes. This hasn't bitten me in the ass yet but it
> may one day. The bottom line is: I think the oob_buf in
> write_ecc is segmented in 16 bytes per chunk but the oob_buf in
> read_ecc is segmented into 20 bytes per chunk. Hopefully Thomas
> can shed some light on this.
>
> Can someone please tell verify these things for me?
>
> Thanks!
>
> Christian
>
> > -----Original Message-----
> > From: Thomas Gleixner [mailto:tglx@linutronix.de]
> > Sent: Wednesday, December 04, 2002 11:56 PM
> > To: manningc2@actrix.gen.nz; Christian Gan; yaffs list
> > Subject: Re: [YAFFS] Latest CVS ==> Interaction with mtd
> >
> >
> > On Thursday 05 December 2002 00:25, Charles Manning wrote:
> > > Nice to see things come together...
> > >
> > > Take a bow Thomas :-).
> > Thanks.
> > Also I know that I'm strongheaded some times. But at least I
> > think we have a
> > solution for everybody to live with. :)
> >
> > > On Thu, 05 Dec 2002 10:59, Christian Gan wrote:
> > > > Wow... I finally got back onto getting a finalized version
> of YAFFS to
> > > > ship with our board (www.guide-systems.com) and was about
> to get dirty
> > > > with mods I had to make in earlier versions. But lo and behold
> > > > everything worked pretty much on the first compile with
> YAFFS, MTD and
> > > > HWECC.
> > COOL !
> >
> > --
> > 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)