On Thu, Nov 23, 2023 at 12:34:03PM +0100, Andreas Henriksson wrote: > 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.
Thank you for the detailed write-up! I think you are right, a new binary package based on the existing u-boot is certainly preferable over having a separate source package. It also looks like there is progress in getting the changes merged upstream. My preferred choices would be 1/ yes, 2/ u-boot-asahi and 3.2/ because keyboard support in u-boot actually is important to boot usb disks if you break your system and that patch shouldn't be huge. > > > 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 I'd be happy to drop that if we decide to go with your proposal > > > 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
