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

Tue Dec 12 03:28:46 PST 2017


On 2017-12-12 12:08, Miquel RAYNAL wrote:
> On Tue, 12 Dec 2017 11:55:22 +0100
> Sean Nyekjær <sean.nyekjaer at prevas.dk> wrote:
>
>> 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?
> I did not realize your NAND had 2 partitions (I though /dev/mtd0 was
> something else).
Sorry i should have said that :-)
>
> In Linux, the offset your give to nanddump is from the beginning of the
> MTD device, not the NAND device. Because /dev/mtd1 starts at 0x100000
> (8 blocks are used for U-Boot), you have to substract 0x100000 from the
> offsets I gave you otherwise you read beyond the device (ie. nothing).
>
> Please try again with:
>
>          0xFE80000
>          0xFEA0000
>          0xFEC0000
>          0xFEE0000
root at wandboard:~# nanddump -nop -l 0x800 -s 0xFE80000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fe80000 and ending at 0x0fe80800...
root at wandboard:~# nanddump -nop -l 0x800 -s 0xFEA0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fea0000 and ending at 0x0fea0800...
root at wandboard:~# nanddump -nop -l 0x800 -s 0xFEC0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
root at wandboard:~# nanddump -nop -l 0x800 -s 0xFEE0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fee0000 and ending at 0x0fee0800...

/Sean