BISECTED f3866909e350 ("distro_bootcmd: call EFI bootmgr even without having /EFI/boot")
Heinrich Schuchardt
xypron.glpk at gmx.de
Sun Jun 6 18:47:48 CEST 2021
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
Best regards
Heinrich
More information about the U-Boot
mailing list