All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Francesco Dolcini <francesco@dolcini.it>
Cc: Shawn Guo <shawnguo@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	NXP Linux Team <linux-imx@nxp.com>,
	devicetree@vger.kernel.org, stable@vger.kernel.org,
	Sasha Levin <sashal@kernel.org>
Subject: Re: Boot failure regression on 6.0.10 stable kernel on iMX7
Date: Wed, 30 Nov 2022 23:59:04 +0100	[thread overview]
Message-ID: <fef2598e-e5fc-c4fc-0530-2d3c380ed39a@denx.de> (raw)
In-Reply-To: <Y4fCZmjDMtMMyu+E@francesco-nb.int.toradex.com>

On 11/30/22 21:51, Francesco Dolcini wrote:
> On Wed, Nov 30, 2022 at 03:41:13PM +0100, Marek Vasut wrote:
>> On 11/30/22 14:52, Francesco Dolcini wrote:
>>> [    0.000000] Booting Linux on physical CPU 0x0
>>> [    0.000000] Linux version 6.0.10 (francesco@francesco-nb) (arm-linux-gnueabihf-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.
>>> 4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #36 SMP Wed Nov 30 14:07:15 CET 2022
>>> ...
>>> [    4.407499] gpmi-nand: error parsing ofpart partition /soc/nand-controller@33002000/partition@0 (/soc/nand-controller
>>> @33002000)
>>> [    4.438401] gpmi-nand 33002000.nand-controller: driver registered.
>>> ...
>>> [    5.933906] VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0): error -19
>>> [    5.946504] Please append a correct "root=" boot option; here are the available partitions:
>>> ...
>>>
>>> Any idea? I'm not familiar with the gpmi-nand driver and I would just revert it, but
>>> maybe you have a better idea.
>>
>> Can you share the relevant snippet of your nand controller DT node ?
> 
> We just have
> 
> from imx7-colibri.dtsi,
> 
>    &gpmi {
>    	fsl,use-minimum-ecc;
>    	nand-ecc-mode = "hw";
>    	nand-on-flash-bbt;
>    	pinctrl-names = "default";
>    	pinctrl-0 = <&pinctrl_gpmi_nand>;
>    };
> 
> OF partition are created by U-Boot from
>    mtdparts=mtdparts=gpmi-nand:512k(mx7-bcb),1536k(u-boot1)ro,1536k(u-boot2)ro,512k(u-boot-env),-(ubi)
> env variables calling fdt_fixup_mtdparts from colibri_imx7.c
> 
> Everything is available in the upstream Linux/U-Boot git, no downstream
> repo of any sort.
> 
>> Probably up to first partition is enough. I suspect you need to fill in the
>> correct address-cells/size-cells there, which might be currently missing in
>> your DT and worked by chance.
> 
> This is generated by U-Boot, I would need to dump what he did generate
> from the standard fdt_fixup_mtdparts(). I will try to do it tomorrow
> unless what I wrote here is already enough to understand what's going
> on.

Oh drat ... I see. It's the u-boot fdt_node_set_part_info() which checks 
the current NAND controller #size-cells and uses that when generating 
MTD partitions 'reg' properties. Since #size-cells is now zero, the reg 
properties would be malformed.

Now, what I am unsure is whether the right fix is to update mx7 colibri 
DT and include &gpmi { #size-cells=<1>; }; , or , revert this patch. The 
former fixes the problem for colibri and retains the correct 
#size-cells=<0> behavior for any other board which does not specify MTD 
partitions in the GPMI NAND node. The later also covers boards which we 
don't know about which might also use generated MTD partitions in DT 
using fdt_fixup_mtdparts() in U-Boot, but I am not convinced that is 
correct.

So, would you be OK with fixing up the colibri mx7 DT with #size-cells=<1> ?

WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex@denx.de>
To: Francesco Dolcini <francesco@dolcini.it>
Cc: Shawn Guo <shawnguo@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	NXP Linux Team <linux-imx@nxp.com>,
	devicetree@vger.kernel.org, stable@vger.kernel.org,
	Sasha Levin <sashal@kernel.org>
Subject: Re: Boot failure regression on 6.0.10 stable kernel on iMX7
Date: Wed, 30 Nov 2022 23:59:04 +0100	[thread overview]
Message-ID: <fef2598e-e5fc-c4fc-0530-2d3c380ed39a@denx.de> (raw)
In-Reply-To: <Y4fCZmjDMtMMyu+E@francesco-nb.int.toradex.com>

On 11/30/22 21:51, Francesco Dolcini wrote:
> On Wed, Nov 30, 2022 at 03:41:13PM +0100, Marek Vasut wrote:
>> On 11/30/22 14:52, Francesco Dolcini wrote:
>>> [    0.000000] Booting Linux on physical CPU 0x0
>>> [    0.000000] Linux version 6.0.10 (francesco@francesco-nb) (arm-linux-gnueabihf-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.
>>> 4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #36 SMP Wed Nov 30 14:07:15 CET 2022
>>> ...
>>> [    4.407499] gpmi-nand: error parsing ofpart partition /soc/nand-controller@33002000/partition@0 (/soc/nand-controller
>>> @33002000)
>>> [    4.438401] gpmi-nand 33002000.nand-controller: driver registered.
>>> ...
>>> [    5.933906] VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0): error -19
>>> [    5.946504] Please append a correct "root=" boot option; here are the available partitions:
>>> ...
>>>
>>> Any idea? I'm not familiar with the gpmi-nand driver and I would just revert it, but
>>> maybe you have a better idea.
>>
>> Can you share the relevant snippet of your nand controller DT node ?
> 
> We just have
> 
> from imx7-colibri.dtsi,
> 
>    &gpmi {
>    	fsl,use-minimum-ecc;
>    	nand-ecc-mode = "hw";
>    	nand-on-flash-bbt;
>    	pinctrl-names = "default";
>    	pinctrl-0 = <&pinctrl_gpmi_nand>;
>    };
> 
> OF partition are created by U-Boot from
>    mtdparts=mtdparts=gpmi-nand:512k(mx7-bcb),1536k(u-boot1)ro,1536k(u-boot2)ro,512k(u-boot-env),-(ubi)
> env variables calling fdt_fixup_mtdparts from colibri_imx7.c
> 
> Everything is available in the upstream Linux/U-Boot git, no downstream
> repo of any sort.
> 
>> Probably up to first partition is enough. I suspect you need to fill in the
>> correct address-cells/size-cells there, which might be currently missing in
>> your DT and worked by chance.
> 
> This is generated by U-Boot, I would need to dump what he did generate
> from the standard fdt_fixup_mtdparts(). I will try to do it tomorrow
> unless what I wrote here is already enough to understand what's going
> on.

Oh drat ... I see. It's the u-boot fdt_node_set_part_info() which checks 
the current NAND controller #size-cells and uses that when generating 
MTD partitions 'reg' properties. Since #size-cells is now zero, the reg 
properties would be malformed.

Now, what I am unsure is whether the right fix is to update mx7 colibri 
DT and include &gpmi { #size-cells=<1>; }; , or , revert this patch. The 
former fixes the problem for colibri and retains the correct 
#size-cells=<0> behavior for any other board which does not specify MTD 
partitions in the GPMI NAND node. The later also covers boards which we 
don't know about which might also use generated MTD partitions in DT 
using fdt_fixup_mtdparts() in U-Boot, but I am not convinced that is 
correct.

So, would you be OK with fixing up the colibri mx7 DT with #size-cells=<1> ?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-11-30 22:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 13:52 Boot failure regression on 6.0.10 stable kernel on iMX7 Francesco Dolcini
2022-11-30 13:52 ` Francesco Dolcini
2022-11-30 14:41 ` Marek Vasut
2022-11-30 14:41   ` Marek Vasut
2022-11-30 20:51   ` Francesco Dolcini
2022-11-30 20:51     ` Francesco Dolcini
2022-11-30 22:59     ` Marek Vasut [this message]
2022-11-30 22:59       ` Marek Vasut
2022-12-01 11:03       ` Francesco Dolcini
2022-12-01 11:03         ` Francesco Dolcini
2022-12-01 11:03         ` Francesco Dolcini
2022-12-01 11:25         ` Marek Vasut
2022-12-01 11:25           ` Marek Vasut
2022-12-01 11:25           ` Marek Vasut
2022-12-01 15:45           ` Francesco Dolcini
2022-12-01 15:45             ` Francesco Dolcini
2022-12-01 15:45             ` Francesco Dolcini
2022-12-01 22:00             ` Marek Vasut
2022-12-01 22:00               ` Marek Vasut
2022-12-01 22:00               ` Marek Vasut
2022-12-01 12:06 ` Boot failure regression on 6.0.10 stable kernel on iMX7 #forregzbot Thorsten Leemhuis
2022-12-01 12:06   ` Thorsten Leemhuis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fef2598e-e5fc-c4fc-0530-2d3c380ed39a@denx.de \
    --to=marex@denx.de \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=francesco@dolcini.it \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sashal@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.