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

["Sean Nyekjær" <sean.nyekjaer@prevas.dk>]

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

/Sean