18 ms·

Asahi Linux for M1 Macs: progress report for September 2021

474 points by fanf2 5y ago

ngcc_hk 5y ago
The hypervisor option to run macOS is a good way out for testing and using. Great job!
deleted 5y ago
[deleted]
dirtybirdnj 5y ago
This looks super cool! I just got an M1 MBA, it's fast as lightning. Its nice knowing a project like this is percolating and that in a few years when this daily driver becomes an extra machine there will be fun linux alternatives to try.
- markenqualitaet 5y ago
  If your MacBook is still working by then. Looks like there is a lawsuit against Apple, because there are hardware issues with the screens of M1 Air and Pro. Before there was the USB-C PD to brick issue, but that may have been fixed now. Overall, not the best track record for longevity.
gigatexal 5y ago
Anyone know if the *BSDs are following this work in parallel or plan on doing the same? It would be nice to have some choice — yea I know MacOS is Darwin plus the BSD userland but I like the idea of throwing FreeBSD on an old M1 when I get sick of Linux (even if I eventually go back to a distro…)
- my123 5y ago
  So far NetBSD and OpenBSD are working on the M1 port. https://wiki.netbsd.org/ports/evbarm/apple/ https://wiki.netbsd.org/ports/evbarm/apple/ for NetBSD install instructions. I don't see a focus on the FreeBSD side (yet?) however.
  - gigatexal 5y ago
    wow they've made a ton of progress -- wish this work got more press. Not to take away from the Asahi linux folks's work but I had no idea the netbsd for example was this far along.
    - marcan_42 5y ago
      Mark Kettenis has been working on the OpenBSD and U-Boot ports with us, and we'll be relying on U-Boot for our end user installs :) We're also dual licensing all our bespoke drivers, so the BSDs can take code from there (particularly important for the GPU driver, as there is already a lot of shared code in that subsystem). I'm actually thinking I'm going to rewrite the WiFi support patch for Linux from scratch, based on the OpenBSD version, just because they did a great job distilling what matters out of the original messy PoC patch that Corellium dumped earlier this year.
      - gigatexal 5y ago
        amazing -- godspeed!
Syonyk 5y ago
Hm. I've got an M1 Mini laying around (Apple annoyed me enough in the past six months that I've gone away from them entirely, replacing a M1 Mini with an ODroid N2+, among other things). If it's daily drivable, I suppose I should see about getting Linux installed on it. I've not gotten around to selling it yet...
- pengaru 5y ago
  If Apple has really annoyed you, put that Mini on the used market ASAP where it can potentially displace a new unit sale. Not that I'm unsupportive of the Asahi project, it's just a fact that you're dong Apple a favor by keeping that M1 Mini around collecting dust, while every passing day it becomes increasingly irrelevant WRT offsetting new unit sales.
- wayneftw 5y ago
  I put Manjaro on my 2012 Mac Pro and it was so frustrating to even get the boot loader running that I'll never run Linux on a Mac again. Once it was running, Apple's garbage BIOS continued to present issues too. If I don't have to work with iOS anymore then I'll never even buy another Mac.
- lyssa 5y ago
  > replacing a M1 Mini with an ODroid N2+, Hey, if you're running Linux, you're using my drivers either way ;-) Now back to typing away at Panfrost on my M1 Linux to debug an issue on the Odroid N2 I have Ethernet connected to the M1...
deleted 5y ago
[deleted]
techrat 5y ago
Sell it and buy something better with actual Linux support. Anything that involves installing Linux onto an M1 will always be an unsupported hack*, at best. * Some of y'all need to unwad your panties and look at the overall picture here. Without Apple contributing to the kernel or at least documenting the system, getting ANYTHING running on an M1 is still a hack... ...regardless of the quality of the end result. I wish the Asahi Linux folks the best of luck and have no doubt that they're capable. I just wish it wasn't so much effort put towards hardware from a company that is known for its incredibly hostile response to users doing what they want with the hardware they own. And for those who insist that 'unsupported hack' is an insult, you should look up other meanings in the dictionary sometime. * Definition of Unsupported: (of a program, language, or device) not having assistance for the user available from a *manufacturer* or systems manager. * Definition of Hack: an act of computer hacking.
- r00fus 5y ago
  Makes sense, even as someone who wishes I had an M1 mini lying about (all non-trivial purchases need home CFO approval) I would be hesitant to install Linux on it as I'm not a kernel hacker.
- marcan_42 5y ago
  Our project's goal is not to produce an "unsupported hack", it's to make these machines work at least as good as, if not better than, any other machine with "actual Linux support" ;-)
  - butterisgood 5y ago
    All I can say is I wish you luck!
  - nextos 5y ago
    That's cool. Some Macs rank near the top in terms of Linux support and openness. E.g., the MacBook 2,1 is one of the very few laptops supported by Libreboot. Others are totally unusable. I like Apple hardware (and ThinkPads), but I prefer the openness of Linux (and BSD). Current MacBook Airs are pretty competitive in terms of price, and the fanless CPU is very appealing. Is it much of a gamble to purchase one now expecting to run mainline Linux in a year or so? Aside from the new architecture, some components Apple has been using are quite unfriendly. Broadcom wireless cards tend to perform really poorly with open source drivers.
asdff 5y ago
Meta but does the name have any relation or maybe give homage to the other Asahi? https://en.wikipedia.org/wiki/Asahi_Pentax https://en.wikipedia.org/wiki/Asahi_Pentax
- HMH 5y ago
  Their about page only says: > Asahi means “rising sun” in Japanese, and it is also the name of an apple cultivar. 旭りんご (asahi ringo) is what we know as the McIntosh Apple, the apple variety that gave the Mac its name.
