Fixing UiApp seems reasonable, I do think we would= want a hook to the platform library in here as the enumeration that occurs= in the UiApp is intended to do a full enumeration of the system and there may be platform specifics to how that occurs.

Thanks,

Jeff

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

I treat the issue in this way:

Platform Boot Manager library does a good job. It doesn’t alw= ays call RefreshAll() API to auto-create the boot options=
But UiApp doesn’t. It constantly call RefreshAll().<= /o:p>

Do you think that we can fix UiApp instead? For ex= ample, introducing a PCD to control the boot option refresh behavior?<= /o:p>

Thanks,

Ray

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jeff Brasen
Sent: Thursday, November 7, 2019 3:02 PM
To: Ni, Ray <ray.ni@intel.co= m>; afish@apple.com
Cc: devel@edk2.groups.io; Ashish Singhal <ashishsing= ha@nvidia.com>; Laszlo Ersek <lersek@redhat.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.ga= o@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

The issue= is there are some auto created options we do not want on our platform.

Get Outlook for Android

From: Ni, R= ay <ray.ni@intel.com>
Sent: Wednesday, November 6, 2019 11:59:31 PM
To: Jeff Brasen <jbrasen@n= vidia.com>; afish@apple.com <afish@apple.com>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>;= Ashish Singhal <ashishsingha= @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>; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

Jeff,

RefreshAllBootOption() only modifies/creates the a= uto-created boot options. For the boot options created by platform boot man= ager library, they stay with no one touches. And all auto-created boot opti= ons are appended in the end of boot option list (through BootOrder).

From: Jeff Brasen <jbrasen@nvidia.com>
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 <ashishsing= ha@nvidia.com>; Laszlo Ersek <lersek@redhat.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.ga= o@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 ou= r platform boot manager library to behave in this manner and for normal boo= ts everything works well. However the UiApp and boot maintenance applicatio= ns 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 BmEnumerateBoo= tOptions? For example, either a function or protocol that takes the same pa= rameters 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: af= ish@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 Jeff= and Ashish at?

Long term it would be a good idea to have a Wiki p= age 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’s expected that Platform Boot Manager lib= calls EfiBootManagerRefreshAllBootOption() only in full configuration boot= path.

The full configuration boot path is chosen when ha= rdware changes happen. So it’s not expected EfiBootManagerRefreshR= 30;() 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 Singh= al <ashishsingha@nvidia.com>; Laszlo Ersek <lersek@redhat= .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: [ed= k2-devel] [PATCH] Support skipping automatic BM enumeration

On Nov 5, 2019, at 7:34 PM, Jeff Brasen <jbrasen@nvidia= .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"xapple-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 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-occu= r

The code that does this (1/2) is EfiBootManagerRefreshAllBo= otOption 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 reco= gnize that is the same boot option.

If however we modify EfiBootManagerFindLoadOption to not co= mpare 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 thing= s as the platform I work on day to day has a custom BDS and does not use th= is library..... I though the patch changed BmEnumerateBootOptions(), s= o 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. <= /p>

I think Laszlo advocated having the BDS platform s= pecific code make sure the boot variables are in the correct state. That sh= ould 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 diffe= rent 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 th= e boot variable.

[1]

/**

The function creates boot options for all p= ossible bootable medias in the following order:

1. Removable BlockIo &= nbsp; - The boot option only points to the removable media

&= nbsp; = device, like USB key, DVD, Floppy etc.

2. Fixed BlockIo = ; - The boot option only points to a Fixed block= Io device,

&= nbsp; = like HardDisk.

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

&= nbsp; = SimpleFileSystem Protocol, but not supporting BlockIo

&= nbsp; = protocol.

4. LoadFile &nb= sp; - The boot option points to the medi= a supporting

&= nbsp; = LoadFile protocol.

Reference: UEFI Spec chapter 3.3 Boot Optio= n Variables Default Boot Behavior

The function won't delete the boot option n= ot 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 in= tended recipient(s) and may contain confidential information. Any una= uthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact t= he sender by reply email and destroy all copies of the original message.