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

[Mark Kettenis]

> 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.

Cheers,

Mark