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 (v2) #39796

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Conversation

dkwo
Copy link
Contributor

@dkwo dkwo commented Oct 7, 2022

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?

@dkwo dkwo force-pushed the asahi2 branch 2 times, most recently from f9107c1 to 77b0c56 Compare October 7, 2022 18:55
@classabbyamp classabbyamp added the new-package This PR adds a new package label Oct 7, 2022
@dkwo
Copy link
Contributor Author

dkwo commented Oct 7, 2022

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
Copy link
Contributor

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
Copy link
Contributor Author

dkwo commented Oct 7, 2022

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
Copy link
Contributor Author

dkwo commented Oct 13, 2022

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
Copy link
Contributor Author

dkwo commented Nov 3, 2022

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
Copy link
Contributor Author

dkwo commented Dec 1, 2022

@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 :)

@dkwo dkwo force-pushed the asahi2 branch 2 times, most recently from 64131f4 to dce5828 Compare December 6, 2022 19:13
@Anachron
Copy link
Contributor

Anachron commented Dec 17, 2022

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
Copy link
Contributor

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
Copy link
Contributor Author

dkwo commented Dec 17, 2022

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

@Calandracas606
Copy link

With this meson PR, it may be possible to cross compile mesa-asahi: mesonbuild/meson#12022

@dkwo
Copy link
Contributor Author

dkwo commented Jul 4, 2024

Void is already crosscompiling mesa, so it must be only certain drivers that block cross (e.g. intel-clc, and now asahi)

@dkwo
Copy link
Contributor Author

dkwo commented Jul 4, 2024

I'll try the meson patch.

@Calandracas606
Copy link

even with the meson patch, the asahi-mesa meson.build will need to be patched too

Copy link

@Calandracas606 Calandracas606 left a 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

srcpkgs/mesa-asahi/template Show resolved Hide resolved
@dkwo
Copy link
Contributor Author

dkwo commented Jul 10, 2024

@Calandracas606 You're right, that patch is already upstream, but when I tested it, I forgot to add the build_helper.

@dkwo
Copy link
Contributor Author

dkwo commented Jul 10, 2024

With the patch https://gitlab.freedesktop.org/asahi/mesa/-/commit/51f2ed872e8491d0d4b72309d5117fe9f7f43672 and the build helper, I'm getting a different failure in mesa

