RE: [Yaffs] Re: YAFFS and HW ECC

>-----Original Message-----
>From: Thomas Gleixner [mailto:tglx@linutronix.de]
>Sent: Thursday, March 17, 2005 10:18 AM
>To: Wookey
>Cc: Roberts Nathan-mcg31137; YAFFS
>Subject: Re: [Yaffs] Re: YAFFS and HW ECC
>
>
>On Thu, 2005-03-17 at 15:16 +0000, Wookey wrote:
>> I haven't seen a response to this so here goes. There is the old MTD
>> way of doing this and the new. The new way allows arbitrary
>> positioning of the bits of info in the OOB as I understand it, which
>> solves your problem. The old MTD scheme allows 2 or three different
>> schemes but if your hardware is putting in 'completely' the wrong
>> place then yes you areout of luck without some hacking.
>>
>> My understanding is a bit vague. Thomas will no doubt correct me if
>> I'm talking rubbish. I'mnot sure when the new scheme came in.
>
>We introduced it along with the support for large page NAND
>and as a result of a long discussion with Charles and David.
>
>There is an explanation in the NAND API docs.
>
>In short:
>
>The board driver provides an oob_info structure which contains
>information about ECC placement and oob bytes free for fs
>usage to the generic nand code.
>
>A fs which wants to write oob data along with the data in the
>main area provides a buffer and the nand layer places the
>bytes into the free byte positions. On read it picks the bytes
>from the oob and puts it into the fs buffer.
>
>The file system can be agnostic of the ECC positions and the
>areas where fs information is stored in oob, so situations
>like yours are not happening.

Thank you for the reply and yes I should have mentioned the fact
that my case involves MTD.

I understand what's been said but I'm unclear on how the tools
(mkyaffsimage, mkyaffs, and nandwrite) can be used in conjunction
with this mechanism. Please point out the flaw in the following
analysis:

It seems like mkyaffsimage generates an image
that contains the OOB info based on how it wants the tags placed:

typedef struct
{
    __u8  tagByte0;
    __u8  tagByte1;
    __u8  tagByte2;
    __u8  tagByte3;
    __u8  pageStatus;     // set to 0 to delete the chunk
    __u8  blockStatus;
    __u8  tagByte4;
    __u8  tagByte5;
    __u8  ecc1[3];
    __u8  tagByte6;
    __u8  tagByte7;
    __u8  ecc2[3];
} yaffs_Spare;

Both nandwrite and mkyaffs will then use the MEMWRITEOOB ioctl to write
these 16 bytes to the OOB. MEMWRITEOOB doesn't appear to use the oobfree
info to figure out how to write the OOB info so it looks to me like it
will write these 16 bytes as layed out above (which will not work with
the hardware ecc placement scheme I am using).

Is this just a case where the tools should really be using GETOOBSEL to figure
out where the free bytes are and then program accordingly?

>
>tglx
>
>
>
>
>