On Fri, Aug 4, 2017 at 4:41 PM, Mark Kettenis <[email protected]> wrote: >> From: Rob Clark <[email protected]> >> Date: Fri, 4 Aug 2017 15:31:55 -0400 > > Hi Rob, > > OpenBSD has been an early adopter of efi_loader and pretty much > completely relies on it for booting OpenBSD/armv7 and OpenBSD/arm64. > We use our own bootloader which is fairly lightweight. Obviously we'd > like to keep it working if this patchset gets adopted. We don't make > use of EFI variables and don't really plan to make use of them on our > ARM platforms. But obviously we have to deal with device paths... > >> Also, create disk objects for the disk itself, in addition to the >> partitions. (UEFI terminology is a bit confusing, a "disk" object is >> really a partition.) This helps grub properly identify the boot device >> since it is trying to match up partition "disk" object with it's parent >> device. >> >> Now instead of seeing devices like: >> >> /File([email protected])/EndEntire >> /File(usb_mass_storage.lun0)/EndEntire >> >> You see: >> >> /ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire >> >> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c00000000,1,1)/EndEntire >> >> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,200000,dd904a8c00000000,1,1)/EndEntire >> >> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c00000000,1,1)/EndEntire >> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire >> >> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,60000,38ca680200000000,1,1)/EndEntire >> >> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca680200000000,1,1)/EndEntire >> >> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca680200000000,1,1)/EndEntire >> >> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca680200000000,1,1)/EndEntire >> >> This is on a board with single USB disk and single sd-card. The >> UnknownMessaging(1d) node in the device-path is the MMC device, >> but grub_efi_print_device_path() hasn't been updated yet for some >> of the newer device-path sub-types. > > ..and what you're sketching out here should work with recent enough > versions of our bootloader. > > However, to me having an ACPI Device Path component in there doesn't > make much sense on a board without ACPI. It certainly doesn't help > mapping a boot path back to an actual hardware device. Wouldn't it be > more logical to a Hardware Device Path there instead? In particular a > Memory Mapped Device Path would make a lot of sense as the start > address would make it fairly easy to do the mapping. >
It was pretty much an arbitrary choice, and it wouldn't be hard to change. From my reading of the grub code, all it really cares about is that there is *some* parent of the "partition" HD device. I'm not really sure what maps best in a UEFI world to the "soc" node in a device tree world. I'm certainly open to changing this. It would be cool if you have a chance to give this a try w/ OpenBSD and let me know if you run into issues. I want this to be something that works across-distro so I'll try to help as much as I can. (Not sure if there is an OpenBSD port for db410c, but I guess there is always qemu..). Fwiw, if git pull/cherry-pick is easier than grabbing patches from list, then [1]. [1] https://github.com/robclark/u-boot/commits/enough-uefi-for-shim BR, -R _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
