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

[Sean Nyekjaer]

Hi Boris and 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.

/Sean