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

[Jonathan Gray]

On Tue, Nov 21, 2017 at 04:59:33PM +1100, Jonathan Gray wrote:
> On Sat, Nov 18, 2017 at 03:25:29PM +1100, Jonathan Gray wrote:
> >
> > While U-Boot 2017.11 release works with vexpress/qemu with the
> > efi loader it is broken on at least rpi_3 and tinker-rk3288.
> > MEDIA_DEVICE is not found again.
> 
> The loaded image paths look like the below.
> 
> vexpress and qemu_arm (virt) have a MEDIA_DEVICE, rpi_3 and
> tinkerboard do not.
> 
> Having boot_targets load bootarm.efi from mmc on rpi_3 works but having
> it load from usb does not.

The following efi_dp_match call should match but doesn't as two bytes in
the dp path nodes differ.

Forcing this to match returns the correct dp with a MEDIA_DEVICE and allows
the system to boot.

This turns out to be the partition_signature.  It is uninitialised memory.
The diff below to zero that part of the device path node fixes the
comparison.

find_obj efi_dp_match
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/USBClass(781,5581,0,0,0)/HD(Part0,MBRType=01,SigType=00)
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/USBClass(781,5581,0,0,0)/HD(Part0,MBRType=01,SigType=00)
efi_dp_match depth 0 alen 20 blen 20
efi_dp_match A
01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8
28 f3 62 8b 
efi_dp_match B
01 04 14 00 b9 73 1d e6 84 a3 cc 4a ae ab 82 e8
28 f3 62 8b 
efi_dp_match depth 1 alen 11 blen 11
efi_dp_match A
03 0f 0b 00 00 00 00 00 09 00 00 
efi_dp_match B
03 0f 0b 00 00 00 00 00 09 00 00 
efi_dp_match depth 2 alen 11 blen 11
efi_dp_match A
03 0f 0b 00 24 04 14 95 09 00 02 
efi_dp_match B
03 0f 0b 00 24 04 14 95 09 00 02 
efi_dp_match depth 3 alen 11 blen 11
efi_dp_match A
03 0f 0b 00 81 07 81 55 00 00 00 
efi_dp_match B
03 0f 0b 00 81 07 81 55 00 00 00 
efi_dp_match depth 4 alen 42 blen 42
efi_dp_match A
04 01 2a 00 00 00 00 00 00 20 00 00 00 00 00 00
00 80 00 00 00 00 00 00 15 55 55 55 55 55 d5 c1
55 55 51 55 55 45 51 55 01 00 
efi_dp_match B
04 01 2a 00 00 00 00 00 00 20 00 00 00 00 00 00
00 80 00 00 00 00 00 00 57 15 05 15 55 55 55 50
d5 55 55 55 55 55 50 75 01 00

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index f6e368e029..8045532a29 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -431,6 +431,9 @@ static void *dp_part_fill(void *buf, struct blk_desc *desc, 
int part)
if (hddp->signature_type != 0)
memcpy(hddp->partition_signature, >guid_sig,
   sizeof(hddp->partition_signature));
+   else
+   memset(hddp->partition_signature, 0,
+  sizeof(hddp->partition_signature));
 
buf = [1];
}
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Jonathan Gray]

On Sat, Nov 18, 2017 at 03:25:29PM +1100, Jonathan Gray wrote:
>
> While U-Boot 2017.11 release works with vexpress/qemu with the
> efi loader it is broken on at least rpi_3 and tinker-rk3288.
> MEDIA_DEVICE is not found again.

The loaded image paths look like the below.

vexpress and qemu_arm (virt) have a MEDIA_DEVICE, rpi_3 and
tinkerboard do not.

Having boot_targets load bootarm.efi from mmc on rpi_3 works but having
it load from usb does not.

vexpress
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on mmc...
efi_disk_add_dev: name: mmc0 if_typename: mmc part: 1
efi_disk_add_dev: name: mmc0 if_typename: mmc part: 4
efi_disk_add_dev: name: mmc0 if_typename: mmc part: 0
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 1 disks
reading efi/boot/bootarm.efi
67436 bytes read in 45 ms (1.4 MiB/s)
## Starting EFI application at a0008000 ...
efi_setup_loaded_image: device_path: 
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Usb(0x6,0x0)/HD(Part0,MBRType=01,SigType=00)
efi_setup_loaded_image: file_path /\efi\boot\bootarm.efi

