New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apple Silicon Mac support packages #36390
Conversation
Great work! Can you rebase on 5.19? Do you know whether one can skip grub and use something like efibootmgr here? |
I tried to add an image for this in void-mklive. |
I tested on a M1 macbook air: the above-mentioned PR to mklive is able to boot the kernel from this PR.
I believe p1 is my efi partition, p2 is linux root, ignore the rest: could anyone confirm before I proceed? |
Ok, it turns out I was dumb: |
@Skirmisher Do you mind moving the |
It seems my issues have already been fixed by the script |
Actually, asahi provides the https://github.com/AsahiLinux/asahi-scripts repo, with a makefile that works for arch and fedora. |
It seems there's no way to have persistent EFI variable storage, so we're stuck with grub for now. I'm waiting until they tag a kernel of the 6.1 series, which is supposed to support wifi out of the box, |
Made some changes, updated some things in #39796 |
This PR contains the closure of packages necessary to run Void Linux on Apple Silicon (M1) Macs, following the Asahi Linux Open OS Ecosystem document and borrowing from their scripts and PKGBUILDs.
Following this, I will submit changes to void-mklive that enable creation of M1 Mac live images, intended to be booted from an external drive via EFI after using the Asahi Linux install script and selecting "UEFI environment only".
Note on "asahi" nomenclature
Asahi Linux's about page states "Asahi Linux is a project and community with the goal of porting Linux to Apple Silicon Macs". The FAQ entry "Is this a Linux distribution?" clarifies that Asahi Linux represents the overall effort to port Linux etc. to these machines, and the distribution of the same name largely serves as a reference, until such time as all the relevant changes are upstreamed. Thus, the packages are named "asahi" in reference to Asahi Linux as a platform.
Packages
asahi-base
Metapackage that depends on the other three packages (and dracut). Contains the following support files:
dracut-asahi.conf
: Adds platform support kmods to the initrd.update-grub-image
: Updates the GRUB core image on the ESP, embedding a config that points to the boot partition where the GRUB config + kernels are stored, as modeled by Asahi upstream. Modified from Asahi sources. Not executed automatically; intended to be run by an install process, and manually by the user at their discretion, just like standardgrub-install
(which should be run before this script whenever GRUB is installed/updated).update-vendor-firmware
: Updates local system firmware from the ESP, where it is placed by the Asahi installer (and subsequent install/upgrade mechanisms invoked from macOS recovery) after being retrieved from Apple, as described in the Open OS Ecosystem document. Modified from Asahi sources. Currently not invoked by anything; Asahi specifies that it should be run on each boot, but I punted on that for the moment.linux-asahi
The Linux kernel, built from Asahi sources and config. Uses 16K page size due to the M1 IOMMU, which means some stuff breaks. There is reportedly a patch to enable 4K page size, but I don't know when or if it will be stable, or if it will really be desirable (unless people really don't want to keep building a platform kernel once most stuff is upstream, because 16K pages do represent a performance benefit).
I tweaked the config a little bit to align it with Void's (
INIT_ON_ALLOC_DEFAULT_ON
and sysrq enabled by default), but dotconfigs give me a headache and I don't know what's important to keep from Void's configs. Let me know if there's anything else that needs changing.m1n1
Asahi Linux bootloader and hypervisor. In the standard boot flow, it is invoked by the platform firmware as the "kernel", after which it loads U-Boot, which then acts as a typical UEFI bootloader. (The full boot flow is described here.)
The included script
update-m1n1
concatenates m1n1 itself with the available Apple device trees, followed by the U-Boot binary, and places it on the ESP inm1n1/boot.bin
. Stage 1 of m1n1 will chainload this binary if present as "stage 2", so that it can be updated by the distro without needing to boot to macOS recovery. The script is invoked byINSTALL
in both them1n1
andasahi-uboot
packages, so that if either one is updated, the binary on the ESP will always be up to date.The template currently builds the latest commit in order to enable new functionality that works around some external monitors not initializing on the Mac mini (described in AsahiLinux/m1n1#159 (comment)). The
update-m1n1
script appends the contents of/etc/m1n1.conf
for this reason, but this functionality is subject to change. I expect to return to building a tag as soon as possible.asahi-uboot
Asahi's fork of U-Boot. Behaves as described above, not much else to mention.
The version and commit in the template are taken from the Asahi PKGBUILD. Since the repo and the PKGBUILD are maintained by the same group, I'm treating the PKGBUILD values as Word Of God until they publish more tags.
Further reading
Testing the changes
New package
This new package conforms to the quality requirements: YES
I built this PR locally for my native architecture,
aarch64
I built this PR locally for these architectures:
aarch64
(crossbuild)aarch64-musl
(native)[ci skip]