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

Boris Brezillon
2019-01-24T08:34:38Z

On Thu, 24 Jan 2019 09:00:43 +0100
Stefan Roese <sr@denx.de> wrote:

> On 24.01.19 08:50, Boris Brezillon wrote:
> > On Thu, 24 Jan 2019 08:35:32 +0100
> > Stefan Roese <sr@denx.de> wrote:
> >
> >> On 23.01.19 13:57, Boris Brezillon wrote:
> >>> On Wed, 23 Jan 2019 13:40:50 +0100
> >>> Boris Brezillon <bbrezillon@kernel.org> wrote:
> >>>
> >>>>> This definitely does look better. I assume that we are we on the
> >>>>> right track now?
> >>>>
> >>>> Yep, and it confirms the ECC caps => 8bits/512bytes. Will send a proper
> >>>> commit for the fix I did and Cc you so you can add your
> >>>> Tested-by/Reviewed-by.
> >>>
> >>> Oh, looks like a side-effect of migrating to the dirmap approach
> >>> (merged in nand/next [1]) is that this bug does not exist. Can you test
> >>> the nand/next branch and let me know if it still works?
> >>>
> >>> [1]http://git.infradead.org/linux-mtd.git/shortlog/refs/heads/nand/next
> >>
> >> Unfortunately this does not seem to work. I was unable to boot my
> >> platform from this branch directly so I rebased all MTD/NAND related
> >> patches on top of the latest kernel.org tree for this.
> >
> > You mean linux-next?
>
> No. I can try linux-next as well if necessary.
>
> >> Here a log
> >> with this version (new error this time):
> >>
> >> root@mt7688:~# ./nandbiterrs /dev/mtd5 -i
> >> incremental biterrors test
> >> libmtd: error!: cannot write 2048 bytes to mtd5 (eraseblock 0, offset 0)
> >> error 5 (Input/output error)
> >> Failed to write page 0 in block 0
> >>
> >> Here a log with nandwrite errors:
> >>
> >> 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
> >> libmtd: error!: cannot write 2048 bytes to mtd5 (eraseblock 0, offset 0)
> >> error 5 (Input/output error)
> >> Erasing failed write from 00000000 to 0x01ffff
> >
> > Weird, I wasn't expecting ERASE to fail (nothing changed in the erase
> > path).
> >
> >> Writing data to block 1 at offset 0x20000
> >> libmtd: error!: cannot write 2048 bytes to mtd5 (eraseblock 1, offset 0)
> >> error 5 (Input/output error)
> >> Erasing failed write from 0x020000 to 0x03ffff
> >> Writing data to block 2 at offset 0x40000
> >> libmtd: error!: cannot write 2048 bytes to mtd5 (eraseblock 2, offset 0)
> >> error 5 (Input/output error)

Can you find out which layer (spinand, spi-mem or the spi driver) is
returning this -EIO?