Apple Silicon Mac support packages (v2)

[dkwo]

This PR can boot from a USB stick using void-linux/void-mklive#281
I thank @slimjimsoftware @Skirmisher and @Calandracas606 for contributing and/or testing.

[ci skip]
Remarks:

• if using seatd and wlroots, see https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3911
• upstream eudev patch for sound eudev-project/eudev@917ae64

[dkwo]

After installing in the usual way (chroot), it seems to run smoothly on my m1 macbook air.
I natively rebuilt all the packages for aarch64.
The script update-vendor-firmware runs smoothly.
Next on the list is updating kernel.

[Skirmisher]

Note that the way Asahi reference distro handles things like firmware is still in flux; they recently changed it so that "update-vendor-firmware" is run in the initrd, for example. They also have some dracut stuff for Fedora that you can source if it makes sense for Void. Worth checking on pages from the Asahi wiki such as this if you haven't already, as well as asking in their IRC channels if you have questions. marcan has expressed that Asahi would like to help downstream distros make sense of the Asahi work so they can function properly, instead of trying to do it on their own and shipping broken packages (as happened recently with Manjaro).

[dkwo]

Thanks for the suggestions, and for doing the initial hard work.
They have a hook for mkinitcpio, but not for dracut yet.
Since the dracut config can be distro-specific, I thought we'd ship our own, but I'm open to suggestions.

[dkwo]

Upon some minor config changes, I was able to boot the latest 6.0 series kernel.
It's imperative to run update-m1n1 upon a kernel update, otherwise it won't boot.
It'd be nice if someone could take a second look at the config, to verify that it's inline with Void's standards.

[dkwo]

At this point, I think only kernel and m1n1 are really needed, the rest can be dropped,
as m1n1 can boot the initramfs directly. Some work is ongoing as how to load firmware.
Perhaps I'll just keep a script to update m1n1 after every kernel update.

[dkwo]

@Skirmisher Now shipping a kernel hook for m1n1, which allows to either have the kernel or uboot as payload.
In my tests it works fine, using

cat /etc/m1n1.conf
chosen.bootargs=earlycon debug root=/dev/nvme0n1p6 rootwait rw loglevel=4

More eyes are welcome :)

[Anachron]

This is awesome!

Just a quick question:

@dkwo you said

I natively rebuilt all the packages for aarch64.

Is this phrased correctly? Do we really need to rebuild all aarch64 packages? If yes, should we create another aarch?

Do you have interest in also porting the gpu drivers to Void Linux?

[Skirmisher]

I natively rebuilt all the packages for aarch64.

Is this phrased correctly? Do we really need to rebuild all aarch64 packages? If yes, should we create another aarch?

"The packages" in this context is just referring to the ones in this PR. dkwo had to cross-compile the Asahi packages from another machine before making a system image to install on the M1. But after that, Void on the M1 can natively compile the packages; dkwo is confirming that native compilation is also working. The Apple Silicon machines can use Void's existing aarch64 packages just fine.

Do you have interest in also porting the gpu drivers to Void Linux?

There is nothing to "port", the code is already in the same tree that the normal Asahi kernel is built from. It's still a work in progress though, so Asahi Linux (the reference distro) turns it off for their default kernel package, and offers a separate linux-asahi-edge package for testing the GPU driver and other less-stable changes (but the kernel version is otherwise identical).

We could add a similar package, but it wouldn't be a good idea; the Asahi developers are frequently updating both the kernel and their mesa driver (which we would also need to build for the GPU to work), and we shouldn't be adding dev builds to Void. All the Asahi work is supposed to be upstreamed as soon as possible, and while the GPU driver is much bigger than other components and will not be upstreamable for a long time, it is better for us to wait for major features to be properly released. (The kernel is the usual exception here, since at this stage there are a lot of individual additions that make the user experience on M1/M2 machines more complete, but each feature need to be negotiated with mainline Linux developers before making it into an upstream release, even if it only needs minor tweaks to be "done". So, the platform kernel package is likely to stick around for a while, and it keeps to itself in the package tree. We are very lucky that Asahi Linux is diligent about tagging kernel releases and only updating their "stable" package with known-good changes.)

Now, it might be nice to have templates for Asahi dev packages anyway, the hardware is plenty capable of building those updates itself :p But they shouldn't live in void-packages and take up Void maintainers' time and effort.

[dkwo]

Exactly as @Skirmisher said. I agree that GPU/mesa might be a bit premature.

[Calandracas606]

I've spent a while working on getting a good kconfig, and here's what i've gotten it to: https://gist.github.com/Calandracas606/332d2c42ce2713c4bbf799a3470ec74a

It's based on the guidance from https://github.com/AsahiLinux/docs/wiki/Kernel-config-notes-for-distros, and from the references here: https://github.com/zzywysm/asahi-kernel-configs, along with many of the default settings that void sets for hardening, etc.

As many modules which are not-applicable have been removed as possible, while still building most peripherals that could reasonably be connected to the system as modules

[dkwo]

@Calandracas606 I made some changes myself, I will look at that kconfig as well.

[Calandracas606]

lsp plugins has been merged: ba5adad

I think this is pretty much good to go now?

[dkwo]

My main concern is now wlroots not doing redshift :) So yes, I'd say this is good to go.

[Calandracas606]

I do still insist that there is a lot of un-needed drivers in the kernel config, and generally a lot of things in there which are worth reviewing

[dkwo]

As for following Void's best practices, I will check again and try to be as close as possible to its aarch64 config.
@Calandracas606 Maybe you can point out specific things that need to be changed?

As for turning off unneeded stuff: this kernel can work as a generic aarch64 kernel for 16k pages devices, which is what asahi-fedora does. This would also be my preference. I understand that we could instead provide an Apple-specific kernel, which could then be a lot more stripped down (and maybe be built in 6 min instead of the current 10).

Maybe other users or some maintainer can suggest which one would be preferred for Void?

[Calandracas606]

As for following Void's best practices, I will check again and try to be as close as possible to its aarch64 config. @Calandracas606 Maybe you can point out specific things that need to be changed?

I'm currently working on making the config much closer to the aarch64 one. Will report back when I'm done