[SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb

[Sean Nyekjær]

Hi Miquel
>>>>>>>>>> I also tried booting with ECC enabled and with that enabled
>>>>>>>>>> the driver is unable to read the bbt and marked all blocks
>>>>>>>>>> bad.
>>>>>>>>> And if I understand correctly, if you remove nand-ecc-mode =
>>>>> "none" (or
>>>>>>>>> set it to "hw"), the kernel fails to find the BBT, that is
>>>>>>>>> right?
>>>>>       
>>>>>>>> Yes.
>>>>>>>>> As I was not expecting such a quick answer, I did push
>>>>>>>>> another
>>>>> patch
>>>>>>>>> after sending my email that fixes an issue in mtdcore.c,
>>>>>>>>> please
>>>>> check
>>>>>>>>> you have it (there are a few "fixup!" patches, and on top of
>>>>>>>>> them
>>>>> you
>>>>>>>>> must find one which is a well-formatted patch about
>>>>>>>>> mtd_check_oob_ops()).
>>>>>>>> I have rebased on top of 9aee88a618f8 mtd: Fix
>>>>>>>> mtd_check_oob_ops()
>>>>>       
>>>>>>>>> I learned that today: to get a prompt while all blocks are
>>>>>>>>> bad,
>>>>> you can
>>>>>>>>> add:
>>>>>>>>>
>>>>>>>>>         chip->options |= NAND_SKIP_BBTSCAN;
>>>>>>>>>
>>>>>>>>> Before nand_scan_tail().
>>>>>>>>>
>>>>>>>>> If you can reach a prompt with the failing configuration and
>>>>>>>>> when
>>>>> you
>>>>>>>>> will have the time, I will welcome a dump of the same area
>>>>>>>>> as
>>>>> before
>>>>>>>>> so we will try to understand what is wrong now ! :)
>>>>>>>> Nice one, a lot easier to read whats happens
>>>>>>>>
>>>>>>>> nanddump of BBT without ECC enabled:
>>>>>>>> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
>>>>>>>>
>>>>>>>> nanddump of BBT with ECC enabled:
>>>>>>>> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
>>>>>>>> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
>>>>>>>> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
>>>>>>>>
>>>>>>>> Please let me know what traces you need to fix the ECC :-)
>>>>>>> The dumps look good (at least, the BBT pattern is correct, we
>>>>>>> have
>>>>> the
>>>>>>> number of ECC bytes we expect and they are where we expect
>>>>>>> them).
>>>>>>>
>>>>>>> My gut feeling is that something is wrong with ECC (or
>>>>>>> something
>>>>> related
>>>>>>> to ECC) in u-boot.
>>>>>>>
>>>>>>> Can you try to let Linux create the BBT on its own and dump
>>>>>>> the
>>>>> last
>>>>>>> block as you did previously?
>>>>>>>
>>>>>>> So, to sum-up
>>>>>>>
>>>>>>> 1/ put the following in your DT
>>>>>>>
>>>>>>> 	nand-ecc-mode = "hw";
>>>>>>> 	nand-on-flash-bbt;
>>>>>>>
>>>>>>> 2/ scrub the NAND from u-boot and make sure you don't reboot
>>>>>>> after
>>>>> that,
>>>>>>>       so that u-boot can't recreate its own BBT.
>>>>>>>
>>>>>>> 3/ Let Linux boot and dump the pages (in raw mode) where BBTs
>>>>> created by
>>>>>>> Linux are supposed to be (should be the same addresses as
>>>>>>> before)
>>>>>> Trace with nand scrub in uboot and ecc enabled:
>>>>>> https://gist.github.com/anonymous/3ce389b9276fddbd46f59c89b99ee4ff
>>>>>>
>>>>>> Same as above with "chip->options |= NAND_SKIP_BBTSCAN;" in the
>>>>> marvell
>>>>>> nand driver
>>>>>> https://gist.github.com/anonymous/3aed159b5a5ee22f27403fe79ba97400
>>>>>>
>>>>>> If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt
>>>>>> pages) they contain
>>>>>> only 0xFF's as the kernel does not write to the blocks.
>>>>>>
>>>>>> To me it seem a little bit difficult to say why the new marvell
>>>>>> nand
>>>>> driver
>>>>>> (with ecc enabled) thinks all the freshly scrubbed blocks are
>>>>>> bad.
>>>>> Ok, now I really need the dump without the -n option. It seems
>>>>> that dumping in non-raw mode does not return the expected value.
>>>>>      
>>>> How can I get the driver to write a bbt when it have marked all the
>>>> blocks bad?
>>> I think the easier way is to let U-Boot do it. So I guess you'll
>>> have to reboot the board after scrubbing.
>>>   
>>>> So I do a trace, without the -n option, with ecc enabled and
>>>> NAND_SKIP_BBTSCAN set? Is that what you need?
>>> It will be helpful, yes!
>>>   
>> https://gist.github.com/anonymous/08049fbb46bf6df2d24a07aab8783833
> This is really helpful. It shows the driver is the problem. I don't
> know yet why it reads the NAND status instead of the actual data at
> this moment. I am looking into it.
>
> I added one fixup in my github branch that could possibly help, could
> you give it a try while I am going deeper in my research?
>
Rebased on top of 8cec3f8653e0fe914d831f05cf91ab9face5c1a5
The "print_req_error: I/O error, dev mtdblock1, sector 0" is gone

And what you did have apperently fixed the issue with ecc.
The driver is reading the bbt uboot have written :-)

https://gist.github.com/anonymous/4476819c081896e5e265b3282db52e46

/Sean