=> dm tree
Unknown command 'dm' - try 'help'

=> part list mmc 0

Partition Map for MMC device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 20484096-01 0c Boot
  4 614430720   -04 a6

qemu_arm
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disk ahci_scsi.id0lun0...
efi_disk_add_dev: name: ahci_scsi.id0lun0 if_typename: scsi_blk part: 1
efi_disk_add_dev: name: ahci_scsi.id0lun0 if_typename: scsi_blk part: 4
efi_disk_add_dev: name: ahci_scsi.id0lun0 if_typename: scsi_blk part: 0
Found 1 disks
reading efi/boot/bootarm.efi
67436 bytes read in 9 ms (7.1 MiB/s)
## Starting EFI application at 4040 ...
efi_setup_loaded_image: device_path: 
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/HD(Part0,MBRType=01,SigType=00)
efi_setup_loaded_image: file_path /\efi\boot\bootarm.efi

=> dm tree
 Class  Probed  Driver  Name

 root   [ + ]   root_drive  root_driver
 simple_bus [   ]   generic_si  |-- platform@c00
 pci[ + ]   pci_generi  |-- pcie@1000
 pci_generi [   ]   pci_generi  |   |-- pci_0:0.0
 pci_generi [   ]   pci_generi  |   |-- pci_0:1.0
 ahci   [   ]   ahci_pci|   `-- ahci_pci
 scsi   [   ]   ahci_scsi   |   `-- ahci_scsi
 serial [ + ]   serial_pl0  |-- pl011@900
 firmware   [   ]   psci`-- psci
 sysreset   [   ]   psci-sysre  `-- psci-sysreset

=> part list scsi 0

Partition Map for SCSI device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 20484096-01 0c Boot
  4 614430720   -04 a6

rpi3
U-Boot> printenv boot_targets
boot_targets=usb0 mmc0 pxe dhcp

## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 1
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 4
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 0
Scanning disk usb_mass_storage.lun0...
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 1
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 4
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 0
Found 2 disks
efi_setup_loaded_image: device_path: 
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/USBClass(781,5581,0,0,0)/HD(Part0,MBRType=01,SigType=00)
efi_setup_loaded_image: file_path /\efi\boot\bootaa64.efi

U-Boot> printenv boot_targets
boot_targets=mmc0 usb0 pxe dhcp

mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
78623 bytes read in 31 ms (2.4 MiB/s)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 1
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 4
efi_disk_add_dev: name: sd...@7e30.blk if_typename: mmc_blk part: 0
Scanning disk usb_mass_storage.lun0...
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 1
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 4
efi_disk_add_dev: name: usb_mass_storage.lun0 if_typename: usb_storage_blk 
part: 0
Found 2 disks
efi_setup_loaded_image: device_path: 
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MMC(Slot0)/HD(Part0,MBRType=01,SigType=00)
efi_setup_loaded_image: file_path /\efi\boot\bootaa64.efi

U-Boot> dm tree
 Class  Probed  Driver  Name

 root   [ + ]   root_drive  root_driver
 simple_bus [ + ]   generic_si  |-- soc
 gpio   [ + ]   gpio_bcm28  |   

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

[Jonathan Gray]

