On 26.12.18 22:33, Heinrich Schuchardt wrote: > On 12/26/18 10:23 PM, Alexander Graf wrote: >> >> >> 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.aka...@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(). > > No, that is not how the call counting has been set up. You will get an > assert error if debugging is enabled. We use EFI_CALL when we want to > call an API function from inside an API function.
Ah, true. I stand corrected. > Just have a look at all the selftest code. It never uses EFI_CALL. > > In this respect the bootmgr code is broken. Yes. Maybe this calls for a few travis checks with debugging enabled? Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot