mtd_oobtest fails with GPMI-NAND

mtd_oobtest fails with GPMI-NAND

[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>

Is there a way to run this test successfully?

Regards,
Vikram

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年01月19日 00:52, 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>
>
> Is there a way to run this test successfully?
The gpmi-nand may use all the oob. So the oobtest may fails.

thanks
Huang Shijie
>
> Regards,
> Vikram
>

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

Hello Huang,

On 1/21/2013 7:42 AM, Huang Shijie wrote:
> 于 2013年01月19日 00:52, 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>
>>
>> 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

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年01月28日 10:39, Vikram Narayanan 写道:
> Hello Huang,
>
> On 1/21/2013 7:42 AM, Huang Shijie wrote:
>> 于 2013年01月19日 00:52, 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>
>>>
>>> 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?
>
[1] what's the kernel's version?

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

thanks
Huang Shijie

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

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

On 1/28/2013 8:50 AM, Huang Shijie wrote:
> 于 2013年01月28日 10:39, Vikram Narayanan 写道:
>> Hello Huang,
>>
>> On 1/21/2013 7:42 AM, Huang Shijie wrote:
>>> 于 2013年01月19日 00:52, 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>
>>>>
>>>> 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?
>>
> [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.

> [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

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年01月29日 01:04, Vikram Narayanan 写道:
> On 1/28/2013 8:50 AM, Huang Shijie wrote:
>> 于 2013年01月28日 10:39, Vikram Narayanan 写道:
>>> Hello Huang,
>>>
>>> On 1/21/2013 7:42 AM, Huang Shijie wrote:
>>>> 于 2013年01月19日 00:52, 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.

>>>>> 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?
>>>> 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?
>>>
>> [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.
>
>> [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

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".

thanks
Huang Shijie
> writesize - 4KiB
> oobsize - 224 bytes
>
> Regards,
> Vikram
>

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

On 1/29/2013 7:36 AM, Huang Shijie wrote:
> 于 2013年01月29日 01:04, Vikram Narayanan 写道:
>> On 1/28/2013 8:50 AM, Huang Shijie wrote:
>>> 于 2013年01月28日 10:39, Vikram Narayanan 写道:
>>>> Hello Huang,
>>>>
>>>> On 1/21/2013 7:42 AM, Huang Shijie wrote:
>>>>> 于 2013年01月19日 00:52, 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.

> The kernel only supports the mx6q-arm2 now.

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

>>
>> 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

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年01月29日 10:26, Vikram Narayanan 写道:
> On 1/29/2013 7:36 AM, Huang Shijie wrote:
>> 于 2013年01月29日 01:04, Vikram Narayanan 写道:
>>> On 1/28/2013 8:50 AM, Huang Shijie wrote:
>>>> 于 2013年01月28日 10:39, Vikram Narayanan 写道:
>>>>> Hello Huang,
>>>>>
>>>>> On 1/21/2013 7:42 AM, Huang Shijie wrote:
>>>>>> 于 2013年01月19日 00:52, 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.
ok.
>
>> The kernel only supports the mx6q-arm2 now.
>
> 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.

>
>>>
>>> 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?
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.

thanks
Huang Shijie
>
> Regards,
> Vikram
>

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

On 1/29/2013 8:06 AM, Huang Shijie wrote:
>> 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.

>> 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

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年01月30日 00:28, Vikram Narayanan 写道:
> On 1/29/2013 8:06 AM, Huang Shijie wrote:
>>> 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.
could you tell the dts file for your board?
are you sure the pinmux settings are right?

>
>>> 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?
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.

BR
Huang Shijie
>
> Regards,
> Vikram
>

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

On 1/30/2013 7:57 AM, Huang Shijie wrote:
> 于 2013年01月30日 00:28, Vikram Narayanan 写道:
>> On 1/29/2013 8:06 AM, Huang Shijie wrote:
>>>> 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.
> 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.

>>
>>>> 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?
> 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.

>     [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.

>     [3] timings.

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

Thanks,
Vikram

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

On Sat, Feb 2, 2013 at 2:41 PM, Vikram Narayanan <vikram186@gmail.com> wrote:
> On 1/30/2013 7:57 AM, Huang Shijie wrote:
>>
>> 于 2013年01月30日 00:28, Vikram Narayanan 写道:
>>>
>>> On 1/29/2013 8:06 AM, Huang Shijie wrote:
>>>>>
>>>>> 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.
>>
>> 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.


>>>
>>>>> 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?
>>
>> 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.
>
>
>>     [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.
>
yes. i agree.

>>     [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



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

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

On Sat, Feb 2, 2013 at 3:42 PM, Huang Shijie <shijie8@gmail.com> wrote:
> On Sat, Feb 2, 2013 at 2:41 PM, Vikram Narayanan <vikram186@gmail.com> wrote:
>> On 1/30/2013 7:57 AM, Huang Shijie wrote:
>>>
>>> 于 2013年01月30日 00:28, Vikram Narayanan 写道:
>>>>
>>>> On 1/29/2013 8:06 AM, Huang Shijie wrote:
>>>>>>
>>>>>> 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.
>>>
>>> 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.
>
>
>>>>
>>>>>> 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?
>>>
>>> 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.
>>
>>
>>>     [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.
>>
> yes. i agree.
>
>>>     [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

sorry.  it should be the mtd_torturetest.c.


>
> thanks
> Huang Shijie
>
>
>
>> Thanks,
>>
>> Vikram
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: mtd_oobtest fails with GPMI-NAND

[Stefan Roese]

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?

Thanks,
Stefan

On 02/02/2013 07:41 AM, Vikram Narayanan wrote:
> On 1/30/2013 7:57 AM, Huang Shijie wrote:
>> 于 2013年01月30日 00:28, Vikram Narayanan 写道:
>>> On 1/29/2013 8:06 AM, Huang Shijie wrote:
>>>>> 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.
>> 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.
> 
>>>
>>>>> 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?
>> 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.
> 
>>     [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.
> 
>>     [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/
> 

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

Hello Stefan,

On 5/8/2013 8:03 PM, Stefan Roese wrote:
> Hi Vikram,
>
> 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?

>
> 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.

Regards,
Vikram

> On 02/02/2013 07:41 AM, Vikram Narayanan wrote:
>> On 1/30/2013 7:57 AM, Huang Shijie wrote:
>>> 于 2013年01月30日 00:28, Vikram Narayanan 写道:
>>>> On 1/29/2013 8:06 AM, Huang Shijie wrote:
>>>>>> 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.
>>> 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.
>>
>>>>
>>>>>> 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?
>>> 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.
>>
>>>      [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.
>>
>>>      [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/
>>
>

Re: mtd_oobtest fails with GPMI-NAND

[Stefan Roese]

Hi Vikram,

On 05/09/2013 02:30 PM, Vikram Narayanan wrote:
>> 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
[  305.991516] 
[  305.993022] =================================================
[  305.998817] mtd_subpagetest: MTD device: 3
[  306.003016] mtd_subpagetest: MTD device size 519045120, eraseblock size 131072, page size 2048, subpage size 2048, count of eraseblocks 3960, pages per eraseblock 64, OOB size 64
[  306.019077] mtd_subpagetest: scanning for bad eraseblocks
[  306.025249] mtd_subpagetest: scanned 3960 eraseblocks, 0 are bad
[  306.031281] mtd_subpagetest: erasing whole device
[  307.998911] mtd_subpagetest: erased 3960 eraseblocks
[  308.003884] mtd_subpagetest: writing whole device
[  308.009438] mtd_subpagetest: written up to eraseblock 0
[  308.208714] mtd_subpagetest: written up to eraseblock 256
[  308.408049] mtd_subpagetest: written up to eraseblock 512
[  308.607147] mtd_subpagetest: written up to eraseblock 768
[  308.806962] mtd_subpagetest: written up to eraseblock 1024
[  309.007791] mtd_subpagetest: written up to eraseblock 1280
[  309.208895] mtd_subpagetest: written up to eraseblock 1536
[  309.409194] mtd_subpagetest: written up to eraseblock 1792
[  309.609379] mtd_subpagetest: written up to eraseblock 2048
[  309.809121] mtd_subpagetest: written up to eraseblock 2304
[  310.008202] mtd_subpagetest: written up to eraseblock 2560
[  310.206817] mtd_subpagetest: written up to eraseblock 2816
[  310.406695] mtd_subpagetest: written up to eraseblock 3072
[  310.607464] mtd_subpagetest: written up to eraseblock 3328
[  310.807963] mtd_subpagetest: written up to eraseblock 3584
[  311.007515] mtd_subpagetest: written up to eraseblock 3840
[  311.102996] mtd_subpagetest: written 3960 eraseblocks
[  311.108079] mtd_subpagetest: verifying all eraseblocks
[  311.113623] mtd_subpagetest: verified up to eraseblock 0
[  311.219368] mtd_subpagetest: verified up to eraseblock 256
[  311.324900] mtd_subpagetest: verified up to eraseblock 512
[  311.430172] mtd_subpagetest: verified up to eraseblock 768
[  311.536136] mtd_subpagetest: verified up to eraseblock 1024
[  311.641565] mtd_subpagetest: verified up to eraseblock 1280
[  311.747521] mtd_subpagetest: verified up to eraseblock 1536
[  311.853136] mtd_subpagetest: verified up to eraseblock 1792
[  311.959090] mtd_subpagetest: verified up to eraseblock 2048
[  312.064725] mtd_subpagetest: verified up to eraseblock 2304
[  312.170469] mtd_subpagetest: verified up to eraseblock 2560
[  312.276184] mtd_subpagetest: verified up to eraseblock 2816
[  312.381647] mtd_subpagetest: verified up to eraseblock 3072
[  312.487339] mtd_subpagetest: verified up to eraseblock 3328
[  312.593213] mtd_subpagetest: verified up to eraseblock 3584
[  312.698887] mtd_subpagetest: verified up to eraseblock 3840
[  312.751091] mtd_subpagetest: verified 3960 eraseblocks
[  312.756265] mtd_subpagetest: erasing whole device
[  315.925559] mtd_subpagetest: erased 3960 eraseblocks
[  315.930553] mtd_subpagetest: verifying all eraseblocks for 0xff
[  315.947734] mtd_subpagetest: verified up to eraseblock 0
[  317.140658] mtd_subpagetest: error: read failed at 0xd60800
[  317.146278] mtd_subpagetest: error -74 occurred
[  317.150818] =================================================

# insmod mtd_subpagetest.ko dev=3
[ 2531.551029] 
[ 2531.552534] =================================================
[ 2531.558325] mtd_subpagetest: MTD device: 3
[ 2531.562529] mtd_subpagetest: MTD device size 519045120, eraseblock size 131072, page size 2048, subpage size 2048, count of eraseblocks 3960, pages per eraseblock 64, OOB size 64
[ 2531.578478] mtd_subpagetest: scanning for bad eraseblocks
[ 2531.584647] mtd_subpagetest: scanned 3960 eraseblocks, 0 are bad
[ 2531.590678] mtd_subpagetest: erasing whole device
[ 2533.558127] mtd_subpagetest: erased 3960 eraseblocks
[ 2533.563099] mtd_subpagetest: writing whole device
[ 2533.568626] mtd_subpagetest: written up to eraseblock 0
[ 2533.767485] mtd_subpagetest: written up to eraseblock 256
[ 2533.966877] mtd_subpagetest: written up to eraseblock 512
[ 2534.165419] mtd_subpagetest: written up to eraseblock 768
[ 2534.364624] mtd_subpagetest: written up to eraseblock 1024
[ 2534.564741] mtd_subpagetest: written up to eraseblock 1280
[ 2534.765559] mtd_subpagetest: written up to eraseblock 1536
[ 2534.965797] mtd_subpagetest: written up to eraseblock 1792
[ 2535.165736] mtd_subpagetest: written up to eraseblock 2048
[ 2535.365025] mtd_subpagetest: written up to eraseblock 2304
[ 2535.564295] mtd_subpagetest: written up to eraseblock 2560
[ 2535.763114] mtd_subpagetest: written up to eraseblock 2816
[ 2535.963109] mtd_subpagetest: written up to eraseblock 3072
[ 2536.163287] mtd_subpagetest: written up to eraseblock 3328
[ 2536.363245] mtd_subpagetest: written up to eraseblock 3584
[ 2536.562388] mtd_subpagetest: written up to eraseblock 3840
[ 2536.657760] mtd_subpagetest: written 3960 eraseblocks
[ 2536.662818] mtd_subpagetest: verifying all eraseblocks
[ 2536.668410] mtd_subpagetest: verified up to eraseblock 0
[ 2536.774134] mtd_subpagetest: verified up to eraseblock 256
[ 2536.879704] mtd_subpagetest: verified up to eraseblock 512
[ 2536.985855] mtd_subpagetest: verified up to eraseblock 768
[ 2537.091823] mtd_subpagetest: verified up to eraseblock 1024
[ 2537.197130] mtd_subpagetest: verified up to eraseblock 1280
[ 2537.302641] mtd_subpagetest: verified up to eraseblock 1536
[ 2537.408158] mtd_subpagetest: verified up to eraseblock 1792
[ 2537.514150] mtd_subpagetest: verified up to eraseblock 2048
[ 2537.619806] mtd_subpagetest: verified up to eraseblock 2304
[ 2537.725757] mtd_subpagetest: verified up to eraseblock 2560
[ 2537.831831] mtd_subpagetest: verified up to eraseblock 2816
[ 2537.937520] mtd_subpagetest: verified up to eraseblock 3072
[ 2538.043640] mtd_subpagetest: verified up to eraseblock 3328
[ 2538.149644] mtd_subpagetest: verified up to eraseblock 3584
[ 2538.255815] mtd_subpagetest: verified up to eraseblock 3840
[ 2538.307873] mtd_subpagetest: verified 3960 eraseblocks
[ 2538.313018] mtd_subpagetest: erasing whole device
[ 2541.541123] mtd_subpagetest: erased 3960 eraseblocks
[ 2541.546119] mtd_subpagetest: verifying all eraseblocks for 0xff
[ 2541.563155] mtd_subpagetest: verified up to eraseblock 0
[ 2544.439123] mtd_subpagetest: verified up to eraseblock 256
[ 2547.314905] mtd_subpagetest: verified up to eraseblock 512
[ 2550.189340] mtd_subpagetest: verified up to eraseblock 768
[ 2553.065276] mtd_subpagetest: verified up to eraseblock 1024
[ 2555.941052] mtd_subpagetest: verified up to eraseblock 1280
[ 2558.814191] mtd_subpagetest: verified up to eraseblock 1536
[ 2561.687721] mtd_subpagetest: verified up to eraseblock 1792
[ 2561.996470] mtd_subpagetest: error: read failed at 0xe380800
[ 2562.002147] mtd_subpagetest: error -74 occurred
[ 2562.006726] =================================================

>>
>> 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.

> 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
[    0.935871] gpmi-nand 112000.gpmi-nand: enable the asynchronous EDO mode 5
[    0.942772] Scanning device for bad blocks
[    1.287358] 4 cmdlinepart partitions found on MTD device gpmi-nand
[    1.293546] Creating 4 MTD partitions on "gpmi-nand":
[    1.298624] 0x000000000000-0x000001000000 : "uboot"
[    1.304349] 0x000001000000-0x000001080000 : "env1"
[    1.309910] 0x000001080000-0x000001100000 : "env2"
[    1.315426] 0x000001100000-0x000020000000 : "ubi"
[    1.321276] gpmi-nand 112000.gpmi-nand: driver registered.

...

# mtdinfo /dev/mtd0
mtd0
Name:                           uboot
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          128 (16777216 bytes, 16.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             true

Thanks,
Stefan

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

Hello Stefan,

On 5/10/2013 11:50 AM, Stefan Roese wrote:
> Hi Vikram,
>
> On 05/09/2013 02:30 PM, Vikram Narayanan wrote:
>>> 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

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

>>>
>>> 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.

> 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.

Thanks,
Vikram

Re: mtd_oobtest fails with GPMI-NAND

[Stefan Roese]

Hi Vikram,

On 05/12/2013 02:10 PM, Vikram Narayanan wrote:
>>>> 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
> 
> 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.

>>>> 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.
> 
>> 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.

Could you please post a link to this thread?

> 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?

Thanks,
Stefan

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年05月10日 14:20, Stefan Roese 写道:
>
>
>> 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.





> 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?

thanks
Huang Shijie

Re: mtd_oobtest fails with GPMI-NAND

[Stefan Roese]

On 05/13/2013 04:51 AM, Huang Shijie wrote:
>>> 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?

> 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?

BTW: I'm using Linux v3.9.1 for theses tests.

>> 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?

SLC. Why do you ask?

Thanks,
Stefan

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年05月13日 16:01, Stefan Roese 写道:
> On 05/13/2013 04:51 AM, Huang Shijie wrote:
>>>> 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?
>
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.

>> 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?
>
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


>
> 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.

thanks
Huang Shijie

Re: mtd_oobtest fails with GPMI-NAND

[Stefan Roese]

On 05/13/2013 11:01 AM, Huang Shijie wrote:
>> 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.

We're currently using the same values as in imx6q-sabresd.dts. With this
addition:

+	soc {
+		nfc: gpmi-nand@00112000 {
+			status = "enabled";
+		};
+	};

to enable NAND support. So the pin muxing from imx6q.dtsi (gpmi-nand-1)
is used (which is what is also connected physically). Again, I don't
think that pin-muxing is our problem here.

>>> 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

<snip>

>> 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.

Okay. Thanks for the explanation.

> 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

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)?

>> 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.

Thanks,
Stefan

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年05月13日 17:22, 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.

> 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.


thanks
Huang Shijie

Re: mtd_oobtest fails with GPMI-NAND

[Stefan Roese]

On 05/13/2013 11:34 AM, Huang Shijie wrote:
> 于 2013年05月13日 17:22, 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.

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

>> 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)

Thank for this update.

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

Sure. Thanks anyways for all your input.

Thanks,
Stefan

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

Hello Stefan,

On 5/12/2013 8:39 PM, Stefan Roese wrote:
>> 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.

Ok.

>> 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?

http://lists.denx.de/pipermail/u-boot/2012-December/142476.html

>> 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.

I'll test this as well with the latest u-boot.

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

I'm using "Toshiba, TC58NYG2S0FBAI4".

Regards,
Vikram

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

On 5/13/2013 1:31 PM, Stefan Roese wrote:
> On 05/13/2013 04:51 AM, Huang Shijie wrote:
>>>> 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.

If you are missing something very fundamental like the pinmux, I really 
wonder how the board would boot. So I'd say, you got your basic settings 
right.

> 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?

Not sure if this will fix your errors. There is a struct timing in the 
driver (Just give a grep). Update that structure with the timings given 
in your NAND datasheet.

HTH,
Vikram

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

Hello Huang,

On 5/13/2013 2:31 PM, Huang Shijie wrote:
>>
>> 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.

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

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年05月13日 18:02, Stefan Roese 写道:
> Do you have any specific parameters that I should use for this test?
i use:
bonnie++ -d X -u 0 -s 10 -r 5

thanks
Huang Shijie

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年05月13日 18:02, Stefan Roese 写道:
> Do you have any specific parameters that I should use for this test?
I use:
  bonnie++ -d tmp -u 0 -s 10 -r 5

thanks
Huang Shijie

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年05月14日 00:51, Vikram Narayanan 写道:
> Hello Huang,
>
> On 5/13/2013 2:31 PM, Huang Shijie wrote:
>>>
>>> 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.
>
> 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.
>
> 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.



thanks
Huang Shijie



> Regards,
> Vikram
>

Re: mtd_oobtest fails with GPMI-NAND

[Vikram Narayanan]

On 5/14/2013 7:53 AM, Huang Shijie wrote:
> 于 2013年05月14日 00:51, Vikram Narayanan 写道:
>> Hello Huang,
>>
>> On 5/13/2013 2:31 PM, Huang Shijie wrote:
>>>>
>>>> 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.
>>
>> 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.
>>
>> 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".

Yup. Will do it.

>
> 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.

Huang, What we are trying here is to get a stable working driver which 
can live upto the expectation of end users.

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.

Regards,
Vikram

Re: mtd_oobtest fails with GPMI-NAND

[Huang Shijie]

于 2013年05月14日 10:33, Vikram Narayanan 写道:
> So, don't think that we are pointing that the GPMI-NAND driver is 
> buggy. My only concern is _mtdtests_ are there to reveal
the mtd_tests may have bugs too. :)
So do not depend on the mtd_tests too much.
I don't think the mtd_tests can cover all the cases in the real world.


> 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. 
thanks. I know.


Huang Shijie