[U-Boot] [PATCH] efi_loader: Fix partition offsets

[Alexander Graf]

On 07.12.17 08:00, Jonathan Gray wrote:
> On Fri, Dec 01, 2017 at 04:10:33PM +0100, Alexander Graf wrote:
>> Commit 884bcf6f65 (efi_loader: use proper device-paths for partitions) tried
>> to introduce the el torito scheme to all partition table types: Spawn
>> individual disk objects for each partition on a disk.
>>
>> Unfortunately, that code ended up creating partitions with offset=0 which meant
>> that anyone accessing these objects gets data from the raw block device instead
>> of the partition.
>>
>> Furthermore, all the el torito logic to spawn devices for partitions was
>> duplicated. So let's merge the two code paths and give partition disk objects
>> good offsets to work from, so that payloads can actually make use of them.
>>
>> Fixes: 884bcf6f65 (efi_loader: use proper device-paths for partitions)
>> Reported-by: Yousaf Kaukab <yousaf.kaukab at suse.com>
>> Signed-off-by: Alexander Graf <agraf at suse.de>
> 
> This once again broke being able to find a DEVICE_PATH_TYPE_MEDIA_DEVICE
> node with the loaded image protocol on rpi_3 with mmc/usb.

Hooray :). Do you think you could somehow assemble a test that runs
inside Travis-CI to make sure we catch your loader? I still need to do a
better one for grub to ensure that that one's happy too.

> 
> broken
> ## Starting EFI application at 01000000 ...
> Scanning disk sdhci at 7e300000.blk...
> efi_disk_register BLK efi_disk_add_dev name=sdhci at 7e300000.blk, if_typename=mmc_blk, dev_index=0 offset=0, part=0
> efi_disk_create_partitions efi_disk_add_dev name=sdhci at 7e300000.blk:1, if_typename=mmc_blk, dev_index=0 offset=8192, part=1
> efi_disk_create_partitions efi_disk_add_dev name=sdhci at 7e300000.blk:4, if_typename=mmc_blk, dev_index=0 offset=16384, part=4
> Scanning disk usb_mass_storage.lun0...
> efi_disk_register BLK efi_disk_add_dev name=usb_mass_storage.lun0, if_typename=usb_storage_blk, dev_index=0 offset=0, part=0
> efi_disk_create_partitions efi_disk_add_dev name=usb_mass_storage.lun0:1, if_typename=usb_storage_blk, dev_index=0 offset=8192, part=1
> efi_disk_create_partitions efi_disk_add_dev name=usb_mass_storage.lun0:4, if_typename=usb_storage_blk, dev_index=0 offset=40960, part=4
> Found 6 disks
> efi_dp_match a: len 20 type 1 b: len 20 type: 1
> efi_dp_match a: len 20 type 1 b: len 20 type: 1
> efi_dp_match a: len 20 type 1 b: len 20 type: 1
> efi_dp_match a: len 20 type 1 b: len 20 type: 1
> efi_dp_match a: len 11 type 3 b: len 11 type: 3
> efi_dp_match a: len 11 type 3 b: len 11 type: 3
> efi_dp_match a: len 11 type 3 b: len 11 type: 3
> 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 can reproduce this with grub here as well - the device path passed in
via loaded image seems to have something to it that's wrong. I can't
quite figure out what - printing it with our own helpers seems to show a
correct path:

 do_bootefi_exec:
dp=/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Usb(0x6,0x0)/HD(Part1,Sigcb08e82d)

I'll need to dig a bit further into this to understand where things are
going wrong...


Alex