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

[Boris Brezillon]

On Sun, 17 Dec 2017 23:15:42 +0100
Sean Nyekjær <sean.nyekjaer at prevas.dk> wrote:

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

Yes, that would be a good start.