Re: [PATCH] mtd: spinand: Add support for GigaDevice GD5F1GQ4UC

Boris Brezillon
2019-01-23T09:35:28Z

On Wed, 23 Jan 2019 10:06:59 +0100
Stefan Roese <sr@denx.de> wrote:

> On 23.01.19 09:55, Boris Brezillon wrote:
> > On Wed, 23 Jan 2019 09:23:47 +0100
> > Stefan Roese <sr@denx.de> 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.