External email: U= se caution opening links or attachments

Jeff,

Tom from AMD booked the meeting for SEV discus= sion months ago. I am afraid there is no time for this discussion.

Let=92s try to resolve it in mails.

Firstly, let me rephase the problem and your p= roposed solutions here (subjective + verb + objective). Sunny=92s i= nput is also included. Hope Mike K and others can provide inputs.

Personally, I agree with 2.b. It helps us to g= radually migrate the PlatformBootManagerLib to PlatformBootManager protocol= . Protocol with Revision field helps to reduce the impact to old platforms = with new APIs added.

**Problem:

&nbs= p; Platform requires certain BlockIo/Si= mpleFileSystem/LoadFile instances don=92t cause Boot#### created. It=92s a = need of platform customization.

**Details:

&nbs= p; Boot#### for BlockIo/SimpleFileSyste= m/LoadFile are created by API EfiBootMangerRefreshAllBootOptions(). There a= re 2 places that call this API:

Platform Boot Man= ager calls the API (usually in the full configuration boot path)
UiApp calls the API when= entering =93Boot Manager=94 page and =93Boot Maintenance Manager=94 page.<= /li>

Platform can change= Platform Boot Manager to remove the unneeded Boot#### in case #1.

But platform has no= way to remove the Boot#### created in case #2 .

**Potential solutions:

Update UiApp
1. Define a new PCD and a new event g= roup.

If PCD is TRUE, Ui= App signals the event. Event callback creates the Boot####. Otherwise, EfiB= ootManagerRefreshAllBootOptions() is called.

Add a new PlatformBootManagerLib A= PI (implemented by platform).

UiApp calls the ne= w API instead of EfiBootManagerRefreshAllBootOption. (need to coordinate ro= llout with updates to all platforms).

Add a new protocol (implemented by= platform).

UiApp calls the ne= w protocol if it exists otherwise calls EfiBootManagerRefreshAllBootOption.=

Update EfiBootManagerRefreshAllBoo= tOptions()
1. Add a new library class (implement= ed by platform).

EfiBootManagerRefr= eshAllBootOption() calls the new library class.

Add a new Platf= ormBootManager protocol (implemented by platform).

EfiBootManager= RefreshAllBootOption() calls the new protocol if it exists.

Thanks,

Ray

From: Jeff Brasen <jbrasen@nvidia.com>
Sent: Wednesday, December 11, 2019 4:46 AM
To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Laszlo = Ersek <lersek@redhat.com>; afish@apple.com; discuss@edk2.groups.io Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Jian J &l= t;jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhi= chao <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@= intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

Can= we discuss this at the design meeting this week (12/12)?

&nb= sp;

Thanks,

Jeff

From: Jeff Brasen
Sent: Thursday, November 14, 2019 10:04 AM
To: Ni, Ray <ray.ni@i= ntel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Laszlo Ersek &l= t;lersek@redhat.com>; afish@apple.com <afish@appl= e.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Ji= an J <jian.j.wang@intel.= com>; Wu, Hao A <hao.a.wu@intel.com= >; Gao, Zhichao <zhichao.= gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.c= om>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

Yes, I think that would be good.

Summarizing everything in this thread

Problem: Platform needs to customize the boot op= tions, this can be done for normal boot but the UiApp calls EfiBootManagerRefreshAllBoot= Option in a couple places.

&n= bsp;

Po= tential solutions:

1 = = =96 Define new PCD and event group if PCD is set true then signal event in= stead of calling EfiBootManagerRefreshAllBootOption in UiApp

