diff options
author | Sam Protsenko <semen.protsenko@linaro.org> | 2025-09-29 17:19:26 -0500 |
---|---|---|
committer | Tom Rini <trini@konsulko.com> | 2025-10-03 07:45:20 -0600 |
commit | 072264c4b3406aee50dad08355588577a547ab48 (patch) | |
tree | fe60a6fcc45d3ec037f715a895e78d9378d31b89 | |
parent | 5a3c306aaf330794d35d2ab07c2f1d6dfa6020ef (diff) |
Revert "fdt: Make sure there is no stale initrd left"
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>
-rw-r--r-- | boot/fdt_support.c | 17 |
1 files changed, 4 insertions, 13 deletions
diff --git a/boot/fdt_support.c b/boot/fdt_support.c index b7331bb76b3..92f2f534ee0 100644 --- a/boot/fdt_support.c +++ b/boot/fdt_support.c @@ -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); /* |