* [PATCH] distro_bootcmd: call EFI bootmgr even without having /EFI/boot
@ 2020-09-23 21:15 Michael Walle
2020-09-23 22:17 ` Heinrich Schuchardt
0 siblings, 1 reply; 3+ messages in thread
From: Michael Walle @ 2020-09-23 21:15 UTC (permalink / raw)
To: u-boot
Currently, the EFI bootmgr is only called if there is a EFI binary
inside the path for removable media is found, i.e. /EFI/boot/. This
doesn't make sense. It is the duty of the bootmgr to find out the
path and name of the EFI binary to boot. It should be called even
if there is no /EFI/boot directory.
Thus, call the bootmgr before we try to boot the EFI binary inside
the removable media path.
Signed-off-by: Michael Walle <michael@walle.cc>
---
include/config_distro_bootcmd.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index fc0935fa21..c745f115f8 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -123,12 +123,14 @@
#define BOOTENV_SHARED_EFI \
- "boot_efi_binary=" \
+ "boot_efi_bootmgr=" \
"if fdt addr ${fdt_addr_r}; then " \
"bootefi bootmgr ${fdt_addr_r};" \
"else " \
"bootefi bootmgr ${fdtcontroladdr};" \
- "fi;" \
+ "fi\0" \
+ \
+ "boot_efi_binary=" \
"load ${devtype} ${devnum}:${distro_bootpart} " \
"${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; " \
"if fdt addr ${fdt_addr_r}; then " \
@@ -152,6 +154,7 @@
"run load_efi_dtb; " \
"fi;" \
"done;" \
+ "run boot_efi_bootmgr;" \
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then " \
"echo Found EFI removable media binary " \
--
2.20.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [PATCH] distro_bootcmd: call EFI bootmgr even without having /EFI/boot
2020-09-23 21:15 [PATCH] distro_bootcmd: call EFI bootmgr even without having /EFI/boot Michael Walle
@ 2020-09-23 22:17 ` Heinrich Schuchardt
2020-09-25 9:20 ` Michael Walle
0 siblings, 1 reply; 3+ messages in thread
From: Heinrich Schuchardt @ 2020-09-23 22:17 UTC (permalink / raw)
To: u-boot
Am 23. September 2020 23:15:50 MESZ schrieb Michael Walle <michael@walle.cc>:
>Currently, the EFI bootmgr is only called if there is a EFI binary
>inside the path for removable media is found, i.e. /EFI/boot/. This
>doesn't make sense. It is the duty of the bootmgr to find out the
>path and name of the EFI binary to boot. It should be called even
>if there is no /EFI/boot directory.
Yes, UEFI variables indicating the boot binary take precedence. \EFI\boot\ is the fallback.
>
>Thus, call the bootmgr before we try to boot the EFI binary inside
>the removable media path.
>
>Signed-off-by: Michael Walle <michael@walle.cc>
>---
> include/config_distro_bootcmd.h | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>diff --git a/include/config_distro_bootcmd.h
>b/include/config_distro_bootcmd.h
>index fc0935fa21..c745f115f8 100644
>--- a/include/config_distro_bootcmd.h
>+++ b/include/config_distro_bootcmd.h
>@@ -123,12 +123,14 @@
>
>
>#define BOOTENV_SHARED_EFI
> \
>- "boot_efi_binary=" \
>+ "boot_efi_bootmgr=" \
> "if fdt addr ${fdt_addr_r}; then " \
The problem here is that we don't have a clue which device tree we should load to $fdt_addr_r to make this true.
> "bootefi bootmgr ${fdt_addr_r};" \
> "else " \
> "bootefi bootmgr ${fdtcontroladdr};"
Don't pass an fdt address in the else path. Some boards use ACPI. If ACPI is not used we have a fallback logic in cmd/bootefi.c.
Best regards
Heinrich
\
>- "fi;" \
>+ "fi\0" \
>+ \
>+ "boot_efi_binary=" \
> "load ${devtype} ${devnum}:${distro_bootpart} " \
> "${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; " \
> "if fdt addr ${fdt_addr_r}; then " \
>@@ -152,6 +154,7 @@
> "run load_efi_dtb; " \
> "fi;" \
> "done;" \
>+ "run boot_efi_bootmgr;" \
> "if test -e ${devtype} ${devnum}:${distro_bootpart} " \
> "efi/boot/"BOOTEFI_NAME"; then " \
> "echo Found EFI removable media binary " \
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH] distro_bootcmd: call EFI bootmgr even without having /EFI/boot
2020-09-23 22:17 ` Heinrich Schuchardt
@ 2020-09-25 9:20 ` Michael Walle
0 siblings, 0 replies; 3+ messages in thread
From: Michael Walle @ 2020-09-25 9:20 UTC (permalink / raw)
To: u-boot
Am 2020-09-24 00:17, schrieb Heinrich Schuchardt:
> Am 23. September 2020 23:15:50 MESZ schrieb Michael Walle
> <michael@walle.cc>:
>> Currently, the EFI bootmgr is only called if there is a EFI binary
>> inside the path for removable media is found, i.e. /EFI/boot/. This
>> doesn't make sense. It is the duty of the bootmgr to find out the
>> path and name of the EFI binary to boot. It should be called even
>> if there is no /EFI/boot directory.
>
> Yes, UEFI variables indicating the boot binary take precedence.
> \EFI\boot\ is the fallback.
>
>>
>> Thus, call the bootmgr before we try to boot the EFI binary inside
>> the removable media path.
>>
>> Signed-off-by: Michael Walle <michael@walle.cc>
>> ---
>> include/config_distro_bootcmd.h | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/config_distro_bootcmd.h
>> b/include/config_distro_bootcmd.h
>> index fc0935fa21..c745f115f8 100644
>> --- a/include/config_distro_bootcmd.h
>> +++ b/include/config_distro_bootcmd.h
>> @@ -123,12 +123,14 @@
>>
>>
>> #define BOOTENV_SHARED_EFI
>> \
>> - "boot_efi_binary=" \
>> + "boot_efi_bootmgr=" \
>> "if fdt addr ${fdt_addr_r}; then " \
>
> The problem here is that we don't have a clue which device tree we
> should load to $fdt_addr_r to make this true.
The one specified in $fdtfile is loaded in the previous step if it
exists, just like in the removable media case. So I'm not sure I
what you mean.
But that raises the question how does the device tree end up in the
ESP. And I guess there can be only one set of device trees. For example
if you have two different kernel versions installed you'd have two
sets of device trees available, but only one can be put in //ESP/dtb
or //ESP/dtb/current).
>> "bootefi bootmgr ${fdt_addr_r};" \
>> "else " \
>> "bootefi bootmgr ${fdtcontroladdr};"
>
> Don't pass an fdt address in the else path. Some boards use ACPI. If
> ACPI is not used we have a fallback logic in cmd/bootefi.c.
Ok.
-michael
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-09-25 9:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-23 21:15 [PATCH] distro_bootcmd: call EFI bootmgr even without having /EFI/boot Michael Walle
2020-09-23 22:17 ` Heinrich Schuchardt
2020-09-25 9:20 ` Michael Walle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.