Hi Heinrich
On Wed, 30 Apr 2025 at 14:31, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
>
> On 30.04.25 13:00, Heinrich Schuchardt wrote:
> > On 30.04.25 09:03, Heinrich Schuchardt wrote:
> >> On 4/29/25 15:27, Adriano Cordova wrote:
> >>> Do not try to create an initrd device path nor try to register
> >>> an initrd with the EFI_LOAD_FILE2_PROTOCOL if none is provided.
> >>>
> >>> Handle initrd installation in efi_binary_run_dp with
> >>> efi_install_initrd, imitating what is done for the fdt.
> >>>
> >>> Fixes: 36835a9105c ("efi_loader: binary_run: register an initrd")
> >>> Reported-by: Weizhao Ouyang <o451686...@gmail.com>
> >>> Signed-off-by: Adriano Cordova <adriano.cord...@canonical.com>
> >>> Tested-by: Weizhao Ouyang <o451686...@gmail.com>
> >>
> >> I built and installed U-Boot for the StarFive VisionFive 2 based on
> >> origin/master plus this series.
> >>
> >> I created a FIT images using the its file listed below.
> >>
> >> I loaded and tried to run the FIT image:
> >>
> >> StarFive # load nvme 0:1 $kernel_addr_r initrd.itb
> >> StarFive # bootm $kernel_addr_r
> >>
> >> and saw the following failure:
> >>
> >> ## Transferring control to EFI (at address 00000000) ...
> >> Card did not respond to voltage select! : -110
> >> Booting /initrd.itb
> >> Not a PE-COFF file
> >> Loading image failed
> >>
> >> We use the entry point instead of the load address when transferring
> >> control to the EFI sub-system.
> >>
> >> This bug was introduced by ecc7fdaa9ef1 ("bootm: Add a bootm command
> >> for type IH_OS_EFI") and is not related to your patches but we still
> >> need to fix it.
> >
> > Addressed by:
> > bootm: pass kernel load address not entry point for IH_OS_EFI
> > https://patchwork.ozlabs.org/project/uboot/
> > patch/20250430105546.327442-1-heinrich.schucha...@canonical.com/
> >
> >>
> >> Afterwards I tried to boot into Ubuntu and got:
> >>
> >> Loading Linux 6.14.0-13-generic ...
> >> Loading initial ramdisk ...
> >> error: failed to install protocols.
> >> Loading device tree blob...
> >>
> >> Press any key to continue...
> >>
> >> It seems that U-Boot did not uninstall the LoadFile2 protocol when
> >> discovering that the EFI image was invalid. We should have a look at
> >> the error handling.
> >
> > This issue still has to be resolved.
>
> For FIT images we don't trigger the event group related to
> efi_guid_event_group_return_to_efibootmgr which calls event
> efi_initrd_return_notify() which in turn calls efi_initrd_deregister().
>
> A call to efi_initrd_deregister() is missing in do_bootm_efi().
>
> Maybe adding the call to efi_binary_run() and getting rid of the event
> group would be preferable.
>
> @Ilias, @Masahisa
> Any preferences?
I was about to respond that EFI handles that with an event! We used to
do this in the efi bootmgr code, when returning from the EFI app, but
having an event seemed more elegant back then.
If removing the event makes the code common across efi/non-efi cases I
am fine removing it.
Cheers
/Ilias
>
> Best regards
>
> Heinrich
>
> >
> >>
> >> The initrd for my test case can be created with:
> >>
> >> echo 'hello world' > hello
> >> echo hello | cpio -o -H newc > initrd
> >>
> >
> > Reviewed-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> >
>
