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

[Boris Brezillon <bbrezillon@xxxxxxxxxx>]

On Wed, 23 Jan 2019 12:25:14 +0100
Boris Brezillon <bbrezillon@xxxxxxxxxx> wrote:

> 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'?

BTW, which version of the mtd-utils are you using?

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