Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld"

[Andrew Turner]

> On 25 Mar 2019, at 00:49, Warner Losh <imp at bsdimp.com> wrote:
> 
> On Sun, Mar 24, 2019, 6:20 PM Rebecca Cran <rebecca at bluestop.org <mailto:rebecca at bluestop.org>> wrote:
> 
>> On 3/24/19 5:57 PM, Warner Losh wrote:
>> 
>> 
>> He's asking for stopping doing a make install in src/stand. I'm thinking
>> that's a good thing. We should update the ESP's \efi\freebsd\loader.efi,
>> but leave the\efi\boot\bootXXXX.efi alone as part of this new installloader
>> phase. Again, only if the ESP is mounted, and we have a default spot for
>> it. For this script, I don't think hunting for the ESP is the right way to
>> go... which means we need to define a standard place for the ESP to be
>> mounted, which we should do before we turn on any of these features.
>> 
>> We have the start of a generic script to update things in
>> src/tools/boot/install-boot.sh which was supposed to install boot blocks on
>> everything known to run FreeBSD.
>> 
>> 
>> Only updating \efi\freebsd\loader.efi is the wrong thing to do in my
>> opinion: there are situations like on ARM where EFI variables aren't
>> persistent, and we need \efi\boot\bootxxxx.efi for booting. What we could
>> do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which case we
>> know any changes to BootXXXX variables won't survive a reboot, and we need
>> BOOTxxxx.efi.
>> 
> Systems that don't support variables are a super duper weird special case.
> Let's not let them drive the design. I want to get to (a) a standardized
> mount point and (b) drive people towards having the boot loader be in
> /efi/freebsd/loader.efi. our tooling should reflect that first and
> foremost. The weirdo, special cases that likely won't be updating from
> source are secondary.  Let's get a good design flow down first for the most
> common case, one that encourages the most people to adopt the standard boot
> flow as possible.

Systems that don’t support reading variables are weird, however systems that don’t support writing valuables are common for arm and arm64. The EBBR spec [1] that Arm and others are working on allows both reading and writing variables via the runtime services as optional [2]. This is because these variables may be stored on the same media as the OS.

It would be nice if we could support this case, even if it’s not the default on systems that support setting variables.

Andrew

[1] https://github.com/ARM-software/ebbr
[2] https://github.com/ARM-software/ebbr/blob/v1.0-rc1/source/chapter2-uefi.rst