> On Nov 5, 2019, at 3:54 AM, Laszlo Ersek <ler...@redhat.com> wrote:
>
> On 11/05/19 07:15, Andrew Fish via Groups.Io wrote:
>
>> You could also edit any existing variables that point to your Load File to
>> make sure they follow the rules you care about?
>>
>> It is legal from an UEFI spec point of view for a platform to edit the nvram
>> boot variables based on platform boot policy.
>
> Good point; for example OVMF and ArmVirtQemu* do this, with the help of
> QemuBootOrderLib. In essence:
>
> - connect a particular set of devices ("ConnectDevicesFromQemu")
> - if that fails, call EfiBootManagerConnectAll()
>
> - call EfiBootManagerRefreshAllBootOption()
>
> - register UEFI Shell boot option manually
>
> - filter and reorder boot options in a platform specific way
> ("RemoveStaleFvFileOptions", "SetBootOrderFromQemu")
>
> All this happens in PlatformBootManagerAfterConsole().
>
The intent of the EFI Boot Variables was generally for the OS Installer to
write the nvram boot variable with the EFI_LOAD_OPTION (BootXXXX variable name,
XXXX is the UINT16 hex value in BootoOrder) info. The reasons being the EFI
code may not know the path to the OS Loader, or the arguments that should be
passed to the OS Loader.
I'd also point out EFI_LOAD_OPTION.Attributes has LOAD_OPTION_ACTIVE and
LOAD_OPTION_HIDDEN bits that give you more control of how the Boot Manager/BDS
will deal with the existing nvram boot option.
Thanks,
Andrew Fish
> Thanks,
> Laszlo
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#49967): https://edk2.groups.io/g/devel/message/49967
Mute This Topic: https://groups.io/mt/39747302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
