Messages in this thread | | | Date | Tue, 5 Feb 2019 13:59:46 +0100 | From | Miquel Raynal <> | Subject | Re: [PATCH] mtd: rawnand: gpmi: fix MX28 bus master lockup problem |
| |
Hi Martin,
Martin Kepplinger <martink@posteo.de> wrote on Tue, 29 Jan 2019 16:37:00 +0100:
> From: Martin Kepplinger <martin.kepplinger@ginzinger.com> > > Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft > reset may cause bus master lock up") for MX28 too. It has the same > problem. > > Observed problem: once per 100,000+ MX28 reboots NAND read failed on > DMA timeout errors: > [ 1.770823] UBI: attaching mtd3 to ubi0 > [ 2.768088] gpmi_nand: DMA timeout, last DMA :1 > [ 3.958087] gpmi_nand: BCH timeout, last DMA :1 > [ 4.156033] gpmi_nand: Error in ECC-based read: -110 > [ 4.161136] UBI warning: ubi_io_read: error -110 while reading 64 > bytes from PEB 0:0, read only 0 bytes, retry > [ 4.171283] step 1 error > [ 4.173846] gpmi_nand: Chip: 0, Error -1 > > Without BCH soft reset we successfully executed 1,000,000 MX28 reboots. > > I have a quote from NXP regarding this problem, from July 18th 2016: > > "As the i.MX23 and i.MX28 are of the same generation, they share many > characteristics. Unfortunately, also the erratas may be shared. > In case of the documented erratas and the workarounds, you can also > apply the workaround solution of one device on the other one. This have > been reported, but I’m afraid that there are not an estimated date for > updating the Errata documents. > Please accept our apologies for any inconveniences this may cause." > > Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com> > Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> > --- > > This is something we have in our tree for years and is running on > production systems and I hope that this helps others too. > > thanks > martin
Thanks for sharing this.
On my side the patch looks ok, maybe an Acked-by from Han would be great?
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Boris, do you want to take this? If you don't have more fixes to send I can queue it to nand/next.
Thanks, Miquèl
| |