> 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. Cheers, Mark _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