On Tue, Oct 10, 2017 at 04:48:01AM +1100, Jonathan Gray wrote:
> On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote:
> > On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray  wrote:
> > > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
> > >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
> > >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> > >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  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  
> > >> >> >> 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 
> > >> >> >> >> Signed-off-by: Rob Clark 
> > >> >> >> >
> > >> >> >> > 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.
> > >> >
> > >> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
> > >> > in master only gives types of 1 (Hardware Device Path) and
> > >> > 3 (Messaging Device Path).
> > >> >
> > >> > It is DM in this case:
> > >>
> > >> Possibly something weird with your partition table?  In
> > >> efi_disk_register() it should create objects for the disk itself
> > >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
> > >> partition (part>=1, which would have same dp as the disk but
> > >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
> > >>
> > >> If part_get_info() fails for part==1 then you won't get any of the
> > >> partition devices.  I suppose this could happen if you an unknown
> > >> partition table type, or u-boot is not built w/ the correct partition
> > >> driver.
> > >>
> > >> BR,
> > >> -R
> > >
> > > It is partitioned mbr style.
> > >
> > > U-Boot> part list mmc 0
> > >
> > > Partition Map for MMC device 0  --   Partition Type: DOS
> > >
> > > PartStart SectorNum Sectors UUIDType
> > >   1 81928192-01 0c Boot
> > >   4 16384   26624   -04 a6
> > > U-Boot> part list usb 0
> > 
> > perhaps jumping from partition #1 to #4 is what is confusing things
> > here?  It's possible you end up with a partition "diskobj" for
> > partition #1 but not #4?
> > 
> > Try adding a print in efi_disk_register() and see how many times we go
> > thru the while(!part_get_info()) loop.
> 
> Indeed, it seems to only end up calling efi_disk_add_dev() for
> part 1 in that loop:
> 
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 1
> ## Valid DOS partition found ##
> Scanning disk usb_mass_storage.lun0...
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 1
> ## Valid DOS partition found ##
> Found 2 disks
> 
> If I change the code there to match other callers of part_get_info()
> I get a MEDIA_DEVICE type and can boot.
> 
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> ## Valid DOS partition found ##
> efi_disk_register 

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

[Peter Robinson]

On Mon, Oct 9, 2017 at 7:20 PM, Rob Clark  wrote:
> On Mon, Oct 9, 2017 at 1:48 PM, Jonathan Gray  wrote:
>> On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote:
>>> On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray  wrote:
>>> > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
>>> >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>>> >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>>> >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  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  
>>> >> >> >> 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 
>>> >> >> >> >> Signed-off-by: Rob Clark 
>>> >> >> >> >
>>> >> >> >> > 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.
>>> >> >
>>> >> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>>> >> > in master only gives types of 1 (Hardware Device Path) and
>>> >> > 3 (Messaging Device Path).
>>> >> >
>>> >> > It is DM in this case:
>>> >>
>>> >> Possibly something weird with your partition table?  In
>>> >> efi_disk_register() it should create objects for the disk itself
>>> >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
>>> >> partition (part>=1, which would have same dp as the disk but
>>> >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
>>> >>
>>> >> If part_get_info() fails for part==1 then you won't get any of the
>>> >> partition devices.  I suppose this could happen if you an unknown
>>> >> partition table type, or u-boot is not built w/ the correct partition
>>> >> driver.
>>> >>
>>> >> BR,
>>> >> -R
>>> >
>>> > It is partitioned mbr style.
>>> >
>>> > U-Boot> part list mmc 0
>>> >
>>> > Partition Map for MMC device 0  --   Partition Type: DOS
>>> >
>>> > PartStart SectorNum Sectors UUIDType
>>> >   1 81928192-01 0c Boot
>>> >   4 16384   26624   -04 a6
>>> > U-Boot> part list usb 0
>>>
>>> perhaps jumping from partition #1 to #4 is what is confusing things
>>> here?  It's possible you end up with a partition "diskobj" for
>>> partition #1 but not #4?
>>>
>>> Try adding a print in efi_disk_register() and see how many times we go
>>> thru the while(!part_get_info()) loop.
>>
>> Indeed, it seems to only end up calling efi_disk_add_dev() for
>> part 1 in that loop:
>>
>> ## Starting EFI application at 0100 ...
>> Scanning disk sd...@7e30.blk...
>> ## Valid DOS partition found ##
>> efi_disk_register calling efi_disk_add_dev for part 1
>> ## Valid DOS partition found ##
>> Scanning disk usb_mass_storage.lun0...
>> ## Valid DOS partition found ##
>> efi_disk_register calling efi_disk_add_dev for part 1
>> ## Valid DOS partition found ##
>> Found 2 disks
>>
>> If I change the code there to match other callers of part_get_info()
>> I get a MEDIA_DEVICE type and can boot.
>
> Ok, this makes sense now.  There is one 

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

[Rob Clark]

On Mon, Oct 9, 2017 at 1:48 PM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray  wrote:
>> > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
>> >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>> >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>> >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  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  
>> >> >> >> 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 
>> >> >> >> >> Signed-off-by: Rob Clark 
>> >> >> >> >
>> >> >> >> > 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.
>> >> >
>> >> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>> >> > in master only gives types of 1 (Hardware Device Path) and
>> >> > 3 (Messaging Device Path).
>> >> >
>> >> > It is DM in this case:
>> >>
>> >> Possibly something weird with your partition table?  In
>> >> efi_disk_register() it should create objects for the disk itself
>> >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
>> >> partition (part>=1, which would have same dp as the disk but
>> >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
>> >>
>> >> If part_get_info() fails for part==1 then you won't get any of the
>> >> partition devices.  I suppose this could happen if you an unknown
>> >> partition table type, or u-boot is not built w/ the correct partition
>> >> driver.
>> >>
>> >> BR,
>> >> -R
>> >
>> > It is partitioned mbr style.
>> >
>> > U-Boot> part list mmc 0
>> >
>> > Partition Map for MMC device 0  --   Partition Type: DOS
>> >
>> > PartStart SectorNum Sectors UUIDType
>> >   1 81928192-01 0c Boot
>> >   4 16384   26624   -04 a6
>> > U-Boot> part list usb 0
>>
>> perhaps jumping from partition #1 to #4 is what is confusing things
>> here?  It's possible you end up with a partition "diskobj" for
>> partition #1 but not #4?
>>
>> Try adding a print in efi_disk_register() and see how many times we go
>> thru the while(!part_get_info()) loop.
>
> Indeed, it seems to only end up calling efi_disk_add_dev() for
> part 1 in that loop:
>
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 1
> ## Valid DOS partition found ##
> Scanning disk usb_mass_storage.lun0...
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 1
> ## Valid DOS partition found ##
> Found 2 disks
>
> If I change the code there to match other callers of part_get_info()
> I get a MEDIA_DEVICE type and can boot.

Ok, this makes sense now.  There is one more loop to fix in the
non-DM/BLK case (well, the one added by this patch, which I think
agraf has already applied).

Care to send a patch?

BR,
-R

> ## Starting EFI application at 0100 ...
> Scanning disk 

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

[Jonathan Gray]

On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray  wrote:
> > On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
> >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
> >> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> >> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  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  
> >> >> >> 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 
> >> >> >> >> Signed-off-by: Rob Clark 
> >> >> >> >
> >> >> >> > 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.
> >> >
> >> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
> >> > in master only gives types of 1 (Hardware Device Path) and
> >> > 3 (Messaging Device Path).
> >> >
> >> > It is DM in this case:
> >>
> >> Possibly something weird with your partition table?  In
> >> efi_disk_register() it should create objects for the disk itself
> >> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
> >> partition (part>=1, which would have same dp as the disk but
> >> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
> >>
> >> If part_get_info() fails for part==1 then you won't get any of the
> >> partition devices.  I suppose this could happen if you an unknown
> >> partition table type, or u-boot is not built w/ the correct partition
> >> driver.
> >>
> >> BR,
> >> -R
> >
> > It is partitioned mbr style.
> >
> > U-Boot> part list mmc 0
> >
> > Partition Map for MMC device 0  --   Partition Type: DOS
> >
> > PartStart SectorNum Sectors UUIDType
> >   1 81928192-01 0c Boot
> >   4 16384   26624   -04 a6
> > U-Boot> part list usb 0
> 
> perhaps jumping from partition #1 to #4 is what is confusing things
> here?  It's possible you end up with a partition "diskobj" for
> partition #1 but not #4?
> 
> Try adding a print in efi_disk_register() and see how many times we go
> thru the while(!part_get_info()) loop.

Indeed, it seems to only end up calling efi_disk_add_dev() for
part 1 in that loop:

## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 1
## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 1
## Valid DOS partition found ##
Found 2 disks

If I change the code there to match other callers of part_get_info()
I get a MEDIA_DEVICE type and can boot.

## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 1
## Valid DOS partition found ##
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 4
## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 1
## Valid DOS 

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

[Rob Clark]

On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  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  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 
>> >> >> >> Signed-off-by: Rob Clark 
>> >> >> >
>> >> >> > 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.
>> >
>> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>> > in master only gives types of 1 (Hardware Device Path) and
>> > 3 (Messaging Device Path).
>> >
>> > It is DM in this case:
>>
>> Possibly something weird with your partition table?  In
>> efi_disk_register() it should create objects for the disk itself
>> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
>> partition (part>=1, which would have same dp as the disk but
>> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
>>
>> If part_get_info() fails for part==1 then you won't get any of the
>> partition devices.  I suppose this could happen if you an unknown
>> partition table type, or u-boot is not built w/ the correct partition
>> driver.
>>
>> BR,
>> -R
>
> It is partitioned mbr style.
>
> U-Boot> part list mmc 0
>
> Partition Map for MMC device 0  --   Partition Type: DOS
>
> PartStart SectorNum Sectors UUIDType
>   1 81928192-01 0c Boot
>   4 16384   26624   -04 a6
> U-Boot> part list usb 0

perhaps jumping from partition #1 to #4 is what is confusing things
here?  It's possible you end up with a partition "diskobj" for
partition #1 but not #4?

Try adding a print in efi_disk_register() and see how many times we go
thru the while(!part_get_info()) loop.

BR,
-R

> Partition Map for USB device 0  --   Partition Type: DOS
>
> PartStart SectorNum Sectors UUIDType
>   1 819232768   -01 0c Boot
>   4 40960   60021540-04 a6
>
> I changed the part_get_info() debug messages to normal printfs and no
> error paths trigger:
>
> U-Boot 2017.11-rc1-00111-g97b86e3342-dirty (Oct 10 2017 - 03:28:40 +1100)
>
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   sdhci@7e30: 0
> ## Valid DOS partition found ##
> reading uboot.env
> In:serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:   Core Release: 2.80a
> scanning bus 0 for devices... 4 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
>
> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> Type: Removable Hard Disk
> Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> ... is now current device
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> Scanning usb 0:1...
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid 

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

[Rob Clark]

On Mon, Oct 9, 2017 at 12:22 PM, Heinrich Schuchardt  wrote:
> On 10/09/2017 06:06 PM, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>>> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
 On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  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  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 
 Signed-off-by: Rob Clark 
>>>
>>> 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.
>>>
>>> I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>>> in master only gives types of 1 (Hardware Device Path) and
>>> 3 (Messaging Device Path).
>>>
>>> It is DM in this case:
>>
>> Possibly something weird with your partition table?  In
>> efi_disk_register() it should create objects for the disk itself
>> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
>> partition (part>=1, which would have same dp as the disk but
>> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
>>
>> If part_get_info() fails for part==1 then you won't get any of the
>> partition devices.  I suppose this could happen if you an unknown
>> partition table type, or u-boot is not built w/ the correct partition
>> driver.
>>
>> BR,
>> -R
>>
>>
>>> U-Boot> dm tree
>>>  Class  Probed  Driver  Name
>>> 
>>>  root   [ + ]   root_drive  root_driver
>>>  simple_bus [ + ]   generic_si  |-- soc
>>>  gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
>>>  serial [ + ]   serial_bcm  |   |-- serial@7e215040
>>>  mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
>>>  blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
>>>  video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>>>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>>>  usb[ + ]   dwc2_usb|   `-- usb@7e98
>>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>>  eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
>>>  usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
>>>  blk[   ]   usb_storag  |   `-- 
>>> usb_mass_storage.lun0
>>>  simple_bus [   ]   generic_si  `-- clocks
>>>

> 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 0100 ...
> Scanning disk sd...@7e30.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" 

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

[Jonathan Gray]

On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
> > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  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  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 
> >> >> >> Signed-off-by: Rob Clark 
> >> >> >
> >> >> > 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.
> >
> > I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
> > in master only gives types of 1 (Hardware Device Path) and
> > 3 (Messaging Device Path).
> >
> > It is DM in this case:
> 
> Possibly something weird with your partition table?  In
> efi_disk_register() it should create objects for the disk itself
> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
> partition (part>=1, which would have same dp as the disk but
> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
> 
> If part_get_info() fails for part==1 then you won't get any of the
> partition devices.  I suppose this could happen if you an unknown
> partition table type, or u-boot is not built w/ the correct partition
> driver.
> 
> BR,
> -R

It is partitioned mbr style.

U-Boot> part list mmc 0

Partition Map for MMC device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 81928192-01 0c Boot
  4 16384   26624   -04 a6
U-Boot> part list usb 0

Partition Map for USB device 0  --   Partition Type: DOS

PartStart SectorNum Sectors UUIDType
  1 819232768   -01 0c Boot
  4 40960   60021540-04 a6

I changed the part_get_info() debug messages to normal printfs and no
error paths trigger:

U-Boot 2017.11-rc1-00111-g97b86e3342-dirty (Oct 10 2017 - 03:28:40 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci@7e30: 0
## Valid DOS partition found ##
reading uboot.env
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 

Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
Type: Removable Hard Disk
Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
... is now current device
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
Scanning usb 0:1...
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
## Valid DOS partition found ##
Found EFI removable media binary efi/boot/bootaa64.efi
## Valid DOS partition found ##
## Valid DOS partition found ##
reading efi/boot/bootaa64.efi
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
## Valid DOS partition found 

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

[Heinrich Schuchardt]

On 10/09/2017 06:06 PM, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
>> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>>> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  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  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 
>>> Signed-off-by: Rob Clark 
>>
>> 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.
>>
>> I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
>> in master only gives types of 1 (Hardware Device Path) and
>> 3 (Messaging Device Path).
>>
>> It is DM in this case:
> 
> Possibly something weird with your partition table?  In
> efi_disk_register() it should create objects for the disk itself
> (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
> partition (part>=1, which would have same dp as the disk but
> additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).
> 
> If part_get_info() fails for part==1 then you won't get any of the
> partition devices.  I suppose this could happen if you an unknown
> partition table type, or u-boot is not built w/ the correct partition
> driver.
> 
> BR,
> -R
> 
> 
>> U-Boot> dm tree
>>  Class  Probed  Driver  Name
>> 
>>  root   [ + ]   root_drive  root_driver
>>  simple_bus [ + ]   generic_si  |-- soc
>>  gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
>>  serial [ + ]   serial_bcm  |   |-- serial@7e215040
>>  mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
>>  blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
>>  video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>>  usb[ + ]   dwc2_usb|   `-- usb@7e98
>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>>  eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
>>  usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
>>  blk[   ]   usb_storag  |   `-- usb_mass_storage.lun0
>>  simple_bus [   ]   generic_si  `-- clocks
>>
>>>
 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 0100 ...
 Scanning disk sd...@7e30.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.)
>>
>> Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
>> The problem seems to be elsewhere as dropping that I still see:
>>
>> ## Starting EFI application at 0100 ...
>> 

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

[Rob Clark]

On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray  wrote:
> On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  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  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 
>> >> >> Signed-off-by: Rob Clark 
>> >> >
>> >> > 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.
>
> I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
> in master only gives types of 1 (Hardware Device Path) and
> 3 (Messaging Device Path).
>
> It is DM in this case:

Possibly something weird with your partition table?  In
efi_disk_register() it should create objects for the disk itself
(part==0, no MEDIA_DEVICE nodes in the dp), as well as for each
partition (part>=1, which would have same dp as the disk but
additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node).

If part_get_info() fails for part==1 then you won't get any of the
partition devices.  I suppose this could happen if you an unknown
partition table type, or u-boot is not built w/ the correct partition
driver.

BR,
-R


> U-Boot> dm tree
>  Class  Probed  Driver  Name
> 
>  root   [ + ]   root_drive  root_driver
>  simple_bus [ + ]   generic_si  |-- soc
>  gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
>  serial [ + ]   serial_bcm  |   |-- serial@7e215040
>  mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
>  blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
>  video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>  usb[ + ]   dwc2_usb|   `-- usb@7e98
>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>  usb_hub[ + ]   usb_hub |   `-- usb_hub
>  eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
>  usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
>  blk[   ]   usb_storag  |   `-- usb_mass_storage.lun0
>  simple_bus [   ]   generic_si  `-- clocks
>
>>
>> > 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 0100 ...
>> > Scanning disk sd...@7e30.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.)
>
> Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
> The problem seems to be elsewhere as dropping that I still see:
>
> ## Starting EFI application at 0100 ...
> Scanning disk sd...@7e30.blk...
> Scanning disk usb_mass_storage.lun0...
> Found 2 disks
> efi_diskprobe
> 

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

[Jonathan Gray]

On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray  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  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 
> >> >> Signed-off-by: Rob Clark 
> >> >
> >> > 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.

I only see MEDIA_DEVICE with U-Boot 2017.09.  The latest code
in master only gives types of 1 (Hardware Device Path) and
3 (Messaging Device Path).

It is DM in this case:

U-Boot> dm tree
 Class  Probed  Driver  Name

 root   [ + ]   root_drive  root_driver
 simple_bus [ + ]   generic_si  |-- soc
 gpio   [ + ]   gpio_bcm28  |   |-- gpio@7e20
 serial [ + ]   serial_bcm  |   |-- serial@7e215040
 mmc[ + ]   sdhci-bcm2  |   |-- sdhci@7e30
 blk[ + ]   mmc_blk |   |   `-- sd...@7e30.blk
 video  [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
 vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
 usb[ + ]   dwc2_usb|   `-- usb@7e98
 usb_hub[ + ]   usb_hub |   `-- usb_hub
 usb_hub[ + ]   usb_hub |   `-- usb_hub
 eth[ + ]   smsc95xx_e  |   |-- smsc95xx_eth
 usb_mass_s [ + ]   usb_mass_s  |   `-- usb_mass_storage
 blk[   ]   usb_storag  |   `-- usb_mass_storage.lun0
 simple_bus [   ]   generic_si  `-- clocks

> 
> > 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 0100 ...
> > Scanning disk sd...@7e30.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.)

Yes, "efi_loader: Fix disk dp's for pre-DM/legacy devices".
The problem seems to be elsewhere as dropping that I still see:

## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.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
 failed(6). will try /bsd

od1000 (edk2) booting off sata:

INFO:PSCI Power Domain Map:
INFO:  Domain Node : Level 1, parent_node -1, State ON (0x0)
INFO:  Domain Node : Level 1, parent_node -1, State OFF (0x2)
INFO:  Domain Node : Level 1, parent_node -1, State OFF (0x2)
INFO:  Domain Node 

Re: [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  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  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 
>> >> Signed-off-by: Rob Clark 
>> >
>> > 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 0100 ...
> Scanning disk sd...@7e30.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 0100 ...
> Scanning disk sd...@7e30.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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Jonathan Gray]

On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote:
> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  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 
> >> Signed-off-by: Rob Clark 
> >
> > 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?

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 0100 ...
Scanning disk sd...@7e30.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

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 0100 ...
Scanning disk sd...@7e30.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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Rob Clark]

On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray  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 
>> Signed-off-by: Rob Clark 
>
> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Jonathan Gray]

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 
> Signed-off-by: Rob Clark 

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?

U-Boot 2017.11-rc1-00112-g936028a089 (Oct 09 2017 - 13:39:34 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci@7e30: 0
reading uboot.env
In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0
U-Boot> printenv boot_targets
boot_targets=usb0 mmc0 pxe dhcp
U-Boot> boot

Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
Type: Removable Hard Disk
Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
... is now current device
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
78287 bytes read in 86 ms (888.7 KiB/s)
## Starting EFI application at 0100 ...
Scanning disk sd...@7e30.blk...
Scanning disk usb_mass_storage.lun0...
Found 2 disks
>> OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
 failed(6). will try /bsd
boot> ls sd0a:/
stat(sd0a:/): Device not configured
boot> ls sd1a:/
stat(sd1a:/): Device not configured
boot>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot