Jeff,

RefreshAllBootOption() only modifies/creates the = auto-created boot options. For the boot options created by platform boot ma= nager library, they stay with no one touches. And all auto-created boot opt= ions are appended in the end of boot option list (through BootOrder).

From: Jeff Brasen <jbrasen@nvidia.com&g= t;
Sent: Thursday, November 7, 2019 12:13 PM
To: afish@apple.com; Ni, Ray <ray.ni@intel.com>
Cc: devel@edk2.groups.io; Ashish Singhal <ashishsingha@nvidia.co= m>; Laszlo Ersek <lersek@redhat.com>; Wang, Jian J <jian.j.wang= @intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhic= hao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>=
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

As the suggestions below made sense, we updated o= ur platform boot manager library to behave in this manner and for normal bo= ots everything works well. However the UiApp and boot maintenance applicati= ons in EDK2 also call EfiBootManagerRefreshAllBootOption() when ever a user goes into the menu which will re-create the skipped boot= options with no place for the platform code to intervene.

What about a solution where we add a new Platform= library function that allows for override of the behavior of BmEnumerateBo= otOptions? For example, either a function or protocol that takes the same p= arameters as this function and only if it returns NULL then we continue to the default enumeration code. &nbs= p;Or a function call inserted at the end that would modify the load option = array after the system does the standard enumeration.

-Jeff

From: a= fish@apple.com <afish@apple.com>
Sent: Wednesday, November 6, 2019 9:20 AM
To: Ni, Ray <ray.ni@intel.co= m>
Cc: devel@edk2.groups.io; Jeff Brasen <jbrasen@nvidia.com= >; Ashish Singhal <ash= ishsingha@nvidia.com>; Laszlo Ersek <lersek@redhat.com>; Wang, Jian J <jian.j.wang@int= el.com>; Wu, Hao A <hao.a.w= u@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; Mike Kinney <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

Ray,

Is there an obvious hook point we could point Jef= f and Ashish at?

Long term it would be a good idea to have a Wiki = page to give some guidance on how to customize the BDS.

Thanks,

Andrew Fish

On Nov 5, 2019, at 9:20 PM, Ni, Ray <ray.ni@intel.com> wrote:

Andrew,

I agree with your opinion.

It=A1=AFs expected that Platform Boot Manager lib= calls EfiBootManagerRefreshAllBootOption() only in full configuration boot= path.

The full configuration boot path is chosen when h= ardware changes happen. So it=A1=AFs not expected EfiBootManagerRefresh=A1= =AD() be
called in every boot.

So you could:

Delete the auto-created option pointing to LoadFile instance
Create your own one with customized description.

From: afish@apple.com <= afish@apple.com>
Sent: Wednesday= , November 6, 2019 10:47 AM
To: devel@edk2.groups.io; jbrasen@nvidia.com
Cc: Ashish Sing= hal <ashishsingha@nvidia.com<= /a>>; Laszlo Ersek <lersek@redha= t.com>; Ni, Ray <ray.ni@intel= .com>; Wang, Jian J <jian.j.wang@int= el.com>; Wu, Hao A <hao.a.w= u@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [e= dk2-devel] [PATCH] Support skipping automatic BM enumeration

On Nov 5, 2019, at 7:34 PM, Jeff Brasen <jbrasen@nvidi= a.com> wrote:

Wouldn't having a variable that we create and delete on every boot put unn= ecessary stress on the SPI-NOR that the variable store lives on?
What about the alternative approach where we allow the platform code to mo= dify 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 an= d 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 basic= ally the same?

What changes every boot that forces the variable to need to get modified?<= span class=3D"x_apple-converted-space">

I would assume the NOR driver is smart enough to not update a variable tha= t 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 foll= ows

Scan for instance of the boot option in the variabl= es
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 i= t 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-occ= ur

The code that does this (1/2) is EfiBootManagerRefreshAllB= ootOption 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 rec= ognize that is the same boot option.

If however we modify EfiBootManagerFindLoadOption to not c= ompare 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 w= ouldn't have changes every boot.

Jeff,

Sorry if I'm a little off on the sequence of thin= gs as the platform I work on day to day has a custom BDS and does not use t= his 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 s= hould happen before the Boot Manager code runs, and it is not clear t= o 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 diff= erent 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 t= he 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 &nbs= p; - The boot option only points to a Fixed bloc= kIo device,

= = ; like HardDisk.

3. Non-BlockIo SimpleFileSystem - The boot= option points to a device supporting

= = ; SimpleFileSystem Protocol, but not supporting BlockIo

= = ; protocol.

4. LoadFile &n= bsp; - The boot option points to the med= ia supporting

= = ; LoadFile protocol.

Reference: UEFI Spec chapter 3.3 Boot Opti= on 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 u= nauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contac= t the sender by reply email and destroy all copies of the original message.=