This project is impressive but I wonder if those efforts would not have been better spent on an open platform that actually respects its users and that is less likely to kill the whole project on a whim. It seems like building a house on someone's else property.
It is baffling to me that Apple, ostensibly a hardware company (that happens to be pursuing services revenue the way a crackhead pursues crack), ridiculously flush with cash, doesn’t throw 2 or 3 of their thousands of FTEs on this. The goodwill/brand marketing alone is worth their comp, and it will absolutely move units as well. Linux people LOVE laptops, and Apple makes the best laptops by a parsec. It seems like 10x ROI would be a conservative estimate.
> The defacto industry standard for audio ICs is I²S, an I²C-based bus optimised for audio data.
Nit: I²S has nothing to do with I²C.
(Most I²S chips also have an I²C interface since I²S only carries raw audio data, no sideband like volume control or clock configuration. But that's a separate interface and can also be SPI rather than I²C. In fact, SPI is more closely related to I²S than I²C is.)
I²S is a remarkably simple design. There's no protocol handshakes, it's just raw PCM. I like how it's designed so sender and receiver can use totally different sample bit-depths (in either direction) without any incompatibility.
Asahi could be a viable alternative, however, with this amount of funding, small manpower pool pace of development is doomed to be too slow.
There's groundwork that's already been done, as mentioned in the article, which brings some dividends, but, ultimately, there is a new mac every year that comes with a new chip, a plethora of microcontrollers and gpu changes, impossible to keep up with, that is why asahi team is focused more on m1 and m2 models. Even so, to this day both of them have issues with idle power management and alt-dp implementation, preventing many to switch, by the time they will have been ironed out the value of machines would be significantly diminished.
It is a miracle how much so few can do, but in the end, despite ubiquitous media coverage it looks like team's enthusiasm and passion have dwindled to the point that even m1 air will never be ready.
When the new leadership team took over, they announced that they would prioritize upstreaming the existing work over adding support for newer hardware.
Upstreaming their changes into the kernel took time.
Now the announced that they had started work on the M3 in February and things are progressing well.
> On top of the above, we also have PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad, and other core SoC block drivers working in Linux for M3 series machines. Most of this work has come by way of Yureka, who has been very busy hacking on both m1n1 and Linux with her M3 series machines for a while now. We still have a ways to go before we can start enabling Asahi Installer support for these machines, but progress is rapid so watch this space!
That sounds more like talented people doing meticulous work than doom.
They first mentioned that efforts to add M3 support were starting in February:
> For quite some time, m1n1 has had basic support for the M3 series machines. What has been missing are Devicetrees for each machine, as well as patches to our Linux kernel drivers to support M3-specific hardware quirks and changes from M2. Our intent was always to get to fleshing this out once our existing patchset became more manageable
As someone rocking a M3 Pro, I personally don't expect to be able to try Asahi out until mid/late next year on my MBP, but I am looking forward to it nonetheless!
I really wish Apple would fund a small team to open source some documentation and drivers to help Asahi along. I know they won't, but I can dream. It would be a drop in the bucket for Apple but would cement their hardware as de facto for silicon valley engineers (even more so than today).
Apple's own hypervisor framework is close enough to what you said that i run Fedora and Arch Linux builds via the UTM app, set to use Apple Silicon virtualization (_not_ emulation), which is a wrapper around said framework.
it's excellent, and made me reformat and erase Asahi a couple years ago.
> The firmware loaded by XNU is not verified by the CM3. It will begin executing from its reset vector when signalled, no matter what is actually there. What if we just… used our own firmware?
Without taking away from the unutterably awesome achievement of writing custom firmware against a proprietary moving target, I worry about this one specifically. While Apple will hopefully continue the practice of not going out of their way to break third-party OSes, it doesn’t seem unlikely that they will introduce hardware signing for firmware blobs or the data they supply at runtime when programming the hardware; that’s a reasonable security concern for Apple to address. I hope this gamble pays off though!
22 comments
[ 2.2 ms ] story [ 45.0 ms ] threadWill it ultimately be manually loading a build into specific hardware each time, or is there a level of automation that can be done here?
I think the last time I used an RPM-based distro was almost 2 decades ago.
Nit: I²S has nothing to do with I²C.
(Most I²S chips also have an I²C interface since I²S only carries raw audio data, no sideband like volume control or clock configuration. But that's a separate interface and can also be SPI rather than I²C. In fact, SPI is more closely related to I²S than I²C is.)
https://web.archive.org/web/20070102004400/http://www.nxp.co...
There's groundwork that's already been done, as mentioned in the article, which brings some dividends, but, ultimately, there is a new mac every year that comes with a new chip, a plethora of microcontrollers and gpu changes, impossible to keep up with, that is why asahi team is focused more on m1 and m2 models. Even so, to this day both of them have issues with idle power management and alt-dp implementation, preventing many to switch, by the time they will have been ironed out the value of machines would be significantly diminished.
It is a miracle how much so few can do, but in the end, despite ubiquitous media coverage it looks like team's enthusiasm and passion have dwindled to the point that even m1 air will never be ready.
When the new leadership team took over, they announced that they would prioritize upstreaming the existing work over adding support for newer hardware.
Upstreaming their changes into the kernel took time.
Now the announced that they had started work on the M3 in February and things are progressing well.
> On top of the above, we also have PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad, and other core SoC block drivers working in Linux for M3 series machines. Most of this work has come by way of Yureka, who has been very busy hacking on both m1n1 and Linux with her M3 series machines for a while now. We still have a ways to go before we can start enabling Asahi Installer support for these machines, but progress is rapid so watch this space!
That sounds more like talented people doing meticulous work than doom.
They first mentioned that efforts to add M3 support were starting in February:
> For quite some time, m1n1 has had basic support for the M3 series machines. What has been missing are Devicetrees for each machine, as well as patches to our Linux kernel drivers to support M3-specific hardware quirks and changes from M2. Our intent was always to get to fleshing this out once our existing patchset became more manageable
https://asahilinux.org/2026/02/progress-report-6-19/
it's excellent, and made me reformat and erase Asahi a couple years ago.
https://developer.apple.com/documentation/hypervisor
https://docs.getutm.app/installation/macos/
https://github.com/apple-oss-distributions/xnu/blob/f6217f89...
https://lore.kernel.org/asahi/c13d95d0-911f-48f6-b4ca-8a5e9a...
Without taking away from the unutterably awesome achievement of writing custom firmware against a proprietary moving target, I worry about this one specifically. While Apple will hopefully continue the practice of not going out of their way to break third-party OSes, it doesn’t seem unlikely that they will introduce hardware signing for firmware blobs or the data they supply at runtime when programming the hardware; that’s a reasonable security concern for Apple to address. I hope this gamble pays off though!