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

Miquel RAYNAL miquel.raynal at free-electrons.com
Tue Dec 12 02:12:27 PST 2017


Hello Sean,

On Tue, 12 Dec 2017 09:56:19 +0100
Sean Nyekjær <sean.nyekjaer at prevas.dk> wrote:

> Hi Miquel,
> >> Boot log:
> >> [    2.692856] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> >> 0xda [    2.699231] nand: Micron MT29F2G08ABAEAH4
> >> [    2.703286] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> >> 2048, OOB size: 64
> >> [    2.711135] nand: NAND_ECC_NONE selected by board driver. This
> >> is not recommended!
> >> [    2.718730] nand: WARNING: pxa3xx_nand-0: the ECC used on your
> >> system is too weak compared to the one required by the NAND chip
> >> [    2.732632] Bad block table not found for chip 0
> >> [    2.739609] Bad block table not found for chip 0
> >> [    2.744250] Scanning device for bad blocks
> >> [    2.985502] Bad block table written to 0x00000ffe0000, version
> >> 0x01 [    2.992760] Bad block table written to 0x00000ffc0000,
> >> version 0x01
> >>
> >> Nanddump:
> >> root at output-module:~# nanddump -oa /dev/mtd1
> >> ECC failed: 0
> >> ECC corrected: 0
> >> Number of bad blocks: 0
> >> Number of bbt blocks: 0
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x00000000 and ending at 0x0ff00000...
> >> UBIXS...
> >>
> >> I guess it's safe to say something is not right with ECC enabled.  
> >>>> Then please do a raw dump with nanddump from Linux.  
> > Thanks for testing this, but I _really_ need the entire output of
> >
> >          nanddump -o -n -p -l 0x800 /dev/mtd1  
> root at output-module:~# nanddump -o -n -p -l 0x800 /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x00000000 and ending at 0x00000800...

[...]

>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: c1 eb aa 03 d3 5c d8 ae fa fd ba 34 2a a5 20 38
>    OOB Data: fd 0b 22 59 c1 8c 3c a5 a4 62 df f2 d4 7e ff ff

This is exactly what the driver expects, an empty spare area (free OOB)
of 32B, 30B of ECC and 2B lost.

Are you sure your U-Boot does actually use the BBT?

The last two blocks (supposedly written by U-Boot) are usually declared
bad by Linux when it does not find the BBT. This is not the case, like
if the last blocks were empty.

Could you try this, still with "ecc-none" and without the
"nand-keep-config" property:

1/ From U-Boot, scrub the last 4 blocks. As your NAND is 256MiB
wide with 128kiB blocks, this should do the trick:

        nand scrub 0xFF80000 0x80000

2/ At this point, U-Boot should tell you it cannot find a bad block
table, a second later it will tell you that it created it twice at the
end of the NAND chip.

3/ Boot Linux with ECC == none
4/ Dump the first page of the 4 last blocks:

        nanddump -nop -l 0x800 -s <adddr> /dev/mtd1

Supposedly that /dev/mtd1 is the _last_ MTD partition of your NAND
device and <addr> being sequentially:

        0xFF80000
        0xFFA0000
        0xFFC0000
        0xFFE0000

Please copy/paste the overall trace without any cuts (including U-Boot
traces, literally everything).

Thanks for your effort,
Miquèl




More information about the linux-mtd mailing list