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

Stefan Roese
2019-01-23T10:04:59Z

[-- Attachment #1: Type: text/plain, Size: 3040 bytes --]

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.

Thanks,
Stefan

[-- Attachment #2: dump-raw --]
[-- Type: application/octet-stream, Size: 2176 bytes --]

[-- Attachment #3: dump-ecc --]
[-- Type: application/octet-stream, Size: 2176 bytes --]

[-- Attachment #4: Type: text/plain, Size: 144 bytes --]