On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: > On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray <j...@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 <j...@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 <j...@jsg.id.au> > >> >> Signed-off-by: Rob Clark <robdcl...@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 | | `-- sd...@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 sd...@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 sd...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot