R: mtd_nandbitserr and seed using pl35x NAND controller

[Miquel Raynal]

Hi Andrea,

> root at sw0005-devel:~# nandflipbits /dev/mtd0 5 at 0
> root at sw0005-devel:~# nanddump -c -s 0 --length=100 /dev/mtd0  | head
> ECC failed: 0
> ECC corrected: 2
> Number of bad blocks: 0
> Number of bbt blocks: 4
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x00000000 and ending at 0x00000064...
> ECC: 1 corrected bitflip(s) at offset 0x00000000
> 0x00000000: 65 42 49 23 01 00 00 00 00 00 00 00 00 00 00 02  |eBI#............|
> 0x00000010: 00 00 08 00 00 00 10 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 40 93 2d 8c  |............ at .-.|
> 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  |................|
>
> I'm wondering how the author if this driver (you, IIUC) has tested it initially,
> especially regarding ECC functionality.

I was using nandbiterrs -i, but I was on a mainline kernel, I never
tested the backports, even though if they picked the driver entirely
there are little chances this could be a problem.

Subpage writes are normally completely orthogonal to ECC handling, so I
still do not understand what you get here. Maybe you can track the
register statuses and look at what is different.

Good luck and sorry but I have no idea what is wrong here.
Miquèl