mtd_oobtest fails with GPMI-NAND

Hi,

When I try to run the mtd_oobtest on an i.Mx6Q board, it results in a failure with the following error. I'm using 3.5.7 Kernel.

root@freescale:/# insmod mtd_oobtest.ko dev=6
[ 7534.508880]
[ 7534.511228] =================================================
[ 7534.518460] mtd_oobtest: MTD device: 6
[ 7534.523000] mtd_oobtest: MTD device size 304087040, eraseblock size 262144, page size 4096, count of eraseblocks 1160, pages per eraseblock 64, OOB size 128
[ 7534.539301] mtd_oobtest: scanning for bad eraseblocks
[ 7534.545345] mtd_oobtest: scanned 1160 eraseblocks, 0 are bad
[ 7534.552482] mtd_oobtest: test 1 of 5
[ 7534.556797] mtd_oobtest: erasing whole device
[ 7537.523540] mtd_oobtest: erased 1160 eraseblocks
[ 7537.528888] mtd_oobtest: writing OOBs of whole device
[ 7537.534704] mtd_oobtest: error: writeoob failed at 0x0
[ 7537.540562] mtd_oobtest: error: use_len 0, use_offset 0
[ 7537.546565] mtd_oobtest: error -22 occurred
[ 7537.551456] =================================================

This boils down to the fake "struct nand_ecclayout" defined in <drivers/mtd/nand/gpmi-nand/gpmi-nand.c>

Is there a way to run this test successfully?

Regards,
Vikram

Quoted 24 lines · Vikram Narayanan

Hi,

When I try to run the mtd_oobtest on an i.Mx6Q board, it results in a failure with the following error.
I'm using 3.5.7 Kernel.

root@freescale:/# insmod mtd_oobtest.ko dev=6
[ 7534.508880]
[ 7534.511228] =================================================
[ 7534.518460] mtd_oobtest: MTD device: 6
[ 7534.523000] mtd_oobtest: MTD device size 304087040, eraseblock size
262144, page size 4096, count of eraseblocks 1160, pages per
eraseblock 64, OOB size 128
[ 7534.539301] mtd_oobtest: scanning for bad eraseblocks
[ 7534.545345] mtd_oobtest: scanned 1160 eraseblocks, 0 are bad
[ 7534.552482] mtd_oobtest: test 1 of 5
[ 7534.556797] mtd_oobtest: erasing whole device
[ 7537.523540] mtd_oobtest: erased 1160 eraseblocks
[ 7537.528888] mtd_oobtest: writing OOBs of whole device
[ 7537.534704] mtd_oobtest: error: writeoob failed at 0x0
[ 7537.540562] mtd_oobtest: error: use_len 0, use_offset 0
[ 7537.546565] mtd_oobtest: error -22 occurred
[ 7537.551456] =================================================

Quoted 4 lines

This boils down to the fake "struct nand_ecclayout" defined in <drivers/mtd/nand/gpmi-nand/gpmi-nand.c>

Is there a way to run this test successfully?

The gpmi-nand may use all the oob. So the oobtest may fails.

Hello Huang,

Quoted 28 lines · Huang Shijie

Quoted 27 lines · Vikram Narayanan

Hi,

When I try to run the mtd_oobtest on an i.Mx6Q board, it results in a failure with the following error.
I'm using 3.5.7 Kernel.

root@freescale:/# insmod mtd_oobtest.ko dev=6
[ 7534.508880]
[ 7534.511228] =================================================
[ 7534.518460] mtd_oobtest: MTD device: 6
[ 7534.523000] mtd_oobtest: MTD device size 304087040, eraseblock size
262144, page size 4096, count of eraseblocks 1160, pages per
eraseblock 64, OOB size 128
[ 7534.539301] mtd_oobtest: scanning for bad eraseblocks
[ 7534.545345] mtd_oobtest: scanned 1160 eraseblocks, 0 are bad
[ 7534.552482] mtd_oobtest: test 1 of 5
[ 7534.556797] mtd_oobtest: erasing whole device
[ 7537.523540] mtd_oobtest: erased 1160 eraseblocks
[ 7537.528888] mtd_oobtest: writing OOBs of whole device
[ 7537.534704] mtd_oobtest: error: writeoob failed at 0x0
[ 7537.540562] mtd_oobtest: error: use_len 0, use_offset 0
[ 7537.546565] mtd_oobtest: error -22 occurred
[ 7537.551456] =================================================

This boils down to the fake "struct nand_ecclayout" defined in <drivers/mtd/nand/gpmi-nand/gpmi-nand.c>

Quoted 2 lines

Quoted 1 line

Is there a way to run this test successfully?

The gpmi-nand may use all the oob. So the oobtest may fails.

I'm in receipt of the error mentioned in [1]. The FAQ also suggests to run mtd_tests. mtd_oobtest might give more information on whether or not the NAND driver is buggy.

Since I couldn't run this test on gpmi-nand due to the driver design, any ideas on how do I resolve the "ubi_io_read: error -74 (ECC error)" while mounting my UBIFS?

Thanks,
Vikram

[1] http://www.linux-mtd.infradead.org/faq/ubi.html#L_ecc_error

Quoted 38 lines · Vikram Narayanan

