-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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 (v2) #39796
base: master
Are you sure you want to change the base?
Conversation
f9107c1
to
77b0c56
Compare
After installing in the usual way (chroot), it seems to run smoothly on my m1 macbook air. |
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). |
Thanks for the suggestions, and for doing the initial hard work. |
Upon some minor config changes, I was able to boot the latest 6.0 series kernel. |
7e7d09f
to
bfa6733
Compare
962b6f2
to
1dd5bb6
Compare
At this point, I think only kernel and m1n1 are really needed, the rest can be dropped, |
@Skirmisher Now shipping a kernel hook for m1n1, which allows to either have the kernel or uboot as payload.
More eyes are welcome :) |
64131f4
to
dce5828
Compare
This is awesome! Just a quick question: @dkwo you said
Is this phrased correctly? Do we really need to rebuild all Do you have interest in also porting the gpu drivers to Void Linux? |
"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.
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 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. |
Exactly as @Skirmisher said. I agree that GPU/mesa might be a bit premature. |
With this meson PR, it may be possible to cross compile mesa-asahi: mesonbuild/meson#12022 |
Void is already crosscompiling mesa, so it must be only certain drivers that block cross (e.g. intel-clc, and now asahi) |
I'll try the meson patch. |
even with the meson patch, the asahi-mesa meson.build will need to be patched too |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a simple fix to allow mesa-asahi to be cross compiled:
add this patch:
diff --git a/src/asahi/clc/meson.build b/src/asahi/clc/meson.build
index 5db547ffde5..f122c03749e 100644
--- a/src/asahi/clc/meson.build
+++ b/src/asahi/clc/meson.build
@@ -9,5 +9,4 @@ prog_asahi_clc = executable(
c_args : [pre_args, no_override_init_args],
link_args : [ld_args_build_id],
dependencies : [idep_mesaclc, dep_llvm, dep_spirv_tools, idep_nir],
- native : true,
)
add add build_helper=qemu
@Calandracas606 You're right, that patch is already upstream, but when I tested it, I forgot to add the build_helper. |
With the patch https://gitlab.freedesktop.org/asahi/mesa/-/commit/51f2ed872e8491d0d4b72309d5117fe9f7f43672 and the build helper, I'm getting a different failure in mesa
that somehow looks for |
try rebasing the branch I didn't get this error when I tested |
Also, here's the kconfig ive been working on: https://gist.github.com/Calandracas606/6dc49aaa0e6f9290c092ccdf7e458f7b It has changes based on the asahi recommendations, adds hardening options present in void's x86_64 configs, but missing in the aarch64 ones, and removes drivers that are not applicable for asahi That being said, there's still a lot of drivers that are not applicable and should be removed |
Rebasing or cleaning the masterdir does not fix this for me. Are you sure that you can cross-compile mesa-asahi with the patch that is upstream (that I linked) from x86_64 to aarch64 (both glibc), just by adding the qemu buildhelper? As for the kernel, the asahi one can be used as a generic aarch64 16K kernel. I think this is better, rather than stripping down to a device/apple specific one. What do people think? |
actually, i do get the same error with mesa from void's master branch, again x86_64 to aarch64, both glibc |
yeah it works for me
idk if that makes sense, considering the large amount of patches |
Well, what I see for |
try zapping your masterdir |
No luck with zapping. |
Finally, it crosscompiles now, not sure what I had to delete.. sorry about that. |
This PR can boot from a USB stick using void-linux/void-mklive#281
I thank @slimjimsoftware for contributing and testing the mesa and audio pkgs, as well as @Skirmisher for the initial work #36390
See also #48260
See https://github.com/AsahiLinux/docs/wiki/Kernel-config-notes-for-distros for kconfig.
Firmware can be updated manually with
asahi-fwextract /boot/asahi /boot/vendorfw
(if efi is at boot).[ci skip]
To do: do not split mesa-asahi-opencl? refresh kernel, use it as generic aarch64 16k?