[U-Boot] [PATCH v3 15/21] efi_loader: add bootmgr

[Simon Glass]

Hi Rob,

On 21 September 2017 at 08:22, Rob Clark <robdclark at gmail.com> wrote:
> On Thu, Sep 21, 2017 at 12:58 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi,
>>
>> On 20 September 2017 at 08:09, Rob Clark <robdclark at gmail.com> wrote:
>>> On Wed, Sep 20, 2017 at 5:08 AM, Alexander Graf <agraf at suse.de> wrote:
>>>>
>>>>
>>>> On 14.09.17 00:05, Rob Clark wrote:
>>>>>
>>>>> Similar to a "real" UEFI implementation, the bootmgr looks at the
>>>>> BootOrder and BootXXXX variables to try to find an EFI payload to load
>>>>> and boot.  This is added as a sub-command of bootefi.
>>>>>
>>>>> The idea is that the distro bootcmd would first try loading a payload
>>>>> via the bootmgr, and then if that fails (ie. first boot or corrupted
>>>>> EFI variables) it would fallback to loading bootaa64.efi.  (Which
>>>>> would then load fallback.efi which would look for \EFI\*\boot.csv and
>>>>> populate BootOrder and BootXXXX based on what it found.)
>>>>>
>>>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>>>>
>>>>
>>>> Would it make sense to convert the bootmgr into a genuine EFI application
>>>> now that we have Heinrich's test framework available?
>>>>
>>>
>>> I had considered that, but then decided it was nice to be able to use
>>> printf()/malloc()/etc.. plus easier to gdb/debug..
>>>
>>> Maybe at some point it would be worth trying to fixup edk2 build so
>>> some things like this and HII/unicode protocols and maybe a few other
>>> things could be built as standalone .efi drivers and loaded by u-boot.
>>> (Might make sense by the time someone wants a full blown HII "bios
>>> setup menu" ;-))
>>
>> Another advantage of the current approach used by this series is that
>> we can test it with sandbox. With a separate EFI application we would
>> lose that ability.
>>
>
> jfwiw, I do actually have Shell.efi very nearly loading in sandbox..
> it crashes part-way through startup (shortly after reading "ShellOpt"
> variable) and I haven't had a chance to debug further.. but I suspect
> in some form or another having VA != "PA" in sandbox is biting us.
>
> Anyways, getting a bit off topic, but separate .efi in sandbox doesn't
> seem like it should be completely out of the question for sandbox..
> and it would make sandbox *way* more useful for EFI testing, since
> this is really half of the point of efi..

Sounds very promising! The goal for sandbox is to test all U-Boot code
where it is practical to do so.

Regards,
Simon