From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Clark Date: Mon, 9 Oct 2017 12:06:24 -0400 Subject: [U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices In-Reply-To: <20171009153553.GC66255@largo.jsg.id.au> References: <20171008153310.25350-1-robdclark@gmail.com> <20171009033308.GA16143@largo.jsg.id.au> <20171009122556.GB66255@largo.jsg.id.au> <20171009153553.GC66255@largo.jsg.id.au> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray wrote: > On Mon, Oct 09, 2017 at 10:17:18AM -0400, Rob Clark wrote: >> On Mon, Oct 9, 2017 at 8:25 AM, Jonathan Gray wrote: >> > On Mon, Oct 09, 2017 at 06:52:18AM -0400, Rob Clark wrote: >> >> On Sun, Oct 8, 2017 at 11:33 PM, Jonathan Gray wrote: >> >> > On Sun, Oct 08, 2017 at 11:33:08AM -0400, Rob Clark wrote: >> >> >> This fixes an issue with OpenBSD's bootloader, and I think should also >> >> >> fix a similar issue with grub2 on legacy devices. In the legacy case >> >> >> we were creating disk objects for the partitions, but not also the >> >> >> parent device. >> >> >> >> >> >> Reported-by: Jonathan Gray >> >> >> Signed-off-by: Rob Clark >> >> > >> >> > Thanks for looking into this. While this lets armv7/bootarm.efi >> >> > boot again on cubox-i and bbb it doesn't help rpi3. >> >> > >> >> > What is the easiest way to get U-Boot to display these paths >> >> > to be able to compare the current behaviour to 2017.09? >> >> > >> >> >> >> in grub, there is the lsefi command, not sure if the OpenBSD >> >> bootloader has something similar? >> >> >> >> u-boot implements that device-path to text protocol, so it should be >> >> pretty easy to implement something like this if not. >> >> >> >> BR, >> >> -R >> > >> > With git + your patch a node with type 4 (DEVICE_PATH_TYPE_MEDIA_DEVICE) >> > is no longer seen. Is it possible having U-Boot on mmc but directing >> > it to load off usb is somehow involved here? >> >> There is no requirement that efi payload and u-boot are on the same >> device. The distro bootcmd stuff will just look for >> /efi/boot/bootxyz.efi on all the devices/partitions until it finds >> one. >> >> The dp for the partition device should end in MEDIA_DEVICE:HARD_DRIVE >> or MEDIA_DEVICE:CDROM. What comes before that differs depending on DM >> or legacy boards, in the former case we can construct something more >> realistic. Although the bootloader shouldn't really care. > > I only see MEDIA_DEVICE with U-Boot 2017.09. The latest code > in master only gives types of 1 (Hardware Device Path) and > 3 (Messaging Device Path). > > It is DM in this case: Possibly something weird with your partition table? In efi_disk_register() it should create objects for the disk itself (part==0, no MEDIA_DEVICE nodes in the dp), as well as for each partition (part>=1, which would have same dp as the disk but additional MEDIA_DEVICE:HARD_DRIVE or MEDIA_DEVICE:CDROM node). If part_get_info() fails for part==1 then you won't get any of the partition devices. I suppose this could happen if you an unknown partition table type, or u-boot is not built w/ the correct partition driver. BR, -R > U-Boot> dm tree > Class Probed Driver Name > ---------------------------------------- > root [ + ] root_drive root_driver > simple_bus [ + ] generic_si |-- soc > gpio [ + ] gpio_bcm28 | |-- gpio at 7e200000 > serial [ + ] serial_bcm | |-- serial at 7e215040 > mmc [ + ] sdhci-bcm2 | |-- sdhci at 7e300000 > blk [ + ] mmc_blk | | `-- sdhci at 7e300000.blk > video [ + ] bcm2835_vi | |-- hdmi at 7e902000 > vidconsole [ + ] vidconsole | | `-- hdmi at 7e902000.vidconsole0 > usb [ + ] dwc2_usb | `-- usb at 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 at 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 at 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