Hello Huang,

Quoted 25 lines · Huang Shijie

Quoted 24 lines · Vikram Narayanan

Hi,

When I try to run the mtd_oobtest on an i.Mx6Q board, it results in a failure with the following error.
I'm using 3.5.7 Kernel.

root@freescale:/# insmod mtd_oobtest.ko dev=6
[ 7534.508880]
[ 7534.511228] =================================================
[ 7534.518460] mtd_oobtest: MTD device: 6
[ 7534.523000] mtd_oobtest: MTD device size 304087040, eraseblock size
262144, page size 4096, count of eraseblocks 1160, pages per
eraseblock 64, OOB size 128
[ 7534.539301] mtd_oobtest: scanning for bad eraseblocks
[ 7534.545345] mtd_oobtest: scanned 1160 eraseblocks, 0 are bad
[ 7534.552482] mtd_oobtest: test 1 of 5
[ 7534.556797] mtd_oobtest: erasing whole device
[ 7537.523540] mtd_oobtest: erased 1160 eraseblocks
[ 7537.528888] mtd_oobtest: writing OOBs of whole device
[ 7537.534704] mtd_oobtest: error: writeoob failed at 0x0
[ 7537.540562] mtd_oobtest: error: use_len 0, use_offset 0
[ 7537.546565] mtd_oobtest: error -22 occurred
[ 7537.551456] =================================================

Quoted 5 lines

Quoted 4 lines

This boils down to the fake "struct nand_ecclayout" defined in <drivers/mtd/nand/gpmi-nand/gpmi-nand.c>

Is there a way to run this test successfully?

The gpmi-nand may use all the oob. So the oobtest may fails.

I'm in receipt of the error mentioned in [1]. The FAQ also suggests to run mtd_tests. mtd_oobtest might give more information on whether or not the NAND driver is buggy.

Quoted 4 lines

Since I couldn't run this test on gpmi-nand due to the driver design, any ideas on how do I resolve the "ubi_io_read: error -74 (ECC error)" while mounting my UBIFS?

[1] what's the kernel's version?

[2] what's type of the nand chips?
could you show me the nand chip's geometry?

Quoted 8 lines · Huang Shijie

Quoted 7 lines · Vikram Narayanan

Hello Huang,

Quoted 4 lines · Huang Shijie

Quoted 3 lines · Vikram Narayanan

Hi,

When I try to run the mtd_oobtest on an i.Mx6Q board, it results in a

Quoted 35 lines

Quoted 35 lines

Quoted 21 lines

Quoted 21 lines

failure with the following error.
I'm using 3.5.7 Kernel.

root@freescale:/# insmod mtd_oobtest.ko dev=6
[ 7534.508880]
[ 7534.511228] =================================================
[ 7534.518460] mtd_oobtest: MTD device: 6
[ 7534.523000] mtd_oobtest: MTD device size 304087040, eraseblock size
262144, page size 4096, count of eraseblocks 1160, pages per
eraseblock 64, OOB size 128
[ 7534.539301] mtd_oobtest: scanning for bad eraseblocks
[ 7534.545345] mtd_oobtest: scanned 1160 eraseblocks, 0 are bad
[ 7534.552482] mtd_oobtest: test 1 of 5
[ 7534.556797] mtd_oobtest: erasing whole device
[ 7537.523540] mtd_oobtest: erased 1160 eraseblocks
[ 7537.528888] mtd_oobtest: writing OOBs of whole device
[ 7537.534704] mtd_oobtest: error: writeoob failed at 0x0
[ 7537.540562] mtd_oobtest: error: use_len 0, use_offset 0
[ 7537.546565] mtd_oobtest: error -22 occurred
[ 7537.551456] =================================================

Quoted 5 lines

Quoted 4 lines

This boils down to the fake "struct nand_ecclayout" defined in <drivers/mtd/nand/gpmi-nand/gpmi-nand.c>

Is there a way to run this test successfully?

The gpmi-nand may use all the oob. So the oobtest may fails.

I'm in receipt of the error mentioned in [1]. The FAQ also suggests to run mtd_tests. mtd_oobtest might give more information on whether or not the NAND driver is buggy.

Since I couldn't run this test on gpmi-nand due to the driver design, any ideas on how do I resolve the "ubi_io_read: error -74 (ECC error)" while mounting my UBIFS?

Quoted 1 line

[1] what's the kernel's version?

The above log is from 3.5.7, but the results are same for the latest kernel (3.8-rc) too.

Quoted 2 lines

[2] what's type of the nand chips?
could you show me the nand chip's geometry?

Toshiba, 4 Gbit, (4096 +224) bytes ×64 pages ×2048blocks

writesize - 4KiB
oobsize - 224 bytes

Regards,
Vikram

Quoted 9 lines · Vikram Narayanan

Quoted 8 lines · Huang Shijie

Quoted 7 lines · Vikram Narayanan

Hello Huang,

Quoted 4 lines · Huang Shijie

Quoted 3 lines · Vikram Narayanan

Hi,

When I try to run the mtd_oobtest on an i.Mx6Q board, it results in a

Which mx6q' board are you using? the mx6q-arm2 or mx6q-ard?

The kernel only supports the mx6q-arm2 now.

Quoted 2 lines

Toshiba, 4 Gbit, (4096 +224) bytes ×64 pages ×2048blocks

The Toshiba's nand is not well supported by the kernel.
Are you sure the kernel parse out the correct geometry for the toshiba's nand?
Please recheck the page size and oob size with "mtdinfo /dev/mtd0".

Quoted 5 lines · Huang Shijie

Quoted 4 lines · Vikram Narayanan

Quoted 3 lines · Huang Shijie

Quoted 2 lines · Vikram Narayanan

Hello Huang,

Quoted 6 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines · Huang Shijie

Quoted 4 lines

Quoted 3 lines · Vikram Narayanan

Hi,

When I try to run the mtd_oobtest on an i.Mx6Q board, it results in a

Which mx6q' board are you using? the mx6q-arm2 or mx6q-ard?

I'm using a custom board.

Quoted 2 lines

The kernel only supports the mx6q-arm2 now.

May I know in what way the driver is restricted for using with other boards?

Quoted 9 lines

Quoted 3 lines

Toshiba, 4 Gbit, (4096 +224) bytes ×64 pages ×2048blocks

The Toshiba's nand is not well supported by the kernel.
Are you sure the kernel parse out the correct geometry for the toshiba's nand?
Please recheck the page size and oob size with "mtdinfo /dev/mtd0".

You're right and we knew it earlier as the Kernel detects the OOB size as 128 bytes. So, some remaining bytes become unused at the end of each page. i.e., (224-128). Instead of supporting ecc strength as ECC9 we end up using ECC8. Should this be a cause for the -74 error?

Regards,
Vikram

Quoted 2 lines

May I know in what way the driver is restricted for using with other boards?

The devicetree. Please check the dts file in arch/arm/boot/dts/. If there is no dts file for your board, the gpmi will not works very well for your board.
for example, there is arch/arm/boot/dts/imx6q-arm2.dts for the MX6Q-ARM2 board.

Quoted 4 lines

You're right and we knew it earlier as the Kernel detects the OOB size as 128 bytes. So, some remaining bytes become unused at the end of each page. i.e., (224-128). Instead of supporting ecc strength as ECC9 we end up using ECC8. Should this be a cause for the -74 error?

no. this is not the cause. even you get the wrong geometry of the nand chip. the gpmi still can works.

I think the root cause is the devicetree issue as above.

Quoted 7 lines · Huang Shijie

Quoted 2 lines

May I know in what way the driver is restricted for using with other boards?

The devicetree. Please check the dts file in arch/arm/boot/dts/. If there is no dts file for your board, the gpmi will not works very well for your board.
for example, there is arch/arm/boot/dts/imx6q-arm2.dts for the MX6Q-ARM2 board.

I've a valid dts file for my board which is good enough to probe the Toshiba NAND on-board and mount a UBIFS filesystem.

Quoted 9 lines

Quoted 5 lines

You're right and we knew it earlier as the Kernel detects the OOB size as 128 bytes. So, some remaining bytes become unused at the end of each page. i.e., (224-128). Instead of supporting ecc strength as ECC9 we end up using ECC8. Should this be a cause for the -74 error?

no. this is not the cause. even you get the wrong geometry of the nand chip. the gpmi still can works.

I think the root cause is the devicetree issue as above.

Something else is causing the issue. Can you give some other pointers which can potentially cause this -74 error while mounting?

Regards,
Vikram

Quoted 9 lines · Vikram Narayanan

Quoted 7 lines · Huang Shijie

Quoted 2 lines

May I know in what way the driver is restricted for using with other boards?

The devicetree. Please check the dts file in arch/arm/boot/dts/. If there is no dts file for your board, the gpmi will not works very well for your board.
for example, there is arch/arm/boot/dts/imx6q-arm2.dts for the MX6Q-ARM2 board.

Quoted 2 lines

I've a valid dts file for my board which is good enough to probe the Toshiba NAND on-board and mount a UBIFS filesystem.

could you tell the dts file for your board?
are you sure the pinmux settings are right?

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

You're right and we knew it earlier as the Kernel detects the OOB size as 128 bytes. So, some remaining bytes become unused at the end of each page. i.e., (224-128). Instead of supporting ecc strength as ECC9 we end up using ECC8. Should this be a cause for the -74 error?

no. this is not the cause. even you get the wrong geometry of the nand chip. the gpmi still can works.

Quoted 4 lines

Quoted 1 line

I think the root cause is the devicetree issue as above.

Something else is causing the issue. Can you give some other pointers which can potentially cause this -74 error while mounting?

the -74 error is the EBADMSG, it's caused by the uncorrectable ECC failure. There are many reasons can cause this error:
[1] the pinmux setting is not right, the gpmi does not works well.

[2] the wrong setting of BCH. for example, the page size is 8K, you
set 4k to BCH.
so you can set the correct nand geometry parameters for your
nand chip firstly, and then do the debug.

    [3] timings.

Quoted 18 lines · Huang Shijie

Quoted 15 lines · Vikram Narayanan

Quoted 9 lines · Huang Shijie

Quoted 3 lines

May I know in what way the driver is restricted for using with other boards?

