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

[Boris Brezillon]

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.

Thanks,

Boris