* GPMI iMX6ull timeout on DMA
@ 2019-07-29 6:41 Greg Ungerer
2019-07-29 8:36 ` Miquel Raynal
0 siblings, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-07-29 6:41 UTC (permalink / raw)
To: Miquel Raynal; +Cc: linux-mtd
Hi Miquel,
I am experiencing a problem with NAND flash DMA timeouts on
iMX6ull based boards. The problem is very similar to that
described in:
https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
That didn't come to any specific resolution that I could see
in that thread.
The boot trace on the console for me looks like this:
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
gpmi-nand 1806000.gpmi-nand: Show BCH registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
gpmi-nand 1806000.gpmi-nand: BCH Geometry :
GF length : 13
ECC Strength : 8
Page Size in Bytes : 2110
Metadata Size in Bytes : 10
ECC Chunk0 Size in Bytes: 512
ECC Chunkn Size in Bytes: 512
ECC Chunk Count : 4
Payload Size in Bytes : 2048
Auxiliary Size in Bytes: 16
Auxiliary Status Offset: 12
Block Mark Byte Offset : 1999
Block Mark Bit Offset : 0
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
nand: timing mode 5 not acknowledged by the NAND chip
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
Scanning device for bad blocks
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
....
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
5 fixed-partitions partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
This is using a linux kernel v5.1.14. I have seen this happen on
a number of boards I have here - but it is only occasional. It
only happens once in a while on boot, maybe 1 in 40 or more times.
So it can take quite a while to reproduce (using a boot loop setup).
As per the email thread I pointed to above I looked at reverting
those patches, but that was not at all easy given how much the gpmi
driver code had moved. So instead I modified the code with this:
--- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
+++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
@@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
{
+#if 0
struct gpmi_nfc_hardware_timing *hw = &this->hw;
struct resources *r = &this->resources;
void __iomem *gpmi_regs = r->gpmi_regs;
@@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
/* Wait for the DLL to settle. */
udelay(dll_wait_time_us);
+#endif
}
int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
So far after a couple of days of testing with this I no longer
see the DMA timeout.
Any thoughts?
Regards
Greg
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 6:41 GPMI iMX6ull timeout on DMA Greg Ungerer
@ 2019-07-29 8:36 ` Miquel Raynal
2019-07-29 8:42 ` Michael Nazzareno Trimarchi
2019-07-29 12:33 ` Greg Ungerer
0 siblings, 2 replies; 39+ messages in thread
From: Miquel Raynal @ 2019-07-29 8:36 UTC (permalink / raw)
To: Greg Ungerer; +Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd
Hi Greg,
One question below.
+Michael
+Sascha
Hello Michael, here is a similar issue to yours, I know you did not
have enough time to share your solution but here we have someone else
reproducing the issue, would you mind sharing a branch or a patch, even
a WIP one, just to help debugging?
Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> Hi Miquel,
>
> I am experiencing a problem with NAND flash DMA timeouts on
> iMX6ull based boards. The problem is very similar to that
> described in:
>
> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
>
> That didn't come to any specific resolution that I could see
> in that thread.
>
> The boot trace on the console for me looks like this:
>
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> GF length : 13
> ECC Strength : 8
> Page Size in Bytes : 2110
> Metadata Size in Bytes : 10
> ECC Chunk0 Size in Bytes: 512
> ECC Chunkn Size in Bytes: 512
> ECC Chunk Count : 4
> Payload Size in Bytes : 2048
> Auxiliary Size in Bytes: 16
> Auxiliary Status Offset: 12
> Block Mark Byte Offset : 1999
> Block Mark Bit Offset : 0
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> nand: timing mode 5 not acknowledged by the NAND chip
What is the final timing mode used? Most of us tested in mode 5 I
guess, maybe mode 4 is broken (don't know if this is the one used here,
neither why mode 5 is refused). Can you please try by limiting the mode
to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> Scanning device for bad blocks
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> ....
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
>
>
> This is using a linux kernel v5.1.14. I have seen this happen on
> a number of boards I have here - but it is only occasional. It
> only happens once in a while on boot, maybe 1 in 40 or more times.
> So it can take quite a while to reproduce (using a boot loop setup).
That's strange... I don't get what would produce such unstable issue.
>
> As per the email thread I pointed to above I looked at reverting
> those patches, but that was not at all easy given how much the gpmi
> driver code had moved. So instead I modified the code with this:
>
> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> {
> +#if 0
> struct gpmi_nfc_hardware_timing *hw = &this->hw;
> struct resources *r = &this->resources;
> void __iomem *gpmi_regs = r->gpmi_regs;
> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> /* Wait for the DLL to settle. */
> udelay(dll_wait_time_us);
> +#endif
> }
> int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>
> So far after a couple of days of testing with this I no longer
> see the DMA timeout.
>
> Any thoughts?
>
> Regards
> Greg
>
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 8:36 ` Miquel Raynal
@ 2019-07-29 8:42 ` Michael Nazzareno Trimarchi
2019-07-29 12:18 ` Greg Ungerer
2019-07-29 12:33 ` Greg Ungerer
1 sibling, 1 reply; 39+ messages in thread
From: Michael Nazzareno Trimarchi @ 2019-07-29 8:42 UTC (permalink / raw)
To: Miquel Raynal; +Cc: s.hauer, Greg Ungerer, linux-mtd
Hi all
On Mon, Jul 29, 2019 at 10:36 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
>
> Hi Greg,
>
> One question below.
>
> +Michael
> +Sascha
>
> Hello Michael, here is a similar issue to yours, I know you did not
> have enough time to share your solution but here we have someone else
> reproducing the issue, would you mind sharing a branch or a patch, even
> a WIP one, just to help debugging?
>
I have patches reverted as I mention in the email. The step to
reproduce is simple.
Just reboot every successful boot.
Michael
> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>
> > Hi Miquel,
> >
> > I am experiencing a problem with NAND flash DMA timeouts on
> > iMX6ull based boards. The problem is very similar to that
> > described in:
> >
> > https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> >
> > That didn't come to any specific resolution that I could see
> > in that thread.
> >
> > The boot trace on the console for me looks like this:
> >
> > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > nand: Micron MT29F2G08ABAEAWP
> > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > GF length : 13
> > ECC Strength : 8
> > Page Size in Bytes : 2110
> > Metadata Size in Bytes : 10
> > ECC Chunk0 Size in Bytes: 512
> > ECC Chunkn Size in Bytes: 512
> > ECC Chunk Count : 4
> > Payload Size in Bytes : 2048
> > Auxiliary Size in Bytes: 16
> > Auxiliary Status Offset: 12
> > Block Mark Byte Offset : 1999
> > Block Mark Bit Offset : 0
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > nand: timing mode 5 not acknowledged by the NAND chip
>
> What is the final timing mode used? Most of us tested in mode 5 I
> guess, maybe mode 4 is broken (don't know if this is the one used here,
> neither why mode 5 is refused). Can you please try by limiting the mode
> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > Scanning device for bad blocks
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > ....
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > 5 fixed-partitions partitions found on MTD device gpmi-nand
> > Creating 5 MTD partitions on "gpmi-nand":
> > 0x000000000000-0x000000500000 : "u-boot"
> > 0x000000500000-0x000000600000 : "u-boot-env"
> > 0x000000600000-0x000000800000 : "log"
> > 0x000000800000-0x000010000000 : "flash"
> > 0x000000000000-0x000010000000 : "all"
> > gpmi-nand 1806000.gpmi-nand: driver registered.
> >
> >
> > This is using a linux kernel v5.1.14. I have seen this happen on
> > a number of boards I have here - but it is only occasional. It
> > only happens once in a while on boot, maybe 1 in 40 or more times.
> > So it can take quite a while to reproduce (using a boot loop setup).
>
> That's strange... I don't get what would produce such unstable issue.
>
> >
> > As per the email thread I pointed to above I looked at reverting
> > those patches, but that was not at all easy given how much the gpmi
> > driver code had moved. So instead I modified the code with this:
> >
> > --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> > void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > {
> > +#if 0
> > struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > struct resources *r = &this->resources;
> > void __iomem *gpmi_regs = r->gpmi_regs;
> > @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > /* Wait for the DLL to settle. */
> > udelay(dll_wait_time_us);
> > +#endif
> > }
> > int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >
> > So far after a couple of days of testing with this I no longer
> > see the DMA timeout.
> >
> > Any thoughts?
> >
> > Regards
> > Greg
> >
>
> Thanks,
> Miquèl
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 8:42 ` Michael Nazzareno Trimarchi
@ 2019-07-29 12:18 ` Greg Ungerer
2019-07-29 12:20 ` Michael Nazzareno Trimarchi
0 siblings, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-07-29 12:18 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi, Miquel Raynal; +Cc: s.hauer, linux-mtd
Hi Michael,
On 29/7/19 6:42 pm, Michael Nazzareno Trimarchi wrote:
> Hi all
>
> On Mon, Jul 29, 2019 at 10:36 AM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
>>
>> Hi Greg,
>>
>> One question below.
>>
>> +Michael
>> +Sascha
>>
>> Hello Michael, here is a similar issue to yours, I know you did not
>> have enough time to share your solution but here we have someone else
>> reproducing the issue, would you mind sharing a branch or a patch, even
>> a WIP one, just to help debugging?
>>
>
> I have patches reverted as I mention in the email. The step to
> reproduce is simple.
>
> Just reboot every successful boot.
Testing like this how often does it occur?
Regards
Greg
> Michael
>
>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>
>>> Hi Miquel,
>>>
>>> I am experiencing a problem with NAND flash DMA timeouts on
>>> iMX6ull based boards. The problem is very similar to that
>>> described in:
>>>
>>> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
>>>
>>> That didn't come to any specific resolution that I could see
>>> in that thread.
>>>
>>> The boot trace on the console for me looks like this:
>>>
>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>>> nand: Micron MT29F2G08ABAEAWP
>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
>>> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
>>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
>>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
>>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
>>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
>>> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
>>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
>>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
>>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
>>> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
>>> GF length : 13
>>> ECC Strength : 8
>>> Page Size in Bytes : 2110
>>> Metadata Size in Bytes : 10
>>> ECC Chunk0 Size in Bytes: 512
>>> ECC Chunkn Size in Bytes: 512
>>> ECC Chunk Count : 4
>>> Payload Size in Bytes : 2048
>>> Auxiliary Size in Bytes: 16
>>> Auxiliary Status Offset: 12
>>> Block Mark Byte Offset : 1999
>>> Block Mark Bit Offset : 0
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
>>> nand: timing mode 5 not acknowledged by the NAND chip
>>
>> What is the final timing mode used? Most of us tested in mode 5 I
>> guess, maybe mode 4 is broken (don't know if this is the one used here,
>> neither why mode 5 is refused). Can you please try by limiting the mode
>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>>
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> Scanning device for bad blocks
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> ....
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>>> Creating 5 MTD partitions on "gpmi-nand":
>>> 0x000000000000-0x000000500000 : "u-boot"
>>> 0x000000500000-0x000000600000 : "u-boot-env"
>>> 0x000000600000-0x000000800000 : "log"
>>> 0x000000800000-0x000010000000 : "flash"
>>> 0x000000000000-0x000010000000 : "all"
>>> gpmi-nand 1806000.gpmi-nand: driver registered.
>>>
>>>
>>> This is using a linux kernel v5.1.14. I have seen this happen on
>>> a number of boards I have here - but it is only occasional. It
>>> only happens once in a while on boot, maybe 1 in 40 or more times.
>>> So it can take quite a while to reproduce (using a boot loop setup).
>>
>> That's strange... I don't get what would produce such unstable issue.
>>
>>>
>>> As per the email thread I pointed to above I looked at reverting
>>> those patches, but that was not at all easy given how much the gpmi
>>> driver code had moved. So instead I modified the code with this:
>>>
>>> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>>> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>>> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>>> void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>> {
>>> +#if 0
>>> struct gpmi_nfc_hardware_timing *hw = &this->hw;
>>> struct resources *r = &this->resources;
>>> void __iomem *gpmi_regs = r->gpmi_regs;
>>> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>> /* Wait for the DLL to settle. */
>>> udelay(dll_wait_time_us);
>>> +#endif
>>> }
>>> int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>
>>> So far after a couple of days of testing with this I no longer
>>> see the DMA timeout.
>>>
>>> Any thoughts?
>>>
>>> Regards
>>> Greg
>>>
>>
>> Thanks,
>> Miquèl
>
>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 12:18 ` Greg Ungerer
@ 2019-07-29 12:20 ` Michael Nazzareno Trimarchi
0 siblings, 0 replies; 39+ messages in thread
From: Michael Nazzareno Trimarchi @ 2019-07-29 12:20 UTC (permalink / raw)
To: Greg Ungerer; +Cc: s.hauer, linux-mtd, Miquel Raynal
Hi
On Mon, Jul 29, 2019 at 2:19 PM Greg Ungerer <gerg@kernel.org> wrote:
>
> Hi Michael,
>
> On 29/7/19 6:42 pm, Michael Nazzareno Trimarchi wrote:
> > Hi all
> >
> > On Mon, Jul 29, 2019 at 10:36 AM Miquel Raynal
> > <miquel.raynal@bootlin.com> wrote:
> >>
> >> Hi Greg,
> >>
> >> One question below.
> >>
> >> +Michael
> >> +Sascha
> >>
> >> Hello Michael, here is a similar issue to yours, I know you did not
> >> have enough time to share your solution but here we have someone else
> >> reproducing the issue, would you mind sharing a branch or a patch, even
> >> a WIP one, just to help debugging?
> >>
> >
> > I have patches reverted as I mention in the email. The step to
> > reproduce is simple.
> >
> > Just reboot every successful boot.
>
> Testing like this how often does it occur?
>
Not more then 60 reboot ;). The problem is how is done the code the
system can not rebooting without an hardware watchdog
MIchael
> Regards
> Greg
>
>
> > Michael
> >
> >> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>
> >>> Hi Miquel,
> >>>
> >>> I am experiencing a problem with NAND flash DMA timeouts on
> >>> iMX6ull based boards. The problem is very similar to that
> >>> described in:
> >>>
> >>> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> >>>
> >>> That didn't come to any specific resolution that I could see
> >>> in that thread.
> >>>
> >>> The boot trace on the console for me looks like this:
> >>>
> >>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >>> nand: Micron MT29F2G08ABAEAWP
> >>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >>> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> >>> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> >>> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> >>> GF length : 13
> >>> ECC Strength : 8
> >>> Page Size in Bytes : 2110
> >>> Metadata Size in Bytes : 10
> >>> ECC Chunk0 Size in Bytes: 512
> >>> ECC Chunkn Size in Bytes: 512
> >>> ECC Chunk Count : 4
> >>> Payload Size in Bytes : 2048
> >>> Auxiliary Size in Bytes: 16
> >>> Auxiliary Status Offset: 12
> >>> Block Mark Byte Offset : 1999
> >>> Block Mark Bit Offset : 0
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> >>> nand: timing mode 5 not acknowledged by the NAND chip
> >>
> >> What is the final timing mode used? Most of us tested in mode 5 I
> >> guess, maybe mode 4 is broken (don't know if this is the one used here,
> >> neither why mode 5 is refused). Can you please try by limiting the mode
> >> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> >>
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> Scanning device for bad blocks
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> ....
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> 5 fixed-partitions partitions found on MTD device gpmi-nand
> >>> Creating 5 MTD partitions on "gpmi-nand":
> >>> 0x000000000000-0x000000500000 : "u-boot"
> >>> 0x000000500000-0x000000600000 : "u-boot-env"
> >>> 0x000000600000-0x000000800000 : "log"
> >>> 0x000000800000-0x000010000000 : "flash"
> >>> 0x000000000000-0x000010000000 : "all"
> >>> gpmi-nand 1806000.gpmi-nand: driver registered.
> >>>
> >>>
> >>> This is using a linux kernel v5.1.14. I have seen this happen on
> >>> a number of boards I have here - but it is only occasional. It
> >>> only happens once in a while on boot, maybe 1 in 40 or more times.
> >>> So it can take quite a while to reproduce (using a boot loop setup).
> >>
> >> That's strange... I don't get what would produce such unstable issue.
> >>
> >>>
> >>> As per the email thread I pointed to above I looked at reverting
> >>> those patches, but that was not at all easy given how much the gpmi
> >>> driver code had moved. So instead I modified the code with this:
> >>>
> >>> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> >>> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> >>> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> >>> void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>> {
> >>> +#if 0
> >>> struct gpmi_nfc_hardware_timing *hw = &this->hw;
> >>> struct resources *r = &this->resources;
> >>> void __iomem *gpmi_regs = r->gpmi_regs;
> >>> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>> /* Wait for the DLL to settle. */
> >>> udelay(dll_wait_time_us);
> >>> +#endif
> >>> }
> >>> int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>>
> >>> So far after a couple of days of testing with this I no longer
> >>> see the DMA timeout.
> >>>
> >>> Any thoughts?
> >>>
> >>> Regards
> >>> Greg
> >>>
> >>
> >> Thanks,
> >> Miquèl
> >
> >
> >
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 8:36 ` Miquel Raynal
2019-07-29 8:42 ` Michael Nazzareno Trimarchi
@ 2019-07-29 12:33 ` Greg Ungerer
2019-07-29 12:47 ` Miquel Raynal
1 sibling, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-07-29 12:33 UTC (permalink / raw)
To: Miquel Raynal; +Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd
Hi Miquel,
On 29/7/19 6:36 pm, Miquel Raynal wrote:
> Hi Greg,
>
> One question below.
>
> +Michael
> +Sascha
>
> Hello Michael, here is a similar issue to yours, I know you did not
> have enough time to share your solution but here we have someone else
> reproducing the issue, would you mind sharing a branch or a patch, even
> a WIP one, just to help debugging?
>
> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>
>> Hi Miquel,
>>
>> I am experiencing a problem with NAND flash DMA timeouts on
>> iMX6ull based boards. The problem is very similar to that
>> described in:
>>
>> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
>>
>> That didn't come to any specific resolution that I could see
>> in that thread.
>>
>> The boot trace on the console for me looks like this:
>>
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
>> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
>> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
>> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
>> GF length : 13
>> ECC Strength : 8
>> Page Size in Bytes : 2110
>> Metadata Size in Bytes : 10
>> ECC Chunk0 Size in Bytes: 512
>> ECC Chunkn Size in Bytes: 512
>> ECC Chunk Count : 4
>> Payload Size in Bytes : 2048
>> Auxiliary Size in Bytes: 16
>> Auxiliary Status Offset: 12
>> Block Mark Byte Offset : 1999
>> Block Mark Bit Offset : 0
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
>> nand: timing mode 5 not acknowledged by the NAND chip
>
> What is the final timing mode used? Most of us tested in mode 5 I
> guess, maybe mode 4 is broken (don't know if this is the one used here,
> neither why mode 5 is refused). Can you please try by limiting the mode
> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
Sure, how to do that?
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> Scanning device for bad blocks
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> ....
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>>
>>
>> This is using a linux kernel v5.1.14. I have seen this happen on
>> a number of boards I have here - but it is only occasional. It
>> only happens once in a while on boot, maybe 1 in 40 or more times.
>> So it can take quite a while to reproduce (using a boot loop setup).
>
> That's strange... I don't get what would produce such unstable issue.
My initial guess is that the calculated timing is very marginal.
The problem seems more likely to happen if flash write activity
had been occurring just before a soft reboot. Its not a guarantee,
just more likely.
Interesting observation is that Michael was using Micron flash,
and boards that I have with the problem also have Micron flash.
Both a form of Micron MT29F2G08.
I have similar boards, iMX6ull based, with different brands of
NAND flash and I have not seen any problem on them.
Regards
Greg
>> As per the email thread I pointed to above I looked at reverting
>> those patches, but that was not at all easy given how much the gpmi
>> driver code had moved. So instead I modified the code with this:
>>
>> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>> void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>> {
>> +#if 0
>> struct gpmi_nfc_hardware_timing *hw = &this->hw;
>> struct resources *r = &this->resources;
>> void __iomem *gpmi_regs = r->gpmi_regs;
>> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>> /* Wait for the DLL to settle. */
>> udelay(dll_wait_time_us);
>> +#endif
>> }
>> int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>
>> So far after a couple of days of testing with this I no longer
>> see the DMA timeout.
>>
>> Any thoughts?
>>
>> Regards
>> Greg
>>
>
> Thanks,
> Miquèl
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 12:33 ` Greg Ungerer
@ 2019-07-29 12:47 ` Miquel Raynal
2019-07-29 12:49 ` Michael Nazzareno Trimarchi
2019-07-30 0:28 ` Greg Ungerer
0 siblings, 2 replies; 39+ messages in thread
From: Miquel Raynal @ 2019-07-29 12:47 UTC (permalink / raw)
To: Greg Ungerer
Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd, Boris Brezillon
Hi Greg,
+ Boris
Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> Hi Miquel,
>
> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > Hi Greg,
> >
> > One question below.
> >
> > +Michael
> > +Sascha
> >
> > Hello Michael, here is a similar issue to yours, I know you did not
> > have enough time to share your solution but here we have someone else
> > reproducing the issue, would you mind sharing a branch or a patch, even
> > a WIP one, just to help debugging?
> >
> > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >
> >> Hi Miquel,
> >>
> >> I am experiencing a problem with NAND flash DMA timeouts on
> >> iMX6ull based boards. The problem is very similar to that
> >> described in:
> >>
> >> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> >>
> >> That didn't come to any specific resolution that I could see
> >> in that thread.
> >>
> >> The boot trace on the console for me looks like this:
> >>
> >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >> nand: Micron MT29F2G08ABAEAWP
> >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> >> GF length : 13
> >> ECC Strength : 8
> >> Page Size in Bytes : 2110
> >> Metadata Size in Bytes : 10
> >> ECC Chunk0 Size in Bytes: 512
> >> ECC Chunkn Size in Bytes: 512
> >> ECC Chunk Count : 4
> >> Payload Size in Bytes : 2048
> >> Auxiliary Size in Bytes: 16
> >> Auxiliary Status Offset: 12
> >> Block Mark Byte Offset : 1999
> >> Block Mark Bit Offset : 0
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> >> nand: timing mode 5 not acknowledged by the NAND chip
> >
> > What is the final timing mode used? Most of us tested in mode 5 I
> > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > neither why mode 5 is refused). Can you please try by limiting the mode
> > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>
> Sure, how to do that?
This loop [1] tries to configure each mode (5, 4, ...) until one
succeeds (default is 0: must always work). Please try to limit mode to
0, 1, etc.
Mode 0 should work.
[1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
>
>
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> Scanning device for bad blocks
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> ....
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> >> Creating 5 MTD partitions on "gpmi-nand":
> >> 0x000000000000-0x000000500000 : "u-boot"
> >> 0x000000500000-0x000000600000 : "u-boot-env"
> >> 0x000000600000-0x000000800000 : "log"
> >> 0x000000800000-0x000010000000 : "flash"
> >> 0x000000000000-0x000010000000 : "all"
> >> gpmi-nand 1806000.gpmi-nand: driver registered.
> >>
> >>
> >> This is using a linux kernel v5.1.14. I have seen this happen on
> >> a number of boards I have here - but it is only occasional. It
> >> only happens once in a while on boot, maybe 1 in 40 or more times.
> >> So it can take quite a while to reproduce (using a boot loop setup).
> >
> > That's strange... I don't get what would produce such unstable issue.
>
> My initial guess is that the calculated timing is very marginal.
What do you mean by "marginal"?
> The problem seems more likely to happen if flash write activity
> had been occurring just before a soft reboot. Its not a guarantee,
> just more likely.
That's really disturbing. I doubt this is the real cause though.
>
> Interesting observation is that Michael was using Micron flash,
> and boards that I have with the problem also have Micron flash.
> Both a form of Micron MT29F2G08.
>
> I have similar boards, iMX6ull based, with different brands of
> NAND flash and I have not seen any problem on them.
That's great to narrow down the root cause. Maybe these chips have
tighter timing constraints.
>
> Regards
> Greg
>
>
>
> >> As per the email thread I pointed to above I looked at reverting
> >> those patches, but that was not at all easy given how much the gpmi
> >> driver code had moved. So instead I modified the code with this:
> >>
> >> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> >> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> >> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> >> void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >> {
> >> +#if 0
> >> struct gpmi_nfc_hardware_timing *hw = &this->hw;
> >> struct resources *r = &this->resources;
> >> void __iomem *gpmi_regs = r->gpmi_regs;
> >> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >> /* Wait for the DLL to settle. */
> >> udelay(dll_wait_time_us);
> >> +#endif
> >> }
> >> int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>
> >> So far after a couple of days of testing with this I no longer
> >> see the DMA timeout.
> >>
> >> Any thoughts?
> >>
> >> Regards
> >> Greg
> >>
> >
> > Thanks,
> > Miquèl
> >
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 12:47 ` Miquel Raynal
@ 2019-07-29 12:49 ` Michael Nazzareno Trimarchi
2019-07-29 12:55 ` Miquel Raynal
2019-07-30 0:28 ` Greg Ungerer
1 sibling, 1 reply; 39+ messages in thread
From: Michael Nazzareno Trimarchi @ 2019-07-29 12:49 UTC (permalink / raw)
To: Miquel Raynal; +Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon
Hi Miguel
On Mon, Jul 29, 2019 at 2:47 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Greg,
>
> + Boris
>
> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>
> > Hi Miquel,
> >
> > On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > > Hi Greg,
> > >
> > > One question below.
> > >
> > > +Michael
> > > +Sascha
> > >
> > > Hello Michael, here is a similar issue to yours, I know you did not
> > > have enough time to share your solution but here we have someone else
> > > reproducing the issue, would you mind sharing a branch or a patch, even
> > > a WIP one, just to help debugging?
> > >
> > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > >
> > >> Hi Miquel,
> > >>
> > >> I am experiencing a problem with NAND flash DMA timeouts on
> > >> iMX6ull based boards. The problem is very similar to that
> > >> described in:
> > >>
> > >> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > >>
> > >> That didn't come to any specific resolution that I could see
> > >> in that thread.
> > >>
> > >> The boot trace on the console for me looks like this:
> > >>
> > >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > >> nand: Micron MT29F2G08ABAEAWP
> > >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > >> GF length : 13
> > >> ECC Strength : 8
> > >> Page Size in Bytes : 2110
> > >> Metadata Size in Bytes : 10
> > >> ECC Chunk0 Size in Bytes: 512
> > >> ECC Chunkn Size in Bytes: 512
> > >> ECC Chunk Count : 4
> > >> Payload Size in Bytes : 2048
> > >> Auxiliary Size in Bytes: 16
> > >> Auxiliary Status Offset: 12
> > >> Block Mark Byte Offset : 1999
> > >> Block Mark Bit Offset : 0
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > >> nand: timing mode 5 not acknowledged by the NAND chip
> > >
> > > What is the final timing mode used? Most of us tested in mode 5 I
> > > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > > neither why mode 5 is refused). Can you please try by limiting the mode
> > > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> >
> > Sure, how to do that?
>
> This loop [1] tries to configure each mode (5, 4, ...) until one
> succeeds (default is 0: must always work). Please try to limit mode to
> 0, 1, etc.
>
> Mode 0 should work.
>
This is not correct. When all the mode fail it fallback to 0 that does
not work. Already check
So the fallback is created for this situation
> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
>
> >
> >
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> Scanning device for bad blocks
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> ....
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> > >> Creating 5 MTD partitions on "gpmi-nand":
> > >> 0x000000000000-0x000000500000 : "u-boot"
> > >> 0x000000500000-0x000000600000 : "u-boot-env"
> > >> 0x000000600000-0x000000800000 : "log"
> > >> 0x000000800000-0x000010000000 : "flash"
> > >> 0x000000000000-0x000010000000 : "all"
> > >> gpmi-nand 1806000.gpmi-nand: driver registered.
> > >>
> > >>
> > >> This is using a linux kernel v5.1.14. I have seen this happen on
> > >> a number of boards I have here - but it is only occasional. It
> > >> only happens once in a while on boot, maybe 1 in 40 or more times.
> > >> So it can take quite a while to reproduce (using a boot loop setup).
> > >
> > > That's strange... I don't get what would produce such unstable issue.
> >
> > My initial guess is that the calculated timing is very marginal.
>
> What do you mean by "marginal"?
>
I don't think that is timing calculation. I have tried to use the same timing
as before but when those are applide. Is it possible?
Michael
> > The problem seems more likely to happen if flash write activity
> > had been occurring just before a soft reboot. Its not a guarantee,
> > just more likely.
>
> That's really disturbing. I doubt this is the real cause though.
>
> >
> > Interesting observation is that Michael was using Micron flash,
> > and boards that I have with the problem also have Micron flash.
> > Both a form of Micron MT29F2G08.
> >
> > I have similar boards, iMX6ull based, with different brands of
> > NAND flash and I have not seen any problem on them.
>
> That's great to narrow down the root cause. Maybe these chips have
> tighter timing constraints.
>
> >
> > Regards
> > Greg
> >
> >
> >
> > >> As per the email thread I pointed to above I looked at reverting
> > >> those patches, but that was not at all easy given how much the gpmi
> > >> driver code had moved. So instead I modified the code with this:
> > >>
> > >> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > >> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > >> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> > >> void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > >> {
> > >> +#if 0
> > >> struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > >> struct resources *r = &this->resources;
> > >> void __iomem *gpmi_regs = r->gpmi_regs;
> > >> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > >> /* Wait for the DLL to settle. */
> > >> udelay(dll_wait_time_us);
> > >> +#endif
> > >> }
> > >> int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> > >>
> > >> So far after a couple of days of testing with this I no longer
> > >> see the DMA timeout.
> > >>
> > >> Any thoughts?
> > >>
> > >> Regards
> > >> Greg
> > >>
> > >
> > > Thanks,
> > > Miquèl
> > >
>
> Thanks,
> Miquèl
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 12:49 ` Michael Nazzareno Trimarchi
@ 2019-07-29 12:55 ` Miquel Raynal
2019-07-29 13:00 ` Michael Nazzareno Trimarchi
0 siblings, 1 reply; 39+ messages in thread
From: Miquel Raynal @ 2019-07-29 12:55 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi
Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon
Hi Michael,
Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
Mon, 29 Jul 2019 14:49:19 +0200:
> Hi Miguel
>
> On Mon, Jul 29, 2019 at 2:47 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Greg,
> >
> > + Boris
> >
> > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >
> > > Hi Miquel,
> > >
> > > On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > > > Hi Greg,
> > > >
> > > > One question below.
> > > >
> > > > +Michael
> > > > +Sascha
> > > >
> > > > Hello Michael, here is a similar issue to yours, I know you did not
> > > > have enough time to share your solution but here we have someone else
> > > > reproducing the issue, would you mind sharing a branch or a patch, even
> > > > a WIP one, just to help debugging?
> > > >
> > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > > >
> > > >> Hi Miquel,
> > > >>
> > > >> I am experiencing a problem with NAND flash DMA timeouts on
> > > >> iMX6ull based boards. The problem is very similar to that
> > > >> described in:
> > > >>
> > > >> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > > >>
> > > >> That didn't come to any specific resolution that I could see
> > > >> in that thread.
> > > >>
> > > >> The boot trace on the console for me looks like this:
> > > >>
> > > >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > >> nand: Micron MT29F2G08ABAEAWP
> > > >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > >> GF length : 13
> > > >> ECC Strength : 8
> > > >> Page Size in Bytes : 2110
> > > >> Metadata Size in Bytes : 10
> > > >> ECC Chunk0 Size in Bytes: 512
> > > >> ECC Chunkn Size in Bytes: 512
> > > >> ECC Chunk Count : 4
> > > >> Payload Size in Bytes : 2048
> > > >> Auxiliary Size in Bytes: 16
> > > >> Auxiliary Status Offset: 12
> > > >> Block Mark Byte Offset : 1999
> > > >> Block Mark Bit Offset : 0
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > > >> nand: timing mode 5 not acknowledged by the NAND chip
> > > >
> > > > What is the final timing mode used? Most of us tested in mode 5 I
> > > > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > > > neither why mode 5 is refused). Can you please try by limiting the mode
> > > > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> > >
> > > Sure, how to do that?
> >
> > This loop [1] tries to configure each mode (5, 4, ...) until one
> > succeeds (default is 0: must always work). Please try to limit mode to
> > 0, 1, etc.
> >
> > Mode 0 should work.
> >
>
> This is not correct. When all the mode fail it fallback to 0 that does
> not work. Already check
> So the fallback is created for this situation
Sorry but I don't understand what you are saying.
Are you telling me that you already tried mode 0 and that it did not
work better than other timings?
>
> > [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
> >
> > >
> > >
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> Scanning device for bad blocks
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> ....
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> > > >> Creating 5 MTD partitions on "gpmi-nand":
> > > >> 0x000000000000-0x000000500000 : "u-boot"
> > > >> 0x000000500000-0x000000600000 : "u-boot-env"
> > > >> 0x000000600000-0x000000800000 : "log"
> > > >> 0x000000800000-0x000010000000 : "flash"
> > > >> 0x000000000000-0x000010000000 : "all"
> > > >> gpmi-nand 1806000.gpmi-nand: driver registered.
> > > >>
> > > >>
> > > >> This is using a linux kernel v5.1.14. I have seen this happen on
> > > >> a number of boards I have here - but it is only occasional. It
> > > >> only happens once in a while on boot, maybe 1 in 40 or more times.
> > > >> So it can take quite a while to reproduce (using a boot loop setup).
> > > >
> > > > That's strange... I don't get what would produce such unstable issue.
> > >
> > > My initial guess is that the calculated timing is very marginal.
> >
> > What do you mean by "marginal"?
> >
>
> I don't think that is timing calculation. I have tried to use the same timing
> as before but when those are applide. Is it possible?
^
I suppose the end of the sentence is missing?
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 12:55 ` Miquel Raynal
@ 2019-07-29 13:00 ` Michael Nazzareno Trimarchi
2019-07-29 13:22 ` Miquel Raynal
0 siblings, 1 reply; 39+ messages in thread
From: Michael Nazzareno Trimarchi @ 2019-07-29 13:00 UTC (permalink / raw)
To: Miquel Raynal; +Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon
Hi Miquel
On Mon, Jul 29, 2019 at 2:55 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Michael,
>
> Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> Mon, 29 Jul 2019 14:49:19 +0200:
>
> > Hi Miguel
> >
> > On Mon, Jul 29, 2019 at 2:47 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Greg,
> > >
> > > + Boris
> > >
> > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> > >
> > > > Hi Miquel,
> > > >
> > > > On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > > > > Hi Greg,
> > > > >
> > > > > One question below.
> > > > >
> > > > > +Michael
> > > > > +Sascha
> > > > >
> > > > > Hello Michael, here is a similar issue to yours, I know you did not
> > > > > have enough time to share your solution but here we have someone else
> > > > > reproducing the issue, would you mind sharing a branch or a patch, even
> > > > > a WIP one, just to help debugging?
> > > > >
> > > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > > > >
> > > > >> Hi Miquel,
> > > > >>
> > > > >> I am experiencing a problem with NAND flash DMA timeouts on
> > > > >> iMX6ull based boards. The problem is very similar to that
> > > > >> described in:
> > > > >>
> > > > >> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > > > >>
> > > > >> That didn't come to any specific resolution that I could see
> > > > >> in that thread.
> > > > >>
> > > > >> The boot trace on the console for me looks like this:
> > > > >>
> > > > >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > > >> nand: Micron MT29F2G08ABAEAWP
> > > > >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > > >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > > >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > > >> GF length : 13
> > > > >> ECC Strength : 8
> > > > >> Page Size in Bytes : 2110
> > > > >> Metadata Size in Bytes : 10
> > > > >> ECC Chunk0 Size in Bytes: 512
> > > > >> ECC Chunkn Size in Bytes: 512
> > > > >> ECC Chunk Count : 4
> > > > >> Payload Size in Bytes : 2048
> > > > >> Auxiliary Size in Bytes: 16
> > > > >> Auxiliary Status Offset: 12
> > > > >> Block Mark Byte Offset : 1999
> > > > >> Block Mark Bit Offset : 0
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > > > >> nand: timing mode 5 not acknowledged by the NAND chip
> > > > >
> > > > > What is the final timing mode used? Most of us tested in mode 5 I
> > > > > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > > > > neither why mode 5 is refused). Can you please try by limiting the mode
> > > > > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> > > >
> > > > Sure, how to do that?
> > >
> > > This loop [1] tries to configure each mode (5, 4, ...) until one
> > > succeeds (default is 0: must always work). Please try to limit mode to
> > > 0, 1, etc.
> > >
> > > Mode 0 should work.
> > >
> >
> > This is not correct. When all the mode fail it fallback to 0 that does
> > not work. Already check
> > So the fallback is created for this situation
>
> Sorry but I don't understand what you are saying.
>
I said that where a timing mode is not ackolege then the mtd stack should
send a reset command and fallback to timeing mode 0. The nand does not
respond anymore.
> Are you telling me that you already tried mode 0 and that it did not
> work better than other timings?
>
I force only to use different mode but never try mode 0 ;) just
because should be
the normal fallback
Michael
> >
> > > [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
> > >
> > > >
> > > >
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> Scanning device for bad blocks
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> ....
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> > > > >> Creating 5 MTD partitions on "gpmi-nand":
> > > > >> 0x000000000000-0x000000500000 : "u-boot"
> > > > >> 0x000000500000-0x000000600000 : "u-boot-env"
> > > > >> 0x000000600000-0x000000800000 : "log"
> > > > >> 0x000000800000-0x000010000000 : "flash"
> > > > >> 0x000000000000-0x000010000000 : "all"
> > > > >> gpmi-nand 1806000.gpmi-nand: driver registered.
> > > > >>
> > > > >>
> > > > >> This is using a linux kernel v5.1.14. I have seen this happen on
> > > > >> a number of boards I have here - but it is only occasional. It
> > > > >> only happens once in a while on boot, maybe 1 in 40 or more times.
> > > > >> So it can take quite a while to reproduce (using a boot loop setup).
> > > > >
> > > > > That's strange... I don't get what would produce such unstable issue.
> > > >
> > > > My initial guess is that the calculated timing is very marginal.
> > >
> > > What do you mean by "marginal"?
> > >
> >
> > I don't think that is timing calculation. I have tried to use the same timing
> > as before but when those are applide. Is it possible?
>
> ^
> I suppose the end of the sentence is missing?
>
>
> Thanks,
> Miquèl
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 13:00 ` Michael Nazzareno Trimarchi
@ 2019-07-29 13:22 ` Miquel Raynal
2019-07-29 20:00 ` Michael Nazzareno Trimarchi
0 siblings, 1 reply; 39+ messages in thread
From: Miquel Raynal @ 2019-07-29 13:22 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi
Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon
Hi Michael,
Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
Mon, 29 Jul 2019 15:00:04 +0200:
> Hi Miquel
>
> On Mon, Jul 29, 2019 at 2:55 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Michael,
> >
> > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > Mon, 29 Jul 2019 14:49:19 +0200:
> >
> > > Hi Miguel
> > >
> > > On Mon, Jul 29, 2019 at 2:47 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi Greg,
> > > >
> > > > + Boris
> > > >
> > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> > > >
> > > > > Hi Miquel,
> > > > >
> > > > > On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > One question below.
> > > > > >
> > > > > > +Michael
> > > > > > +Sascha
> > > > > >
> > > > > > Hello Michael, here is a similar issue to yours, I know you did not
> > > > > > have enough time to share your solution but here we have someone else
> > > > > > reproducing the issue, would you mind sharing a branch or a patch, even
> > > > > > a WIP one, just to help debugging?
> > > > > >
> > > > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > > > > >
> > > > > >> Hi Miquel,
> > > > > >>
> > > > > >> I am experiencing a problem with NAND flash DMA timeouts on
> > > > > >> iMX6ull based boards. The problem is very similar to that
> > > > > >> described in:
> > > > > >>
> > > > > >> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > > > > >>
> > > > > >> That didn't come to any specific resolution that I could see
> > > > > >> in that thread.
> > > > > >>
> > > > > >> The boot trace on the console for me looks like this:
> > > > > >>
> > > > > >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > > > >> nand: Micron MT29F2G08ABAEAWP
> > > > > >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > > > >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > > > >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > > > >> GF length : 13
> > > > > >> ECC Strength : 8
> > > > > >> Page Size in Bytes : 2110
> > > > > >> Metadata Size in Bytes : 10
> > > > > >> ECC Chunk0 Size in Bytes: 512
> > > > > >> ECC Chunkn Size in Bytes: 512
> > > > > >> ECC Chunk Count : 4
> > > > > >> Payload Size in Bytes : 2048
> > > > > >> Auxiliary Size in Bytes: 16
> > > > > >> Auxiliary Status Offset: 12
> > > > > >> Block Mark Byte Offset : 1999
> > > > > >> Block Mark Bit Offset : 0
> > > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > > > > >> nand: timing mode 5 not acknowledged by the NAND chip
> > > > > >
> > > > > > What is the final timing mode used? Most of us tested in mode 5 I
> > > > > > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > > > > > neither why mode 5 is refused). Can you please try by limiting the mode
> > > > > > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> > > > >
> > > > > Sure, how to do that?
> > > >
> > > > This loop [1] tries to configure each mode (5, 4, ...) until one
> > > > succeeds (default is 0: must always work). Please try to limit mode to
> > > > 0, 1, etc.
> > > >
> > > > Mode 0 should work.
> > > >
> > >
> > > This is not correct. When all the mode fail it fallback to 0 that does
> > > not work. Already check
> > > So the fallback is created for this situation
> >
> > Sorry but I don't understand what you are saying.
> >
>
> I said that where a timing mode is not ackolege then the mtd stack should
> send a reset command and fallback to timeing mode 0. The nand does not
> respond anymore.
It depends on what you define by "not acknowledged". What you describe
is the current situation: if either the NAND controller or the NAND
chip do not support the mode requested by the core, the core will try
another (slower) mode until either we found one or we are at timing
mode 0.
Unfortunately, we cannot check that "all operation with these timings
will work" at boot time, it would be very time consuming; especially
for something that is very likely to be a controller driver issue, and
that is what happens here: both the controller and the chip acknowledge
the new timings.
>
> > Are you telling me that you already tried mode 0 and that it did not
> > work better than other timings?
> >
>
> I force only to use different mode but never try mode 0 ;) just
> because should be
> the normal fallback
Unless there is a timing calculation issue in the controller driver.
Greg, can you please find the quickest working mode (starting from 0,
of course, to ensure mode 0 is stable).
[...]
> > > > > >
> > > > > > That's strange... I don't get what would produce such unstable issue.
> > > > >
> > > > > My initial guess is that the calculated timing is very marginal.
> > > >
> > > > What do you mean by "marginal"?
> > > >
> > >
> > > I don't think that is timing calculation. I have tried to use the same timing
> > > as before but when those are applide. Is it possible?
> >
> > ^
> > I suppose the end of the sentence is missing?
Michael, what did you mean here?
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 13:22 ` Miquel Raynal
@ 2019-07-29 20:00 ` Michael Nazzareno Trimarchi
2019-07-29 21:02 ` Miquel Raynal
0 siblings, 1 reply; 39+ messages in thread
From: Michael Nazzareno Trimarchi @ 2019-07-29 20:00 UTC (permalink / raw)
To: Miquel Raynal; +Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon
Hi Miquel
sorry was difficult day ;). My answer below
On Mon, Jul 29, 2019 at 3:22 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Michael,
>
> Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> Mon, 29 Jul 2019 15:00:04 +0200:
>
> > Hi Miquel
> >
> > On Mon, Jul 29, 2019 at 2:55 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Michael,
> > >
> > > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > > Mon, 29 Jul 2019 14:49:19 +0200:
> > >
> > > > Hi Miguel
> > > >
> > > > On Mon, Jul 29, 2019 at 2:47 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Hi Greg,
> > > > >
> > > > > + Boris
> > > > >
> > > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> > > > >
> > > > > > Hi Miquel,
> > > > > >
> > > > > > On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > > > > > > Hi Greg,
> > > > > > >
> > > > > > > One question below.
> > > > > > >
> > > > > > > +Michael
> > > > > > > +Sascha
> > > > > > >
> > > > > > > Hello Michael, here is a similar issue to yours, I know you did not
> > > > > > > have enough time to share your solution but here we have someone else
> > > > > > > reproducing the issue, would you mind sharing a branch or a patch, even
> > > > > > > a WIP one, just to help debugging?
> > > > > > >
> > > > > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > > > > > >
> > > > > > >> Hi Miquel,
> > > > > > >>
> > > > > > >> I am experiencing a problem with NAND flash DMA timeouts on
> > > > > > >> iMX6ull based boards. The problem is very similar to that
> > > > > > >> described in:
> > > > > > >>
> > > > > > >> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > > > > > >>
> > > > > > >> That didn't come to any specific resolution that I could see
> > > > > > >> in that thread.
> > > > > > >>
> > > > > > >> The boot trace on the console for me looks like this:
> > > > > > >>
> > > > > > >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > > > > >> nand: Micron MT29F2G08ABAEAWP
> > > > > > >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > > >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > > > > >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > > > > >> GF length : 13
> > > > > > >> ECC Strength : 8
> > > > > > >> Page Size in Bytes : 2110
> > > > > > >> Metadata Size in Bytes : 10
> > > > > > >> ECC Chunk0 Size in Bytes: 512
> > > > > > >> ECC Chunkn Size in Bytes: 512
> > > > > > >> ECC Chunk Count : 4
> > > > > > >> Payload Size in Bytes : 2048
> > > > > > >> Auxiliary Size in Bytes: 16
> > > > > > >> Auxiliary Status Offset: 12
> > > > > > >> Block Mark Byte Offset : 1999
> > > > > > >> Block Mark Bit Offset : 0
> > > > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > > > > > >> nand: timing mode 5 not acknowledged by the NAND chip
> > > > > > >
> > > > > > > What is the final timing mode used? Most of us tested in mode 5 I
> > > > > > > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > > > > > > neither why mode 5 is refused). Can you please try by limiting the mode
> > > > > > > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> > > > > >
> > > > > > Sure, how to do that?
> > > > >
> > > > > This loop [1] tries to configure each mode (5, 4, ...) until one
> > > > > succeeds (default is 0: must always work). Please try to limit mode to
> > > > > 0, 1, etc.
> > > > >
> > > > > Mode 0 should work.
> > > > >
> > > >
> > > > This is not correct. When all the mode fail it fallback to 0 that does
> > > > not work. Already check
> > > > So the fallback is created for this situation
> > >
> > > Sorry but I don't understand what you are saying.
> > >
> >
> > I said that where a timing mode is not ackolege then the mtd stack should
> > send a reset command and fallback to timeing mode 0. The nand does not
> > respond anymore.
>
> It depends on what you define by "not acknowledged". What you describe
> is the current situation: if either the NAND controller or the NAND
> chip do not support the mode requested by the core, the core will try
> another (slower) mode until either we found one or we are at timing
> mode 0.
>
> Unfortunately, we cannot check that "all operation with these timings
> will work" at boot time, it would be very time consuming; especially
> for something that is very likely to be a controller driver issue, and
> that is what happens here: both the controller and the chip acknowledge
> the new timings.
>
> >
> > > Are you telling me that you already tried mode 0 and that it did not
> > > work better than other timings?
> > >
> >
> > I force only to use different mode but never try mode 0 ;) just
> > because should be
> > the normal fallback
>
> Unless there is a timing calculation issue in the controller driver.
> Greg, can you please find the quickest working mode (starting from 0,
> of course, to ensure mode 0 is stable).
>
> [...]
>
> > > > > > >
> > > > > > > That's strange... I don't get what would produce such unstable issue.
> > > > > >
> > > > > > My initial guess is that the calculated timing is very marginal.
> > > > >
> > > > > What do you mean by "marginal"?
> > > > >
> > > >
> > > > I don't think that is timing calculation. I have tried to use the same timing
> > > > as before but when those are applide. Is it possible?
> > >
> > > ^
> > > I suppose the end of the sentence is missing?
>
> Michael, what did you mean here?
>
commit 02c786627b93b3c3286570f793294816286ff397
Author: Michael Trimarchi <michael@amarulasolutions.com>
Date: Fri Oct 5 09:46:29 2018 +0200
Revert "mtd: rawnand: gpmi: use core timings instead of an
empirical derivation"
This reverts commit b1206122069aadabe1a8c50789277a978aaa4df7.
Change-Id: Icd0ddcd5e3ac7d82932bbf412299cca424cbc571
Jira-Id: WAN-50
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Revert this one does not fix the problem. Right now I have two revert
this one and
commit 6ab543c1924f77957004994bd6806a9daa45f903 (tag: MMI_004_011_R02)
Author: Michael Trimarchi <michael@amarulasolutions.com>
Date: Fri Oct 5 09:46:44 2018 +0200
Revert "mtd: rawnand: gpmi: support ->setup_data_interface()"
This reverts commit 76e1a0086a0c3276b384f77905345e0fcc886fdd.
Change-Id: I60fb6f874364d1deeda3424d4508553a38ac9b1a
Jira-Id: WAN-50
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
I did not have time to finish to undestand why this was fixing my problem
Michael
>
> Thanks,
> Miquèl
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 20:00 ` Michael Nazzareno Trimarchi
@ 2019-07-29 21:02 ` Miquel Raynal
0 siblings, 0 replies; 39+ messages in thread
From: Miquel Raynal @ 2019-07-29 21:02 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi
Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon
Hi Michael,
Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
Mon, 29 Jul 2019 22:00:25 +0200:
> Hi Miquel
>
> sorry was difficult day ;). My answer below
>
No pb ;)
[...]
> > > > > > > > That's strange... I don't get what would produce
such unstable issue.
> > > > > > >
> > > > > > > My initial guess is that the calculated timing is very marginal.
> > > > > >
> > > > > > What do you mean by "marginal"?
> > > > > >
> > > > >
> > > > > I don't think that is timing calculation. I have tried to use the same timing
> > > > > as before but when those are applide. Is it possible?
> > > >
> > > > ^
> > > > I suppose the end of the sentence is missing?
> >
> > Michael, what did you mean here?
> >
> commit 02c786627b93b3c3286570f793294816286ff397
> Author: Michael Trimarchi <michael@amarulasolutions.com>
> Date: Fri Oct 5 09:46:29 2018 +0200
>
> Revert "mtd: rawnand: gpmi: use core timings instead of an
> empirical derivation"
>
> This reverts commit b1206122069aadabe1a8c50789277a978aaa4df7.
>
> Change-Id: Icd0ddcd5e3ac7d82932bbf412299cca424cbc571
> Jira-Id: WAN-50
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
>
> Revert this one does not fix the problem. Right now I have two revert
> this one and
>
> commit 6ab543c1924f77957004994bd6806a9daa45f903 (tag: MMI_004_011_R02)
> Author: Michael Trimarchi <michael@amarulasolutions.com>
> Date: Fri Oct 5 09:46:44 2018 +0200
>
> Revert "mtd: rawnand: gpmi: support ->setup_data_interface()"
>
> This reverts commit 76e1a0086a0c3276b384f77905345e0fcc886fdd.
>
> Change-Id: I60fb6f874364d1deeda3424d4508553a38ac9b1a
> Jira-Id: WAN-50
> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
>
> I did not have time to finish to undestand why this was fixing my problem
Ok so I am pretty convinced that this is still a timings issue then;
but not entirely due to the different timings calculation. Interesting.
I'm waiting for Greg's results now.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-29 12:47 ` Miquel Raynal
2019-07-29 12:49 ` Michael Nazzareno Trimarchi
@ 2019-07-30 0:28 ` Greg Ungerer
2019-07-30 0:41 ` Greg Ungerer
1 sibling, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-07-30 0:28 UTC (permalink / raw)
To: Miquel Raynal
Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd, Boris Brezillon
Hi Miquel,
On 29/7/19 10:47 pm, Miquel Raynal wrote:
> Hi Greg,
>
> + Boris
>
> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>
>> Hi Miquel,
>>
>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>> Hi Greg,
>>>
>>> One question below.
>>>
>>> +Michael
>>> +Sascha
>>>
>>> Hello Michael, here is a similar issue to yours, I know you did not
>>> have enough time to share your solution but here we have someone else
>>> reproducing the issue, would you mind sharing a branch or a patch, even
>>> a WIP one, just to help debugging?
>>>
>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>
>>>> Hi Miquel,
>>>>
>>>> I am experiencing a problem with NAND flash DMA timeouts on
>>>> iMX6ull based boards. The problem is very similar to that
>>>> described in:
>>>>
>>>> https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
>>>>
>>>> That didn't come to any specific resolution that I could see
>>>> in that thread.
>>>>
>>>> The boot trace on the console for me looks like this:
>>>>
>>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>>>> nand: Micron MT29F2G08ABAEAWP
>>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>>> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
>>>> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
>>>> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
>>>> GF length : 13
>>>> ECC Strength : 8
>>>> Page Size in Bytes : 2110
>>>> Metadata Size in Bytes : 10
>>>> ECC Chunk0 Size in Bytes: 512
>>>> ECC Chunkn Size in Bytes: 512
>>>> ECC Chunk Count : 4
>>>> Payload Size in Bytes : 2048
>>>> Auxiliary Size in Bytes: 16
>>>> Auxiliary Status Offset: 12
>>>> Block Mark Byte Offset : 1999
>>>> Block Mark Bit Offset : 0
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
>>>> nand: timing mode 5 not acknowledged by the NAND chip
>>>
>>> What is the final timing mode used? Most of us tested in mode 5 I
>>> guess, maybe mode 4 is broken (don't know if this is the one used here,
>>> neither why mode 5 is refused). Can you please try by limiting the mode
>>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>>
>> Sure, how to do that?
>
> This loop [1] tries to configure each mode (5, 4, ...) until one
> succeeds (default is 0: must always work). Please try to limit mode to
> 0, 1, etc.
>
> Mode 0 should work.
>
> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
The normal behavior - which usually works - has
chip->onfi_timing_mode_default=5 here. So in other words on the first pass
through this loop it is checking mode 5, and setting it as the default.
I am running a test/reboot loop now waiting for failure to see
if it is still using mode 5 in that case.
Regards
Greg
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> Scanning device for bad blocks
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> ....
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>>>> Creating 5 MTD partitions on "gpmi-nand":
>>>> 0x000000000000-0x000000500000 : "u-boot"
>>>> 0x000000500000-0x000000600000 : "u-boot-env"
>>>> 0x000000600000-0x000000800000 : "log"
>>>> 0x000000800000-0x000010000000 : "flash"
>>>> 0x000000000000-0x000010000000 : "all"
>>>> gpmi-nand 1806000.gpmi-nand: driver registered.
>>>>
>>>>
>>>> This is using a linux kernel v5.1.14. I have seen this happen on
>>>> a number of boards I have here - but it is only occasional. It
>>>> only happens once in a while on boot, maybe 1 in 40 or more times.
>>>> So it can take quite a while to reproduce (using a boot loop setup).
>>>
>>> That's strange... I don't get what would produce such unstable issue.
>>
>> My initial guess is that the calculated timing is very marginal.
>
> What do you mean by "marginal"?
>
>> The problem seems more likely to happen if flash write activity
>> had been occurring just before a soft reboot. Its not a guarantee,
>> just more likely.
>
> That's really disturbing. I doubt this is the real cause though.
>
>>
>> Interesting observation is that Michael was using Micron flash,
>> and boards that I have with the problem also have Micron flash.
>> Both a form of Micron MT29F2G08.
>>
>> I have similar boards, iMX6ull based, with different brands of
>> NAND flash and I have not seen any problem on them.
>
> That's great to narrow down the root cause. Maybe these chips have
> tighter timing constraints.
>
>>
>> Regards
>> Greg
>>
>>
>>
>>>> As per the email thread I pointed to above I looked at reverting
>>>> those patches, but that was not at all easy given how much the gpmi
>>>> driver code had moved. So instead I modified the code with this:
>>>>
>>>> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>>>> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>>>> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>>>> void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>> {
>>>> +#if 0
>>>> struct gpmi_nfc_hardware_timing *hw = &this->hw;
>>>> struct resources *r = &this->resources;
>>>> void __iomem *gpmi_regs = r->gpmi_regs;
>>>> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>> /* Wait for the DLL to settle. */
>>>> udelay(dll_wait_time_us);
>>>> +#endif
>>>> }
>>>> int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>
>>>> So far after a couple of days of testing with this I no longer
>>>> see the DMA timeout.
>>>>
>>>> Any thoughts?
>>>>
>>>> Regards
>>>> Greg
>>>>
>>>
>>> Thanks,
>>> Miquèl
>>>
>
> Thanks,
> Miquèl
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-30 0:28 ` Greg Ungerer
@ 2019-07-30 0:41 ` Greg Ungerer
2019-07-30 6:06 ` Greg Ungerer
0 siblings, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-07-30 0:41 UTC (permalink / raw)
To: Miquel Raynal
Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd, Boris Brezillon
Hi Miquel,
On 30/7/19 10:28 am, Greg Ungerer wrote:
> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
[snip]
>>>>> nand: timing mode 5 not acknowledged by the NAND chip
>>>>
>>>> What is the final timing mode used? Most of us tested in mode 5 I
>>>> guess, maybe mode 4 is broken (don't know if this is the one used here,
>>>> neither why mode 5 is refused). Can you please try by limiting the mode
>>>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>>>
>>> Sure, how to do that?
>>
>> This loop [1] tries to configure each mode (5, 4, ...) until one
>> succeeds (default is 0: must always work). Please try to limit mode to
>> 0, 1, etc.
>>
>> Mode 0 should work.
>>
>> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
>
> The normal behavior - which usually works - has
> chip->onfi_timing_mode_default=5 here. So in other words on the first pass
> through this loop it is checking mode 5, and setting it as the default.
>
> I am running a test/reboot loop now waiting for failure to see
> if it is still using mode 5 in that case.
With this trace in place:
--- a/linux/drivers/mtd/nand/raw/nand_base.c
+++ b/linux/drivers/mtd/nand/raw/nand_base.c
@@ -910,6 +910,7 @@ static int nand_init_data_interface(struct nand_chip *chip)
}
for (mode = fls(modes) - 1; mode >= 0; mode--) {
+ printk("%s(%d): checking mode=%d\n", __FILE__, __LINE__, mode);
ret = onfi_fill_data_interface(chip, NAND_SDR_IFACE, mode);
if (ret)
continue;
@@ -923,10 +924,12 @@ static int nand_init_data_interface(struct nand_chip *chip)
&chip->data_interface);
if (!ret) {
chip->onfi_timing_mode_default = mode;
+ printk("%s(%d): BREAKING AT mode=%d\n", __FILE__, __LINE__, mode);
break;
}
}
+ printk("%s(%d): chip->onfi_timing_mode_default=%d\n", __FILE__, __LINE__, chip->onfi_timing_mode_default);
return 0;
}
First NAND failure gives this:
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000100
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
gpmi-nand 1806000.gpmi-nand: Show BCH registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
gpmi-nand 1806000.gpmi-nand: BCH Geometry :
GF length : 13
ECC Strength : 8
Page Size in Bytes : 2110
Metadata Size in Bytes : 10
ECC Chunk0 Size in Bytes: 512
ECC Chunkn Size in Bytes: 512
ECC Chunk Count : 4
Payload Size in Bytes : 2048
Auxiliary Size in Bytes: 16
Auxiliary Status Offset: 12
Block Mark Byte Offset : 1999
Block Mark Bit Offset : 0
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
nand: timing mode 5 not acknowledged by the NAND chip
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
Regards
Greg
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-30 0:41 ` Greg Ungerer
@ 2019-07-30 6:06 ` Greg Ungerer
2019-07-30 8:38 ` Miquel Raynal
0 siblings, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-07-30 6:06 UTC (permalink / raw)
To: Miquel Raynal
Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd, Boris Brezillon
Hi Miquel,
On 30/7/19 10:41 am, Greg Ungerer wrote:
> On 30/7/19 10:28 am, Greg Ungerer wrote:
>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> [snip]
>>>>>> nand: timing mode 5 not acknowledged by the NAND chip
>>>>>
>>>>> What is the final timing mode used? Most of us tested in mode 5 I
>>>>> guess, maybe mode 4 is broken (don't know if this is the one used here,
>>>>> neither why mode 5 is refused). Can you please try by limiting the mode
>>>>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>>>>
>>>> Sure, how to do that?
>>>
>>> This loop [1] tries to configure each mode (5, 4, ...) until one
>>> succeeds (default is 0: must always work). Please try to limit mode to
>>> 0, 1, etc.
>>>
>>> Mode 0 should work.
>>>
>>> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
>>
>> The normal behavior - which usually works - has
>> chip->onfi_timing_mode_default=5 here. So in other words on the first pass
>> through this loop it is checking mode 5, and setting it as the default.
>>
>> I am running a test/reboot loop now waiting for failure to see
>> if it is still using mode 5 in that case.
>
> With this trace in place:
>
> --- a/linux/drivers/mtd/nand/raw/nand_base.c
> +++ b/linux/drivers/mtd/nand/raw/nand_base.c
> @@ -910,6 +910,7 @@ static int nand_init_data_interface(struct nand_chip *chip)
> }
>
> for (mode = fls(modes) - 1; mode >= 0; mode--) {
> + printk("%s(%d): checking mode=%d\n", __FILE__, __LINE__, mode);
> ret = onfi_fill_data_interface(chip, NAND_SDR_IFACE, mode);
> if (ret)
> continue;
> @@ -923,10 +924,12 @@ static int nand_init_data_interface(struct nand_chip *chip)
> &chip->data_interface);
> if (!ret) {
> chip->onfi_timing_mode_default = mode;
> + printk("%s(%d): BREAKING AT mode=%d\n", __FILE__, __LINE__, mode);
> break;
> }
> }
>
> + printk("%s(%d): chip->onfi_timing_mode_default=%d\n", __FILE__, __LINE__, chip->onfi_timing_mode_default);
> return 0;
> }
>
>
> First NAND failure gives this:
>
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
> drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
> drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000100
> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> GF length : 13
> ECC Strength : 8
> Page Size in Bytes : 2110
> Metadata Size in Bytes : 10
> ECC Chunk0 Size in Bytes: 512
> ECC Chunkn Size in Bytes: 512
> ECC Chunk Count : 4
> Payload Size in Bytes : 2048
> Auxiliary Size in Bytes: 16
> Auxiliary Status Offset: 12
> Block Mark Byte Offset : 1999
> Block Mark Bit Offset : 0
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> nand: timing mode 5 not acknowledged by the NAND chip
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
Not sure if this is a useful data point... But I modified that
nand_init_data_interface() loop to start checking from data mode 4.
So now on every boot it defaults to mode 4. That has been running
most of the day, up to 900 boot cycles now, no failures.
Regards
Greg
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-30 6:06 ` Greg Ungerer
@ 2019-07-30 8:38 ` Miquel Raynal
2019-07-30 8:58 ` Boris Brezillon
2019-07-31 2:05 ` Greg Ungerer
0 siblings, 2 replies; 39+ messages in thread
From: Miquel Raynal @ 2019-07-30 8:38 UTC (permalink / raw)
To: Greg Ungerer
Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd, Boris Brezillon
Hi Greg,
Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> Hi Miquel,
>
> On 30/7/19 10:41 am, Greg Ungerer wrote:
> > On 30/7/19 10:28 am, Greg Ungerer wrote:
> >> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> >>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> >>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > [snip]
> >>>>>> nand: timing mode 5 not acknowledged by the NAND chip
> >>>>>
> >>>>> What is the final timing mode used? Most of us tested in mode 5 I
> >>>>> guess, maybe mode 4 is broken (don't know if this is the one used here,
> >>>>> neither why mode 5 is refused). Can you please try by limiting the mode
> >>>>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> >>>>
> >>>> Sure, how to do that?
> >>>
> >>> This loop [1] tries to configure each mode (5, 4, ...) until one
> >>> succeeds (default is 0: must always work). Please try to limit mode to
> >>> 0, 1, etc.
> >>>
> >>> Mode 0 should work.
> >>>
> >>> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
> >>
> >> The normal behavior - which usually works - has
> >> chip->onfi_timing_mode_default=5 here. So in other words on the first pass
> >> through this loop it is checking mode 5, and setting it as the default.
> >>
> >> I am running a test/reboot loop now waiting for failure to see
> >> if it is still using mode 5 in that case.
> >
> > With this trace in place:
> >
> > --- a/linux/drivers/mtd/nand/raw/nand_base.c
> > +++ b/linux/drivers/mtd/nand/raw/nand_base.c
> > @@ -910,6 +910,7 @@ static int nand_init_data_interface(struct nand_chip *chip)
> > }
> >
> > for (mode = fls(modes) - 1; mode >= 0; mode--) {
> > + printk("%s(%d): checking mode=%d\n", __FILE__, __LINE__, mode);
> > ret = onfi_fill_data_interface(chip, NAND_SDR_IFACE, mode);
> > if (ret)
> > continue;
> > @@ -923,10 +924,12 @@ static int nand_init_data_interface(struct nand_chip *chip)
> > &chip->data_interface);
> > if (!ret) {
> > chip->onfi_timing_mode_default = mode;
> > + printk("%s(%d): BREAKING AT mode=%d\n", __FILE__, __LINE__, mode);
> > break;
> > }
> > }
> >
> > + printk("%s(%d): chip->onfi_timing_mode_default=%d\n", __FILE__, __LINE__, chip->onfi_timing_mode_default);
> > return 0;
> > }
> >
> >
> > First NAND failure gives this:
> >
> > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > nand: Micron MT29F2G08ABAEAWP
> > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> > drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
> > drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
> > drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
> > gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000100
> > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > GF length : 13
> > ECC Strength : 8
> > Page Size in Bytes : 2110
> > Metadata Size in Bytes : 10
> > ECC Chunk0 Size in Bytes: 512
> > ECC Chunkn Size in Bytes: 512
> > ECC Chunk Count : 4
> > Payload Size in Bytes : 2048
> > Auxiliary Size in Bytes: 16
> > Auxiliary Status Offset: 12
> > Block Mark Byte Offset : 1999
> > Block Mark Bit Offset : 0
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > nand: timing mode 5 not acknowledged by the NAND chip
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>
> Not sure if this is a useful data point... But I modified that
> nand_init_data_interface() loop to start checking from data mode 4.
> So now on every boot it defaults to mode 4. That has been running
> most of the day, up to 900 boot cycles now, no failures.
Ok so after having chatted quite a bit with Boris, it is very likely
that, for these chips, the timings in mode 5 are too tight. It could
fail the GET_FEATURES once in mode 5. Can you please dump every single
intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
use of half pêriods, tRP, sample delay, etc) as well as the content
of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
enabled and mounted).
Also, can you be sure that the NAND chip is powered with 3.3V?
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-30 8:38 ` Miquel Raynal
@ 2019-07-30 8:58 ` Boris Brezillon
2019-07-31 2:05 ` Greg Ungerer
1 sibling, 0 replies; 39+ messages in thread
From: Boris Brezillon @ 2019-07-30 8:58 UTC (permalink / raw)
To: Miquel Raynal
Cc: s.hauer, Greg Ungerer, linux-mtd, Michael Nazzareno Trimarchi,
Boris Brezillon
On Tue, 30 Jul 2019 10:38:22 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Hi Greg,
>
> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>
> > Hi Miquel,
> >
> > On 30/7/19 10:41 am, Greg Ungerer wrote:
> > > On 30/7/19 10:28 am, Greg Ungerer wrote:
> > >> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> > >>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> > >>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > >>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > > [snip]
> > >>>>>> nand: timing mode 5 not acknowledged by the NAND chip
> > >>>>>
> > >>>>> What is the final timing mode used? Most of us tested in mode 5 I
> > >>>>> guess, maybe mode 4 is broken (don't know if this is the one used here,
> > >>>>> neither why mode 5 is refused). Can you please try by limiting the mode
> > >>>>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> > >>>>
> > >>>> Sure, how to do that?
> > >>>
> > >>> This loop [1] tries to configure each mode (5, 4, ...) until one
> > >>> succeeds (default is 0: must always work). Please try to limit mode to
> > >>> 0, 1, etc.
> > >>>
> > >>> Mode 0 should work.
> > >>>
> > >>> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
> > >>
> > >> The normal behavior - which usually works - has
> > >> chip->onfi_timing_mode_default=5 here. So in other words on the first pass
> > >> through this loop it is checking mode 5, and setting it as the default.
> > >>
> > >> I am running a test/reboot loop now waiting for failure to see
> > >> if it is still using mode 5 in that case.
> > >
> > > With this trace in place:
> > >
> > > --- a/linux/drivers/mtd/nand/raw/nand_base.c
> > > +++ b/linux/drivers/mtd/nand/raw/nand_base.c
> > > @@ -910,6 +910,7 @@ static int nand_init_data_interface(struct nand_chip *chip)
> > > }
> > >
> > > for (mode = fls(modes) - 1; mode >= 0; mode--) {
> > > + printk("%s(%d): checking mode=%d\n", __FILE__, __LINE__, mode);
> > > ret = onfi_fill_data_interface(chip, NAND_SDR_IFACE, mode);
> > > if (ret)
> > > continue;
> > > @@ -923,10 +924,12 @@ static int nand_init_data_interface(struct nand_chip *chip)
> > > &chip->data_interface);
> > > if (!ret) {
> > > chip->onfi_timing_mode_default = mode;
> > > + printk("%s(%d): BREAKING AT mode=%d\n", __FILE__, __LINE__, mode);
> > > break;
> > > }
> > > }
> > >
> > > + printk("%s(%d): chip->onfi_timing_mode_default=%d\n", __FILE__, __LINE__, chip->onfi_timing_mode_default);
> > > return 0;
> > > }
> > >
> > >
> > > First NAND failure gives this:
> > >
> > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > nand: Micron MT29F2G08ABAEAWP
> > > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> > > drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
> > > drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
> > > drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
> > > gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000100
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > GF length : 13
> > > ECC Strength : 8
> > > Page Size in Bytes : 2110
> > > Metadata Size in Bytes : 10
> > > ECC Chunk0 Size in Bytes: 512
> > > ECC Chunkn Size in Bytes: 512
> > > ECC Chunk Count : 4
> > > Payload Size in Bytes : 2048
> > > Auxiliary Size in Bytes: 16
> > > Auxiliary Status Offset: 12
> > > Block Mark Byte Offset : 1999
> > > Block Mark Bit Offset : 0
> > > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > > nand: timing mode 5 not acknowledged by the NAND chip
> > > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >
> > Not sure if this is a useful data point... But I modified that
> > nand_init_data_interface() loop to start checking from data mode 4.
> > So now on every boot it defaults to mode 4. That has been running
> > most of the day, up to 900 boot cycles now, no failures.
>
> Ok so after having chatted quite a bit with Boris, it is very likely
> that, for these chips, the timings in mode 5 are too tight. It could
> fail the GET_FEATURES once in mode 5. Can you please dump every single
> intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
> use of half pêriods, tRP, sample delay, etc) as well as the content
> of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
> enabled and mounted).
Not sure the clk will stay at the rate it was set during the timing
selection. Can you also add a trace printing the result of
clk_get_rate(r->clock[0], hw->clk_rate) here [1]?
[1]https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c#L711
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-30 8:38 ` Miquel Raynal
2019-07-30 8:58 ` Boris Brezillon
@ 2019-07-31 2:05 ` Greg Ungerer
2019-07-31 6:28 ` Boris Brezillon
1 sibling, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-07-31 2:05 UTC (permalink / raw)
To: Miquel Raynal, Boris Brezillon
Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd
[-- Attachment #1: Type: text/plain, Size: 29834 bytes --]
Hi Miquel, Boris,
On 30/7/19 6:38 pm, Miquel Raynal wrote:
> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>> [snip]
>> Not sure if this is a useful data point... But I modified that
>> nand_init_data_interface() loop to start checking from data mode 4.
>> So now on every boot it defaults to mode 4. That has been running
>> most of the day, up to 900 boot cycles now, no failures.
>
> Ok so after having chatted quite a bit with Boris, it is very likely
> that, for these chips, the timings in mode 5 are too tight. It could
> fail the GET_FEATURES once in mode 5. Can you please dump every single
> intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
> use of half pêriods, tRP, sample delay, etc) as well as the content
> of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
> enabled and mounted).
>
> Also, can you be sure that the NAND chip is powered with 3.3V?
Yes, 3.3V NAND chip.
Using the attached patch I get the following trace:
...
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
sdr->tBERS_max=65535000000
sdr->tCCS_min=500000000
sdr->tPROG_max=65535000000
sdr->tR_max=200000000000000
sdr->tALH_min=20000
sdr->tADL_min=400000
sdr->tALS_min=50000
sdr->tAR_min=25000
sdr->tCEA_max=100000
sdr->tCEH_min=20000
sdr->tCH_min=20000
sdr->tCHZ_max=100000
sdr->tCLH_min=20000
sdr->tCLR_min=20000
sdr->tCLS_min=50000
sdr->tCOH_min=0
sdr->tCS_min=70000
sdr->tDH_min=20000
sdr->tDS_min=40000
sdr->tFEAT_max=1000000
sdr->tIR_min=10000
sdr->tITC_max=1000000
sdr->tRC_min=100000
sdr->tREA_max=40000
sdr->tREH_min=30000
sdr->tRHOH_min=0
sdr->tRHW_min=200000
sdr->tRHZ_max=200000
sdr->tRLOH_min=0
sdr->tRP_min=50000
sdr->tRR_min=40000
sdr->tRST_max=250000000000
sdr->tWB_max=200000
sdr->tWC_min=100000
sdr->tWH_min=30000
sdr->tWHR_min=120000
sdr->tWP_min=50000
sdr->tWW_min=100000
hw->clk_rate=22000000
wrn_dly_sel=0
period_ps=45454
addr_setup_cycles=2
data_setup_cycles=1
data_hold_cycles=1
busy_timeout_cycles=31302
hw->timing0=0x00020101
hw->timing1=0x60000000
dll_threshold_ps=12000
use_half_period=1
reference_period_ps=22727
tRP_ps=45454
sample_delay_ps=4294955664
sample_delay_factor=0
hw->ctrl1n=0x00000000
hw->ctrl1n=0x00000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
hw>clk_rate=22000000
clk_set_rate(r->clock[0], hw->clk_rate)=0
clk_get_rate(r->clock[0])=22000000
random: fast init done
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
sdr->tBERS_max=3000000000
sdr->tCCS_min=100000
sdr->tPROG_max=600000000
sdr->tR_max=25000000
sdr->tALH_min=20000
sdr->tADL_min=400000
sdr->tALS_min=50000
sdr->tAR_min=25000
sdr->tCEA_max=100000
sdr->tCEH_min=20000
sdr->tCH_min=20000
sdr->tCHZ_max=100000
sdr->tCLH_min=20000
sdr->tCLR_min=20000
sdr->tCLS_min=50000
sdr->tCOH_min=0
sdr->tCS_min=70000
sdr->tDH_min=20000
sdr->tDS_min=40000
sdr->tFEAT_max=1000000
sdr->tIR_min=10000
sdr->tITC_max=1000000
sdr->tRC_min=100000
sdr->tREA_max=40000
sdr->tREH_min=30000
sdr->tRHOH_min=0
sdr->tRHW_min=200000
sdr->tRHZ_max=200000
sdr->tRLOH_min=0
sdr->tRP_min=50000
sdr->tRR_min=40000
sdr->tRST_max=250000000000
sdr->tWB_max=200000
sdr->tWC_min=100000
sdr->tWH_min=30000
sdr->tWHR_min=120000
sdr->tWP_min=50000
sdr->tWW_min=100000
hw->clk_rate=22000000
wrn_dly_sel=0
period_ps=45454
addr_setup_cycles=2
data_setup_cycles=1
data_hold_cycles=1
busy_timeout_cycles=555
hw->timing0=0x00020101
hw->timing1=0xb0000000
dll_threshold_ps=12000
use_half_period=1
reference_period_ps=22727
tRP_ps=45454
sample_delay_ps=4294955664
sample_delay_factor=0
hw->ctrl1n=0x00000000
hw->ctrl1n=0x00000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
hw>clk_rate=22000000
clk_set_rate(r->clock[0], hw->clk_rate)=0
clk_get_rate(r->clock[0])=22000000
gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
sdr->tBERS_max=3000000000
sdr->tCCS_min=100000
sdr->tPROG_max=600000000
sdr->tR_max=25000000
sdr->tALH_min=5000
sdr->tADL_min=400000
sdr->tALS_min=10000
sdr->tAR_min=10000
sdr->tCEA_max=25000
sdr->tCEH_min=20000
sdr->tCH_min=5000
sdr->tCHZ_max=30000
sdr->tCLH_min=5000
sdr->tCLR_min=10000
sdr->tCLS_min=10000
sdr->tCOH_min=15000
sdr->tCS_min=15000
sdr->tDH_min=5000
sdr->tDS_min=7000
sdr->tFEAT_max=1000000
sdr->tIR_min=0
sdr->tITC_max=1000000
sdr->tRC_min=20000
sdr->tREA_max=16000
sdr->tREH_min=7000
sdr->tRHOH_min=15000
sdr->tRHW_min=100000
sdr->tRHZ_max=100000
sdr->tRLOH_min=5000
sdr->tRP_min=10000
sdr->tRR_min=20000
sdr->tRST_max=500000000
sdr->tWB_max=100000
sdr->tWC_min=20000
sdr->tWH_min=7000
sdr->tWHR_min=80000
sdr->tWP_min=10000
sdr->tWW_min=100000
hw->clk_rate=100000000
wrn_dly_sel=3
period_ps=10000
addr_setup_cycles=1
data_setup_cycles=1
data_hold_cycles=1
busy_timeout_cycles=2510
hw->timing0=0x00010101
hw->timing1=0xe0000000
dll_threshold_ps=12000
use_half_period=0
reference_period_ps=10000
tRP_ps=10000
sample_delay_ps=80000
sample_delay_factor=8
hw->ctrl1n=0x00c00000
hw->ctrl1n=0x00c28000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
hw>clk_rate=100000000
clk_set_rate(r->clock[0], hw->clk_rate)=0
clk_get_rate(r->clock[0])=99000000
Scanning device for bad blocks
5 fixed-partitions partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...
And "cat /sys/kernel/debug/clk/clk_summary" gives:
enable prepare protect duty
clock count count count rate accuracy phase cycle
---------------------------------------------------------------------------------------------
dummy 2 2 0 0 0 0 50000
cko2_sel 0 0 0 0 0 0 50000
cko2_podf 0 0 0 0 0 0 50000
cko2 0 0 0 0 0 0 50000
cko1_sel 0 0 0 0 0 0 50000
cko1_podf 0 0 0 0 0 0 50000
cko1 0 0 0 0 0 0 50000
cko 0 0 0 0 0 0 50000
usbphy2_gate 1 1 0 0 0 0 50000
usbphy1_gate 1 1 0 0 0 0 50000
ipp_di1 0 0 0 0 0 0 50000
ipp_di0 0 0 0 0 0 0 50000
osc 6 6 0 24000000 0 0 50000
perclk_sel 1 1 0 24000000 0 0 50000
perclk 3 3 0 24000000 0 0 50000
pwm7 0 0 0 24000000 0 0 50000
pwm6 0 0 0 24000000 0 0 50000
pwm5 0 0 0 24000000 0 0 50000
i2c4 0 0 0 24000000 0 0 50000
pwm8 0 0 0 24000000 0 0 50000
pwm4 0 0 0 24000000 0 0 50000
pwm3 0 0 0 24000000 0 0 50000
pwm2 0 0 0 24000000 0 0 50000
pwm1 0 0 0 24000000 0 0 50000
i2c3 0 0 0 24000000 0 0 50000
i2c2 1 1 0 24000000 0 0 50000
i2c1 0 0 0 24000000 0 0 50000
gpt1_serial 1 1 0 24000000 0 0 50000
gpt1_bus 1 1 0 24000000 0 0 50000
epit2 0 0 0 24000000 0 0 50000
epit1 0 0 0 24000000 0 0 50000
gpt2_serial 0 0 0 24000000 0 0 50000
gpt2_bus 0 0 0 24000000 0 0 50000
periph_clk2_sel 0 0 0 24000000 0 0 50000
periph_clk2 0 0 0 24000000 0 0 50000
gpt_3m 0 0 0 3000000 0 0 50000
csi_sel 0 0 0 24000000 0 0 50000
csi_podf 0 0 0 24000000 0 0 50000
csi 0 0 0 24000000 0 0 50000
pll7 1 1 0 480000000 0 0 50000
pll7_bypass 1 1 0 480000000 0 0 50000
pll7_usb_host 1 1 0 480000000 0 0 50000
usbphy2 1 1 0 480000000 0 0 50000
pll6 1 1 0 500000000 0 0 50000
pll6_bypass 1 1 0 500000000 0 0 50000
pll6_enet 2 2 0 500000000 0 0 50000
enet_ptp_ref 1 1 0 25000000 0 0 50000
enet_ptp 1 1 0 25000000 0 0 50000
enet2_ref 0 0 0 50000000 0 0 50000
enet_ref_125m 0 0 0 50000000 0 0 50000
enet_ref 2 2 0 50000000 0 0 50000
pll5 0 0 0 296600000 0 0 50000
pll5_bypass 0 0 0 296600000 0 0 50000
pll5_video 0 0 0 296600000 0 0 50000
pll5_post_div 0 0 0 74150000 0 0 50000
pll5_video_div 0 0 0 74150000 0 0 50000
pll4 0 0 0 147456000 0 0 50000
pll4_bypass 0 0 0 147456000 0 0 50000
pll4_audio 0 0 0 147456000 0 0 50000
pll4_post_div 0 0 0 36864000 0 0 50000
pll4_audio_div 0 0 0 36864000 0 0 50000
pll3 1 1 0 480000000 0 0 50000
pll3_bypass 1 1 0 480000000 0 0 50000
pll3_usb_otg 2 2 0 480000000 0 0 50000
spdif_sel 0 0 0 480000000 0 0 50000
spdif_pred 0 0 0 240000000 0 0 50000
spdif_podf 0 0 0 30000000 0 0 50000
spdif 0 0 0 30000000 0 0 50000
esai_sel 0 0 0 480000000 0 0 50000
esai_pred 0 0 0 240000000 0 0 50000
esai_podf 0 0 0 30000000 0 0 50000
esai_extal 0 0 0 30000000 0 0 50000
qspi1_sel 0 0 0 480000000 0 0 50000
qspi1_podf 0 0 0 240000000 0 0 50000
qspi1 0 0 0 240000000 0 0 50000
ldb_di1_div_7 0 0 0 68571428 0 0 50000
ldb_di1 0 0 0 68571428 0 0 50000
ldb_di1_div_3_5 0 0 0 137142857 0 0 50000
periph2_clk2_sel 0 0 0 480000000 0 0 50000
periph2_clk2 0 0 0 480000000 0 0 50000
pll3_60m 0 0 0 60000000 0 0 50000
can_sel 0 0 0 60000000 0 0 50000
can_podf 0 0 0 30000000 0 0 50000
can2_serial 0 0 0 30000000 0 0 50000
can1_serial 0 0 0 30000000 0 0 50000
ecspi_sel 0 0 0 60000000 0 0 50000
ecspi_podf 0 0 0 60000000 0 0 50000
ecspi4 0 0 0 60000000 0 0 50000
ecspi3 0 0 0 60000000 0 0 50000
ecspi2 0 0 0 60000000 0 0 50000
ecspi1 0 0 0 60000000 0 0 50000
pll3_80m 1 1 0 80000000 0 0 50000
uart_sel 1 1 0 80000000 0 0 50000
uart_podf 1 1 0 80000000 0 0 50000
uart8_serial 0 0 0 80000000 0 0 50000
uart7_serial 0 0 0 80000000 0 0 50000
uart1_serial 1 2 0 80000000 0 0 50000
uart6_serial 0 0 0 80000000 0 0 50000
uart5_serial 0 0 0 80000000 0 0 50000
uart4_serial 0 0 0 80000000 0 0 50000
uart3_serial 0 0 0 80000000 0 0 50000
uart2_serial 0 0 0 80000000 0 0 50000
pll3_pfd3_454m 0 0 0 454736842 0 0 50000
pll3_pfd2_508m 0 0 0 508235294 0 0 50000
epdc_pre_sel 0 0 0 508235294 0 0 50000
epdc_podf 0 0 0 254117647 0 0 50000
epdc_pix 0 0 0 254117647 0 0 50000
epdc_sel 0 0 0 254117647 0 0 50000
sai1_sel 0 0 0 508235294 0 0 50000
sai1_pred 0 0 0 127058824 0 0 50000
sai1_podf 0 0 0 63529412 0 0 50000
sai1 0 0 0 63529412 0 0 50000
sai2_sel 0 0 0 508235294 0 0 50000
sai2_pred 0 0 0 127058824 0 0 50000
sai2_podf 0 0 0 63529412 0 0 50000
sai2 0 0 0 63529412 0 0 50000
sai3_sel 0 0 0 508235294 0 0 50000
sai3_pred 0 0 0 127058824 0 0 50000
sai3_podf 0 0 0 63529412 0 0 50000
sai3 0 0 0 63529412 0 0 50000
pll3_pfd1_540m 0 0 0 540000000 0 0 50000
lcdif_pre_sel 0 0 0 540000000 0 0 50000
lcdif_pred 0 0 0 270000000 0 0 50000
lcdif_podf 0 0 0 135000000 0 0 50000
lcdif_pix 0 0 0 135000000 0 0 50000
iomuxc 0 0 0 135000000 0 0 50000
lcdif_sel 0 0 0 135000000 0 0 50000
pll3_pfd0_720m 0 0 0 720000000 0 0 50000
usbphy1 1 1 0 480000000 0 0 50000
pll2 1 1 0 528000000 0 0 50000
pll2_bypass 1 1 0 528000000 0 0 50000
pll2_bus 2 2 0 528000000 0 0 50000
ca7_secondary_sel 0 0 0 528000000 0 0 50000
step 0 0 0 528000000 0 0 50000
periph_pre 1 1 0 528000000 0 0 50000
periph 3 3 0 528000000 0 0 50000
ahb 7 7 0 132000000 0 0 50000
sdma 0 0 0 132000000 0 0 50000
rom 1 1 0 132000000 0 0 50000
esai_mem 0 0 0 132000000 0 0 50000
esai_ipg 0 0 0 132000000 0 0 50000
aips_tz3 1 1 0 132000000 0 0 50000
enet_ahb 2 2 0 132000000 0 0 50000
dcp 0 0 0 132000000 0 0 50000
asrc_mem 0 0 0 132000000 0 0 50000
asrc_ipg 0 0 0 132000000 0 0 50000
aips_tz2 1 1 0 132000000 0 0 50000
aips_tz1 1 1 0 132000000 0 0 50000
ipg 10 10 0 66000000 0 0 50000
wdog3 0 0 0 66000000 0 0 50000
uart8_ipg 0 0 0 66000000 0 0 50000
usboh3 2 2 0 66000000 0 0 50000
sai2_ipg 0 0 0 66000000 0 0 50000
sai1_ipg 0 0 0 66000000 0 0 50000
uart7_ipg 0 0 0 66000000 0 0 50000
uart1_ipg 1 2 0 66000000 0 0 50000
sai3_ipg 0 0 0 66000000 0 0 50000
spdif_gclk 0 0 0 66000000 0 0 50000
spba 0 0 0 66000000 0 0 50000
wdog2 0 0 0 66000000 0 0 50000
kpp 0 0 0 66000000 0 0 50000
mmdc_p1_ipg 0 0 0 66000000 0 0 50000
mmdc_p0_ipg 2 2 0 66000000 0 0 50000
wdog1 1 1 0 66000000 0 0 50000
gpio4 1 1 0 66000000 0 0 50000
uart6_ipg 0 0 0 66000000 0 0 50000
uart5_ipg 0 0 0 66000000 0 0 50000
gpio3 1 1 0 66000000 0 0 50000
ocotp 0 0 0 66000000 0 0 50000
gpio5 1 1 0 66000000 0 0 50000
gpio1 1 1 0 66000000 0 0 50000
uart4_ipg 0 0 0 66000000 0 0 50000
adc1 0 0 0 66000000 0 0 50000
uart3_ipg 0 0 0 66000000 0 0 50000
adc2 0 0 0 66000000 0 0 50000
gpio2 1 1 0 66000000 0 0 50000
uart2_ipg 0 0 0 66000000 0 0 50000
can2_ipg 0 0 0 66000000 0 0 50000
can1_ipg 0 0 0 66000000 0 0 50000
enet 2 2 0 66000000 0 0 50000
axi_sel 1 1 0 528000000 0 0 50000
axi_podf 2 2 0 264000000 0 0 50000
axi 1 1 0 264000000 0 0 50000
eim_slow_sel 0 0 0 264000000 0 0 50000
eim_slow_podf 0 0 0 132000000 0 0 50000
eim 0 0 0 132000000 0 0 50000
lcdif_apb 0 0 0 264000000 0 0 50000
pxp 0 0 0 264000000 0 0 50000
epdc_aclk 0 0 0 264000000 0 0 50000
pll2_pfd3_594m 0 0 0 594000000 0 0 50000
ldb_di0_sel 0 0 0 594000000 0 0 50000
ldb_di0_div_7 0 0 0 84857142 0 0 50000
ldb_di0 0 0 0 84857142 0 0 50000
ldb_di0_div_3_5 0 0 0 169714285 0 0 50000
pll2_pfd2_396m 2 2 0 396000000 0 0 50000
enfc_sel 0 0 0 396000000 0 0 50000
enfc_pred 0 0 0 99000000 0 0 50000
enfc_podf 0 0 0 99000000 0 0 50000
gpmi_io 0 0 0 99000000 0 0 50000
usdhc1_sel 0 0 0 396000000 0 0 50000
usdhc1_podf 0 0 0 198000000 0 0 50000
usdhc1 0 0 0 198000000 0 0 50000
usdhc2_sel 0 0 0 396000000 0 0 50000
usdhc2_podf 0 0 0 198000000 0 0 50000
usdhc2 0 0 0 198000000 0 0 50000
bch_sel 1 1 0 396000000 0 0 50000
bch_podf 1 1 0 99000000 0 0 50000
gpmi_apb 0 0 0 99000000 0 0 50000
gpmi_bch_apb 0 0 0 99000000 0 0 50000
per_bch 0 0 0 99000000 0 0 50000
apbh_dma 1 1 0 99000000 0 0 50000
gpmi_sel 0 0 0 396000000 0 0 50000
gpmi_podf 0 0 0 99000000 0 0 50000
gpmi_bch 0 0 0 99000000 0 0 50000
periph2_pre 1 1 0 396000000 0 0 50000
periph2 2 2 0 396000000 0 0 50000
mmdc_podf 2 2 0 396000000 0 0 50000
mmdc_p0_fast 1 1 0 396000000 0 0 50000
axi_alt_sel 0 0 0 396000000 0 0 50000
pll2_198m 0 0 0 198000000 0 0 50000
pll2_pfd1_594m 0 0 0 594000000 0 0 50000
pll2_pfd0_352m 0 0 0 352000000 0 0 50000
pll1 1 1 0 900000000 0 0 50000
pll1_bypass 1 1 0 900000000 0 0 50000
pll1_sys 1 1 0 900000000 0 0 50000
pll1_sw 1 1 0 900000000 0 0 50000
arm 1 1 0 900000000 0 0 50000
pll7_bypass_src 0 0 0 24000000 0 0 50000
pll6_bypass_src 0 0 0 24000000 0 0 50000
pll5_bypass_src 0 0 0 24000000 0 0 50000
pll4_bypass_src 0 0 0 24000000 0 0 50000
pll3_bypass_src 0 0 0 24000000 0 0 50000
pll2_bypass_src 0 0 0 24000000 0 0 50000
pll1_bypass_src 0 0 0 24000000 0 0 50000
ckil 0 0 0 32768 0 0 50000
Note that this was generated on a normal boot up (not failure).
Running boot testing now waiting for a failure.
Regards
Greg
[-- Attachment #2: imx6-nand-trace.patch --]
[-- Type: text/x-patch, Size: 6320 bytes --]
[-- Attachment #3: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-31 2:05 ` Greg Ungerer
@ 2019-07-31 6:28 ` Boris Brezillon
2019-08-02 7:19 ` Greg Ungerer
2019-08-02 12:34 ` Greg Ungerer
0 siblings, 2 replies; 39+ messages in thread
From: Boris Brezillon @ 2019-07-31 6:28 UTC (permalink / raw)
To: Greg Ungerer
Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
Miquel Raynal
On Wed, 31 Jul 2019 12:05:44 +1000
Greg Ungerer <gerg@kernel.org> wrote:
> Hi Miquel, Boris,
>
> On 30/7/19 6:38 pm, Miquel Raynal wrote:
> > Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> >> On 30/7/19 10:41 am, Greg Ungerer wrote:
> >>> On 30/7/19 10:28 am, Greg Ungerer wrote:
> >>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> >>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>> [snip]
> >> Not sure if this is a useful data point... But I modified that
> >> nand_init_data_interface() loop to start checking from data mode 4.
> >> So now on every boot it defaults to mode 4. That has been running
> >> most of the day, up to 900 boot cycles now, no failures.
> >
> > Ok so after having chatted quite a bit with Boris, it is very likely
> > that, for these chips, the timings in mode 5 are too tight. It could
> > fail the GET_FEATURES once in mode 5. Can you please dump every single
> > intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
> > use of half pêriods, tRP, sample delay, etc) as well as the content
> > of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
> > enabled and mounted).
> >
> > Also, can you be sure that the NAND chip is powered with 3.3V?
>
> Yes, 3.3V NAND chip.
>
> Using the attached patch I get the following trace:
>
> ...
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
> sdr->tBERS_max=65535000000
> sdr->tCCS_min=500000000
> sdr->tPROG_max=65535000000
> sdr->tR_max=200000000000000
> sdr->tALH_min=20000
> sdr->tADL_min=400000
> sdr->tALS_min=50000
> sdr->tAR_min=25000
> sdr->tCEA_max=100000
> sdr->tCEH_min=20000
> sdr->tCH_min=20000
> sdr->tCHZ_max=100000
> sdr->tCLH_min=20000
> sdr->tCLR_min=20000
> sdr->tCLS_min=50000
> sdr->tCOH_min=0
> sdr->tCS_min=70000
> sdr->tDH_min=20000
> sdr->tDS_min=40000
> sdr->tFEAT_max=1000000
> sdr->tIR_min=10000
> sdr->tITC_max=1000000
> sdr->tRC_min=100000
> sdr->tREA_max=40000
> sdr->tREH_min=30000
> sdr->tRHOH_min=0
> sdr->tRHW_min=200000
> sdr->tRHZ_max=200000
> sdr->tRLOH_min=0
> sdr->tRP_min=50000
> sdr->tRR_min=40000
> sdr->tRST_max=250000000000
> sdr->tWB_max=200000
> sdr->tWC_min=100000
> sdr->tWH_min=30000
> sdr->tWHR_min=120000
> sdr->tWP_min=50000
> sdr->tWW_min=100000
> hw->clk_rate=22000000
> wrn_dly_sel=0
> period_ps=45454
> addr_setup_cycles=2
> data_setup_cycles=1
> data_hold_cycles=1
> busy_timeout_cycles=31302
> hw->timing0=0x00020101
> hw->timing1=0x60000000
> dll_threshold_ps=12000
> use_half_period=1
> reference_period_ps=22727
> tRP_ps=45454
> sample_delay_ps=4294955664
> sample_delay_factor=0
> hw->ctrl1n=0x00000000
> hw->ctrl1n=0x00000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
> hw>clk_rate=22000000
> clk_set_rate(r->clock[0], hw->clk_rate)=0
> clk_get_rate(r->clock[0])=22000000
> random: fast init done
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
> sdr->tBERS_max=3000000000
> sdr->tCCS_min=100000
> sdr->tPROG_max=600000000
> sdr->tR_max=25000000
> sdr->tALH_min=20000
> sdr->tADL_min=400000
> sdr->tALS_min=50000
> sdr->tAR_min=25000
> sdr->tCEA_max=100000
> sdr->tCEH_min=20000
> sdr->tCH_min=20000
> sdr->tCHZ_max=100000
> sdr->tCLH_min=20000
> sdr->tCLR_min=20000
> sdr->tCLS_min=50000
> sdr->tCOH_min=0
> sdr->tCS_min=70000
> sdr->tDH_min=20000
> sdr->tDS_min=40000
> sdr->tFEAT_max=1000000
> sdr->tIR_min=10000
> sdr->tITC_max=1000000
> sdr->tRC_min=100000
> sdr->tREA_max=40000
> sdr->tREH_min=30000
> sdr->tRHOH_min=0
> sdr->tRHW_min=200000
> sdr->tRHZ_max=200000
> sdr->tRLOH_min=0
> sdr->tRP_min=50000
> sdr->tRR_min=40000
> sdr->tRST_max=250000000000
> sdr->tWB_max=200000
> sdr->tWC_min=100000
> sdr->tWH_min=30000
> sdr->tWHR_min=120000
> sdr->tWP_min=50000
> sdr->tWW_min=100000
> hw->clk_rate=22000000
> wrn_dly_sel=0
> period_ps=45454
> addr_setup_cycles=2
> data_setup_cycles=1
> data_hold_cycles=1
> busy_timeout_cycles=555
> hw->timing0=0x00020101
> hw->timing1=0xb0000000
> dll_threshold_ps=12000
> use_half_period=1
> reference_period_ps=22727
> tRP_ps=45454
> sample_delay_ps=4294955664
> sample_delay_factor=0
> hw->ctrl1n=0x00000000
> hw->ctrl1n=0x00000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
> hw>clk_rate=22000000
> clk_set_rate(r->clock[0], hw->clk_rate)=0
> clk_get_rate(r->clock[0])=22000000
> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
> drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
> drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
> sdr->tBERS_max=3000000000
> sdr->tCCS_min=100000
> sdr->tPROG_max=600000000
> sdr->tR_max=25000000
> sdr->tALH_min=5000
> sdr->tADL_min=400000
> sdr->tALS_min=10000
> sdr->tAR_min=10000
> sdr->tCEA_max=25000
> sdr->tCEH_min=20000
> sdr->tCH_min=5000
> sdr->tCHZ_max=30000
> sdr->tCLH_min=5000
> sdr->tCLR_min=10000
> sdr->tCLS_min=10000
> sdr->tCOH_min=15000
> sdr->tCS_min=15000
> sdr->tDH_min=5000
> sdr->tDS_min=7000
> sdr->tFEAT_max=1000000
> sdr->tIR_min=0
> sdr->tITC_max=1000000
> sdr->tRC_min=20000
> sdr->tREA_max=16000
> sdr->tREH_min=7000
> sdr->tRHOH_min=15000
> sdr->tRHW_min=100000
> sdr->tRHZ_max=100000
> sdr->tRLOH_min=5000
> sdr->tRP_min=10000
> sdr->tRR_min=20000
> sdr->tRST_max=500000000
> sdr->tWB_max=100000
> sdr->tWC_min=20000
> sdr->tWH_min=7000
> sdr->tWHR_min=80000
> sdr->tWP_min=10000
> sdr->tWW_min=100000
> hw->clk_rate=100000000
> wrn_dly_sel=3
> period_ps=10000
> addr_setup_cycles=1
> data_setup_cycles=1
> data_hold_cycles=1
> busy_timeout_cycles=2510
> hw->timing0=0x00010101
> hw->timing1=0xe0000000
> dll_threshold_ps=12000
> use_half_period=0
> reference_period_ps=10000
> tRP_ps=10000
> sample_delay_ps=80000
> sample_delay_factor=8
> hw->ctrl1n=0x00c00000
> hw->ctrl1n=0x00c28000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
> hw>clk_rate=100000000
> clk_set_rate(r->clock[0], hw->clk_rate)=0
> clk_get_rate(r->clock[0])=99000000
> Scanning device for bad blocks
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
>
>
> And "cat /sys/kernel/debug/clk/clk_summary" gives:
>
> enable prepare protect duty
> clock count count count rate accuracy phase cycle
> ---------------------------------------------------------------------------------------------
> dummy 2 2 0 0 0 0 50000
> cko2_sel 0 0 0 0 0 0 50000
> cko2_podf 0 0 0 0 0 0 50000
> cko2 0 0 0 0 0 0 50000
> cko1_sel 0 0 0 0 0 0 50000
> cko1_podf 0 0 0 0 0 0 50000
> cko1 0 0 0 0 0 0 50000
> cko 0 0 0 0 0 0 50000
> usbphy2_gate 1 1 0 0 0 0 50000
> usbphy1_gate 1 1 0 0 0 0 50000
> ipp_di1 0 0 0 0 0 0 50000
> ipp_di0 0 0 0 0 0 0 50000
> osc 6 6 0 24000000 0 0 50000
> perclk_sel 1 1 0 24000000 0 0 50000
> perclk 3 3 0 24000000 0 0 50000
> pwm7 0 0 0 24000000 0 0 50000
> pwm6 0 0 0 24000000 0 0 50000
> pwm5 0 0 0 24000000 0 0 50000
> i2c4 0 0 0 24000000 0 0 50000
> pwm8 0 0 0 24000000 0 0 50000
> pwm4 0 0 0 24000000 0 0 50000
> pwm3 0 0 0 24000000 0 0 50000
> pwm2 0 0 0 24000000 0 0 50000
> pwm1 0 0 0 24000000 0 0 50000
> i2c3 0 0 0 24000000 0 0 50000
> i2c2 1 1 0 24000000 0 0 50000
> i2c1 0 0 0 24000000 0 0 50000
> gpt1_serial 1 1 0 24000000 0 0 50000
> gpt1_bus 1 1 0 24000000 0 0 50000
> epit2 0 0 0 24000000 0 0 50000
> epit1 0 0 0 24000000 0 0 50000
> gpt2_serial 0 0 0 24000000 0 0 50000
> gpt2_bus 0 0 0 24000000 0 0 50000
> periph_clk2_sel 0 0 0 24000000 0 0 50000
> periph_clk2 0 0 0 24000000 0 0 50000
> gpt_3m 0 0 0 3000000 0 0 50000
> csi_sel 0 0 0 24000000 0 0 50000
> csi_podf 0 0 0 24000000 0 0 50000
> csi 0 0 0 24000000 0 0 50000
> pll7 1 1 0 480000000 0 0 50000
> pll7_bypass 1 1 0 480000000 0 0 50000
> pll7_usb_host 1 1 0 480000000 0 0 50000
> usbphy2 1 1 0 480000000 0 0 50000
> pll6 1 1 0 500000000 0 0 50000
> pll6_bypass 1 1 0 500000000 0 0 50000
> pll6_enet 2 2 0 500000000 0 0 50000
> enet_ptp_ref 1 1 0 25000000 0 0 50000
> enet_ptp 1 1 0 25000000 0 0 50000
> enet2_ref 0 0 0 50000000 0 0 50000
> enet_ref_125m 0 0 0 50000000 0 0 50000
> enet_ref 2 2 0 50000000 0 0 50000
> pll5 0 0 0 296600000 0 0 50000
> pll5_bypass 0 0 0 296600000 0 0 50000
> pll5_video 0 0 0 296600000 0 0 50000
> pll5_post_div 0 0 0 74150000 0 0 50000
> pll5_video_div 0 0 0 74150000 0 0 50000
> pll4 0 0 0 147456000 0 0 50000
> pll4_bypass 0 0 0 147456000 0 0 50000
> pll4_audio 0 0 0 147456000 0 0 50000
> pll4_post_div 0 0 0 36864000 0 0 50000
> pll4_audio_div 0 0 0 36864000 0 0 50000
> pll3 1 1 0 480000000 0 0 50000
> pll3_bypass 1 1 0 480000000 0 0 50000
> pll3_usb_otg 2 2 0 480000000 0 0 50000
> spdif_sel 0 0 0 480000000 0 0 50000
> spdif_pred 0 0 0 240000000 0 0 50000
> spdif_podf 0 0 0 30000000 0 0 50000
> spdif 0 0 0 30000000 0 0 50000
> esai_sel 0 0 0 480000000 0 0 50000
> esai_pred 0 0 0 240000000 0 0 50000
> esai_podf 0 0 0 30000000 0 0 50000
> esai_extal 0 0 0 30000000 0 0 50000
> qspi1_sel 0 0 0 480000000 0 0 50000
> qspi1_podf 0 0 0 240000000 0 0 50000
> qspi1 0 0 0 240000000 0 0 50000
> ldb_di1_div_7 0 0 0 68571428 0 0 50000
> ldb_di1 0 0 0 68571428 0 0 50000
> ldb_di1_div_3_5 0 0 0 137142857 0 0 50000
> periph2_clk2_sel 0 0 0 480000000 0 0 50000
> periph2_clk2 0 0 0 480000000 0 0 50000
> pll3_60m 0 0 0 60000000 0 0 50000
> can_sel 0 0 0 60000000 0 0 50000
> can_podf 0 0 0 30000000 0 0 50000
> can2_serial 0 0 0 30000000 0 0 50000
> can1_serial 0 0 0 30000000 0 0 50000
> ecspi_sel 0 0 0 60000000 0 0 50000
> ecspi_podf 0 0 0 60000000 0 0 50000
> ecspi4 0 0 0 60000000 0 0 50000
> ecspi3 0 0 0 60000000 0 0 50000
> ecspi2 0 0 0 60000000 0 0 50000
> ecspi1 0 0 0 60000000 0 0 50000
> pll3_80m 1 1 0 80000000 0 0 50000
> uart_sel 1 1 0 80000000 0 0 50000
> uart_podf 1 1 0 80000000 0 0 50000
> uart8_serial 0 0 0 80000000 0 0 50000
> uart7_serial 0 0 0 80000000 0 0 50000
> uart1_serial 1 2 0 80000000 0 0 50000
> uart6_serial 0 0 0 80000000 0 0 50000
> uart5_serial 0 0 0 80000000 0 0 50000
> uart4_serial 0 0 0 80000000 0 0 50000
> uart3_serial 0 0 0 80000000 0 0 50000
> uart2_serial 0 0 0 80000000 0 0 50000
> pll3_pfd3_454m 0 0 0 454736842 0 0 50000
> pll3_pfd2_508m 0 0 0 508235294 0 0 50000
> epdc_pre_sel 0 0 0 508235294 0 0 50000
> epdc_podf 0 0 0 254117647 0 0 50000
> epdc_pix 0 0 0 254117647 0 0 50000
> epdc_sel 0 0 0 254117647 0 0 50000
> sai1_sel 0 0 0 508235294 0 0 50000
> sai1_pred 0 0 0 127058824 0 0 50000
> sai1_podf 0 0 0 63529412 0 0 50000
> sai1 0 0 0 63529412 0 0 50000
> sai2_sel 0 0 0 508235294 0 0 50000
> sai2_pred 0 0 0 127058824 0 0 50000
> sai2_podf 0 0 0 63529412 0 0 50000
> sai2 0 0 0 63529412 0 0 50000
> sai3_sel 0 0 0 508235294 0 0 50000
> sai3_pred 0 0 0 127058824 0 0 50000
> sai3_podf 0 0 0 63529412 0 0 50000
> sai3 0 0 0 63529412 0 0 50000
> pll3_pfd1_540m 0 0 0 540000000 0 0 50000
> lcdif_pre_sel 0 0 0 540000000 0 0 50000
> lcdif_pred 0 0 0 270000000 0 0 50000
> lcdif_podf 0 0 0 135000000 0 0 50000
> lcdif_pix 0 0 0 135000000 0 0 50000
> iomuxc 0 0 0 135000000 0 0 50000
> lcdif_sel 0 0 0 135000000 0 0 50000
> pll3_pfd0_720m 0 0 0 720000000 0 0 50000
> usbphy1 1 1 0 480000000 0 0 50000
> pll2 1 1 0 528000000 0 0 50000
> pll2_bypass 1 1 0 528000000 0 0 50000
> pll2_bus 2 2 0 528000000 0 0 50000
> ca7_secondary_sel 0 0 0 528000000 0 0 50000
> step 0 0 0 528000000 0 0 50000
> periph_pre 1 1 0 528000000 0 0 50000
> periph 3 3 0 528000000 0 0 50000
> ahb 7 7 0 132000000 0 0 50000
> sdma 0 0 0 132000000 0 0 50000
> rom 1 1 0 132000000 0 0 50000
> esai_mem 0 0 0 132000000 0 0 50000
> esai_ipg 0 0 0 132000000 0 0 50000
> aips_tz3 1 1 0 132000000 0 0 50000
> enet_ahb 2 2 0 132000000 0 0 50000
> dcp 0 0 0 132000000 0 0 50000
> asrc_mem 0 0 0 132000000 0 0 50000
> asrc_ipg 0 0 0 132000000 0 0 50000
> aips_tz2 1 1 0 132000000 0 0 50000
> aips_tz1 1 1 0 132000000 0 0 50000
> ipg 10 10 0 66000000 0 0 50000
> wdog3 0 0 0 66000000 0 0 50000
> uart8_ipg 0 0 0 66000000 0 0 50000
> usboh3 2 2 0 66000000 0 0 50000
> sai2_ipg 0 0 0 66000000 0 0 50000
> sai1_ipg 0 0 0 66000000 0 0 50000
> uart7_ipg 0 0 0 66000000 0 0 50000
> uart1_ipg 1 2 0 66000000 0 0 50000
> sai3_ipg 0 0 0 66000000 0 0 50000
> spdif_gclk 0 0 0 66000000 0 0 50000
> spba 0 0 0 66000000 0 0 50000
> wdog2 0 0 0 66000000 0 0 50000
> kpp 0 0 0 66000000 0 0 50000
> mmdc_p1_ipg 0 0 0 66000000 0 0 50000
> mmdc_p0_ipg 2 2 0 66000000 0 0 50000
> wdog1 1 1 0 66000000 0 0 50000
> gpio4 1 1 0 66000000 0 0 50000
> uart6_ipg 0 0 0 66000000 0 0 50000
> uart5_ipg 0 0 0 66000000 0 0 50000
> gpio3 1 1 0 66000000 0 0 50000
> ocotp 0 0 0 66000000 0 0 50000
> gpio5 1 1 0 66000000 0 0 50000
> gpio1 1 1 0 66000000 0 0 50000
> uart4_ipg 0 0 0 66000000 0 0 50000
> adc1 0 0 0 66000000 0 0 50000
> uart3_ipg 0 0 0 66000000 0 0 50000
> adc2 0 0 0 66000000 0 0 50000
> gpio2 1 1 0 66000000 0 0 50000
> uart2_ipg 0 0 0 66000000 0 0 50000
> can2_ipg 0 0 0 66000000 0 0 50000
> can1_ipg 0 0 0 66000000 0 0 50000
> enet 2 2 0 66000000 0 0 50000
> axi_sel 1 1 0 528000000 0 0 50000
> axi_podf 2 2 0 264000000 0 0 50000
> axi 1 1 0 264000000 0 0 50000
> eim_slow_sel 0 0 0 264000000 0 0 50000
> eim_slow_podf 0 0 0 132000000 0 0 50000
> eim 0 0 0 132000000 0 0 50000
> lcdif_apb 0 0 0 264000000 0 0 50000
> pxp 0 0 0 264000000 0 0 50000
> epdc_aclk 0 0 0 264000000 0 0 50000
> pll2_pfd3_594m 0 0 0 594000000 0 0 50000
> ldb_di0_sel 0 0 0 594000000 0 0 50000
> ldb_di0_div_7 0 0 0 84857142 0 0 50000
> ldb_di0 0 0 0 84857142 0 0 50000
> ldb_di0_div_3_5 0 0 0 169714285 0 0 50000
> pll2_pfd2_396m 2 2 0 396000000 0 0 50000
> enfc_sel 0 0 0 396000000 0 0 50000
> enfc_pred 0 0 0 99000000 0 0 50000
> enfc_podf 0 0 0 99000000 0 0 50000
> gpmi_io 0 0 0 99000000 0 0 50000
> usdhc1_sel 0 0 0 396000000 0 0 50000
> usdhc1_podf 0 0 0 198000000 0 0 50000
> usdhc1 0 0 0 198000000 0 0 50000
> usdhc2_sel 0 0 0 396000000 0 0 50000
> usdhc2_podf 0 0 0 198000000 0 0 50000
> usdhc2 0 0 0 198000000 0 0 50000
> bch_sel 1 1 0 396000000 0 0 50000
> bch_podf 1 1 0 99000000 0 0 50000
> gpmi_apb 0 0 0 99000000 0 0 50000
> gpmi_bch_apb 0 0 0 99000000 0 0 50000
> per_bch 0 0 0 99000000 0 0 50000
> apbh_dma 1 1 0 99000000 0 0 50000
> gpmi_sel 0 0 0 396000000 0 0 50000
> gpmi_podf 0 0 0 99000000 0 0 50000
> gpmi_bch 0 0 0 99000000 0 0 50000
> periph2_pre 1 1 0 396000000 0 0 50000
> periph2 2 2 0 396000000 0 0 50000
> mmdc_podf 2 2 0 396000000 0 0 50000
> mmdc_p0_fast 1 1 0 396000000 0 0 50000
> axi_alt_sel 0 0 0 396000000 0 0 50000
> pll2_198m 0 0 0 198000000 0 0 50000
> pll2_pfd1_594m 0 0 0 594000000 0 0 50000
> pll2_pfd0_352m 0 0 0 352000000 0 0 50000
> pll1 1 1 0 900000000 0 0 50000
> pll1_bypass 1 1 0 900000000 0 0 50000
> pll1_sys 1 1 0 900000000 0 0 50000
> pll1_sw 1 1 0 900000000 0 0 50000
> arm 1 1 0 900000000 0 0 50000
> pll7_bypass_src 0 0 0 24000000 0 0 50000
> pll6_bypass_src 0 0 0 24000000 0 0 50000
> pll5_bypass_src 0 0 0 24000000 0 0 50000
> pll4_bypass_src 0 0 0 24000000 0 0 50000
> pll3_bypass_src 0 0 0 24000000 0 0 50000
> pll2_bypass_src 0 0 0 24000000 0 0 50000
> pll1_bypass_src 0 0 0 24000000 0 0 50000
> ckil 0 0 0 32768 0 0 50000
>
>
> Note that this was generated on a normal boot up (not failure).
The values looks good. Can you try with the below diff applied?
--->8---
diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
index 334fe3130285..9771f6a82abe 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
@@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
/* Wait 64 clock cycles before using the GPMI after enabling the DLL */
- dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
- if (!dll_wait_time_us)
- dll_wait_time_us = 1;
+ dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
/* Wait for the DLL to settle. */
- udelay(dll_wait_time_us);
+ usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
}
static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-31 6:28 ` Boris Brezillon
@ 2019-08-02 7:19 ` Greg Ungerer
2019-08-02 12:34 ` Greg Ungerer
1 sibling, 0 replies; 39+ messages in thread
From: Greg Ungerer @ 2019-08-02 7:19 UTC (permalink / raw)
To: Boris Brezillon
Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
Miquel Raynal
Hi Boris,
On 31/7/19 4:28 pm, Boris Brezillon wrote:
> On Wed, 31 Jul 2019 12:05:44 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>
>> Hi Miquel, Boris,
>>
>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>> [snip]
>>>> Not sure if this is a useful data point... But I modified that
>>>> nand_init_data_interface() loop to start checking from data mode 4.
>>>> So now on every boot it defaults to mode 4. That has been running
>>>> most of the day, up to 900 boot cycles now, no failures.
>>>
>>> Ok so after having chatted quite a bit with Boris, it is very likely
>>> that, for these chips, the timings in mode 5 are too tight. It could
>>> fail the GET_FEATURES once in mode 5. Can you please dump every single
>>> intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
>>> use of half pêriods, tRP, sample delay, etc) as well as the content
>>> of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
>>> enabled and mounted).
>>>
>>> Also, can you be sure that the NAND chip is powered with 3.3V?
>>
>> Yes, 3.3V NAND chip.
>>
>> Using the attached patch I get the following trace:
>>
>> ...
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>> sdr->tBERS_max=65535000000
>> sdr->tCCS_min=500000000
>> sdr->tPROG_max=65535000000
>> sdr->tR_max=200000000000000
>> sdr->tALH_min=20000
>> sdr->tADL_min=400000
>> sdr->tALS_min=50000
>> sdr->tAR_min=25000
>> sdr->tCEA_max=100000
>> sdr->tCEH_min=20000
>> sdr->tCH_min=20000
>> sdr->tCHZ_max=100000
>> sdr->tCLH_min=20000
>> sdr->tCLR_min=20000
>> sdr->tCLS_min=50000
>> sdr->tCOH_min=0
>> sdr->tCS_min=70000
>> sdr->tDH_min=20000
>> sdr->tDS_min=40000
>> sdr->tFEAT_max=1000000
>> sdr->tIR_min=10000
>> sdr->tITC_max=1000000
>> sdr->tRC_min=100000
>> sdr->tREA_max=40000
>> sdr->tREH_min=30000
>> sdr->tRHOH_min=0
>> sdr->tRHW_min=200000
>> sdr->tRHZ_max=200000
>> sdr->tRLOH_min=0
>> sdr->tRP_min=50000
>> sdr->tRR_min=40000
>> sdr->tRST_max=250000000000
>> sdr->tWB_max=200000
>> sdr->tWC_min=100000
>> sdr->tWH_min=30000
>> sdr->tWHR_min=120000
>> sdr->tWP_min=50000
>> sdr->tWW_min=100000
>> hw->clk_rate=22000000
>> wrn_dly_sel=0
>> period_ps=45454
>> addr_setup_cycles=2
>> data_setup_cycles=1
>> data_hold_cycles=1
>> busy_timeout_cycles=31302
>> hw->timing0=0x00020101
>> hw->timing1=0x60000000
>> dll_threshold_ps=12000
>> use_half_period=1
>> reference_period_ps=22727
>> tRP_ps=45454
>> sample_delay_ps=4294955664
>> sample_delay_factor=0
>> hw->ctrl1n=0x00000000
>> hw->ctrl1n=0x00000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>> hw>clk_rate=22000000
>> clk_set_rate(r->clock[0], hw->clk_rate)=0
>> clk_get_rate(r->clock[0])=22000000
>> random: fast init done
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>> sdr->tBERS_max=3000000000
>> sdr->tCCS_min=100000
>> sdr->tPROG_max=600000000
>> sdr->tR_max=25000000
>> sdr->tALH_min=20000
>> sdr->tADL_min=400000
>> sdr->tALS_min=50000
>> sdr->tAR_min=25000
>> sdr->tCEA_max=100000
>> sdr->tCEH_min=20000
>> sdr->tCH_min=20000
>> sdr->tCHZ_max=100000
>> sdr->tCLH_min=20000
>> sdr->tCLR_min=20000
>> sdr->tCLS_min=50000
>> sdr->tCOH_min=0
>> sdr->tCS_min=70000
>> sdr->tDH_min=20000
>> sdr->tDS_min=40000
>> sdr->tFEAT_max=1000000
>> sdr->tIR_min=10000
>> sdr->tITC_max=1000000
>> sdr->tRC_min=100000
>> sdr->tREA_max=40000
>> sdr->tREH_min=30000
>> sdr->tRHOH_min=0
>> sdr->tRHW_min=200000
>> sdr->tRHZ_max=200000
>> sdr->tRLOH_min=0
>> sdr->tRP_min=50000
>> sdr->tRR_min=40000
>> sdr->tRST_max=250000000000
>> sdr->tWB_max=200000
>> sdr->tWC_min=100000
>> sdr->tWH_min=30000
>> sdr->tWHR_min=120000
>> sdr->tWP_min=50000
>> sdr->tWW_min=100000
>> hw->clk_rate=22000000
>> wrn_dly_sel=0
>> period_ps=45454
>> addr_setup_cycles=2
>> data_setup_cycles=1
>> data_hold_cycles=1
>> busy_timeout_cycles=555
>> hw->timing0=0x00020101
>> hw->timing1=0xb0000000
>> dll_threshold_ps=12000
>> use_half_period=1
>> reference_period_ps=22727
>> tRP_ps=45454
>> sample_delay_ps=4294955664
>> sample_delay_factor=0
>> hw->ctrl1n=0x00000000
>> hw->ctrl1n=0x00000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>> hw>clk_rate=22000000
>> clk_set_rate(r->clock[0], hw->clk_rate)=0
>> clk_get_rate(r->clock[0])=22000000
>> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
>> drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
>> drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
>> drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>> sdr->tBERS_max=3000000000
>> sdr->tCCS_min=100000
>> sdr->tPROG_max=600000000
>> sdr->tR_max=25000000
>> sdr->tALH_min=5000
>> sdr->tADL_min=400000
>> sdr->tALS_min=10000
>> sdr->tAR_min=10000
>> sdr->tCEA_max=25000
>> sdr->tCEH_min=20000
>> sdr->tCH_min=5000
>> sdr->tCHZ_max=30000
>> sdr->tCLH_min=5000
>> sdr->tCLR_min=10000
>> sdr->tCLS_min=10000
>> sdr->tCOH_min=15000
>> sdr->tCS_min=15000
>> sdr->tDH_min=5000
>> sdr->tDS_min=7000
>> sdr->tFEAT_max=1000000
>> sdr->tIR_min=0
>> sdr->tITC_max=1000000
>> sdr->tRC_min=20000
>> sdr->tREA_max=16000
>> sdr->tREH_min=7000
>> sdr->tRHOH_min=15000
>> sdr->tRHW_min=100000
>> sdr->tRHZ_max=100000
>> sdr->tRLOH_min=5000
>> sdr->tRP_min=10000
>> sdr->tRR_min=20000
>> sdr->tRST_max=500000000
>> sdr->tWB_max=100000
>> sdr->tWC_min=20000
>> sdr->tWH_min=7000
>> sdr->tWHR_min=80000
>> sdr->tWP_min=10000
>> sdr->tWW_min=100000
>> hw->clk_rate=100000000
>> wrn_dly_sel=3
>> period_ps=10000
>> addr_setup_cycles=1
>> data_setup_cycles=1
>> data_hold_cycles=1
>> busy_timeout_cycles=2510
>> hw->timing0=0x00010101
>> hw->timing1=0xe0000000
>> dll_threshold_ps=12000
>> use_half_period=0
>> reference_period_ps=10000
>> tRP_ps=10000
>> sample_delay_ps=80000
>> sample_delay_factor=8
>> hw->ctrl1n=0x00c00000
>> hw->ctrl1n=0x00c28000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>> hw>clk_rate=100000000
>> clk_set_rate(r->clock[0], hw->clk_rate)=0
>> clk_get_rate(r->clock[0])=99000000
>> Scanning device for bad blocks
>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>> ...
>>
>>
>> And "cat /sys/kernel/debug/clk/clk_summary" gives:
>>
>> enable prepare protect duty
>> clock count count count rate accuracy phase cycle
>> ---------------------------------------------------------------------------------------------
>> dummy 2 2 0 0 0 0 50000
>> cko2_sel 0 0 0 0 0 0 50000
>> cko2_podf 0 0 0 0 0 0 50000
>> cko2 0 0 0 0 0 0 50000
>> cko1_sel 0 0 0 0 0 0 50000
>> cko1_podf 0 0 0 0 0 0 50000
>> cko1 0 0 0 0 0 0 50000
>> cko 0 0 0 0 0 0 50000
>> usbphy2_gate 1 1 0 0 0 0 50000
>> usbphy1_gate 1 1 0 0 0 0 50000
>> ipp_di1 0 0 0 0 0 0 50000
>> ipp_di0 0 0 0 0 0 0 50000
>> osc 6 6 0 24000000 0 0 50000
>> perclk_sel 1 1 0 24000000 0 0 50000
>> perclk 3 3 0 24000000 0 0 50000
>> pwm7 0 0 0 24000000 0 0 50000
>> pwm6 0 0 0 24000000 0 0 50000
>> pwm5 0 0 0 24000000 0 0 50000
>> i2c4 0 0 0 24000000 0 0 50000
>> pwm8 0 0 0 24000000 0 0 50000
>> pwm4 0 0 0 24000000 0 0 50000
>> pwm3 0 0 0 24000000 0 0 50000
>> pwm2 0 0 0 24000000 0 0 50000
>> pwm1 0 0 0 24000000 0 0 50000
>> i2c3 0 0 0 24000000 0 0 50000
>> i2c2 1 1 0 24000000 0 0 50000
>> i2c1 0 0 0 24000000 0 0 50000
>> gpt1_serial 1 1 0 24000000 0 0 50000
>> gpt1_bus 1 1 0 24000000 0 0 50000
>> epit2 0 0 0 24000000 0 0 50000
>> epit1 0 0 0 24000000 0 0 50000
>> gpt2_serial 0 0 0 24000000 0 0 50000
>> gpt2_bus 0 0 0 24000000 0 0 50000
>> periph_clk2_sel 0 0 0 24000000 0 0 50000
>> periph_clk2 0 0 0 24000000 0 0 50000
>> gpt_3m 0 0 0 3000000 0 0 50000
>> csi_sel 0 0 0 24000000 0 0 50000
>> csi_podf 0 0 0 24000000 0 0 50000
>> csi 0 0 0 24000000 0 0 50000
>> pll7 1 1 0 480000000 0 0 50000
>> pll7_bypass 1 1 0 480000000 0 0 50000
>> pll7_usb_host 1 1 0 480000000 0 0 50000
>> usbphy2 1 1 0 480000000 0 0 50000
>> pll6 1 1 0 500000000 0 0 50000
>> pll6_bypass 1 1 0 500000000 0 0 50000
>> pll6_enet 2 2 0 500000000 0 0 50000
>> enet_ptp_ref 1 1 0 25000000 0 0 50000
>> enet_ptp 1 1 0 25000000 0 0 50000
>> enet2_ref 0 0 0 50000000 0 0 50000
>> enet_ref_125m 0 0 0 50000000 0 0 50000
>> enet_ref 2 2 0 50000000 0 0 50000
>> pll5 0 0 0 296600000 0 0 50000
>> pll5_bypass 0 0 0 296600000 0 0 50000
>> pll5_video 0 0 0 296600000 0 0 50000
>> pll5_post_div 0 0 0 74150000 0 0 50000
>> pll5_video_div 0 0 0 74150000 0 0 50000
>> pll4 0 0 0 147456000 0 0 50000
>> pll4_bypass 0 0 0 147456000 0 0 50000
>> pll4_audio 0 0 0 147456000 0 0 50000
>> pll4_post_div 0 0 0 36864000 0 0 50000
>> pll4_audio_div 0 0 0 36864000 0 0 50000
>> pll3 1 1 0 480000000 0 0 50000
>> pll3_bypass 1 1 0 480000000 0 0 50000
>> pll3_usb_otg 2 2 0 480000000 0 0 50000
>> spdif_sel 0 0 0 480000000 0 0 50000
>> spdif_pred 0 0 0 240000000 0 0 50000
>> spdif_podf 0 0 0 30000000 0 0 50000
>> spdif 0 0 0 30000000 0 0 50000
>> esai_sel 0 0 0 480000000 0 0 50000
>> esai_pred 0 0 0 240000000 0 0 50000
>> esai_podf 0 0 0 30000000 0 0 50000
>> esai_extal 0 0 0 30000000 0 0 50000
>> qspi1_sel 0 0 0 480000000 0 0 50000
>> qspi1_podf 0 0 0 240000000 0 0 50000
>> qspi1 0 0 0 240000000 0 0 50000
>> ldb_di1_div_7 0 0 0 68571428 0 0 50000
>> ldb_di1 0 0 0 68571428 0 0 50000
>> ldb_di1_div_3_5 0 0 0 137142857 0 0 50000
>> periph2_clk2_sel 0 0 0 480000000 0 0 50000
>> periph2_clk2 0 0 0 480000000 0 0 50000
>> pll3_60m 0 0 0 60000000 0 0 50000
>> can_sel 0 0 0 60000000 0 0 50000
>> can_podf 0 0 0 30000000 0 0 50000
>> can2_serial 0 0 0 30000000 0 0 50000
>> can1_serial 0 0 0 30000000 0 0 50000
>> ecspi_sel 0 0 0 60000000 0 0 50000
>> ecspi_podf 0 0 0 60000000 0 0 50000
>> ecspi4 0 0 0 60000000 0 0 50000
>> ecspi3 0 0 0 60000000 0 0 50000
>> ecspi2 0 0 0 60000000 0 0 50000
>> ecspi1 0 0 0 60000000 0 0 50000
>> pll3_80m 1 1 0 80000000 0 0 50000
>> uart_sel 1 1 0 80000000 0 0 50000
>> uart_podf 1 1 0 80000000 0 0 50000
>> uart8_serial 0 0 0 80000000 0 0 50000
>> uart7_serial 0 0 0 80000000 0 0 50000
>> uart1_serial 1 2 0 80000000 0 0 50000
>> uart6_serial 0 0 0 80000000 0 0 50000
>> uart5_serial 0 0 0 80000000 0 0 50000
>> uart4_serial 0 0 0 80000000 0 0 50000
>> uart3_serial 0 0 0 80000000 0 0 50000
>> uart2_serial 0 0 0 80000000 0 0 50000
>> pll3_pfd3_454m 0 0 0 454736842 0 0 50000
>> pll3_pfd2_508m 0 0 0 508235294 0 0 50000
>> epdc_pre_sel 0 0 0 508235294 0 0 50000
>> epdc_podf 0 0 0 254117647 0 0 50000
>> epdc_pix 0 0 0 254117647 0 0 50000
>> epdc_sel 0 0 0 254117647 0 0 50000
>> sai1_sel 0 0 0 508235294 0 0 50000
>> sai1_pred 0 0 0 127058824 0 0 50000
>> sai1_podf 0 0 0 63529412 0 0 50000
>> sai1 0 0 0 63529412 0 0 50000
>> sai2_sel 0 0 0 508235294 0 0 50000
>> sai2_pred 0 0 0 127058824 0 0 50000
>> sai2_podf 0 0 0 63529412 0 0 50000
>> sai2 0 0 0 63529412 0 0 50000
>> sai3_sel 0 0 0 508235294 0 0 50000
>> sai3_pred 0 0 0 127058824 0 0 50000
>> sai3_podf 0 0 0 63529412 0 0 50000
>> sai3 0 0 0 63529412 0 0 50000
>> pll3_pfd1_540m 0 0 0 540000000 0 0 50000
>> lcdif_pre_sel 0 0 0 540000000 0 0 50000
>> lcdif_pred 0 0 0 270000000 0 0 50000
>> lcdif_podf 0 0 0 135000000 0 0 50000
>> lcdif_pix 0 0 0 135000000 0 0 50000
>> iomuxc 0 0 0 135000000 0 0 50000
>> lcdif_sel 0 0 0 135000000 0 0 50000
>> pll3_pfd0_720m 0 0 0 720000000 0 0 50000
>> usbphy1 1 1 0 480000000 0 0 50000
>> pll2 1 1 0 528000000 0 0 50000
>> pll2_bypass 1 1 0 528000000 0 0 50000
>> pll2_bus 2 2 0 528000000 0 0 50000
>> ca7_secondary_sel 0 0 0 528000000 0 0 50000
>> step 0 0 0 528000000 0 0 50000
>> periph_pre 1 1 0 528000000 0 0 50000
>> periph 3 3 0 528000000 0 0 50000
>> ahb 7 7 0 132000000 0 0 50000
>> sdma 0 0 0 132000000 0 0 50000
>> rom 1 1 0 132000000 0 0 50000
>> esai_mem 0 0 0 132000000 0 0 50000
>> esai_ipg 0 0 0 132000000 0 0 50000
>> aips_tz3 1 1 0 132000000 0 0 50000
>> enet_ahb 2 2 0 132000000 0 0 50000
>> dcp 0 0 0 132000000 0 0 50000
>> asrc_mem 0 0 0 132000000 0 0 50000
>> asrc_ipg 0 0 0 132000000 0 0 50000
>> aips_tz2 1 1 0 132000000 0 0 50000
>> aips_tz1 1 1 0 132000000 0 0 50000
>> ipg 10 10 0 66000000 0 0 50000
>> wdog3 0 0 0 66000000 0 0 50000
>> uart8_ipg 0 0 0 66000000 0 0 50000
>> usboh3 2 2 0 66000000 0 0 50000
>> sai2_ipg 0 0 0 66000000 0 0 50000
>> sai1_ipg 0 0 0 66000000 0 0 50000
>> uart7_ipg 0 0 0 66000000 0 0 50000
>> uart1_ipg 1 2 0 66000000 0 0 50000
>> sai3_ipg 0 0 0 66000000 0 0 50000
>> spdif_gclk 0 0 0 66000000 0 0 50000
>> spba 0 0 0 66000000 0 0 50000
>> wdog2 0 0 0 66000000 0 0 50000
>> kpp 0 0 0 66000000 0 0 50000
>> mmdc_p1_ipg 0 0 0 66000000 0 0 50000
>> mmdc_p0_ipg 2 2 0 66000000 0 0 50000
>> wdog1 1 1 0 66000000 0 0 50000
>> gpio4 1 1 0 66000000 0 0 50000
>> uart6_ipg 0 0 0 66000000 0 0 50000
>> uart5_ipg 0 0 0 66000000 0 0 50000
>> gpio3 1 1 0 66000000 0 0 50000
>> ocotp 0 0 0 66000000 0 0 50000
>> gpio5 1 1 0 66000000 0 0 50000
>> gpio1 1 1 0 66000000 0 0 50000
>> uart4_ipg 0 0 0 66000000 0 0 50000
>> adc1 0 0 0 66000000 0 0 50000
>> uart3_ipg 0 0 0 66000000 0 0 50000
>> adc2 0 0 0 66000000 0 0 50000
>> gpio2 1 1 0 66000000 0 0 50000
>> uart2_ipg 0 0 0 66000000 0 0 50000
>> can2_ipg 0 0 0 66000000 0 0 50000
>> can1_ipg 0 0 0 66000000 0 0 50000
>> enet 2 2 0 66000000 0 0 50000
>> axi_sel 1 1 0 528000000 0 0 50000
>> axi_podf 2 2 0 264000000 0 0 50000
>> axi 1 1 0 264000000 0 0 50000
>> eim_slow_sel 0 0 0 264000000 0 0 50000
>> eim_slow_podf 0 0 0 132000000 0 0 50000
>> eim 0 0 0 132000000 0 0 50000
>> lcdif_apb 0 0 0 264000000 0 0 50000
>> pxp 0 0 0 264000000 0 0 50000
>> epdc_aclk 0 0 0 264000000 0 0 50000
>> pll2_pfd3_594m 0 0 0 594000000 0 0 50000
>> ldb_di0_sel 0 0 0 594000000 0 0 50000
>> ldb_di0_div_7 0 0 0 84857142 0 0 50000
>> ldb_di0 0 0 0 84857142 0 0 50000
>> ldb_di0_div_3_5 0 0 0 169714285 0 0 50000
>> pll2_pfd2_396m 2 2 0 396000000 0 0 50000
>> enfc_sel 0 0 0 396000000 0 0 50000
>> enfc_pred 0 0 0 99000000 0 0 50000
>> enfc_podf 0 0 0 99000000 0 0 50000
>> gpmi_io 0 0 0 99000000 0 0 50000
>> usdhc1_sel 0 0 0 396000000 0 0 50000
>> usdhc1_podf 0 0 0 198000000 0 0 50000
>> usdhc1 0 0 0 198000000 0 0 50000
>> usdhc2_sel 0 0 0 396000000 0 0 50000
>> usdhc2_podf 0 0 0 198000000 0 0 50000
>> usdhc2 0 0 0 198000000 0 0 50000
>> bch_sel 1 1 0 396000000 0 0 50000
>> bch_podf 1 1 0 99000000 0 0 50000
>> gpmi_apb 0 0 0 99000000 0 0 50000
>> gpmi_bch_apb 0 0 0 99000000 0 0 50000
>> per_bch 0 0 0 99000000 0 0 50000
>> apbh_dma 1 1 0 99000000 0 0 50000
>> gpmi_sel 0 0 0 396000000 0 0 50000
>> gpmi_podf 0 0 0 99000000 0 0 50000
>> gpmi_bch 0 0 0 99000000 0 0 50000
>> periph2_pre 1 1 0 396000000 0 0 50000
>> periph2 2 2 0 396000000 0 0 50000
>> mmdc_podf 2 2 0 396000000 0 0 50000
>> mmdc_p0_fast 1 1 0 396000000 0 0 50000
>> axi_alt_sel 0 0 0 396000000 0 0 50000
>> pll2_198m 0 0 0 198000000 0 0 50000
>> pll2_pfd1_594m 0 0 0 594000000 0 0 50000
>> pll2_pfd0_352m 0 0 0 352000000 0 0 50000
>> pll1 1 1 0 900000000 0 0 50000
>> pll1_bypass 1 1 0 900000000 0 0 50000
>> pll1_sys 1 1 0 900000000 0 0 50000
>> pll1_sw 1 1 0 900000000 0 0 50000
>> arm 1 1 0 900000000 0 0 50000
>> pll7_bypass_src 0 0 0 24000000 0 0 50000
>> pll6_bypass_src 0 0 0 24000000 0 0 50000
>> pll5_bypass_src 0 0 0 24000000 0 0 50000
>> pll4_bypass_src 0 0 0 24000000 0 0 50000
>> pll3_bypass_src 0 0 0 24000000 0 0 50000
>> pll2_bypass_src 0 0 0 24000000 0 0 50000
>> pll1_bypass_src 0 0 0 24000000 0 0 50000
>> ckil 0 0 0 32768 0 0 50000
>>
>>
>> Note that this was generated on a normal boot up (not failure).
>
> The values looks good. Can you try with the below diff applied?
> --->8---
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> index 334fe3130285..9771f6a82abe 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>
> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> - if (!dll_wait_time_us)
> - dll_wait_time_us = 1;
> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>
> /* Wait for the DLL to settle. */
> - udelay(dll_wait_time_us);
> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> }
>
> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
Running a boot test with this now. Has run for a couple of hours, but I
want to give it a really good run over the weekend. Will report results
on Monday.
Thanks
Greg
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-07-31 6:28 ` Boris Brezillon
2019-08-02 7:19 ` Greg Ungerer
@ 2019-08-02 12:34 ` Greg Ungerer
2019-08-02 12:51 ` Boris Brezillon
1 sibling, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-08-02 12:34 UTC (permalink / raw)
To: Boris Brezillon
Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
Miquel Raynal
Hi Boris,
On 31/7/19 4:28 pm, Boris Brezillon wrote:
> On Wed, 31 Jul 2019 12:05:44 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>
>> Hi Miquel, Boris,
>>
>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>> [snip]
>>>> Not sure if this is a useful data point... But I modified that
>>>> nand_init_data_interface() loop to start checking from data mode 4.
>>>> So now on every boot it defaults to mode 4. That has been running
>>>> most of the day, up to 900 boot cycles now, no failures.
>>>
>>> Ok so after having chatted quite a bit with Boris, it is very likely
>>> that, for these chips, the timings in mode 5 are too tight. It could
>>> fail the GET_FEATURES once in mode 5. Can you please dump every single
>>> intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
>>> use of half pêriods, tRP, sample delay, etc) as well as the content
>>> of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
>>> enabled and mounted).
>>>
>>> Also, can you be sure that the NAND chip is powered with 3.3V?
>>
>> Yes, 3.3V NAND chip.
>>
>> Using the attached patch I get the following trace:
>>
>> ...
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>> sdr->tBERS_max=65535000000
>> sdr->tCCS_min=500000000
>> sdr->tPROG_max=65535000000
>> sdr->tR_max=200000000000000
>> sdr->tALH_min=20000
>> sdr->tADL_min=400000
>> sdr->tALS_min=50000
>> sdr->tAR_min=25000
>> sdr->tCEA_max=100000
>> sdr->tCEH_min=20000
>> sdr->tCH_min=20000
>> sdr->tCHZ_max=100000
>> sdr->tCLH_min=20000
>> sdr->tCLR_min=20000
>> sdr->tCLS_min=50000
>> sdr->tCOH_min=0
>> sdr->tCS_min=70000
>> sdr->tDH_min=20000
>> sdr->tDS_min=40000
>> sdr->tFEAT_max=1000000
>> sdr->tIR_min=10000
>> sdr->tITC_max=1000000
>> sdr->tRC_min=100000
>> sdr->tREA_max=40000
>> sdr->tREH_min=30000
>> sdr->tRHOH_min=0
>> sdr->tRHW_min=200000
>> sdr->tRHZ_max=200000
>> sdr->tRLOH_min=0
>> sdr->tRP_min=50000
>> sdr->tRR_min=40000
>> sdr->tRST_max=250000000000
>> sdr->tWB_max=200000
>> sdr->tWC_min=100000
>> sdr->tWH_min=30000
>> sdr->tWHR_min=120000
>> sdr->tWP_min=50000
>> sdr->tWW_min=100000
>> hw->clk_rate=22000000
>> wrn_dly_sel=0
>> period_ps=45454
>> addr_setup_cycles=2
>> data_setup_cycles=1
>> data_hold_cycles=1
>> busy_timeout_cycles=31302
>> hw->timing0=0x00020101
>> hw->timing1=0x60000000
>> dll_threshold_ps=12000
>> use_half_period=1
>> reference_period_ps=22727
>> tRP_ps=45454
>> sample_delay_ps=4294955664
>> sample_delay_factor=0
>> hw->ctrl1n=0x00000000
>> hw->ctrl1n=0x00000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>> hw>clk_rate=22000000
>> clk_set_rate(r->clock[0], hw->clk_rate)=0
>> clk_get_rate(r->clock[0])=22000000
>> random: fast init done
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>> sdr->tBERS_max=3000000000
>> sdr->tCCS_min=100000
>> sdr->tPROG_max=600000000
>> sdr->tR_max=25000000
>> sdr->tALH_min=20000
>> sdr->tADL_min=400000
>> sdr->tALS_min=50000
>> sdr->tAR_min=25000
>> sdr->tCEA_max=100000
>> sdr->tCEH_min=20000
>> sdr->tCH_min=20000
>> sdr->tCHZ_max=100000
>> sdr->tCLH_min=20000
>> sdr->tCLR_min=20000
>> sdr->tCLS_min=50000
>> sdr->tCOH_min=0
>> sdr->tCS_min=70000
>> sdr->tDH_min=20000
>> sdr->tDS_min=40000
>> sdr->tFEAT_max=1000000
>> sdr->tIR_min=10000
>> sdr->tITC_max=1000000
>> sdr->tRC_min=100000
>> sdr->tREA_max=40000
>> sdr->tREH_min=30000
>> sdr->tRHOH_min=0
>> sdr->tRHW_min=200000
>> sdr->tRHZ_max=200000
>> sdr->tRLOH_min=0
>> sdr->tRP_min=50000
>> sdr->tRR_min=40000
>> sdr->tRST_max=250000000000
>> sdr->tWB_max=200000
>> sdr->tWC_min=100000
>> sdr->tWH_min=30000
>> sdr->tWHR_min=120000
>> sdr->tWP_min=50000
>> sdr->tWW_min=100000
>> hw->clk_rate=22000000
>> wrn_dly_sel=0
>> period_ps=45454
>> addr_setup_cycles=2
>> data_setup_cycles=1
>> data_hold_cycles=1
>> busy_timeout_cycles=555
>> hw->timing0=0x00020101
>> hw->timing1=0xb0000000
>> dll_threshold_ps=12000
>> use_half_period=1
>> reference_period_ps=22727
>> tRP_ps=45454
>> sample_delay_ps=4294955664
>> sample_delay_factor=0
>> hw->ctrl1n=0x00000000
>> hw->ctrl1n=0x00000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>> hw>clk_rate=22000000
>> clk_set_rate(r->clock[0], hw->clk_rate)=0
>> clk_get_rate(r->clock[0])=22000000
>> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
>> drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
>> drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
>> drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>> sdr->tBERS_max=3000000000
>> sdr->tCCS_min=100000
>> sdr->tPROG_max=600000000
>> sdr->tR_max=25000000
>> sdr->tALH_min=5000
>> sdr->tADL_min=400000
>> sdr->tALS_min=10000
>> sdr->tAR_min=10000
>> sdr->tCEA_max=25000
>> sdr->tCEH_min=20000
>> sdr->tCH_min=5000
>> sdr->tCHZ_max=30000
>> sdr->tCLH_min=5000
>> sdr->tCLR_min=10000
>> sdr->tCLS_min=10000
>> sdr->tCOH_min=15000
>> sdr->tCS_min=15000
>> sdr->tDH_min=5000
>> sdr->tDS_min=7000
>> sdr->tFEAT_max=1000000
>> sdr->tIR_min=0
>> sdr->tITC_max=1000000
>> sdr->tRC_min=20000
>> sdr->tREA_max=16000
>> sdr->tREH_min=7000
>> sdr->tRHOH_min=15000
>> sdr->tRHW_min=100000
>> sdr->tRHZ_max=100000
>> sdr->tRLOH_min=5000
>> sdr->tRP_min=10000
>> sdr->tRR_min=20000
>> sdr->tRST_max=500000000
>> sdr->tWB_max=100000
>> sdr->tWC_min=20000
>> sdr->tWH_min=7000
>> sdr->tWHR_min=80000
>> sdr->tWP_min=10000
>> sdr->tWW_min=100000
>> hw->clk_rate=100000000
>> wrn_dly_sel=3
>> period_ps=10000
>> addr_setup_cycles=1
>> data_setup_cycles=1
>> data_hold_cycles=1
>> busy_timeout_cycles=2510
>> hw->timing0=0x00010101
>> hw->timing1=0xe0000000
>> dll_threshold_ps=12000
>> use_half_period=0
>> reference_period_ps=10000
>> tRP_ps=10000
>> sample_delay_ps=80000
>> sample_delay_factor=8
>> hw->ctrl1n=0x00c00000
>> hw->ctrl1n=0x00c28000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>> hw>clk_rate=100000000
>> clk_set_rate(r->clock[0], hw->clk_rate)=0
>> clk_get_rate(r->clock[0])=99000000
>> Scanning device for bad blocks
>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>> ...
>>
>>
>> And "cat /sys/kernel/debug/clk/clk_summary" gives:
>>
>> enable prepare protect duty
>> clock count count count rate accuracy phase cycle
>> ---------------------------------------------------------------------------------------------
>> dummy 2 2 0 0 0 0 50000
>> cko2_sel 0 0 0 0 0 0 50000
>> cko2_podf 0 0 0 0 0 0 50000
>> cko2 0 0 0 0 0 0 50000
>> cko1_sel 0 0 0 0 0 0 50000
>> cko1_podf 0 0 0 0 0 0 50000
>> cko1 0 0 0 0 0 0 50000
>> cko 0 0 0 0 0 0 50000
>> usbphy2_gate 1 1 0 0 0 0 50000
>> usbphy1_gate 1 1 0 0 0 0 50000
>> ipp_di1 0 0 0 0 0 0 50000
>> ipp_di0 0 0 0 0 0 0 50000
>> osc 6 6 0 24000000 0 0 50000
>> perclk_sel 1 1 0 24000000 0 0 50000
>> perclk 3 3 0 24000000 0 0 50000
>> pwm7 0 0 0 24000000 0 0 50000
>> pwm6 0 0 0 24000000 0 0 50000
>> pwm5 0 0 0 24000000 0 0 50000
>> i2c4 0 0 0 24000000 0 0 50000
>> pwm8 0 0 0 24000000 0 0 50000
>> pwm4 0 0 0 24000000 0 0 50000
>> pwm3 0 0 0 24000000 0 0 50000
>> pwm2 0 0 0 24000000 0 0 50000
>> pwm1 0 0 0 24000000 0 0 50000
>> i2c3 0 0 0 24000000 0 0 50000
>> i2c2 1 1 0 24000000 0 0 50000
>> i2c1 0 0 0 24000000 0 0 50000
>> gpt1_serial 1 1 0 24000000 0 0 50000
>> gpt1_bus 1 1 0 24000000 0 0 50000
>> epit2 0 0 0 24000000 0 0 50000
>> epit1 0 0 0 24000000 0 0 50000
>> gpt2_serial 0 0 0 24000000 0 0 50000
>> gpt2_bus 0 0 0 24000000 0 0 50000
>> periph_clk2_sel 0 0 0 24000000 0 0 50000
>> periph_clk2 0 0 0 24000000 0 0 50000
>> gpt_3m 0 0 0 3000000 0 0 50000
>> csi_sel 0 0 0 24000000 0 0 50000
>> csi_podf 0 0 0 24000000 0 0 50000
>> csi 0 0 0 24000000 0 0 50000
>> pll7 1 1 0 480000000 0 0 50000
>> pll7_bypass 1 1 0 480000000 0 0 50000
>> pll7_usb_host 1 1 0 480000000 0 0 50000
>> usbphy2 1 1 0 480000000 0 0 50000
>> pll6 1 1 0 500000000 0 0 50000
>> pll6_bypass 1 1 0 500000000 0 0 50000
>> pll6_enet 2 2 0 500000000 0 0 50000
>> enet_ptp_ref 1 1 0 25000000 0 0 50000
>> enet_ptp 1 1 0 25000000 0 0 50000
>> enet2_ref 0 0 0 50000000 0 0 50000
>> enet_ref_125m 0 0 0 50000000 0 0 50000
>> enet_ref 2 2 0 50000000 0 0 50000
>> pll5 0 0 0 296600000 0 0 50000
>> pll5_bypass 0 0 0 296600000 0 0 50000
>> pll5_video 0 0 0 296600000 0 0 50000
>> pll5_post_div 0 0 0 74150000 0 0 50000
>> pll5_video_div 0 0 0 74150000 0 0 50000
>> pll4 0 0 0 147456000 0 0 50000
>> pll4_bypass 0 0 0 147456000 0 0 50000
>> pll4_audio 0 0 0 147456000 0 0 50000
>> pll4_post_div 0 0 0 36864000 0 0 50000
>> pll4_audio_div 0 0 0 36864000 0 0 50000
>> pll3 1 1 0 480000000 0 0 50000
>> pll3_bypass 1 1 0 480000000 0 0 50000
>> pll3_usb_otg 2 2 0 480000000 0 0 50000
>> spdif_sel 0 0 0 480000000 0 0 50000
>> spdif_pred 0 0 0 240000000 0 0 50000
>> spdif_podf 0 0 0 30000000 0 0 50000
>> spdif 0 0 0 30000000 0 0 50000
>> esai_sel 0 0 0 480000000 0 0 50000
>> esai_pred 0 0 0 240000000 0 0 50000
>> esai_podf 0 0 0 30000000 0 0 50000
>> esai_extal 0 0 0 30000000 0 0 50000
>> qspi1_sel 0 0 0 480000000 0 0 50000
>> qspi1_podf 0 0 0 240000000 0 0 50000
>> qspi1 0 0 0 240000000 0 0 50000
>> ldb_di1_div_7 0 0 0 68571428 0 0 50000
>> ldb_di1 0 0 0 68571428 0 0 50000
>> ldb_di1_div_3_5 0 0 0 137142857 0 0 50000
>> periph2_clk2_sel 0 0 0 480000000 0 0 50000
>> periph2_clk2 0 0 0 480000000 0 0 50000
>> pll3_60m 0 0 0 60000000 0 0 50000
>> can_sel 0 0 0 60000000 0 0 50000
>> can_podf 0 0 0 30000000 0 0 50000
>> can2_serial 0 0 0 30000000 0 0 50000
>> can1_serial 0 0 0 30000000 0 0 50000
>> ecspi_sel 0 0 0 60000000 0 0 50000
>> ecspi_podf 0 0 0 60000000 0 0 50000
>> ecspi4 0 0 0 60000000 0 0 50000
>> ecspi3 0 0 0 60000000 0 0 50000
>> ecspi2 0 0 0 60000000 0 0 50000
>> ecspi1 0 0 0 60000000 0 0 50000
>> pll3_80m 1 1 0 80000000 0 0 50000
>> uart_sel 1 1 0 80000000 0 0 50000
>> uart_podf 1 1 0 80000000 0 0 50000
>> uart8_serial 0 0 0 80000000 0 0 50000
>> uart7_serial 0 0 0 80000000 0 0 50000
>> uart1_serial 1 2 0 80000000 0 0 50000
>> uart6_serial 0 0 0 80000000 0 0 50000
>> uart5_serial 0 0 0 80000000 0 0 50000
>> uart4_serial 0 0 0 80000000 0 0 50000
>> uart3_serial 0 0 0 80000000 0 0 50000
>> uart2_serial 0 0 0 80000000 0 0 50000
>> pll3_pfd3_454m 0 0 0 454736842 0 0 50000
>> pll3_pfd2_508m 0 0 0 508235294 0 0 50000
>> epdc_pre_sel 0 0 0 508235294 0 0 50000
>> epdc_podf 0 0 0 254117647 0 0 50000
>> epdc_pix 0 0 0 254117647 0 0 50000
>> epdc_sel 0 0 0 254117647 0 0 50000
>> sai1_sel 0 0 0 508235294 0 0 50000
>> sai1_pred 0 0 0 127058824 0 0 50000
>> sai1_podf 0 0 0 63529412 0 0 50000
>> sai1 0 0 0 63529412 0 0 50000
>> sai2_sel 0 0 0 508235294 0 0 50000
>> sai2_pred 0 0 0 127058824 0 0 50000
>> sai2_podf 0 0 0 63529412 0 0 50000
>> sai2 0 0 0 63529412 0 0 50000
>> sai3_sel 0 0 0 508235294 0 0 50000
>> sai3_pred 0 0 0 127058824 0 0 50000
>> sai3_podf 0 0 0 63529412 0 0 50000
>> sai3 0 0 0 63529412 0 0 50000
>> pll3_pfd1_540m 0 0 0 540000000 0 0 50000
>> lcdif_pre_sel 0 0 0 540000000 0 0 50000
>> lcdif_pred 0 0 0 270000000 0 0 50000
>> lcdif_podf 0 0 0 135000000 0 0 50000
>> lcdif_pix 0 0 0 135000000 0 0 50000
>> iomuxc 0 0 0 135000000 0 0 50000
>> lcdif_sel 0 0 0 135000000 0 0 50000
>> pll3_pfd0_720m 0 0 0 720000000 0 0 50000
>> usbphy1 1 1 0 480000000 0 0 50000
>> pll2 1 1 0 528000000 0 0 50000
>> pll2_bypass 1 1 0 528000000 0 0 50000
>> pll2_bus 2 2 0 528000000 0 0 50000
>> ca7_secondary_sel 0 0 0 528000000 0 0 50000
>> step 0 0 0 528000000 0 0 50000
>> periph_pre 1 1 0 528000000 0 0 50000
>> periph 3 3 0 528000000 0 0 50000
>> ahb 7 7 0 132000000 0 0 50000
>> sdma 0 0 0 132000000 0 0 50000
>> rom 1 1 0 132000000 0 0 50000
>> esai_mem 0 0 0 132000000 0 0 50000
>> esai_ipg 0 0 0 132000000 0 0 50000
>> aips_tz3 1 1 0 132000000 0 0 50000
>> enet_ahb 2 2 0 132000000 0 0 50000
>> dcp 0 0 0 132000000 0 0 50000
>> asrc_mem 0 0 0 132000000 0 0 50000
>> asrc_ipg 0 0 0 132000000 0 0 50000
>> aips_tz2 1 1 0 132000000 0 0 50000
>> aips_tz1 1 1 0 132000000 0 0 50000
>> ipg 10 10 0 66000000 0 0 50000
>> wdog3 0 0 0 66000000 0 0 50000
>> uart8_ipg 0 0 0 66000000 0 0 50000
>> usboh3 2 2 0 66000000 0 0 50000
>> sai2_ipg 0 0 0 66000000 0 0 50000
>> sai1_ipg 0 0 0 66000000 0 0 50000
>> uart7_ipg 0 0 0 66000000 0 0 50000
>> uart1_ipg 1 2 0 66000000 0 0 50000
>> sai3_ipg 0 0 0 66000000 0 0 50000
>> spdif_gclk 0 0 0 66000000 0 0 50000
>> spba 0 0 0 66000000 0 0 50000
>> wdog2 0 0 0 66000000 0 0 50000
>> kpp 0 0 0 66000000 0 0 50000
>> mmdc_p1_ipg 0 0 0 66000000 0 0 50000
>> mmdc_p0_ipg 2 2 0 66000000 0 0 50000
>> wdog1 1 1 0 66000000 0 0 50000
>> gpio4 1 1 0 66000000 0 0 50000
>> uart6_ipg 0 0 0 66000000 0 0 50000
>> uart5_ipg 0 0 0 66000000 0 0 50000
>> gpio3 1 1 0 66000000 0 0 50000
>> ocotp 0 0 0 66000000 0 0 50000
>> gpio5 1 1 0 66000000 0 0 50000
>> gpio1 1 1 0 66000000 0 0 50000
>> uart4_ipg 0 0 0 66000000 0 0 50000
>> adc1 0 0 0 66000000 0 0 50000
>> uart3_ipg 0 0 0 66000000 0 0 50000
>> adc2 0 0 0 66000000 0 0 50000
>> gpio2 1 1 0 66000000 0 0 50000
>> uart2_ipg 0 0 0 66000000 0 0 50000
>> can2_ipg 0 0 0 66000000 0 0 50000
>> can1_ipg 0 0 0 66000000 0 0 50000
>> enet 2 2 0 66000000 0 0 50000
>> axi_sel 1 1 0 528000000 0 0 50000
>> axi_podf 2 2 0 264000000 0 0 50000
>> axi 1 1 0 264000000 0 0 50000
>> eim_slow_sel 0 0 0 264000000 0 0 50000
>> eim_slow_podf 0 0 0 132000000 0 0 50000
>> eim 0 0 0 132000000 0 0 50000
>> lcdif_apb 0 0 0 264000000 0 0 50000
>> pxp 0 0 0 264000000 0 0 50000
>> epdc_aclk 0 0 0 264000000 0 0 50000
>> pll2_pfd3_594m 0 0 0 594000000 0 0 50000
>> ldb_di0_sel 0 0 0 594000000 0 0 50000
>> ldb_di0_div_7 0 0 0 84857142 0 0 50000
>> ldb_di0 0 0 0 84857142 0 0 50000
>> ldb_di0_div_3_5 0 0 0 169714285 0 0 50000
>> pll2_pfd2_396m 2 2 0 396000000 0 0 50000
>> enfc_sel 0 0 0 396000000 0 0 50000
>> enfc_pred 0 0 0 99000000 0 0 50000
>> enfc_podf 0 0 0 99000000 0 0 50000
>> gpmi_io 0 0 0 99000000 0 0 50000
>> usdhc1_sel 0 0 0 396000000 0 0 50000
>> usdhc1_podf 0 0 0 198000000 0 0 50000
>> usdhc1 0 0 0 198000000 0 0 50000
>> usdhc2_sel 0 0 0 396000000 0 0 50000
>> usdhc2_podf 0 0 0 198000000 0 0 50000
>> usdhc2 0 0 0 198000000 0 0 50000
>> bch_sel 1 1 0 396000000 0 0 50000
>> bch_podf 1 1 0 99000000 0 0 50000
>> gpmi_apb 0 0 0 99000000 0 0 50000
>> gpmi_bch_apb 0 0 0 99000000 0 0 50000
>> per_bch 0 0 0 99000000 0 0 50000
>> apbh_dma 1 1 0 99000000 0 0 50000
>> gpmi_sel 0 0 0 396000000 0 0 50000
>> gpmi_podf 0 0 0 99000000 0 0 50000
>> gpmi_bch 0 0 0 99000000 0 0 50000
>> periph2_pre 1 1 0 396000000 0 0 50000
>> periph2 2 2 0 396000000 0 0 50000
>> mmdc_podf 2 2 0 396000000 0 0 50000
>> mmdc_p0_fast 1 1 0 396000000 0 0 50000
>> axi_alt_sel 0 0 0 396000000 0 0 50000
>> pll2_198m 0 0 0 198000000 0 0 50000
>> pll2_pfd1_594m 0 0 0 594000000 0 0 50000
>> pll2_pfd0_352m 0 0 0 352000000 0 0 50000
>> pll1 1 1 0 900000000 0 0 50000
>> pll1_bypass 1 1 0 900000000 0 0 50000
>> pll1_sys 1 1 0 900000000 0 0 50000
>> pll1_sw 1 1 0 900000000 0 0 50000
>> arm 1 1 0 900000000 0 0 50000
>> pll7_bypass_src 0 0 0 24000000 0 0 50000
>> pll6_bypass_src 0 0 0 24000000 0 0 50000
>> pll5_bypass_src 0 0 0 24000000 0 0 50000
>> pll4_bypass_src 0 0 0 24000000 0 0 50000
>> pll3_bypass_src 0 0 0 24000000 0 0 50000
>> pll2_bypass_src 0 0 0 24000000 0 0 50000
>> pll1_bypass_src 0 0 0 24000000 0 0 50000
>> ckil 0 0 0 32768 0 0 50000
>>
>>
>> Note that this was generated on a normal boot up (not failure).
>
> The values looks good. Can you try with the below diff applied?
> --->8---
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> index 334fe3130285..9771f6a82abe 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>
> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> - if (!dll_wait_time_us)
> - dll_wait_time_us = 1;
> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>
> /* Wait for the DLL to settle. */
> - udelay(dll_wait_time_us);
> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> }
>
> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
Eventually it failed, in the same way with with same errors.
Took quite a while, over 600 boot cycles.
Note also that I had to hand merge the changes, since in 5.1.14 that
gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
Regards
Greg
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-02 12:34 ` Greg Ungerer
@ 2019-08-02 12:51 ` Boris Brezillon
2019-08-05 5:51 ` Greg Ungerer
0 siblings, 1 reply; 39+ messages in thread
From: Boris Brezillon @ 2019-08-02 12:51 UTC (permalink / raw)
To: Greg Ungerer
Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
Miquel Raynal
On Fri, 2 Aug 2019 22:34:57 +1000
Greg Ungerer <gerg@kernel.org> wrote:
> Hi Boris,
>
> On 31/7/19 4:28 pm, Boris Brezillon wrote:
> > On Wed, 31 Jul 2019 12:05:44 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:
> >
> >> Hi Miquel, Boris,
> >>
> >> On 30/7/19 6:38 pm, Miquel Raynal wrote:
> >>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> >>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
> >>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
> >>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>>>> [snip]
> >>>> Not sure if this is a useful data point... But I modified that
> >>>> nand_init_data_interface() loop to start checking from data mode 4.
> >>>> So now on every boot it defaults to mode 4. That has been running
> >>>> most of the day, up to 900 boot cycles now, no failures.
> >>>
> >>> Ok so after having chatted quite a bit with Boris, it is very likely
> >>> that, for these chips, the timings in mode 5 are too tight. It could
> >>> fail the GET_FEATURES once in mode 5. Can you please dump every single
> >>> intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
> >>> use of half pêriods, tRP, sample delay, etc) as well as the content
> >>> of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
> >>> enabled and mounted).
> >>>
> >>> Also, can you be sure that the NAND chip is powered with 3.3V?
> >>
> >> Yes, 3.3V NAND chip.
> >>
> >> Using the attached patch I get the following trace:
> >>
> >> ...
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
> >> sdr->tBERS_max=65535000000
> >> sdr->tCCS_min=500000000
> >> sdr->tPROG_max=65535000000
> >> sdr->tR_max=200000000000000
> >> sdr->tALH_min=20000
> >> sdr->tADL_min=400000
> >> sdr->tALS_min=50000
> >> sdr->tAR_min=25000
> >> sdr->tCEA_max=100000
> >> sdr->tCEH_min=20000
> >> sdr->tCH_min=20000
> >> sdr->tCHZ_max=100000
> >> sdr->tCLH_min=20000
> >> sdr->tCLR_min=20000
> >> sdr->tCLS_min=50000
> >> sdr->tCOH_min=0
> >> sdr->tCS_min=70000
> >> sdr->tDH_min=20000
> >> sdr->tDS_min=40000
> >> sdr->tFEAT_max=1000000
> >> sdr->tIR_min=10000
> >> sdr->tITC_max=1000000
> >> sdr->tRC_min=100000
> >> sdr->tREA_max=40000
> >> sdr->tREH_min=30000
> >> sdr->tRHOH_min=0
> >> sdr->tRHW_min=200000
> >> sdr->tRHZ_max=200000
> >> sdr->tRLOH_min=0
> >> sdr->tRP_min=50000
> >> sdr->tRR_min=40000
> >> sdr->tRST_max=250000000000
> >> sdr->tWB_max=200000
> >> sdr->tWC_min=100000
> >> sdr->tWH_min=30000
> >> sdr->tWHR_min=120000
> >> sdr->tWP_min=50000
> >> sdr->tWW_min=100000
> >> hw->clk_rate=22000000
> >> wrn_dly_sel=0
> >> period_ps=45454
> >> addr_setup_cycles=2
> >> data_setup_cycles=1
> >> data_hold_cycles=1
> >> busy_timeout_cycles=31302
> >> hw->timing0=0x00020101
> >> hw->timing1=0x60000000
> >> dll_threshold_ps=12000
> >> use_half_period=1
> >> reference_period_ps=22727
> >> tRP_ps=45454
> >> sample_delay_ps=4294955664
> >> sample_delay_factor=0
> >> hw->ctrl1n=0x00000000
> >> hw->ctrl1n=0x00000000
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
> >> hw>clk_rate=22000000
> >> clk_set_rate(r->clock[0], hw->clk_rate)=0
> >> clk_get_rate(r->clock[0])=22000000
> >> random: fast init done
> >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >> nand: Micron MT29F2G08ABAEAWP
> >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
> >> sdr->tBERS_max=3000000000
> >> sdr->tCCS_min=100000
> >> sdr->tPROG_max=600000000
> >> sdr->tR_max=25000000
> >> sdr->tALH_min=20000
> >> sdr->tADL_min=400000
> >> sdr->tALS_min=50000
> >> sdr->tAR_min=25000
> >> sdr->tCEA_max=100000
> >> sdr->tCEH_min=20000
> >> sdr->tCH_min=20000
> >> sdr->tCHZ_max=100000
> >> sdr->tCLH_min=20000
> >> sdr->tCLR_min=20000
> >> sdr->tCLS_min=50000
> >> sdr->tCOH_min=0
> >> sdr->tCS_min=70000
> >> sdr->tDH_min=20000
> >> sdr->tDS_min=40000
> >> sdr->tFEAT_max=1000000
> >> sdr->tIR_min=10000
> >> sdr->tITC_max=1000000
> >> sdr->tRC_min=100000
> >> sdr->tREA_max=40000
> >> sdr->tREH_min=30000
> >> sdr->tRHOH_min=0
> >> sdr->tRHW_min=200000
> >> sdr->tRHZ_max=200000
> >> sdr->tRLOH_min=0
> >> sdr->tRP_min=50000
> >> sdr->tRR_min=40000
> >> sdr->tRST_max=250000000000
> >> sdr->tWB_max=200000
> >> sdr->tWC_min=100000
> >> sdr->tWH_min=30000
> >> sdr->tWHR_min=120000
> >> sdr->tWP_min=50000
> >> sdr->tWW_min=100000
> >> hw->clk_rate=22000000
> >> wrn_dly_sel=0
> >> period_ps=45454
> >> addr_setup_cycles=2
> >> data_setup_cycles=1
> >> data_hold_cycles=1
> >> busy_timeout_cycles=555
> >> hw->timing0=0x00020101
> >> hw->timing1=0xb0000000
> >> dll_threshold_ps=12000
> >> use_half_period=1
> >> reference_period_ps=22727
> >> tRP_ps=45454
> >> sample_delay_ps=4294955664
> >> sample_delay_factor=0
> >> hw->ctrl1n=0x00000000
> >> hw->ctrl1n=0x00000000
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
> >> hw>clk_rate=22000000
> >> clk_set_rate(r->clock[0], hw->clk_rate)=0
> >> clk_get_rate(r->clock[0])=22000000
> >> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> >> drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
> >> drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
> >> drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
> >> sdr->tBERS_max=3000000000
> >> sdr->tCCS_min=100000
> >> sdr->tPROG_max=600000000
> >> sdr->tR_max=25000000
> >> sdr->tALH_min=5000
> >> sdr->tADL_min=400000
> >> sdr->tALS_min=10000
> >> sdr->tAR_min=10000
> >> sdr->tCEA_max=25000
> >> sdr->tCEH_min=20000
> >> sdr->tCH_min=5000
> >> sdr->tCHZ_max=30000
> >> sdr->tCLH_min=5000
> >> sdr->tCLR_min=10000
> >> sdr->tCLS_min=10000
> >> sdr->tCOH_min=15000
> >> sdr->tCS_min=15000
> >> sdr->tDH_min=5000
> >> sdr->tDS_min=7000
> >> sdr->tFEAT_max=1000000
> >> sdr->tIR_min=0
> >> sdr->tITC_max=1000000
> >> sdr->tRC_min=20000
> >> sdr->tREA_max=16000
> >> sdr->tREH_min=7000
> >> sdr->tRHOH_min=15000
> >> sdr->tRHW_min=100000
> >> sdr->tRHZ_max=100000
> >> sdr->tRLOH_min=5000
> >> sdr->tRP_min=10000
> >> sdr->tRR_min=20000
> >> sdr->tRST_max=500000000
> >> sdr->tWB_max=100000
> >> sdr->tWC_min=20000
> >> sdr->tWH_min=7000
> >> sdr->tWHR_min=80000
> >> sdr->tWP_min=10000
> >> sdr->tWW_min=100000
> >> hw->clk_rate=100000000
> >> wrn_dly_sel=3
> >> period_ps=10000
> >> addr_setup_cycles=1
> >> data_setup_cycles=1
> >> data_hold_cycles=1
> >> busy_timeout_cycles=2510
> >> hw->timing0=0x00010101
> >> hw->timing1=0xe0000000
> >> dll_threshold_ps=12000
> >> use_half_period=0
> >> reference_period_ps=10000
> >> tRP_ps=10000
> >> sample_delay_ps=80000
> >> sample_delay_factor=8
> >> hw->ctrl1n=0x00c00000
> >> hw->ctrl1n=0x00c28000
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
> >> hw>clk_rate=100000000
> >> clk_set_rate(r->clock[0], hw->clk_rate)=0
> >> clk_get_rate(r->clock[0])=99000000
> >> Scanning device for bad blocks
> >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> >> Creating 5 MTD partitions on "gpmi-nand":
> >> 0x000000000000-0x000000500000 : "u-boot"
> >> 0x000000500000-0x000000600000 : "u-boot-env"
> >> 0x000000600000-0x000000800000 : "log"
> >> 0x000000800000-0x000010000000 : "flash"
> >> 0x000000000000-0x000010000000 : "all"
> >> gpmi-nand 1806000.gpmi-nand: driver registered.
> >> ...
> >>
> >>
> >> And "cat /sys/kernel/debug/clk/clk_summary" gives:
> >>
> >> enable prepare protect duty
> >> clock count count count rate accuracy phase cycle
> >> ---------------------------------------------------------------------------------------------
> >> dummy 2 2 0 0 0 0 50000
> >> cko2_sel 0 0 0 0 0 0 50000
> >> cko2_podf 0 0 0 0 0 0 50000
> >> cko2 0 0 0 0 0 0 50000
> >> cko1_sel 0 0 0 0 0 0 50000
> >> cko1_podf 0 0 0 0 0 0 50000
> >> cko1 0 0 0 0 0 0 50000
> >> cko 0 0 0 0 0 0 50000
> >> usbphy2_gate 1 1 0 0 0 0 50000
> >> usbphy1_gate 1 1 0 0 0 0 50000
> >> ipp_di1 0 0 0 0 0 0 50000
> >> ipp_di0 0 0 0 0 0 0 50000
> >> osc 6 6 0 24000000 0 0 50000
> >> perclk_sel 1 1 0 24000000 0 0 50000
> >> perclk 3 3 0 24000000 0 0 50000
> >> pwm7 0 0 0 24000000 0 0 50000
> >> pwm6 0 0 0 24000000 0 0 50000
> >> pwm5 0 0 0 24000000 0 0 50000
> >> i2c4 0 0 0 24000000 0 0 50000
> >> pwm8 0 0 0 24000000 0 0 50000
> >> pwm4 0 0 0 24000000 0 0 50000
> >> pwm3 0 0 0 24000000 0 0 50000
> >> pwm2 0 0 0 24000000 0 0 50000
> >> pwm1 0 0 0 24000000 0 0 50000
> >> i2c3 0 0 0 24000000 0 0 50000
> >> i2c2 1 1 0 24000000 0 0 50000
> >> i2c1 0 0 0 24000000 0 0 50000
> >> gpt1_serial 1 1 0 24000000 0 0 50000
> >> gpt1_bus 1 1 0 24000000 0 0 50000
> >> epit2 0 0 0 24000000 0 0 50000
> >> epit1 0 0 0 24000000 0 0 50000
> >> gpt2_serial 0 0 0 24000000 0 0 50000
> >> gpt2_bus 0 0 0 24000000 0 0 50000
> >> periph_clk2_sel 0 0 0 24000000 0 0 50000
> >> periph_clk2 0 0 0 24000000 0 0 50000
> >> gpt_3m 0 0 0 3000000 0 0 50000
> >> csi_sel 0 0 0 24000000 0 0 50000
> >> csi_podf 0 0 0 24000000 0 0 50000
> >> csi 0 0 0 24000000 0 0 50000
> >> pll7 1 1 0 480000000 0 0 50000
> >> pll7_bypass 1 1 0 480000000 0 0 50000
> >> pll7_usb_host 1 1 0 480000000 0 0 50000
> >> usbphy2 1 1 0 480000000 0 0 50000
> >> pll6 1 1 0 500000000 0 0 50000
> >> pll6_bypass 1 1 0 500000000 0 0 50000
> >> pll6_enet 2 2 0 500000000 0 0 50000
> >> enet_ptp_ref 1 1 0 25000000 0 0 50000
> >> enet_ptp 1 1 0 25000000 0 0 50000
> >> enet2_ref 0 0 0 50000000 0 0 50000
> >> enet_ref_125m 0 0 0 50000000 0 0 50000
> >> enet_ref 2 2 0 50000000 0 0 50000
> >> pll5 0 0 0 296600000 0 0 50000
> >> pll5_bypass 0 0 0 296600000 0 0 50000
> >> pll5_video 0 0 0 296600000 0 0 50000
> >> pll5_post_div 0 0 0 74150000 0 0 50000
> >> pll5_video_div 0 0 0 74150000 0 0 50000
> >> pll4 0 0 0 147456000 0 0 50000
> >> pll4_bypass 0 0 0 147456000 0 0 50000
> >> pll4_audio 0 0 0 147456000 0 0 50000
> >> pll4_post_div 0 0 0 36864000 0 0 50000
> >> pll4_audio_div 0 0 0 36864000 0 0 50000
> >> pll3 1 1 0 480000000 0 0 50000
> >> pll3_bypass 1 1 0 480000000 0 0 50000
> >> pll3_usb_otg 2 2 0 480000000 0 0 50000
> >> spdif_sel 0 0 0 480000000 0 0 50000
> >> spdif_pred 0 0 0 240000000 0 0 50000
> >> spdif_podf 0 0 0 30000000 0 0 50000
> >> spdif 0 0 0 30000000 0 0 50000
> >> esai_sel 0 0 0 480000000 0 0 50000
> >> esai_pred 0 0 0 240000000 0 0 50000
> >> esai_podf 0 0 0 30000000 0 0 50000
> >> esai_extal 0 0 0 30000000 0 0 50000
> >> qspi1_sel 0 0 0 480000000 0 0 50000
> >> qspi1_podf 0 0 0 240000000 0 0 50000
> >> qspi1 0 0 0 240000000 0 0 50000
> >> ldb_di1_div_7 0 0 0 68571428 0 0 50000
> >> ldb_di1 0 0 0 68571428 0 0 50000
> >> ldb_di1_div_3_5 0 0 0 137142857 0 0 50000
> >> periph2_clk2_sel 0 0 0 480000000 0 0 50000
> >> periph2_clk2 0 0 0 480000000 0 0 50000
> >> pll3_60m 0 0 0 60000000 0 0 50000
> >> can_sel 0 0 0 60000000 0 0 50000
> >> can_podf 0 0 0 30000000 0 0 50000
> >> can2_serial 0 0 0 30000000 0 0 50000
> >> can1_serial 0 0 0 30000000 0 0 50000
> >> ecspi_sel 0 0 0 60000000 0 0 50000
> >> ecspi_podf 0 0 0 60000000 0 0 50000
> >> ecspi4 0 0 0 60000000 0 0 50000
> >> ecspi3 0 0 0 60000000 0 0 50000
> >> ecspi2 0 0 0 60000000 0 0 50000
> >> ecspi1 0 0 0 60000000 0 0 50000
> >> pll3_80m 1 1 0 80000000 0 0 50000
> >> uart_sel 1 1 0 80000000 0 0 50000
> >> uart_podf 1 1 0 80000000 0 0 50000
> >> uart8_serial 0 0 0 80000000 0 0 50000
> >> uart7_serial 0 0 0 80000000 0 0 50000
> >> uart1_serial 1 2 0 80000000 0 0 50000
> >> uart6_serial 0 0 0 80000000 0 0 50000
> >> uart5_serial 0 0 0 80000000 0 0 50000
> >> uart4_serial 0 0 0 80000000 0 0 50000
> >> uart3_serial 0 0 0 80000000 0 0 50000
> >> uart2_serial 0 0 0 80000000 0 0 50000
> >> pll3_pfd3_454m 0 0 0 454736842 0 0 50000
> >> pll3_pfd2_508m 0 0 0 508235294 0 0 50000
> >> epdc_pre_sel 0 0 0 508235294 0 0 50000
> >> epdc_podf 0 0 0 254117647 0 0 50000
> >> epdc_pix 0 0 0 254117647 0 0 50000
> >> epdc_sel 0 0 0 254117647 0 0 50000
> >> sai1_sel 0 0 0 508235294 0 0 50000
> >> sai1_pred 0 0 0 127058824 0 0 50000
> >> sai1_podf 0 0 0 63529412 0 0 50000
> >> sai1 0 0 0 63529412 0 0 50000
> >> sai2_sel 0 0 0 508235294 0 0 50000
> >> sai2_pred 0 0 0 127058824 0 0 50000
> >> sai2_podf 0 0 0 63529412 0 0 50000
> >> sai2 0 0 0 63529412 0 0 50000
> >> sai3_sel 0 0 0 508235294 0 0 50000
> >> sai3_pred 0 0 0 127058824 0 0 50000
> >> sai3_podf 0 0 0 63529412 0 0 50000
> >> sai3 0 0 0 63529412 0 0 50000
> >> pll3_pfd1_540m 0 0 0 540000000 0 0 50000
> >> lcdif_pre_sel 0 0 0 540000000 0 0 50000
> >> lcdif_pred 0 0 0 270000000 0 0 50000
> >> lcdif_podf 0 0 0 135000000 0 0 50000
> >> lcdif_pix 0 0 0 135000000 0 0 50000
> >> iomuxc 0 0 0 135000000 0 0 50000
> >> lcdif_sel 0 0 0 135000000 0 0 50000
> >> pll3_pfd0_720m 0 0 0 720000000 0 0 50000
> >> usbphy1 1 1 0 480000000 0 0 50000
> >> pll2 1 1 0 528000000 0 0 50000
> >> pll2_bypass 1 1 0 528000000 0 0 50000
> >> pll2_bus 2 2 0 528000000 0 0 50000
> >> ca7_secondary_sel 0 0 0 528000000 0 0 50000
> >> step 0 0 0 528000000 0 0 50000
> >> periph_pre 1 1 0 528000000 0 0 50000
> >> periph 3 3 0 528000000 0 0 50000
> >> ahb 7 7 0 132000000 0 0 50000
> >> sdma 0 0 0 132000000 0 0 50000
> >> rom 1 1 0 132000000 0 0 50000
> >> esai_mem 0 0 0 132000000 0 0 50000
> >> esai_ipg 0 0 0 132000000 0 0 50000
> >> aips_tz3 1 1 0 132000000 0 0 50000
> >> enet_ahb 2 2 0 132000000 0 0 50000
> >> dcp 0 0 0 132000000 0 0 50000
> >> asrc_mem 0 0 0 132000000 0 0 50000
> >> asrc_ipg 0 0 0 132000000 0 0 50000
> >> aips_tz2 1 1 0 132000000 0 0 50000
> >> aips_tz1 1 1 0 132000000 0 0 50000
> >> ipg 10 10 0 66000000 0 0 50000
> >> wdog3 0 0 0 66000000 0 0 50000
> >> uart8_ipg 0 0 0 66000000 0 0 50000
> >> usboh3 2 2 0 66000000 0 0 50000
> >> sai2_ipg 0 0 0 66000000 0 0 50000
> >> sai1_ipg 0 0 0 66000000 0 0 50000
> >> uart7_ipg 0 0 0 66000000 0 0 50000
> >> uart1_ipg 1 2 0 66000000 0 0 50000
> >> sai3_ipg 0 0 0 66000000 0 0 50000
> >> spdif_gclk 0 0 0 66000000 0 0 50000
> >> spba 0 0 0 66000000 0 0 50000
> >> wdog2 0 0 0 66000000 0 0 50000
> >> kpp 0 0 0 66000000 0 0 50000
> >> mmdc_p1_ipg 0 0 0 66000000 0 0 50000
> >> mmdc_p0_ipg 2 2 0 66000000 0 0 50000
> >> wdog1 1 1 0 66000000 0 0 50000
> >> gpio4 1 1 0 66000000 0 0 50000
> >> uart6_ipg 0 0 0 66000000 0 0 50000
> >> uart5_ipg 0 0 0 66000000 0 0 50000
> >> gpio3 1 1 0 66000000 0 0 50000
> >> ocotp 0 0 0 66000000 0 0 50000
> >> gpio5 1 1 0 66000000 0 0 50000
> >> gpio1 1 1 0 66000000 0 0 50000
> >> uart4_ipg 0 0 0 66000000 0 0 50000
> >> adc1 0 0 0 66000000 0 0 50000
> >> uart3_ipg 0 0 0 66000000 0 0 50000
> >> adc2 0 0 0 66000000 0 0 50000
> >> gpio2 1 1 0 66000000 0 0 50000
> >> uart2_ipg 0 0 0 66000000 0 0 50000
> >> can2_ipg 0 0 0 66000000 0 0 50000
> >> can1_ipg 0 0 0 66000000 0 0 50000
> >> enet 2 2 0 66000000 0 0 50000
> >> axi_sel 1 1 0 528000000 0 0 50000
> >> axi_podf 2 2 0 264000000 0 0 50000
> >> axi 1 1 0 264000000 0 0 50000
> >> eim_slow_sel 0 0 0 264000000 0 0 50000
> >> eim_slow_podf 0 0 0 132000000 0 0 50000
> >> eim 0 0 0 132000000 0 0 50000
> >> lcdif_apb 0 0 0 264000000 0 0 50000
> >> pxp 0 0 0 264000000 0 0 50000
> >> epdc_aclk 0 0 0 264000000 0 0 50000
> >> pll2_pfd3_594m 0 0 0 594000000 0 0 50000
> >> ldb_di0_sel 0 0 0 594000000 0 0 50000
> >> ldb_di0_div_7 0 0 0 84857142 0 0 50000
> >> ldb_di0 0 0 0 84857142 0 0 50000
> >> ldb_di0_div_3_5 0 0 0 169714285 0 0 50000
> >> pll2_pfd2_396m 2 2 0 396000000 0 0 50000
> >> enfc_sel 0 0 0 396000000 0 0 50000
> >> enfc_pred 0 0 0 99000000 0 0 50000
> >> enfc_podf 0 0 0 99000000 0 0 50000
> >> gpmi_io 0 0 0 99000000 0 0 50000
> >> usdhc1_sel 0 0 0 396000000 0 0 50000
> >> usdhc1_podf 0 0 0 198000000 0 0 50000
> >> usdhc1 0 0 0 198000000 0 0 50000
> >> usdhc2_sel 0 0 0 396000000 0 0 50000
> >> usdhc2_podf 0 0 0 198000000 0 0 50000
> >> usdhc2 0 0 0 198000000 0 0 50000
> >> bch_sel 1 1 0 396000000 0 0 50000
> >> bch_podf 1 1 0 99000000 0 0 50000
> >> gpmi_apb 0 0 0 99000000 0 0 50000
> >> gpmi_bch_apb 0 0 0 99000000 0 0 50000
> >> per_bch 0 0 0 99000000 0 0 50000
> >> apbh_dma 1 1 0 99000000 0 0 50000
> >> gpmi_sel 0 0 0 396000000 0 0 50000
> >> gpmi_podf 0 0 0 99000000 0 0 50000
> >> gpmi_bch 0 0 0 99000000 0 0 50000
> >> periph2_pre 1 1 0 396000000 0 0 50000
> >> periph2 2 2 0 396000000 0 0 50000
> >> mmdc_podf 2 2 0 396000000 0 0 50000
> >> mmdc_p0_fast 1 1 0 396000000 0 0 50000
> >> axi_alt_sel 0 0 0 396000000 0 0 50000
> >> pll2_198m 0 0 0 198000000 0 0 50000
> >> pll2_pfd1_594m 0 0 0 594000000 0 0 50000
> >> pll2_pfd0_352m 0 0 0 352000000 0 0 50000
> >> pll1 1 1 0 900000000 0 0 50000
> >> pll1_bypass 1 1 0 900000000 0 0 50000
> >> pll1_sys 1 1 0 900000000 0 0 50000
> >> pll1_sw 1 1 0 900000000 0 0 50000
> >> arm 1 1 0 900000000 0 0 50000
> >> pll7_bypass_src 0 0 0 24000000 0 0 50000
> >> pll6_bypass_src 0 0 0 24000000 0 0 50000
> >> pll5_bypass_src 0 0 0 24000000 0 0 50000
> >> pll4_bypass_src 0 0 0 24000000 0 0 50000
> >> pll3_bypass_src 0 0 0 24000000 0 0 50000
> >> pll2_bypass_src 0 0 0 24000000 0 0 50000
> >> pll1_bypass_src 0 0 0 24000000 0 0 50000
> >> ckil 0 0 0 32768 0 0 50000
> >>
> >>
> >> Note that this was generated on a normal boot up (not failure).
> >
> > The values looks good. Can you try with the below diff applied?
> > --->8---
> > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > index 334fe3130285..9771f6a82abe 100644
> > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >
> > /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> > - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> > - if (!dll_wait_time_us)
> > - dll_wait_time_us = 1;
> > + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >
> > /* Wait for the DLL to settle. */
> > - udelay(dll_wait_time_us);
> > + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> > }
> >
> > static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>
> Eventually it failed, in the same way with with same errors.
> Took quite a while, over 600 boot cycles.
>
> Note also that I had to hand merge the changes, since in 5.1.14 that
> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
Oh well. I guess the next thing to do would be to dump the timing regs
and clk rate that are set by the bootloader (before the driver override
them) or those applied by an older kernel (one that didn't have that
issue).
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-02 12:51 ` Boris Brezillon
@ 2019-08-05 5:51 ` Greg Ungerer
2019-08-07 16:05 ` Miquel Raynal
2019-08-08 16:36 ` Boris Brezillon
0 siblings, 2 replies; 39+ messages in thread
From: Greg Ungerer @ 2019-08-05 5:51 UTC (permalink / raw)
To: Boris Brezillon
Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
Miquel Raynal
[-- Attachment #1: Type: text/plain, Size: 3937 bytes --]
Hi Boris,
On 2/8/19 10:51 pm, Boris Brezillon wrote:
> On Fri, 2 Aug 2019 22:34:57 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>> [snip]
>>>> Note that this was generated on a normal boot up (not failure).
>>>
>>> The values looks good. Can you try with the below diff applied?
>>> --->8---
>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>> index 334fe3130285..9771f6a82abe 100644
>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>
>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>> - if (!dll_wait_time_us)
>>> - dll_wait_time_us = 1;
>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>
>>> /* Wait for the DLL to settle. */
>>> - udelay(dll_wait_time_us);
>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>> }
>>>
>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>
>> Eventually it failed, in the same way with with same errors.
>> Took quite a while, over 600 boot cycles.
>>
>> Note also that I had to hand merge the changes, since in 5.1.14 that
>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>
> Oh well. I guess the next thing to do would be to dump the timing regs
> and clk rate that are set by the bootloader (before the driver override
> them) or those applied by an older kernel (one that didn't have that
> issue).
Is this useful?
With attached patch, I get the following dump of the timing
settings in use:
...
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
HW_GPMI_TIMING1=0x00000000 (calculated=0x60000000)
HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
r->clock[0]=22000000 (calculated=22000000)
random: fast init done
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
HW_GPMI_TIMING1=0x00000000 (calculated=0xb0000000)
HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
r->clock[0]=22000000 (calculated=22000000)
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
HW_GPMI_TIMING0=0x00010203 (calculated=0x00010101)
HW_GPMI_TIMING1=0x00000000 (calculated=0xe0000000)
HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00c28000)
r->clock[0]=22000000 (calculated=100000000)
Scanning device for bad blocks
5 fixed-partitions partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...
Regards
Greg
[-- Attachment #2: gpmi-nand-default-timing.patch --]
[-- Type: text/x-patch, Size: 1042 bytes --]
[-- Attachment #3: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-05 5:51 ` Greg Ungerer
@ 2019-08-07 16:05 ` Miquel Raynal
2019-08-08 0:43 ` Greg Ungerer
2019-08-08 16:36 ` Boris Brezillon
1 sibling, 1 reply; 39+ messages in thread
From: Miquel Raynal @ 2019-08-07 16:05 UTC (permalink / raw)
To: Greg Ungerer
Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
Boris Brezillon
Hi Greg,
Greg Ungerer <gerg@kernel.org> wrote on Mon, 5 Aug 2019 15:51:05 +1000:
> Hi Boris,
>
> On 2/8/19 10:51 pm, Boris Brezillon wrote:
> > On Fri, 2 Aug 2019 22:34:57 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:
> >> On 31/7/19 4:28 pm, Boris Brezillon wrote:
> >>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
> >>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> >>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
> >>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
> >>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> >>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>>>>>> [snip]
> >>>> Note that this was generated on a normal boot up (not failure).
> >>>
> >>> The values looks good. Can you try with the below diff applied?
> >>> --->8---
> >>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> index 334fe3130285..9771f6a82abe 100644
> >>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>> >>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>> - if (!dll_wait_time_us)
> >>> - dll_wait_time_us = 1;
> >>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>> >>> /* Wait for the DLL to settle. */
> >>> - udelay(dll_wait_time_us);
> >>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>> }
> >>> >>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>
> >> Eventually it failed, in the same way with with same errors.
> >> Took quite a while, over 600 boot cycles.
> >>
> >> Note also that I had to hand merge the changes, since in 5.1.14 that
> >> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
> >
> > Oh well. I guess the next thing to do would be to dump the timing regs
> > and clk rate that are set by the bootloader (before the driver override
> > them) or those applied by an older kernel (one that didn't have that
> > issue).
>
> Is this useful?
>
> With attached patch, I get the following dump of the timing
> settings in use:
>
> ...
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
> HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
> HW_GPMI_TIMING1=0x00000000 (calculated=0x60000000)
> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
> r->clock[0]=22000000 (calculated=22000000)
> random: fast init done
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
> HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
> HW_GPMI_TIMING1=0x00000000 (calculated=0xb0000000)
> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
> r->clock[0]=22000000 (calculated=22000000)
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
> HW_GPMI_TIMING0=0x00010203 (calculated=0x00010101)
> HW_GPMI_TIMING1=0x00000000 (calculated=0xe0000000)
> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00c28000)
> r->clock[0]=22000000 (calculated=100000000)
Why are the registers not updated? Is it the same situation when we
get all the failures?
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-07 16:05 ` Miquel Raynal
@ 2019-08-08 0:43 ` Greg Ungerer
0 siblings, 0 replies; 39+ messages in thread
From: Greg Ungerer @ 2019-08-08 0:43 UTC (permalink / raw)
To: Miquel Raynal
Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
Boris Brezillon
Hi Miquel,
On 8/8/19 2:05 am, Miquel Raynal wrote:
> Greg Ungerer <gerg@kernel.org> wrote on Mon, 5 Aug 2019 15:51:05 +1000:
>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>> [snip]
>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>
>>>>> The values looks good. Can you try with the below diff applied?
>>>>> --->8---
>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>> >>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>> - if (!dll_wait_time_us)
>>>>> - dll_wait_time_us = 1;
>>>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>> >>> /* Wait for the DLL to settle. */
>>>>> - udelay(dll_wait_time_us);
>>>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>> }
>>>>> >>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>
>>>> Eventually it failed, in the same way with with same errors.
>>>> Took quite a while, over 600 boot cycles.
>>>>
>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>
>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>> and clk rate that are set by the bootloader (before the driver override
>>> them) or those applied by an older kernel (one that didn't have that
>>> issue).
>>
>> Is this useful?
>>
>> With attached patch, I get the following dump of the timing
>> settings in use:
>>
>> ...
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>> HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
>> HW_GPMI_TIMING1=0x00000000 (calculated=0x60000000)
>> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
>> r->clock[0]=22000000 (calculated=22000000)
>> random: fast init done
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>> HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
>> HW_GPMI_TIMING1=0x00000000 (calculated=0xb0000000)
>> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
>> r->clock[0]=22000000 (calculated=22000000)
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>> HW_GPMI_TIMING0=0x00010203 (calculated=0x00010101)
>> HW_GPMI_TIMING1=0x00000000 (calculated=0xe0000000)
>> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00c28000)
>> r->clock[0]=22000000 (calculated=100000000)
>
> Why are the registers not updated? Is it the same situation when we
> get all the failures?
As per the patch that was attached to that email. The setting of the
registers and clock was "#if 0" out so you could see what the
power-up/boot-loader settings are. Those settings work reliably
with no nand failures. In between running various tests I have
left my hardware boot cycle testing with those settings. I don't
have an exact number but it has probably run at least 100 hours
and tens of thousands of boots with no problem using those.
Or am I misunderstanding your question?
Regards
Greg
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-05 5:51 ` Greg Ungerer
2019-08-07 16:05 ` Miquel Raynal
@ 2019-08-08 16:36 ` Boris Brezillon
2019-08-09 5:20 ` Greg Ungerer
1 sibling, 1 reply; 39+ messages in thread
From: Boris Brezillon @ 2019-08-08 16:36 UTC (permalink / raw)
To: Greg Ungerer
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
On Mon, 5 Aug 2019 15:51:05 +1000
Greg Ungerer <gerg@kernel.org> wrote:
> Hi Boris,
>
> On 2/8/19 10:51 pm, Boris Brezillon wrote:
> > On Fri, 2 Aug 2019 22:34:57 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:
> >> On 31/7/19 4:28 pm, Boris Brezillon wrote:
> >>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
> >>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> >>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
> >>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
> >>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> >>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>>>>>> [snip]
> >>>> Note that this was generated on a normal boot up (not failure).
> >>>
> >>> The values looks good. Can you try with the below diff applied?
> >>> --->8---
> >>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> index 334fe3130285..9771f6a82abe 100644
> >>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>>
> >>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>> - if (!dll_wait_time_us)
> >>> - dll_wait_time_us = 1;
> >>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>>
> >>> /* Wait for the DLL to settle. */
> >>> - udelay(dll_wait_time_us);
> >>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>> }
> >>>
> >>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>
> >> Eventually it failed, in the same way with with same errors.
> >> Took quite a while, over 600 boot cycles.
> >>
> >> Note also that I had to hand merge the changes, since in 5.1.14 that
> >> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
> >
> > Oh well. I guess the next thing to do would be to dump the timing regs
> > and clk rate that are set by the bootloader (before the driver override
> > them) or those applied by an older kernel (one that didn't have that
> > issue).
>
> Is this useful?
Hm, looks like it's configured in mode 0, so no, it's not super useful.
Can you try booting an older kernel (one that didn't have the
->setup_data_interface() hook implemented).
>
> With attached patch, I get the following dump of the timing
> settings in use:
>
> ...
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
> HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
> HW_GPMI_TIMING1=0x00000000 (calculated=0x60000000)
> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
> r->clock[0]=22000000 (calculated=22000000)
> random: fast init done
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
> HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
> HW_GPMI_TIMING1=0x00000000 (calculated=0xb0000000)
> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
> r->clock[0]=22000000 (calculated=22000000)
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
> HW_GPMI_TIMING0=0x00010203 (calculated=0x00010101)
> HW_GPMI_TIMING1=0x00000000 (calculated=0xe0000000)
> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00c28000)
> r->clock[0]=22000000 (calculated=100000000)
> Scanning device for bad blocks
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
>
> Regards
> Greg
>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-08 16:36 ` Boris Brezillon
@ 2019-08-09 5:20 ` Greg Ungerer
2019-08-09 6:23 ` Boris Brezillon
0 siblings, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-08-09 5:20 UTC (permalink / raw)
To: Boris Brezillon
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
Hi Boris,
On 9/8/19 2:36 am, Boris Brezillon wrote:
> On Mon, 5 Aug 2019 15:51:05 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>> [snip]
>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>
>>>>> The values looks good. Can you try with the below diff applied?
>>>>> --->8---
>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>
>>>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>> - if (!dll_wait_time_us)
>>>>> - dll_wait_time_us = 1;
>>>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>
>>>>> /* Wait for the DLL to settle. */
>>>>> - udelay(dll_wait_time_us);
>>>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>> }
>>>>>
>>>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>
>>>> Eventually it failed, in the same way with with same errors.
>>>> Took quite a while, over 600 boot cycles.
>>>>
>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>
>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>> and clk rate that are set by the bootloader (before the driver override
>>> them) or those applied by an older kernel (one that didn't have that
>>> issue).
>>
>> Is this useful?
>
> Hm, looks like it's configured in mode 0, so no, it's not super useful.
> Can you try booting an older kernel (one that didn't have the
> ->setup_data_interface() hook implemented).
Ok. I went back from 5.1 and the first kernel I could find that
returned no grep hits for "setup_data_interface" was 4.16.
So I built for my target with that and added similar trace to dump
the hardware register settings for that. Debug output looks like
this now for it:
...
drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
clk_get_rate(r->clock[0])=22000000
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
HW_GPMI_TIMING0=0x00010203
HW_GPMI_TIMING1=0x05000000
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
clk_get_rate(r->clock[0])=99000000
gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
HW_GPMI_TIMING0=0x00010101
HW_GPMI_TIMING1=0x90000000
Scanning device for bad blocks
5 ofpart partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...
I am running boot tests now on this to confirm it actually runs
reliably.
Regards
Greg
>> With attached patch, I get the following dump of the timing
>> settings in use:
>>
>> ...
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>> HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
>> HW_GPMI_TIMING1=0x00000000 (calculated=0x60000000)
>> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
>> r->clock[0]=22000000 (calculated=22000000)
>> random: fast init done
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>> HW_GPMI_TIMING0=0x00010203 (calculated=0x00020101)
>> HW_GPMI_TIMING1=0x00000000 (calculated=0xb0000000)
>> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00000000)
>> r->clock[0]=22000000 (calculated=22000000)
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>> HW_GPMI_TIMING0=0x00010203 (calculated=0x00010101)
>> HW_GPMI_TIMING1=0x00000000 (calculated=0xe0000000)
>> HW_GPMI_CTRL1_SET=0x01c4000c (calculated=0x00c28000)
>> r->clock[0]=22000000 (calculated=100000000)
>> Scanning device for bad blocks
>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>> ...
>>
>> Regards
>> Greg
>>
>>
>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-09 5:20 ` Greg Ungerer
@ 2019-08-09 6:23 ` Boris Brezillon
2019-08-09 6:55 ` Greg Ungerer
0 siblings, 1 reply; 39+ messages in thread
From: Boris Brezillon @ 2019-08-09 6:23 UTC (permalink / raw)
To: Greg Ungerer
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
On Fri, 9 Aug 2019 15:20:52 +1000
Greg Ungerer <gerg@kernel.org> wrote:
> Hi Boris,
>
> On 9/8/19 2:36 am, Boris Brezillon wrote:
> > On Mon, 5 Aug 2019 15:51:05 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:
> >> On 2/8/19 10:51 pm, Boris Brezillon wrote:
> >>> On Fri, 2 Aug 2019 22:34:57 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
> >>>>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> >>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
> >>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
> >>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> >>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> >>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>>>>>>>> [snip]
> >>>>>> Note that this was generated on a normal boot up (not failure).
> >>>>>
> >>>>> The values looks good. Can you try with the below diff applied?
> >>>>> --->8---
> >>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>> index 334fe3130285..9771f6a82abe 100644
> >>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>>>>
> >>>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>>>> - if (!dll_wait_time_us)
> >>>>> - dll_wait_time_us = 1;
> >>>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>>>>
> >>>>> /* Wait for the DLL to settle. */
> >>>>> - udelay(dll_wait_time_us);
> >>>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>>>> }
> >>>>>
> >>>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>>>
> >>>> Eventually it failed, in the same way with with same errors.
> >>>> Took quite a while, over 600 boot cycles.
> >>>>
> >>>> Note also that I had to hand merge the changes, since in 5.1.14 that
> >>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
> >>>
> >>> Oh well. I guess the next thing to do would be to dump the timing regs
> >>> and clk rate that are set by the bootloader (before the driver override
> >>> them) or those applied by an older kernel (one that didn't have that
> >>> issue).
> >>
> >> Is this useful?
> >
> > Hm, looks like it's configured in mode 0, so no, it's not super useful.
> > Can you try booting an older kernel (one that didn't have the
> > ->setup_data_interface() hook implemented).
>
> Ok. I went back from 5.1 and the first kernel I could find that
> returned no grep hits for "setup_data_interface" was 4.16.
>
> So I built for my target with that and added similar trace to dump
> the hardware register settings for that. Debug output looks like
> this now for it:
>
> ...
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
> clk_get_rate(r->clock[0])=22000000
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> HW_GPMI_TIMING0=0x00010203
> HW_GPMI_TIMING1=0x05000000
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
> clk_get_rate(r->clock[0])=99000000
> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> HW_GPMI_TIMING0=0x00010101
TIMING0 match the one you have with 5.1 kernels.
> HW_GPMI_TIMING1=0x90000000
And we even have a bigger timeout value in 5.1 (0xe0000000), so we
should be all safe WRT to timings in TIMING{0,1}.
Can you dump CTRL1?
> Scanning device for bad blocks
> 5 ofpart partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-09 6:23 ` Boris Brezillon
@ 2019-08-09 6:55 ` Greg Ungerer
2019-08-09 7:32 ` Boris Brezillon
0 siblings, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-08-09 6:55 UTC (permalink / raw)
To: Boris Brezillon
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
On 9/8/19 4:23 pm, Boris Brezillon wrote:
> On Fri, 9 Aug 2019 15:20:52 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>> On 9/8/19 2:36 am, Boris Brezillon wrote:
>>> On Mon, 5 Aug 2019 15:51:05 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>>>> [snip]
>>>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>>>
>>>>>>> The values looks good. Can you try with the below diff applied?
>>>>>>> --->8---
>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>>>
>>>>>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>>>> - if (!dll_wait_time_us)
>>>>>>> - dll_wait_time_us = 1;
>>>>>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>>>
>>>>>>> /* Wait for the DLL to settle. */
>>>>>>> - udelay(dll_wait_time_us);
>>>>>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>>>> }
>>>>>>>
>>>>>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>>>
>>>>>> Eventually it failed, in the same way with with same errors.
>>>>>> Took quite a while, over 600 boot cycles.
>>>>>>
>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>>>
>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>>>> and clk rate that are set by the bootloader (before the driver override
>>>>> them) or those applied by an older kernel (one that didn't have that
>>>>> issue).
>>>>
>>>> Is this useful?
>>>
>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
>>> Can you try booting an older kernel (one that didn't have the
>>> ->setup_data_interface() hook implemented).
>>
>> Ok. I went back from 5.1 and the first kernel I could find that
>> returned no grep hits for "setup_data_interface" was 4.16.
>>
>> So I built for my target with that and added similar trace to dump
>> the hardware register settings for that. Debug output looks like
>> this now for it:
>>
>> ...
>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
>> clk_get_rate(r->clock[0])=22000000
>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>> HW_GPMI_TIMING0=0x00010203
>> HW_GPMI_TIMING1=0x05000000
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
>> clk_get_rate(r->clock[0])=99000000
>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>> HW_GPMI_TIMING0=0x00010101
>
> TIMING0 match the one you have with 5.1 kernels.
>
>> HW_GPMI_TIMING1=0x90000000
>
> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
> should be all safe WRT to timings in TIMING{0,1}.
>
> Can you dump CTRL1?
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
HW_GPMI_TIMING0=0x00010101
HW_GPMI_TIMING1=0x90000000
HW_GPMI_CTRL1_SET=0x01c4800c
Scanning device for bad blocks
5 ofpart partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
Regards
Greg
>> Scanning device for bad blocks
>> 5 ofpart partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>> ...
>>
>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-09 6:55 ` Greg Ungerer
@ 2019-08-09 7:32 ` Boris Brezillon
2019-08-09 13:57 ` Greg Ungerer
0 siblings, 1 reply; 39+ messages in thread
From: Boris Brezillon @ 2019-08-09 7:32 UTC (permalink / raw)
To: Greg Ungerer
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
On Fri, 9 Aug 2019 16:55:22 +1000
Greg Ungerer <gerg@kernel.org> wrote:
> On 9/8/19 4:23 pm, Boris Brezillon wrote:
> > On Fri, 9 Aug 2019 15:20:52 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:
> >> On 9/8/19 2:36 am, Boris Brezillon wrote:
> >>> On Mon, 5 Aug 2019 15:51:05 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
> >>>>> On Fri, 2 Aug 2019 22:34:57 +1000
> >>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
> >>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> >>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
> >>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
> >>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> >>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> >>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>>>>>>>>>> [snip]
> >>>>>>>> Note that this was generated on a normal boot up (not failure).
> >>>>>>>
> >>>>>>> The values looks good. Can you try with the below diff applied?
> >>>>>>> --->8---
> >>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>> index 334fe3130285..9771f6a82abe 100644
> >>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>>>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>>>>>>
> >>>>>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>>>>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>>>>>> - if (!dll_wait_time_us)
> >>>>>>> - dll_wait_time_us = 1;
> >>>>>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>>>>>>
> >>>>>>> /* Wait for the DLL to settle. */
> >>>>>>> - udelay(dll_wait_time_us);
> >>>>>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>>>>>> }
> >>>>>>>
> >>>>>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>>>>>
> >>>>>> Eventually it failed, in the same way with with same errors.
> >>>>>> Took quite a while, over 600 boot cycles.
> >>>>>>
> >>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
> >>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
> >>>>>
> >>>>> Oh well. I guess the next thing to do would be to dump the timing regs
> >>>>> and clk rate that are set by the bootloader (before the driver override
> >>>>> them) or those applied by an older kernel (one that didn't have that
> >>>>> issue).
> >>>>
> >>>> Is this useful?
> >>>
> >>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
> >>> Can you try booting an older kernel (one that didn't have the
> >>> ->setup_data_interface() hook implemented).
> >>
> >> Ok. I went back from 5.1 and the first kernel I could find that
> >> returned no grep hits for "setup_data_interface" was 4.16.
> >>
> >> So I built for my target with that and added similar trace to dump
> >> the hardware register settings for that. Debug output looks like
> >> this now for it:
> >>
> >> ...
> >> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
> >> clk_get_rate(r->clock[0])=22000000
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >> HW_GPMI_TIMING0=0x00010203
> >> HW_GPMI_TIMING1=0x05000000
> >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >> nand: Micron MT29F2G08ABAEAWP
> >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
> >> clk_get_rate(r->clock[0])=99000000
> >> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >> HW_GPMI_TIMING0=0x00010101
> >
> > TIMING0 match the one you have with 5.1 kernels.
> >
> >> HW_GPMI_TIMING1=0x90000000
> >
> > And we even have a bigger timeout value in 5.1 (0xe0000000), so we
> > should be all safe WRT to timings in TIMING{0,1}.
> >
> > Can you dump CTRL1?
>
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> HW_GPMI_TIMING0=0x00010101
> HW_GPMI_TIMING1=0x90000000
> HW_GPMI_CTRL1_SET=0x01c4800c
The read/write delay fields seem to match, but there are a few more
fields set in this version:
- DECOUPLE_CS
- BCH_MODE
- DEV_RESET
- CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
Looks like those fields are not explicitly set in the gpmi_begin()
patch, but maybe you dumped CTRL1. Would you mind sharing your patch?
If I'm right and you indeed dumped CTRL1, it might be worth doing the
same in your 5.1 kernel so we can more easily compare those dumps.
While at it, can you dump CTRL1 before and after applying the changes?
> Scanning device for bad blocks
> 5 ofpart partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
>
> Regards
> Greg
>
>
> >> Scanning device for bad blocks
> >> 5 ofpart partitions found on MTD device gpmi-nand
> >> Creating 5 MTD partitions on "gpmi-nand":
> >> 0x000000000000-0x000000500000 : "u-boot"
> >> 0x000000500000-0x000000600000 : "u-boot-env"
> >> 0x000000600000-0x000000800000 : "log"
> >> 0x000000800000-0x000010000000 : "flash"
> >> 0x000000000000-0x000010000000 : "all"
> >> gpmi-nand 1806000.gpmi-nand: driver registered.
> >> ...
> >>
> >
> >
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-09 7:32 ` Boris Brezillon
@ 2019-08-09 13:57 ` Greg Ungerer
2019-08-09 13:59 ` Boris Brezillon
0 siblings, 1 reply; 39+ messages in thread
From: Greg Ungerer @ 2019-08-09 13:57 UTC (permalink / raw)
To: Boris Brezillon
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
[-- Attachment #1: Type: text/plain, Size: 5440 bytes --]
Hi Boris,
On 9/8/19 5:32 pm, Boris Brezillon wrote:
> On Fri, 9 Aug 2019 16:55:22 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>> On 9/8/19 4:23 pm, Boris Brezillon wrote:
>>> On Fri, 9 Aug 2019 15:20:52 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 9/8/19 2:36 am, Boris Brezillon wrote:
>>>>> On Mon, 5 Aug 2019 15:51:05 +1000
>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>>>>>> [snip]
>>>>>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>>>>>
>>>>>>>>> The values looks good. Can you try with the below diff applied?
>>>>>>>>> --->8---
>>>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>>>>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>>>>>
>>>>>>>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>>>>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>>>>>> - if (!dll_wait_time_us)
>>>>>>>>> - dll_wait_time_us = 1;
>>>>>>>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>>>>>
>>>>>>>>> /* Wait for the DLL to settle. */
>>>>>>>>> - udelay(dll_wait_time_us);
>>>>>>>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>>>>>
>>>>>>>> Eventually it failed, in the same way with with same errors.
>>>>>>>> Took quite a while, over 600 boot cycles.
>>>>>>>>
>>>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>>>>>
>>>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>>>>>> and clk rate that are set by the bootloader (before the driver override
>>>>>>> them) or those applied by an older kernel (one that didn't have that
>>>>>>> issue).
>>>>>>
>>>>>> Is this useful?
>>>>>
>>>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
>>>>> Can you try booting an older kernel (one that didn't have the
>>>>> ->setup_data_interface() hook implemented).
>>>>
>>>> Ok. I went back from 5.1 and the first kernel I could find that
>>>> returned no grep hits for "setup_data_interface" was 4.16.
>>>>
>>>> So I built for my target with that and added similar trace to dump
>>>> the hardware register settings for that. Debug output looks like
>>>> this now for it:
>>>>
>>>> ...
>>>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
>>>> clk_get_rate(r->clock[0])=22000000
>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>> HW_GPMI_TIMING0=0x00010203
>>>> HW_GPMI_TIMING1=0x05000000
>>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>>>> nand: Micron MT29F2G08ABAEAWP
>>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
>>>> clk_get_rate(r->clock[0])=99000000
>>>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>> HW_GPMI_TIMING0=0x00010101
>>>
>>> TIMING0 match the one you have with 5.1 kernels.
>>>
>>>> HW_GPMI_TIMING1=0x90000000
>>>
>>> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
>>> should be all safe WRT to timings in TIMING{0,1}.
>>>
>>> Can you dump CTRL1?
>>
>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>> HW_GPMI_TIMING0=0x00010101
>> HW_GPMI_TIMING1=0x90000000
>> HW_GPMI_CTRL1_SET=0x01c4800c
>
> The read/write delay fields seem to match, but there are a few more
> fields set in this version:
> - DECOUPLE_CS
> - BCH_MODE
> - DEV_RESET
> - CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
>
> Looks like those fields are not explicitly set in the gpmi_begin()
> patch, but maybe you dumped CTRL1. Would you mind sharing your patch?
Attached.
> If I'm right and you indeed dumped CTRL1, it might be worth doing the
> same in your 5.1 kernel so we can more easily compare those dumps.
> While at it, can you dump CTRL1 before and after applying the changes?
Will do. I am out of my lab for the weekend, but I'll get
those numbers first thing Monday morning.
Regards
Greg
[-- Attachment #2: gpmi-416.patch --]
[-- Type: text/x-patch, Size: 2481 bytes --]
[-- Attachment #3: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-09 13:57 ` Greg Ungerer
@ 2019-08-09 13:59 ` Boris Brezillon
2019-08-12 2:50 ` Greg Ungerer
0 siblings, 1 reply; 39+ messages in thread
From: Boris Brezillon @ 2019-08-09 13:59 UTC (permalink / raw)
To: Greg Ungerer
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
On Fri, 9 Aug 2019 23:57:08 +1000
Greg Ungerer <gerg@kernel.org> wrote:
> Hi Boris,
>
> On 9/8/19 5:32 pm, Boris Brezillon wrote:
> > On Fri, 9 Aug 2019 16:55:22 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:
> >> On 9/8/19 4:23 pm, Boris Brezillon wrote:
> >>> On Fri, 9 Aug 2019 15:20:52 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>> On 9/8/19 2:36 am, Boris Brezillon wrote:
> >>>>> On Mon, 5 Aug 2019 15:51:05 +1000
> >>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
> >>>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
> >>>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
> >>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> >>>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
> >>>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
> >>>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> >>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >>>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> >>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>>>>>>>>>>>> [snip]
> >>>>>>>>>> Note that this was generated on a normal boot up (not failure).
> >>>>>>>>>
> >>>>>>>>> The values looks good. Can you try with the below diff applied?
> >>>>>>>>> --->8---
> >>>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>> index 334fe3130285..9771f6a82abe 100644
> >>>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>>>>>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>>>>>>>>
> >>>>>>>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>>>>>>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>>>>>>>> - if (!dll_wait_time_us)
> >>>>>>>>> - dll_wait_time_us = 1;
> >>>>>>>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>>>>>>>>
> >>>>>>>>> /* Wait for the DLL to settle. */
> >>>>>>>>> - udelay(dll_wait_time_us);
> >>>>>>>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>>>>>>>
> >>>>>>>> Eventually it failed, in the same way with with same errors.
> >>>>>>>> Took quite a while, over 600 boot cycles.
> >>>>>>>>
> >>>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
> >>>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
> >>>>>>>
> >>>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
> >>>>>>> and clk rate that are set by the bootloader (before the driver override
> >>>>>>> them) or those applied by an older kernel (one that didn't have that
> >>>>>>> issue).
> >>>>>>
> >>>>>> Is this useful?
> >>>>>
> >>>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
> >>>>> Can you try booting an older kernel (one that didn't have the
> >>>>> ->setup_data_interface() hook implemented).
> >>>>
> >>>> Ok. I went back from 5.1 and the first kernel I could find that
> >>>> returned no grep hits for "setup_data_interface" was 4.16.
> >>>>
> >>>> So I built for my target with that and added similar trace to dump
> >>>> the hardware register settings for that. Debug output looks like
> >>>> this now for it:
> >>>>
> >>>> ...
> >>>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
> >>>> clk_get_rate(r->clock[0])=22000000
> >>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>>> HW_GPMI_TIMING0=0x00010203
> >>>> HW_GPMI_TIMING1=0x05000000
> >>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >>>> nand: Micron MT29F2G08ABAEAWP
> >>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
> >>>> clk_get_rate(r->clock[0])=99000000
> >>>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> >>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>>> HW_GPMI_TIMING0=0x00010101
> >>>
> >>> TIMING0 match the one you have with 5.1 kernels.
> >>>
> >>>> HW_GPMI_TIMING1=0x90000000
> >>>
> >>> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
> >>> should be all safe WRT to timings in TIMING{0,1}.
> >>>
> >>> Can you dump CTRL1?
> >>
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >> HW_GPMI_TIMING0=0x00010101
> >> HW_GPMI_TIMING1=0x90000000
> >> HW_GPMI_CTRL1_SET=0x01c4800c
> >
> > The read/write delay fields seem to match, but there are a few more
> > fields set in this version:
> > - DECOUPLE_CS
> > - BCH_MODE
> > - DEV_RESET
> > - CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
> >
> > Looks like those fields are not explicitly set in the gpmi_begin()
> > patch, but maybe you dumped CTRL1. Would you mind sharing your patch?
>
> Attached.
Hm, you should read CTRL1 instead of CTRL1_SET which I guess is WO.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-09 13:59 ` Boris Brezillon
@ 2019-08-12 2:50 ` Greg Ungerer
2019-08-12 4:04 ` Greg Ungerer
2019-08-12 7:31 ` Boris Brezillon
0 siblings, 2 replies; 39+ messages in thread
From: Greg Ungerer @ 2019-08-12 2:50 UTC (permalink / raw)
To: Boris Brezillon
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
Hi Boris,
On 9/8/19 11:59 pm, Boris Brezillon wrote:
> On Fri, 9 Aug 2019 23:57:08 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>> On 9/8/19 5:32 pm, Boris Brezillon wrote:
>>> On Fri, 9 Aug 2019 16:55:22 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 9/8/19 4:23 pm, Boris Brezillon wrote:
>>>>> On Fri, 9 Aug 2019 15:20:52 +1000
>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>> On 9/8/19 2:36 am, Boris Brezillon wrote:
>>>>>>> On Mon, 5 Aug 2019 15:51:05 +1000
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>>>>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>>>>>>>> [snip]
>>>>>>>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>>>>>>>
>>>>>>>>>>> The values looks good. Can you try with the below diff applied?
>>>>>>>>>>> --->8---
>>>>>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>>>>>>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>>>>>>>
>>>>>>>>>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>>>>>>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>>>>>>>> - if (!dll_wait_time_us)
>>>>>>>>>>> - dll_wait_time_us = 1;
>>>>>>>>>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>>>>>>>
>>>>>>>>>>> /* Wait for the DLL to settle. */
>>>>>>>>>>> - udelay(dll_wait_time_us);
>>>>>>>>>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>>>>>>>
>>>>>>>>>> Eventually it failed, in the same way with with same errors.
>>>>>>>>>> Took quite a while, over 600 boot cycles.
>>>>>>>>>>
>>>>>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>>>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>>>>>>>
>>>>>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>>>>>>>> and clk rate that are set by the bootloader (before the driver override
>>>>>>>>> them) or those applied by an older kernel (one that didn't have that
>>>>>>>>> issue).
>>>>>>>>
>>>>>>>> Is this useful?
>>>>>>>
>>>>>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
>>>>>>> Can you try booting an older kernel (one that didn't have the
>>>>>>> ->setup_data_interface() hook implemented).
>>>>>>
>>>>>> Ok. I went back from 5.1 and the first kernel I could find that
>>>>>> returned no grep hits for "setup_data_interface" was 4.16.
>>>>>>
>>>>>> So I built for my target with that and added similar trace to dump
>>>>>> the hardware register settings for that. Debug output looks like
>>>>>> this now for it:
>>>>>>
>>>>>> ...
>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
>>>>>> clk_get_rate(r->clock[0])=22000000
>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>>> HW_GPMI_TIMING0=0x00010203
>>>>>> HW_GPMI_TIMING1=0x05000000
>>>>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>>>>>> nand: Micron MT29F2G08ABAEAWP
>>>>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
>>>>>> clk_get_rate(r->clock[0])=99000000
>>>>>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>>> HW_GPMI_TIMING0=0x00010101
>>>>>
>>>>> TIMING0 match the one you have with 5.1 kernels.
>>>>>
>>>>>> HW_GPMI_TIMING1=0x90000000
>>>>>
>>>>> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
>>>>> should be all safe WRT to timings in TIMING{0,1}.
>>>>>
>>>>> Can you dump CTRL1?
>>>>
>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>> HW_GPMI_TIMING0=0x00010101
>>>> HW_GPMI_TIMING1=0x90000000
>>>> HW_GPMI_CTRL1_SET=0x01c4800c
>>>
>>> The read/write delay fields seem to match, but there are a few more
>>> fields set in this version:
>>> - DECOUPLE_CS
>>> - BCH_MODE
>>> - DEV_RESET
>>> - CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
>>>
>>> Looks like those fields are not explicitly set in the gpmi_begin()
>>> patch, but maybe you dumped CTRL1. Would you mind sharing your patch?
>>
>> Attached.
>
> Hm, you should read CTRL1 instead of CTRL1_SET which I guess is WO.
Here is 2 sets of trace dumping the same set of registers.
This first is on the linux-4.16 kernel:
Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #9 Mon Aug 12 10:46:25 AEST 2019
...
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1110): gpmi_begin()
HW_GPMI_TIMING0=0x00010101
HW_GPMI_TIMING1=0x90000000
HW_GPMI_CTRL1=0x01c6800c
r->clock[0]=99000000
Scanning device for bad blocks
5 ofpart partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...
And then this is from the 5.1.14 kernel:
Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #25 Mon Aug 12 10:49:21 AEST 2019
...
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
HW_GPMI_TIMING0=0x00020101
HW_GPMI_TIMING1=0xb0000000
HW_GPMI_CTRL1=0x0104000c
r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
HW_GPMI_TIMING0=0x00010101
HW_GPMI_TIMING1=0xe0000000
HW_GPMI_CTRL1=0x01c6800c
r->clock[0]=99000000
Scanning device for bad blocks
5 fixed-partitions partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
Register settings read back from the registers themselves at the end
of the respective setting routines (so gpmi_begin() for 4.16 and
gpmi_nfc_apply_timings() for 5.1.14)
So something I notice here is that gpmi_nfc_apply_timings() is
being run multiple times. When I look back to the original
failure dumps the first error ("DMA timeout, last DMA") occurred
after the device type messages ("nand: 256 MiB, SLC,..."). Is it
happening with that higher clock rate still set?
Regards
Greg
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-12 2:50 ` Greg Ungerer
@ 2019-08-12 4:04 ` Greg Ungerer
2019-08-12 7:31 ` Boris Brezillon
1 sibling, 0 replies; 39+ messages in thread
From: Greg Ungerer @ 2019-08-12 4:04 UTC (permalink / raw)
To: Boris Brezillon
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
On 12/8/19 12:50 pm, Greg Ungerer wrote:
> On 9/8/19 11:59 pm, Boris Brezillon wrote:
>> On Fri, 9 Aug 2019 23:57:08 +1000
>> Greg Ungerer <gerg@kernel.org> wrote:
>>> On 9/8/19 5:32 pm, Boris Brezillon wrote:
>>>> On Fri, 9 Aug 2019 16:55:22 +1000
>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>> On 9/8/19 4:23 pm, Boris Brezillon wrote:
>>>>>> On Fri, 9 Aug 2019 15:20:52 +1000
>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>> On 9/8/19 2:36 am, Boris Brezillon wrote:
>>>>>>>> On Mon, 5 Aug 2019 15:51:05 +1000
>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>>>>>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>>>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>>>>>>>>> [snip]
>>>>>>>>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>>>>>>>>
>>>>>>>>>>>> The values looks good. Can you try with the below diff applied?
>>>>>>>>>>>> --->8---
>>>>>>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>>>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>>>>>>>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>>>>>>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>>>>>>>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>>>>>>>>> - if (!dll_wait_time_us)
>>>>>>>>>>>> - dll_wait_time_us = 1;
>>>>>>>>>>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>>>>>>>> /* Wait for the DLL to settle. */
>>>>>>>>>>>> - udelay(dll_wait_time_us);
>>>>>>>>>>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>>>>>>>>> }
>>>>>>>>>>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>>>>>>>>
>>>>>>>>>>> Eventually it failed, in the same way with with same errors.
>>>>>>>>>>> Took quite a while, over 600 boot cycles.
>>>>>>>>>>>
>>>>>>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>>>>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>>>>>>>>
>>>>>>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>>>>>>>>> and clk rate that are set by the bootloader (before the driver override
>>>>>>>>>> them) or those applied by an older kernel (one that didn't have that
>>>>>>>>>> issue).
>>>>>>>>>
>>>>>>>>> Is this useful?
>>>>>>>>
>>>>>>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
>>>>>>>> Can you try booting an older kernel (one that didn't have the
>>>>>>>> ->setup_data_interface() hook implemented).
>>>>>>>
>>>>>>> Ok. I went back from 5.1 and the first kernel I could find that
>>>>>>> returned no grep hits for "setup_data_interface" was 4.16.
>>>>>>>
>>>>>>> So I built for my target with that and added similar trace to dump
>>>>>>> the hardware register settings for that. Debug output looks like
>>>>>>> this now for it:
>>>>>>>
>>>>>>> ...
>>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
>>>>>>> clk_get_rate(r->clock[0])=22000000
>>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>>>> HW_GPMI_TIMING0=0x00010203
>>>>>>> HW_GPMI_TIMING1=0x05000000
>>>>>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>>>>>>> nand: Micron MT29F2G08ABAEAWP
>>>>>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
>>>>>>> clk_get_rate(r->clock[0])=99000000
>>>>>>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
>>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>>>> HW_GPMI_TIMING0=0x00010101
>>>>>>
>>>>>> TIMING0 match the one you have with 5.1 kernels.
>>>>>>> HW_GPMI_TIMING1=0x90000000
>>>>>>
>>>>>> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
>>>>>> should be all safe WRT to timings in TIMING{0,1}.
>>>>>>
>>>>>> Can you dump CTRL1?
>>>>>
>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>> HW_GPMI_TIMING0=0x00010101
>>>>> HW_GPMI_TIMING1=0x90000000
>>>>> HW_GPMI_CTRL1_SET=0x01c4800c
>>>>
>>>> The read/write delay fields seem to match, but there are a few more
>>>> fields set in this version:
>>>> - DECOUPLE_CS
>>>> - BCH_MODE
>>>> - DEV_RESET
>>>> - CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
>>>>
>>>> Looks like those fields are not explicitly set in the gpmi_begin()
>>>> patch, but maybe you dumped CTRL1. Would you mind sharing your patch?
>>>
>>> Attached.
>>
>> Hm, you should read CTRL1 instead of CTRL1_SET which I guess is WO.
>
>
> Here is 2 sets of trace dumping the same set of registers.
> This first is on the linux-4.16 kernel:
>
> Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #9 Mon Aug 12 10:46:25 AEST 2019
> ...
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1110): gpmi_begin()
> HW_GPMI_TIMING0=0x00010101
> HW_GPMI_TIMING1=0x90000000
> HW_GPMI_CTRL1=0x01c6800c
> r->clock[0]=99000000
> Scanning device for bad blocks
> 5 ofpart partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
>
>
> And then this is from the 5.1.14 kernel:
>
> Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #25 Mon Aug 12 10:49:21 AEST 2019
> ...
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
> HW_GPMI_TIMING0=0x00020101
> HW_GPMI_TIMING1=0xb0000000
> HW_GPMI_CTRL1=0x0104000c
> r->clock[0]=22000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
> HW_GPMI_TIMING0=0x00010101
> HW_GPMI_TIMING1=0xe0000000
> HW_GPMI_CTRL1=0x01c6800c
> r->clock[0]=99000000
> Scanning device for bad blocks
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
>
>
> Register settings read back from the registers themselves at the end
> of the respective setting routines (so gpmi_begin() for 4.16 and
> gpmi_nfc_apply_timings() for 5.1.14)
>
> So something I notice here is that gpmi_nfc_apply_timings() is
> being run multiple times. When I look back to the original
> failure dumps the first error ("DMA timeout, last DMA") occurred
> after the device type messages ("nand: 256 MiB, SLC,..."). Is it
> happening with that higher clock rate still set?
Looks like that is not the case...
...
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
HW_GPMI_TIMING0=0x00020101
HW_GPMI_TIMING1=0xb0000000
HW_GPMI_CTRL1=0x0104000c
r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
HW_GPMI_TIMING0=0x00010101
HW_GPMI_TIMING1=0xe0000000
HW_GPMI_CTRL1=0x01c6800c
r->clock[0]=99000000
gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000100
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
gpmi-nand 1806000.gpmi-nand: Show BCH registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
Regards
Greg
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-12 2:50 ` Greg Ungerer
2019-08-12 4:04 ` Greg Ungerer
@ 2019-08-12 7:31 ` Boris Brezillon
2019-08-13 0:50 ` Greg Ungerer
1 sibling, 1 reply; 39+ messages in thread
From: Boris Brezillon @ 2019-08-12 7:31 UTC (permalink / raw)
To: Greg Ungerer
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
On Mon, 12 Aug 2019 12:50:36 +1000
Greg Ungerer <gerg@kernel.org> wrote:
> Hi Boris,
>
> On 9/8/19 11:59 pm, Boris Brezillon wrote:
> > On Fri, 9 Aug 2019 23:57:08 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:
> >> On 9/8/19 5:32 pm, Boris Brezillon wrote:
> >>> On Fri, 9 Aug 2019 16:55:22 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>> On 9/8/19 4:23 pm, Boris Brezillon wrote:
> >>>>> On Fri, 9 Aug 2019 15:20:52 +1000
> >>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>> On 9/8/19 2:36 am, Boris Brezillon wrote:
> >>>>>>> On Mon, 5 Aug 2019 15:51:05 +1000
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
> >>>>>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
> >>>>>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
> >>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> >>>>>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
> >>>>>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
> >>>>>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> >>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >>>>>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> >>>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>>>>>>>>>>>>>> [snip]
> >>>>>>>>>>>> Note that this was generated on a normal boot up (not failure).
> >>>>>>>>>>>
> >>>>>>>>>>> The values looks good. Can you try with the below diff applied?
> >>>>>>>>>>> --->8---
> >>>>>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>>>> index 334fe3130285..9771f6a82abe 100644
> >>>>>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>>>>>>>>> writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>>>>>>>>>>
> >>>>>>>>>>> /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>>>>>>>>>> - dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>>>>>>>>>> - if (!dll_wait_time_us)
> >>>>>>>>>>> - dll_wait_time_us = 1;
> >>>>>>>>>>> + dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>>>>>>>>>>
> >>>>>>>>>>> /* Wait for the DLL to settle. */
> >>>>>>>>>>> - udelay(dll_wait_time_us);
> >>>>>>>>>>> + usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>>>>>>>>>
> >>>>>>>>>> Eventually it failed, in the same way with with same errors.
> >>>>>>>>>> Took quite a while, over 600 boot cycles.
> >>>>>>>>>>
> >>>>>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
> >>>>>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
> >>>>>>>>>
> >>>>>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
> >>>>>>>>> and clk rate that are set by the bootloader (before the driver override
> >>>>>>>>> them) or those applied by an older kernel (one that didn't have that
> >>>>>>>>> issue).
> >>>>>>>>
> >>>>>>>> Is this useful?
> >>>>>>>
> >>>>>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
> >>>>>>> Can you try booting an older kernel (one that didn't have the
> >>>>>>> ->setup_data_interface() hook implemented).
> >>>>>>
> >>>>>> Ok. I went back from 5.1 and the first kernel I could find that
> >>>>>> returned no grep hits for "setup_data_interface" was 4.16.
> >>>>>>
> >>>>>> So I built for my target with that and added similar trace to dump
> >>>>>> the hardware register settings for that. Debug output looks like
> >>>>>> this now for it:
> >>>>>>
> >>>>>> ...
> >>>>>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
> >>>>>> clk_get_rate(r->clock[0])=22000000
> >>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>>>>> HW_GPMI_TIMING0=0x00010203
> >>>>>> HW_GPMI_TIMING1=0x05000000
> >>>>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >>>>>> nand: Micron MT29F2G08ABAEAWP
> >>>>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
> >>>>>> clk_get_rate(r->clock[0])=99000000
> >>>>>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> >>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>>>>> HW_GPMI_TIMING0=0x00010101
> >>>>>
> >>>>> TIMING0 match the one you have with 5.1 kernels.
> >>>>>
> >>>>>> HW_GPMI_TIMING1=0x90000000
> >>>>>
> >>>>> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
> >>>>> should be all safe WRT to timings in TIMING{0,1}.
> >>>>>
> >>>>> Can you dump CTRL1?
> >>>>
> >>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>>> HW_GPMI_TIMING0=0x00010101
> >>>> HW_GPMI_TIMING1=0x90000000
> >>>> HW_GPMI_CTRL1_SET=0x01c4800c
> >>>
> >>> The read/write delay fields seem to match, but there are a few more
> >>> fields set in this version:
> >>> - DECOUPLE_CS
> >>> - BCH_MODE
> >>> - DEV_RESET
> >>> - CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
> >>>
> >>> Looks like those fields are not explicitly set in the gpmi_begin()
> >>> patch, but maybe you dumped CTRL1. Would you mind sharing your patch?
> >>
> >> Attached.
> >
> > Hm, you should read CTRL1 instead of CTRL1_SET which I guess is WO.
>
>
> Here is 2 sets of trace dumping the same set of registers.
> This first is on the linux-4.16 kernel:
>
> Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #9 Mon Aug 12 10:46:25 AEST 2019
> ...
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1110): gpmi_begin()
> HW_GPMI_TIMING0=0x00010101
> HW_GPMI_TIMING1=0x90000000
> HW_GPMI_CTRL1=0x01c6800c
> r->clock[0]=99000000
> Scanning device for bad blocks
> 5 ofpart partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
>
>
> And then this is from the 5.1.14 kernel:
>
> Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #25 Mon Aug 12 10:49:21 AEST 2019
> ...
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
> HW_GPMI_TIMING0=0x00020101
> HW_GPMI_TIMING1=0xb0000000
> HW_GPMI_CTRL1=0x0104000c
> r->clock[0]=22000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
> HW_GPMI_TIMING0=0x00010101
> HW_GPMI_TIMING1=0xe0000000
> HW_GPMI_CTRL1=0x01c6800c
> r->clock[0]=99000000
> Scanning device for bad blocks
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
>
>
> Register settings read back from the registers themselves at the end
> of the respective setting routines (so gpmi_begin() for 4.16 and
> gpmi_nfc_apply_timings() for 5.1.14)
Hm, CTRL1 is identical. Can you dump all regs at the beginning and at
the end of those funcs?
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI iMX6ull timeout on DMA
2019-08-12 7:31 ` Boris Brezillon
@ 2019-08-13 0:50 ` Greg Ungerer
0 siblings, 0 replies; 39+ messages in thread
From: Greg Ungerer @ 2019-08-13 0:50 UTC (permalink / raw)
To: Boris Brezillon
Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
Boris Brezillon
Hi Boris,
On 12/8/19 5:31 pm, Boris Brezillon wrote:
> On Mon, 12 Aug 2019 12:50:36 +1000
[snip]
> Hm, CTRL1 is identical. Can you dump all regs at the beginning and at
> the end of those funcs?
Here is a more complete dump of registers. Trace points are at
entry and exit of the respective functions in the different
kernel versions. Register dumping code is identical for both.
Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #10 Tue Aug 13 10:24:28 AEST 2019
...
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1073): gpmi_begin(): ENTRY
HW_GPMI_CTRL0=0x00000000
HW_GPMI_CTRL1=0x01c4000c
HW_GPMI_COMPARE=0x00000000
HW_GPMI_ECCCTRL=0x00000400
HW_GPMI_ECCCOUNT=0x00000000
HW_GPMI_PAYLOAD=0x00000000
HW_GPMI_AUXILIARY=0x00000000
HW_GPMI_TIMING0=0x00010203
HW_GPMI_TIMING1=0x00000000
HW_GPMI_TIMING2=0x23023336
HW_GPMI_DATA=0x00000000
HW_GPMI_STAT=0xff000005
HW_GPMI_DEBUG=0x00000000
r->clock[0]=22000000
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1073): gpmi_begin(): ENTRY
HW_GPMI_CTRL0=0x01800001
HW_GPMI_CTRL1=0x0104000c
HW_GPMI_COMPARE=0x00000000
HW_GPMI_ECCCTRL=0x00000000
HW_GPMI_ECCCOUNT=0x00000000
HW_GPMI_PAYLOAD=0x00000000
HW_GPMI_AUXILIARY=0x00000000
HW_GPMI_TIMING0=0x00010203
HW_GPMI_TIMING1=0x05000000
HW_GPMI_TIMING2=0x23023336
HW_GPMI_DATA=0x00000000
HW_GPMI_STAT=0xff000005
HW_GPMI_DEBUG=0x00000101
r->clock[0]=99000000
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1136): gpmi_begin(): EXIT
HW_GPMI_CTRL0=0x01800001
HW_GPMI_CTRL1=0x01c6800c
HW_GPMI_COMPARE=0x00000000
HW_GPMI_ECCCTRL=0x00000000
HW_GPMI_ECCCOUNT=0x00000000
HW_GPMI_PAYLOAD=0x00000000
HW_GPMI_AUXILIARY=0x00000000
HW_GPMI_TIMING0=0x00010101
HW_GPMI_TIMING1=0x90000000
HW_GPMI_TIMING2=0x23023336
HW_GPMI_DATA=0x00000000
HW_GPMI_STAT=0xff000005
HW_GPMI_DEBUG=0x00000101
r->clock[0]=99000000
Scanning device for bad blocks
5 ofpart partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...
Note that the first ENTRY dump has no matching EXIT dump. From the
code I assume it is returning from gpmi_begin() at the
"if (!hw.sample_delay_factor)" check.
And for the 5.1.14 kernel:
Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #27 Tue Aug 13 10:20:32 AEST 2019
...
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
HW_GPMI_CTRL0=0x00000000
HW_GPMI_CTRL1=0x01c4000c
HW_GPMI_COMPARE=0x00000000
HW_GPMI_ECCCTRL=0x00000400
HW_GPMI_ECCCOUNT=0x00000000
HW_GPMI_PAYLOAD=0x00000000
HW_GPMI_AUXILIARY=0x00000000
HW_GPMI_TIMING0=0x00010203
HW_GPMI_TIMING1=0x00000000
HW_GPMI_TIMING2=0x23023336
HW_GPMI_DATA=0x00000000
HW_GPMI_STAT=0xff000005
HW_GPMI_DEBUG=0x00000000
r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
HW_GPMI_CTRL0=0x00000000
HW_GPMI_CTRL1=0x0104000c
HW_GPMI_COMPARE=0x00000000
HW_GPMI_ECCCTRL=0x00000400
HW_GPMI_ECCCOUNT=0x00000000
HW_GPMI_PAYLOAD=0x00000000
HW_GPMI_AUXILIARY=0x00000000
HW_GPMI_TIMING0=0x00020101
HW_GPMI_TIMING1=0x60000000
HW_GPMI_TIMING2=0x23023336
HW_GPMI_DATA=0x00000000
HW_GPMI_STAT=0xff000005
HW_GPMI_DEBUG=0x00000000
r->clock[0]=22000000
random: fast init done
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
HW_GPMI_CTRL0=0x01800001
HW_GPMI_CTRL1=0x0104000c
HW_GPMI_COMPARE=0x00000000
HW_GPMI_ECCCTRL=0x00000000
HW_GPMI_ECCCOUNT=0x00000000
HW_GPMI_PAYLOAD=0x00000000
HW_GPMI_AUXILIARY=0x00000000
HW_GPMI_TIMING0=0x00020101
HW_GPMI_TIMING1=0x60000000
HW_GPMI_TIMING2=0x23023336
HW_GPMI_DATA=0x0000003f
HW_GPMI_STAT=0xff000005
HW_GPMI_DEBUG=0x00000101
r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
HW_GPMI_CTRL0=0x01800001
HW_GPMI_CTRL1=0x0104000c
HW_GPMI_COMPARE=0x00000000
HW_GPMI_ECCCTRL=0x00000000
HW_GPMI_ECCCOUNT=0x00000000
HW_GPMI_PAYLOAD=0x00000000
HW_GPMI_AUXILIARY=0x00000000
HW_GPMI_TIMING0=0x00020101
HW_GPMI_TIMING1=0xb0000000
HW_GPMI_TIMING2=0x23023336
HW_GPMI_DATA=0x0000003f
HW_GPMI_STAT=0xff000005
HW_GPMI_DEBUG=0x00000101
r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
HW_GPMI_CTRL0=0x01800001
HW_GPMI_CTRL1=0x0104000c
HW_GPMI_COMPARE=0x00000000
HW_GPMI_ECCCTRL=0x00000000
HW_GPMI_ECCCOUNT=0x00000000
HW_GPMI_PAYLOAD=0x00000000
HW_GPMI_AUXILIARY=0x00000000
HW_GPMI_TIMING0=0x00020101
HW_GPMI_TIMING1=0xb0000000
HW_GPMI_TIMING2=0x23023336
HW_GPMI_DATA=0x000000e0
HW_GPMI_STAT=0xff000005
HW_GPMI_DEBUG=0x00000000
r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
HW_GPMI_CTRL0=0x01800001
HW_GPMI_CTRL1=0x01c6800c
HW_GPMI_COMPARE=0x00000000
HW_GPMI_ECCCTRL=0x00000000
HW_GPMI_ECCCOUNT=0x00000000
HW_GPMI_PAYLOAD=0x00000000
HW_GPMI_AUXILIARY=0x00000000
HW_GPMI_TIMING0=0x00010101
HW_GPMI_TIMING1=0xe0000000
HW_GPMI_TIMING2=0x23023336
HW_GPMI_DATA=0x000000e0
HW_GPMI_STAT=0xff000005
HW_GPMI_DEBUG=0x00000000
r->clock[0]=99000000
Scanning device for bad blocks
5 fixed-partitions partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...
Regards
Greg
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: GPMI IMX6ull timeout on dma
2018-10-02 13:22 GPMI IMX6ull timeout on dma Michael Nazzareno Trimarchi
@ 2018-10-04 14:36 ` Michael Nazzareno Trimarchi
0 siblings, 0 replies; 39+ messages in thread
From: Michael Nazzareno Trimarchi @ 2018-10-04 14:36 UTC (permalink / raw)
To: Han Xu, Boris Brezillon; +Cc: linux-mtd
Hi
I add now this code but nand seems incosistent
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
---
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
index c2597c8107a0..b1598dc5013f 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
@@ -466,11 +466,9 @@ void prepare_data_dma(struct gpmi_nand_data
*this, enum dma_data_direction dr)
this->direct_dma_map_ok = false;
}
-/* This will be called after the DMA operation is finished. */
-static void dma_irq_callback(void *param)
+static void dma_unmap_request(void *param)
{
struct gpmi_nand_data *this = param;
- struct completion *dma_c = &this->dma_done;
switch (this->dma_type) {
case DMA_FOR_COMMAND:
@@ -492,11 +490,18 @@ static void dma_irq_callback(void *param)
case DMA_FOR_WRITE_ECC_PAGE:
/* We have to wait the BCH interrupt to finish. */
break;
-
default:
dev_err(this->dev, "in wrong DMA operation.\n");
}
+}
+
+/* This will be called after the DMA operation is finished. */
+static void dma_irq_callback(void *param)
+{
+ struct gpmi_nand_data *this = param;
+ struct completion *dma_c = &this->dma_done;
+ dma_unmap_request(param);
complete(dma_c);
}
Michael
On Tue, Oct 2, 2018 at 3:22 PM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi all
>
> I have a strange problem on booting an imx6ull system. The problem is
> not systematic and seems that it depends on how bootloader is using
> the nand on first stage boot. BTW kernel can not always pass to go to
> edo time 5 (even 4). If I power off and power on the unit the nand
> work properly.
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 4.17.0-rc1 (michael@panicking) (gcc
> version 6.4.0 (Buildroot 2018.02-rc2-00006-g39101b7)) #2 SMP Tue Oct 2
> 08:24:58 CEST 2018
>
> [ 1.612357] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> [ 1.618905] nand: Micron MT29F2G08ABAEAH4
> [ 1.623126] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64
> [ 2.651940] gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA :2
> [ 2.658146] gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> [ 2.664203] gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> [ 2.670474] gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> [ 2.676849] gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> [ 2.683217] gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> [ 2.689482] gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> [ 2.695840] gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> [ 2.702202] gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> [ 2.708470] gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> [ 2.714826] gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> [ 2.721093] gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> [ 2.727450] gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> [ 2.733812] gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> [ 2.740078] gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000000
> [ 2.746437] gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> [ 2.752794] gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> [ 2.758626] gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> [ 2.764982] gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> [ 2.771247] gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> [ 2.777604] gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> [ 2.783961] gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> [ 2.790226] gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> [ 2.796582] gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> [ 2.802942] gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> [ 2.809208] gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> [ 2.815564] gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> [ 2.821924] gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> [ 2.828191] gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> [ 2.834546] gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> [ 2.840813] gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> [ 2.847170] gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> [ 2.853527] gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> [ 2.859794] gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> [ 2.866153] gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> [ 2.872513] gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> [ 2.878779] gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> [ 2.885135] gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> [ 2.891401] gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> [ 2.897759] gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> [ 2.904117] gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> [ 2.910400] gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> [ 2.910400] GF length : 13
> [ 2.910400] ECC Strength : 8
> [ 2.910400] Page Size in Bytes : 2110
> [ 2.910400] Metadata Size in Bytes : 10
> [ 2.910400] ECC Chunk Size in Bytes: 512
> [ 2.910400] ECC Chunk Count : 4
> [ 2.910400] Payload Size in Bytes : 2048
> [ 2.910400] Auxiliary Size in Bytes: 16
> [ 2.910400] Auxiliary Status Offset: 12
> [ 2.910400] Block Mark Byte Offset : 1999
> [ 2.910400] Block Mark Bit Offset : 0
> [ 2.958231] gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
>
> What bootloader do is just attach the ubi and then boot the image
>
> ubi0: attaching mtd1
> ubi0: scanning is finished
> ubi0: attached mtd1 (name "mtd=5", size 231 MiB)
> ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
> ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
> ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
> ubi0: good PEBs: 1844, bad PEBs: 4, corrupted PEBs: 0
> ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
> ubi0: max/mean erase counter: 4/2, WL threshold: 4096, image sequence number: 0
> ubi0: available PEBs: 2, total reserved PEBs: 1842, PEBs reserved for
> bad PEB handling: 36
> Read 0 bytes from volume kernel to 82800000
> No size specified -> Using max size (16887808)
> ## Loading kernel from FIT Image at 82800000 ...
> Using 'conf@2' configuration
> Verifying Hash Integrity ... OK
> Trying 'kernel@1' kernel subimage
> Description: kernel
> Type: Kernel Image
> Compression: uncompressed
> Data Start: 0x828000ac
> Data Size: 6685920 Bytes = 6.4 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x80008000
> Entry Point: 0x80008000
> Hash algo: sha1
> Hash value: 4646b0eea535d8ea9e2f7167bdeedc7668b2a948
> Verifying Hash Integrity ... sha1+ OK
> ## Loading fdt from FIT Image at 82800000 ...
> Using 'conf@2' configuration
> Trying 'fdt@2' fdt subimage
> Description: imx6ull-bammi.dtb
> Type: Flat Device Tree
> Compression: uncompressed
> Data Start: 0x82e67730
> Data Size: 28667 Bytes = 28 KiB
> Architecture: ARM
> Hash algo: sha1
> Hash value: 1cf147576a30eb901a6306172f9385d6a6b65753
> Verifying Hash Integrity ... sha1+ OK
> Booting using the fdt blob at 0x82e67730
> Loading Kernel Image ... OK
> Using Device Tree in place at 82e67730, end 82e7172a
> Using Device Tree in place at 82e67730, end 82e7472a
>
> Any idea?
>
> Michael
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
^ permalink raw reply [flat|nested] 39+ messages in thread
* GPMI IMX6ull timeout on dma
@ 2018-10-02 13:22 Michael Nazzareno Trimarchi
2018-10-04 14:36 ` Michael Nazzareno Trimarchi
0 siblings, 1 reply; 39+ messages in thread
From: Michael Nazzareno Trimarchi @ 2018-10-02 13:22 UTC (permalink / raw)
To: Han Xu, Boris Brezillon; +Cc: linux-mtd
Hi all
I have a strange problem on booting an imx6ull system. The problem is
not systematic and seems that it depends on how bootloader is using
the nand on first stage boot. BTW kernel can not always pass to go to
edo time 5 (even 4). If I power off and power on the unit the nand
work properly.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.17.0-rc1 (michael@panicking) (gcc
version 6.4.0 (Buildroot 2018.02-rc2-00006-g39101b7)) #2 SMP Tue Oct 2
08:24:58 CEST 2018
[ 1.612357] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[ 1.618905] nand: Micron MT29F2G08ABAEAH4
[ 1.623126] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[ 2.651940] gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA :2
[ 2.658146] gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
[ 2.664203] gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
[ 2.670474] gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
[ 2.676849] gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
[ 2.683217] gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
[ 2.689482] gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
[ 2.695840] gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
[ 2.702202] gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
[ 2.708470] gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
[ 2.714826] gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
[ 2.721093] gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
[ 2.727450] gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
[ 2.733812] gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
[ 2.740078] gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000000
[ 2.746437] gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
[ 2.752794] gpmi-nand 1806000.gpmi-nand: Show BCH registers :
[ 2.758626] gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
[ 2.764982] gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
[ 2.771247] gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
[ 2.777604] gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
[ 2.783961] gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
[ 2.790226] gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
[ 2.796582] gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
[ 2.802942] gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
[ 2.809208] gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
[ 2.815564] gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
[ 2.821924] gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
[ 2.828191] gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
[ 2.834546] gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
[ 2.840813] gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
[ 2.847170] gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
[ 2.853527] gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
[ 2.859794] gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
[ 2.866153] gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
[ 2.872513] gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
[ 2.878779] gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
[ 2.885135] gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
[ 2.891401] gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
[ 2.897759] gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
[ 2.904117] gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
[ 2.910400] gpmi-nand 1806000.gpmi-nand: BCH Geometry :
[ 2.910400] GF length : 13
[ 2.910400] ECC Strength : 8
[ 2.910400] Page Size in Bytes : 2110
[ 2.910400] Metadata Size in Bytes : 10
[ 2.910400] ECC Chunk Size in Bytes: 512
[ 2.910400] ECC Chunk Count : 4
[ 2.910400] Payload Size in Bytes : 2048
[ 2.910400] Auxiliary Size in Bytes: 16
[ 2.910400] Auxiliary Status Offset: 12
[ 2.910400] Block Mark Byte Offset : 1999
[ 2.910400] Block Mark Bit Offset : 0
[ 2.958231] gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
What bootloader do is just attach the ubi and then boot the image
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=5", size 231 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 1844, bad PEBs: 4, corrupted PEBs: 0
ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 4/2, WL threshold: 4096, image sequence number: 0
ubi0: available PEBs: 2, total reserved PEBs: 1842, PEBs reserved for
bad PEB handling: 36
Read 0 bytes from volume kernel to 82800000
No size specified -> Using max size (16887808)
## Loading kernel from FIT Image at 82800000 ...
Using 'conf@2' configuration
Verifying Hash Integrity ... OK
Trying 'kernel@1' kernel subimage
Description: kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x828000ac
Data Size: 6685920 Bytes = 6.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x80008000
Entry Point: 0x80008000
Hash algo: sha1
Hash value: 4646b0eea535d8ea9e2f7167bdeedc7668b2a948
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 82800000 ...
Using 'conf@2' configuration
Trying 'fdt@2' fdt subimage
Description: imx6ull-bammi.dtb
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x82e67730
Data Size: 28667 Bytes = 28 KiB
Architecture: ARM
Hash algo: sha1
Hash value: 1cf147576a30eb901a6306172f9385d6a6b65753
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x82e67730
Loading Kernel Image ... OK
Using Device Tree in place at 82e67730, end 82e7172a
Using Device Tree in place at 82e67730, end 82e7472a
Any idea?
Michael
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, back to index
Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-29 6:41 GPMI iMX6ull timeout on DMA Greg Ungerer
2019-07-29 8:36 ` Miquel Raynal
2019-07-29 8:42 ` Michael Nazzareno Trimarchi
2019-07-29 12:18 ` Greg Ungerer
2019-07-29 12:20 ` Michael Nazzareno Trimarchi
2019-07-29 12:33 ` Greg Ungerer
2019-07-29 12:47 ` Miquel Raynal
2019-07-29 12:49 ` Michael Nazzareno Trimarchi
2019-07-29 12:55 ` Miquel Raynal
2019-07-29 13:00 ` Michael Nazzareno Trimarchi
2019-07-29 13:22 ` Miquel Raynal
2019-07-29 20:00 ` Michael Nazzareno Trimarchi
2019-07-29 21:02 ` Miquel Raynal
2019-07-30 0:28 ` Greg Ungerer
2019-07-30 0:41 ` Greg Ungerer
2019-07-30 6:06 ` Greg Ungerer
2019-07-30 8:38 ` Miquel Raynal
2019-07-30 8:58 ` Boris Brezillon
2019-07-31 2:05 ` Greg Ungerer
2019-07-31 6:28 ` Boris Brezillon
2019-08-02 7:19 ` Greg Ungerer
2019-08-02 12:34 ` Greg Ungerer
2019-08-02 12:51 ` Boris Brezillon
2019-08-05 5:51 ` Greg Ungerer
2019-08-07 16:05 ` Miquel Raynal
2019-08-08 0:43 ` Greg Ungerer
2019-08-08 16:36 ` Boris Brezillon
2019-08-09 5:20 ` Greg Ungerer
2019-08-09 6:23 ` Boris Brezillon
2019-08-09 6:55 ` Greg Ungerer
2019-08-09 7:32 ` Boris Brezillon
2019-08-09 13:57 ` Greg Ungerer
2019-08-09 13:59 ` Boris Brezillon
2019-08-12 2:50 ` Greg Ungerer
2019-08-12 4:04 ` Greg Ungerer
2019-08-12 7:31 ` Boris Brezillon
2019-08-13 0:50 ` Greg Ungerer
-- strict thread matches above, loose matches on Subject: below --
2018-10-02 13:22 GPMI IMX6ull timeout on dma Michael Nazzareno Trimarchi
2018-10-04 14:36 ` Michael Nazzareno Trimarchi
Linux-mtd Archive on lore.kernel.org
Archives are clonable:
git clone --mirror https://lore.kernel.org/linux-mtd/0 linux-mtd/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 linux-mtd linux-mtd/ https://lore.kernel.org/linux-mtd \
linux-mtd@lists.infradead.org linux-mtd@archiver.kernel.org
public-inbox-index linux-mtd
Example config snippet for mirrors
Newsgroup available over NNTP:
nntp://nntp.lore.kernel.org/org.infradead.lists.linux-mtd
AGPL code for this site: git clone https://public-inbox.org/ public-inbox