Hi,
I've updated my DtbLoader with what I think will be the final approach for dealing with the fact that all of these laptops can have one of several panels installed (I can resend the patchset to the aarch64- laptops list if that is useful):
https://github.com/robclark/edk2/commits/dtbloader
This is the third iteration of panel-picking, now using dtb overlays to patch the dtb according to which panel is installed on the laptop. I think this is the approach that will finally get upstream kernel buy-in, namely because it doesn't require any kernel patches.
Because of the dtb overlay approach, for distro boot using DT, distro's will need to use DtbLoader, or handle applying the dtb overlay somewhere else.
Overview ========
The patchset I have on top of Leif's original DtbLoader handle two things to make this a useful thing for distro boot, and in particular having a single image (or installer) which can support multiple laptops:
1) pick a device specific dtb based on SMBIOS tables 2) apply a panel specific dtb overlay based on UEFIDisplayInfo
In particular, it tries to load dtb from (in order, paths relative to EFI system partition where DtbLoader is installed):
1) \dtb$SysVendor$ProductName-$BoardName.dtb 2) \dtb$SysVendor$ProductName.dtb
and panel overlay dtb from:
1) \dtb$SysVendor$ProductName-$BoardName-panel-$PanelId.dtb 2) \dtb$SysVendor$ProductName-panel-$PanelId.dtb 3) \dtb\panels\panel-$PanelId.dtb
with this in place, the correct dtb is loaded before grub starts, so from distro PoV it is all just a config table provided by the firmware.
(Also, based on comments from Ard on IRC, it sounds like we'll also use DtbLoader to avoid needing the efi=novamap hack, which I assume is also useful to distros to avoid device specific hacks.)
Installation ============
I've put a pre-built DtbLoader.efi here:
https://people.freedesktop.org/~robclark/DtbLoader.efi
1) copy DtbLoader.efi to EFI system partition2) copy dtb files to EFI system partition with the layout described above 3) Boot Shell.efi (overwrite \EFI\BOOT\BOOTAA64.EFI with Shell.efi) 4) switch to boot device (FS2: in my case) 5) use bcfg to install
Shell> fs2: FS2:> bcfg driver add 1 \DtbLoader.efi "dtb loader" FS2:> reset
At this point you can copy normal shim back to \EFI\BOOT\BOOTAA64.EFI.. on subsequent reboots, efibootmgr will load DtbLoader.efi for you.
Open Issues ===========
1) The path to DtbLoader.efi is stored with the full EFI devicepath.. so installer media would have to install/load it's own DtbLoader.efi and dtb files? Which is maybe suboptimal, especially for a laptop released after the installer media was baked. (The DtbLoader.efi shouldn't need to change, but a new laptop based on an already supported SoC would at least need new dtb tables)
a) maybe the DtbLoader is installed before the user boots the install media.. but in this case, if distro is installing to internal disk and replacing the EFI partition, it would need to take care to preserve DtbLoader and the \dtb directory
2) How to handle dtb updates? Should the distro do this? Or is there some way we can use fwupd to push out dtb updates outside of distro? Or??
3) Constructing the \dtb directory.. currently there isn't any link between dtb's that come out of kernel build, and where DtbLoader.efi expects to find things. I guess this is managable with a shell script for now. And if we push out dtb updates outside of the distro then it is really just a thing for whatever generates the "firmware update" package to care about. But if we have distro's updating the dtb files in the EFI system partition then we should come up with something better
4) ACPI vs DT boot? I guess this is easy, if DtbLoader doesn't find a dtb to load (ie. \dtb\LENOVO\81JL.dtb, etc), it doesn't change anything. So DtbLoader.efi should be safe to load on all aarch64 devices.
5) Secure-boot? Or at least not interfering with secure-boot support on devices using ACPI boot? I *guess* if DtbLoader.efi is not signed and BIOS is configured for secure-boot, then efibootmgr won't load it. So no-harm, no-foul?
Anything else?
BR, -R