4 ms·

He is still working on porting Linux? I’m pretty sure it already has been done. https://twitter.com/cmwdotme/status/1355660127433535490?s=21 https://twitter.co

He is still working on porting Linux? I’m pretty sure it already has been done. https://twitter.com/cmwdotme/status/1355660127433535490?s=21 https://twitter.com/cmwdotme/status/1355660127433535490?s=21

ogre_codes 6y ago
They have linux booting on bare metal. Still to be done: - GPU drivers - Wifi/ network drivers - Power management - Getting the GUI online - Audio - Bluetooth - Webcam Extra credit: - Fingerprint scanner (This may never be possible due to Secure Enclave) - Neural Engine support - ??? other M1 extensions
- bad_hat_henry 6y ago
  It says WiFi/Ethernet is done. It also looks like Power management is done? Getting GUI online? The pictures show a full desktop working.
  - marcan_42 6y ago
    They have a desktop running on simplefb. That is not a usable desktop (no matter what they say), with zero acceleration and all completely software rendered. There is literally no graphics or display driver. The bootloader gives you a chunk of RAM that is the screen and you write stuff to it. No multidisplay, no resolution switching, no hotplugging, no acceleration. It's like running x86 linux on efifb with no radeon/intel/nvidia drivers at all. Think vesafb for those old enough to remember those days, but even dumber - at least on that one you could pick a resolution. Our kernel has simplefb support too, literally all you need to do is write 5 lines of devicetree properties to get that to work - zero patches needed to the upstream simplefb driver. Here is the code in our bootloader that takes the Apple framebuffer information and stuffs it in the DT for Linux to use it: https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59 https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59 That's literally all you need to get "graphics". I was actually planning on doing exactly the demo that they did since December, with a simplefb "full Ubuntu desktop" and everything else running off of USB, for the clickbait, because it's flashy even though it's a minimal amount of work, but with a clear disclaimer that it's a tech demo and there is a lot of work left to do. It certainly brings in the news. However, it is not a "fully usable Linux desktop". FWIW: WiFi is Broadcom FullMAC (existing Linux driver) with some patches. Ethernet is a Broadcom chip over PCIe (once you have PCIe up, the driver is there). USB is DWC3 (existing Linux driver) with just an Apple PHY adaptation layer. Storage is NVMe with Apple hacks and a horrible (definitely not upstreamable) hack Corellium wrote to fake a PCIe bus because the Linux NVMe driver assumes PCIe. Please don't assume they are cranking out bespoke drivers every other day; most of their work is simple drivers and patches to existing ones. There is certainly work involved in figuring out all these Apple oddities, but these aren't new drivers. I fully intend to support the SEP in our kernel once we get that far, with Touch ID for Linux log-in/unlock and also things like storing and using SSH keys within the SEP (think built-in YubiKey). Lots of reversing to be done, but all of this is in scope for our project. Drop by our IRC if you'd like to help out :)
    - zamalek 6y ago
      > but these aren't new drivers. The GPU is probably going to be the monster here, unless you have found that it bears similarly to something else? And Bluetooth. Bluetooth is always a joke.
      - marcan_42 6y ago
        Indeed, the GPU is likely going to be more work than everything else combined. We already have Alyssa Rosenzweig from panfrost working on that, and some other mesa folks. I'll be doing kernel work; I have some experience with Radeon GPU kernel-side drivers to lean on. Alyssa already got her first triangle rendered the other day (from macOS, but without using any macOS Metal frameworks): https://rosenzweig.io/blog/asahi-gpu-part-2.html https://rosenzweig.io/blog/asahi-gpu-part-2.html Kernel work is blocked on the lower levels of the kernel being solid first, but I'll be jumping on that as soon as I can. Bluetooth is just Broadcom again. I think it's the usual UART HCI stuff? I saw a Corellium patch fly by to their UART driver related to that I think, adding hardware flow control support? That driver is a waste of time; I don't know why but Corellium are writing bespoke drivers for some (simple) hardware that already has near-compatible Linux drivers (PASemi I2C is another one). I already added M1 support to the Samsung UART driver in Linux in ~200 lines of patch, and that has more features that Corellium's bespoke >600 line driver. It seems in general they're happy to waste time on code and approaches that will never make it to upstream Linux without a complete rewrite/rethink... which speaks about their approach to this.
        my123 6y ago
        Ok, on the I2C driver because you are saying that: A separate I2C driver was done because the PA Semi one is polled, not interrupt-driven. Polling to wait on a slow bus such as I2C is brutal. And we don't know if the original PA Semi hardware even supports being interrupt-driven (in the same way?). As such the drivers don't even have much in common here.
        marcan_42 6y ago
        This is exactly why you talk to the author of the existing driver, and/or the maintainer if someone else, to figure out what to do and how to avoid code duplication. That's what they aren't doing. Talking to anyone.
  - ogre_codes 6y ago
    Sounds like support is further along than I thought! I'm pretty sure the graphics support is frame buffer only at this point though.
