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

[Miquel RAYNAL]

Hi Sean,

> >>>> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC
> >>>> step size 2048  
> >>> In theory, Marvell NAND flash controller does support 16-bit
> >>> strength per 512 bytes over 2048 bytes pages. However, this
> >>> controller driver (pxa3xx_nand) does not. See [1] for the
> >>> supported configurations.
> >>>
> >>> The ECC strength shown here is probably the best to use with this
> >>> type of NAND device but I suggest you try with 4b/512B by using
> >>> these two properties like in [2]:
> >>>
> >>>           nand-ecc-strength = <4>;
> >>>           nand-ecc-step-size = <512>;  
> >> My dts iscreated with great inspiration from the
> >> armada-385-dp-ap.dts
> >>
> >> &nand {
> >>           status = "okay";
> >>           pinctrl-names = "default";
> >>           pinctrl-0 = <&nand_pins>, <&nand_rb>;
> >>           num-cs = <1>;
> >>           nand-on-flash-bbt;
> >>           nand-ecc-strength = <4>;
> >>           nand-ecc-step-size = <512>;
> >> };  
> > Just for testing purpose, could you also put the keep-config and
> > enable-arbiter properties ?  
> Yes, but i don't think the arbiter have any affect in the nand
> controller. Bit 12 in NDCR register is marked reserved in the
> datasheet.

Be careful with that. I recently enabled 64-bit platforms featuring
this NAND controller. After hours of digging because it was not
working, I set this bit by adding this property like in any other device
tree and it worked. I am not telling that it will solve your issue,
mostly not, but this is something you should be careful about.

> >  
> >> Why does the driver not set these values?  
> > Perhaps you can add traces there [3] and see where it fails?
> >
> > [3]
> > http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1721  
> See here [4] the driver is selecting 16 bit strength when we are 
> specifying 4 bits in the dts.

That is right.

> 
> [4]
> http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1595
> >> (I only see the timeouts if I remove the nand-on-flash-bbt)  
> > The nand-on-flash-bbt will read some of the last pages in you NAND
> > chip where a bad block table is supposed to be and derive from that
> > whether a block is bad or not. So this does only one read. I guess
> > you should have at least one timeout there?  
> Maybe, but the flash is fine we are running a rootfs in the NAND chip.

So you can safely use the content of the NAND chip? Without any timeout
neither with reads nor writes? Can you try the mtd-utils from [5]:
nanddump/nandwrite or nandpagetest?

Also, can you isolate the line that produces the timeouts?

[5] http://www.linux-mtd.infradead.org/

> 
> > Without this property, the NAND core will read every bad block
> > marker (a few bytes at the beginning of the OOB area) and detect if
> > the block was marked bad. Each access seems to produce a timeout,
> > hence the big amount of errors you see.  
> in the old thread I linked, they had the same issue and like me only 
> when scanning for
> bad blocks.
> 
> /Sean