2 = = =96 Add new function to boot manager library and replace call to EfiBootMa= nagerRefreshAllBootOption in UiApp (need to coordinate rollout with updates= to all platform.

3 = = =96 Add new protocol with new function, if supported call this otherwise c= all EfiBootManagerRefreshAllBootOption as is done now

4 = = =96 For 2/3 use generic function so we don=92t need new APIs for fut= ure expansion

5 = = =96 Update EfiBootManagerRefreshAllBootOption to call platform specific fu= nction.

&n= bsp;

Th= anks,
Jeff

From: Ni, Ray <ray.ni@intel.com>
Sent: Wednesday, November 13, 2019 7:09 PM
To: devel@edk2.groups.io; Jeff Brasen <jbrasen@nvidia.com= >; Laszlo Ersek <lersek@redh= at.com>; afish@apple.com
Cc: Ashish Singhal <a= shishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>= ;; Kinney, Michael D <mich= ael.d.kinney@intel.com>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

Jeff,

I think it=92s a good topic that we could discus= s in the open design meeting.

Are you ok to present the problem you have and d= iscuss the potential solutions in that meeting?

https://github.com/tianocore/tianocore.git= hub.io/wiki/Design-Meeting

Thanks,

Ray

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

Th= inking about this more I think we could do this with a PCD and a new group = event without having to define any new function interfaces.

&n= bsp;

We= could change UiApp and BootManagerMenuApp (and any others that are relevan= t) from

&n= bsp;

Ef= iBootManagerRefreshAllBootOption ();

&n= bsp;

to=

&n= bsp;

if= (FeaturePcdGet (PcdEventBasedRefreshAllBootOptionSupport) {

&n= bsp; EFI_EVENT Event;

&n= bsp; gBS->CreateEventEx ( 0, 0, NULL, NULL, &gEventBasedRefreshGuid,= &Event );

&n= bsp; gBS->SignalEvent (Event);

&n= bsp; gBS->CloseEvent (Event);

} = else {

&n= bsp; EfiBootManagerRefreshAllBootOption ();

}

&n= bsp;

Th= en a platform that wants to do this on its own would just set this pcd and = create a group event and do what it needs to do there.

&n= bsp;

Thanks,

Jeff

From:<= span style=3D"color:black"> Jeff Brasen <jbrasen@nvidia.com>
Sent: Monday, November 11, 2019 5:00 PM
To: Ni, Ray <ray.ni@i= ntel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; Laszlo Ersek &l= t;lersek@redhat.com>; afish@apple.com <afish@appl= e.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Ji= an J <jian.j.wang@intel.= com>; Wu, Hao A <hao.a.wu@intel.com= >; Gao, Zhichao <zhichao.= gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.c= om>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

I = am not sure a PCD would work (unless I am missing something) We do want to = do a connect all and re-enumerate in UiApp but we need the platform code to= be involved in that process.

&n= bsp;

Thanks,

Jeff

From:<= span style=3D"color:black"> Ni, Ray <ray.ni@intel.com>
Sent: Monday, November 11, 2019 4:58 PM
To: devel@edk2.group= s.io <devel@edk2.groups.io>; Jeff= Brasen <jbrasen@nvidia.com= >; Laszlo Ersek <lersek@redha= t.com>; afish@apple.com <afish@appl= e.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Ji= an J <jian.j.wang@intel.= com>; Wu, Hao A <hao.a.wu@intel.com= >; Gao, Zhichao <zhichao.= gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.c= om>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

Jeff,

If adding a PCD to control UiApp can meet the = real needs, I prefer to do in that way instead of adding new APIs to Platfo= rmBootManagerLib.

Thanks,

Ray

From: devel@edk2.groups.io <devel= @edk2.groups.io> On Behalf Of Jeff Brasen
Sent: Tuesday, November 12, 2019 6:58 AM
To: Laszlo Ersek <lersek@re= dhat.com>; Ni, Ray <ray.ni@in= tel.com>; devel@edk2.groups.io; afish@apple.com
Cc: Ashish Singhal <a= shishsingha@nvidia.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>= ;; Kinney, Michael D <mich= ael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

= If we are concerned about deploying this and breaking builds we could do th= is via a new protocol instead. In that case though we would leave the old d= efault behavior in the code to handle platforms that didn't implement the new protocol, so this might not be th= e cleanest way to deploy this.

=

= We could also look at adding a generic platform boot hook function (either = as a library function or protocol) if we wanted to limit the number of disr= uption on new customization hooks. Something like

=

= EFI_STATUS PlatformBootNotify (CONST EFI_GUID *NotificationType, VOID *Cont= extData OPTIONAL)

=

= Where Notification type describes where we are that we want platform to pot= entially handle and ContextData is per type caller allocated data that prov= ides additional in/out data. This has the same issue of leaving the current default behavior in place for unsup= ported types as well as being a less than specific function to describe.

=

Thanks,

Jeff

=

From: Laszlo Ersek <lersek@redhat.com>
Sent: Friday, November 8, 2019 9:37 AM
To: Jeff Brasen <jb= rasen@nvidia.com>; Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io <devel@edk2.groups.io>; afish@apple.com <afish@appl= e.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>; Wang, Ji= an J <jian.j.wang@intel.= com>; Wu, Hao A <hao.a.wu@intel.com= >; Gao, Zhichao <zhichao.= gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.c= om>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enu= meration

On 11/07/19 18:= 46, Jeff Brasen wrote:
> 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 in= tended to do a full enumeration of the system and there may be platform spe= cifics to how that occurs.

Fully agreed -- entering UiApp should expose everything bootable in the system, unless (perhaps) PlatformBootManagerLib specifically thinks
otherwise.

Of course, then we arrive (again) at the problem that a call in
UefiBootManagerLib, to a *new* PlatformBootManagerLib API, will break
tens of out-of-tree platforms. :)

I think that can be prevented, as follows; but it will take quite some tim= e:

- introduce the new function declaration in "PlatformBootManagerLib.h= ",
- modify all platforms (in tree and out of tree) to implement (define)
the new function,
- call the new function from UefiBootManagerLib

For some history / background on this kind of problem, I suggest reading through:

ht= tps://bugzilla.tianocore.org/show_bug.cgi?id=3D982

Thanks,
Laszlo

> From: Ni, Ray <ray.ni@intel.co= m>
> Sent: Thursday, November 7, 2019 12:21 AM
> To: devel@edk2.groups.io;= Jeff Brasen <jbrasen@nvidia.com>; afish@apple.com
> Cc: Ashish Singhal <ash= ishsingha@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.gao@intel.co= m>; Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
> I treat the issue in this way:
>
>   1. Platform Boot Manager library does a good job. I= t doesn't always call RefreshAll() API to auto-create the boot options
>   2. But UiApp doesn't. It constantly call RefreshAll= ().
>
> Do you think that we can fix UiApp instead? For example, introducing = a PCD to control the boot option refresh behavior?
>
> Thanks,
> Ray
>
> From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk= 2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Jeff Brasen
> Sent: Thursday, November 7, 2019 3:02 PM
> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; afish@app= le.com<mailto:afish@apple.com>=
> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Ashish Si= nghal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>= ;>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Wang, Ji= an J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zh= ichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael= .d.kinney@intel.com>>
> Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
> The issue is there are some auto created options we do not want on ou= r platform.
> Get Outlook for Android<https://= aka.ms/ghei36>
>
> ________________________________
> From: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> Sent: Wednesday, November 6, 2019 11:59:31 PM
> To: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>>= ;; afish@apple.com<mailto:afish@apple= .com> <afish@apple.com<mailto:afish@apple.com>>
> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.= groups.io<mailto:devel@edk2.groups.io>>; Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com&g= t;>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com&g= t;>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:m= ichael.d.kinney@intel.com>>
> Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
>
> Jeff,
>
> RefreshAllBootOption() only modifies/creates the auto-created boot op= tions. For the boot options created by platform boot manager library, they = stay with no one touches. And all auto-created boot options are appended in= the end of boot option list (through BootOrder).
>
>
>
> From: Jeff Brasen <jbrasen@nvidia.com<mailto:jbrasen@nvidia.com>&= gt;
> Sent: Thursday, November 7, 2019 12:13 PM
> To: afish@apple.com<mailto:afis= h@apple.com>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>=
> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Ashish Si= nghal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>= ;>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; Wang, Ji= an J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zh= ichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael= .d.kinney@intel.com>>
> Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
>
>
> As the suggestions below made sense, we updated our platform boot man= ager library to behave in this manner and for normal boots everything works= well. However the UiApp and boot maintenance applications in EDK2 also cal= l 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 th= at allows for override of the behavior of BmEnumerateBootOptions? For examp= le, either a function or protocol that takes the same parameters as this fu= nction and only if it returns NULL then we continue to the default enumeration code. Or a function call ins= erted at the end that would modify the load option array after the system d= oes the standard enumeration.
>
>
>
> -Jeff
>
>
>
> From: afish@apple.com<mailto:af= ish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
> Sent: Wednesday, November 6, 2019 9:20 AM
> To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>
> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Jeff Bras= en <jb= rasen@nvidia.com<mailto:jbrasen@nvidia.com>>; Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia= .com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com&g= t;>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com&g= t;>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zhichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com&g= t;>; Mike Kinney <michael.d.kinney@intel.com<mailto:michael= .d.kinney@intel.com>>
> Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
>
>
> 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 page to give some gu= idance on how to customize the BDS.
>
>
>
> Thanks,
>
>
>
> Andrew Fish
>
>
>
> On Nov 5, 2019, at 9:20 PM, Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.co= m>> wrote:
>
>
>
> Andrew,
>
> I agree with your opinion.
>
> It's expected that Platform Boot Manager lib calls EfiBootManagerRefr= eshAllBootOption() only in full configuration boot path.
>
> The full configuration boot path is chosen when hardware changes happ= en. So it's not expected EfiBootManagerRefresh...() be
> called in every boot.
>
> So you could:
>
>   1. Delete the auto-created option pointing to LoadF= ile instance
>   2. Create your own one with customized description.=
>
>
>
>
>
> From: afish@apple.com<mailto:af= ish@apple.com> <afish@apple.com<mailto:afish@apple.com>>
> Sent: Wednesday, November 6, 2019 10:47 AM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; jbrasen@n= vidia.com<mailto:jbrasen@nvidia.co= m>
> Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingh= a@nvidia.com>>; Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.c= om>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; Wang, Jian J <= jia= n.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; Gao, Zh= ichao <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael= .d.kinney@intel.com>>
> Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enume= ration
>
>
>
>
>
>
>
> On Nov 5, 2019, at 7:34 PM, Jeff Brasen <jbrasen@nvidia.com<mailto:jbras= en@nvidia.com>> wrote:
>
>
>
> Wouldn't having a variable that we create and delete on every boot pu= t 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 hi= dden/!active but still match for detection purposes so that it doesn't dele= te 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 basic= ally the same?
>
> What changes every boot that forces the variable to need to get modif= ied?
>
> I would assume the NOR driver is smart enough to not update a variabl= e that is not changing.
>
> The custom BDS could could only create the variable for this device i= f it does not exist.
>
> [JB] The current flow with no changes in the boot manager would be as= follows
>
>
>
>   1. Scan for instance of the boot option in the vari= ables
>   2. It will not be found, so create a new boot optio= n store it to a variable and update BootOrder
>   3. Platform code runs creates the options for the b= oot option it wants and writes those to variable store
>   4. Delete/disable the boot option in the variable s= tore
>
>
>
> 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 i= n BmBoot.c
>
>
>
> If you modify the variable to disable it with hidden/not active it wo= uld 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 w= hen 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 t= hough the patch changed BmEnumerateBootOptions(), so that is going to chang= e 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 s= ure 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 Ma= nager 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 a= nswer is to have the BDS platform specific code write the boot variable. >
>
>
>
>
> [1]
>
> /**
>
>   The function creates boot options for all possible bootab= le medias in the following order:
>
>   1. Removable BlockIo      &= nbsp;     - The boot option only points to the removabl= e media
>
>           &nbs= p;            &= nbsp;            dev= ice, like USB key, DVD, Floppy etc.
>
>   2. Fixed BlockIo       = ;         - The boot option only po= ints to a Fixed blockIo device,
>
>           &nbs= p;            &= nbsp;            lik= e HardDisk.
>
>   3. Non-BlockIo SimpleFileSystem - The boot option points = to a device supporting
>
>           &nbs= p;            &= nbsp;            Sim= pleFileSystem Protocol, but not supporting BlockIo
>
>           &nbs= p;            &= nbsp;            pro= tocol.
>
>   4. LoadFile       &nbs= p;             = - The boot option points to the media supporting
>
>           &nbs= p;            &= nbsp;            Loa= dFile protocol.
>
>   Reference: UEFI Spec chapter 3.3 Boot Option Variables De= fault Boot Behavior
>
>
>
>   The function won't delete the boot option not added by it= self.
>
> **/
>
> 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) a= nd may contain confidential information. Any unauthorized review, use= , disclosure or distribution is prohibited. If you are not the intend= ed recipient, please contact the sender by reply email and destroy all copies of the original message.
>
> ________________________________
>
> >