A few months ago we shared the news of the initiative for Linux support for the Apple M1 chip, promoted by the Asahi Linux and Corellium projects which during all this time have been working and now you have reached the point where it is possible to run the GNOME desktop in a Linux environment running on a system with an Apple M1 chip.
Visualization is organized by a framebuffer and OpenGL support provided by rasterizer software LLVMPipe. The next step is to enable the display coprocessor for a up to 4K output, which has already been reverse engineered.
The Asahi project has achieved initial support for SoC M1 non-GPU components in the core Linux kernel. In the demonstrated Linux environment, in addition to the capabilities of the standard kernel, several additional patches related to PCIe, the pinctrl driver for the internal bus, and the display driver are used. These additions allowed for on-screen display and operation of USB and Ethernet. Graphics acceleration is not yet used.
LLVMPipe, my shoddy display controller, and hours of @ svenpeter42‘s patience presents….
GNOME Shell on the Apple M1, bare metal.
No, it’s not GPU accelerated. Yes, I’m sending this tweet from it. pic.twitter.com/P4YuPEnbvp
– Alyssa Rosenzweig (@alyssarzg) August 22, 2021
The M1 represents a huge reverse engineering challenge, with a lot of custom hardware and completely undocumented. One approach to reverse engineering hardware is blind probing, as we used to reverse engineer Apple’s interrupt driver, but this doesn’t really work for more complicated hardware.
To properly understand how hardware is handled, we have to look at the only piece of documentation out there: macOS itself. It would be technically possible to disassemble and reverse engineer the macOS drivers themselves, but this raises legal challenges that could jeopardize the copyright status of our project, as well as being inefficient, as much of the code is specific to the macOS driver framework. and it doesn’t give us any useful information about the hardware.
Curiously, to reverse engineer the M1 SoC, the Asahi project, instead of trying to unmount the drivers from macOS, implemented a hypervisor that runs between macOS and the M1 chip and intercepts and transparently records all operations with the chip. Among the SoC M1 features that make it difficult to implement chip support in third-party operating systems is the addition of a coprocessor to the display controller (DCP).
On the specified coprocessor side, half the functionality of the macOS display driver is removed, which calls the pre-built coprocessor functions through a special RPC interface.
Instead, a much more secure approach that has been used by projects like Nouveau in the past is to record a log of hardware accesses made by official controllers on a real system, without having to look at the code. Nouveau accomplished this by using a Linux driver to intercept accesses from Nvidia’s official Linux driver. Of course, Apple’s M1 drivers are for macOS, not Linux. While we could implement the same approach with a custom patch for the open source kernel of the macOS kernel, we decided to go one level deeper and build a hypervisor that can run the entirety of macOS, unmodified, in a virtual machine that features it. transparently. the real M1 hardware.
Enthusiasts have already discovered enough calls to this RPC interface to use the coprocessor for display, as well as to control the hardware cursor and perform composition and scaling operations.
The problem is that the RPC interface depends on the firmware and changes in each version of macOS, which is why Asahi Linux plans to support only certain versions of firmware.
First, support will be provided for firmware shipped with macOS 12 “Monterey”. It is not possible to download the required firmware option, since the firmware is installed by iBoot in the stage prior to the transfer of control to the operating system and verified by digital signature.