On Mon, Oct 9, 2017 at 12:41 PM, Jonathan Gray <j...@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 <j...@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 <j...@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 <j...@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 <j...@jsg.id.au> >> >> >> >> Signed-off-by: Rob Clark <robdcl...@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@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 sd...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot