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 20000+ files is... arduous. And it would
be somewhat ridiculous to do that twice.
live well,
vagrant
signature.asc
Description: PGP signature