The devicetree. Please check the dts file in arch/arm/boot/dts/. If there is no dts file for your board, the gpmi will not works very well for your board.
for example, there is arch/arm/boot/dts/imx6q-arm2.dts for the MX6Q-ARM2 board.

I've a valid dts file for my board which is good enough to probe the Toshiba NAND on-board and mount a UBIFS filesystem.

Quoted 2 lines

could you tell the dts file for your board?
are you sure the pinmux settings are right?

I'm using the same pinumx settings mentioned in the file "arch/arm/boot/dts/imx6q.dtsi". Hope that is right.

Quoted 12 lines

Quoted 12 lines

Quoted 10 lines

Quoted 5 lines

You're right and we knew it earlier as the Kernel detects the OOB size as 128 bytes. So, some remaining bytes become unused at the end of each page. i.e., (224-128). Instead of supporting ecc strength as ECC9 we end up using ECC8. Should this be a cause for the -74 error?

no. this is not the cause. even you get the wrong geometry of the nand chip. the gpmi still can works.

I think the root cause is the devicetree issue as above.

Quoted 7 lines

Quoted 2 lines

Something else is causing the issue. Can you give some other pointers which can potentially cause this -74 error while mounting?

the -74 error is the EBADMSG, it's caused by the uncorrectable ECC failure.
There are many reasons can cause this error:
[1] the pinmux setting is not right, the gpmi does not works well.

As said above, my pinmux settings are right. GPMI detects my NAND, does read/write/erase/mount. At times I'm seeing this -74 issue. Sometimes this error goes off in the next reboot.

Quoted 4 lines

[2] the wrong setting of BCH. for example, the page size is 8K, you
set 4k to BCH.
so you can set the correct nand geometry parameters for your
nand chip firstly, and then do the debug.

From the driver I understood that the geometry are determined according to the data from the read_id bytes. mtd layer detects my NAND as 4K page-sized. So, this shouldn't be a problem I guess.

Quoted 1 line

    [3] timings.

Should I tweak something specific according to the NAND device that I have? Can you give more hints please?

Thanks,

Vikram

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Quoted 19 lines · Vikram Narayanan

Quoted 18 lines · Huang Shijie

Quoted 15 lines · Vikram Narayanan

Quoted 9 lines · Huang Shijie

Quoted 3 lines

May I know in what way the driver is restricted for using with other boards?

The devicetree. Please check the dts file in arch/arm/boot/dts/. If there is no dts file for your board, the gpmi will not works very well for your board.
for example, there is arch/arm/boot/dts/imx6q-arm2.dts for the MX6Q-ARM2 board.

I've a valid dts file for my board which is good enough to probe the Toshiba NAND on-board and mount a UBIFS filesystem.

Quoted 8 lines

Quoted 2 lines

could you tell the dts file for your board?
are you sure the pinmux settings are right?

I'm using the same pinumx settings mentioned in the file "arch/arm/boot/dts/imx6q.dtsi". Hope that is right.

The pinmux was set for the arm2 board. So i am not sure it is suitable for your board.

i suggest you check this carefully with your board.

Quoted 32 lines

Quoted 12 lines

Quoted 12 lines

Quoted 10 lines

Quoted 5 lines

You're right and we knew it earlier as the Kernel detects the OOB size as 128 bytes. So, some remaining bytes become unused at the end of each page. i.e., (224-128). Instead of supporting ecc strength as ECC9 we end up using ECC8. Should this be a cause for the -74 error?

no. this is not the cause. even you get the wrong geometry of the nand chip. the gpmi still can works.

I think the root cause is the devicetree issue as above.

Quoted 7 lines

Quoted 2 lines

Something else is causing the issue. Can you give some other pointers which can potentially cause this -74 error while mounting?

the -74 error is the EBADMSG, it's caused by the uncorrectable ECC failure.
There are many reasons can cause this error:
[1] the pinmux setting is not right, the gpmi does not works well.

As said above, my pinmux settings are right. GPMI detects my NAND, does read/write/erase/mount. At times I'm seeing this -74 issue. Sometimes this error goes off in the next reboot.

Quoted 4 lines

[2] the wrong setting of BCH. for example, the page size is 8K, you
set 4k to BCH.
so you can set the correct nand geometry parameters for your
nand chip firstly, and then do the debug.

Quoted 4 lines

From the driver I understood that the geometry are determined according to the data from the read_id bytes. mtd layer detects my NAND as 4K page-sized. So, this shouldn't be a problem I guess.

yes. i agree.

Quoted 6 lines

Quoted 1 line

    [3] timings.

Should I tweak something specific according to the NAND device that I have? Can you give more hints please?

Could you make sure that the page write is good?
You can test it with the mtd_torture.c

thanks
Huang Shijie

Quoted 7 lines

Thanks,

Vikram

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Quoted 10 lines · Huang Shijie

Quoted 9 lines · Vikram Narayanan

Quoted 7 lines · Huang Shijie

Quoted 2 lines

May I know in what way the driver is restricted for using with other boards?

The devicetree. Please check the dts file in arch/arm/boot/dts/. If there is no dts file for your board, the gpmi will not works very well for your board.
for example, there is arch/arm/boot/dts/imx6q-arm2.dts for the MX6Q-ARM2 board.

Quoted 4 lines

Quoted 2 lines

