ubifs error with marvell_nand on Armada-98DX4251 (was Re: [PATCH] mtd: rawnand: marvell: fix command xtype in BCH write hook)

[Boris Brezillon]

Hi Chris,

On Mon, 7 May 2018 03:48:42 +0000
Chris Packham <Chris.Packham at alliedtelesis.co.nz> wrote:

> Hi Miquel,
> 
> On 04/05/18 19:10, Miquel Raynal wrote:
> > Hi Chris,
> > 
> > On Fri, 4 May 2018 00:06:48 +0000, Chris Packham
> > <Chris.Packham at alliedtelesis.co.nz> wrote:  
> >>
> >> I do have one platform that passes the initial detection but starts to
> >> report ubifs errors when mounted.
> >>
> >> Armada-98DX4251 Micron MT29F8G08ABACAWP 1024 MiB 256 KiB 4096 224
> >>
> >> This is probably unrelated to this particular fix. It may be as simple
> >> as something not catering for the Armada-98DX4251 SoC or a genuine
> >> difference between Armada-98DX4251 and Armada-385. 4.16.4 with
> >> pxa3xx_nand works with this combination.  
> 
> I did spot a few problems in the pinctrl driver for this platform, but 
> nothing that was stopping things from working (the bootloader set the 
> MPP functions correctly). I've sent some patches for that.
> 
> > Can you please share more details: the device tree (at least the NAND
> > node), the strength requested, the boot log, the errors?  
> 
> Here's the relevant part of the device tree
> 
> 	nand at d0000 {
> 		compatible = "marvell,armada370-nand";
> 		reg = <0xd0000 0x54>;
> 		#address-cells = <0x1>;
> 		#size-cells = <0x1>;
> 		interrupts = <0x71>;
> 		clocks = <0xc 0x0>;
> 		status = "okay";
> 		num-cs = <0x1>;
> 		marvell,nand-enable-arbiter;
> 		nand-on-flash-bbt;
> 	};
> 
> 	...
> 
> 	dfx-server at ac000000 {
> 		compatible = "marvell,dfx-server", "simple-bus";
> 		#address-cells = <0x1>;
> 		#size-cells = <0x1>;
> 		ranges = <0x0 0x8000000 0x0 0x100000>;
> 		reg = <0x8000000 0x0 0x100000>;
> 		phandle = <0xe>;
> 
> 		corediv-clock at f8268 {
> 			compatible = "marvell,mv98dx3236-corediv-clock";
> 			reg = <0xf8268 0xc>;
> 			#clock-cells = <0x1>;
> 			clocks = <0x9>;
> 			clock-output-names = "nand";
> 			phandle = <0xc>;
> 		};
> 	};
> 
> Boot output
> 
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xd3
> nand: Micron MT29F8G08ABACAWP
> nand: 1024 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 224
> Bad block table found at page 261952, version 0x01
> Bad block table found at page 261888, version 0x01
> nand_read_bbt: bad block at 0x00003ff80000
> nand_read_bbt: bad block at 0x00003ffc0000
> 
> Error at mount time
> 
> Re-mounting file system...
> UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 1096
> UBIFS error (ubi0:0 pid 1093): check_lpt_type.constprop.6: invalid type 
> (0) in LPT node type 2
> CPU: 0 PID: 1093 Comm: mount Not tainted 4.17.0-rc2-at1+ #1
> Hardware name: Marvell Armada 370/XP (Device Tree)
> [<80110f40>] (unwind_backtrace) from [<8010c350>] (show_stack+0x10/0x14)
> [<8010c350>] (show_stack) from [<805c11b4>] (dump_stack+0x88/0x9c)
> [<805c11b4>] (dump_stack) from [<802dde14>] 
> (check_lpt_type.constprop.6+0x48/0x50)
> [<802dde14>] (check_lpt_type.constprop.6) from [<802dfe70>] 
> (ubifs_lpt_init+0x2cc/0x4d8)
> [<802dfe70>] (ubifs_lpt_init) from [<802c9810>] (ubifs_mount+0x106c/0x1594)
> [<802c9810>] (ubifs_mount) from [<801ef1dc>] (mount_fs+0x14/0xa4)
> [<801ef1dc>] (mount_fs) from [<8020a63c>] (vfs_kern_mount+0x4c/0xf4)
> [<8020a63c>] (vfs_kern_mount) from [<8020d7f0>] (do_mount+0x184/0xb98)
> [<8020d7f0>] (do_mount) from [<8020e584>] (ksys_mount+0x8c/0xbc)
> [<8020e584>] (ksys_mount) from [<80101000>] (ret_fast_syscall+0x0/0x54)
> Exception stack(0xbda63fa8 to 0xbda63ff0)
> 3fa0:                   00000000 00000000 7ea24f4e 7ea24f60 7ea24f48 
> 00008010
> 3fc0: 00000000 00000000 7ea24f48 00000015 7ea24f4e 00008010 00000000 
> 000a5f44
> 3fe0: 76e6b1b0 7ea24af0 00046020 76e6b1c0
> UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops
> mount: mounting ubi0:user on /flash failed: Invalid argument
> 

Can you paste the full boot logs?

> 
> > 
> > Are you sure Linux ECC configuration is aligned with the bootloader's?  
> 
> In this case the bootloader doesn't have any NAND support enabled since 
> this board is always network booting.
> 
> It is likely that an older kernel has set this up with ecc-strength=4. 
> Does flash_erase destroy the ecc data as well or is there some other 
> mtd-util to do this from userland?

There's no metadata describing the ECC setup to use. flash_erase should
place the NAND is a clean state.

> 
> That got me thinking. I ran with the new driver but the following added 
> to the dts
> 
> +       nand-ecc-strength = <4>;
> +       nand-ecc-step-size = <512>;
> 
> After an erase/re-init things were working.
> 
> But then if I have nothing (auto-select) or nand-ecc-strength = <8> 
> (which would be "correct" for this chip) in the dts I get the errors above.

Maybe a problem with the 16bits/1024bytes layout, but what's weird is
that the driver does not report ECC errors.

Regards,

Boris