Bug#1056576: u-boot: Consider building apple/asahi variant
Hello Vagrant, Thanks for the followup. Comments below. On Fri, Jan 05, 2024 at 01:33:00PM -0800, Vagrant Cascadian wrote: > On 2024-01-05, Vagrant Cascadian wrote: > > On 2023-11-23, Andreas Henriksson wrote: > >> 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: > > ... > >>> > > 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. > > > > This seems like the main blocker at this point; I am hoping to upload at > > least 2024.01-rc6 to experimental shortly (and 2024.01 to unstable once > > it releases), and it would be nice to include a u-boot variant > > supporting these boards, but I am nervous about shipping patches. As > > you pointed out an unpatched version with asashi in the name might not > > be appreciated... but ... uh, er. Hrm. I would really like to get this > > in! > > I guess we could include a note in the description? Something like: > > This package does not include all patches shipped by the asahi project, > only patches that have been merged in mainline u-boot. I've been thinking the same thing about just putting info in the description (even if noone ever reads the long description :/). I think we should mention specific which issues to expect, fortunately many changes has already gone upstream for 2024.01 release so these are the high-level ones I can spot are still missing: - keyboard support on m2 models. - multi-os support (eg. multiple linux/bsd installs). - firmware loading (eg. on models with usb type-A ports). (Not sure how important the last one is to mention, could probably be left out.) Hopefully this is all resolved before Trixie freeze (and by then we might want to mention we only support M1/M2 and not M3 and whatever the Apple and Asahi Linux project has been up to in the meantime). FWIW. https://github.com/AsahiLinux/u-boot has already been rebased on latest denx/master (2024.01-rc) and the delta is now down to 20 commits. Devicetree updates is not relevant to us, ignoring those we also don't need the dtc changes - this would lower the number even more. The remaining commits are split up to nicely refactor things for implementing the three above mentioned features. Basically all now touching Apple-specific code/files (except adding a few function prototypes to header files, Kconfig/Makefile hookups and additions to xhci-pci-asmedia). I think we can go ahead with using the u-boot-asahi name and hope we can proceed as planned. > > > live well, > vagrant Regards, Andreas Henriksson
Bug#1056576: u-boot: Consider building apple/asahi variant
On 2024-01-05, Vagrant Cascadian wrote: > On 2023-11-23, Andreas Henriksson wrote: >> 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: > ... >>> > > 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. > > This seems like the main blocker at this point; I am hoping to upload at > least 2024.01-rc6 to experimental shortly (and 2024.01 to unstable once > it releases), and it would be nice to include a u-boot variant > supporting these boards, but I am nervous about shipping patches. As > you pointed out an unpatched version with asashi in the name might not > be appreciated... but ... uh, er. Hrm. I would really like to get this > in! I guess we could include a note in the description? Something like: This package does not include all patches shipped by the asahi project, only patches that have been merged in mainline u-boot. live well, vagrant signature.asc Description: PGP signature
Bug#1056576: u-boot: Consider building apple/asahi variant
On 2023-11-23, Andreas Henriksson wrote: > 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: ... >> > > 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. This seems like the main blocker at this point; I am hoping to upload at least 2024.01-rc6 to experimental shortly (and 2024.01 to unstable once it releases), and it would be nice to include a u-boot variant supporting these boards, but I am nervous about shipping patches. As you pointed out an unpatched version with asashi in the name might not be appreciated... but ... uh, er. Hrm. I would really like to get this in! live well, vagrant signature.asc Description: PGP signature
Bug#1056576: u-boot: Consider building apple/asahi variant
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
Bug#1056576: u-boot: Consider building apple/asahi variant
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. > > > > # 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 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 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.
Bug#1056576: u-boot: Consider building apple/asahi variant
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. > # 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 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. > 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? > 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? > # 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. > 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 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. > 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 2+ files is... arduous. And it would be somewhat ridiculous to do that twice. live well, vagrant signature.asc Description: PGP signature
Bug#1056576: u-boot: Consider building apple/asahi variant
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 , Andreas Henriksson > > > 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
Bug#1056576: u-boot: Consider building apple/asahi variant
On Thu, Nov 23, 2023 at 12:34:03PM +0100, Andreas Henriksson wrote: [...] > 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 [...] My mistake here, the PHY driver has already been upstreamed: https://source.denx.de/u-boot/u-boot/-/commit/b99c6357877da2829dc7fd73a50048e83abc53e2 What I wanted to mention was the firmware loading patches: https://lists.denx.de/pipermail/u-boot/2023-July/522962.html Regards, Andreas Henriksson
Bug#1056576: u-boot: Consider building apple/asahi variant
Source: u-boot Version: 2023.07+dfsg-1 Severity: wishlist X-Debbugs-CC: Tobias Heider , Andreas Henriksson 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)
