[BUG] pxa3xx: wait time out when scanning for bb
Boris Brezillon
boris.brezillon at free-electrons.com
Mon Dec 11 06:49:12 PST 2017
On Mon, 11 Dec 2017 15:09:29 +0100
Miquel RAYNAL <miquel.raynal at free-electrons.com> wrote:
> On Mon, 11 Dec 2017 15:02:00 +0100
> Miquel RAYNAL <miquel.raynal at free-electrons.com> wrote:
>
> > 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).
>
> Instead of hacking this way, to boot until you get a prompt, you may
> add this property to the nand controller node:
I guess you mean the nand node, not the nand-controller node?
>
> nand-ecc-mode = "none";
>
> Then please use nanddump over a programmed page, including the OOB area.
>
More information about the linux-mtd
mailing list