From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id DF593740039 for ; Wed, 23 Oct 2024 17:00:15 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=2xE3FlZtIN//0IHCHYHw9K//DRhFFUPYLYAjJiXWn18=; c=relaxed/simple; d=groups.io; h=Subject:To:From:User-Agent:MIME-Version:Date:Message-ID:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20240830; t=1729702815; v=1; x=1729962014; b=ZDr1A/0Gx+gyiOMePqP7T0VJGHONZnuc/2W/RGo++0f7EuQ6Mal5dpTAVTRz4nl5g6LihOi4 XcQGTp07FNqB20zKor3rJtTc4rfMyEfLCvpKhp0yRTeQPnPLakiLYWTL5CdKGGIKfuJm8Q0UvnV LF+SV4NQ0KAngf5Q8WLzuI05jKPDqKfv6BxNRgr2dVRYe1FfDPqtZVJW7UZdypETG8SSrpVtmBG DT+ZYp4Ihck0gSu2aLTZdQ2E61VJphlrKdan+xFRtQztEmNl3EuvBm87BT1F5gvxpUeS39u98a5 IrCm9T/w4rAet4Ddg4D0tQJiMkMl+50edfWctcwexXt8A== X-Received: by 127.0.0.2 with SMTP id yk95YY7687511x9XXDtwdbSN; Wed, 23 Oct 2024 10:00:14 -0700 Subject: [edk2-devel] Exposing Redfish data via HII To: devel@edk2.groups.io From: "tdoedline via groups.io" X-Originating-Location: Lockport, New York, US (208.69.85.34) X-Originating-Platform: Windows Firefox 131 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Mon, 21 Oct 2024 06:41:25 -0700 Message-ID: Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,tdoedline@atto.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: x7KBs3cfCh0bGi6puMDVStx4x7686176AA= Content-Type: multipart/alternative; boundary="mFaE4HBmdUmw1PoRw2me" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b="ZDr1A/0G"; dmarc=pass (policy=none) header.from=groups.io; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io --mFaE4HBmdUmw1PoRw2me Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Let me know if this isn't the correct place to post this, but I was directe= d here from the Redfish forum.=C2=A0 I work for a hardware company that dev= elops storage and network HBAs. We already expose a set of HII configuratio= n utilities for display and modification of settings and health data for ou= r adapters in UEFI.=C2=A0 We are looking to add some of these features and = functionality to the system's exposed Redfish interface to allow user confi= guration through additional means.=C2=A0 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%20implementatio= n_FINAL.pdf ( https://uefi.org/sites/default/files/resources/13_Jason_HPE_r= edfish%20implementation_FINAL.pdf ) In order understand better how this works we attempted to use the DriverSam= pleDxe in the edk2 as an example of what we should expect to see when somet= hing with a REST_STYLE flag is presented to a system.=C2=A0 Specifically, l= ooking 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 optio= n which has REST_STYLE flag and x-UEFI namespace UNI string associated. Thi= s HII option could be configured by either in-band edk2 setup browser or th= e 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 thre= e different vendors, and while the HII forms show up correctly in the Syste= m 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.=C2=A0 To be cle= ar, what we did was boot to a UEFI shell, load the DriverSampleDxe, exit ba= ck to the System Setup to confirm that the HII forms are loaded successfull= y, then attempted to query the Redfish data looking for additional fields. Is the expected behavior of the sample driver?=C2=A0 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?=C2=A0 Or are we not looking in the correct location for fields that a= re presented by an add-in driver?=C2=A0 Or is this model not really support= ed for add-in drivers and the REST_STYLE functionality is reserved for driv= ers present in the system firmware itself?=C2=A0 Is there another example o= r 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 sh= owing up under Redfish was because I was loading the sample driver too late= in the boot process.=C2=A0 To confirm this, we changed to using our own Op= tion 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-n= s" language to them, which is what the sample details. These changes were b= uilt into our Option ROM driver so they automatically load on system boot.= =C2=A0 However, this did not change the behavior on the system and our para= meters still do not show up under $(IP)/redfish/v1/Systems/1/Bios (or anywh= ere 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 a= pplication that used the EFI_CONFIG_KEYWORD_HANDLER_PROTOCOL to query param= eters in the system by their namespaces. I could see tons of settings in th= e "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 NI= C) that show up using the EFI_CONFIG_KEYWORD_HANDLER_PROTOCOL and show up u= nder 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 na= mespace to "x-UEFI" as a test, but that didn't do anything. Does anyone have any experience with this? Is this something that System Fi= rmware will do on a case-by-case basis, based on what is expected on the sy= stem?=C2=A0 Is there a consistent place I should be looking for HII setting= s flagged in this way, or will that vary based on implementation.=C2=A0 I p= lan on trying a wider variety of platforms to see if this is consistent beh= avior, but I wanted to make sure what I was doing made sense in the first p= lace. Thank you for any insight into this. -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120670): https://edk2.groups.io/g/devel/message/120670 Mute This Topic: https://groups.io/mt/109174504/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --mFaE4HBmdUmw1PoRw2me Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi,
 
Let me know if this isn't the correct place to post this, but I was di= rected here from the Redfish forum.  I work for a hardware company tha= t develops storage and network HBAs. We already expose a set of HII configu= ration utilities for display and modification of settings and health data f= or 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 interest= ed in the section "Bridging HII and Redfish" in the following presentation:=
 
 
 
In order understand better how this works we attempted to use the Driv= erSampleDxe 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.  Specifical= ly, 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 O= ption"
#language x-UEFI-ns "xUefiHiiOption"
#string STR_ONE_OF_PR= OMPT_X_UEFI_HELP #language en-US "This is an HII option which has REST_STYL= E 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 i= n out-of-band such as Redfish service. This HII option is configured throug= h 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 flagg= ed as REST_STYLE with help text saying that they should be present in Redfi= sh), nothing new shows up under $(IP)/redfish/v1/Systems/1/Bios.  To b= e clear, what we did was boot to a UEFI shell, load the DriverSampleDxe, ex= it back to the System Setup to confirm that the HII forms are loaded succes= sfully, then attempted to query the Redfish data looking for additional fie= lds.

Is the expected behavior of the sample driver?  Is our= issue that the information about the BIOS settings has already been querie= d 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 f= or fields that are presented by an add-in driver?  Or is this model no= t really supported for add-in drivers and the REST_STYLE functionality is r= eserved for drivers present in the system firmware itself?  Is there a= nother example or methodology to do what we want to do, which is to populat= e Redfish data / configuration parameters for our HBAs using our UEFI drive= r?
 
 
As a follow-up, we did some more experimentation for this issue and, w= hile 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 n= ot 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 o= wn Option ROM instead of the DriverSample, specifically changing some of ou= r HII settings to flag that they were REST_STYLE, as well as added the "x-U= EFI-ns" language to them, which is what the sample details. These changes w= ere built into our Option ROM driver so they automatically load on system b= oot.  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 a= nywhere 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 t= est 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-UEF= I-ns" namespace. I even see some onboard Option ROM settings (like an Onboa= rd 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 exp= ected 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 o= ur namespace to "x-UEFI" as a test, but that didn't do anything.
 
Does anyone have any experience with this? Is this something that Syst= em Firmware will do on a case-by-case basis, based on what is expected on t= he system?  Is there a consistent place I should be looking for HII se= ttings 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 consisten= t behavior, but I wanted to make sure what I was doing made sense in the fi= rst place.

Thank you for any insight into this.
_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#120670) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--mFaE4HBmdUmw1PoRw2me--