Am 2020-09-24 00:17, schrieb Heinrich Schuchardt:
Am 23. September 2020 23:15:50 MESZ schrieb Michael Walle
<[email protected]>:
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 <[email protected]>
---
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
