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

[Miquel RAYNAL]

Hi Sean,

On Mon, 18 Dec 2017 07:23:04 +0100
Sean Nyekjær <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?  
> > 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

This is really helpful. It shows the driver is the problem. I don't
know yet why it reads the NAND status instead of the actual data at
this moment. I am looking into it.

I added one fixup in my github branch that could possibly help, could
you give it a try while I am going deeper in my research?

Thank you,
Miquèl