[RFC, PATCH] fdt: Make sure there is no stale initrd left

[Sam Protsenko]

On Thu, Jun 12, 2025 at 5:15 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, 29 May 2025 17:02:13 +0200, Richard Weinberger wrote:
>
> > Although if we we don't setup an initrd, there could be a stale
> > initrd setting from the previous boot firmware in the live
> > device tree. So, make sure there is no setting left if we
> > don't want an initrd.
> >
> > This can happen when booting on a Raspberry Pi. The boot firmware
> > can happily load an initrd before us and configuring the addresses
> > in the live device tree we get handed over.
> >
> > [...]
>
> Applied to u-boot/next, thanks!
>

This patch introduces regression in case when U-Boot transfers control
to an EFI app which acts as a subsequent bootloading program. Such an
app might try to set "linux,initrd-start" and "linux,initrd-end" fdt
properties, but by that time those properties are already removed by
the code added in this patch.

Particularly, the issue was observed on the E850-96 board where GBL
EFI app [1] can't run Android successfully anymore. More specifically,
the kernel can't see the ramdisk and panics with these messages:

    /dev/root: Can't open blockdev
    VFS: Cannot open root device "" or unknown-block(0,0): error -6
    Please append a correct "root=" boot option; here are the
available partitions:
    Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)

fdt_initrd() function (where initrd dts properties are removed) is
called two times:

1. First it's called by EFI boot manager (e.g. as a part of U-Boot
Standard Boot mechanism) when it's installing FDT:

    fdt_initrd
    image_setup_libfdt
    efi_install_fdt
    efi_bootmgr_run
    efi_mgr_boot

It's already enough for EFI app to malfunction. But then it's also
called second time:

2. From the EFI app, via EFI DT fixup protocol:

    fdt_initrd
    image_setup_libfdt
    efi_dt_fixup
    struct efi_dt_fixup_protocol efi_dt_fixup_prot = {
        .fixup = efi_dt_fixup
    };

See [2] for specific GBL code which sets those fdt properties and then
runs DT fixup protocol callback.

I don't see any way for U-Boot to know if those initrd properties are
going to be set later by other EFI apps or not. So arguably this patch
should be reverted. But I might be missing something and maybe there
are better options to fix that?

Thanks!

[1] https://source.android.com/docs/core/architecture/bootloader/generic-bootloader/gbl-dev
[2] https://android.googlesource.com/platform/bootable/libbootloader/+/refs/heads/gbl-mainline/gbl/libgbl/src/android_boot/mod.rs#208

> [1/1] fdt: Make sure there is no stale initrd left
>       commit: 9fe2e4b46458f9c4ec6b8115ebf18b4b26fe6127
> --
> Tom
>