On 03/29/16 17:32, Michael Brown wrote:
> On 29/03/16 16:20, Laszlo Ersek wrote:
>> recent edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII configuration
>> settings available to OS runtime") seems to trigger an issue between
>> edk2 and iPXE.
>
> Thanks for debugging this!
>
> Is iPXE misbehaving here? At the time that I implemented our HII
> support, the HII_CONFIG_ROUTING_PROTOCOL in EDK2 was so badly broken
> that I couldn't even begin testing with it. (Any attempt to use it,
> with or without iPXE present, would immediately crash with a NULL
> pointer dereference, and the relevant EDK2 code was so confused that I
> couldn't even start to guess what it was trying to do.)
>
>>> gateway=&ip=&netmask=&dns=&dnssl=&domain=&filename=&next-server=&root-path=&keep-san=&skip-san-boot=&hostname=&user-class=&password=&username=&dhcp-server=&priority=&scriptlet=
>>>
>>
>> Note that my only reason for pointing at iPXE is this result string
>> precisely. Namely, I grepped the edk2 source for various tokens in the
>> above (like "scriptlet" and "skip-san-boot"), and came up empty. Then
>> I grepped iPXE for the same tokens, and I found them (in
>> "src/usr/autoboot.c"). I think the function that actually formats the
>> response string in iPXE is efi_snp_hii_extract_config()
>> [src/interface/efi/efi_snp_hii.c].
>
> Yes, that's where we generate it, and that result string is very
> plausible for an unconfigured iPXE SNP instance.
>
> From reading the spec, I can't tell whether what iPXE is doing is
> correct or not. Any input appreciated.
Unfortunately, I can't offer any "enlightenment" off-hand. :(
OVMF does install one -- partly dynamically generated -- HII form as
well. The actual string parsing and formatting is delegated to the
gHiiConfigRouting->ConfigToBlock() and
gHiiConfigRouting->BlockToConfig() functions.
(In the spec, I think these are described under
- EFI_HII_CONFIG_ROUTING_PROTOCOL.BlockToConfig()
- EFI_HII_CONFIG_ROUTING_PROTOCOL.ConfigToBlock()
)
It's been a while... I can only point you to:
$ git log --reverse OvmfPkg/PlatformDxe
Hopefully you'll be able to take away something from those commits...
For example, when the same edk2 machinery calls the ExtractConfig()
function in "OvmfPkg/PlatformDxe/Platform.c", we log (on EFI_D_VERBOSE):
ExtractConfig:
Request="GUID=1cc53572800cab4c87ac3b084a6304b1&NAME=004d00610069006e0046006f0072006d00530074006100740065&PATH=01041400dfc5dcd907405e4390988970935504b27fff0400&OFFSET=0000&WIDTH=0020&OFFSET=0020&WIDTH=0004"
ExtractConfig:
Results="GUID=1cc53572800cab4c87ac3b084a6304b1&NAME=004d00610069006e0046006f0072006d00530074006100740065&PATH=01041400dfc5dcd907405e4390988970935504b27fff0400&OFFSET=0000&WIDTH=0020&VALUE=00000000000000000000000000000000000000000000007400650073006e0055&OFFSET=0020&WIDTH=0004&VALUE=00000000"
In this case, the Request string consists of the following:
- the GUID value is "gOvmfPlatformConfigGuid" (= what we use as the Form
Set GUID),
- NAME is UCS-2 for "MainFormState" (see "name = MainFormState" in
"OvmfPkg/PlatformDxe/PlatformForms.vfr")
- PATH is the binary representation of "mPkgDevicePath" -- see near the
top of "OvmfPkg/PlatformDxe/Platform.c". See also the comment above it,
plus FILE_GUID in "OvmfPkg/PlatformDxe/Platform.inf".
- The OFFSET and WIDTH pairs describe the fields of the MAIN_FORM_STATE
structure (which is the type of MainFormState, see in
"OvmfPkg/PlatformDxe/Platform.h" and
"OvmfPkg/PlatformDxe/PlatformForms.vfr").
The Results string is the same, except for each field interrogated by
the system, the value of that form field is returned (see VALUE=...).
As I wrote above, the transition from Request to Results is implemented
by gHiiConfigRouting->BlockToConfig(), which relies on:
- the Request string,
- the current form state (MainFormState)
as input parameters.
HTH,
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
