[U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices

[Rob Clark]

On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg at jsg.id.au> wrote:
> On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
>> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg at jsg.id.au> wrote:
>> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote:
>> >> This fixes an issue with OpenBSD's bootloader, and I think should also
>> >> fix a similar issue with grub2 on legacy devices.  In the legacy case
>> >> we were creating disk objects for the partitions, but not also the
>> >> parent device.
>> >>
>> >> Reported-by: Jonathan Gray <jsg at jsg.id.au>
>> >> Signed-off-by: Rob Clark <robdclark at gmail.com>
>> >
>> > Thanks for looking into this.  While this lets armv7/bootarm.efi
>> > boot again on cubox-i and bbb it doesn't help rpi3.
>> >
>> > What is the easiest way to get U-Boot to display these paths
>> > to be able to compare the current behaviour to 2017.09?
>> >
>>
>> in grub, there is the lsefi command, not sure if the OpenBSD
>> bootloader has something similar?
>>
>> u-boot implements that device-path to text protocol, so it should be
>> pretty easy to implement something like this if not.
>>
>> BR,
>> -R
>
> With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE)
> is no longer seen.  Is it possible having U-Boot on mmc but directing
> it to load off usb is somehow involved here?

There is no requirement that efi payload and u-boot are on the same
device.  The distro bootcmd stuff will just look for
/efi/boot/bootxyz.efi on all the devices/partitions until it finds
one.

The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE
or MEDIA_DEVICE:CDROM.  What comes before that differs depending on DM
or legacy boards, in the former case we can construct something more
realistic.  Although the bootloader shouldn't really care.

> efi_bootdp obtained from the loaded image protocol
>
> 2017.09
>
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> 78959 bytes read in 76 ms (1013.7 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk sdhci at 7e300000.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> efi_device_path_depth looking for type 4 i=0 type 4
> depth=0
> i=0
> efi_bootdp=Dusbmassstoragelun dp=Dsdhcieblk
> i=1
> efi_bootdp=Dusbmassstoragelun dp=Dusbmassstoragelun
>>> OpenBSD/arm64 BOOTAA64 0.8
> boot>
> booting sd0a:/bsd: 3871708+578596+509352+803952 [283845+96+451968+239920]=0x82f330
>
> git + patch


I assume you are referring to this patch?  It should only add
additional per-partion "disk" objects.  (In UEFI terminology each
partition is a "disk" object.)

BR,
-R

> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> reading efi/boot/bootaa64.efi
> 78959 bytes read in 86 ms (896.5 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk sdhci at 7e300000.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> efi_device_path_depth looking for type 4 i=0 type 1
> efi_device_path_depth looking for type 4 i=1 type 3
> efi_device_path_depth looking for type 4 i=2 type 3
> efi_device_path_depth looking for type 4 i=3 type 3
> efi_device_path_depth no match for type 4
> depth=-1
> i=0
> i=1
> i=2
> i=3
>>> OpenBSD/arm64 BOOTAA64 0.8
> boot>
> cannot open sd0a:/etc/random.seed: Device not configured
> booting sd0a:/bsd: open sd0a:/bsd: Device not configured