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

[Miquel RAYNAL]

On Mon, 11 Dec 2017 14:22:18 +0100
Sean Nyekjær <sean.nyekjaer at 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).

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