I've a valid dts file for my board which is good enough to probe the Toshiba NAND on-board and mount a UBIFS filesystem.

could you tell the dts file for your board?
are you sure the pinmux settings are right?

I'm using the same pinumx settings mentioned in the file "arch/arm/boot/dts/imx6q.dtsi". Hope that is right.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

You're right and we knew it earlier as the Kernel detects the OOB size as 128 bytes. So, some remaining bytes become unused at the end of each page. i.e., (224-128). Instead of supporting ecc strength as ECC9 we end up using ECC8. Should this be a cause for the -74 error?

no. this is not the cause. even you get the wrong geometry of the nand chip. the gpmi still can works.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

I think the root cause is the devicetree issue as above.

Something else is causing the issue. Can you give some other pointers which can potentially cause this -74 error while mounting?

the -74 error is the EBADMSG, it's caused by the uncorrectable ECC failure. There are many reasons can cause this error:
[1] the pinmux setting is not right, the gpmi does not works well.

As said above, my pinmux settings are right. GPMI detects my NAND, does read/write/erase/mount. At times I'm seeing this -74 issue. Sometimes this error goes off in the next reboot.

Quoted 4 lines

[2] the wrong setting of BCH. for example, the page size is 8K, you
set 4k to BCH.
so you can set the correct nand geometry parameters for your
nand chip firstly, and then do the debug.

From the driver I understood that the geometry are determined according
to the data from the read_id bytes. mtd layer detects my NAND as 4K page-sized. So, this shouldn't be a problem I guess.

Quoted 1 line

    [3] timings.

Should I tweak something specific according to the NAND device that I have? Can you give more hints please?

Thanks,
Vikram

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Hi Vikram,

I might be seeing something similar on my iMX6 board. Here mtd_subpagetest sometimes fails.

What is the current status on your platform? Did you resolve this problem? If yes, what did you have to change/fix?

Quoted 60 lines · Huang Shijie

Quoted 10 lines

Quoted 9 lines · Vikram Narayanan

Quoted 7 lines · Huang Shijie

Quoted 2 lines

May I know in what way the driver is restricted for using with other boards?

The devicetree. Please check the dts file in arch/arm/boot/dts/. If there is no dts file for your board, the gpmi will not works very well for your board.
for example, there is arch/arm/boot/dts/imx6q-arm2.dts for the MX6Q-ARM2 board.

Quoted 4 lines

Quoted 2 lines

I've a valid dts file for my board which is good enough to probe the Toshiba NAND on-board and mount a UBIFS filesystem.

could you tell the dts file for your board?
are you sure the pinmux settings are right?

I'm using the same pinumx settings mentioned in the file "arch/arm/boot/dts/imx6q.dtsi". Hope that is right.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

You're right and we knew it earlier as the Kernel detects the OOB size as 128 bytes. So, some remaining bytes become unused at the end of each page. i.e., (224-128). Instead of supporting ecc strength as ECC9 we end up using ECC8. Should this be a cause for the -74 error?

no. this is not the cause. even you get the wrong geometry of the nand chip. the gpmi still can works.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

I think the root cause is the devicetree issue as above.

Something else is causing the issue. Can you give some other pointers which can potentially cause this -74 error while mounting?

the -74 error is the EBADMSG, it's caused by the uncorrectable ECC failure. There are many reasons can cause this error:
[1] the pinmux setting is not right, the gpmi does not works well.

As said above, my pinmux settings are right. GPMI detects my NAND, does read/write/erase/mount. At times I'm seeing this -74 issue. Sometimes this error goes off in the next reboot.

Quoted 4 lines

[2] the wrong setting of BCH. for example, the page size is 8K, you
set 4k to BCH.
so you can set the correct nand geometry parameters for your
nand chip firstly, and then do the debug.

From the driver I understood that the geometry are determined according
to the data from the read_id bytes. mtd layer detects my NAND as 4K page-sized. So, this shouldn't be a problem I guess.

Quoted 1 line

     [3] timings.

Should I tweak something specific according to the NAND device that I have? Can you give more hints please?

Thanks,
Vikram

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Quoted 2 lines

I might be seeing something similar on my iMX6 board. Here mtd_subpagetest sometimes fails.

AFAIR, subpagetest passed for me when I tested.

BTW, What kind of errors are you getting? Any logs?

Quoted 3 lines

What is the current status on your platform? Did you resolve this problem? If yes, what did you have to change/fix?

Unfortunately no. I haven't got enough time to look into this.

Also, I don't have enough spare boards to sacrifice it for mtd_torture test.

Hi Vikram,

Quoted 6 lines · Vikram Narayanan

Quoted 2 lines

I might be seeing something similar on my iMX6 board. Here mtd_subpagetest sometimes fails.

AFAIR, subpagetest passed for me when I tested.

BTW, What kind of errors are you getting? Any logs?

Sure. Here 2 logs with v3.9.1:

# insmod mtd_subpagetest.ko dev=3
[  315.947734] mtd_subpagetest: verified up to eraseblock 0
[  317.140658] mtd_subpagetest: error: read failed at 0xd60800

[ 2561.996470] mtd_subpagetest: error: read failed at 0xe380800

Quoted 5 lines

Quoted 3 lines

What is the current status on your platform? Did you resolve this problem? If yes, what did you have to change/fix?

Unfortunately no. I haven't got enough time to look into this.

Too bad. Could you please explain again, how you first noticed that the you might have a problem with NAND on your imx6 board?

We noticed a problem first in U-Boot by using the following commands:

=> nand erase.part ubi; ubi part ubi

This works the first time without any problem. But the 2nd time it leads to "uncorrectable errors" (0xfe) while reading from some blocks. And those failing blocks tend to be the same (more or less).

Perhaps you might want to test this in U-Boot (if you use it) as well.

Quoted 9 lines

Quoted 6 lines

Quoted 2 lines

I might be seeing something similar on my iMX6 board. Here mtd_subpagetest sometimes fails.

AFAIR, subpagetest passed for me when I tested.

BTW, What kind of errors are you getting? Any logs?

Sure. Here 2 logs with v3.9.1:

Quoted 5 lines

# insmod mtd_subpagetest.ko dev=3
[  315.947734] mtd_subpagetest: verified up to eraseblock 0
[  317.140658] mtd_subpagetest: error: read failed at 0xd60800

[ 2561.996470] mtd_subpagetest: error: read failed at 0xe380800

Looks like it is happening at random. Two different physical locations on two different runs.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

What is the current status on your platform? Did you resolve this problem? If yes, what did you have to change/fix?

Unfortunately no. I haven't got enough time to look into this.

Too bad. Could you please explain again, how you first noticed that the you might have a problem with NAND on your imx6 board?

For me, the error (-74) happened when the kernel is finally trying to mount the rootfs. It is random as well.

<http://www.linux-mtd.infradead.org/faq/ubi.html#L_ecc_error>
As suggested in the above link, I tried to run the oobtest and it was failing due to the missing ecc_layout structure. That's how this thread was born.

Quoted 11 lines

We noticed a problem first in U-Boot by using the following commands:

=> nand erase.part ubi; ubi part ubi

This works the first time without any problem. But the 2nd time it leads to "uncorrectable errors" (0xfe) while reading from some blocks. And those failing blocks tend to be the same (more or less).

Perhaps you might want to test this in U-Boot (if you use it) as well.

I'm using u-boot v2012.10, with no extra patches for mtd/ubi layers.

I tried in both the ways. Issued "nand erase; ubi part" and "ubi part" alone. For me, It didn't give any "uncorrectable errors" error you've mentioned.

The only error I came across in u-boot is "fixable bit-flip" issue. My colleagues have reported it sometime back. But I couldn't reproduce it and neither could they.

Can you please post the logs for the "uncorrectable errors" in u-boot? That might give some hints to Huang.

Quoted 3 lines

Also, I don't have enough spare boards to sacrifice it for mtd_torture test.

Yes, I can understand this.

Huang, do you have any idea on how to proceed here? What else could/should we test? Any ideas/hints?

Here the infos for our NAND device:

[    0.917552] ONFI param page 0 valid
[    0.921053] ONFI flash detected
[    0.924206] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABADAH4), 512MiB, page size: 2048, OOB size: 64

[

Quoted 5 lines

Quoted 1 line

Also, I don't have enough spare boards to sacrifice it for mtd_torture test.

Yes, I can understand this.

Huang, do you have any idea on how to proceed here? What else could/should we test? Any ideas/hints?

Currently, the kernel supports three imx6 boards for the gpmi-nand:
imx6q-arm2, imx6q-sabreauto, imx6dl-sabareauto.

I am afraid your board is none of them. I doubt your board is not correctly configrated with
some timing or signals.

The key issue (i want to emphosis ) is that the current gpmi-nand does not support the
subpage operations.

Quoted 6 lines

Here the infos for our NAND device:

[    0.917552] ONFI param page 0 valid
[    0.921053] ONFI flash detected
[    0.924206] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron MT29F4G08ABADAH4), 512MiB, page size: 2048, OOB size: 64

[

It's a SLC ,or a MLC?

Quoted 11 lines · Huang Shijie

Quoted 5 lines

Quoted 1 line

Also, I don't have enough spare boards to sacrifice it for mtd_torture test.

Yes, I can understand this.

Huang, do you have any idea on how to proceed here? What else could/should we test? Any ideas/hints?

Currently, the kernel supports three imx6 boards for the gpmi-nand:
imx6q-arm2, imx6q-sabreauto, imx6dl-sabareauto.

I am afraid your board is none of them. I doubt your board is not correctly configrated with
some timing or signals.

Correct, our board is a custom imx6 board. Basically NAND is working just fine (UBI/UBIFS works basically). This board even boots from NAND. So at least the pin muxing has to be correct.

Please correct me if I'm wrong, but from my understanding the Linux GPMI NAND driver configures the timings. So this is not board platform code related but NAND driver related.

Do you have any hints where to "tune/change" some values (timing or signal related) to fix this error?

Quoted 3 lines

The key issue (i want to emphosis ) is that the current gpmi-nand does not support the
subpage operations.

Yes. And this is disabled via setting NAND_NO_SUBPAGE_WRITE in the options variable in the GPMI NAND driver.

BTW: I just tested with the "mtd_nandbiterrs" test. This fails directly. I would have expected the ECC to being able to at least correct the errors for some loops:

# insmod mtd_nandbiterrs.ko dev=3 mode=0
[  831.622694]
[  831.624198] ==================================================
[  831.630071] mtd_nandbiterrs: MTD device: 3
[  831.634259] mtd_nandbiterrs: MTD device size 519045120,
eraseblock=131072, page=2048, oob=64
[  831.642796] mtd_nandbiterrs: Device uses 1 subpages of 2048 bytes
[  831.648920] mtd_nandbiterrs: Using page=0, offset=0, eraseblock=0
[  831.655026] mtd_nandbiterrs: erase_block
[  831.659502] mtd_nandbiterrs: incremental biterrors test
[  831.664805] mtd_nandbiterrs: write_page
[  831.669028] mtd_nandbiterrs: rewrite page
[  831.673413] mtd_nandbiterrs: read_page
[  831.691729] mtd_nandbiterrs: error: read failed at 0x0
[  831.696887] mtd_nandbiterrs: After 0 biterrors per subpage, read
reported error -74
[  831.704546] mtd_nandbiterrs: erase_block
[  831.708997] mtd_nandbiterrs: finished successfully.
[  831.713880] ==================================================
insmod: error inserting 'mtd_nandbiterrs.ko': -1 Input/output error

Huang, is this to be expected? How does this look on one of your officially "supported" imx6 boards with NAND support?

SLC. Why do you ask?

Quoted 7 lines

Please correct me if I'm wrong, but from my understanding the Linux GPMI NAND driver configures the timings. So this is not board platform code related but NAND driver related.

Do you have any hints where to "tune/change" some values (timing or signal related) to fix this error?

Please check the schematic, is there some pin conflict with the gpmi-nand? What's the pad value for these pins? You can take a reference with current dts file.

Quoted 11 lines

Quoted 3 lines

The key issue (i want to emphosis ) is that the current gpmi-nand does not support the
subpage operations.

Yes. And this is disabled via setting NAND_NO_SUBPAGE_WRITE in the options variable in the GPMI NAND driver.

BTW: I just tested with the "mtd_nandbiterrs" test. This fails directly. I would have expected the ECC to being able to at least correct the errors for some loops:

# insmod mtd_nandbiterrs.ko dev=3 mode=0

Quoted 3 lines

Huang, is this to be expected? How does this look on one of your officially "supported" imx6 boards with NAND support?

I suggest you do not use the mtd_nandbiterrs.ko. It will call the mtd_write_oob() which will definitely lead to the -EBADMSG (-74) error.

The mtd_write_oob() in mtd_nandbiterrs.ko writes a whole page without enabling the BCH to do the hardware ECC.
But mtd_read() in mtd_nandbiterrs.ko DOES do the hardware ECC by the BCH. It's normal that you meet -74.

You can use the mtd_torturetest, such as:

#insmod mtd_torturetest.ko dev=3 check=1 cycles_count=1 eb=0 ebcnt=4 gran=1

Quoted 1 line

SLC. Why do you ask?

For the MLC, if you write the OOB, it will impacts other part of the page. For some nands, you will meet a -74.
that's another story.

Done. But no errors in this test though. Even with increasing the cycles_count. I don't want to destroy this chip, so I'm not increasing the cycles too much.

Which NAND devices did you test with on imx6? Did you also tests with a "similar" Micron ONFI chip as this one (MT29F4G08ABADAH4)?

Quoted 3 lines · Stefan Roese

Done. But no errors in this test though. Even with increasing the cycles_count. I don't want to destroy this chip, so I'm not increasing the cycles too much.

If you can pass the bonnie++ stress test on the ubifs, it means the gpmi works fine.

Quoted 3 lines

Which NAND devices did you test with on imx6? Did you also tests with a "similar" Micron ONFI chip as this one (MT29F4G08ABADAH4)?

For micron's chips, I tested more then 10 chips. some chips show following :
Micron MT29F4G08ABADAWP (2048 + 64)

Micron MT29F8G08ABACAWP (4096 + 224)

Micron MT29F4G08ABAEAWP (4096 + 224)

Micron MT29F32G08QAA (4096 + 218)

But i do not test your chip. I do not have this chip, if i have, i can test it on arm2/ard boards.

Quoted 2 lines

Looks like it is happening at random. Two different physical locations on two different runs.

These locations (blocks) where the errors happen are not always identical. But some blocks reoccur. And this Linux test stops when one error is detected. The U-Boot reported multiple blocks, where some blocks were most of the time defective.

So its not really random.

Quoted 3 lines

The only error I came across in u-boot is "fixable bit-flip" issue. My colleagues have reported it sometime back. But I couldn't reproduce it and neither could they.

Could you please post a link to this thread?

Quoted 2 lines

Can you please post the logs for the "uncorrectable errors" in u-boot? That might give some hints to Huang.

Sure. Please note that I tracked the error (-74) back to the U-Boot imx NAND driver (mxs_nand.c):

	/* Loop over status bytes, accumulating ECC status. */
	status = nand_info->oob_buf + mxs_nand_aux_status_offset();
	for (i = 0; i < mxs_nand_ecc_chunk_cnt(mtd->writesize); i++) {
		if (status[i] == 0x00)
			continue;

		if (status[i] == 0xff)
			continue;

		if (status[i] == 0xfe) {
			failed++;
			continue;
		}

		corrected += status[i];
	}

I could also add some code to the Linux driver to see, if the error happens at the same place (status == 0xfe). I'm pretty sure that this is the case though.

Here the logs from U-Boot:

=> nand erase.part ubi;
NAND erase.part: device 0 offset 0x1100000, size 0x1ef00000
Erasing at 0x1ffe0000 -- 100% complete.
OK
=> ubi part ubi
UBI: mtd1 is detached from ubi0
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 3093:0, read 64 bytes UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 3956:0, read 64 bytes UBI error: ubi_read_volume_table: the layout volume was not found
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -22
UBI init error 22

Another thing to mention is, that using this command (nand erase; nand erase;ubi part) never triggers this problem. So an additional erase somehow seems to fix this problem. Still not sure why this is the case.

Vikram, which NAND part/chip are you using again?

Quoted 9 lines · Huang Shijie

Quoted 5 lines

Quoted 1 line

Also, I don't have enough spare boards to sacrifice it for mtd_torture test.

Yes, I can understand this.

Huang, do you have any idea on how to proceed here? What else could/should we test? Any ideas/hints?

Currently, the kernel supports three imx6 boards for the gpmi-nand:
imx6q-arm2, imx6q-sabreauto, imx6dl-sabareauto.

Quoted 3 lines

I am afraid your board is none of them. I doubt your board is not correctly configrated with
some timing or signals.

Correct, our board is a custom imx6 board. Basically NAND is working just fine (UBI/UBIFS works basically). This board even boots from NAND. So at least the pin muxing has to be correct.

Please correct me if I'm wrong, but from my understanding the Linux GPMI NAND driver configures the timings. So this is not board platform code related but NAND driver related.

Do you have any hints where to "tune/change" some values (timing or signal related) to fix this error?

Quoted 4 lines

Huang, is this to be expected? How does this look on one of your officially "supported" imx6 boards with NAND support?

I suggest you do not use the mtd_nandbiterrs.ko. It will call the mtd_write_oob() which will definitely lead to the -EBADMSG (-74) error.

The mtd_write_oob() in mtd_nandbiterrs.ko writes a whole page without enabling the BCH to do the hardware ECC.
But mtd_read() in mtd_nandbiterrs.ko DOES do the hardware ECC by the BCH. It's normal that you meet -74.

Do you have any specific parameters that I should use for this test?

Do you have any specific parameters that I should use for this test?

Hello Huang,

Quoted 8 lines · Huang Shijie

Quoted 4 lines

Huang, is this to be expected? How does this look on one of your officially "supported" imx6 boards with NAND support?

I suggest you do not use the mtd_nandbiterrs.ko. It will call the mtd_write_oob() which will definitely lead to the -EBADMSG (-74) error.

Quoted 4 lines

The mtd_write_oob() in mtd_nandbiterrs.ko writes a whole page without enabling the BCH to do the hardware ECC.
But mtd_read() in mtd_nandbiterrs.ko DOES do the hardware ECC by the BCH. It's normal that you meet -74.

I wonder if this has something to do with the fake "struct nand_ecclayout" defined in <drivers/mtd/nand/gpmi-nand/gpmi-nand.c>?

Could you please explain on what is the technical restriction for not providing a _sane_ ecclayout structure, so that the mtd_tests run happily?

Regards,
Vikram

Quoted 17 lines · Vikram Narayanan

Hello Huang,

Quoted 8 lines · Huang Shijie

Quoted 4 lines

Huang, is this to be expected? How does this look on one of your officially "supported" imx6 boards with NAND support?

I suggest you do not use the mtd_nandbiterrs.ko. It will call the mtd_write_oob() which will definitely lead to the -EBADMSG (-74) error.

Quoted 5 lines

The mtd_write_oob() in mtd_nandbiterrs.ko writes a whole page without enabling the BCH to do the hardware ECC.
But mtd_read() in mtd_nandbiterrs.ko DOES do the hardware ECC by the BCH.
It's normal that you meet -74.

Quoted 3 lines

I wonder if this has something to do with the fake "struct nand_ecclayout" defined in <drivers/mtd/nand/gpmi-nand/gpmi-nand.c>?

it's not a fake structure, i think.

We do use all the oob now.

Quoted 5 lines

Could you please explain on what is the technical restriction for not providing a _sane_ ecclayout structure, so that the mtd_tests run happily?

could you please read the chapter about the BCH, especially the "Flash Page Layout".

The reason why We use all the oob is that we can not get the correct ECC info from the nand, such as "4 bits for 512 byte".
I have sent a patch set with whitch we can parse out some ECC info for ONFI nand and full-id nand.

The gpmi-nand does not live for mtd_tests. If it can not pass some mtd_tests, it does not mean the gpmi has bugs.

So, don't think that we are pointing that the GPMI-NAND driver is buggy. My only concern is _mtdtests_ are there to reveal

problems (if any) in the NAND related code, be it a driver or the mtd layer. If one can make that run happily, it's easy to pin point the source of these errors. (-74, fixable bit-flip etc).

Hope this clarifies my point.