7 ms·

My guess is that the Mx GPU is probably the toughest target for reverse engineering -- as it is very unique to Apple. It will probably take many years to revers

My guess is that the Mx GPU is probably the toughest target for reverse engineering -- as it is very unique to Apple. It will probably take many years to reverse engineer. I believe the Asahi Linux X11/Wayland graphics interface still works on the CPU today (Mesa) and _not_ the GPU. I don't think they have the GPU working except for small proof of concept things. 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.

unmole 4y ago
Drivers for things like WiFi are generally platform independent.
- sidkshatriya 4y ago
  > Drivers for things like WiFi are generally platform independent. 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.
gjsman-1000 4y ago
This is not correct. Right now, the GPU Driver for Asahi Linux is not written in Rust/C++ yet (because that's a lot of work). Instead, the prototype driver is written in Python, and when it is done, then it will be rewritten in Rust/C++ once it works correctly. It runs on a host system, receives OpenGL calls (like the demo application shown at the bottom), and then creates a pile of GPU instructions that are then sent over USB to run on the real GPU in the m1n1 preboot environment. So, in practice, the GPU is being reverse-engineered, is doing the rendering, it's just that the OpenGL -> GPU layer is being handled outside Linux in a simpler language for development speed. This prototype GPU driver has 94% openGLES test suite compliance at this point. > 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.
- cultofmetatron 4y ago
  I'm a bit mind blown that you can write a driver in python. I thought it would be too high level to do the job at all, nevrmind slowly
  - aseipp 4y ago
    "Drivers" for things in the kernel space in this case, are mostly just a glorified shim that allow you to submit command buffers to a device through memory-mapped I/O. 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.)
  - pxc 4y ago
    Python is a popular choice for FUSE filesystem drivers, I think. It's also how this perfectly usable driver for the DualShock 4 is written: https://github.com/chrippa/ds4drv https://github.com/chrippa/ds4drv
- IntelMiner 4y ago
  Why Rust/C++? 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"
  - remexre 4y ago
    This is the userspace part of the driver, not the kernelspace part; the existing open-source graphics drivers already are (for the most part) in C++, because extern "C" is less of a pain than writing a compiler in pure C
  - dezgeg 4y ago
rowanG077 4y ago
There are parts where basically only the interface to the hardware is different (example as in the article: bluetooth). But there are also many, many piece of hardware that are bespoke. GPU, DCP, Interrupt controller and more. It's not really a serious hindrance with m1n1. As the communication can be snooped basically like using wireshark but on the hardware level. Don't get me wrong that doesn't make things easy. But it's definitely not an impossible task.
est31 4y ago
> 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. 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/13520bd2beef49019b1b7436e3b95ddd https://gist.github.com/z4yx/13520bd2beef49019b1b7436e3b95dd... [1]: https://wiki.debian.org/brcmfmac https://wiki.debian.org/brcmfmac [2]: https://lore.kernel.org/lkml/4928ea79-2794-05fb-d1a8-942b589a1c3a@marcan.st/T/ https://lore.kernel.org/lkml/4928ea79-2794-05fb-d1a8-942b589...
- garaetjjte 4y ago
  > [2] You linked to the old Corellium patch, here's proper one: https://lore.kernel.org/linux-acpi/20211226153624.162281-1-marcan@marcan.st/ https://lore.kernel.org/linux-acpi/20211226153624.162281-1-m...
  - est31 4y ago
    My bad, thanks for pointing it out! It seems that these patches have also been accepted since and are part of 5.18 onward.

unmole 4y ago

Drivers for things like WiFi are generally platform independent.

sidkshatriya 4y ago
> Drivers for things like WiFi are generally platform independent. 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.

gjsman-1000 4y ago

This is not correct. Right now, the GPU Driver for Asahi Linux is not written in Rust/C++ yet (because that's a lot of work). Instead, the prototype driver is written in Python, and when it is done, then it will be rewritten in Rust/C++ once it works correctly. It runs on a host system, receives OpenGL calls (like the demo application shown at the bottom), and then creates a pile of GPU instructions that are then sent over USB to run on the real GPU in the m1n1 preboot environment. So, in practice, the GPU is being reverse-engineered, is doing the rendering, it's just that the OpenGL -> GPU layer is being handled outside Linux in a simpler language for development speed. This prototype GPU driver has 94% openGLES test suite compliance at this point. > 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.

cultofmetatron 4y ago
I'm a bit mind blown that you can write a driver in python. I thought it would be too high level to do the job at all, nevrmind slowly
- aseipp 4y ago
  "Drivers" for things in the kernel space in this case, are mostly just a glorified shim that allow you to submit command buffers to a device through memory-mapped I/O. 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.)
- pxc 4y ago
  Python is a popular choice for FUSE filesystem drivers, I think. It's also how this perfectly usable driver for the DualShock 4 is written: https://github.com/chrippa/ds4drv https://github.com/chrippa/ds4drv
IntelMiner 4y ago
Why Rust/C++? 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"
- remexre 4y ago
  This is the userspace part of the driver, not the kernelspace part; the existing open-source graphics drivers already are (for the most part) in C++, because extern "C" is less of a pain than writing a compiler in pure C
- dezgeg 4y ago

rowanG077 4y ago

There are parts where basically only the interface to the hardware is different (example as in the article: bluetooth). But there are also many, many piece of hardware that are bespoke. GPU, DCP, Interrupt controller and more. It's not really a serious hindrance with m1n1. As the communication can be snooped basically like using wireshark but on the hardware level. Don't get me wrong that doesn't make things easy. But it's definitely not an impossible task.

est31 4y ago

> 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. 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/13520bd2beef49019b1b7436e3b95ddd https://gist.github.com/z4yx/13520bd2beef49019b1b7436e3b95dd... [1]: https://wiki.debian.org/brcmfmac https://wiki.debian.org/brcmfmac [2]: https://lore.kernel.org/lkml/4928ea79-2794-05fb-d1a8-942b589a1c3a@marcan.st/T/ https://lore.kernel.org/lkml/4928ea79-2794-05fb-d1a8-942b589...

garaetjjte 4y ago
> [2] You linked to the old Corellium patch, here's proper one: https://lore.kernel.org/linux-acpi/20211226153624.162281-1-marcan@marcan.st/ https://lore.kernel.org/linux-acpi/20211226153624.162281-1-m...
- est31 4y ago
  My bad, thanks for pointing it out! It seems that these patches have also been accepted since and are part of 5.18 onward.