Jeshua,
I did ask my team how we have incorporated IPMI boot features into BDS.
There are two main points.
1. The BDS you see in edk2 is very rarely used as is for commercial
products. In fact, most PC class systems and servers have a lot of
customization in the BDS.
2. The BDS you see in edk2 has no concept of "generic boot options".
IPMI basically says I want to boot some "generic" thing like HDD. Some
platform code has to convert HDD into something real that the BDS/UEFI
system can actually boot. For example in Project Mu we have a BDS with
a concept of generic platform boot options. These boot options actually
just boot a platform defined firmware application which then can
interpret the "generic" request and runs a platform defined algorithm
for finding something bootable. Using the HDD example, it would
connect the storage drivers (say NVME Dxe driver) and then enumerate
each of storage device found in a defined order and look for a
efi/boot{arch} file. This would then allow the IPMI defined generic
options to actually convert into a boot path that BDS could use.
Regarding the handling of BootNext specifically this is modified as part
of the larger overhaul to the BDS and its relevant libraries/APIs.
My expectation is this doesn't really help you with your current problem
but might give some context as to why this functionality isn't
integrated in the edk2 BDS and you haven't got a lot of feedback from
the mailing list. If interested I can provide more info on our BDS in
Project Mu and reference platform bds implementation used here
microsoft/mu_tiano_platforms: Project Mu Virtual Platform Firmware
(github.com) <https://github.com/microsoft/mu_tiano_platforms>
Thanks
Sean
On 1/10/2023 7:53 AM, Jeshua Smith via groups.io wrote:
Any input on this?
It seems that the current behavior isn’t ideal:
* If BootNext is already set when PlatformBootManagerLib APIs are
called, a new BootNext value from the PlatformBootManagerLib code
will be *ignored* (because the original value is cached before the
APIs have a chance to set it) and then deleted (when the cached
value is consumed after the APIs have been called)
* If BootNext is not already set, then the current boot will not be
affected by the BootNext value that PlatformBootManagerLib API
code sets (because there was no value when the value was cached),
but the *subsequent* boot will boot with the BootNext value set by
the APIs during the current boot (because not having a cached
value skips the deletion of BootNext).
To me this seems inconsistent and confusing.
*From:* devel@edk2.groups.io <devel@edk2.groups.io> *On Behalf Of
*Jeshua Smith via groups.io
*Sent:* Tuesday, January 3, 2023 11:32 AM
*To:* devel@edk2.groups.io
*Cc:* Zhichao Gao <zhichao....@intel.com>; Ray Ni <ray...@intel.com>
*Subject:* [edk2-devel] How to select boot device for current boot in
response to IPMI System Boot Options commands?
*External email: Use caution opening links or attachments*
Happy New Year!
I’m trying to figure out the proper place to add code to allow the EFI
boot code to respond to the IPMI System Boot Options request to boot a
device on the current boot. My initial thought was to change BootNext
in the PlatformBootManagerLib APIs, but based on the comment
https://www.mail-archive.com/edk2-devel@lists.01.org/msg30378.html it
looks like that is **intentionally** unsupported. Does anyone know why
we want to avoid PlatformBootManagerLib hooks from being able to set
BootNext to control what gets booted on the current boot? Is there an
intended alternative way to support the IPMI System Boot Options
Command request to use a boot device for the current boot?
Thanks,
Jeshua Smith
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98255): https://edk2.groups.io/g/devel/message/98255
Mute This Topic: https://groups.io/mt/96034184/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
