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

[Miquel RAYNAL]

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).

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

Thank you,
Miquèl