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

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

[Richard Weinberger]

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.

Especially the setting `auto_initramfs` in config.txt is dangerous.
When enabled (default), the firmware tries to be smart and looks for
initramfs files.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
Hi!

This foot gun hit me hard and invalidated an A/B
update concept...

Thanks,
//richard
---
 boot/fdt_support.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 92f2f534ee0..b7331bb76b3 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -224,15 +224,24 @@ 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);
 
 	/*
-- 
2.43.0

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

[Tom Rini]

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!

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

Re: [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@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
>

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

[Richard Weinberger]

On Mittwoch, 9. Juli 2025 00:58 Sam Protsenko wrote:
> 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?

I think we need to distinguish two cases:
1. The caller explicitly does not want to have an initramfs. e.g. you run  "bootm addr1 - addr3".
2. The caller does not care. Your case.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

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

[Sam Protsenko]

On Wed, Jul 9, 2025 at 1:24 AM Richard Weinberger <richard@sigma-star.at> wrote:
>
> On Mittwoch, 9. Juli 2025 00:58 Sam Protsenko wrote:
> > 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?
>
> I think we need to distinguish two cases:
> 1. The caller explicitly does not want to have an initramfs. e.g. you run  "bootm addr1 - addr3".

Yes, so fdt_delprop() lines should be probably moved to appropriate
users, e.g. image_setup_linux(). Can you take care of this? I'm in the
middle of something else right now and can't spend too much time on
this. Or we can just revert this patch for now, to fix EFI apps
breakage.

> 2. The caller does not care. Your case.
>
> Thanks,
> //richard
>
> --
> sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
> ATU 66964118 | FN: 374287y
>
>

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

[Richard Weinberger]

On Mittwoch, 9. Juli 2025 19:05 Sam Protsenko wrote:
> > I think we need to distinguish two cases:
> > 1. The caller explicitly does not want to have an initramfs. e.g. you run  "bootm addr1 - addr3".
> 
> Yes, so fdt_delprop() lines should be probably moved to appropriate
> users, e.g. image_setup_linux(). Can you take care of this? I'm in the
> middle of something else right now and can't spend too much time on
> this. Or we can just revert this patch for now, to fix EFI apps
> breakage.

I'll try to allocate time for that.
Are we in a hurry? I'm fine with reverting but since the next release is months
away and the change is only in next I'd first try to find a solution.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

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

[Sam Protsenko]

On Thu, Jul 10, 2025 at 9:40 AM Richard Weinberger
<richard@sigma-star.at> wrote:
>
> On Mittwoch, 9. Juli 2025 19:05 Sam Protsenko wrote:
> > > I think we need to distinguish two cases:
> > > 1. The caller explicitly does not want to have an initramfs. e.g. you run  "bootm addr1 - addr3".
> >
> > Yes, so fdt_delprop() lines should be probably moved to appropriate
> > users, e.g. image_setup_linux(). Can you take care of this? I'm in the
> > middle of something else right now and can't spend too much time on
> > this. Or we can just revert this patch for now, to fix EFI apps
> > breakage.
>
> I'll try to allocate time for that.
> Are we in a hurry? I'm fine with reverting but since the next release is months
> away and the change is only in next I'd first try to find a solution.
>

No, you're right, we have time. I specifically reported the issue
instead of sending a revert, so that we can try and look for a
solution. So I'm ok waiting, if you have time to sort this out. Please
add me to Cc: when you send a patch, I can test it on my HW for you.

P.S. The change is in master already btw, not only in -next, it's MW right now.

> Thanks,
> //richard
>
> --
> sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
> ATU 66964118 | FN: 374287y
>
>

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

[Sam Protsenko]

On Thu, Jul 10, 2025 at 12:20 PM Sam Protsenko
<semen.protsenko@linaro.org> wrote:
>
> On Thu, Jul 10, 2025 at 9:40 AM Richard Weinberger
> <richard@sigma-star.at> wrote:
> >
> > On Mittwoch, 9. Juli 2025 19:05 Sam Protsenko wrote:
> > > > I think we need to distinguish two cases:
> > > > 1. The caller explicitly does not want to have an initramfs. e.g. you run  "bootm addr1 - addr3".
> > >
> > > Yes, so fdt_delprop() lines should be probably moved to appropriate
> > > users, e.g. image_setup_linux(). Can you take care of this? I'm in the
> > > middle of something else right now and can't spend too much time on
> > > this. Or we can just revert this patch for now, to fix EFI apps
> > > breakage.
> >
> > I'll try to allocate time for that.
> > Are we in a hurry? I'm fine with reverting but since the next release is months
> > away and the change is only in next I'd first try to find a solution.
> >
>
> No, you're right, we have time. I specifically reported the issue
> instead of sending a revert, so that we can try and look for a
> solution. So I'm ok waiting, if you have time to sort this out. Please
> add me to Cc: when you send a patch, I can test it on my HW for you.
>

Hey Richard,

Did you have a chance to look into reworking this patch? I'm still
carrying a revert locally (to make GBL EFI app work), and would like
to get rid of it. Please advice if you have a plan on handling this in
the near future.

Thanks!

> P.S. The change is in master already btw, not only in -next, it's MW right now.
>
> > Thanks,
> > //richard
> >
> > --
> > sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
> > ATU 66964118 | FN: 374287y
> >
> >

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

[Richard Weinberger]

Sam,

On Sonntag, 21. September 2025 01:01 Sam Protsenko wrote:
> Hey Richard,
> 
> Did you have a chance to look into reworking this patch? I'm still
> carrying a revert locally (to make GBL EFI app work), and would like
> to get rid of it. Please advice if you have a plan on handling this in
> the near future.

Before my vacation I had a look but found no nice solution.
So, let's process with the revert.

My current way to work around the problem is having these commands in
my U-Boot scripts:

fdt addr $fdt_addr
fdt rm /chosen linux,initrd-start
fdt rm /chosen linux,initrd-end

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Fri, Oct 03, 2025 at 09:09:20PM +0200, Richard Weinberger wrote:
> Sam,
> 
> On Sonntag, 21. September 2025 01:01 Sam Protsenko wrote:
> > Hey Richard,
> > 
> > Did you have a chance to look into reworking this patch? I'm still
> > carrying a revert locally (to make GBL EFI app work), and would like
> > to get rid of it. Please advice if you have a plan on handling this in
> > the near future.
> 
> Before my vacation I had a look but found no nice solution.
> So, let's process with the revert.
> 
> My current way to work around the problem is having these commands in
> my U-Boot scripts:
> 
> fdt addr $fdt_addr
> fdt rm /chosen linux,initrd-start
> fdt rm /chosen linux,initrd-end

I do wonder if the best path forward is adding some opt-in CONFIG option
here?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Richard Weinberger]

On Freitag, 3. Oktober 2025 23:01 Tom Rini wrote:
> > My current way to work around the problem is having these commands in
> > my U-Boot scripts:
> > 
> > fdt addr $fdt_addr
> > fdt rm /chosen linux,initrd-start
> > fdt rm /chosen linux,initrd-end
> 
> I do wonder if the best path forward is adding some opt-in CONFIG option
> here?

Hm, yes. Maybe something like CONFIG_FDT_INITRD_EXPLIZIT which is enabled
by default for the RPi target?

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

On Sat, Oct 04, 2025 at 10:05:43AM +0200, Richard Weinberger wrote:
> On Freitag, 3. Oktober 2025 23:01 Tom Rini wrote:
> > > My current way to work around the problem is having these commands in
> > > my U-Boot scripts:
> > > 
> > > fdt addr $fdt_addr
> > > fdt rm /chosen linux,initrd-start
> > > fdt rm /chosen linux,initrd-end
> > 
> > I do wonder if the best path forward is adding some opt-in CONFIG option
> > here?
> 
> Hm, yes. Maybe something like CONFIG_FDT_INITRD_EXPLIZIT which is enabled
> by default for the RPi target?

That's probably as good a name as any, yes.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]