[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 at 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
>
>