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

[Boris Brezillon <bbrezillon@xxxxxxxxxx>]

On Wed, 23 Jan 2019 11:04:36 +0100
Stefan Roese <sr@xxxxxxx> wrote:

> 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 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.  
> 
> 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.

First weird thing, the first portion of OOB (bytes 0x800 to 0x83F) are
set to 0x0, and I'd expect to have 0xff in there. BTW, can you try
nandbiterrs again without the '-k'?

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/