> On Nov 5, 2019, at 7:34 PM, Jeff Brasen <jbra...@nvidia.com> wrote:
>
>
> Wouldn't having a variable that we create and delete on every boot put
> unnecessary stress on the SPI-NOR that the variable store lives on?
> What about the alternative approach where we allow the platform code to
> modify the attributes of the auto created variable to disable it with
> hidden/!active but still match for detection purposes so that it doesn't
> delete and recreate the modified variable each boot? That way all the logic
> on what to disable can still be in the platform code and all the existing
> logic in the boot manager can stay basically the same?
>
> What changes every boot that forces the variable to need to get modified?
>
> I would assume the NOR driver is smart enough to not update a variable that
> is not changing.
>
> The custom BDS could could only create the variable for this device if it
> does not exist.
>
> [JB] The current flow with no changes in the boot manager would be as follows
>
> Scan for instance of the boot option in the variables
> It will not be found, so create a new boot option store it to a variable and
> update BootOrder
> Platform code runs creates the options for the boot option it wants and
> writes those to variable store
> Delete/disable the boot option in the variable store
>
> When you reboot it won't find the variable so 1/2/4 will re-occur
>
> The code that does this (1/2) is EfiBootManagerRefreshAllBootOption in
> BmBoot.c
>
> If you modify the variable to disable it with hidden/not active it would
> delete that and create a new one as well as the code wouldn't recognize that
> is the same boot option.
>
> If however we modify EfiBootManagerFindLoadOption to not compare the
> attributes (at least allow for differences in active and hidden) then the
> when it refreshes every thing it would see the match and not delete/create a
> new variable in the store and thus we wouldn't have changes every boot.
>
Jeff,
Sorry if I'm a little off on the sequence of things as the platform I work on
day to day has a custom BDS and does not use this library..... I though the
patch changed BmEnumerateBootOptions(), so that is going to change how
EfiBootManagerRefreshAllBootOption() works. I'd also point out the patch as
given is invalid as it changed the behavior of the public library API for
EfiBootManagerRefreshAllBootOption() [1] so for the patch to be valid it would
need to change the comments to reflect the new behavior. This is kind of what
Laszlo's technical debt comment was about.
I think Laszlo advocated having the BDS platform specific code make sure the
boot variables are in the correct state. That should happen before the Boot
Manager code runs, and it is not clear to me why the Boot Manager could would
need to run if you have a valid EFI nvram variable to boot from.
I think the question is how is your use case different than the boot variable
that Windows installs? If it works kind of the same way then the answer is to
have the BDS platform specific code write the boot variable.
[1]
/**
The function creates boot options for all possible bootable medias in the
following order:
1. Removable BlockIo - The boot option only points to the
removable media
device, like USB key, DVD, Floppy etc.
2. Fixed BlockIo - The boot option only points to a Fixed
blockIo device,
like HardDisk.
3. Non-BlockIo SimpleFileSystem - The boot option points to a device
supporting
SimpleFileSystem Protocol, but not
supporting BlockIo
protocol.
4. LoadFile - The boot option points to the media
supporting
LoadFile protocol.
Reference: UEFI Spec chapter 3.3 Boot Option Variables Default Boot Behavior
The function won't delete the boot option not added by itself.
**/
VOID
EFIAPI
EfiBootManagerRefreshAllBootOption (
VOID
);
Thanks,
Andrew Fish
>
> Thanks,
>
> Andrew Fish
>
> Thanks,
>
> Jeff
>
>
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential information. Any unauthorized review, use, disclosure
> or distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message.
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#50040): https://edk2.groups.io/g/devel/message/50040
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]
-=-=-=-=-=-=-=-=-=-=-=-
