Source: u-boot Version: 2023.07+dfsg-1 Severity: wishlist X-Debbugs-CC: Tobias Heider <m...@tobhe.de>, Andreas Henriksson <andr...@fatal.se>
Dear Maintainer, I'm opening this bug report to discuss the potential of building another u-boot variant in a new binary package from src:u-boot for "Apple Silicon" machines. The Asahi Linux project has been working on bringing Linux to the newer ARM based line of laptops and stationary (mac mini) by Apple, a.k.a. M1, M2 and just released generation M3. # The overall picture of booting Linux on apple silicon A normal users boot procedure would look something like: Apple iBoot -> m1n1 (stage1) -> m1n1 (stage2) -> u-boot (EFI) -> generic distro EFI boot managers (grub, systemd-boot, etc) m1n1 stage1 is installed by the Asahi Linux installer. m1n1 stage2 + u-boot + dtbs are bundled together and installed as boot.bin on the EFI partition. Apple/macOS does not make use of EFI. The purpose of u-boot is to provide the EFI environment to allow "generic distro boot". m1n1 stage2 is already in debian, see: https://tracker.debian.org/m1n1 # Upstream status The Asahi Linux project has already upstreamed most of their work so simply building `apple_m1_defconfig` is already possible. However they also maintain their own fork of it at: https://github.com/AsahiLinux/u-boot/tree/asahi-releng This fork currently contains 43 additional patches (some already upstreamed, some posted for review, some simply defconfig changes, some dts updates, etc). I've looked over the 43 patches and here's my *perception* of the current status: The current upstream apple_m1_defconfig should be usable for booting (from internal storage) on M1 machines. The M2 can possibly boot, but keyboard driver is not yet upstream - so no interaction with u-boot possible. M3 is not yet supported at all by Asahi Linux (the usual notice of expect atleast 6 months before this happens has been announced). Notable here is that Apple iBoot does not support USB booting, so booting from external media will have to be happening with the help of U-Boot. Unfortunately U-Boot USB support has a number of as I understand it generic bugs that pretty much prevents real-world usage, eg. not support >2TB usb drives, etc. Patches to fix these problems has been posted for review (with mostly positive feedback): https://lists.denx.de/pipermail/u-boot/2023-October/535517.html https://lists.denx.de/pipermail/u-boot/2023-October/535529.html https://lists.denx.de/pipermail/u-boot/2023-October/535534.html https://lists.denx.de/pipermail/u-boot/2023-October/535535.html This is the bulk of the code changes outside apple specific files in the current 43 patch series living in asahi fork of u-boot. There was previously also an attempt to upstream the Apple Type-C PHY dummy driver: https://lists.denx.de/pipermail/u-boot/2023-July/522961.html Some of the patches updates devicetree files (dts) which are completely apple-specific and should not have any chance to affect anything else, but these are also completely unused so does not neccessarily need to be included. The asahi tools to update the EFI boot.bin that combines m1n1, u-boot and dtbs uses the dtbs from the installed kernel, see: https://tracker.debian.org/asahi-fwextract https://tracker.debian.org/asahi-scripts # considerations 1/ are we willing to add another binary package to src:u-boot building apple_m1_defconfig? 2/ should we name the binary package u-boot-apple or -asahi? The existing third-party packages of the asahi fork calls theirs u-boot-asahi. 3/ do we include patches? 3.1/ No patches. If this is the desired path I can volunteer to test that it boots on my M1 machine. Other machines should probably be considered unsupported for now, even though they might have limited usefulness. 3.2/ Minimal set of patches. We identify what we consider crutial only patches and recruit volunteers to test. M2 keyboard? USB? etc... 3.3/ All asahi patches. We consider it simpler to just sync all patches with the asahi fork (even though some are even unused, like the devicetree patches). We trust the Asahi Linux project in their quest to upstream all their work and that they will rebase on newer releases and make our job easy. Debian has a bananas-team that can take responsibility for testing and maintaining software, see: https://wiki.debian.org/Teams/Bananas Also worth noting is that the asahi fork of u-boot has been uploaded and currently sitting in NEW as src:u-boot-asahi. https://ftp-master.debian.org/new.html As mentioned already on the ITP, I think it's excessive to duplicate all of u-boot over 43 patches (and hopefully shrinking): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042471 Thanks for considering, Andreas Henriksson -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (400, 'unstable'), (300, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 6.5.0-asahi-00780-g62806c2c6f29 (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
