On Thu, Sep 21, 2017 at 12:58 AM, Simon Glass sjg@chromium.org wrote:
Hi,
On 20 September 2017 at 08:09, Rob Clark robdclark@gmail.com wrote:
On Wed, Sep 20, 2017 at 5:08 AM, Alexander Graf agraf@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@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..
BR, -R