Asahi Linux: July 2022 Release and Progress Report
asahilinux.org
asahilinux.org
How can this be so different from the situation with, say, the nvidia drivers, or even many wi-fi drivers, where it took years of effort from the community before reaching fully working drivers?
They only have to get a single device model to work, with perhaps a handful of small variations. Monoculture has its benefits.
In general, I think the porting effort depends on whether Apple has used a freely available industry component. So if the WiFi chip is something that is available in a non-Apple system, one could tweak the AArch64 Linux driver a bit and get it to work on AArch64 Mx Linux. If the silicon is totally custom I can imagine the task being much more difficult.
My guess is that many of the components on which Asahi Linux has made good progress in porting over to work have good support already on vanilla AArch64 Linux. Understanding the integration and working around Apple's proprietary sauce, of course, makes the task totally non-trivial.
> It will probably take many years to reverse engineer.
The last 6% is probably decently hard, but it will probably not be terribly hard to finish - and not long for this team thereafter to change the Python code into an actual Linux driver considering the sheer number of drivers they've already written. Once you have openGLES, you have a HW-accelerated desktop, at least through most desktop environments. Video acceleration is another story they haven't started on, but its generally easy by comparison. Might take another year or two for full OpenGL or Vulkan though.
The actual meat of the "driver" in these case is in Mesa, a userspace component, which is what actually forms and creates the command buffers to send.
You can write a driver to interact with hardware in any language assuming you don't have insane timing requirements. It's mostly a matter of engineering deciding where the pieces should go, though. (For example, everything else aside, a major advantage of this kind of design is that all the real complexity exists in userspace.)
The Linux kernel is written in C, Linus has historically made his dislike of C++ clear as well
Rust would be reasonable but its inclusion in the kernel at this point is "that's a good idea!" rather than "that's a thing being done right now in kernel.org kernels"
Yeah that's precisely what they did. According to this [0] dmesg of a mac mini, M1 macs have the BCM4378 chip, for which they use the existing [1] brcmfmac driver. That driver is years old. A cursory look into git log drivers/net/wireless/broadcom/brcm80211/brcmfmac shows maintenance from various people, including folks with @broadcom.com e-mails, reaching back to 2015 (but that might only have been the date the directory was moved, it might be actually older, as again it's only been a cursory look to establish a lower bound on the age). They did have to add some patches to add support for the specific chip used by apple thogh, which they are upstreaming [2], but they weren't starting from scratch.
[0]: https://gist.github.com/z4yx/13520bd2beef49019b1b7436e3b95dd...
[1]: https://wiki.debian.org/brcmfmac
[2]: https://lore.kernel.org/lkml/4928ea79-2794-05fb-d1a8-942b589...
You linked to the old Corellium patch, here's proper one: https://lore.kernel.org/linux-acpi/20211226153624.162281-1-m...
For the core of the driver that may be true. Ultimately the driver needs to _interface_ with the platform (and the OS) and for that custom code needs to be done to account for platform and OS differences. You cannot abstract away everything.
So I would assume it's mostly developer resources that make the difference.
And yeah, it helps that there's just a tiny amount of Mac hardware compared to PC hardware. If you get any arbitrary wifi chip to work with Linux, then congrats, you just made like 2 or 3 of the thousands of PC laptops work. But if you get the wifi chip Apple uses in their laptops to work, then you might've gotten wifi to work on multiple generations of Mac laptops.
Bluetooth and WiFi reverse engineering is something I can conceptually grasp from afar, especially because they should be relatively similar across architectures. They are well defined protocols, you send and receive packages. OK.
But GPUs are such complicated beasts, each on it’s own snowflakey way, I don’t even understand how the work on a deep level, let alone imagine how reverse engineering would begin. Memory access and sharing with the CPU, shaders, a massively parallel computing model. Crazy stuff. Oh, and you also get to draw lots of triangles really fast while you’re at it.
Support for Apple Silicon has much less device combinations to deal with unlike what you see with other devices. There is only one type and fixed set of GPU, storage, wifi, bluetooth drivers to support vs the hundreds of hundreds of GPU variants, with the infinite combinations of other devices found on PCs.
Also the so-called 'open-sourcing' of the Nvidia drivers which got the Linux fans too excited, only to be disappointed to realise that Nvidia was not only still working against them, but the news of this announcement turned out to be a red herring.
Pushing GPU FFI wrapper code to binary blobs is still not 'open-source'.
It is not possible to simply reverse engineer everything nowadays -- it could take years to build a polished system and in the meanwhile there will always be new hardware from Apple. It's a never ending game of "catch up".
Are there some scenarios where Apple might want to allow "proper" Linux on Mx to happen ? The fact that Apple has not totally locked down these machines is tremendously heartening. Could it be in Apple's interest to somehow help the Asahi guys move faster -- release hardware specifications in the open etc.?
I think that if Apple hardware releases Mx hardware specs, a high quality linux implementation can then take shape on the Mx. This will create some competition with the Apple software folks. People will benchmarks software running on Mx Linux vs Mx MacOS. This could create some healthy competition.
Just like the arrival of llvm helped gcc improve its game, a well functioning software stack on Mx Linux can create some healthy competition for the Apple software team. Their software is quite decent already -- it can achieve greater heights with some competition !
Wonder what Qualcomm had to do to get that agreement though. All signs seem to point to Qualcomm being absolutely poisonous to work with and their ARM offerings being uncompetitive with Apple's now
That's the reality of Linux support on pretty much any hardware - it can easily take years to really shape up and become polished. The Apple M1/M2 if anything are making surprisingly fast progress.
Whereas Asahi still sports a rudimentary GPU driver written in Python... Current guesstimate to achieve hardware acceleration is... years. https://news.ycombinator.com/item?id=32138327
If there is no H/W acceleration, then it is not useful as a daily driver at all.
We wait until there is proper support of H/W acceleration before using such a system. Otherwise all your memory eating programs or graphical intensive apps will run the computer to the ground.
You can basically take any PC with brand new components and have high confidence that it'll work perfectly with Linux.
So sure the popular GPU chipsets, ethernet, wifi, etc have drivers. But the integration doesn't necessarily work, doubly so after sleep mode. There's a cottage industry of selling "good" wifi cards for laptops (like Lenovo) that work well with Linux to replace the "bad" wifi cards that don't work well with Linux. Other problems include controlling clock speeds of GPUs, memory chips, fan speeds, etc.
So sure there are some laptops that are known to work well, of if in particularly lucky your vendor (like System76 or Dell) supports linux. But often the "linux" flavor of the laptop has different hardware then the windows flavor, particularly because the drivers for some chips don't work well.
Most of the folks I know that used to run linux on laptops have given up, they don't want to tinker with PCI-id maps, disabling features to get idle/sleep modes working, etc. They just buy an apple laptop and everything works.
I seem to recall reading that they had an x86/x86-64 internal distribution but maybe I am thinking of another company...
It's less likely that they have an internal ARM/Mx Linux project though. Doesn't serve any known purpose that I'm aware of.
Either way, that's a good point and does have clear internal utility. It's certainly easier to get Linux running on a new chip than OSX!
I'd say that's wrong. From the outside view, perhaps, but an internal Apple team can certainly get macOS to sing and dance on whatever they need very quickly.
A similar effort for Linux would usually benefit from related work by many people. For OSX or macOS it would need to be an explicit project, starting with fewer initial bits. But the internal Apple team would be exactly the right experts for the job, so it would be easier to organize at least.
Apple doesn't have a history of helping anyone but themselves and if you read the article it looks like they're not thinking at all about helping alternative OSes by using proprietary interfaces and overly complicated hardware/firmware designs and breaking things with macOS updates.
It is a truly herculian task to get Linux merely booting up and usable on Apple M* SoCs - kudos to the Asahi Linux team for all the heroic efforts - personally it feels like it's a great reverse engineering project and they should continue fighting it but Linux on M1/2 is not going to be a daily driver like Linux on standard x64 machines is.
Thankfully Intel and AMD are doing pretty good in performance department with their latest chips and it's only going to get better.
This is such a shallow take. Your animosity toward Apple has blinkered you.
There is zero possibility that anyone at Apple is spending any time working to make hardware designs "overly complicated" for the purpose of hindering efforts like Asahi Linux.
Also since you might have take this personally - I wanted to clarify that my comment mostly is a reflection of wasted potential for the M* hardware - making it friendly to alt OSes would vastly improve the hardware's utility without hurting Apple. (If you are to believe most HNers they are a H/W company that is not interested in selling your personal data - so it should be in their financial interest if alt OSes sell more of their hardware.)
They are not even close to the same thing.
And if you were more familiar with the Asahi Linux project, you might remember that Apple has done a thing or two that made their work possible/future-proof.
Absence of beneficence is not evidence of malevolence.
Apple is busy making their custom OS work on their custom chips. They will change either or both, as needed, to serve their needs.
It's no minor thing to ask Apple to limit their own flexibility for a tiny non-revenue-generating external project. Remember Apple does not sell Mx chips on the open market like Intel/AMD/some ARM mfrs. They do not publish hardware specs as a service to customers, because they have no customers.
Except it absolutely is evidence of malevolence. It's not conclusive evidence (i.e., irrefutable proof), but almost nothing has conclusive evidence.
I did not make breakfast for you this morning. Is this evidence that I want you to starve?
It's not conclusive evidence (i.e., irrefutable proof), but almost nothing has conclusive evidence. ;)
Helping Asahi would tangentially benefit Apple (such as increasing mac sales... something that is reasonable to assume might happen a little bit, given how much more efficient the M chips are to Intel, and the fact that most Linux stuff already compiles just fine on it) while also possibly garnering some goodwill. It'd be great if they sold or licensed the chip to others so that it would have to be documented publicly, but we're not there yet.
> doing everything they can to hinder others by using overly complicated hardware and firmware designs and breaking things
That's malevolence. And it's completely certifiably and demonstrably false.
Again you cannot really prove this from where you and me sit - so it is implied that even without "it looks like" I meant their externally visible actions / results make it looks like they go out of their way to hinder - that can be a combination of thoughtless hardware design and resolve to not help anyone else. And none of those are necessarily "malevolence" (which is a word you used) - it's just business practices.
...but it does not look like they do those things either.
You'd have to ignore all of the reasons it makes no sense for Apple to make decisions like that, in order to believe or even wonder about such a thing.
If you had said "I wish Apple would work with Asahi to make their distro a full-fledged citizen on Apple's desirable hardware." ... then I would have upvoted your comment and moved on.
Instead I saw you describing a hostile and active thwarting scenario, which is unfounded and nonsensical.
I won't even address your "thoughtless hardware design and resolve not to help anyone else", except to say that ... you're doing it again, and you're still wrong.
Ah, that argument. Apple is, like Microsoft, actively trying to get people to run Linux and applications _under_ their OS -- Microsoft is shipping an entire Linux emulator for graphical applications and Apple is going to ship an x86 Linux emulator in a future release too.
And then, both companies have a lot of incentive that you continue to run their operating system as your main OS -- they can show you ads that way, they can continue to sell your their subscriptions and services, their partners', etc.
Combine the two, and I no longer believe the argument that "they couldn't care less about people who run Linux".
Things Apple does to make macOS more useful or appealing are in service of that goal. Absolutely.
I have not heard, and cannot find, any rumors about Apple shipping a Linux emulator. Links?
Regardless, I would not argue that Apple doesn't care about Linux. I would argue that Apple does not overcomplicate their hardware engineering with the goal of preventing people from running Linux on their hardware. And that is what I said.
macOS drives hardware sales. Apple makes money on hardware sales. They will not compromise their ability to change hardware or software to support a tiny noncommercial project, of course!
But at the end of the day, thinking as commercially as I can: Apple would prefer that you buy a M1 Mac and run Asahi, than buy a Dell running Windows or Linux instead. They have no opportunity to sell you macOS services in either case, but if you buy the M1, they capture hardware sales revenue.
It was even on HN: https://news.ycombinator.com/item?id=31644990 , https://arstechnica.com/gadgets/2022/06/macos-ventura-will-e...
> macOS drives hardware sales. Apple makes money on hardware sales.
Not as clear specially when the money they make from macOS hardware sales is actually less than what they make from services or iOS hardware sales.
The era when we had an open computing standards Apple that tried to interoperate with others is long gone. This is the era of the captive Apple who is trying to bind you into their ecosystem, and I won't believe the "0%" argument any more than I believe it for MS.
1. A Linux binary, 2. Which translates Linux/ELF code from x86 to ARM, 3. And translates Linux x86 syscalls to amd64 Linux, 4. With the explicit intention of allowing the user to run x86 Linux binaries under macOS.
If you want to be this level of nitpicking, then WSL is not a Linux emulator either; after all, they also require an existing Linux kernel to work, and may not even emulate anything whatsoever. But BOTH WSL2 and this emulator serve _exactly_ the serve purpose: to facilitate running of Linux binaries under a native host OS that is not Linux, thus my point.
I often wonder if AMD was able to use TSMC's cutting edge fabrication node how would their laptop chips compare with the M1. Apple uses TSMC's best node as I understand it.
Apple also has the advantage of cramming every thing on a single piece of silicon while AMD has gone in for the chiplet approach. The single piece of silicon reduces yields but increases performance with a lower power draw. The chiplet approach followed by AMD is more modular, less risky and cost effective.
So if both AMD and Apple use the same TSMC node _and_ AMD went in for "cost is not an objective" and cram everything on a single piece of silicon _and_ add HBM (aka unified memory) it would be real interesting for the two to go "head to head".
I would definitely be interested in paying good dollar for such X86 client system !
I hope someone at AMD is listening !
I'm still puzzled why during a long GPU shortage where supply was short and prices insane that nobody in the x86-64 world managed a > 128 bit wide memory interface to benefit of an iGPU. Apple desktops and laptops have options for 256, 512, and even 1024 bit (on the studio) wide memory systems.
I think the lead the M1 has is bigger than what can be attributed to the different node.
Apple is practically the worst computer vendor when it comes to "decent Linux support"; even nvidia is better, at least they have proprietary drivers.
It's quite a stretch to say that "vendors must boost their game if they brand themselves as decent Linux supporters"; rather, the conclusion here would be that vendors should drop their game altogether since no one cares. People, even Linux users and developers apparently, buy the hardware anyway even if the vendor just totally ignores Linux (at best).
I would find it quite telling if we go back to that era where all I see are MacBooks at the Linux kernel developers conferences, specially when the other manufacturers are now most definitely not ignoring Linux. Fortunately, that is not the case, so far.
Currently yes, Apple is the worst vendor.
> rather, the conclusion here would be that vendors should drop their game altogether since no one cares. People, even Linux users and developers apparently, buy the hardware anyway even if the vendor just totally ignores Linux (at best).
That's exactly the idea I was chasing - if Apple would care, then other vendors should care as well. But currently, Linux users are still in minority and it does not matter that much yet.
I would guess that the best way to incentivize them is to let them know—en masse—that a large number of people would want to buy new Apple Silicon-based Macs to run Asahi Linux on if it were in better shape.
> It is not possible to simply reverse engineer everything nowadays -- it could take years to build a polished system and in the meanwhile there will always be new hardware from Apple. It's a never ending game of "catch up".
I would think it's very much in their favor to help. If it takes years to build a polished release, a lot of people will value years old apple hardware over whatever more recently released. Cut that down to months and they just added a new (albeit smaller) segment chomping at the bit for their latest hardware.
The Arduino Unos being paired with an ESP-01 module is similar. Tons of other examples out there as well of course.
Not sure if there's a similar "power inversion" at play here, just find it funny when it shows up.
[1]: https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-...
[2]: https://www.infineon.com/cms/en/product/wireless-connectivit... (see block diagram)
if SPI results in lower power usage, then great. USB can easily manage single digit millis, and i’d estimate 4 or 5 (?!) frames of composition and/or vsync latency. insane.
it means my 2019 macbook pro has ~80ms input latency - absolutely noticeable but not the worst thing in the world - the m1 and m2 machines are actually worse somehow. the higher refresh rate displays help (back down ~50ms) but HFR is a crutch.
i really wish apple would get on top of that.
i think peripheral interconnect is a moot point :)
I'd be curious to know whether disabling "EUP Compliance"/"EUP Deep Sleep" mode resolves this issue.
The long and short of it is that the EU passed some idle power requirements that monitor companies found difficult (or expensive?) to implement and it's caused basically a decade of weird bugs in PCs, docks, and other hardware. To hit the power target they put the monitor into a really really deep sleep state and some of the implementations don't always wake up properly, or do weird things as they wake back up and restart.
(this occurs even on some premium monitors and brands... my Dell P2715Q is a very high-end monitor for its day and it has bad issues with freezing after wakeup!)
This is the source of the classic "my monitor sometimes won't wake up after my PC goes to sleep, until I cycle the power to the monitor" and "all my desktop icons reshuffle themselves after sleep" and I suspect also the root cause of many "displayport issues" with thunderbolt docks.
I think EUP power draw is also why many monitors "disconnect themselves" when idle... from the perspective of the PC it's in a deep enough state it's not even responding. This is legal behavior according to the spec, it's not incorrect to do so, but it's not required, and it confuses the PC which obviously now thinks the monitor is disconnected.
I don't have any fine-grain knowledge of exactly what they are doing when they wake up but... rebooting the monitor as a method to wake it up from a deep-sleep state wouldn't surprise me all that much. It would explain the "desktop icons shuffling themselves" failure mode, windows sees a disconnected monitor (even for a second) and goes to the fallback virtual monitor (640x480 res), that's the classic behavior for a disconnected monitor, and rebooting explains why it would disconnect.
Apologies to the planet, I wish it wasn't implemented so poorly, but, turning off EUP Deep Sleep is pretty much the first thing you should do when you buy a monitor.
We had trouble finding a cheap ARMv8.1+ server, and the M1 really fit our needs. We're doing builds in a docker of Amazon Linux 2 ARM since the main use case for our software is running on AWS Graviton 2/3 instances.
why are there no bluetooth controllers that operate over pcie? well, with the now notable exception of these macs, apparently.
i’d looked for them in the past, but could never find one. i always thought i’d just never looked in the right places, or there were a few obscure vendors for them. but the fact that bluetooth over pcie is not supported in linux yet indicates there might not be any out in the wild at all! very strange.
Even the few PCI express add-on bluetooth cards that are "PCI only" have a small USB controller builtin. So the host OS sees a USB addon card with a Bluetooth device hanging from it. There's zero drivers needed since both the USB controller and the Bluetooth USB device is standarized.
If you now decide to remove the USB controller, all you're doing is suddenly making an incompatible interface that now requires drivers for questionable benefits. I will vote to keep the standard any other day.
That said, most PCI addon cards just ditch the onboard USB controller and force you to connect the USB bluetooth device to the USB controller on the motherboard, though. And THEN they require drivers anyway because volatile firmware or whatever.
well, aside from principle simplicity, you wouldn't need to have a USB stack to have bluetooth connectivity - a protocol plagued with "mysterious" connectivity issues - any reduction in that complexity is a benefit. it might even result in a modest increase in energy efficiency.
> There's zero drivers needed since both the USB controller and the Bluetooth USB device is standarized.
the bluetooth stack is standardized, true, but as far as i understand, this has as much to do with USB as a mouse or a keyboard (indeed, as mentioned in the post, the only required stitch-up work was to between the bluetooth HCI interface and a pcie transport)
> If you now decide to remove the USB controller, all you're doing is suddenly making an incompatible interface that now requires drivers for questionable benefits.
i don't think that'd be the case.
There's very little to this -- USB is a well known standard and power saving in USB is also well understood and exercised. PCIe power saving was not even a thing until relatively recently, and anything you'd developed for this new "HCI-over-raw-PCIe" thing would have to be done almost from scratch. It's ironic, but USB-over-PCIe may actually be the simpler "logical" protocol than raw PCIe, and may even provide further physical power saving considering how dead simple USB is as an interface. Or used to be. Cough.
well i mean it's all PCIe at the end of the day - all the USB stacks run on top of PCIe lanes - principally anything USB is pure overhead.
> PCIe power saving was not even a thing until relatively recently, and anything you'd developed for this new "HCI-over-raw-PCIe" thing would have to be done almost from scratch.
as far as i can tell PCIe power saving is still not a thing (at least of any significance). in any case, the energy usage of the transport layer and what messages you're sending over it should be largely orthogonal - i don't know exactly what you think you'd need to implement here. i mean, we're not being hypothetical here: apple have literally done this in their new macs, and the blog post specifies what they had to do to make it work in asahi: send the bluetooth HCI messages over the PCIe transport directly!
> [...] and may even provide further physical power saving considering how dead simple USB is as an interface
again, it's all already on PCIe no matter which way you cut it..
This is why I said the "it's ironic" part. First, realize that under no circumstances a USB link would be "higher power" than a PCIe link just because logically there is a USB controller which connects via PCIe "no matter which way you cut it, precisely because in a way it matters "which way you cut [the interfaces]". An USB link can be as low as 2 wires. Make the math...
> apple have literally done this in their new macs, and the blog post specifies what they had to do to make it work in asahi: send the bluetooth HCI messages over the PCIe transport directly!
And how do we even know if this is the correct, low power behavior? Have they implemented runtime power management for this device? D3cold rings a bell ?
For better or worse, power management _is_ a well understood problem with USB devices & controllers; you can be pretty sure the Linux USB controller driver is as low-power as it gets; you have much fewer assurances if you go directly to the PCIe. I'm quite sure that the "mysterious connectivity issues" you attribute to USB are in part due to runtime power management logic.
Best of luck with future endeavors.
[0]:https://github.com/AsahiLinux/AsahiLinux.github.io/pull/4
Just "still alive"? They delivered solid results very fast, and never lost steam...
Thoughts, comments, observations?
I hope over the next months there is a way to access eGPUs without giving up the macos installation, even if it is over some Asahi VM with direct access to the hardware somehow.
It can, theoretically, be enabled, but be prepared to give up a lot of hardware security and also expect every app you want to use to need a patch because it breaks ABI.
Do you have any pointers, either blog or article, regarding the issue with arm and the raspberry pi?
That’s actually a non-Apple-Silicon machine using the M1 as an eGPU, for ease of development.
Does this imply we can anticipate GPU virtualization in MacOS VMs (not running on a MacOS host) at some point?