[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