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 <[email protected]> >> Signed-off-by: Alexander Graf <[email protected]> > > 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 [email protected]... > efi_disk_register BLK efi_disk_add_dev [email protected], > if_typename=mmc_blk, dev_index=0 offset=0, part=0 > efi_disk_create_partitions efi_disk_add_dev [email protected]:1, > if_typename=mmc_blk, dev_index=0 offset=8192, part=1 > efi_disk_create_partitions efi_disk_add_dev [email protected]: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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
