diff mbox series

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

Message ID 20171008153310.25350-1-robdclark@gmail.com
State Accepted
Headers show
Series [U-Boot] efi_loader: Fix disk dp's for pre-DM/legacy devices | expand

Commit Message

Rob Clark Oct. 8, 2017, 3:33 p.m. UTC 
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@jsg.id.au>
Signed-off-by: Rob Clark <robdclark@gmail.com>
---
 lib/efi_loader/efi_disk.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

Comments

Jonathan Gray Oct. 9, 2017, 3:33 a.m. UTC | #1 
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@jsg.id.au>
> Signed-off-by: Rob Clark <robdclark@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?

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

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci@7e300000: 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 01000000 ...
Scanning disk sdhci@7e300000.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>
Alexander Graf Oct. 9, 2017, 4:43 a.m. UTC | #2 
> 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@jsg.id.au>
> Signed-off-by: Rob Clark <robdclark@gmail.com>

Thanks, applied to efi-next

Alex
Rob Clark Oct. 9, 2017, 10:52 a.m. UTC | #3 
On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray <jsg@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@jsg.id.au>
>> Signed-off-by: Rob Clark <robdclark@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
Jonathan Gray Oct. 9, 2017, 12:25 p.m. UTC | #4 
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@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@jsg.id.au>
> >> Signed-off-by: Rob Clark <robdclark@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?

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

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@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
Rob Clark Oct. 9, 2017, 2:17 p.m. UTC | #5 
On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@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@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@jsg.id.au>
>> >> Signed-off-by: Rob Clark <robdclark@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@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@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
Jonathan Gray Oct. 9, 2017, 3:35 p.m. UTC | #6 
On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <jsg@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@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@jsg.id.au>
> >> >> Signed-off-by: Rob Clark <robdclark@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.

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@7e200000
 serial     [ + ]   serial_bcm  |   |-- serial@7e215040
 mmc        [ + ]   sdhci-bcm2  |   |-- sdhci@7e300000
 blk        [ + ]   mmc_blk     |   |   `-- sdhci@7e300000.blk
 video      [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
 vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
 usb        [ + ]   dwc2_usb    |   `-- usb@7e980000
 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 01000000 ...
> > Scanning disk sdhci@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.)

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 01000000 ...
Scanning disk sdhci@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
 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 : Level 1, parent_node -1, State OFF (0x2)
INFO:	   CPU Node : MPID 0x0, parent_node 0, State ON (0x0)
INFO:	   CPU Node : MPID 0xffffffffffffffff, parent_node 0, State OFF (0x2)
INFO:	   CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
INFO:	   CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
INFO:	   CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
INFO:	   CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
INFO:	   CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
INFO:	   CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
NOTICE:	 BL3-1:
NOTICE:	 BL3-1: Built : 14:04:15, Apr  9 2016
INFO:	 BL3-1: Initializing runtime services
INFO:	 BL3-1: Preparing for EL3 exit to normal world
INFO:	 BL3-1: Next image address = 0x8000e80000
INFO:	 BL3-1: Next image spsr = 0x3c9
Press ESCAPE for boot options .....efi_diskprobe
efi_device_path_depth looking for type 4 i=0 type 2
efi_device_path_depth looking for type 4 i=1 type 1
efi_device_path_depth looking for type 4 i=2 type 3
efi_device_path_depth looking for type 4 i=3 type 4
depth=3
i=0
efi_bootdp=A dp=A
>> OpenBSD/arm64 BOOTAA64 0.8
boot>
booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90
Rob Clark Oct. 9, 2017, 4:06 p.m. UTC | #7 
On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> 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 <jsg@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@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@jsg.id.au>
>> >> >> Signed-off-by: Rob Clark <robdclark@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.
>
> 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@7e200000
>  serial     [ + ]   serial_bcm  |   |-- serial@7e215040
>  mmc        [ + ]   sdhci-bcm2  |   |-- sdhci@7e300000
>  blk        [ + ]   mmc_blk     |   |   `-- sdhci@7e300000.blk
>  video      [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>  usb        [ + ]   dwc2_usb    |   `-- usb@7e980000
>  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 01000000 ...
>> > Scanning disk sdhci@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.)
>
> 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 01000000 ...
> Scanning disk sdhci@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
>  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 : Level 1, parent_node -1, State OFF (0x2)
> INFO:      CPU Node : MPID 0x0, parent_node 0, State ON (0x0)
> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 0, State OFF (0x2)
> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
> NOTICE:  BL3-1:
> NOTICE:  BL3-1: Built : 14:04:15, Apr  9 2016
> INFO:    BL3-1: Initializing runtime services
> INFO:    BL3-1: Preparing for EL3 exit to normal world
> INFO:    BL3-1: Next image address = 0x8000e80000
> INFO:    BL3-1: Next image spsr = 0x3c9
> Press ESCAPE for boot options .....efi_diskprobe
> efi_device_path_depth looking for type 4 i=0 type 2
> efi_device_path_depth looking for type 4 i=1 type 1
> efi_device_path_depth looking for type 4 i=2 type 3
> efi_device_path_depth looking for type 4 i=3 type 4
> depth=3
> i=0
> efi_bootdp=A dp=A
>>> OpenBSD/arm64 BOOTAA64 0.8
> boot>
> booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90
Heinrich Schuchardt Oct. 9, 2017, 4:22 p.m. UTC | #8 
On 10/09/2017 06:06 PM, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> 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 <jsg@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@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@jsg.id.au>
>>>>>>> Signed-off-by: Rob Clark <robdclark@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.
>>
>> 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@7e200000
>>  serial     [ + ]   serial_bcm  |   |-- serial@7e215040
>>  mmc        [ + ]   sdhci-bcm2  |   |-- sdhci@7e300000
>>  blk        [ + ]   mmc_blk     |   |   `-- sdhci@7e300000.blk
>>  video      [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>>  usb        [ + ]   dwc2_usb    |   `-- usb@7e980000
>>  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 01000000 ...
>>>> Scanning disk sdhci@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.)
>>
>> 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 01000000 ...
>> Scanning disk sdhci@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
>>  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 : Level 1, parent_node -1, State OFF (0x2)
>> INFO:      CPU Node : MPID 0x0, parent_node 0, State ON (0x0)
>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 0, State OFF (0x2)
>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
>> NOTICE:  BL3-1:
>> NOTICE:  BL3-1: Built : 14:04:15, Apr  9 2016
>> INFO:    BL3-1: Initializing runtime services
>> INFO:    BL3-1: Preparing for EL3 exit to normal world
>> INFO:    BL3-1: Next image address = 0x8000e80000
>> INFO:    BL3-1: Next image spsr = 0x3c9
>> Press ESCAPE for boot options .....efi_diskprobe
>> efi_device_path_depth looking for type 4 i=0 type 2
>> efi_device_path_depth looking for type 4 i=1 type 1
>> efi_device_path_depth looking for type 4 i=2 type 3
>> efi_device_path_depth looking for type 4 i=3 type 4
>> depth=3
>> i=0
>> efi_bootdp=A dp=A
>>>> OpenBSD/arm64 BOOTAA64 0.8
>> boot>
>> booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90
> 
Hello Rob,