marcan_42 6y ago
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.

ogre_codes 6y ago

They have linux booting on bare metal. Still to be done: - GPU drivers - Wifi/ network drivers - Power management - Getting the GUI online - Audio - Bluetooth - Webcam Extra credit: - Fingerprint scanner (This may never be possible due to Secure Enclave) - Neural Engine support - ??? other M1 extensions

bad_hat_henry 6y ago
It says WiFi/Ethernet is done. It also looks like Power management is done? Getting GUI online? The pictures show a full desktop working.
- marcan_42 6y ago
  They have a desktop running on simplefb. That is not a usable desktop (no matter what they say), with zero acceleration and all completely software rendered. There is literally no graphics or display driver. The bootloader gives you a chunk of RAM that is the screen and you write stuff to it. No multidisplay, no resolution switching, no hotplugging, no acceleration. It's like running x86 linux on efifb with no radeon/intel/nvidia drivers at all. Think vesafb for those old enough to remember those days, but even dumber - at least on that one you could pick a resolution. Our kernel has simplefb support too, literally all you need to do is write 5 lines of devicetree properties to get that to work - zero patches needed to the upstream simplefb driver. Here is the code in our bootloader that takes the Apple framebuffer information and stuffs it in the DT for Linux to use it: https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59 https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59 That's literally all you need to get "graphics". I was actually planning on doing exactly the demo that they did since December, with a simplefb "full Ubuntu desktop" and everything else running off of USB, for the clickbait, because it's flashy even though it's a minimal amount of work, but with a clear disclaimer that it's a tech demo and there is a lot of work left to do. It certainly brings in the news. However, it is not a "fully usable Linux desktop". FWIW: WiFi is Broadcom FullMAC (existing Linux driver) with some patches. Ethernet is a Broadcom chip over PCIe (once you have PCIe up, the driver is there). USB is DWC3 (existing Linux driver) with just an Apple PHY adaptation layer. Storage is NVMe with Apple hacks and a horrible (definitely not upstreamable) hack Corellium wrote to fake a PCIe bus because the Linux NVMe driver assumes PCIe. Please don't assume they are cranking out bespoke drivers every other day; most of their work is simple drivers and patches to existing ones. There is certainly work involved in figuring out all these Apple oddities, but these aren't new drivers. I fully intend to support the SEP in our kernel once we get that far, with Touch ID for Linux log-in/unlock and also things like storing and using SSH keys within the SEP (think built-in YubiKey). Lots of reversing to be done, but all of this is in scope for our project. Drop by our IRC if you'd like to help out :)
  - zamalek 6y ago
    > but these aren't new drivers. The GPU is probably going to be the monster here, unless you have found that it bears similarly to something else? And Bluetooth. Bluetooth is always a joke.
    - marcan_42 6y ago
      Indeed, the GPU is likely going to be more work than everything else combined. We already have Alyssa Rosenzweig from panfrost working on that, and some other mesa folks. I'll be doing kernel work; I have some experience with Radeon GPU kernel-side drivers to lean on. Alyssa already got her first triangle rendered the other day (from macOS, but without using any macOS Metal frameworks): https://rosenzweig.io/blog/asahi-gpu-part-2.html https://rosenzweig.io/blog/asahi-gpu-part-2.html Kernel work is blocked on the lower levels of the kernel being solid first, but I'll be jumping on that as soon as I can. Bluetooth is just Broadcom again. I think it's the usual UART HCI stuff? I saw a Corellium patch fly by to their UART driver related to that I think, adding hardware flow control support? That driver is a waste of time; I don't know why but Corellium are writing bespoke drivers for some (simple) hardware that already has near-compatible Linux drivers (PASemi I2C is another one). I already added M1 support to the Samsung UART driver in Linux in ~200 lines of patch, and that has more features that Corellium's bespoke >600 line driver. It seems in general they're happy to waste time on code and approaches that will never make it to upstream Linux without a complete rewrite/rethink... which speaks about their approach to this.
      - my123 6y ago
        Ok, on the I2C driver because you are saying that: A separate I2C driver was done because the PA Semi one is polled, not interrupt-driven. Polling to wait on a slow bus such as I2C is brutal. And we don't know if the original PA Semi hardware even supports being interrupt-driven (in the same way?). As such the drivers don't even have much in common here.
        marcan_42 6y ago
        This is exactly why you talk to the author of the existing driver, and/or the maintainer if someone else, to figure out what to do and how to avoid code duplication. That's what they aren't doing. Talking to anyone.
- ogre_codes 6y ago
  Sounds like support is further along than I thought! I'm pretty sure the graphics support is frame buffer only at this point though.

marcan_42 6y ago

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.