> Thanks to the combined efforts of mildsunrise and chaos_princess, we discovered that ACE3 has pretty much the same register set as CD3217, only wrapped in a SPMI interface instead of addressed over I2C. Both the SPMI interface and ACE3 itself are now working in Asahi Linux, bringing USB 3.0 and Thunderbolt support to all M3 series devices.
When I got my M3 Pro MBP, I got it with the intention of eventually installing Linux on it. In hindsight I seriously underestimated the amount of effort needed for even partial Linux compatibility, which makes me all the more grateful for the work Asahi contributors have put in! I'll still be keeping macOS installed for iOS dev work(which I plan on doing soonish), but other than that all I really need is a web browser and Ghostty with good battery life.
I have immense respect for the incredible work that the Asahi team does, but at the rate that Intel and AMD have been catching up on power efficiency I wonder whether anyone will really _have_ to run Linux on M series laptops. There was a clear case for it back when Apple silicon absolutely dominated anything else you could buy but with Panther Lake I'm not so sure that Apple's lead will continue to be big enough to justify needing to wait several years for full Linux hardware compatibility to be reverse engineered.
It depends on how long Apple want to support the devices, if the support matches the longevity of the devices maybe nobody really needs Asahi. I believe all Intel Macs have received their final macOS version now so it is almost time for Apple to make that decision for the M1 generation. I think an M1 Pro, Max or Ultra (or even an M1 with 16GB of RAM) still has many good years left.
Yeah, but there was a time when running Linux on a laptop was one of the most complex ways of running Linux. Now I just expect everything to work, especially if I buy from Lenovo, Dell, or HP.
There was a time when Wi-Fi, or Wayland, or XComposite, or Linux gaming, or just accelerated graphics at all or, or, or... People get excited, they work on it, other people get excited and mess about, and eventually it just works.
I would love to one day pick up a decommissioned M1 Ultra and use my OS of choice on it, and I'm grateful for the people who are doing the hard thing now.
> wait several years for full Linux hardware compatibility
I'm not convinced it's only "several years".
Asahi was launched in January 2021. So 5 and a half years ago. Asahi, as far as I can tell, supports most of M1 and M2 features, so generations launched in November 2020 (6 years ago) and June 2022 (4 years ago).
I would be very surprised if a decade from now the story won't still be the same thing: 90% of features for systems half a decade old with software package gaps in important areas and everything slightly less optimized than MacOS.
Asahi is doing incredible work but it's still 5 people in a garage vs the huge corporation.
This project has been so impressive and exciting. I hope power management is a serious concern once they nail all the reverse engineering and functionality. Battery life would be a huge differentiator for the day to day macbook usage and traditionally Linux has been terrible at that due to lack of proprietary & highly tuned drivers
How likely is such tuning to happen within the practical lifetime of these devices? It's already been years and Linux isn't even feature complete on newer models.
Apple's indifference to OSS does not give me much hope.
Given the enormous lifetime of these devices, I’d say chances are pretty good! The only thing that’s going to make an M series Mac obsolete is when Apple stops releasing updates. If you can run Linux on it, that thing is going to last forever.
I would assume that once you have fully functional support for entire historical SoCs, the effort stops being "get most things working on most chips" and starts becoming "adapt already-working things to the newest chips". Yes, it's been years, but there's still so much hardware that Asahi doesn't have good support for yet, and that's dividing the efforts to support the newest chips. I'm sure that once all the existing chips are well-supported, new chips will be fairly quick to bring up.
>The ARM specification mandates that cores in WFI loops should preserve all state. This is not the default mode on Apple Silicon.
I sometimes do wonder at what point do ARM find and test these stuff and ask Apple to follow. Obviously this is not the first time we see such thing happened.
My understanding is that Apple has an extremely special license with ARM partially because they helped fund ARM when it was spun out of Acorn and they are not required to conform to the specifications like other licensees.
Amazing progress as usual. It’s been fun watching just how much a few people can accomplish over the last few years despite working on sometimes unstable sand.
> Meanwhile, donations and pledges kept slowly decreasing, and have done so since the project launched. Not enough to spell immediate doom for my dream of working on Asahi full time in the short term, but enough to make me wonder if any of this was really appreciated. The all-time peak monthly donation volume was the very first month or two. It seemed the more things we accomplished, the less support we had.
I think the issue is funding is so low the developers don’t even have access to newer Apple Siicon, let alone funding for token costs, etc.
Using LLMs in a project like this is also somewhat illegal, because LLMs may have inside information about apple devices and it's not allowed to use it.
> It is the opinion of the Board that Large Language Models (LLMs), herein referred to as Slop Generators, are unsuitable for use as software engineering tools, particularly in the Free and Open Source Software movement.
Yeah, you'll find out that va-api is not a good match for v4l2-requests. It does not pass decoded bitstream to the drivers as is, but pre-computes some things for some codecs, while v4l2-requests mostly expects original information parsed from the bitstream.
AFAWK, M6 CPU is a die shrink of M5, so unless something M7 present that will significantly improve CPU performance. The ARM C1 CPU core that is available to everyone has pretty much matched up to Apple. And that is all things included from performance, power, die size etc.
I was seriously worried the various incompatibilities the M3 bootloader had with Asahi's debugging setup would mean way slower bring-up than M1 and M2 had. Seems like that wasn't the case - or, at least, won't be the case anymore.
To downvoters: historically, a decent number of Windows and Linux users would run the operating systems on Apple hardware. I myself ran a triple-boot between macOS, Windows and Linux for years (although I still mainly used the machine for macOS). Apple Silicon demolished that market, and Asahi Linux is like a light at the end of the tunnel for those users who were entirely left behind by the ARM transition.
Fantastic to see the progress and a fascinating detailed write-up.
You have to appreciate the effort Apple puts into security - goes some way to understanding why they won't endorse/support installing an alternative operating system.
> Rumours circulating that Apple are actively hostile towards efforts such as Asahi, or that their security must be bypassed or jailbroken to run untrusted code are unfounded and false. In fact, Apple have expended effort and time on improving their security tooling in ways that only improve the execution of non-macOS binaries. An example of this is giving their Boot Policy configuration tool the ability to wrap raw AArch64 code in a proper Mach-O format starting with macOS 12.1. This is only ever required for enrolling a boot object that is not already a macOS kernelcache.
This is Apple we're talking about. What may be the bare minimum for you was a lot of work for them. Work they could have passed up and we would've all had to simply deal with it. They do that all the time, and there's nothing we can do about it. But here they didn't. Here they did "the bare minimum" to allow custom operating systems on their newer hardware. That should be commended. Yes, we should celebrate that hardware we purchase and own still allows us to run code we wrote. Because the alternative is that it could not. Their non-macOS devices already don't.
To be perfectly clear, Apple is like a lifeline to a lot of people. They are one of the last bastions of quality in the hardware and software world. This is why it's such a disappointment that they've been faltering lately: we had high expectations of them, which hasn't been quite so true for the rest of the industry for a while. So it is a big deal that hidden gems like this continue to crop up from them: it is a sign that some of their core values still remain. And I really hope the new CEO will bring back some of what they lost after Steve Jobs.
Most of those accommodations are for macOS, and make very few (if any) concessions for alternative operating systems. We're talking Qualcomm-tier effort.
Intel and AMD set the standard for "tremendous effort" bringing up support for alternative OSes. Nvidia follows behind, and Apple's support is (somehow) behind Nvidia's foot-dragging.
They already have the ability to prevent alternative operating systems. They use the same or similar SoCs in their other product lines and those do not let you do this.
Yes, Apple put effort into making it possible to install alternative operating systems on Macs, but that is an exception to the design because the chips are designed to be locked down. I expect Apple to remove the option at some point because nobody is using it on any of the recent hardware.
I see a lot of dual-purpose here. Maybe you don't, or maybe you figure it's just a coincidence that Linux can also benefit from this. Apple definitely had it in mind, and designed for it, even if they don't release documentation.
I will admit I am a bit confused by them locking out features like that, especially since they didn't at first. I wouldn't jump to assuming it's hostile, though.
> Thanks to the combined efforts of mildsunrise and chaos_princess, we discovered that ACE3 has pretty much the same register set as CD3217, only wrapped in a SPMI interface instead of addressed over I2C. Both the SPMI interface and ACE3 itself are now working in Asahi Linux, bringing USB 3.0 and Thunderbolt support to all M3 series devices.
When I got my M3 Pro MBP, I got it with the intention of eventually installing Linux on it. In hindsight I seriously underestimated the amount of effort needed for even partial Linux compatibility, which makes me all the more grateful for the work Asahi contributors have put in! I'll still be keeping macOS installed for iOS dev work(which I plan on doing soonish), but other than that all I really need is a web browser and Ghostty with good battery life.
Everyone is free to work on whatever they want, but...
I wish the amount of time and brain power spent on this project was instead used to work on something more friendly to the Linux community.
For example to improve Strix Halo GPU and NPU support.
People who work on Asahi want exactly that - working on black box hardware with no specification.
Most likely they just not interested in working on well maintained drivers that require 1000 times more effort to upstream code.
I have immense respect for the incredible work that the Asahi team does, but at the rate that Intel and AMD have been catching up on power efficiency I wonder whether anyone will really _have_ to run Linux on M series laptops. There was a clear case for it back when Apple silicon absolutely dominated anything else you could buy but with Panther Lake I'm not so sure that Apple's lead will continue to be big enough to justify needing to wait several years for full Linux hardware compatibility to be reverse engineered.
It depends on how long Apple want to support the devices, if the support matches the longevity of the devices maybe nobody really needs Asahi. I believe all Intel Macs have received their final macOS version now so it is almost time for Apple to make that decision for the M1 generation. I think an M1 Pro, Max or Ultra (or even an M1 with 16GB of RAM) still has many good years left.
Does anyone have to run Linux on an M series? I’m fairly confident it’s one of the most complex ways of running Linux…
Yeah, but there was a time when running Linux on a laptop was one of the most complex ways of running Linux. Now I just expect everything to work, especially if I buy from Lenovo, Dell, or HP.
There was a time when Wi-Fi, or Wayland, or XComposite, or Linux gaming, or just accelerated graphics at all or, or, or... People get excited, they work on it, other people get excited and mess about, and eventually it just works.
I would love to one day pick up a decommissioned M1 Ultra and use my OS of choice on it, and I'm grateful for the people who are doing the hard thing now.
But, power efficiency isn't the primary reason I'd like Apple hardware with linux software.
Display quality, trackpad quality, overall form factor, and very high RAM space in a laptop would be the primary reasons I'd go with Asahi Linux.
> wait several years for full Linux hardware compatibility
I'm not convinced it's only "several years".
Asahi was launched in January 2021. So 5 and a half years ago. Asahi, as far as I can tell, supports most of M1 and M2 features, so generations launched in November 2020 (6 years ago) and June 2022 (4 years ago).
I would be very surprised if a decade from now the story won't still be the same thing: 90% of features for systems half a decade old with software package gaps in important areas and everything slightly less optimized than MacOS.
Asahi is doing incredible work but it's still 5 people in a garage vs the huge corporation.
Even if amd or intel caught up the Apple hardware is just built better and is far higher quality.
> but at the rate that Intel and AMD have been catching up on power efficiency
Have they? What AMD or Intel laptop with Linux on it can hold a candle to and M4 air or an M4max pro? Genuinely curious, cause I found none...
Framework 13 pro with new Intel chips claims to run 20h of 4k Netflix stream, or 17h of light web browsing @250 nits.
That said these numbers are with windows.
No idea but my Framework 12 goes for days without charging. I really haven't seen any real world need for M chips.
Granted Im not compiling large projects on a train all day but who is.
AMD Strix Halo?
"up to 9 hours for light web browsing or everyday tasks"
that is 1/3 the battery life of a macbook in the same use case. seems completely incomparable
This project has been so impressive and exciting. I hope power management is a serious concern once they nail all the reverse engineering and functionality. Battery life would be a huge differentiator for the day to day macbook usage and traditionally Linux has been terrible at that due to lack of proprietary & highly tuned drivers
How likely is such tuning to happen within the practical lifetime of these devices? It's already been years and Linux isn't even feature complete on newer models.
Apple's indifference to OSS does not give me much hope.
Given the enormous lifetime of these devices, I’d say chances are pretty good! The only thing that’s going to make an M series Mac obsolete is when Apple stops releasing updates. If you can run Linux on it, that thing is going to last forever.
I would assume that once you have fully functional support for entire historical SoCs, the effort stops being "get most things working on most chips" and starts becoming "adapt already-working things to the newest chips". Yes, it's been years, but there's still so much hardware that Asahi doesn't have good support for yet, and that's dividing the efforts to support the newest chips. I'm sure that once all the existing chips are well-supported, new chips will be fairly quick to bring up.
>The ARM specification mandates that cores in WFI loops should preserve all state. This is not the default mode on Apple Silicon.
I sometimes do wonder at what point do ARM find and test these stuff and ask Apple to follow. Obviously this is not the first time we see such thing happened.
My understanding is that Apple has an extremely special license with ARM partially because they helped fund ARM when it was spun out of Acorn and they are not required to conform to the specifications like other licensees.
Didn't Apple help define the Aarch64 instruction set?
Amazing progress as usual. It’s been fun watching just how much a few people can accomplish over the last few years despite working on sometimes unstable sand.
Is Asahi an LLM-hostile project? I'd imagine this is something that would be benefitted tremendously with a Fable class model
> Meanwhile, donations and pledges kept slowly decreasing, and have done so since the project launched. Not enough to spell immediate doom for my dream of working on Asahi full time in the short term, but enough to make me wonder if any of this was really appreciated. The all-time peak monthly donation volume was the very first month or two. It seemed the more things we accomplished, the less support we had.
I think the issue is funding is so low the developers don’t even have access to newer Apple Siicon, let alone funding for token costs, etc.
https://marcan.st/2025/02/resigning-as-asahi-linux-project-l...
Using LLMs in a project like this is also somewhat illegal, because LLMs may have inside information about apple devices and it's not allowed to use it.
do you have a source for this? it doesn't really make sense to me
> It is the opinion of the Board that Large Language Models (LLMs), herein referred to as Slop Generators, are unsuitable for use as software engineering tools, particularly in the Free and Open Source Software movement.
https://asahilinux.org/docs/project/policies/slop/
Yeah, you'll find out that va-api is not a good match for v4l2-requests. It does not pass decoded bitstream to the drivers as is, but pre-computes some things for some codecs, while v4l2-requests mostly expects original information parsed from the bitstream.
https://xff.cz/git/libva-v4l2_request/
> Please stop Thinking Different
Considering how much better m-series CPUs are, i’d say actually keep thinking different.
AFAWK, M6 CPU is a die shrink of M5, so unless something M7 present that will significantly improve CPU performance. The ARM C1 CPU core that is available to everyone has pretty much matched up to Apple. And that is all things included from performance, power, die size etc.
Can you just use normal acronyms instead of something like AFAWK? Why not AFAIK? Do I need to know every acronym there is on the internet?
I was seriously worried the various incompatibilities the M3 bootloader had with Asahi's debugging setup would mean way slower bring-up than M1 and M2 had. Seems like that wasn't the case - or, at least, won't be the case anymore.
The processor version with the debugging incompstibilities was M4, I think.
Seems like once they got past that things weren’t too bad. Could have been way more incompatibilities waiting on the other side.
And all that with a hard fork of kernel
I'm extremely excited to hear that the hypervisor now works on M4! Can't wait to try out Asahi in a year or two.
macOS is so terrible. Godspeed!
To downvoters: historically, a decent number of Windows and Linux users would run the operating systems on Apple hardware. I myself ran a triple-boot between macOS, Windows and Linux for years (although I still mainly used the machine for macOS). Apple Silicon demolished that market, and Asahi Linux is like a light at the end of the tunnel for those users who were entirely left behind by the ARM transition.
Fantastic to see the progress and a fascinating detailed write-up.
You have to appreciate the effort Apple puts into security - goes some way to understanding why they won't endorse/support installing an alternative operating system.
Apple has gone through tremendous effort to enable alternative operating systems on Apple Silicon Macs: https://asahilinux.org/docs/platform/open-os-interop/
Are you sure you linked the right page? This looks like a list of workarounds the Asahi team had to figure out.
Oh, my bad, I think the one I intended was this one: https://asahilinux.org/docs/platform/security/#apples-unspok...
> Rumours circulating that Apple are actively hostile towards efforts such as Asahi, or that their security must be bypassed or jailbroken to run untrusted code are unfounded and false. In fact, Apple have expended effort and time on improving their security tooling in ways that only improve the execution of non-macOS binaries. An example of this is giving their Boot Policy configuration tool the ability to wrap raw AArch64 code in a proper Mach-O format starting with macOS 12.1. This is only ever required for enrolling a boot object that is not already a macOS kernelcache.
> tremendous efforts
Tremendous efforts would be to publish reference manuals for all their hardware components.
Apple is doing the bare minimum, which is to not build 10km tall walls around its walled garden.
But in the modern day of walled gardens, that's viewed as generosity.
This is Apple we're talking about. What may be the bare minimum for you was a lot of work for them. Work they could have passed up and we would've all had to simply deal with it. They do that all the time, and there's nothing we can do about it. But here they didn't. Here they did "the bare minimum" to allow custom operating systems on their newer hardware. That should be commended. Yes, we should celebrate that hardware we purchase and own still allows us to run code we wrote. Because the alternative is that it could not. Their non-macOS devices already don't.
To be perfectly clear, Apple is like a lifeline to a lot of people. They are one of the last bastions of quality in the hardware and software world. This is why it's such a disappointment that they've been faltering lately: we had high expectations of them, which hasn't been quite so true for the rest of the industry for a while. So it is a big deal that hidden gems like this continue to crop up from them: it is a sign that some of their core values still remain. And I really hope the new CEO will bring back some of what they lost after Steve Jobs.
Most of those accommodations are for macOS, and make very few (if any) concessions for alternative operating systems. We're talking Qualcomm-tier effort.
Intel and AMD set the standard for "tremendous effort" bringing up support for alternative OSes. Nvidia follows behind, and Apple's support is (somehow) behind Nvidia's foot-dragging.
This is true, although Apple could of just as easily prevented alternative OSes as a whole if they wanted to.
They already have the ability to prevent alternative operating systems. They use the same or similar SoCs in their other product lines and those do not let you do this.
Yes, Apple put effort into making it possible to install alternative operating systems on Macs, but that is an exception to the design because the chips are designed to be locked down. I expect Apple to remove the option at some point because nobody is using it on any of the recent hardware.
I see a lot of dual-purpose here. Maybe you don't, or maybe you figure it's just a coincidence that Linux can also benefit from this. Apple definitely had it in mind, and designed for it, even if they don't release documentation.
Absolutely not. They put in the literal bare minimum possible effort short of locking down the platform entirely.
You get a jmp to some arm64 instructions of your choosing, with a bunch of CPU features locked out.
I will admit I am a bit confused by them locking out features like that, especially since they didn't at first. I wouldn't jump to assuming it's hostile, though.