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