Hi, On 20 September 2017 at 08:09, Rob Clark <robdcl...@gmail.com> wrote: > On Wed, Sep 20, 2017 at 5:08 AM, Alexander Graf <ag...@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 <robdcl...@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. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