[1381/1596] Generating bindings for Rust src/gallium/frontends/rusticl/rustmod-bindgen-rusticl_llvm_bindings.hpp
FAILED: src/gallium/frontends/rusticl/rusticl_llvm_bindings.rs 
/usr/bin/bindgen ../src/gallium/frontends/rusticl/rusticl_llvm_bindings.hpp --output /builddir/mesa-asahi-24.2.0/build/src/gallium/frontends/rusticl/rusticl_llvm_bindings.rs --generate constructors,functions,types --opaque-type '.*' --allowlist-function clang::getClangFullVersion --allowlist-function llvm::LLVMContext::LLVMContext --allowlist-function llvm::writeSpirv -- -fno-builtin-malloc -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="24.2.0-devel"' '-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues"' -DHAVE_OPENGL=1 -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ASAHI -DHAVE_VIRGL -DHAVE_ZINK -DVIDEO_CODEC_VC1DEC=0 -DVIDEO_CODEC_H264DEC=0 -DVIDEO_CODEC_H264ENC=0 -DVIDEO_CODEC_H265DEC=0 -DVIDEO_CODEC_H265ENC=0 -DVIDEO_CODEC_AV1DEC=1 -DVIDEO_CODEC_AV1ENC=1 -DVIDEO_CODEC_VP9DEC=1 -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DUSE_LIBGLVND=1 -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DHAVE_VA_SURFACE_ATTRIB_DRM_FORMAT_MODIFIERS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=0 -DALLOW_KCMP -DMESA_DEBUG=0 -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN -D_GNU_SOURCE -DUSE_GCC_ATOMIC_BUILTINS -DUSE_AARCH64_ASM -DMAJOR_IN_SYSMACROS -DHAS_SCHED_H -DHAS_SCHED_GETAFFINITY -DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_SYS_SHM_H -DHAVE_SYS_INOTIFY_H -DHAVE_LINUX_UDMABUF_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_MEMFD_CREATE -DHAVE_RANDOM_R -DHAVE_FLOCK -DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_POSIX_FALLOCATE -DHAVE_SECURE_GETENV -DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_ISSIGNALING -DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREAD -DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DHAVE_LIBUDEV '-DMESA_LLVM_VERSION_STRING="17.0.6"' -DLLVM_IS_SHARED=1 -DLLVM_AVAILABLE=1 -DDRAW_LLVM_AVAILABLE=1 -DUSE_LIBELF -DTHREAD_SANITIZER=0 -DWL_HIDE_DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_DRISW_KMS -DHAVE_LIBSENSORS=1 -target aarch64-linux-gnu -DNDEBUG -isystem/usr/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -pthread -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="24.2.0-devel"' '-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues"' -DHAVE_OPENGL=1 -DHAVE_OPENGL_ES_1=1 -DHAVE_OPENGL_ES_2=1 -DHAVE_SWRAST -DHAVE_ASAHI -DHAVE_VIRGL -DHAVE_ZINK -DVIDEO_CODEC_VC1DEC=0 -DVIDEO_CODEC_H264DEC=0 -DVIDEO_CODEC_H264ENC=0 -DVIDEO_CODEC_H265DEC=0 -DVIDEO_CODEC_H265ENC=0 -DVIDEO_CODEC_AV1DEC=1 -DVIDEO_CODEC_AV1ENC=1 -DVIDEO_CODEC_VP9DEC=1 -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DUSE_LIBGLVND=1 -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DHAVE_VA_SURFACE_ATTRIB_DRM_FORMAT_MODIFIERS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DGLAPI_EXPORT_PROTO_ENTRY_POINTS=0 -DALLOW_KCMP -DMESA_DEBUG=0 -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN -D_GNU_SOURCE -DUSE_GCC_ATOMIC_BUILTINS -DUSE_AARCH64_ASM -DMAJOR_IN_SYSMACROS -DHAS_SCHED_H -DHAS_SCHED_GETAFFINITY -DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_SYS_SHM_H -DHAVE_SYS_INOTIFY_H -DHAVE_LINUX_UDMABUF_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_MEMFD_CREATE -DHAVE_RANDOM_R -DHAVE_FLOCK -DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_POSIX_FALLOCATE -DHAVE_SECURE_GETENV -DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_PROGRAM_INVOCATION_NAME -DHAVE_ISSIGNALING -DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREAD -DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DHAVE_LIBUDEV '-DMESA_LLVM_VERSION_STRING="17.0.6"' -DLLVM_IS_SHARED=1 -DLLVM_AVAILABLE=1 -DDRAW_LLVM_AVAILABLE=1 -DUSE_LIBELF -DTHREAD_SANITIZER=0 -DWL_HIDE_DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_DRISW_KMS -DHAVE_LIBSENSORS=1 -D_FORTIFY_SOURCE=2 -I/usr/aarch64-linux-gnu/usr/include -x c++ -std=gnu++17 -MD -MQ ../src/gallium/frontends/rusticl/rusticl_llvm_bindings.hpp -MF src/gallium/frontends/rusticl/rusticl_llvm_bindings.hpp.d
/usr/include/features.h:414:4: warning: _FORTIFY_SOURCE requires compiling with optimization (-O) [-W#warnings]
/usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
clang diag: /usr/include/features.h:414:4: warning: _FORTIFY_SOURCE requires compiling with optimization (-O) [-W#warnings]
panicked at bindgen-cli/main.rs:52:36:
Unable to generate bindings: ClangDiagnostic("/usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found\n")

that somehow looks for gnu/stubs-32.h. I suspect somehow the post_configure hack is not working for rust anymore?

@Calandracas606
Copy link

try rebasing the branch

I didn't get this error when I tested

@Calandracas606
Copy link

Calandracas606 commented Jul 10, 2024

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

@dkwo
Copy link
Contributor Author

dkwo commented Jul 11, 2024

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?

@dkwo
Copy link
Contributor Author

dkwo commented Jul 11, 2024

actually, i do get the same error with mesa from void's master branch, again x86_64 to aarch64, both glibc

@Calandracas606
Copy link

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?

yeah it works for me

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?

idk if that makes sense, considering the large amount of patches

@dkwo
Copy link
Contributor Author

dkwo commented Jul 11, 2024

Well, what I see for x86_64-glibc -> aarch64-glibc at the moment is that /usr/bin/bindgen is called with -isystem/usr/include, which is not caught by any wrapper (nor by the post_configure hack) and leads to the failure. I think this is a bug of Void's mesa as well, not just asahi.

@Calandracas606
Copy link

try zapping your masterdir

@dkwo
Copy link
Contributor Author

dkwo commented Jul 11, 2024

No luck with zapping.

@dkwo
Copy link
Contributor Author

dkwo commented Jul 11, 2024

Finally, it crosscompiles now, not sure what I had to delete.. sorry about that.

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

9 participants