From Fedora Project Wiki

Automatic DTB selection for aarch64 EFI systems

Summary

Make the aarch64 Fedora Live ISO images work OOTB on Windows on ARM (WoA) laptops by automatically selecting the right DTB at boot.

Owner

Current status

Detailed Description

This change will use a modified kernel image which embeds the systemd-stub boot stub, hardware-id to DTB mappings and relevant DTB files. The systemd-stub will use the embedded mappings to find the right DTB file and automatically load that DTB file. Whereas before users would need to modify the ISO image to manually add the right DTB file, otherwise the image would not work.

The modified kernel image is in essence an incomplete UKI containing just the systemd-stub and the DTBs, but not an initrd nor a kernel commandline. The host generated initrd and host specific commandline will still be supplied by GRUB as usual, including allowing the user to make changes to the commandline through GRUB.

The embedded stub and DTBs cause the vmlinuz size to increase by approx. 3MB from ~16MB to ~19MB.

The main reason for making this change is to allow the prolific Windows on ARM laptop models boot Fedora OOTB.

The following are considered out of scope for this specific change, these could be looked at for a future change proposal. For this specific change the intent is to keep the changes minimal:

  • The vmlinuz EFI with the systemd-stub and DTBs embedded should work fine as the main vmlinuz image for all boards, but this may require changes to U-Boot builds without an EFI payload and this will need testing on many different boards.

Alternatives

While preparing this change proposal 4 possible options for auto DTB loading where considered:

DTB-loader

DTB-loader is an EFI driver which either looks up a DTB by CHID from $ESP\dtb\ (original dtbloader) or has a bunch of DTBs + a CHID mapping table builtin (TravMurav/dtbloader).

This has a number of disadvantages:

1. This uses a fixed DTB path / fixed builtin DTBs where as we really want to have separate DTBs per kernel version, since the DTB sources come bundled with the kernel and are regularly updated. Theoretically using an older/newer DTB should work but at a minimum this will likely cause newly supported features to not work.

2. Since this is an EFI driver it will not be automatically loaded from boot media unless dropped in $ESP\EFI\systemd and we switch to systemd-boot .

3. Since this is an EFI driver secureboot wise it needs to be signed by a key known to the firmware, rather then with Fedora's own key. IOW this is not signature checked by the shim but directly by the firmware. For signing purposes the original aarch64-laptops version likely is completely off the table since that would mean loading an unsigned DTB and for the TravMurav version with DTBs builtin it would need to be updated frequently because of 1. which is not compatible with it being signed by a third party.

DTB-loader in the laptop UEFI firmware

The Lenovo ThinkPad X13s has a DTB-loader similar to the original dtbloader from DTB-loader above built into its UEFI firmware, this can be enabled in the firmware by setting the "Linux Boot (Beta)" option.

Advantages of this approach:

1. In an ideal world WoA UEFI firmware would provide enough information to Linux (either through ACPI or a DTB) for Linux to be able to just work on new laptop models without any adjustments. So if we can get WoA UEFI firmwares to actually provide this info that would be great. Note though that the X13s "Linux Boot (Beta)" option is not this, see disadvantages below.

Disadvantages of this approach:

1. By far the biggest disadvantage of this approach is that it requires the laptop vendors to care enough about supporting Linux on to actually add this as an option to the laptop's firmware. Based on almost a decade of experience supporting x86 laptops most vendors will not care about this.

2. The current X13s "Linux Boot (Beta)" option just enables DTB loading, it does not include a DTB in the UEFI. The DTB itself must still be supplied by the user by copying it to the root of the internal disk ESP partition. IOW even on the X13s things do not work OOTB.

3. DTBs are constantly evolving and often an updated DTB is necessary to get features only supported newer kernels, like e.g. camera support working. A DTB embedded in the firmware will quickly grow stale, while things work best when version matching the DTB and the kernel.

UKI with auto dtb selection for Live ISOs

