On Mon, Dec 9, 2019 at 9:01 AM Dimitri John Ledkov xnox@ubuntu.com wrote:

On Sun, 8 Dec 2019 at 22:36, Rob Clark robdclark@gmail.com wrote:

...

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

Is SysVendor here i.e. Lenovo or i.e. Ubuntu? Shouldn't these be under \EFI$DISTRO with Linux fallback? Ie.

The $SysVendor here is "LENOVO" (or "Dell Inc.", etc)..

\EFI\ubuntu\dtb$SysVendor$ProductName-$BoardName.dtb \EFI\ubuntu\dtb$SysVendor$ProductName.dtb \EFI\Linux\dtb$SysVendor$ProductName-$BoardName.dtb \EFI\Linux\dtb$SysVendor$ProductName.dtb

Such that e.g. ubuntu distro can update dtbs, and those are used by ubuntu boot. ANd it may mange update to Linux ones, which are used as fallbacks if distro specific ones not found?

This goes to the question of "do we want the distro to upgrade the dtbs".. hopefully we can do it outside of the distro, but ideally we don't have different dtb for different distros.

This ends up making it harder before patches land upstream (ie. during development, sometimes the dt changes in ways not backwards compatible). But by the time patches land in upstream kernel, the dtb should be stable.. ie. you can always use newest dtb with older kernel, and you can use older dtb with newer kernel (although possibly without support for some newer features)

Or does that make no sense at all?

...

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
2. Boot Shell.efi (overwrite \EFI\BOOT\BOOTAA64.EFI with Shell.efi)
3. switch to boot device (FS2: in my case)
4. 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?

Well, for that thing to be trusted in secureboot something trust worthy needs to sign it. And it still loads unsigned .dtbs thus I don't think it will be signed with Vendor or MS keys.

Can the dtbs be embeded inside DtbLoader.efi? Or like can we sign DtbLoader with something that shim trusts and allow it to execute anyway?

I guess the first thing is just make sure that having DtbLoader installed doesn't break secure ACPI boot.

I suppose dtbs could be embedded inside DtbLoader.efi.. but that means rev'ing DtbLoader, instead of just pushing new \dtb directory tree. I guess this is related to the question of how do we deploy and update the DtbLoader.efi + dtb files.

At the moment, I'm still failing to understand the benefit of doing this vs distros integrating things by-hand (ie. shipping and autoloading dtbs with grub / kernel cmdline) from a single distro point of view. Especially if this still does not allow secureboot. I guess once one does DtbLoader stuff once, one can autoload any distro / vanilla kernels?

yeah, the goal is to support any distro and/or vanilla kernels

BR, -R