On Wednesday 09 May 2007 18:38, Andrea Conti wrote:
> Anyway, the two implementations are clearly working together,
> so they must share the same oob layout. We can get that from
> the kernel patches, and it is the the exact same
> yaffs_oob_layout you posted above.
Yes, this is a good point.
The OOB/Spare data for the first page in your dump file is:
00000200 00 00 10 00 00 ff 7f 01 ff f0 0f 70 81 aa 5a 97
If I compute the ECC (using MTD's nand_calculate_ecc function)
I get the following 6 ECC bytes:
ff f0 0f aa 5a 97
So it looks like the ECC is at bytes (starting at 0):
8, 9, 10, 13, 14, 15.
Byte 5 (6th byte) is the block-status (this is known/fixed).
This looks like the old Yaffs(1) layout:
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;
So that would translate to an MTD layout like this:
static struct nand_ecclayout nand_oob_16 = {
.eccbytes = 6,
.eccpos = { 8, 9, 10, 13, 14, 15 },
.oobfree = { { 0, 4 }, { 6, 2 }, { 11, 2 } }
};
BUT: there's a problem with getting access to the pageStatus
and blockStatus bytes. You need to know some history here,
and it's a long story. Yaffs used to read and write all 16 bytes
of spare using the MTD api, and they cooperated in handling the 6
ECC bytes. These days, with the improved MTD API, that's not so
easy. You might need to modify the code that packs and unpacks
the Yaffs1 tags into and out of the 'oobfree' data as stored and
retrieved by mtd. If you are using an old kernel (old MTD) you
can probably just use the old code in Yaffs, with the old MTD
api.
If you use the newer MTD API, where nand_ecclayout is present,
you will probably have to include the 'pageStatus' byte in the
oobfree list:
static struct nand_ecclayout nand_oob_16 = {
.eccbytes = 6,
.eccpos = { 8, 9, 10, 13, 14, 15 },
.oobfree = { { 0, 5 }, { 6, 2 }, { 11, 2 } }
};
AND fix up the yaffs pack/unpack funcs and calls to MTD
read/write to understand this. The block status can be gotten
the same way, but this should only be needed by the scan step
and can be retrieved from the (new) mtd using the bad-block test
call.
There is probably enough known now that someone else on the list
can help.
-imcd
(text/plain)