On Thu, Jun 12, 2025 at 5:15 PM Tom Rini <tr...@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
>