- marcan_42 5y ago
  There are lots of things called Asahi (a beer, a newspaper, an ISP, ...), but our project is specifically named after the Asahi apple, which is the Japanese name for the McIntosh Apple. https://asahilinux.org/about/ https://asahilinux.org/about/
  - gilbetron 5y ago
    That's ridiculously clever.
- barkingcat 5y ago
  There are tons of "other Asahi" - among other things it's a beer (super dry), baseball team, ramen noodle moniker
schmichael 5y ago
Asahi Linux progress reports rank up there with Dolphin[1] progress reports for being excellent examples of technical writing as well as simply reminding me why I fell in love with computers in the first place. Love reading this stuff even if I may never use it (although I would love to run Linux on M1 hardware someday!). [1] https://dolphin-emu.org/blog/ https://dolphin-emu.org/blog/
- m4rtink 5y ago
  Still a bit sad that in both cases its effectively righting of wrongs caused by closed down undocumented computing platform. On the other hand if the respective authors like accepting such challenges and working on these projects, there is nothing wrong with that. :)
  - emptyparadise 5y ago
    Can't write a good detective story without a mystery, after all.
- philistine 5y ago
  How about running Dolphin in Linux on M1 software?
  - marcan_42 5y ago
    Should work just fine. It already runs on macOS on M1, and on ARM64 on Linux in general. Just needs a GPU driver to perform well :)
vletal 5y ago
Observing the achievements of this group of young talented devs only increases my imposter syndrome. Awesome job, love the enthusiasm.
- morganvachon 5y ago
  Agreed, I have a M1 mini sitting around doing mostly nothing and I'd love to use it to contribute to the project but I'm not a developer so I don't know where to start. I am definitely looking forward to the mentioned installer release so I can try it out myself though. I can believe the hype about how blazing fast it is on the desktop even in software rendering, given how powerful a Linux VM on Parallels can be on it. It rivals my Ryzen 5 3600 machine and even surpasses it in some metrics, and that runs Linux bare metal.
  - markenqualitaet 5y ago
    Do you know about Marcan's YouTube channel? He livestreams (some of) the hacking, so you can actually see exactly how to start! They are super huge packages, but make for excellent ambient stimulation. I wish he was doing tutorial style videos, too. Pleasant voice, well-spoken and incredible knowledgeable. I bet he could do videos which don't have you thinking "Yeah, but why does this work?".
    - marcan_42 5y ago
      I tried doing one of those! It's not exactly a tutorial, but it's an attempt at a walk through everything that went into building the hypervisor that we use for hardware reverse engineering and testing. https://youtu.be/igYgGH6PnOw https://youtu.be/igYgGH6PnOw
      - markenqualitaet 5y ago
        I don't follow your feed too closely, as it's usually not within my time budget, so I missed that. Thank you very much for doing what you do! You are an inspiration to me and I admire the calm and structured way you work. Hope you keep enjoying what you do!
thoughtsimple 5y ago
Mind blowing progress! So impressed with the Asahi team.
bgorman 5y ago
"On typical SoCs, drivers have intimate knowledge of the underlying hardware, and they hard-code its precise layout: how many registers, how many pins, how things relate to each other, etc...... However, Apple is unique in putting emphasis in keeping hardware interfaces compatible across SoC generations ..... the device tree then can be used to represent the dependency relationships between these power domains dynamically. ... This approach is unfamiliar to most upstream subsystem maintainers, but we hope they recognize the benefits over time. Who knows, perhaps this will inspire other manufacturers to do it this way!" This is really weird commentary to me, as far as I know Device Tree has been the standard for embedded ARM drivers in the Linux kernel for years, and for several years on PowerPC before that. When I worked in embedded linux, often the "bringup" for components in new ASICs was to create the device tree definition. What am I missing here?
- marcan_42 5y ago
  This is about compatible properties. On typical DTs and SoCs, you end up with entirely new compatibles for tons of stuff every SoC generation, and it'd never work with the old ones. What we're doing is putting on generic compatibles that old drivers can continue to bind to, and designing the rest of the binding to be generic enough to describe parameters of the device. So, a GPIO driver for a random SoC might hardcode that it has 42 pins. Ours uses a property instead. The vast majority of clock and power management drivers for other SoCs hard code the clock or power hierarchy and provide static sets of outputs. We put every single clock control in a separate DT node and describe their relationships. A typical cpufreq driver has intimate knowledge of the clocking controls for the whole SoC, and hardcodes the layout of the clock registers. My prototype for that just has a separate instance for each CPU cluster, and describes the performance states in the DT. And so on and so forth. Basically, on a typical SoC, either a hardware block is identical to last generation's, or it's incompatible. Apple's blocks instead follow patterns, so we're building parameterizable bindings that can handle any configuration of those blocks with a single driver.
saagarjha 5y ago
> It’s not perfect, as it can’t support a select few corner case drivers (that do things that are fundamentally impossible to support in this situation), but it works well and will support everything we need to make 4K kernels viable. I'm curious what these corner cases are; could anyone share?
- marcan_42 5y ago
  eGPUs for one, but there are bigger problems to solve there. Other than that, IIRC some v4l stuff did this, and a few others. It's a tiny subset of drivers.
  - floatboth 5y ago
    > bigger problems to solve there It's not the fucking "maximum BAR size is tiny" problem again is it? (hello Rockchip :D)
    - marcan_42 5y ago
      Nah, but I was informed the other day that GPU drivers apparently like to map BARs as normal cacheable memory and... I'm not sure the M1 supports that. And then if you don't do that you run into problems with apps mapping GPU memory and doing unaligned accesses (plus it's a performance problem).
      - floatboth 5y ago
        drm likes uncacheable write-combining as an optimization… but that's disabled on arm64 https://patchwork.kernel.org/project/linux-arm-kernel/patch/20190124120658.30288-1-ard.biesheuvel@linaro.org/ https://patchwork.kernel.org/project/linux-arm-kernel/patch/... because it can cause image corruption glitches (saw them myself, had to find and cherry-pick that commit into FreeBSD's drm back then) Generally I don't think "normal" is necessary? In FreeBSD/aarch64 we interpret most ioremaps (all other than WC and WB) as "device": https://reviews.freebsd.org/D20789 https://reviews.freebsd.org/D20789 and there doesn't seem to be a performance problem. Well, I haven't scientifically tested the performance but SuperTuxKart can do >100fps at 4K on an RX 480 :)