does you patch create the partitions handles as children of the disk?

This means do you append the partition name as node to the device path
of the drive to produce the partition device path?

Best regards

Heinrich
Jonathan Gray Oct. 9, 2017, 4:41 p.m. UTC | #9 
On Mon, Oct 09, 2017 at 12:06:24PM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> 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 <jsg@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@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@jsg.id.au>
> >> >> >> Signed-off-by: Rob Clark <robdclark@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.
> >
> > 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

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            8192            00000000-01     0c Boot
  4     16384           26624           00000000-04     a6
U-Boot> part list usb 0

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

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            32768           00000000-01     0c Boot
  4     40960           60021540        00000000-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@7e300000: 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 01000000 ...
Scanning disk sdhci@7e300000.blk...
## Valid DOS partition found ##
## Valid DOS partition found ##
Scanning disk usb_mass_storage.lun0...
## Valid DOS partition found ##
## Valid DOS partition found ##
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
Rob Clark Oct. 9, 2017, 5:02 p.m. UTC | #10 
On Mon, Oct 9, 2017 at 12:22 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> On 10/09/2017 06:06 PM, Rob Clark wrote:
>> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg@jsg.id.au> 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 <jsg@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@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@jsg.id.au>
>>>>>>>> Signed-off-by: Rob Clark <robdclark@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.
>>>
>>> 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@7e200000
>>>  serial     [ + ]   serial_bcm  |   |-- serial@7e215040
>>>  mmc        [ + ]   sdhci-bcm2  |   |-- sdhci@7e300000
>>>  blk        [ + ]   mmc_blk     |   |   `-- sdhci@7e300000.blk
>>>  video      [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
>>>  vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
>>>  usb        [ + ]   dwc2_usb    |   `-- usb@7e980000
>>>  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 01000000 ...
>>>>> Scanning disk sdhci@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.)
>>>
>>> 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 01000000 ...
>>> Scanning disk sdhci@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
>>>  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 : Level 1, parent_node -1, State OFF (0x2)
>>> INFO:      CPU Node : MPID 0x0, parent_node 0, State ON (0x0)
>>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 0, State OFF (0x2)
>>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
>>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 1, State OFF (0x2)
>>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
>>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 2, State OFF (0x2)
>>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
>>> INFO:      CPU Node : MPID 0xffffffffffffffff, parent_node 3, State OFF (0x2)
>>> NOTICE:  BL3-1:
>>> NOTICE:  BL3-1: Built : 14:04:15, Apr  9 2016
>>> INFO:    BL3-1: Initializing runtime services
>>> INFO:    BL3-1: Preparing for EL3 exit to normal world
>>> INFO:    BL3-1: Next image address = 0x8000e80000
>>> INFO:    BL3-1: Next image spsr = 0x3c9
>>> Press ESCAPE for boot options .....efi_diskprobe
>>> efi_device_path_depth looking for type 4 i=0 type 2
>>> efi_device_path_depth looking for type 4 i=1 type 1
>>> efi_device_path_depth looking for type 4 i=2 type 3
>>> efi_device_path_depth looking for type 4 i=3 type 4
>>> depth=3
>>> i=0
>>> efi_bootdp=A dp=A
>>>>> OpenBSD/arm64 BOOTAA64 0.8
>>> boot>
>>> booting sd0a:/bsd: 3871308+578600+506424+803928-[284614+96+451944+239920]=0x82ea90
>>
> Hello Rob,
>
> does you patch create the partitions handles as children of the disk?
>
> This means do you append the partition name as node to the device path
> of the drive to produce the partition device path?
>

We create diskobj's for both the entire disk, and for each partition.
(The per-partition diskobj was previously missing in the !DM case,
which this patch fixes.)

The devicepath for the per-partition diskobj's matches the devicepath
of the parent whole-disk diskobj with MEDIA_DEVICE:HARD_DRIVE (or
:CDROM) node appended.  So in this sense, they are children of the
parent disk[1].

BR,
-R

[1] UEFI's terminology is designed to confuse here, since it calls the
per-partition diskobj's as "disk objects" rather than something like
"partition objects"..
Rob Clark Oct. 9, 2017, 5:06 p.m. UTC | #11 
On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray <jsg@jsg.id.au> 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 <jsg@jsg.id.au> 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 <jsg@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@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@jsg.id.au>
>> >> >> >> Signed-off-by: Rob Clark <robdclark@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.
>> >
>> > 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
>
> Part    Start Sector    Num Sectors     UUID            Type
>   1     8192            8192            00000000-01     0c Boot
>   4     16384           26624           00000000-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
>
> Part    Start Sector    Num Sectors     UUID            Type
>   1     8192            32768           00000000-01     0c Boot
>   4     40960           60021540        00000000-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@7e300000: 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 01000000 ...
> Scanning disk sdhci@7e300000.blk...
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> Scanning disk usb_mass_storage.lun0...
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> 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
Jonathan Gray Oct. 9, 2017, 5:48 p.m. UTC | #12 
On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote:
> On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray <jsg@jsg.id.au> 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 <jsg@jsg.id.au> 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 <jsg@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@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@jsg.id.au>
> >> >> >> >> Signed-off-by: Rob Clark <robdclark@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.
> >> >
> >> > 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
> >
> > Part    Start Sector    Num Sectors     UUID            Type
> >   1     8192            8192            00000000-01     0c Boot
> >   4     16384           26624           00000000-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 01000000 ...
Scanning disk sdhci@7e300000.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 01000000 ...
Scanning disk sdhci@7e300000.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 partition found ##
## Valid DOS partition found ##
efi_disk_register calling efi_disk_add_dev for part 4
## Valid DOS partition found ##
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 looking for type 4 i=4 type 4
depth=4
i=0

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index eb9ce772d1..d34a5b3e5e 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -254,18 +254,20 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,
 #if CONFIG_IS_ENABLED(ISO_PARTITION)
 	char devname[32] = { 0 }; /* dp->str is u16[32] long */
 	disk_partition_t info;
-	int part = 1;
+	int part, ret;
 
 	if (desc->part_type != PART_TYPE_ISO)
 		return 0;
 
 	/* and devices for each partition: */
-	while (!part_get_info(desc, part, &info)) {
+	for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+		ret = part_get_info(desc, part, &info);
+		if (ret)
+			continue;
 		snprintf(devname, sizeof(devname), "%s:%d", pdevname,
 			 part);
 		efi_disk_add_dev(devname, if_typename, desc, diskid,
 				 info.start, part);
-		part++;
 		disks++;
 	}
 
@@ -299,15 +301,18 @@ int efi_disk_register(void)
 		struct blk_desc *desc = dev_get_uclass_platdata(dev);
 		const char *if_typename = dev->driver->name;
 		disk_partition_t info;
-		int part = 1;
+		int part, ret;
 
 		printf("Scanning disk %s...\n", dev->name);
 
 		/* add devices for each partition: */
-		while (!part_get_info(desc, part, &info)) {
+		for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+			ret = part_get_info(desc, part, &info);
+			if (ret)
+				continue;
+printf("%s calling efi_disk_add_dev for part %d\n", __func__, part);
 			efi_disk_add_dev(dev->name, if_typename, desc,
 					 desc->devnum, 0, part);
-			part++;
 		}
 
 		/* ... and add block device: */