I do not believe that Fedora is ready (yet?) to fully switch to using UKIs with most setups expecting host specific initrds (UKI's can allow a custom / host specific commandline if none is present in the UKI).

But for the Live ISO images the initrd gets generated during image-creation, so we could boot an UKI there, using the auto DTB selection feature of systemd-stub.

This could then be combined with some anaconda changes to retrieve which DTB was chosen somehow and then write that DTB to /etc/default/grub .

Advantages of this approach:

1. Only impacts the Live ISO images.

Disadvantages of this approach:

1. Requires anaconda changes and the anaconda team already has bandwidth problems.

2. This would permanently diverge how the Live ISOs boot from other media, with now clear path to unification.

UKI without initrd

This is the chosen solution as described in Detailed Description.

Advantages of this approach:

1. We can add a new kernel-dtb-loader sub-package with a vmlinuz with the stub + DTBs embedded and switch the Live ISO images over from kernel-core to kernel-dtb-loader, without needing further changes anywhere else.

2. This leaves everything the same as we currently have it wrt initrd generation + cmdline passing.

3. Eventually we could add the stub + DTBs to the vmlinuz inside kernel-core and drop kernel-dtb-loader resulting in a unified boot approach for aarch64 with EFI auto DTB loading everywhere.

Disadvantages of this approach:

1. For now vmlinuz will grow by about 3 MB which is not a problem, but as more DTBs get added it will grow more. There are several ideas to reduce the growth but those are not implemented yet.

Feedback

  • "Shouldn't Windows on Arm laptop vendors just fix the ACPI tables so that they fully describe the hw and things will just work booting in ACPI mode?"

    We definitely want for future WoA hardware to have enough info in the ACPI tables to allow things to work without a DTB but that is likely still far away and for current systems we need some sort of workaround.

    At least WoA laptops have OOTB UEFI support, so that they can boot a generic aarch64 image, without first needing to flash a custom U-Boot with EFI payload; and their UEFI contains enough info to identify the system and pick the right DTB.

Benefit to Fedora

Improve the live ISO boot and install experience on WoA laptops to be on par with x86_64. Making it much easier for users to try and use Fedora on WoA laptops. Also see User Experience.

Scope

  • Proposal owners:
  1. Package Stubble done.
  2. Add a new kernel-dtb-loader sub-package Pull Request.
  3. Fix Fedora's GRUB failing to boot kernel images with the systemd-stub fixed.
  4. Switch the aarch64 Live ISO images from kernel-core to kernel-dtb-loader Pull Request.
  • Other developers:
  1. kernel developers: review and merge the pull-request to add the kernel-dtb-loader sub-package
  2. grub developers: review and merge the GRUB fixes to fix kernels with the systemd-stub not booting
  3. fedora-kiwi-descriptions developers: review and merge the pull-request to switch to kernel-dtb-loader
  • Release engineering: #Releng issue number
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy: This change will hopefully lead to more Fedora users on aarch64 WoA laptops; and some of these new users will hopefully become contributors.

Upgrade/compatibility impact

Existing installs will keep using the kernel-core package, with the DTB specified manually in /etc/default/grub, after upgrading so nothing will change for them.

How To Test

Note the changes have been (temporary?) reverted due to them breaking some openQA tests, so this cannot be tested atm.

Starting with 20260213 nightly images all the necessary changes to test are in place. This can be tested as follows:

  1. Download a nightly aarch64 Fedora Live ISO image.
  2. Write (e.g. "dd") this to a USB stick.
  3. Boot an aarch64 laptop, e.g. The ThinkPad T14s gen 6, from the created Live USB.
  4. Before booting the kernel commandline must be edited in grub to add " clk_ignore_unused pd_ignore_unused" to the kernel commandline. This works around a long standing kernel issue, upstream discussions on solving this issue are ongoing.
  5. Note it will take 1-2 minutes before the Fedora spinner shows, this is expected. This should successfully boot into the live environment.
  6. Optionally do an install to the laptops internal disk from the Live USB.

User Experience

Currently installing Fedora on a WoA laptop is quite challenging requiring manually modifying the Live ISO see e.g. this discussion.

The goal of this change is to make installing Fedora on WoA laptops just as easy as on a x86_64 laptops, download a Fedora aarch64 Live ISO, write it to an USB stick and boot + install.

Dependencies

This change depends on the kernel, GRUB and kiwi-description developers agreeing with and integrating the proposed changes.

Contingency Plan

  • Contingency mechanism: Revert the kiwi-description change for the Live ISO images back to using kernel-core. The other changes can stay in place without causing any issues.
  • Contingency deadline: Ideally the decision to revert would be made before the Beta Freeze, but if serious issues are found during Beta testing it could also happen before the Final Freeze.
  • Blocks release? Yes (if not reverted)

Documentation

Release Notes

To Do.

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Automatic_DTB_selection_for_aarch64_EFI_systems&oldid=762411"