On Thu, Nov 23, 2023 at 08:16:43PM +0100, Tobias Heider wrote: > On Thu, Nov 23, 2023 at 10:51:04AM -0800, Vagrant Cascadian wrote: > > On 2023-11-23, Andreas Henriksson wrote: > > > 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. > > > > Thanks! I am guessing this class of hardware may represent a much larger > > community than many other boards already supported in u-boot.
Potentially, although most users interested in running Linux on their Apple Silicon probably will go with the distro choice that Asahi Linux project heavily promotes (currently Fedora Asahi Remix). We also have a long way to go before debian can offer a complete end-user ready alternative (without third party packages). At the moment Glanzmann provides a usable installer and his own apt repository which works as a stop-gap solution for people who want to run "debian", while we get proper debian in shape. I'm hopefully we'll be able to somehow provide a smooth upgrade from glanzmann installs to plain debian at some point in the future. > > > > > > > # 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. > > > > From u-boot 2023.10 doc/board/apple/m1.rst: > > > > $ cat m1n1.macho t8103-j274.dtb u-boot-nodtb.bin > u-boot.macho > > > > So, this suggests to me one has to pick exactly which .dtb to use which > > is presumably device-specific? Or is there some other process? I'd like to point out that src:u-boot is only expected to provide u-boot-nodtb.bin Creating the macho variant and installing it in the ESP will be done by `update-m1n1`. The asahi-fwextract + asahi-scripts packages contains all the integration glue for kernel, initramfs and bootloader updates. (Possibly they should also grow triggers for both m1n1 and u-boot-nodtb.bin to automatically launch update-m1n1.) Thus which dtbs will be used isn't really a concern from the src:u-boot maintainer side. However if you want to think about theoretical license compliance, a possibility would indeed be to use the dtbs coming out of u-boot project (although in reality those dtbs are probably the most outdated ones, and atleast at the moment you'd probably want to use something more up to date for better hardware support which likely means the dtbs from the asahi kernel fork). > > > > I am guessing we would not be able to provide all the possible > > "u-boot.macho" permutations out of the box (unless it is a very small > > number of variants), but can probably ship all the relevent components > > as long as they are in debian main. If the .dtb files come from > > somewhere other than debian main, we would probably have to build it as > > a contrib package. > > Not really, including multiple dtbs is possible. In fact the original > Asahi distribution based on Arch and Asahi Fedora both do that (and use > the dtbs provided by the kernel package). > > See: https://github.com/AsahiLinux/asahi-scripts/blob/main/update-m1n1#L20 > > > > > > > > m1n1 stage2 is already in debian, see: > > > https://tracker.debian.org/m1n1 > > > > Great! > > > > > > > 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. > > > > Ok, so worst case, there is at least one supported working platform even > > without patches? > > Indeed, plus some with partial support. > > > > > > > > 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 > > > > Here is the crux of the question ... can it use the .dtb files from > > debian main or does it need .dtb files from some sources outside of > > debian? > > > > That really depends on which kernel you are going to use as both > are developed in tandem. Since we don't have a working kernel in > the debian archive most people will use a 3rd party build including > more up-to-date dtbs. > I think this will really start to matter once we are nearing a release. > > > > > > # considerations > > > > > > 1/ are we willing to add another binary package to src:u-boot > > > building apple_m1_defconfig? > > > > I think that makes sense. > > > > > > > 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. > > > > I would be inclined towards u-boot-asashi (much like u-boot-sunxi is the > > sunxi community port of allwinner hardware), but with src:u-boot-asashi > > already in NEW, that makes it a more confusing situation. > > We can drop the one in new. There is no need to have both. > > > > > > > > 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. > > > > I am inclined towards starting with no patches or a minimal set of > > patches. The asashi folks do seem to generally do a good job of > > upstreaming, so support should improve over time. I'm not against going this route, my only concern is using the asahi name while shipping an "inferior" variant (no patches). The Asahi Linux people have been very good at being end-user focused, fixing all kind of bugs and really go above and beyond to not compromise on end user experience. Not sure they'd appreciate us shipping it under their name while exposing "already fixed" bugs.... but what do I know. We can always add patches later I guess. The Trixie freeze is not happening soon and we're not providing any installer yet, so it should just be a few #debian-bananas people trying this out for a while still I guess. > > > > I have been working on getting 2023.10 into unstable, and before too > > long 2024.01~rc variants should land in experimental, presumably with > > more upstreamed patches. Indeed, however still without functional USB and M2 keyboard AFAIK. Maybe/hopefully in a future update.... > > That sounds great. > > > > > > > > Debian has a bananas-team that can take responsibility for testing > > > and maintaining software, see: > > > https://wiki.debian.org/Teams/Bananas > > > > Glad to know! > > > > > > > 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 > > > > Yes, it does seem a shame to duplicate all of u-boot, although it really > > depends on how the upstreaming progress goes. > > > > I can personally tell you reviewing the copyright and licesning > > information for a project with 20000+ files is... arduous. And it would > > be somewhat ridiculous to do that twice. > > > > > > live well, > > vagrant > > Regards, Andreas Henriksson
