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 27 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 @Skirmisher and @Calandracas606 for contributing and/or testing.
Docs pr: void-linux/void-docs#827

[ci skip]
Remarks:

@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 dkwo force-pushed the asahi2 branch 2 times, most recently from 7e7d09f to bfa6733 Compare October 14, 2022 18:53
@dkwo dkwo force-pushed the asahi2 branch 7 times, most recently from 962b6f2 to 1dd5bb6 Compare October 27, 2022 15:47
@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.

checksum=e877508b73fe90774d74526d838f75e8ea278bdbcee0a1f92e3eca67ed734675

do_install() {
vmkdir usr/lib/lv2/bankstown.lv2/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vmkdir + vinstall is redundant

# If there's a file called <arch>-dotconfig, use it to
# configure the kernel; otherwise use arch defaults and all stuff
# as modules (allmodconfig).
local arch subarch
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

subarch is an unused variable

}

do_install() {
local arch subarch _args hdrdest
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

subarch also unused herre

}
}

post_install() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

post_install should go before subpackages

build_options_default="wayland"

# Set subpackages manually
subpackages="libgbm-asahi libgbm-asahi-devel libOSMesa-asahi mesa-asahi-vaapi mesa-asahi-vdpau
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doesn't need to be set manually

hostmakedepends="alsa-lib pkg-config"
makedepends="alsa-lib-devel"
short_desc="Software Smart Amp implementation"
maintainer="Orphaned <[email protected]>"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new packages shouldn't be orphaned (same with mesa-asahi)

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
Development

Successfully merging this pull request may close these issues.

9 participants