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

Mon Oct 9 16:22:52 UTC 2017

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?

Best regards

Heinrich