All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: u-boot@lists.denx.de
Subject: [PATCH] distro_bootcmd: call EFI bootmgr even without having /EFI/boot
Date: Fri, 25 Sep 2020 11:20:47 +0200	[thread overview]
Message-ID: <4504190d8a1892de617a6770f1e87aaa@walle.cc> (raw)
In-Reply-To: <22503A63-A7F9-48A1-8AE6-7A947F7009CA@gmx.de>

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

      reply	other threads:[~2020-09-25  9:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4504190d8a1892de617a6770f1e87aaa@walle.cc \
    --to=michael@walle.cc \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.