Received-SPF: pass (google.com: domain of linux-kernel+bounces-121350-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20230317053415.2254616-1-frowand.list@gmail.com>
 <20230317053415.2254616-2-frowand.list@gmail.com> <886049ed-4f5f-4e17-86f4-1245024ade3a@roeck-us.net>
 <CAL_JsqKsF53v7d7uZ3XT4kPFy-2FBWHfvKNSFdTx2oZhmSZkDA@mail.gmail.com>
 <66409df9-6f5f-4fbe-ae7f-47b86665c113@roeck-us.net> <CAL_Jsq+0JHTDmBPr94ZZF_5rtQg14q8OmWH6WpRspjHMX-MZmg@mail.gmail.com>
 <23ed5bbb-7616-424b-96ee-3fe1c6d8ca89@roeck-us.net>
In-Reply-To: <23ed5bbb-7616-424b-96ee-3fe1c6d8ca89@roeck-us.net>
From: Rob Herring <robh+dt@kernel.org>
Date: Wed, 27 Mar 2024 08:11:37 -0500
Message-ID: <CAL_JsqJd-upC4TgOwP5-DMXKL+x=X7sGC7qqiy2PTjD6pnSV7Q@mail.gmail.com>
Subject: Re: [PATCH v4 1/2] of: create of_root if no dtb provided
To: Guenter Roeck <linux@roeck-us.net>
Cc: Stephen Boyd <sboyd@kernel.org>, Frank Rowand <frowand.list@gmail.com>, 
	=?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com>, 
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, 
	Lizhi Hou <lizhi.hou@xilinx.com>, Allan Nielsen <allan.nielsen@microchip.com>, 
	Horatiu Vultur <horatiu.vultur@microchip.com>, 
	Steen Hegelund <steen.hegelund@microchip.com>, 
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2024 at 3:06=E2=80=AFPM Guenter Roeck <linux@roeck-us.net> =
wrote:
>
> On 3/20/24 12:14, Rob Herring wrote:
> > On Mon, Mar 18, 2024 at 4:31=E2=80=AFPM Guenter Roeck <linux@roeck-us.n=
et> wrote:
> >>
> >> On 3/18/24 12:26, Rob Herring wrote:
> >>> +Stephen
> >>>
> >>> On Mon, Mar 18, 2024 at 12:09=E2=80=AFPM Guenter Roeck <linux@roeck-u=
s.net> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> On Fri, Mar 17, 2023 at 12:34:14AM -0500, Frank Rowand wrote:
> >>>>> When enabling CONFIG_OF on a platform where of_root is not populate=
d by
> >>>>> firmware, we end up without a root node. In order to apply overlays=
 and
> >>>>> create subnodes of the root node, we need one. Create this root nod=
e
> >>>>> by unflattening an empty builtin dtb.
> >>>>>
> >>>>> If firmware provides a flattened device tree (FDT) then the FDT is
> >>>>> unflattened via setup_arch().  Otherwise setup_of(), which is calle=
d
> >>>>> immediately after setup_arch(), will create the default root node
> >>>>> if it does not exist.
> >>>>>
> >>>>> Signed-off-by: Frank Rowand <frowand.list@gmail.com>
> >>>>
> >>>> This patch results in a crash on nios2.
> >>>
> >>> This patch was never applied. I assume you meant a later version of i=
t
> >>> that did get applied.
> >>>
> >>>>
> >>>> Building nios2:10m50-ghrd:10m50_defconfig:10m50_devboard.dts ... run=
ning ...R failed (crashed)
> >>>
> >>> Booting with DT?
> >>>
> >>>> ------------
> >>>> qemu log:
> >>>> earlycon: uart8250 at MMIO32 0x18001600 (options '')
> >>>> printk: legacy bootconsole [uart8250] enabled
> >>>> Linux version 6.8.0-11409-gf6cef5f8c37f (groeck@desktop) (nios2-linu=
x-gcc (GCC) 11.4.0, GNU ld (GNU Binutils) 2.40) #1 Sun Mar 17 23:38:59 PDT =
2024
> >>>> Kernel panic - not syncing: early_init_dt_alloc_memory_arch: Failed =
to allocate 72 bytes align=3D0x40
> >>>> ---[ end Kernel panic - not syncing: early_init_dt_alloc_memory_arch=
: Failed to allocate 72 bytes align=3D0x40 ]---
> >>>
> >>> nios2 looks utterly broken to me. This change should be a nop unless
> >>> initial_boot_params is NULL. It looks like it is possible for r6 (dtb
> >>> address) to be 0 depending on kconfig options, but that would have
> >>> skipped copying and unflattening which would then panic in
> >>> setup_cpuinfo(). If initial_boot_params is not NULL, then the same
> >>> early_init_dt_alloc_memory_arch() calls should fail when copying the
> >>> DT. So I don't see how nios2 booting with DT ever worked.
> >>>
> >>
> >> For nios2, in early_init_devtree():
> >>
> >> void __init early_init_devtree(void *params)
> >> {
> >>           __be32 *dtb =3D (u32 *)__dtb_start;
> >>          ...
> >>           if (be32_to_cpu((__be32) *dtb) =3D=3D OF_DT_HEADER)
> >>                   params =3D (void *)__dtb_start;
> >>
> >> That worked fine until this patch. Starting with this patch, __dtb_sta=
rt
> >> always points to a valid empty devicetree blob, which overrides the
> >> devicetree blob passed to early_init_devtree(). This causes the proble=
m.
> >
> > With an external DTB, it doesn't boot with or without this patch. It
> > just dies in different spots. Before it just skipped any memory
>
> No, that is incorrect.

Well, I can tell you it doesn't boot for me. So I must be doing
something different from your setup.

> Up to this patch it booted just fine with an
> external dtb using the "-initrd" command line argument, and I explained
> to you above why this is the case.

What does -initrd have to do with anything? Does that shift where the
external dtb is placed or something?

I think I see the issue. __dtb_start points to the start of *all*
built-in DTBs, not a specific one. In this case, arc, csky, loongarch,
mips, openrisc, riscv, sh, and xtensa may all be broken too (if one
picks the magic combination of booting modes and kconfig options). I
would expect all these cases have been broken forever if the DT
unittest is enabled as it too adds a built-in dtb. But I would also
expect that arch code gets linked first and link order would save us
here.

Rob