> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx@linutronix.de]
> Sent: Wednesday, December 11, 2002 4:53 PM
> To: Christian Gan; manningc2@actrix.gen.nz; yaffs list
> Subject: Re: [YAFFS] Latest CVS ==> Interaction with mtd
>
>
> 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 current implementation in the mtdif is still not right when it calls:
mtd->read_ecc(mtd,addr,YAFFS_BYTES_PER_CHUNK,&dummy,data,spareAsBytes,NAND_Y
AFFS_OOB);
This is with CONFIG_YAFFS_USE_NANDECC turned on.  And spareAsBytes is a 16
byte buffer.

Although it will be fine if CONFIG_YAFFS_USE_NANDECC is turned off as the
call will now be:
mtd->read_ecc(mtd,addr,YAFFS_BYTES_PER_CHUNK,&dummy,data,spareAsBytes,NAND_N
ONE_OOB);

>
> > 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
>

Cool, thats why I think it would be better if the mtdif observed the result
and the retlen for errors.  Currently, it does neither.

> > 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.