gringo_flamingo 5y ago
This fascinates me, all these negative comments that seem to stem from projections of fear of failure. Yeah, this project has a chance to fail, like everything else in life. But to me I think this project will be indeed ready in a few years, and I will certainly be running this on my M1 as soon as it is stable and useful. It will be interesting to see how this turns out, I just wanted to comment on the next-level narcissism going on. Why most of you choose to be pessimistic and make not your problem, your problem, is beyond me. Keep up the great work Team, Asahi!
- deleted 5y ago
  [deleted]
- webmobdev 5y ago
  > all these negative comments that seem to stem from projections of fear of failure. No. I criticise this project because it adds value to a device that we should all be boycotting. We absolutely do not want to see the proliferation of custom, locked down SoCs on the desktop platform with each one being incompatible with each other, and limiting our freedom to run what code we want on it. That is why this project is extremely short-sighted for the future of our computing freedom. The M1 is a locked blackbox. It is designed to take away user control on both hardware and software. These are legitimate criticism that many Apple fans try to deflect. They claim that the M1 isn't a locked down machine by comparing it with the ios platform as proof. After all, iPhones and iPads have locked bootloaders that prevent you from even running any other OS, while this is not so with the M1 computers. That's just plain denial. Just look at what has been happening to the Mac Mini: 1. The first few Intel Mac Minis allowed you some level of customisation of both the hardware (change RAM or HDD / SSD) and software (install other full featured OS). 2. Then came the Mac Minis with soldered RAM and SSD. You could no longer customise the hardware. Software was still customisable and you could still install other OSes. (Recall that Apple even offered free drivers for another OS, i.e. Windows). 3. The current generation of M1 Mini now doesn't allow you to customise both the hardware (everything is soldered) and the software. Technically you can install other OSes, but the reality is that currently only crippled versions of Linux and xBSD is available and practically the only full-featured OS available for it is macOS. These are clear indicators of how Apple has been working slowly to lockdown the Mac platform like their ios platforms. (Right now, projects like these give Apple and M1 publicity without harming their end goals. And so they are tolerated. Want to bet that as soon as some alternate fully featured viable OS appears for the M1, the bootloader will be locked, and the next Apple SoC will cripple it again?). The frog is still slowly boiling - https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog - to keep you in denial. There's another reason why I call this particular project short-sighted. Remember what happened when Apple introduced the Mini with soldered RAM and SSD's? It wasn't popular and didn't sell. Apple was forced to backtrack and the next Mini didn't have soldered RAM (but the SSD was still soldered). A similar thing could have been possible with the M1 too. Apple has bet their future on the success of their ARM processors. But if people boycotted Apple Silicon desktop platform for not being as open as AMD / Intel, Apple would have been forced to compromise a bit (at least strategically for the short-term) and released more literature to make the platform seem a little more open. And we might have seen Linux and xBSD being supported on the platform by now.
rubatuga 5y ago
Amazing progress. However I don’t imagine GPU driver progress will be fast, or ready in the near future.
- marcan_42 5y ago
  Reminder that GPU userspace is passing 90% or so of the GLES2 tests. It's just missing kernelspace, which is arguably the easier part.
  - marcalc 5y ago
    That’s absolutely exciting. Thanks for all your efforts and the team’s! I hope to contribute with the project somehow, but you guys are on another “lower”-level :) Cheers
kelnos 5y ago
> The NVMe hardware in the M1 is quite peculiar: it breaks the spec in multiple ways, requiring patches to the core NVMe support in Linux, and it also is exposed as a platform device instead of PCIe. In addition, it is managed by an ASC, the “ANS”, which needs to be brought up before NVMe can work, and that also relies on a companion “SART” driver, which is like a minimal IOMMU. Stuff like this makes me wonder: why does Apple do this? If I try to give them the benefit of the doubt, I can assume that these changes are done for performance, cost, power-saving, or maybe even security reasons. Otherwise it just seems like Apple does these things in order to make it harder for other OSes to run on their hardware. Which is certainly their prerogative, but it just makes me think less of them. On the other hand, this is really cool: > However, Apple is unique in putting emphasis in keeping hardware interfaces compatible across SoC generations – the UART hardware in the M1 dates back to the original iPhone! This means we are in a unique position to be able to try writing drivers that will not only work for the M1, but may work –unchanged– on future chips as well. ... but cynically (or perhaps just realistically), I can easily believe that this isn't done for reasons of openness, but because this makes maintenance of macOS itself easier for Apple.
- jeffbee 5y ago
  I believe this has come up multiple times on HN but the reason Apple breaks NVMe is because NVMe command structure isn't large enough to hold all the crypto state information they need to shove down to the device. The spec would not support what they are doing, so their choice was to either tweak NVMe to suit, or abandon their feature.
  - floatboth 5y ago
    Why are they even doing crypto at the NMVe level?! Why is it not good enough for them to do it at the filesystem level (like ZFS native encryption) or at least block device level (GELI/dm-crypt/etc)?
    - marcan_42 5y ago
      Because that way the OS does not need to ever see the low level keys. It allows them to feed them straight from the Secure Enclave, which means an OS compromise can never result in compromise of storage encryption. Plus they do the crypto in a hardware accelerator, so it's free for the CPU.
