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

Rob Clark robdclark at gmail.com
Mon Oct 9 17:02:08 UTC 2017


On Mon, Oct 9, 2017 at 12:22 PM, Heinrich Schuchardt <xypron.glpk at 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 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
>>
> 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"..


More information about the U-Boot mailing list