BISECTED f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot")

Matwey V. Kornilov matwey.kornilov at gmail.com
Fri Jun 11 17:18:54 CEST 2021


пт, 11 июн. 2021 г. в 00:02, Heinrich Schuchardt <xypron.glpk at gmx.de>:
>
> On 6/10/21 10:05 PM, Heinrich Schuchardt wrote:
> > On 6/7/21 7:51 PM, Matwey V. Kornilov wrote:
> >> вс, 6 июн. 2021 г. в 19:47, Heinrich Schuchardt <xypron.glpk at gmx.de>:
> >>>
> >>> On 6/6/21 6:21 PM, Heinrich Schuchardt wrote:
> >>>> On 6/6/21 5:42 PM, Matwey V. Kornilov wrote:
> >>>>> вс, 6 июн. 2021 г. в 18:20, Heinrich Schuchardt <xypron.glpk at gmx.de>:
> >>>>>>
> >>>>>> On 6/6/21 4:37 PM, Matwey V. Kornilov wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I've found that
> >>>>>>>
> >>>>>>> f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having
> >>>>>>> /EFI/boot")
> >>>>>>>
> >>>>>>> breaks running EFI application from USB device on BeagleBone Black
> >>>>>>> (am335x) device.
> >>>>>>>
> >>>>>>> With this patch I see the following:
> >>>>>>>
> >>>>>>> Booting /efi\boot\bootarm.efi
> >>>>>>> Welcome to GRUB!
> >>>>>>>
> >>>>>>> data abort
> >>>>>>> pc : [<9ce0b6d0>]          lr : [<9ffab7c7>]
> >>>>>>> reloc pc : [<7d69d6d0>]    lr : [<8083d7c7>]
> >>>>>>> sp : 9df44e28  ip : 9ffdfe90     fp : 00000003
> >>>>>>> r10: 9ffe3300  r9 : 00000000     r8 : 9df6fe88
> >>>>>>> r7 : 00000000  r6 : 9ce5da08     r5 : 9ce571f8  r4 : 9ce2c040
> >>>>>>> r3 : 00000000  r2 : 00000001     r1 : 9ce56598  r0 : 00000000
> >>>>>>> Flags: NzCv  IRQs off  FIQs on  Mode SVC_32
> >>>>>>> Code: e3500000 0a000015 e590000c eb00f96e (e5d03000)
> >>>>>>    > UEFI image [0x9ce46000:0x9cf28fff] '/efi\boot\bootarm.efi'
> >>>>>>    > Resetting CPU ...
> >>>>>>
> >>>>>> Hello Matwey,
> >>>>>>
> >>>>>> thank you for reporting the issue.
> >>>>>>
> >>>>>> $ echo 'Code: e3500000 0a000015 e590000c eb00f96e (e5d03000)' |
> >>>>>> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm scripts/decodecode
> >>>>>>
> >>>>>> Code: e3500000 0a000015 e590000c eb00f96e (e5d03000)
> >>>>>> All code
> >>>>>> ========
> >>>>>>       0:   e3500000        cmp     r0, #0
> >>>>>>       4:   0a000015        beq     0x60
> >>>>>>       8:   e590000c        ldr     r0, [r0, #12]
> >>>>>>       c:   eb00f96e        bl      0x3e5cc
> >>>>>>      10:*  e5d03000        ldrb    r3, [r0]                <--
> >>>>>> trapping
> >>>>>> instruction
> >>>>>>
> >>>>>> Code starting with the faulting instruction
> >>>>>> ===========================================
> >>>>>>       0:   e5d03000        ldrb    r3, [r0]
> >>>>>>
> >>>>>> Looking at the disassembly above we see that reading memory location
> >>>>>> NULL fails.
> >>>>>>
> >>>>>> We need to find out where the exception occurs. The code position is
> >>>>>> neither in bootarm.efi nor in U-Boot (9ce0b6d0 is lower than the load
> >>>>>> position of bootarm.efi, so it is below the relocated U-Boot code).
> >>>>>>
> >>>>>> Please, add the following line at the start of grub.cfg to get more
> >>>>>> output from GRUB:
> >>>>>>
> >>>>>>           debug=all
> >>>>>
> >>>>> This doesn't provide any additional output from GRUB :(
> >>>>>
> >>>>>>
> >>>>>> When building U-Boot, please, add
> >>>>>>
> >>>>>>           #define DEBUG 1
> >>>>>>
> >>>>>> in lib/efi_loader/efi_disk.c and lib/efi_loader_file.c a line before
> >>>>>> #include <common.h>.
> >>>>>
> >>>>>
> >>>>> This doesn't provide much output as well:
> >>>>>
> >>>>> Scanning disk mmc at 48060000.blk...
> >>>>> EFI: Call: efi_install_multiple_protocol_interfaces( &handle,
> >>>>> &efi_guid_device_path, diskobj->dp, &efi_block_io_guid, &diskobj->ops,
> >>>>> NULL)
> >>>>> EFI: 0 returned by efi_install_multiple_protocol_interfaces( &handle,
> >>>>> &efi_guid_device_path, diskobj->dp, &efi_block_io_guid, &diskobj->ops,
> >>>>> NULL)
> >>>>> ** Unrecognized filesystem type **
> >>>>> Scanning disk mmc at 481d8000.blk...
> >>>>> EFI: Call: efi_install_multiple_protocol_interfaces( &handle,
> >>>>> &efi_guid_device_path, diskobj->dp, &efi_block_io_guid, &diskobj->ops,
> >>>>> NULL)
> >>>>> EFI: 0 returned by efi_install_multiple_protocol_interfaces( &handle,
> >>>>> &efi_guid_device_path, diskobj->dp, &efi_block_io_guid, &diskobj->ops,
> >>>>> NULL)
> >>>>> EFI: Call: efi_install_multiple_protocol_interfaces( &handle,
> >>>>> &efi_guid_device_path, diskobj->dp, &efi_block_io_guid, &diskobj->ops,
> >>>>> NULL)
> >>>>> EFI: 0 returned by efi_install_multiple_protocol_interfaces( &handle,
> >>>>> &efi_guid_device_path, diskobj->dp, &efi_block_io_guid, &diskobj->ops,
> >>>>> NULL)
> >>>>> Found 3 disks
> >>>>
> >>>> This implies that GRUB is crashing before even accessing the file
> >>>> system
> >>>> (including grub.cfg).
> >>>>
> >>>> On an OrangePi PC I deleted /boot.scr and moved grubarm.efi to
> >>>> /EFI/boot/bootarm.efi. It boots without problem.
> >>>>
> >>>> What version of GRUB are you using?
> >>>> How were you booting before updating U-Boot?
> >>>> What version of U-Boot are you using where the error occurs?
> >>>> Why do you have grub in /EFI/boot/bootarm.efi and not in a distro
> >>>> specific path, e.g. /EFI/debian/grubarm.efi? /EFI/boot is typically
> >>>> only
> >>>> used by installers.
> >>>>
> >>>> If the boot manager is started by distroboot it may not have an
> >>>> appropriate device path. It tries to load the file given by environment
> >>>> variable $fdtfile from the boot device.
> >>>>
> >>>>   From the U-Boot console could you, please, try:
> >>>>
> >>>> 1)
> >>>> load usb 0:1 $kernel_addr_r EFI/boot/bootarm.efi
> >>>> bootefi bootmgr
> >>>>
> >>>>
> >>>> 2)
> >>>> load usb 0:1 $kernel_addr_r EFI/boot/bootarm.efi
> >>>> load usb 0:2 $fdt_addr_r dtb
> >>>> bootefi bootmgr $fdt_addr_r
> >>>>
> >>>> where you need to replace dtb by the correct device tree file and
> >>>> adjust
> >>>> the partition numbers.
> >>>>
> >>>> Best regards
> >>>>
> >>>> Heinrich
> >>>
> >>> To catch the earlier EFI API calls you can add
> >>>
> >>> #define DEBUG 1
> >>>
> >>> to lib/efi_loader/efi_boottime.c
> >>
> >>
> >> Welcome to GRUB!
> >>
> >>      EFI: Entry efi_locate_handle_ext(2,
> >> 9042a9de-23dc-4a38-96fb-7aded080516a, 00000000, 9df40dfc, 9ce2d660)
> >
> > EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID
> >
> > This call could be from grub-core/video/efi_gop.c, check_protocol().
> >
> >>      EFI: Exit: efi_locate_handle_ext: 14
> >
> > EFI_NOT_FOUND
> >
> >>      EFI: Entry efi_open_protocol(9df5f298,
> >> 5b1b31a1-9562-11d2-8e3f-00a0c969723b, 9df40e14, 9df5f298, 00000000,
> >> 0x2)
> >
> > EFI_LOADED_IMAGE_PROTOCOL_GUID
> >
> > This call could be from grub-core/kern/efi/efi.c,
> > grub_efi_get_loaded_image().
> >
> >>      EFI: Exit: efi_open_protocol: 0
> >>      EFI: Entry efi_open_protocol(00000000,
> >
> > The parameter @handle must not be NULL.
> >
> >> 09576e91-6d3f-11d2-8e39-00a0c969723b, 9df40e14, 9df5f298, 00000000,
> >
> > EFI_DEVICE_PATH_PROTOCOL_GUID
> >
> > This could be called from grub-core/kern/efi/efi.c,
> > grub_efi_get_device_path() which is invoked from
> > grub_machine_get_bootlocation().
> >
> >> 0x2)
> >
> > EFI_INVALID_PARAMETER is returned because the handle is NULL.
> >
> > I could partially reproduce the problem by setting
> >
> >    info->device_handle = NULL;
> >
> > at the end of efi_setup_loaded_image():
> >
> > Welcome to GRUB!
> >
> >     EFI: Entry efi_open_protocol(79fdea40,
> > 5b1b31a1-9562-11d2-8e3f-00a0c969723b, 79f570e4, 79fdea40, 00000000, 0x2)
> >     EFI: Exit: efi_open_protocol: 0
> >     EFI: Entry efi_open_protocol(00000000,
> > 09576e91-6d3f-11d2-8e39-00a0c969723b, 79f570b4, 79fdea40, 00000000, 0x2)
> >     EFI: Exit: efi_open_protocol: 2
> > error: disk `,msdos2' not found.
> > grub rescue> >
> >
> > This leaves me with two questions:
> >
> > Why does GRUB not handle
> >
> >     *device = grub_efidisk_get_device_name (NULL);
> >
> > gracefully? Maybe it is because it tries to print via the graphical
> > output protocol which does not exist?
>
> You wrote that you are using Suse JeOS.
>
> In grub.cfg you could replace
>
> with_gfx=1
> gfxmode=auto
>
> by
>
> with_gfx=0
> set textmode=true
>
> This should give you output on the serial console and avoid the crash.

I've tried but this doesn't seem to work :(

>
> Best regards
>
> Heinrich
>
> >
> > Why is image->device_handle NULL?
> >
> > Next step is to verify that image->device_handle is really NULL.
> >
> > Please apply the following change to efi/efi_loader/efi_boottime.c
> >
> > @@ -2060,6 +2069,7 @@ efi_status_t EFIAPI efi_load_image(bool boot_policy,
> >                 free(info);
> >         }
> > error:
> > +       printf("*** %p\n", info->device_handle);
> >         return EFI_EXIT(ret);
> > }
> >
> > Best regards
> >
> > Heinrich
> >
> >>      EFI: Exit: efi_open_protocol: 2
> >> data abort
> >> pc : [<9ce076d0>]          lr : [<9ffa85b3>]
> >> reloc pc : [<7d69d6d0>]    lr : [<8083e5b3>]
> >> sp : 9df40e28  ip : 00000000     fp : 00000003
> >> r10: 9ffe2df8  r9 : 00000000     r8 : 9df5f298
> >> r7 : 00000000  r6 : 9ce59a08     r5 : 9ce531f8  r4 : 9ce28040
> >> r3 : 00000000  r2 : 9ffeb328     r1 : 00000000  r0 : 00000000
> >> Flags: NzCv  IRQs off  FIQs on  Mode SVC_32
> >> Code: e3500000 0a000015 e590000c eb00f96e (e5d03000)
> >> UEFI image [0x9ce42000:0x9cf24fff] '/efi\boot\bootarm.efi'
> >> Resetting CPU ...
> >>
> >>
> >>>
> >>> Best regards
> >>>
> >>> Heinrich
> >>>
> >>>
> >>
> >>
> >
> >
>


-- 
With best regards,
Matwey V. Kornilov


More information about the U-Boot mailing list