bug - bootflow: grub efi crashes when bootflow selected explicitly

[Simon Glass]

+Heinrich Schuchardt

Hi Shantur,

On Wed, 15 Nov 2023 at 05:59, Shantur Rathore <i at shantur.com> wrote:
>
> Hi all,
>
> I am facing an issue with bootflow where grub efi crashes only when
> bootflow is selected manually.
>
> Board - RockPro64
> OS - Armbian Bookworm CLI
> U-boot : 2024.01-rc2
> Built and installed in SPI
> Boot Device = USB drive connected to USB 2.0 port
>
> Success scenario :
>
> => setenv boot_targets usb
> => setenv bootmeths efi
> => bootflow scan -lb
>
> Grub loads and Linux boots
> Full Log - https://pastebin.com/KUFtUcha
>
> Failure scenario
> Full Log : https://pastebin.com/GHyG2NDz
>
> > setenv boot_targets usb
> => setenv bootmeths efi
> => bootflow scan
> => bootflow list
> Showing all bootflows
> Seq Method State Uclass Part Name Filename
> --- ----------- ------ -------- ---- ------------------------ ----------------
> 0 efi ready usb_mass_ 1 usb_mass_storage.lun0.boo efi/boot/bootaa64.efi
> --- ----------- ------ -------- ---- ------------------------ ----------------
> (1 bootflow, 1 valid)
> => bootflow select 0
> => bootflow boot
> ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_1' with efi
>
> Loading Linux 6.1.50-current-rockchip64 ...
> Loading initial ramdisk ...
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services...
> "Synchronous Abort" handler, esr 0x96000044, far 0x300905a65
> elr: 000000000022d634 lr : 0000000000208e14 (reloc)
> elr: 00000000f3f47634 lr : 00000000f3f22e14
> x0 : 0000000300905a4d x1 : 0000000000000000
> x2 : 0000000000000000 x3 : 000000000207fff0
> x4 : 00000000f3fd6470 x5 : 000000000207fff0
> x6 : 0000ffff00000004 x7 : 00000000f1f9fad0
> x8 : 7f7f7f7f7f7f7f7f x9 : 000000000000d02c
> x10: 00000000f1efee8c x11: 000000000000d020
> x12: 00000000f1efef88 x13: 00000000ad400000
> x14: 00000000f1efef2c x15: 00000000f1eff057
> x16: 00000000f3f21fc0 x17: 00000000d017a1d0
> x18: 00000000f1f11d70 x19: 00000000f1f21eb0
> x20: 0000000000000000 x21: 00000000f1f27b80
> x22: 0000000000000000 x23: 0000000000000000
> x24: 0000000000000000 x25: 00000000f3fc9ed7
> x26: 00000000b0c36000 x27: 00000000f02cd000
> x28: 00000000f03a210c x29: 00000000f1efee20
>
> Code: f9400860 eb06001f 540004e0 f9400c66 (f9000c06)
> UEFI image [0x00000000f0da4000:0x00000000f0dbbfff] '/efi\boot\fbaa64.efi'
> UEFI image [0x00000000f0386000:0x00000000f07adfff] '/\EFI\debian\grubaa64.efi'
> UEFI image [0x00000000af4e0000:0x00000000b11dffff]
> Resetting CPU ...
>
> resetting ...
>
> I am unable to figure out what is the difference between the 2 ways of booting.
>
> Thanks for your help.

Thank you for the detailed report. Can you try series [1] in
particular patch [2]

It has been sitting around for quite a while, unfortunately.

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=381851
[2] https://patchwork.ozlabs.org/project/uboot/patch/20231112130245.v4.5.If206027372f73ce32480223e5626f4b944e281b7@changeid/