Discussion:
GPMI IMX6ull timeout on dma
(too old to reply)
Michael Nazzareno Trimarchi
2018-10-02 13:22:29 UTC
Permalink
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 (***@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 '***@2' configuration
Verifying Hash Integrity ... OK
Trying '***@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 '***@2' configuration
Trying '***@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
2018-10-04 14:36:20 UTC
Permalink
Hi

I add now this code but nand seems incosistent
Signed-off-by: Michael Trimarchi <***@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
Post by Michael Nazzareno Trimarchi
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
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
2048, OOB size: 64
[ 2.651940] gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA :2
[ 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.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] 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 ...
Verifying Hash Integrity ... OK
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 ...
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 |
Michael Nazzareno Trimarchi
2018-10-05 10:32:18 UTC
Permalink
Hi Boris

I have reverted for now

Revert "mtd: rawnand: gpmi: support ->setup_data_interface()"
This reverts commit 76e1a0086a0c3276b384f77905345e0fcc886fdd.

Revert "mtd: rawnand: gpmi: use core timings instead of an empirical
derivation"
This reverts commit b1206122069aadabe1a8c50789277a978aaa4df7.

Michael

On Thu, Oct 4, 2018 at 4:36 PM Michael Nazzareno Trimarchi
Post by Michael Nazzareno Trimarchi
Hi
I add now this code but nand seems incosistent
---
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) {
@@ -492,11 +490,18 @@ static void dma_irq_callback(void *param)
/* We have to wait the BCH interrupt to finish. */
break;
-
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
Post by Michael Nazzareno Trimarchi
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
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
2048, OOB size: 64
[ 2.651940] gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA :2
[ 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.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] 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 ...
Verifying Hash Integrity ... OK
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 ...
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 |
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
Miquel Raynal
2018-10-29 09:40:57 UTC
Permalink
Hi Michael,
Post by Michael Nazzareno Trimarchi
Hi Boris
I have reverted for now
Revert "mtd: rawnand: gpmi: support ->setup_data_interface()"
This reverts commit 76e1a0086a0c3276b384f77905345e0fcc886fdd.
Revert "mtd: rawnand: gpmi: use core timings instead of an empirical
derivation"
This reverts commit b1206122069aadabe1a8c50789277a978aaa4df7.
Sorry for the delay, I've been very busy lately.

Please also Cc: me in your e-mails to the MTD ML.

AFAIR I'm the author of these patches so I would like to understand and
fix what's wrong there. As a start, can you discriminate which patch
actually makes the timings inconsistent? Are you ready to do more
testing to find what's wrong?


Thanks,
Miquèl
Michael Nazzareno Trimarchi
2018-10-29 09:43:05 UTC
Permalink
Hi

On Mon, Oct 29, 2018 at 10:41 AM Miquel Raynal
Post by Miquel Raynal
Hi Michael,
Post by Michael Nazzareno Trimarchi
Hi Boris
I have reverted for now
Revert "mtd: rawnand: gpmi: support ->setup_data_interface()"
This reverts commit 76e1a0086a0c3276b384f77905345e0fcc886fdd.
Revert "mtd: rawnand: gpmi: use core timings instead of an empirical
derivation"
This reverts commit b1206122069aadabe1a8c50789277a978aaa4df7.
Sorry for the delay, I've been very busy lately.
Please also Cc: me in your e-mails to the MTD ML.
AFAIR I'm the author of these patches so I would like to understand and
fix what's wrong there. As a start, can you discriminate which patch
actually makes the timings inconsistent? Are you ready to do more
testing to find what's wrong?
Yes it's on my plan. Now for field I need to revert them but I have
them in roadmap.
We are testing now an imx6dl. It can be a combination with the micron
part number too.

Michael
Post by Miquel Raynal
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 |
Miquel Raynal
2018-10-29 09:53:12 UTC
Permalink
Hi Michael,
Post by Michael Nazzareno Trimarchi
Hi
On Mon, Oct 29, 2018 at 10:41 AM Miquel Raynal
Post by Miquel Raynal
Hi Michael,
Post by Michael Nazzareno Trimarchi
Hi Boris
I have reverted for now
Revert "mtd: rawnand: gpmi: support ->setup_data_interface()"
This reverts commit 76e1a0086a0c3276b384f77905345e0fcc886fdd.
Revert "mtd: rawnand: gpmi: use core timings instead of an empirical
derivation"
This reverts commit b1206122069aadabe1a8c50789277a978aaa4df7.
Sorry for the delay, I've been very busy lately.
Please also Cc: me in your e-mails to the MTD ML.
AFAIR I'm the author of these patches so I would like to understand and
fix what's wrong there. As a start, can you discriminate which patch
actually makes the timings inconsistent? Are you ready to do more
testing to find what's wrong?
Yes it's on my plan. Now for field I need to revert them but I have
them in roadmap.
We are testing now an imx6dl. It can be a combination with the micron
part number too.
Sure, let us know about your discoveries, I really want the GPMI driver
to use core timings and ->setup_data_interface() so if there is
something wrong there it should be fixed.

Thanks,
Miquèl

Loading...