summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSam Protsenko <semen.protsenko@linaro.org>2025-09-29 17:19:26 -0500
committerTom Rini <trini@konsulko.com>2025-10-03 07:45:20 -0600
commit072264c4b3406aee50dad08355588577a547ab48 (patch)
treefe60a6fcc45d3ec037f715a895e78d9378d31b89
parent5a3c306aaf330794d35d2ab07c2f1d6dfa6020ef (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.c17
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);
/*