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

[Miquel RAYNAL <miquel.raynal@free-electrons.com>]

On Mon, 11 Dec 2017 15:02:00 +0100
Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:

> On Mon, 11 Dec 2017 14:22:18 +0100
> Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
> 
> > Hi Miquel,  
> > >>> Actually, if you look carefully to the trace behind, you are not
> > >>> using the same bad block table with the bootloader ("Bad block
> > >>> table not found for chip 0") so the core then reads the OOB area
> > >>> of every first page for each block and looks at the first OOB
> > >>> bytes for the bad block markers. If there was data there, the
> > >>> block will be declared as bad.    
> > >> With the new NFC driver, is the bad block table located
> > >> elsewhere? I have not done any changes to my bootloader when i
> > >> did the switch to the new driver,
> > >> so i guess it should work as before.    
> > >>> Can you please check that by using the configuration that
> > >>> actually boots and use nanddump in raw mode with the OOB area
> > >>> (options -n and -o)
> > >>> to show us the content of the first page of any block of the
> > >>> last NAND MTD device?
> > >>>
> > >>>    
> > >> Will do
> > >>    
> > > Dumped from uboot:    
> > > => nand dump.oob 0xffc0000    
> > > Page 0ffc0000 dump:
> > > OOB:
> > >         ff ff ff ff ff ff ff ff
> > >         31 74 62 42 56 4d 01 ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff    
> > > => nand dump.oob 0xffe0000    
> > > Page 0ffe0000 dump:
> > > OOB:
> > >         ff ff ff ff ff ff ff ff
> > >         4d 56 42 62 74 30 01 ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >
> > > I have tried to dump some random pages, and they all contain
> > > 0xFF's. I'll try to trace what the NFC driver is reading from the
> > > OOBs. 
> > What function is called in the marvel_nand.c driver here [1].
> >  From my tracing i can see:
> > mtd->_read_oob(mtd, from, ops);  
> > ->    marvell_nfc_hw_ecc_bch_read_oob
> > ->        marvell_nfc_hw_ecc_bch_read_page    
> > marvell_nfc_hw_ecc_bch_read_page is returning 0 (bitflips)
> > But the mtd->_read_oob is returning -74.  
> 
> This means the hardware detected an ECC error (and the page was not
> empty).
> 
> > 
> > Some of the tracing:
> > [    2.947220] Scanning device for bad blocks
> > [    2.951334] mtd_read_oob
> > [    2.953874] marvell_nfc_hw_ecc_bch_read_oob
> > [    2.958393] marvell_nfc_hw_ecc_bch_read_page: max_bitflips: 0,
> > page 0x0 [    2.965034] marvell_nfc_hw_ecc_bch_read_oob: returns 0
> > [    2.970194] mtd_read_oob: ret_code -74
> > [    2.983669] Bad eraseblock 0 at 0x000000000000  
> 
> This behavior is "normal", it is because the number of failure has
> been incremented (probably by marvell_nfc_hw_ecc_correct()).
> 
> 
> Can you hack the code right before this line [1] and add:
> 1/ A dump of both the data buffer and the oob buffer (entirely)
> 2/ Add a memset(mtd->oob_poi, 0xff, mtd->oobsize) conditionally until
> the probe is finished (you may want to add a global boolean value that
> changes its state after the nand_scan_tail() call).

Instead of hacking this way, to boot until you get a prompt, you may
add this property to the nand controller node:

nand-ecc-mode = "none";

Then please use nanddump over a programmed page, including the OOB area.


> 
> Then please do a raw dump with nanddump from Linux.
> 
> 
> Also, please try booting without the nand-keep-config property.
> 
> Thank you,
> Miquèl
> 
> [1]
> https://github.com/miquelraynal/linux/blob/marvell/nand-next/nfc-rework/drivers/mtd/nand/marvell_nand.c#L1351



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com