On Tue, 5 Feb 2019 13:59:46 +0100
Miquel Raynal <miquel.ray...@bootlin.com> wrote:
> Hi Martin,
>
> Martin Kepplinger <mart...@posteo.de> wrote on Tue, 29 Jan 2019
> 16:37:00 +0100:
>
> > From: Martin Kepplinger <martin.kepplin...@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.schla...@ginzinger.com>
> > Signed-off-by: Martin Kepplinger <martin.kepplin...@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.ray...@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.
I'll take it.
