[U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices
Rob Clark
robdclark at gmail.com
Mon Oct 9 16:06:24 UTC 2017
On Mon, Oct 9, 2017 at 11:35 AM, Jonathan Gray <jsg at 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 at 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 at 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 at jsg.id.au>
>> >> >> Signed-off-by: Rob Clark <robdclark at 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 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
More information about the U-Boot
mailing list