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