Wiki: https://fedoraproject.org/wiki/Changes/Automatic_DTB_selection_for_aarch64_EFI_systems
Discussion Thread: https://discussion.fedoraproject.org/t/177289 **This is a proposed Change for Fedora Linux.** This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == 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 == * Name: [[User:jwrdegoede| Hans de Goede]] * Email: [email protected] == Detailed Description== This change will use a modified kernel image which embeds the [ https://github.com/ubuntu/stubble/ Stubble] boot stub, hardware-id to DTB mappings and relevant DTB files. The Stubble 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 a UKI boot-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 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: * Stubble is a fork of systemd-stub there is no reason why the same should not be possible with systemd-stub. Testing has shown that ATM using systemd-stub this way does not work, why this does not work has not been investigated yet. For now we are going with Stubble. * The vmlinuz EFI with the Stubble 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 3 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. == 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?" <br><br>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. <br><br>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 | User Experience]]. == Scope == * Proposal owners: # Package Stubble [https://bugzilla.redhat.com/show_bug.cgi?id=2421973 Review Request]. # Submit a kernel spec pull-request adding a new kernel-dtb-loader sub-package similar to how kernel-uki-virt was recently added. # Fedora's GRUB currently fails to boot kernel images with the Stubble stub. This is caused by downstream Fedora patches (specifically 0253-Add-support-for-Linux-EFI-stub-loading-on-arm-archit.patch). I've a set of patches fixing this. # Submit a fedora-kiwi-descriptions pull-request to switch the aarch64 Live ISO images from kernel-core to kernel-dtb-loader, so that these ISOs use the new vmlinuz with the Stubble stub and embedded DTBs. * Other developers: # kernel developers: review and merge the pull-request to add the kernel-dtb-loader sub-package # grub developers: review and merge the GRUB fixes to fix kernels with the Stubble stub not booting # fedora-kiwi-descriptions developers: review and merge the pull-request to switch to kernel-dtb-loader * Release engineering: [https://pagure.io/releng/issues #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. == Early Testing (Optional) == N/A == How To Test == Once the nightly images use the new kernel-dtb-loader package, this can be tested as follows: # Download a nightly aarch64 Fedora Live ISO image. # Write (e.g. "dd") this to a USB stick. # Boot an aarch64 laptop, e.g. The ThinkPad T14s gen 6, from the created Live USB. # This should boot into the live environment without requiring any manual setup. # Optionally do an install to the laptops internal disk from the Live USB. The install should also boot without requiring any manual setup. == User Experience == Currently installing Fedora on a WoA laptop is quite challenging requiring manually modifying the Live ISO see e.g. [ https://discussion.fedoraproject.org/t/snapdragon-x-elite-fedora-42-system-bring-up-and-looking-for-collaborators-or-sigs/ 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 == * [ https://discourse.ubuntu.com/t/spec-stubble-a-secure-boot-friendly-device-tree-loading-efi-stub/ Ubuntu Stubble proposal] * [ https://discourse.ubuntu.com/t/what-s-new-for-generic-arm64-desktop-isos-in-25-10/ Ubuntu 25.10 Stubble documentation] == Release Notes == To Do.
-- _______________________________________________ devel-announce mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
