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

[Miquel RAYNAL]

Hi Sean,

> >>> I insist on the fact that this is something I could have spotted
> >>> earlier
> >>> if you had blindlessly copy/pasted the *entire* trace, I don't
> >>> mind if it is big, it can be really interesting for others to get
> >>> the full trace.
> >>>
> >>> This time I only need the trace without the "on-flash-bbt"
> >>> property.  
> >  
> I have double checked the result without kernel bbt and the bbt
> written from uboot, the marvell_nand driver is reading 0xFF's...

That is weird. I am gonna check with my setup if the sequence I ask you
actually works.

> 
> Tracing:
> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)

"-dirty"? Is the 17.11 U-Boot clean around the NAND area? What did you
change from mainline code?


> 
> 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 -
> d6:4c:37:5e:b6:28 eth0: ethernet at 30000
> => nand erase.part ubi0; nand scrub 0xFF80000 0x80000; nand bad  
> 
> NAND erase.part: device 0 offset 0x100000, size 0xff00000
> Skipping bad block at 0x0ff00000
> Skipping bad block at 0x0ff20000
> Skipping bad block at 0x0ff40000
> Skipping bad block at 0x0ff60000
> Skipping bad block at 0x0ff80000
> Skipping bad block at  0x0ffa0000
> Skipping bad block at  0x0ffc0000
> Skipping bad block at  0x0ffe0000
> 
> OK
> 
> 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
> 
> Device 0 bad blocks:
> 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
>    0ff00000
>    0ff20000
>    0ff40000
>    0ff60000
>    0ff80000
>    0ffa0000
>    0ffc0000
>    0ffe0000
> => boot  
> [ ... ]

Please, stop doing this, we _really_ _really_ _really_ want the *full*
log, no matter if you think this part is irrelevant.

If for you the trace is too big, please use
http://code.bulix.org/ or https://pastebin.com/

> [    2.699996] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> 0xda [    2.706413] nand: Micron MT29F2G08ABAEAH4
> [    2.710461] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64
> [    2.718122] nand: NAND_ECC_NONE selected by board driver. This is
> not recommended!
> [    2.725750] nand: WARNING: pxa3xx_nand-0: the ECC used on your
> system is too weak compared to the one required by the NAND chip
> [    2.737295] Scanning device for bad blocks
> [    2.886451] 2 cmdlinepart partitions found on MTD device
> pxa3xx_nand-0 [    2.893008] Creating 2 MTD partitions on
> "pxa3xx_nand-0": [    2.898429] 0x000000000000-0x000000100000 :
> "uboot" [    2.903806] 0x000000100000-0x000010000000 : "ubi0"
> [ ... ]
> root at output-module:~# nanddump -nop -l 0x800 --bb=dumpbad -s
> 0xFE80000 /dev/mtd1

While I am investigating on my side, could you please:
- dump the same pages as before from U-Boot, with the OOB area of
  course (do not substract the 0x100000 offset from U-Boot), I want
  to see if there is actually something in these pages.
- dump the entire MTD1 device from Linux (same configuration as before)
  and grep for the string "MVBbt".

Thanks,
Miquèl