techrat 5y ago
> why does Apple do this? User hostility. They started soldering ram onto motherboards, even in devices that had plenty of space (iMacs) when it cut too much into their margins because people were doing upgrades themselves instead of paying for the 2000% premium to have Apple do it for them. Then they soldered the SSD to the Macbook boards. Despite having a long running bug that prematurely wears out the SSD. Glue in Macbooks with the batteries where it wasn't necessary. Soldered down glass backs on iPhones. Serialized hardware AND batteries that cannot be swapped between identical models. Everything they do is user hostile and anticompetitive. Every step of the way, when something was found to be user repairable or replaceable, the next iteration had that 'fixed.' * The fanboys have arrived. Factual discussion will not be tolerated. Downvotes shall commence without comment! *
- kelnos 5y ago
  I don't think this really makes sense. I agree that you could characterize things like soldering on RAM and storage, or gluing the battery in, as user-hostile (because that means the user can't repair or replace or upgrade), but changing the interface used by a component that's already integrated just won't matter to any user (at least one that is staying in the Apple ecosystem). This sort of thing only matters to people who want to run Linux or Windows (or something else) on Apple hardware. > The fanboys have arrived. Factual discussion will not be tolerated. Downvotes shall commence without comment! Please don't do this. Complaining about downvotes is a waste of time, and ultimately detracts further from what you're trying to say.
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - simonh 5y ago
    I don’t get the glued battery complaint though. I’ve replaced the battery on 4 iPhones of 3 different models and the glue is just a sticky blob holding the battery in place. It was trivial to prize the battery off and press a new one into place.
jjtheblunt 5y ago
really naive question: why not run Parallels since it now uses the native macOS hypervisor.framework, and then Linux / Haiku / FreeBSD / whatever? i thought of that as it somewhat outsources device driver digressions.
- horsawlarway 5y ago
  Because then you still don't own the hardware - Apple does. Support can be pulled out from underneath you at any point and you're limited to the exposed hardware interfaces. Throw on top that (at least for me) I have zero desire to maintain a macOS machine.
- marcan_42 5y ago
  Because virtual hardware will never work as well as real hardware. You're layering one OS on top of another; that's not free. No GPU acceleration, etc. (Plus, we actually support the M1's vGIC which Hypervisor.framework does not yet, so VMs running on Linux should perform better than VMs running on macOS! Yes, we beat Apple at supporting some parts of the M1 already.)
Rob_Polding 5y ago
I cannot wait for this to come to fruition. Thanks for all the hard work, I'll be installing it as soon as sound and GPU acceleration hit. Amazing work :-)
andy_ppp 5y ago
It’s so good that I decided to sponsor the project a while back. I will probably never use it but I really like these guys talent and dedication!
silasb 5y ago
This is just embarrassing. > the M1’s CPUs are so powerful that a software-rendered desktop is actually faster on them than on e.g. Rockchip ARM64 machines with hardware acceleration.
alin23 5y ago
I wonder if Alyssa (or other devs that took a deeper look at the DCP) have any idea why the builtin HDMI port of the Mac Mini would not send DDC messages to the connected monitor. I’ve been struggling with this in Lunar (https://lunar.fyi https://lunar.fyi) for a long time and while I tried my best by comparing ioreg dumps and looking at the DCP driver in IDA, I couldn’t find any obvious logic would block this communication voluntarily. I should mention that on M1, the DDC messages are sent to the monitor by calling IOAVServiceWriteI2C on the DCPAVServiceProxy of the monitor as seen here: https://gist.github.com/alin23/b476a02a8cd298436848e28476aed07b https://gist.github.com/alin23/b476a02a8cd298436848e28476aed... I’m thinking that this logic might either exist in the DCP firmware which is not accessible from userspace, or it might just be a side effect of some out of spec behavior that the HDMI port might have.
- lyssa 5y ago
  The DCP firmware has multiple endpoints. Currently, we only use and understand the main endpoint, which lacks raw I2C/DDC/EDID interfaces. Presumably this is available on another endpoint, but we haven't looked at this yet. Your gist gives me hope. The HDMI port on the Mini is funny. The M1 supports exactly one internal display (the panel on a MacBook or iThing) and one external display (over DisplayPort/Thunderbolt). This is why M1 MacBooks can only drive a single external monitor. For the Mini, the "internal" display is an internal DisplayPort connection, converted to HDMI with a mcdp29xx chip, and stuck on the HDMI port. Expect weirdness.
  - alin23 5y ago
    I thought it must be something related to the DisplayPort transport. I noticed in ioreg that the HDMI AppleCLCD2 had downstream=HDMI upstream=DP as its transport params. So its possible that it isn’t DCP related after all, the mcdp29xx chip might not be implementing the DDC part at all like most USB-C hubs that I have to deal with. Thanks for the insight!
    - marcan_42 5y ago
      It's worth noting that the MDCP29xx has its own DCP endpoint and proxy driver, so it likely implements its own DDC channel that way. Obviously, DCP itself needs to get the EDID one way or another. We'll see once we start looking into those add-on endpoints :)
masterof0 5y ago
This is a truly amazing project. I'm contributing financially (as I don't have the time to contribute code) to help Alyssa and the rest of the team. If you can, you should too.
heavyset_go 5y ago
I was initially critical of this endeavor before it started. However, the issues I had in mind have been addressed and this effort is truly impressive. I really appreciate that marcan is committed to going beyond doing this the right way.
marcalc 5y ago
So good to read Marcan’s comments on this thread, so much context. Thank you!
TheMagicHorsey 5y ago
I wonder if it would be legal for a veteran of Apple, who has worked on porting MacOS to M1, to take that knowledge of the hardware and assist with BSD or Linux porting? On the one hand its just porting to a piece of hardware, but on the other hand she may be using some proprietary knowledge of a closed interface. Anyone have experience with doing this for Apple hardware? Does the company come after you if you reveal some of this knowledge to the wider public? Not asking for myself, BTW, as I have had no affiliation with Apple.

474 points by fanf2 5y ago

ngcc_hk 5y ago

The hypervisor option to run macOS is a good way out for testing and using. Great job!

deleted 5y ago

[deleted]

dirtybirdnj 5y ago

This looks super cool! I just got an M1 MBA, it's fast as lightning. Its nice knowing a project like this is percolating and that in a few years when this daily driver becomes an extra machine there will be fun linux alternatives to try.

markenqualitaet 5y ago
If your MacBook is still working by then. Looks like there is a lawsuit against Apple, because there are hardware issues with the screens of M1 Air and Pro. Before there was the USB-C PD to brick issue, but that may have been fixed now. Overall, not the best track record for longevity.

gigatexal 5y ago

Anyone know if the *BSDs are following this work in parallel or plan on doing the same? It would be nice to have some choice — yea I know MacOS is Darwin plus the BSD userland but I like the idea of throwing FreeBSD on an old M1 when I get sick of Linux (even if I eventually go back to a distro…)

my123 5y ago
So far NetBSD and OpenBSD are working on the M1 port. https://wiki.netbsd.org/ports/evbarm/apple/ https://wiki.netbsd.org/ports/evbarm/apple/ for NetBSD install instructions. I don't see a focus on the FreeBSD side (yet?) however.
- gigatexal 5y ago
  wow they've made a ton of progress -- wish this work got more press. Not to take away from the Asahi linux folks's work but I had no idea the netbsd for example was this far along.
  - marcan_42 5y ago
    Mark Kettenis has been working on the OpenBSD and U-Boot ports with us, and we'll be relying on U-Boot for our end user installs :) We're also dual licensing all our bespoke drivers, so the BSDs can take code from there (particularly important for the GPU driver, as there is already a lot of shared code in that subsystem). I'm actually thinking I'm going to rewrite the WiFi support patch for Linux from scratch, based on the OpenBSD version, just because they did a great job distilling what matters out of the original messy PoC patch that Corellium dumped earlier this year.
    - gigatexal 5y ago
      amazing -- godspeed!

Syonyk 5y ago

Hm. I've got an M1 Mini laying around (Apple annoyed me enough in the past six months that I've gone away from them entirely, replacing a M1 Mini with an ODroid N2+, among other things). If it's daily drivable, I suppose I should see about getting Linux installed on it. I've not gotten around to selling it yet...

pengaru 5y ago
If Apple has really annoyed you, put that Mini on the used market ASAP where it can potentially displace a new unit sale. Not that I'm unsupportive of the Asahi project, it's just a fact that you're dong Apple a favor by keeping that M1 Mini around collecting dust, while every passing day it becomes increasingly irrelevant WRT offsetting new unit sales.
wayneftw 5y ago
I put Manjaro on my 2012 Mac Pro and it was so frustrating to even get the boot loader running that I'll never run Linux on a Mac again. Once it was running, Apple's garbage BIOS continued to present issues too. If I don't have to work with iOS anymore then I'll never even buy another Mac.
lyssa 5y ago
> replacing a M1 Mini with an ODroid N2+, Hey, if you're running Linux, you're using my drivers either way ;-) Now back to typing away at Panfrost on my M1 Linux to debug an issue on the Odroid N2 I have Ethernet connected to the M1...

deleted 5y ago

[deleted]

techrat 5y ago

Sell it and buy something better with actual Linux support. Anything that involves installing Linux onto an M1 will always be an unsupported hack*, at best. * Some of y'all need to unwad your panties and look at the overall picture here. Without Apple contributing to the kernel or at least documenting the system, getting ANYTHING running on an M1 is still a hack... ...regardless of the quality of the end result. I wish the Asahi Linux folks the best of luck and have no doubt that they're capable. I just wish it wasn't so much effort put towards hardware from a company that is known for its incredibly hostile response to users doing what they want with the hardware they own. And for those who insist that 'unsupported hack' is an insult, you should look up other meanings in the dictionary sometime. * Definition of Unsupported: (of a program, language, or device) not having assistance for the user available from a *manufacturer* or systems manager. * Definition of Hack: an act of computer hacking.

r00fus 5y ago
Makes sense, even as someone who wishes I had an M1 mini lying about (all non-trivial purchases need home CFO approval) I would be hesitant to install Linux on it as I'm not a kernel hacker.
marcan_42 5y ago
Our project's goal is not to produce an "unsupported hack", it's to make these machines work at least as good as, if not better than, any other machine with "actual Linux support" ;-)
- butterisgood 5y ago
  All I can say is I wish you luck!
- nextos 5y ago
  That's cool. Some Macs rank near the top in terms of Linux support and openness. E.g., the MacBook 2,1 is one of the very few laptops supported by Libreboot. Others are totally unusable. I like Apple hardware (and ThinkPads), but I prefer the openness of Linux (and BSD). Current MacBook Airs are pretty competitive in terms of price, and the fanless CPU is very appealing. Is it much of a gamble to purchase one now expecting to run mainline Linux in a year or so? Aside from the new architecture, some components Apple has been using are quite unfriendly. Broadcom wireless cards tend to perform really poorly with open source drivers.

asdff 5y ago

Meta but does the name have any relation or maybe give homage to the other Asahi? https://en.wikipedia.org/wiki/Asahi_Pentax https://en.wikipedia.org/wiki/Asahi_Pentax

HMH 5y ago
Their about page only says: > Asahi means “rising sun” in Japanese, and it is also the name of an apple cultivar. 旭りんご (asahi ringo) is what we know as the McIntosh Apple, the apple variety that gave the Mac its name.
marcan_42 5y ago
There are lots of things called Asahi (a beer, a newspaper, an ISP, ...), but our project is specifically named after the Asahi apple, which is the Japanese name for the McIntosh Apple. https://asahilinux.org/about/ https://asahilinux.org/about/
- gilbetron 5y ago
  That's ridiculously clever.
barkingcat 5y ago
There are tons of "other Asahi" - among other things it's a beer (super dry), baseball team, ramen noodle moniker

schmichael 5y ago

Asahi Linux progress reports rank up there with Dolphin[1] progress reports for being excellent examples of technical writing as well as simply reminding me why I fell in love with computers in the first place. Love reading this stuff even if I may never use it (although I would love to run Linux on M1 hardware someday!). [1] https://dolphin-emu.org/blog/ https://dolphin-emu.org/blog/

m4rtink 5y ago
Still a bit sad that in both cases its effectively righting of wrongs caused by closed down undocumented computing platform. On the other hand if the respective authors like accepting such challenges and working on these projects, there is nothing wrong with that. :)
- emptyparadise 5y ago
  Can't write a good detective story without a mystery, after all.
philistine 5y ago
How about running Dolphin in Linux on M1 software?
- marcan_42 5y ago
  Should work just fine. It already runs on macOS on M1, and on ARM64 on Linux in general. Just needs a GPU driver to perform well :)

vletal 5y ago

Observing the achievements of this group of young talented devs only increases my imposter syndrome. Awesome job, love the enthusiasm.

morganvachon 5y ago
Agreed, I have a M1 mini sitting around doing mostly nothing and I'd love to use it to contribute to the project but I'm not a developer so I don't know where to start. I am definitely looking forward to the mentioned installer release so I can try it out myself though. I can believe the hype about how blazing fast it is on the desktop even in software rendering, given how powerful a Linux VM on Parallels can be on it. It rivals my Ryzen 5 3600 machine and even surpasses it in some metrics, and that runs Linux bare metal.
- markenqualitaet 5y ago
  Do you know about Marcan's YouTube channel? He livestreams (some of) the hacking, so you can actually see exactly how to start! They are super huge packages, but make for excellent ambient stimulation. I wish he was doing tutorial style videos, too. Pleasant voice, well-spoken and incredible knowledgeable. I bet he could do videos which don't have you thinking "Yeah, but why does this work?".
  - marcan_42 5y ago
    I tried doing one of those! It's not exactly a tutorial, but it's an attempt at a walk through everything that went into building the hypervisor that we use for hardware reverse engineering and testing. https://youtu.be/igYgGH6PnOw https://youtu.be/igYgGH6PnOw
    - markenqualitaet 5y ago
      I don't follow your feed too closely, as it's usually not within my time budget, so I missed that. Thank you very much for doing what you do! You are an inspiration to me and I admire the calm and structured way you work. Hope you keep enjoying what you do!

thoughtsimple 5y ago

Mind blowing progress! So impressed with the Asahi team.

bgorman 5y ago

"On typical SoCs, drivers have intimate knowledge of the underlying hardware, and they hard-code its precise layout: how many registers, how many pins, how things relate to each other, etc...... However, Apple is unique in putting emphasis in keeping hardware interfaces compatible across SoC generations ..... the device tree then can be used to represent the dependency relationships between these power domains dynamically. ... This approach is unfamiliar to most upstream subsystem maintainers, but we hope they recognize the benefits over time. Who knows, perhaps this will inspire other manufacturers to do it this way!" This is really weird commentary to me, as far as I know Device Tree has been the standard for embedded ARM drivers in the Linux kernel for years, and for several years on PowerPC before that. When I worked in embedded linux, often the "bringup" for components in new ASICs was to create the device tree definition. What am I missing here?

marcan_42 5y ago
This is about compatible properties. On typical DTs and SoCs, you end up with entirely new compatibles for tons of stuff every SoC generation, and it'd never work with the old ones. What we're doing is putting on generic compatibles that old drivers can continue to bind to, and designing the rest of the binding to be generic enough to describe parameters of the device. So, a GPIO driver for a random SoC might hardcode that it has 42 pins. Ours uses a property instead. The vast majority of clock and power management drivers for other SoCs hard code the clock or power hierarchy and provide static sets of outputs. We put every single clock control in a separate DT node and describe their relationships. A typical cpufreq driver has intimate knowledge of the clocking controls for the whole SoC, and hardcodes the layout of the clock registers. My prototype for that just has a separate instance for each CPU cluster, and describes the performance states in the DT. And so on and so forth. Basically, on a typical SoC, either a hardware block is identical to last generation's, or it's incompatible. Apple's blocks instead follow patterns, so we're building parameterizable bindings that can handle any configuration of those blocks with a single driver.

saagarjha 5y ago

> It’s not perfect, as it can’t support a select few corner case drivers (that do things that are fundamentally impossible to support in this situation), but it works well and will support everything we need to make 4K kernels viable. I'm curious what these corner cases are; could anyone share?

marcan_42 5y ago
eGPUs for one, but there are bigger problems to solve there. Other than that, IIRC some v4l stuff did this, and a few others. It's a tiny subset of drivers.
- floatboth 5y ago
  > bigger problems to solve there It's not the fucking "maximum BAR size is tiny" problem again is it? (hello Rockchip :D)
  - marcan_42 5y ago
    Nah, but I was informed the other day that GPU drivers apparently like to map BARs as normal cacheable memory and... I'm not sure the M1 supports that. And then if you don't do that you run into problems with apps mapping GPU memory and doing unaligned accesses (plus it's a performance problem).
    - floatboth 5y ago
      drm likes uncacheable write-combining as an optimization… but that's disabled on arm64 https://patchwork.kernel.org/project/linux-arm-kernel/patch/20190124120658.30288-1-ard.biesheuvel@linaro.org/ https://patchwork.kernel.org/project/linux-arm-kernel/patch/... because it can cause image corruption glitches (saw them myself, had to find and cherry-pick that commit into FreeBSD's drm back then) Generally I don't think "normal" is necessary? In FreeBSD/aarch64 we interpret most ioremaps (all other than WC and WB) as "device": https://reviews.freebsd.org/D20789 https://reviews.freebsd.org/D20789 and there doesn't seem to be a performance problem. Well, I haven't scientifically tested the performance but SuperTuxKart can do >100fps at 4K on an RX 480 :)

gringo_flamingo 5y ago

This fascinates me, all these negative comments that seem to stem from projections of fear of failure. Yeah, this project has a chance to fail, like everything else in life. But to me I think this project will be indeed ready in a few years, and I will certainly be running this on my M1 as soon as it is stable and useful. It will be interesting to see how this turns out, I just wanted to comment on the next-level narcissism going on. Why most of you choose to be pessimistic and make not your problem, your problem, is beyond me. Keep up the great work Team, Asahi!

deleted 5y ago
[deleted]
webmobdev 5y ago
> all these negative comments that seem to stem from projections of fear of failure. No. I criticise this project because it adds value to a device that we should all be boycotting. We absolutely do not want to see the proliferation of custom, locked down SoCs on the desktop platform with each one being incompatible with each other, and limiting our freedom to run what code we want on it. That is why this project is extremely short-sighted for the future of our computing freedom. The M1 is a locked blackbox. It is designed to take away user control on both hardware and software. These are legitimate criticism that many Apple fans try to deflect. They claim that the M1 isn't a locked down machine by comparing it with the ios platform as proof. After all, iPhones and iPads have locked bootloaders that prevent you from even running any other OS, while this is not so with the M1 computers. That's just plain denial. Just look at what has been happening to the Mac Mini: 1. The first few Intel Mac Minis allowed you some level of customisation of both the hardware (change RAM or HDD / SSD) and software (install other full featured OS). 2. Then came the Mac Minis with soldered RAM and SSD. You could no longer customise the hardware. Software was still customisable and you could still install other OSes. (Recall that Apple even offered free drivers for another OS, i.e. Windows). 3. The current generation of M1 Mini now doesn't allow you to customise both the hardware (everything is soldered) and the software. Technically you can install other OSes, but the reality is that currently only crippled versions of Linux and xBSD is available and practically the only full-featured OS available for it is macOS. These are clear indicators of how Apple has been working slowly to lockdown the Mac platform like their ios platforms. (Right now, projects like these give Apple and M1 publicity without harming their end goals. And so they are tolerated. Want to bet that as soon as some alternate fully featured viable OS appears for the M1, the bootloader will be locked, and the next Apple SoC will cripple it again?). The frog is still slowly boiling - https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog - to keep you in denial. There's another reason why I call this particular project short-sighted. Remember what happened when Apple introduced the Mini with soldered RAM and SSD's? It wasn't popular and didn't sell. Apple was forced to backtrack and the next Mini didn't have soldered RAM (but the SSD was still soldered). A similar thing could have been possible with the M1 too. Apple has bet their future on the success of their ARM processors. But if people boycotted Apple Silicon desktop platform for not being as open as AMD / Intel, Apple would have been forced to compromise a bit (at least strategically for the short-term) and released more literature to make the platform seem a little more open. And we might have seen Linux and xBSD being supported on the platform by now.

rubatuga 5y ago

Amazing progress. However I don’t imagine GPU driver progress will be fast, or ready in the near future.

marcan_42 5y ago
Reminder that GPU userspace is passing 90% or so of the GLES2 tests. It's just missing kernelspace, which is arguably the easier part.
- marcalc 5y ago
  That’s absolutely exciting. Thanks for all your efforts and the team’s! I hope to contribute with the project somehow, but you guys are on another “lower”-level :) Cheers

kelnos 5y ago

> The NVMe hardware in the M1 is quite peculiar: it breaks the spec in multiple ways, requiring patches to the core NVMe support in Linux, and it also is exposed as a platform device instead of PCIe. In addition, it is managed by an ASC, the “ANS”, which needs to be brought up before NVMe can work, and that also relies on a companion “SART” driver, which is like a minimal IOMMU. Stuff like this makes me wonder: why does Apple do this? If I try to give them the benefit of the doubt, I can assume that these changes are done for performance, cost, power-saving, or maybe even security reasons. Otherwise it just seems like Apple does these things in order to make it harder for other OSes to run on their hardware. Which is certainly their prerogative, but it just makes me think less of them. On the other hand, this is really cool: > However, Apple is unique in putting emphasis in keeping hardware interfaces compatible across SoC generations – the UART hardware in the M1 dates back to the original iPhone! This means we are in a unique position to be able to try writing drivers that will not only work for the M1, but may work –unchanged– on future chips as well. ... but cynically (or perhaps just realistically), I can easily believe that this isn't done for reasons of openness, but because this makes maintenance of macOS itself easier for Apple.

jeffbee 5y ago
I believe this has come up multiple times on HN but the reason Apple breaks NVMe is because NVMe command structure isn't large enough to hold all the crypto state information they need to shove down to the device. The spec would not support what they are doing, so their choice was to either tweak NVMe to suit, or abandon their feature.
- floatboth 5y ago
  Why are they even doing crypto at the NMVe level?! Why is it not good enough for them to do it at the filesystem level (like ZFS native encryption) or at least block device level (GELI/dm-crypt/etc)?
  - marcan_42 5y ago
    Because that way the OS does not need to ever see the low level keys. It allows them to feed them straight from the Secure Enclave, which means an OS compromise can never result in compromise of storage encryption. Plus they do the crypto in a hardware accelerator, so it's free for the CPU.

techrat 5y ago

> why does Apple do this? User hostility. They started soldering ram onto motherboards, even in devices that had plenty of space (iMacs) when it cut too much into their margins because people were doing upgrades themselves instead of paying for the 2000% premium to have Apple do it for them. Then they soldered the SSD to the Macbook boards. Despite having a long running bug that prematurely wears out the SSD. Glue in Macbooks with the batteries where it wasn't necessary. Soldered down glass backs on iPhones. Serialized hardware AND batteries that cannot be swapped between identical models. Everything they do is user hostile and anticompetitive. Every step of the way, when something was found to be user repairable or replaceable, the next iteration had that 'fixed.' * The fanboys have arrived. Factual discussion will not be tolerated. Downvotes shall commence without comment! *

kelnos 5y ago
I don't think this really makes sense. I agree that you could characterize things like soldering on RAM and storage, or gluing the battery in, as user-hostile (because that means the user can't repair or replace or upgrade), but changing the interface used by a component that's already integrated just won't matter to any user (at least one that is staying in the Apple ecosystem). This sort of thing only matters to people who want to run Linux or Windows (or something else) on Apple hardware. > The fanboys have arrived. Factual discussion will not be tolerated. Downvotes shall commence without comment! Please don't do this. Complaining about downvotes is a waste of time, and ultimately detracts further from what you're trying to say.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- simonh 5y ago
  I don’t get the glued battery complaint though. I’ve replaced the battery on 4 iPhones of 3 different models and the glue is just a sticky blob holding the battery in place. It was trivial to prize the battery off and press a new one into place.

jjtheblunt 5y ago

really naive question: why not run Parallels since it now uses the native macOS hypervisor.framework, and then Linux / Haiku / FreeBSD / whatever? i thought of that as it somewhat outsources device driver digressions.

horsawlarway 5y ago
Because then you still don't own the hardware - Apple does. Support can be pulled out from underneath you at any point and you're limited to the exposed hardware interfaces. Throw on top that (at least for me) I have zero desire to maintain a macOS machine.
marcan_42 5y ago
Because virtual hardware will never work as well as real hardware. You're layering one OS on top of another; that's not free. No GPU acceleration, etc. (Plus, we actually support the M1's vGIC which Hypervisor.framework does not yet, so VMs running on Linux should perform better than VMs running on macOS! Yes, we beat Apple at supporting some parts of the M1 already.)

Rob_Polding 5y ago

I cannot wait for this to come to fruition. Thanks for all the hard work, I'll be installing it as soon as sound and GPU acceleration hit. Amazing work :-)

andy_ppp 5y ago

It’s so good that I decided to sponsor the project a while back. I will probably never use it but I really like these guys talent and dedication!

silasb 5y ago

This is just embarrassing. > the M1’s CPUs are so powerful that a software-rendered desktop is actually faster on them than on e.g. Rockchip ARM64 machines with hardware acceleration.

alin23 5y ago

I wonder if Alyssa (or other devs that took a deeper look at the DCP) have any idea why the builtin HDMI port of the Mac Mini would not send DDC messages to the connected monitor. I’ve been struggling with this in Lunar (https://lunar.fyi https://lunar.fyi) for a long time and while I tried my best by comparing ioreg dumps and looking at the DCP driver in IDA, I couldn’t find any obvious logic would block this communication voluntarily. I should mention that on M1, the DDC messages are sent to the monitor by calling IOAVServiceWriteI2C on the DCPAVServiceProxy of the monitor as seen here: https://gist.github.com/alin23/b476a02a8cd298436848e28476aed07b https://gist.github.com/alin23/b476a02a8cd298436848e28476aed... I’m thinking that this logic might either exist in the DCP firmware which is not accessible from userspace, or it might just be a side effect of some out of spec behavior that the HDMI port might have.

lyssa 5y ago
The DCP firmware has multiple endpoints. Currently, we only use and understand the main endpoint, which lacks raw I2C/DDC/EDID interfaces. Presumably this is available on another endpoint, but we haven't looked at this yet. Your gist gives me hope. The HDMI port on the Mini is funny. The M1 supports exactly one internal display (the panel on a MacBook or iThing) and one external display (over DisplayPort/Thunderbolt). This is why M1 MacBooks can only drive a single external monitor. For the Mini, the "internal" display is an internal DisplayPort connection, converted to HDMI with a mcdp29xx chip, and stuck on the HDMI port. Expect weirdness.
- alin23 5y ago
  I thought it must be something related to the DisplayPort transport. I noticed in ioreg that the HDMI AppleCLCD2 had downstream=HDMI upstream=DP as its transport params. So its possible that it isn’t DCP related after all, the mcdp29xx chip might not be implementing the DDC part at all like most USB-C hubs that I have to deal with. Thanks for the insight!
  - marcan_42 5y ago
    It's worth noting that the MDCP29xx has its own DCP endpoint and proxy driver, so it likely implements its own DDC channel that way. Obviously, DCP itself needs to get the EDID one way or another. We'll see once we start looking into those add-on endpoints :)

masterof0 5y ago

This is a truly amazing project. I'm contributing financially (as I don't have the time to contribute code) to help Alyssa and the rest of the team. If you can, you should too.

heavyset_go 5y ago

I was initially critical of this endeavor before it started. However, the issues I had in mind have been addressed and this effort is truly impressive. I really appreciate that marcan is committed to going beyond doing this the right way.

marcalc 5y ago

So good to read Marcan’s comments on this thread, so much context. Thank you!

TheMagicHorsey 5y ago

I wonder if it would be legal for a veteran of Apple, who has worked on porting MacOS to M1, to take that knowledge of the hardware and assist with BSD or Linux porting? On the one hand its just porting to a piece of hardware, but on the other hand she may be using some proprietary knowledge of a closed interface. Anyone have experience with doing this for Apple hardware? Does the company come after you if you reveal some of this knowledge to the wider public? Not asking for myself, BTW, as I have had no affiliation with Apple.