[U-Boot] [PATCH v2 1/3] efi_loader: rework fdt handling in distro boot script
Alexander Graf
agraf at suse.de
Tue Oct 23 07:36:58 UTC 2018
On 23.10.18 03:08, AKASHI Takahiro wrote:
> On Mon, Oct 22, 2018 at 08:42:32AM +0100, Alexander Graf wrote:
>>
>>
>> On 22.10.18 08:22, AKASHI Takahiro wrote:
>>> On Mon, Oct 22, 2018 at 01:40:05PM +0900, AKASHI Takahiro wrote:
>>>> The current scenario for default UEFI booting, scan_dev_for_efi, has
>>>> several issues:
>>>> * load dtb dynamically even if its loacation (device) is not the same
>>>> as BOOTEFI_NAME binary's, (reported by Alex)
>>>> * invoke 'bootmgr' only if BOOTEFI_NAME binary does exit even though
>>>> 'bootmgr' can and should work independently whether or not the binary
>>>> exist,
>>>> * in addition, invoke 'bootmgr' with dynamically-loaded dtb.
>>>> This behavior is not expected. (reported by Alex)
>>>> * always assume that a 'fdtfile' variable is defined,
>>>> ("test -e ${devtype} ${devnum}:${distro_bootpart} "${prefix}${efi_fdtfile}"
>>>> always returns true even if fdtfile is NULL with prefix=="/".)
>>>> * redundantly check for 'fdt_addr_r' in boot_efi_binary
>>>>
>>>> In this patch, all the issues above are sorted out.
>>>> Please note that the default behavior can be customized with:
>>>> fdtfile: a dtb file name
>>>> efi_dtb_prefixes: a list of paths for searching for a dtb file
>>>>
>>>> (this feature does work even without this patch.)
>>>>
>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi at linaro.org>
>>>> ---
>>>> include/config_distro_bootcmd.h | 38 +++++++++++++++++----------------
>>>> 1 file changed, 20 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>>>> index 373fee78a999..256698309eb9 100644
>>>> --- a/include/config_distro_bootcmd.h
>>>> +++ b/include/config_distro_bootcmd.h
>>>> @@ -115,7 +115,7 @@
>>>> */
>>>> #define BOOTENV_EFI_SET_FDTFILE_FALLBACK \
>>>> "if test -z \"${fdtfile}\" -a -n \"${soc}\"; then " \
>>>> - "setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; " \
>>>> + "efi_fdtfile=${soc}-${board}${boardver}.dtb; " \
>>>> "fi; "
>>>> #else
>>>> #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
>>>> @@ -124,26 +124,20 @@
>>>>
>>>> #define BOOTENV_SHARED_EFI \
>>>> "boot_efi_binary=" \
>>>> - "if fdt addr ${fdt_addr_r}; then " \
>>>> - "bootefi bootmgr ${fdt_addr_r};" \
>>>> - "else " \
>>>> - "bootefi bootmgr ${fdtcontroladdr};" \
>>>> - "fi;" \
>>>> "load ${devtype} ${devnum}:${distro_bootpart} " \
>>>> "${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; " \
>>>> - "if fdt addr ${fdt_addr_r}; then " \
>>>> - "bootefi ${kernel_addr_r} ${fdt_addr_r};" \
>>>> - "else " \
>>>> - "bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
>>>> - "fi\0" \
>>>> + "bootefi ${kernel_addr_r} ${efi_fdt_addr};\0" \
>>>> \
>>>> "load_efi_dtb=" \
>>>> - "load ${devtype} ${devnum}:${distro_bootpart} " \
>>>> - "${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
>>>> + "load ${devtype} ${devnum}:${distro_bootpart} " \
>>>> + "${fdt_addr_r} ${prefix}${efi_fdtfile}; " \
>>>> + "if fdt addr ${fdt_addr_r}; then " \
>>>> + "efi_fdt_addr=${fdt_addr_r}; " \
>>>> + "fi;\0" \
>>>> \
>>>> "efi_dtb_prefixes=/ /dtb/ /dtb/current/\0" \
>>>> - "scan_dev_for_efi=" \
>>>> - "setenv efi_fdtfile ${fdtfile}; " \
>>>> + "set_efi_fdt_addr=" \
>>>> + "efi_fdtfile=${fdtfile}; " \
>>>> BOOTENV_EFI_SET_FDTFILE_FALLBACK \
>>>> "for prefix in ${efi_dtb_prefixes}; do " \
>>>> "if test -e ${devtype} " \
>>>> @@ -151,19 +145,26 @@
>>>> "${prefix}${efi_fdtfile}; then " \
>>>> "run load_efi_dtb; " \
>>>> "fi;" \
>>>> - "done;" \
>>>> + "done;\0" \
>>>> + \
>>>> + "scan_dev_for_efi=" \
>>>> "if test -e ${devtype} ${devnum}:${distro_bootpart} " \
>>>> "efi/boot/"BOOTEFI_NAME"; then " \
>>>> "echo Found EFI removable media binary " \
>>>> "efi/boot/"BOOTEFI_NAME"; " \
>>>> + "efi_fdt_addr=${fdtcontroladdr}; " \
>>>> + "if test -n \"${fdtfile}\"; then " \
>>>> + "run set_efi_fdt_addr; " \
>>>> + "fi; " \
>>>> "run boot_efi_binary; " \
>>>> "echo EFI LOAD FAILED: continuing...; " \
>>>> - "fi; " \
>>>> - "setenv efi_fdtfile\0"
>>>> + "fi;\0"
>>>> #define SCAN_DEV_FOR_EFI "run scan_dev_for_efi;"
>>>> +#define BOOT_EFI_BOOT_MANAGER "bootefi bootmgr;"
>>>> #else
>>>> #define BOOTENV_SHARED_EFI
>>>> #define SCAN_DEV_FOR_EFI
>>>> +#define BOOT_EFI_BOOT_MANAGER
>>>> #endif
>>>>
>>>> #ifdef CONFIG_SATA
>>>> @@ -409,6 +410,7 @@
>>>> BOOT_TARGET_DEVICES(BOOTENV_DEV) \
>>>> \
>>>> "distro_bootcmd=" BOOTENV_SET_SCSI_NEED_INIT \
>>>> + BOOT_EFI_BOOT_MANAGER \
>>>
>>> The last-minute change may have introduced a problem.
>>> By moving "bootmgr" from scan_dev_for_efi" to here,
>>> grub fails to start a grub.cfg menu, saying
>>> "error: no such device: /.disk/info."
>>>
>>> Do you have any ideas?
>>
>> I would guess that bootmgr doesn't set the loaded image target correctly
>> and before it just happened to work because there was a load command
>> before the bootmgr command?
>
> The root cause was that efi_init_obj_list(), particularly efi_disk_register(),
> is executed only once.
> In my case, efi bootmgr is called before "usb start" in scan_dev_for_efi,
> and any USB devices will not be added to efi object list forever.
> Therefore, later on, grub itself can start but cannot detect/access its own
> boot device (USB mass storage) via efi interface.
>
> I think we can fix this problem in several ways:
> 1. run all 'device-scanning' commands, like "usb start" and "scsi scan,"
> before calling bootmgr in distro_bootcmd,
This would work, though it's slightly complicated - hm :/.
> 2. modify efi_obj_init_list() to check and register newly-detected devices,
That won't work, because then efibootmgr won't be able to boot from USB, no?
> 3. add a device to efi object list dynamically whenever a 'device-scanning'
> command detects one,
Same here I assume.
> 4. search and check for a device on-the-fly with each efi device path
> (or handle?) specified in efi interface
That won't work either, because we simply don't initialize USB in the
efibootmgr case, so there won't be anything on the fly ;).
>
> What do you think?
I guess one of your options above mentions this and I just missed it,
but I think we'll have to find out what to initialize in the efibootmgr
command based on the device path we're trying to execute and then
initialize that respective subsystem.
So if we see that the device path involves USB, we need to run "usb
start" from within the efibootmgr code.
Alex
More information about the U-Boot
mailing list