Re: [Yaffs] Yaffs2 erasure issue on MT29 NAND part

> First off, please pick up the latest from cvs. The most recent patches should
> not be material to the issues you are dealing with but they might be
> confusing things a bit.

I still haven't gotten around to this as I'm trying to debug at the MTD level.
I thought I'd give a bit of an update if where I'm at.

I noticed that MTD untils will dump OOB information with the nanddump
application. It is my understanding that the last 48 bytes of of the OOB area
is used for ECC

When I dump the NAND after YAFFS2 has created been mounted, and a file created,
I get this on the first page:

/mnt/zen/mtd-utils # ./nanddump -p /dev/mtd12
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 10
Number of bbt blocks: 0
Block size 262144, page size 4096, OOB size 128
Dumping data starting at 0x00000000 and ending at 0x80000000...
0x00000000: 01 00 00 00 01 00 00 00 ff ff 66 69 6c 65 00 00
0x00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000100: 00 00 00 00 00 00 00 00 00 00 ff ff a4 81 00 00
...[TRIM]...
0x00000f10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000f20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000f30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000f40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000f50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000f60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000f70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000f90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000fa0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000fb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000fd0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000fe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000ff0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
OOB Data: ff ff d8 6c 00 00 05 01 00 10 01 00 00 80 00 00
OOB Data: 00 00 33 3b 41 c4 01 00 00 00 01 00 00 00 ff ff
OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Notice that the last 48 bytes of OOB haven't been written. I suspect something
is going wrong at the MTD layer. Using dd or nandwrite doesn't seem to write
ECC data to those bytes either. I went back to a board with a 2K page size and
there is ECC information in the last 24 bytes when YAFFS2 has created it's file
system. However dd or nandwrite do not seem to write ECC information on the 2K
part either.

I'm now trying to understand what is going on with ECC at the MTD level.

Andrew