Hi tdoedline, For the UEFI Redfish design and implementation, please check below links:
* Redfish foundation support: https://github.com/tianocore/edk2/tree/master/RedfishPkg * Redfish application implementation by using RedfishPkg: https://github.com/tianocore/edk2-redfish-client/tree/main/RedfishClientPkg And it seems to me that you are working on PCIe storage device. I would suggest you to check Redfish Device Enablement (RDE): https://www.dmtf.org/dsp/DSP0218 In this way, you don't rely on UEFI BIOS to communicate with BMC. Add @Chang, Abner<mailto:abner.ch...@amd.com> for this Redfish topic. Regards, Nickle ________________________________ From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of tdoedline via groups.io <tdoedline=atto....@groups.io> Sent: Monday, October 21, 2024 9:41 PM To: devel@edk2.groups.io <devel@edk2.groups.io> Subject: [edk2-devel] Exposing Redfish data via HII External email: Use caution opening links or attachments Hi, Let me know if this isn't the correct place to post this, but I was directed here from the Redfish forum. I work for a hardware company that develops storage and network HBAs. We already expose a set of HII configuration utilities for display and modification of settings and health data for our adapters in UEFI. We are looking to add some of these features and functionality to the system's exposed Redfish interface to allow user configuration through additional means. Specifically, we are interested in the section "Bridging HII and Redfish" in the following presentation: uefi.org/sites/default/files/resources/13_Jason_HPE_redfish%20implementation_FINAL.pdf<https://uefi.org/sites/default/files/resources/13_Jason_HPE_redfish%20implementation_FINAL.pdf> In order understand better how this works we attempted to use the DriverSampleDxe in the edk2 as an example of what we should expect to see when something with a REST_STYLE flag is presented to a system. Specifically, looking at examples like the x-UEFI HII options, like this one: #string STR_ONE_OF_PROMPT_X_UEFI #language en-US "x-UEFI HII Option" #language fr-FR "x-UEFI HII Option" #language x-UEFI-ns "xUefiHiiOption" #string STR_ONE_OF_PROMPT_X_UEFI_HELP #language en-US "This is an HII option which has REST_STYLE flag and x-UEFI namespace UNI string associated. This HII option could be configured by either in-band edk2 setup browser or the remote management in out-of-band such as Redfish service. This HII option is configured through EFI_KEYWORD_HANDLER_PROTOCOL." We built and loaded the DriverSampleDxe driver on example servers from three different vendors, and while the HII forms show up correctly in the System Setup when booting the system (including these fields that are flagged as REST_STYLE with help text saying that they should be present in Redfish), nothing new shows up under $(IP)/redfish/v1/Systems/1/Bios. To be clear, what we did was boot to a UEFI shell, load the DriverSampleDxe, exit back to the System Setup to confirm that the HII forms are loaded successfully, then attempted to query the Redfish data looking for additional fields. Is the expected behavior of the sample driver? Is our issue that the information about the BIOS settings has already been queried by / pushed to the BMC, so any changes once we boot to the shell are not reflected in the BMC? Or are we not looking in the correct location for fields that are presented by an add-in driver? Or is this model not really supported for add-in drivers and the REST_STYLE functionality is reserved for drivers present in the system firmware itself? Is there another example or methodology to do what we want to do, which is to populate Redfish data / configuration parameters for our HBAs using our UEFI driver? As a follow-up, we did some more experimentation for this issue and, while we haven't yet figured out what the issue is, maybe someone will have some insight into what we're seeing. The first thing we wanted to confirm was whether the reason data was not showing up under Redfish was because I was loading the sample driver too late in the boot process. To confirm this, we changed to using our own Option ROM instead of the DriverSample, specifically changing some of our HII settings to flag that they were REST_STYLE, as well as added the "x-UEFI-ns" language to them, which is what the sample details. These changes were built into our Option ROM driver so they automatically load on system boot. However, this did not change the behavior on the system and our parameters still do not show up under $(IP)/redfish/v1/Systems/1/Bios (or anywhere else I searched for). Is possible that these settings are pushed to the BMC before any Option ROM drivers are loaded? To confirm that I was building these settings correctly, I created a test application that used the EFI_CONFIG_KEYWORD_HANDLER_PROTOCOL to query parameters in the system by their namespaces. I could see tons of settings in the "x-UEFI" namespace, and the couple that I've presented in the "x-UEFI-ns" namespace. I even see some onboard Option ROM settings (like an Onboard NIC) that show up using the EFI_CONFIG_KEYWORD_HANDLER_PROTOCOL and show up under some /Oem attribute area in the Redfish output (not under the expected System/1/Bios area). However, no matter what I've done I can't see to get any of our settings to show up in the Redfish output. I even changed our namespace to "x-UEFI" as a test, but that didn't do anything. Does anyone have any experience with this? Is this something that System Firmware will do on a case-by-case basis, based on what is expected on the system? Is there a consistent place I should be looking for HII settings flagged in this way, or will that vary based on implementation. I plan on trying a wider variety of platforms to see if this is consistent behavior, but I wanted to make sure what I was doing made sense in the first place. Thank you for any insight into this. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120678): https://edk2.groups.io/g/devel/message/120678 Mute This Topic: https://groups.io/mt/109174504/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
