[BUG] pxa3xx: wait time out when scanning for bb
Sean Nyekjær
sean.nyekjaer at prevas.dk
Tue Dec 12 02:55:22 PST 2017
Hi Miquel
> 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:
&nand_controller {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&nand_pins>, <&nand_rb>;
nand at 0 {
reg = <0>;
label = "pxa3xx_nand-0";
marvell,rb = <0>;
nand-ecc-mode = "none";
nand-on-flash-bbt;
};
};
>
> 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.
Yes uboot is recreating the bbt and after a new reset it recognise the
new bbt.
>
> 3/ Boot Linux with ECC == none
> 4/ Dump the first page of the 4 last blocks:
>
> nanddump -nop -l 0x800 -s <adddr> /dev/mtd1
See tracing below
>
> 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).
>
U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)
SoC: MV88F6810-A0 at 1066 MHz
DRAM: 1 GiB (533 MHz, 16-bit, ECC not enabled)
WDT: Enabling Armada 385 watchdog.
NAND: PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
256 MiB
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
Model: Triax dvb-tc output
Board: Triax dvb-tc output
Net:
Warning: ethernet at 30000 (eth0) using random MAC address - 26:d3:56:98:ca:b4
eth0: ethernet at 30000
=> nand scrub 0xFF80000 0x80000
NAND scrub: device 0 offset 0xff80000, size 0x80000
Warning: scrub option will erase all factory set bad blocks!
There is no reliable way to recover them.
Use this command only for testing purposes if you
are sure of what you are doing!
Really scrub this NAND flash? <y/N>
y
Erasing at 0xffe0000 -- 100% complete.
OK
=> boot
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.15.0-rc1-00094-g1791eb8f2475-dirty
(skn at skn) (gcc version 7.2.0 (Arch Repository)) #30 SMP PREEMPT Tue Dec
12 09:28:30 CET 2017
...
[ 2.692801] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[ 2.699176] nand: Micron MT29F2G08ABAEAH4
[ 2.703232] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048,
OOB size: 64
[ 2.710928] nand: NAND_ECC_NONE selected by board driver. This is not
recommended!
[ 2.718523] nand: WARNING: pxa3xx_nand-0: the ECC used on your system
is too weak compared to the one required by the NAND chip
[ 2.731429] Bad block table not found for chip 0
[ 2.737384] Bad block table not found for chip 0
[ 2.742024] Scanning device for bad blocks
[ 2.891818] Bad block table written to 0x00000ffe0000, version 0x01
[ 2.898837] Bad block table written to 0x00000ffc0000, version 0x01
[ 2.905152] 2 cmdlinepart partitions found on MTD device pxa3xx_nand-0
[ 2.911708] Creating 2 MTD partitions on "pxa3xx_nand-0":
[ 2.917130] 0x000000000000-0x000000100000 : "uboot"
[ 2.922512] 0x000000100000-0x000010000000 : "ubi0"
...
output-module login: root
Password:
root at output-module:~#
root at output-module:~# nanddump -nop -l 0x800 -s 0xFF80000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0ff80000 and ending at 0x0ff80800...
root at output-module:~# nanddump -nop -l 0x800 -s 0xFFA0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0ffa0000 and ending at 0x0ffa0800...
root at output-module:~# nanddump -nop -l 0x800 -s 0xFFC0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0ffc0000 and ending at 0x0ffc0800...
root at output-module:~# nanddump -nop -l 0x800 -s 0xFFE0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0ffe0000 and ending at 0x0ffe0800...
root at output-module:~# reboot
...
U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)
SoC: MV88F6810-A0 at 1066 MHz
DRAM: 1 GiB (533 MHz, 16-bit, ECC not enabled)
WDT: Enabling Armada 385 watchdog.
NAND: PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
256 MiB
Bad block table not found for chip 0
Bad block table not found for chip 0
Scanning device for bad blocks
Bad block table written to 0x00000ffe0000, version 0x01
Bad block table written to 0x00000ffc0000, version 0x01
If I reboot uboot is unable recognise the bbt, but recreates it. But the
kernel is scanning on every boot.
Am I doing anything wrong in the nanddump command?
/Sean
More information about the linux-mtd
mailing list