[U-Boot] [PATCH 1/5] efi_loader: bootmgr: support BootNext and BootCurrent variable behavior
Alexander Graf
agraf at suse.de
Wed Dec 26 21:23:02 UTC 2018
On 25.12.18 10:36, AKASHI Takahiro wrote:
> On Sun, Dec 23, 2018 at 03:03:51AM +0100, Alexander Graf wrote:
>>
>>
>> On 18.12.18 06:02, AKASHI Takahiro wrote:
>>> See UEFI v2.7, section 3.1.2 for details of the specification.
>>>
>>> With my efishell command[1], you can try as the following:
>>> => efi boot add 1 SHELL ...
>>> => efi boot add 2 HELLO ...
>>> => efi boot order 1 2
>>> => efi bootmgr
>>> (starting SHELL ...)
>>> => efi setvar BootNext =H0200
>>> => efi bootmgr
>>> (starting HELLO ...)
>>> => efi dumpvar
>>> <snip ...>
>>> BootCurrent: {boot,run}(blob)
>>> 00000000: 02 00 ..
>>> BootOrder: {boot,run}(blob)
>>> 00000000: 01 00 02 00 ....
>>>
>>> Using "run -e" would be more human-friendly, though.
>>>
>>> [1] https://lists.denx.de/pipermail/u-boot/2018-November/346450.html
>>>
>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi at linaro.org>
>>> ---
>>> lib/efi_loader/efi_bootmgr.c | 37 +++++++++++++++++++++++++++++++++++-
>>> 1 file changed, 36 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
>>> index a095df3f540b..a54ae28343ce 100644
>>> --- a/lib/efi_loader/efi_bootmgr.c
>>> +++ b/lib/efi_loader/efi_bootmgr.c
>>> @@ -145,11 +145,21 @@ static void *try_load_entry(uint16_t n, struct efi_device_path **device_path,
>>> efi_deserialize_load_option(&lo, load_option);
>>>
>>> if (lo.attributes & LOAD_OPTION_ACTIVE) {
>>> + u32 attributes;
>>> efi_status_t ret;
>>>
>>> debug("%s: trying to load \"%ls\" from %pD\n",
>>> __func__, lo.label, lo.file_path);
>>>
>>> + attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
>>> + EFI_VARIABLE_RUNTIME_ACCESS;
>>> + size = sizeof(n);
>>> + ret = rs->set_variable(L"BootCurrent",
>>> + (efi_guid_t *)&efi_global_variable_guid,
>>> + attributes, size, &n);
>>
>> Every call into UEFI land (rs->foo(), bs->foo(), etc) has to go via the
>> EFI_CALL() macro. Otherwise we may destroy the "gd" pointer on ARM.
>
> OK, but let me make sure one thing:
> My efishell calls efi_* functions directly in some places as
> Not all the features can be implemented only with boot/runtime services.
> In those cases, we don't have to use EFI_CALL(), right?
If your "efishell" is a UEFI binary, you can directly call boot/runtime
services. If it runs as part of the U-Boot code base, every call to
boot/runtime service callbacks *must* go through EFI_CALL().
Alex
More information about the U-Boot
mailing list