On Aug 28, 2013, at 7:17 AM, Laszlo Ersek <ler...@redhat.com> wrote:
> On 08/28/13 14:52, Laszlo Ersek wrote:
>
>> This filters the UEFI boot option list to those that the user requested
>> via fw_cfg, reorders them, and kills off the (non-requested) rest. UEFI
>> boot options of the form
>>
>>
>> HD(1,800,4e000,87f09d6f-dc40-4eaf-b90b-9c2c7d4ffdb5)File(\EFI\opensuse\grubx64.efi)
>>
>> don't match *any* output from the OFW->UEFI device path translation,
>> hence they are always removed. I assumed that would be no problem, since
>> such (root-less, ie. relative) device paths should be unbootable anyway.
>> Apparently edk2 can boot them nonetheless?
>
> Sigh. Yes, that's the case. See BdsLibBootViaBootOption() in
> "IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c":
>
This form is a special case called out in the UEFI spec. It was requested to
make booting more resilient to minor configuration changes. For example if a
PCI card was removed and then placed in another PCI slot the full device path
would no longer match, but this partial device path would match. So it is
proper UEFIness to boot from a device path that starts with a HD() node,
implementation deferred to the reader....
Thanks,
Andrew Fish
> //
> // If it's Device Path that starts with a hard drive path, append it with
> the front part to compose a
> // full device path
> //
> WorkingDevicePath = NULL;
> if ((DevicePathType (DevicePath) == MEDIA_DEVICE_PATH) &&
> (DevicePathSubType (DevicePath) == MEDIA_HARDDRIVE_DP)) {
> WorkingDevicePath = BdsExpandPartitionPartialDevicePathToFull (
> (HARDDRIVE_DEVICE_PATH *)DevicePath
> );
> if (WorkingDevicePath != NULL) {
> DevicePath = WorkingDevicePath;
> }
> }
>
> The simple StrnCmp() call in Match()
> [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] regresses this logic,
> because it kills the relative devpath -- starting with HD(...) -- before
> it could reach the quoted completion.
>
> I'm not sure how to resolve this -- even in theory. The OpenFirmware
> device paths end *exactly before* the HD() part -- they simply don't
> contain the necessary information. The output of *any* OFW->UEFI
> translation can be matched *only* against the leading UEFI device
> sub-path. Which the HD(...) format currently prepared by efibootmgr
> lacks.
>
> It could be worked around, maybe, by completing the relative devpath
> (with BdsExpandPartitionPartialDevicePathToFull(), see above) before
> matching it against the output of the OFW->UEFI translation.
>
> Laszlo
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
