> 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