The goal of the Asahi Linux project is to develop clean, maintainable, upstreamed, first-class support for Apple Silicon on Linux, that works as well or better

The goal of the Asahi Linux project is to develop clean, maintainable, upstreamed, first-class support for Apple Silicon on Linux, that works as well or better than Linux on x86. From the beginning I said we weren't going for a tech demo, but for the long-term product. We are also documenting the hardware here: https://github.com/AsahiLinux/docs/wiki https://github.com/AsahiLinux/docs/wiki I don't know what Corellium's goal is, since it isn't clear what they get out of this as a company other than PR, nor have they interacted with the open source community in any way whatsoever to date (I publicly invited them to our IRC channels and they've yet to show up), nor attempted to upstream any of their work (a third party has and that didn't go so well for the first version). They seem to be going for the tech demos and PR angle, judging by their actions and codebase so far :) E.g I spent most of Saturday debugging the source of L2 memory subsystem bus error exceptions in our bootloader, m1n1. Corellium's codebase and preloader just turns off reporting those errors entirely, all the way into Linux. There are very, very different approaches going on here. FWIW, Corellium had been developing their kernel in secret for A14 devices (that's the extremely similar iPhone version of the M1) for months now, plus had previous versions for older Apple SoCs, so it's not like they did this in two weeks; rather that they are currently piecewise releasing and adapting code they've had for a while and developed on jailbroken devices, while we/Asahi Linux started from scratch mid-January when Apple finally published the tools to run your own kernels on M1 Macs. I'm happy to pull any drivers they develop and release that are clean and upstreamable, but we're working step by step and I'm not in a race with them; we're in this for the long run and I want to make sure anything we work on is the right way of doing things. We're also working on GPU acceleration, which is a hard requirement for a usable desktop, and which as far as I know Corellium have nothing on. Alyssa is working on the userspace side already; I'll jump on the kernel side as soon as the necessary kernel dependencies are in. I'm currently writing a quick start guide to help other kernel devs with interest get started with development, and in the coming weeks I will be taking some time to develop an open hardware design for a serial debug cable for these machines, and building some prototypes to send to other kernel devs to help bootstrap community members who want to help. Today I'm also working on using one M1 machine as a serial terminal for another, with a standard type C cable (it should be possible AIUI, but I need to reverse engineer some details to get the right commands sent to the Type C controller) - not the cheapest solution but certainly the lowest effort one right now, if you have the money for two M1 boxes.