]> git.ipfire.org Git - thirdparty/u-boot.git/commitdiff
Revert "fdt: Make sure there is no stale initrd left"
authorSam Protsenko <semen.protsenko@linaro.org>
Mon, 29 Sep 2025 22:19:26 +0000 (17:19 -0500)
committerTom Rini <trini@konsulko.com>
Fri, 3 Oct 2025 13:45:20 +0000 (07:45 -0600)
This reverts commit 9fe2e4b46458f9c4ec6b8115ebf18b4b26fe6127.

Commit 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left")
introduces a 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 the mentioned commit.

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 next 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; ...
    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.

This issue was discussed [3], but no action was taken since then. Revert
this patch for now, until a proper solution can be found.

[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
[3] https://lists.denx.de/pipermail/u-boot/2025-July/593879.html

Fixes: 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
boot/fdt_support.c

index b7331bb76b3ef5fcf6c0a7d9c77db4befa8c2f0e..92f2f534ee02eab4361a7243fbb39024dd6930b4 100644 (file)
@@ -224,24 +224,15 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end)
        int is_u64;
        uint64_t addr, size;
 
+       /* just return if the size of initrd is zero */
+       if (initrd_start == initrd_end)
+               return 0;
+
        /* find or create "/chosen" node. */
        nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");
        if (nodeoffset < 0)
                return nodeoffset;
 
-       /*
-        * Although we didn'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.
-        */
-       if (initrd_start == initrd_end) {
-               fdt_delprop(fdt, nodeoffset, "linux,initrd-start");
-               fdt_delprop(fdt, nodeoffset, "linux,initrd-end");
-
-               return 0;
-       }
-
        total = fdt_num_mem_rsv(fdt);
 
        /*