Skip to content
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

Closed
wants to merge 4 commits into from

Conversation

Skirmisher
Copy link
Contributor

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 standard grub-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 in m1n1/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 by INSTALL in both the m1n1 and asahi-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

  • I tested the changes in this PR: YES

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]

@dkwo
Copy link
Contributor

dkwo commented Aug 14, 2022

Great work! Can you rebase on 5.19? Do you know whether one can skip grub and use something like efibootmgr here?

@dkwo
Copy link
Contributor

dkwo commented Sep 16, 2022

I tried to add an image for this in void-mklive.
I don't yet have the hardware to test it though.
I'd be grateful if you can point out any stupid mistake.

@dkwo
Copy link
Contributor

dkwo commented Sep 27, 2022

I tested on a M1 macbook air: the above-mentioned PR to mklive is able to boot the kernel from this PR.
What I see after booting into Void (I choose "UEFI environment only" in asahi installer):

lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 465.9G 0 disk
|-nvme0n1p1 259:1 0 500M 0 part
|-nvme0n1p2 259:2 0 230.2G 0 part
|-nvme0n1p3 259:3 0 2.3G 0 part
|-nvme0n1p4 259:4 0 477M 0 part
|-nvme0n1p5 259:5 0 5G 0 part
nvme0n2 259:6 0 3M 0 disk
nvme0n3 259:7 0 128M 0 disk

I believe p1 is my efi partition, p2 is linux root, ignore the rest: could anyone confirm before I proceed?
Btw, I'd like to have encrypted /, with the kernel in /boot, but I'm not sure the grub scripts would work right away.

@dkwo
Copy link
Contributor

dkwo commented Sep 27, 2022

Ok, it turns out I was dumb:
lsblk -f clearly shows that p4 is the only one of type vfat with label EFI - UEFI.

@dkwo
Copy link
Contributor

dkwo commented Sep 28, 2022

@Skirmisher Do you mind moving the update-m1n1 script into the asahi-base pkg?
I'd like to mount the efi partition to /boot (instead of /boot/efi), as usual with encrypted /, but this is hardcoded in that script:
is this a strict requirement from asahi, or can I put grub and kernel/initram into /boot?
Btw, are you still using/interested into this?

@dkwo
Copy link
Contributor

dkwo commented Sep 28, 2022

It seems my issues have already been fixed by the script functions.sh introduced 10 days ago.

@dkwo
Copy link
Contributor

dkwo commented Sep 28, 2022

Actually, asahi provides the https://github.com/AsahiLinux/asahi-scripts repo, with a makefile that works for arch and fedora.
We could use the latter make option, eliminating the need to maintain the scripts ourselves.

@dkwo
Copy link
Contributor

dkwo commented Sep 30, 2022

Do you know whether one can skip grub and use something like efibootmgr here?

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,
then I'll probably revisit this PR.

@dkwo
Copy link
Contributor

dkwo commented Oct 7, 2022

Made some changes, updated some things in #39796
Feedback welcome.

@Skirmisher Skirmisher closed this Oct 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new-package This PR adds a new package
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants