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

[Sean Nyekjær]

On 17 December 2017 23:00:32 CET, Boris Brezillon <boris.brezillon at free-electrons.com> wrote:
>On Sun, 17 Dec 2017 22:47:26 +0100
>Sean Nyekjaer <sean.nyekjaer at prevas.dk> wrote:
>
>> 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?

So I do a trace, without the -n option, with ecc enabled and NAND_SKIP_BBTSCAN set?
Is that what you need?

/Sean