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

Chris Packham Chris.Packham at alliedtelesis.co.nz
Sun May 6 20:48:42 PDT 2018


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


> 
> 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?

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.

> 
> Thanks,
> Miquèl
> 
> 




More information about the linux-mtd mailing list