Rob Clark Oct. 9, 2017, 6:20 p.m. UTC | #13 
On Mon, Oct 9, 2017 at 1:48 PM, Jonathan Gray <jsg@jsg.id.au> 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 <jsg@jsg.id.au> 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 <jsg@jsg.id.au> 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 <jsg@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@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@jsg.id.au>
>> >> >> >> >> Signed-off-by: Rob Clark <robdclark@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.
>> >> >
>> >> > 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
>> >
>> > Part    Start Sector    Num Sectors     UUID            Type
>> >   1     8192            8192            00000000-01     0c Boot
>> >   4     16384           26624           00000000-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 01000000 ...
> Scanning disk sdhci@7e300000.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 01000000 ...
> Scanning disk sdhci@7e300000.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 partition found ##
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 4
> ## Valid DOS partition found ##
> 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 looking for type 4 i=4 type 4
> depth=4
> i=0
>
> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> index eb9ce772d1..d34a5b3e5e 100644
> --- a/lib/efi_loader/efi_disk.c
> +++ b/lib/efi_loader/efi_disk.c
> @@ -254,18 +254,20 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,
>  #if CONFIG_IS_ENABLED(ISO_PARTITION)
>         char devname[32] = { 0 }; /* dp->str is u16[32] long */
>         disk_partition_t info;
> -       int part = 1;
> +       int part, ret;
>
>         if (desc->part_type != PART_TYPE_ISO)
>                 return 0;
>
>         /* and devices for each partition: */
> -       while (!part_get_info(desc, part, &info)) {
> +       for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
> +               ret = part_get_info(desc, part, &info);
> +               if (ret)
> +                       continue;
>                 snprintf(devname, sizeof(devname), "%s:%d", pdevname,
>                          part);
>                 efi_disk_add_dev(devname, if_typename, desc, diskid,
>                                  info.start, part);
> -               part++;
>                 disks++;
>         }
>
> @@ -299,15 +301,18 @@ int efi_disk_register(void)
>                 struct blk_desc *desc = dev_get_uclass_platdata(dev);
>                 const char *if_typename = dev->driver->name;
>                 disk_partition_t info;
> -               int part = 1;
> +               int part, ret;
>
>                 printf("Scanning disk %s...\n", dev->name);
>
>                 /* add devices for each partition: */
> -               while (!part_get_info(desc, part, &info)) {
> +               for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
> +                       ret = part_get_info(desc, part, &info);
> +                       if (ret)
> +                               continue;
> +printf("%s calling efi_disk_add_dev for part %d\n", __func__, part);
>                         efi_disk_add_dev(dev->name, if_typename, desc,
>                                          desc->devnum, 0, part);
> -                       part++;
>                 }
>
>                 /* ... and add block device: */
Peter Robinson Oct. 9, 2017, 6:36 p.m. UTC | #14 
On Mon, Oct 9, 2017 at 7:20 PM, Rob Clark <robdclark@gmail.com> wrote:
> On Mon, Oct 9, 2017 at 1:48 PM, Jonathan Gray <jsg@jsg.id.au> 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 <jsg@jsg.id.au> 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 <jsg@jsg.id.au> 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 <jsg@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@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@jsg.id.au>
>>> >> >> >> >> Signed-off-by: Rob Clark <robdclark@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.
>>> >> >
>>> >> > 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
>>> >
>>> > Part    Start Sector    Num Sectors     UUID            Type
>>> >   1     8192            8192            00000000-01     0c Boot
>>> >   4     16384           26624           00000000-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 01000000 ...
>> Scanning disk sdhci@7e300000.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).

I think that also explains why I've seen issues on the Pine64 as we
currently have a extended partition.

> Care to send a patch?
>
> BR,
> -R
>
>> ## Starting EFI application at 01000000 ...
>> Scanning disk sdhci@7e300000.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 partition found ##
>> ## Valid DOS partition found ##
>> efi_disk_register calling efi_disk_add_dev for part 4
>> ## Valid DOS partition found ##
>> 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 looking for type 4 i=4 type 4
>> depth=4
>> i=0
>>
>> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
>> index eb9ce772d1..d34a5b3e5e 100644
>> --- a/lib/efi_loader/efi_disk.c
>> +++ b/lib/efi_loader/efi_disk.c
>> @@ -254,18 +254,20 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,
>>  #if CONFIG_IS_ENABLED(ISO_PARTITION)
>>         char devname[32] = { 0 }; /* dp->str is u16[32] long */
>>         disk_partition_t info;
>> -       int part = 1;
>> +       int part, ret;
>>
>>         if (desc->part_type != PART_TYPE_ISO)
>>                 return 0;
>>
>>         /* and devices for each partition: */
>> -       while (!part_get_info(desc, part, &info)) {
>> +       for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
>> +               ret = part_get_info(desc, part, &info);
>> +               if (ret)
>> +                       continue;
>>                 snprintf(devname, sizeof(devname), "%s:%d", pdevname,
>>                          part);
>>                 efi_disk_add_dev(devname, if_typename, desc, diskid,
>>                                  info.start, part);
>> -               part++;
>>                 disks++;
>>         }
>>
>> @@ -299,15 +301,18 @@ int efi_disk_register(void)
>>                 struct blk_desc *desc = dev_get_uclass_platdata(dev);
>>                 const char *if_typename = dev->driver->name;
>>                 disk_partition_t info;
>> -               int part = 1;
>> +               int part, ret;
>>
>>                 printf("Scanning disk %s...\n", dev->name);
>>
>>                 /* add devices for each partition: */
>> -               while (!part_get_info(desc, part, &info)) {
>> +               for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
>> +                       ret = part_get_info(desc, part, &info);
>> +                       if (ret)
>> +                               continue;
>> +printf("%s calling efi_disk_add_dev for part %d\n", __func__, part);
>>                         efi_disk_add_dev(dev->name, if_typename, desc,
>>                                          desc->devnum, 0, part);
>> -                       part++;
>>                 }
>>
>>                 /* ... and add block device: */
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
Jonathan Gray Nov. 18, 2017, 4:25 a.m. UTC | #15 
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 <jsg@jsg.id.au> 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 <jsg@jsg.id.au> 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 <jsg@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@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@jsg.id.au>
> > >> >> >> >> Signed-off-by: Rob Clark <robdclark@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.
> > >> >
> > >> > 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
> > >
> > > Part    Start Sector    Num Sectors     UUID            Type
> > >   1     8192            8192            00000000-01     0c Boot
> > >   4     16384           26624           00000000-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 01000000 ...
> Scanning disk sdhci@7e300000.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 01000000 ...
> Scanning disk sdhci@7e300000.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 partition found ##
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 4
> ## Valid DOS partition found ##
> 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 looking for type 4 i=4 type 4
> depth=4
> i=0

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.

U-Boot 2017.09 (Nov 16 2017 - 04:05:33 -0700)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci@7e300000: 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 

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
78959 bytes read in 75 ms (1 MiB/s)
## Starting EFI application at 01000000 ...
Scanning disk sdhci@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

U-Boot 2017.11 (Nov 15 2017 - 13:14:19 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci@7e300000: 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

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
78959 bytes read in 86 ms (896.5 KiB/s)
## Starting EFI application at 01000000 ...
Scanning disk sdhci@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
i=4
i=5
>> 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>
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
 failed(6). will try /bsd
Turning timeout off.
boot>
Jonathan Gray Nov. 21, 2017, 5:59 a.m. UTC | #16 
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

Part    Start Sector    Num Sectors     UUID            Type
  1     2048            4096            00000000-01     0c Boot
  4     6144            30720           00000000-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 40400000 ...
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@c000000
 pci        [ + ]   pci_generi  |-- pcie@10000000
 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@9000000
 firmware   [   ]   psci        `-- psci
 sysreset   [   ]   psci-sysre      `-- psci-sysreset

=> part list scsi 0

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

Part    Start Sector    Num Sectors     UUID            Type
  1     2048            4096            00000000-01     0c Boot
  4     6144            30720           00000000-04     a6

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

## Starting EFI application at 01000000 ...
Scanning disk sdhci@7e300000.blk...
efi_disk_add_dev: name: sdhci@7e300000.blk if_typename: mmc_blk part: 1
efi_disk_add_dev: name: sdhci@7e300000.blk if_typename: mmc_blk part: 4
efi_disk_add_dev: name: sdhci@7e300000.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 01000000 ...
Scanning disk sdhci@7e300000.blk...
efi_disk_add_dev: name: sdhci@7e300000.blk if_typename: mmc_blk part: 1
efi_disk_add_dev: name: sdhci@7e300000.blk if_typename: mmc_blk part: 4
efi_disk_add_dev: name: sdhci@7e300000.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  |   |-- gpio@7e200000
 serial     [ + ]   serial_bcm  |   |-- serial@7e215040
 mmc        [ + ]   sdhci-bcm2  |   |-- sdhci@7e300000
 blk        [ + ]   mmc_blk     |   |   `-- sdhci@7e300000.blk
 video      [ + ]   bcm2835_vi  |   |-- hdmi@7e902000
 vidconsole [ + ]   vidconsole  |   |   `-- hdmi@7e902000.vidconsole0
 usb        [ + ]   dwc2_usb    |   `-- usb@7e980000
 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

U-Boot> part list usb 0

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

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            32768           00000000-01     0c Boot
  4     40960           60021540        00000000-04     a6

U-Boot> part list mmc 0

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

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            8192            00000000-01     0c Boot
  4     16384           26624           00000000-04     a6

tinkerboard

Scanning mmc 1:1...
Found EFI removable media binary efi/boot/bootarm.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk dwmmc@ff0c0000.blk...
efi_disk_add_dev: name: dwmmc@ff0c0000.blk if_typename: mmc_blk part: 1
efi_disk_add_dev: name: dwmmc@ff0c0000.blk if_typename: mmc_blk part: 4
efi_disk_add_dev: name: dwmmc@ff0c0000.blk if_typename: mmc_blk part: 0
Found 1 disks
reading efi/boot/bootarm.efi
67356 bytes read in 10 ms (6.4 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
## Starting EFI application at 02000000 ...
efi_setup_loaded_image: device_path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MMC(Slot1)/HD(Part0,MBRType=01,SigType=00)
efi_setup_loaded_image: file_path /\efi\boot\bootarm.efi

=> part list mmc 1

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

Part    Start Sector    Num Sectors     UUID            Type
  1     2048            32768           00000000-01     0c Boot
  4     34816           62299136        00000000-04     a6

=> dm tree
 Class	    Probed  Driver	Name
----------------------------------------
 root	    [ + ]   root_drive	root_driver
 clk	    [	]   fixed_rate	|-- oscillator
 mmc	    [ + ]   rockchip_r	|-- dwmmc@ff0c0000
 blk	    [ + ]   mmc_blk	|   `-- dwmmc@ff0c0000.blk
 adc	    [	]   rockchip_s	|-- saradc@ff100000
 i2c	    [	]   i2c_rockch	|-- i2c@ff170000
 serial	    [	]   ns16550_se	|-- serial@ff180000
 serial	    [	]   ns16550_se	|-- serial@ff190000
 serial	    [ + ]   ns16550_se	|-- serial@ff690000
 serial	    [	]   ns16550_se	|-- serial@ff1b0000
 serial	    [	]   ns16550_se	|-- serial@ff1c0000
 eth	    [ + ]   gmac_rockc	|-- ethernet@ff290000
 usb	    [	]   dwc2_usb	|-- usb@ff540000
 usb	    [	]   dwc2_usb	|-- usb@ff580000
 ram	    [	]   rockchip_r	|-- dmc@ff610000
 i2c	    [ + ]   i2c_rockch	|-- i2c@ff650000
 pmic	    [ + ]   rk8xx pmic	|   `-- pmic@1b
 regulator  [	]   rk8xx_buck	|	|-- DCDC_REG1
 regulator  [	]   rk8xx_buck	|	|-- DCDC_REG2
 regulator  [	]   rk8xx_buck	|	|-- DCDC_REG3
 regulator  [	]   rk8xx_buck	|	|-- DCDC_REG4
 regulator  [	]   rk8xx_ldo	|	|-- LDO_REG1
 regulator  [	]   rk8xx_ldo	|	|-- LDO_REG2
 regulator  [	]   rk8xx_ldo	|	|-- LDO_REG3
 regulator  [	]   rk8xx_ldo	|	|-- LDO_REG4
 regulator  [	]   rk8xx_ldo	|	|-- LDO_REG5
 regulator  [	]   rk8xx_ldo	|	|-- LDO_REG6
 regulator  [	]   rk8xx_ldo	|	|-- LDO_REG7
 regulator  [	]   rk8xx_ldo	|	|-- LDO_REG8
 regulator  [	]   rk8xx_swit	|	|-- SWITCH_REG1
 regulator  [ + ]   rk8xx_swit	|	`-- SWITCH_REG2
 i2c	    [ + ]   i2c_rockch	|-- i2c@ff660000
 i2c_eeprom [ + ]   i2c_eeprom	|   `-- m24c08@50
 pwm	    [	]   rk_pwm	|-- pwm@ff680000
 pwm	    [	]   rk_pwm	|-- pwm@ff680010
 syscon	    [ + ]   rk3288_sys	|-- power-management@ff730000
 syscon	    [	]   rk3288_sys	|-- syscon@ff740000
 clk	    [ + ]   rockchip_r	|-- clock-controller@ff760000
 sysreset   [	]   rk3288_sys	|-- reset
 syscon	    [ + ]   rk3288_sys	|-- syscon@ff770000
 syscon	    [	]   rk3288_sys	|-- syscon@ffac0000
 pinctrl    [ + ]   rockchip_r	|-- pinctrl
 gpio	    [	]   gpio_rockc	|   |-- gpio0@ff750000
 gpio	    [	]   gpio_rockc	|   |-- gpio1@ff780000
 gpio	    [	]   gpio_rockc	|   |-- gpio2@ff790000
 gpio	    [	]   gpio_rockc	|   |-- gpio3@ff7a0000
 gpio	    [ + ]   gpio_rockc	|   |-- gpio4@ff7b0000
 gpio	    [	]   gpio_rockc	|   |-- gpio5@ff7c0000
 gpio	    [	]   gpio_rockc	|   |-- gpio6@ff7d0000
 gpio	    [ + ]   gpio_rockc	|   |-- gpio7@ff7e0000
 gpio	    [	]   gpio_rockc	|   |-- gpio8@ff7f0000
 pinconfig  [	]   pinconfig	|   |-- pcfg-pull-up
 pinconfig  [	]   pinconfig	|   |-- pcfg-pull-down
 pinconfig  [	]   pinconfig	|   |-- pcfg-pull-none
 pinconfig  [	]   pinconfig	|   |-- pcfg-pull-none-12ma
 pinconfig  [ + ]   pinconfig	|   |-- sleep
 pinconfig  [ + ]   pinconfig	|   |	|-- global-pwroff
 pinconfig  [	]   pinconfig	|   |	|-- ddrio-pwroff
 pinconfig  [	]   pinconfig	|   |	|-- ddr0-retention
 pinconfig  [	]   pinconfig	|   |	`-- ddr1-retention
 pinconfig  [ + ]   pinconfig	|   |-- i2c0
 pinconfig  [ + ]   pinconfig	|   |	`-- i2c0-xfer
 pinconfig  [	]   pinconfig	|   |-- i2c1
 pinconfig  [	]   pinconfig	|   |	`-- i2c1-xfer
 pinconfig  [ + ]   pinconfig	|   |-- i2c2
 pinconfig  [ + ]   pinconfig	|   |	`-- i2c2-xfer
 pinconfig  [	]   pinconfig	|   |-- i2c3
 pinconfig  [	]   pinconfig	|   |	`-- i2c3-xfer
 pinconfig  [	]   pinconfig	|   |-- i2c4
 pinconfig  [	]   pinconfig	|   |	`-- i2c4-xfer
 pinconfig  [	]   pinconfig	|   |-- i2c5
 pinconfig  [	]   pinconfig	|   |	`-- i2c5-xfer
 pinconfig  [	]   pinconfig	|   |-- i2s0
 pinconfig  [	]   pinconfig	|   |	`-- i2s0-bus
 pinconfig  [	]   pinconfig	|   |-- lcdc0
 pinconfig  [	]   pinconfig	|   |	`-- lcdc0-ctl
 pinconfig  [ + ]   pinconfig	|   |-- sdmmc
 pinconfig  [ + ]   pinconfig	|   |	|-- sdmmc-clk
 pinconfig  [ + ]   pinconfig	|   |	|-- sdmmc-cmd
 pinconfig  [ + ]   pinconfig	|   |	|-- sdmcc-cd
 pinconfig  [	]   pinconfig	|   |	|-- sdmmc-bus1
 pinconfig  [ + ]   pinconfig	|   |	|-- sdmmc-bus4
 pinconfig  [ + ]   pinconfig	|   |	`-- sdmmc-pwr
 pinconfig  [	]   pinconfig	|   |-- sdio0
 pinconfig  [	]   pinconfig	|   |	|-- sdio0-bus1
 pinconfig  [	]   pinconfig	|   |	|-- sdio0-bus4
 pinconfig  [	]   pinconfig	|   |	|-- sdio0-cmd
 pinconfig  [	]   pinconfig	|   |	|-- sdio0-clk
 pinconfig  [	]   pinconfig	|   |	|-- sdio0-cd
 pinconfig  [	]   pinconfig	|   |	|-- sdio0-wp
 pinconfig  [	]   pinconfig	|   |	|-- sdio0-pwr
 pinconfig  [	]   pinconfig	|   |	|-- sdio0-bkpwr
 pinconfig  [	]   pinconfig	|   |	`-- sdio0-int
 pinconfig  [	]   pinconfig	|   |-- sdio1
 pinconfig  [	]   pinconfig	|   |	|-- sdio1-bus1
 pinconfig  [	]   pinconfig	|   |	|-- sdio1-bus4
 pinconfig  [	]   pinconfig	|   |	|-- sdio1-cd
 pinconfig  [	]   pinconfig	|   |	|-- sdio1-wp
 pinconfig  [	]   pinconfig	|   |	|-- sdio1-bkpwr
 pinconfig  [	]   pinconfig	|   |	|-- sdio1-int
 pinconfig  [	]   pinconfig	|   |	|-- sdio1-cmd
 pinconfig  [	]   pinconfig	|   |	|-- sdio1-clk
 pinconfig  [	]   pinconfig	|   |	`-- sdio1-pwr
 pinconfig  [	]   pinconfig	|   |-- emmc
 pinconfig  [	]   pinconfig	|   |	|-- emmc-clk
 pinconfig  [	]   pinconfig	|   |	|-- emmc-cmd
 pinconfig  [	]   pinconfig	|   |	|-- emmc-pwr
 pinconfig  [	]   pinconfig	|   |	|-- emmc-bus1
 pinconfig  [	]   pinconfig	|   |	|-- emmc-bus4
 pinconfig  [	]   pinconfig	|   |	`-- emmc-bus8
 pinconfig  [	]   pinconfig	|   |-- spi0
 pinconfig  [	]   pinconfig	|   |	|-- spi0-clk
 pinconfig  [	]   pinconfig	|   |	|-- spi0-cs0
 pinconfig  [	]   pinconfig	|   |	|-- spi0-tx
 pinconfig  [	]   pinconfig	|   |	|-- spi0-rx
 pinconfig  [	]   pinconfig	|   |	`-- spi0-cs1
 pinconfig  [	]   pinconfig	|   |-- spi1
 pinconfig  [	]   pinconfig	|   |	|-- spi1-clk
 pinconfig  [	]   pinconfig	|   |	|-- spi1-cs0
 pinconfig  [	]   pinconfig	|   |	|-- spi1-rx
 pinconfig  [	]   pinconfig	|   |	`-- spi1-tx
 pinconfig  [	]   pinconfig	|   |-- spi2
 pinconfig  [	]   pinconfig	|   |	|-- spi2-cs1
 pinconfig  [	]   pinconfig	|   |	|-- spi2-clk
 pinconfig  [	]   pinconfig	|   |	|-- spi2-cs0
 pinconfig  [	]   pinconfig	|   |	|-- spi2-rx
 pinconfig  [	]   pinconfig	|   |	`-- spi2-tx
 pinconfig  [	]   pinconfig	|   |-- uart0
 pinconfig  [	]   pinconfig	|   |	|-- uart0-xfer
 pinconfig  [	]   pinconfig	|   |	|-- uart0-cts
 pinconfig  [	]   pinconfig	|   |	`-- uart0-rts
 pinconfig  [	]   pinconfig	|   |-- uart1
 pinconfig  [	]   pinconfig	|   |	|-- uart1-xfer
 pinconfig  [	]   pinconfig	|   |	|-- uart1-cts
 pinconfig  [	]   pinconfig	|   |	`-- uart1-rts
 pinconfig  [ + ]   pinconfig	|   |-- uart2
 pinconfig  [ + ]   pinconfig	|   |	`-- uart2-xfer
 pinconfig  [	]   pinconfig	|   |-- uart3
 pinconfig  [	]   pinconfig	|   |	|-- uart3-xfer
 pinconfig  [	]   pinconfig	|   |	|-- uart3-cts
 pinconfig  [	]   pinconfig	|   |	`-- uart3-rts
 pinconfig  [	]   pinconfig	|   |-- uart4
 pinconfig  [	]   pinconfig	|   |	|-- uart4-xfer
 pinconfig  [	]   pinconfig	|   |	|-- uart4-cts
 pinconfig  [	]   pinconfig	|   |	`-- uart4-rts
 pinconfig  [	]   pinconfig	|   |-- tsadc
 pinconfig  [	]   pinconfig	|   |	`-- otp-out
 pinconfig  [	]   pinconfig	|   |-- pwm0
 pinconfig  [	]   pinconfig	|   |	`-- pwm0-pin
 pinconfig  [	]   pinconfig	|   |-- pwm1
 pinconfig  [	]   pinconfig	|   |	`-- pwm1-pin
 pinconfig  [	]   pinconfig	|   |-- pwm2
 pinconfig  [	]   pinconfig	|   |	`-- pwm2-pin
 pinconfig  [	]   pinconfig	|   |-- pwm3
 pinconfig  [	]   pinconfig	|   |	`-- pwm3-pin
 pinconfig  [ + ]   pinconfig	|   |-- gmac
 pinconfig  [ + ]   pinconfig	|   |	|-- rgmii-pins
 pinconfig  [	]   pinconfig	|   |	`-- rmii-pins
 pinconfig  [	]   pinconfig	|   |-- spdif
 pinconfig  [	]   pinconfig	|   |	`-- spdif-tx
 pinconfig  [	]   pinconfig	|   |-- pcfg-pull-none-drv-8ma
 pinconfig  [	]   pinconfig	|   |-- pcfg-pull-up-drv-8ma
 pinconfig  [	]   pinconfig	|   |-- backlight
 pinconfig  [	]   pinconfig	|   |	`-- bl-en
 pinconfig  [	]   pinconfig	|   |-- buttons
 pinconfig  [	]   pinconfig	|   |	`-- pwrbtn
 pinconfig  [	]   pinconfig	|   |-- eth_phy
 pinconfig  [	]   pinconfig	|   |	`-- eth-phy-pwr
 pinconfig  [ + ]   pinconfig	|   |-- pmic
 pinconfig  [ + ]   pinconfig	|   |	`-- pmic-int
 pinconfig  [	]   pinconfig	|   `-- usb
 pinconfig  [	]   pinconfig	|	|-- host-vbus-drv
 pinconfig  [	]   pinconfig	|	`-- pwr-3g
 clk	    [	]   fixed_rate	|-- external-gmac-clock
 regulator  [	]   fixed regu	|-- vsys-regulator
 regulator  [ + ]   fixed regu	|-- sdmmc-regulator
 regulator  [	]   fixed regu	`-- usb-host-regulator
=>

>
> U-Boot 2017.09 (Nov 16 2017 - 04:05:33 -0700)
>
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   sdhci@7e300000: 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
>
> 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
> 78959 bytes read in 75 ms (1 MiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk sdhci@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
>
> U-Boot 2017.11 (Nov 15 2017 - 13:14:19 +1100)
>
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   sdhci@7e300000: 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
>
> 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
> 78959 bytes read in 86 ms (896.5 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk sdhci@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
> i=4
> i=5
> >> 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>
> cannot open sd0a:/etc/random.seed: Device not configured
> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
>  failed(6). will try /bsd
> Turning timeout off.
> boot>
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
Jonathan Gray Nov. 21, 2017, 12:01 p.m. UTC | #17 
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, &desc->guid_sig,
 			       sizeof(hddp->partition_signature));
+		else
+			memset(hddp->partition_signature, 0,
+			       sizeof(hddp->partition_signature));
 
 		buf = &hddp[1];
 	}
diff mbox series

Patch

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index eb9ce772d1..47b487aa30 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -340,6 +340,8 @@  int efi_disk_register(void)
 		for (i = 0; i < 4; i++) {
 			struct blk_desc *desc;
 			char devname[32] = { 0 }; /* dp->str is u16[32] long */
+			disk_partition_t info;
+			int part = 1;
 
 			desc = blk_get_devnum_by_type(if_type, i);
 			if (!desc)
@@ -349,6 +351,15 @@  int efi_disk_register(void)
 
 			snprintf(devname, sizeof(devname), "%s%d",
 				 if_typename, i);
+
+			/* add devices for each partition: */
+			while (!part_get_info(desc, part, &info)) {
+				efi_disk_add_dev(devname, if_typename, desc,
+						 i, 0, part);
+				part++;
+			}
+
+			/* ... and add block device: */
 			efi_disk_add_dev(devname, if_typename, desc, i, 0, 0);
 			disks++;