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

Stefan Roese
2019-01-23T11:38:14Z

On 23.01.19 12:25, Boris Brezillon wrote:
> On Wed, 23 Jan 2019 11:04:36 +0100
> Stefan Roese <sr@denx.de> wrote:
>
>> On 23.01.19 10:35, Boris Brezillon wrote:
>>> 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.
>>
>> 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'?

Same result:

root@mt7688:~# ./nandbiterrs /dev/mtd5 -i
incremental biterrors test
[ 5748.988596] gd5f1gq4u_ecc_get_status (124): status=0x20 status2=0x00
Failed to recover 1 bitflips
Read error after 0 bit errors per page

And from your other mail:

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

I'm currently using the one provided with my Yocto build:

root@mt7688:~# mtdinfo --version
mtdinfo (mtd-utils) 2.0.1

I hope that is recent enough.

Thanks,
Stefan