On 23.01.19 10:35, Boris Brezillon wrote:
On Wed, 23 Jan 2019 10:06:59 +0100 Stefan Roese <sr@xxxxxxx> wrote:On 23.01.19 09:55, Boris Brezillon wrote:On Wed, 23 Jan 2019 09:23:47 +0100 Stefan Roese <sr@xxxxxxx> wrote:This one doesn't, incremental mode (-i) should.Here you go: # ./nandbiterrs /dev/mtd5 -k -i incremental biterrors test Failed to recover 1 bitflips Read error after 0 bit errors per page I'm still unsure how this helps here.It helps, it tells us the ECC doesn't work properly (fails to recover one bitflip), or maybe it's the raw accessors that don't don't work.Is there anything else I should test?Add traces to the get_ecc_status() func and print the status value.# ./nandbiterrs /dev/mtd5 -k -i [ 22.098436] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 [ 22.117184] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 <snip many identical lines> [ 23.085412] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 incremental biterrors test [ 23.102973] gd5f1gq4u_ecc_get_status (124): status=0x20 status2=0x00 Failed to recover 1 bitflipsHm, looks like the ECC reports error as soon as you start writing to the NAND. Maybe we have a problem in the write path...Read error after 0 bit errors per page Strange, this does not seem to match what the datasheet tells us. Any further ideas what I should test?Erase a block (save data before if you need to), write random data with the ECC enabled and dump it back (once in raw mode, once with ECC enabled): # flash_erase /dev/mtdX 0 1 # nandwrite --input-size=<pagesize> /dev/mtdX /dev/urandom # nanddump -f /tmp/dump-ecc -l <pagesize> -o /dev/mtdX # nanddump -f /tmp/dump-raw -l <pagesize> -o -n /dev/mtdX Send me both dumps (plus the console output), and we'll see how it looks.
Here you go: root@mt7688:~# flash_erase /dev/mtd5 0 1 Erasing 128 Kibyte @ 0 -- 100 % complete root@mt7688:~# nandwrite --input-size=2048 /dev/mtd5 /dev/urandom Writing data to block 0 at offset 0x0 root@mt7688:~# nanddump -f /tmp/dump-ecc -l 2048 -o /dev/mtd5 ECC failed: 0 ECC corrected:[ 100.171120] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 0 Number of ba[ 100.178436] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 d blocks: 2 Number of bbt blocks: 0 Block size 131072, page size 2048, OOB size 128 Dumping data starting at 0x00000000 and ending at 0x00000800... root@mt7688:~# dmesg -c [ 100.171120] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 [ 100.178436] gd5f1gq4u_ecc_get_status (124): status=0x00 status2=0x00 root@mt7688:~# nanddump -f /tmp/dump-raw -l 2048 -o -n /dev/mtd5 Block size 131072, page size 2048, OOB size 128 Dumping data starting at 0x00000000 and ending at 0x00000800... root@mt7688:~# dmesg -c root@mt7688:~# The attached files are identical. Thanks for looking into this. Thanks, Stefan
Attachment:
dump-raw
Description: Binary data
Attachment:
dump-ecc
Description: Binary data
______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
