[U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions

[Rob Clark]

On Fri, Aug 4, 2017 at 4:41 PM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>> From: Rob Clark <robdclark at gmail.com>
>> Date: Fri,  4 Aug 2017 15:31:55 -0400
>
> Hi Rob,
>
> OpenBSD has been an early adopter of efi_loader and pretty much
> completely relies on it for booting OpenBSD/armv7 and OpenBSD/arm64.
> We use our own bootloader which is fairly lightweight.  Obviously we'd
> like to keep it working if this patchset gets adopted.  We don't make
> use of EFI variables and don't really plan to make use of them on our
> ARM platforms.  But obviously we have to deal with device paths...
>
>> Also, create disk objects for the disk itself, in addition to the
>> partitions.  (UEFI terminology is a bit confusing, a "disk" object is
>> really a partition.)  This helps grub properly identify the boot device
>> since it is trying to match up partition "disk" object with it's parent
>> device.
>>
>> Now instead of seeing devices like:
>>
>>   /File(sdhci at 07864000.blk)/EndEntire
>>   /File(usb_mass_storage.lun0)/EndEntire
>>
>> You see:
>>
>>   /ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire
>>   /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c00000000,1,1)/EndEntire
>>   /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,200000,dd904a8c00000000,1,1)/EndEntire
>>   /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c00000000,1,1)/EndEntire
>>   /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire
>>   /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,60000,38ca680200000000,1,1)/EndEntire
>>   /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca680200000000,1,1)/EndEntire
>>   /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca680200000000,1,1)/EndEntire
>>   /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca680200000000,1,1)/EndEntire
>>
>> This is on a board with single USB disk and single sd-card.  The
>> UnknownMessaging(1d) node in the device-path is the MMC device,
>> but grub_efi_print_device_path() hasn't been updated yet for some
>> of the newer device-path sub-types.
>
> ..and what you're sketching out here should work with recent enough
> versions of our bootloader.
>
> However, to me having an ACPI Device Path component in there doesn't
> make much sense on a board without ACPI.  It certainly doesn't help
> mapping a boot path back to an actual hardware device.  Wouldn't it be
> more logical to a Hardware Device Path there instead?  In particular a
> Memory Mapped Device Path would make a lot of sense as the start
> address would make it fairly easy to do the mapping.
>

It was pretty much an arbitrary choice, and it wouldn't be hard to
change.  From my reading of the grub code, all it really cares about
is that there is *some* parent of the "partition" HD device.  I'm not
really sure what maps best in a UEFI world to the "soc" node in a
device tree world.  I'm certainly open to changing this.

It would be cool if you have a chance to give this a try w/ OpenBSD
and let me know if you run into issues.  I want this to be something
that works across-distro so I'll try to help as much as I can.  (Not
sure if there is an OpenBSD port for db410c, but I guess there is
always qemu..).  Fwiw, if git pull/cherry-pick is easier than grabbing
patches from list, then [1].

[1] https://github.com/robclark/u-boot/commits/enough-uefi-for-shim

BR,
-R