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

[Boris Brezillon <boris.brezillon@free-electrons.com>]

Hi Sean,

On Sun, 17 Dec 2017 12:56:01 +0100
Sean Nyekjaer <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel
> >>> I am very sorry for the delay but it took me some time to figure a
> >>> way to reproduce your situation until I started doing the exact
> >>> sequence I asked you to follow. It turns out there was a nasty error
> >>> in the parser so you could not observe the last blocks of your chip
> >>> because I messed up with high addresses.  
> >> Fantastic always nice to be able to reproduce the issue. Glad to be
> >> able to help :-)
> >>  
> >>> I updated the Github branch [1], can you rebase on top of it? I think
> >>> this time we should get something :)  
> >> I just did a quick boot with the new commits, and the kernel is able
> >> to find the bbt table :-)  
> > Good ! :-)
> >
> > So with nand-ecc-mode = "none" + on-flash-bbt, there is no more issue,
> > right?  
> No more issue with reading the bbt :-)
> >  
> >> 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)

If we end up with different ECC bytes than what u-boot produces then
there's a mismatch somewhere.

Regards,

Boris