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 bitflips Hm, 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. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/