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

[Miquel RAYNAL <miquel.raynal@free-electrons.com>]

On Tue, 12 Dec 2017 12:28:46 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> On 2017-12-12 12:08, Miquel RAYNAL wrote:
> > On Tue, 12 Dec 2017 11:55:22 +0100
> > Sean Nyekjær <sean.nyekjaer@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@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@30000 (eth0) using random MAC address -
> >> 26:d3:56:98:ca:b4 eth0: ethernet@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@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@output-module:~#
> >> root@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@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@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@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@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@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@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@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@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...
> 

Failure is on me for this one: Linux marks the block containing the BBT
as bad to avoid user accesses on it, please use --bb=dumpbad in the
nanddump command.

Once you will have the trace, please do the same again without
on-flash-bbt, this way we can compare both U-Boot and Linux layouts and
find what is wrong.

Thank you,
Miquèl