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

Sat Nov 18 04:25:29 UTC 2017

On Tue, Oct 10, 2017 at 04:48:01AM +1100, Jonathan Gray wrote:
> On Mon, Oct 09, 2017 at 01:06:26PM -0400, Rob Clark wrote:
> > 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.
> 
> Indeed, it seems to only end up calling efi_disk_add_dev() for
> part 1 in that loop:
> 
> ## Starting EFI application at 01000000 ...
> Scanning disk sdhci at 7e300000.blk...
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 1
> ## Valid DOS partition found ##
> Scanning disk usb_mass_storage.lun0...
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 1
> ## Valid DOS partition found ##
> Found 2 disks
> 
> If I change the code there to match other callers of part_get_info()
> I get a MEDIA_DEVICE type and can boot.
> 
> ## Starting EFI application at 01000000 ...
> Scanning disk sdhci at 7e300000.blk...
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 1
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 4
> ## Valid DOS partition found ##
> Scanning disk usb_mass_storage.lun0...
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 1
> ## Valid DOS partition found ##
> ## Valid DOS partition found ##
> efi_disk_register calling efi_disk_add_dev for part 4
> ## 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 looking for type 4 i=4 type 4
> depth=4
> i=0

While U-Boot 2017.11 release works with vexpress/qemu with the
efi loader it is broken on at least rpi_3 and tinker-rk3288.
MEDIA_DEVICE is not found again.

U-Boot 2017.09 (Nov 16 2017 - 04:05:33 -0700)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci at 7e300000: 0
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
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
78959 bytes read in 75 ms (1 MiB/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

U-Boot 2017.11 (Nov 15 2017 - 13:14:19 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci at 7e300000: 0
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
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
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...
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
i=4
i=5
>> 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
boot>
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
 failed(6). will try /bsd
Turning timeout off.
boot>