[U-Boot] [PATCH] efi_loader: Fix disk dp's for pre-DM/legacy devices
Rob Clark
robdclark at gmail.com
Mon Oct 9 17:06:26 UTC 2017
On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray <jsg at jsg.id.au> wrote:
> On Mon, Oct 09, 2017 at 12:06:24PM -0400, 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
>
> It is partitioned mbr style.
>
> U-Boot> part list mmc 0
>
> Partition Map for MMC device 0 -- Partition Type: DOS
>
> Part Start Sector Num Sectors UUID Type
> 1 8192 8192 00000000-01 0c Boot
> 4 16384 26624 00000000-04 a6
> U-Boot> part list usb 0
perhaps jumping from partition #1 to #4 is what is confusing things
here? It's possible you end up with a partition "diskobj" for
partition #1 but not #4?
Try adding a print in efi_disk_register() and see how many times we go
thru the while(!part_get_info()) loop.
BR,
-R
> Partition Map for USB device 0 -- Partition Type: DOS
>
> Part Start Sector Num Sectors UUID Type
> 1 8192 32768 00000000-01 0c Boot
> 4 40960 60021540 00000000-04 a6
>
> I changed the part_get_info() debug messages to normal printfs and no
> error paths trigger:
>
> U-Boot 2017.11-rc1-00111-g97b86e3342-dirty (Oct 10 2017 - 03:28:40 +1100)
>
> DRAM: 948 MiB
> RPI 3 Model B (0xa02082)
> MMC: sdhci at 7e300000: 0
> ## Valid DOS partition found ##
> reading uboot.env
> In: serial
> Out: vidconsole
> Err: vidconsole
> Net: No ethernet found.
> starting USB...
> USB0: Core Release: 2.80a
> scanning bus 0 for devices... 4 USB Device(s) found
> scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot: 0
>
> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> Type: Removable Hard Disk
> Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> ... is now current device
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> Scanning usb 0:1...
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> Found EFI removable media binary efi/boot/bootaa64.efi
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> reading efi/boot/bootaa64.efi
> 78959 bytes read in 86 ms (896.5 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk sdhci at 7e300000.blk...
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> Scanning disk usb_mass_storage.lun0...
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> 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
More information about the U-Boot
mailing list