On Mon, Oct 9, 2017 at 12:22 PM, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > On 10/09/2017 06:06 PM, Rob Clark wrote: >> On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <j...@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 <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: >> >> 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 | | `-- 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 >> > 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".. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot