Progress Report: Linux 7.0 - Asahi Linux

After almost three years of 6.x series kernels, Linux 7.0 is finally here. That means it’s also time for another Asahi progress report!Automate EverythingUsers of alternate distros and keen-eyed individuals may have noticed some changes to the Asahi Installer. After almost two years, we finally got around to pushing an updated version of the installer to the CDN! Two years is a long time to go between updates, so what took so long?Our upstream installer package is a little bit of a Rube-Goldberg machine. The bulk of the installer is written in Python, with some small Bash scripts to bootstrap it. When you run curl | sh, you’re actually downloading the boostrap script, which then fetches the actual installer bundle from our CDN. This bundle consists of a Python interpreter and very stripped down standard library, a built m1n1 stage 1 binary, and the installer itself.Until recently, cutting an installer release meant: Tagging the installer repoDownloading a macOS Python buildBuilding m1n1 from a blessed commitBundling Python, m1n1 and the installerUploading the installer bundle to the CDNUpdating the CDN’s version flag fileThis process was time-consuming and required administrative access to the CDN. As a result, we neglected to push installer updated for quite some time; the previous installer tag was from June 2024! As upstreaming work has progressed and Devicetree bindings churned, this became rather problematic for our friends maintaining distros.The Asahi Installer offers a UEFI-only installation option. This option shrinks macOS and only installs what is necessary to boot a UEFI executable, meaning m1n1 stage 1, the Devicetrees, and U-Boot. This allows users to boot from live media with Asahi support, such as specialised Gentoo Asahi LiveCD images.Since the Devicetrees on a fresh UEFI-only install come from the installer bundle itself, a kernel will only successfully boot when the installer-bundled Devicetrees match what that kernel expects to see. The two have gotten rather out of sync as time has gone on due to Devicetree bindings changing as a result of the upstreaming process.

This situation finally came to a head with kernel 6.18, which required numerous changes to both m1n1 and the Devicetree bindings for the Apple USB subsystem. This made booting kernel 6.18 and above from live media impossible. Oops.Rather than go through the trouble of manually pushing out another update, we took the opportunity to build some automation and solve this problem permanently.We moved the manifest of installable images into the asahi-installer-data repo, allowing us to update it independently of the installer codebase. On top of this, we also now deploy the installer using GitHub workflows. Going forward, every push to the main branch of asahi-installer will automatically build the installer and upload it to https://alx.sh/dev. Every tag pushed to GitHub will do the same for https://alx.sh.The latest version, 0.8.0, bumps the bundled m1n1 stage 1 binary to version 1.5.2, introduces installer support for the Mac Pro, and adds a firmware update mode which ties in nicely with…How do you overengineer a light sensor?Basically everything with a screen now comes with some sort of light sensor. This is usually to enable automatic brightness adjustment based on ambient conditions. It’s a very convenient feature in devices like smartphones, where a user may walk outside and find their display too dim to see. The cheapest versions of this use a simple photoresistor. This is fine if the goal is just to change brightness, but brightness is not the only thing affected by ambient lighting conditions. What about colour rendering?Apple’s devices have had the True Tone display feature for quite some time. This works by measuring both the brightness and the colour characteristics of the environment’s ambient lighting. This data is then used to apply brightness and colour transformations to the display to ensure that it is always displaying content as accurately as possible. This is most noticeable in environments with lighting fixtures that have a low Colour Rendering Index, such as fluorescent tubes or cheap cool white LEDs. The devices that enable this, ambient light sensors, are usually little ICs that connect to the system over I2C or other industry-standard bus. This is fine for basic applications, but this is Apple.

There are some other considerations to be had: The light sensor is doing stuff whenever the screen is on, so processing its output should be as efficient as possibleThe light sensor should be able to be calibrated for maximum accuracyThere are multiple models of light sensor in use, and the OS should not have to care too much about thatThe light sensor has to have a three letter acronym like every other piece of hardware on this platform (ALS)Naturally, this sounds like a job for the Always-On Processor1 (AOP)!We’ve had a working AOP+ALS driver set for a while thanks to chaos_princess, however the raw data AOP reports back from ALS is rather inaccurate without calibration. That calibration is a binary blob that must be uploaded to the AOP at runtime. It is essentially firmware. Since we cannot redistribute Apple’s binaries, it must be retrieved from macOS at install time and then stored somewhere the driver knows to look for it.To achieve this, the Asahi Installer gathers up all the firmware it knows we will need in Linux and stores it on the EFI System Partition it creates. A Dracut module then mounts this to a subdirectory of /lib/firmware/, where drivers can find it. However, issues arise when we need to retrieve more firmware from macOS after Asahi Linux has already been installed. To avoid a repeat of the webcam situation, where users were required to manually do surgery on their EFI System Partition, chaos_princess added the ability for the Asahi Installer to automatically update the firmware package. Starting with ALS, any required firmware updates will be a simple matter of booting into macOS or macOS Recovery, re-running the Asahi Installer, and following the prompts.To enable ALS support (and to do firmware upgrades in the future), follow these steps: Ensure you are running version 6.19 or above of the Asahi kernelEnsure your distro ships iio-sensor-proxy as a dependency of your DE (Fedora Asahi Remix does this)Shut down your MacHold the power button until “Loading startup options” appears on the display for MacBooks, or for 5-7 seconds on the desktop machinesSelect

Options from the Apple boot menuLog in with your macOS credentials, then do Command + Shift + T to open a terminalInvoke the Asahi Installer by running curl https://alx.sh | shChoose the “Rebuild vendor firmware package” option when promptedQuit the installer and reboot once this is doneSolving the energy crisisIdle energy consumption has been an ongoing issue, especially on devices with Pro/Max/Ultra SoCs. The power management architecture on this platform is incredibly complex, and there are a lot of moving parts involved in making it all work. There is Power Manager (PMGR), which is responsible for the SoC’s power domains, but there is also the Power Management Processor (PMP), which does… stuff?The actual low-level details of how power is managed across the SoC are quite opaque. PMGR is responsible for powering SoC regions up or down and is runtime-configurable. This is necessary to power up parts of the SoC on boot, and to power them up or down on suspend and resume. PMP, however, has a more interesting job. Many SoC blocks communicate their power states to PMP directly in a region of shared memory. PMP also takes reports from the application cores when PMGR power domains are powered up or down. PMP will not read these reports if it is not booted, and certain power management functionality will not work. We are not sure exactly what it does with this information, but it likely involves controlling Apple Fabric power and clocking, among other things.To support PMP, chaos_princess wrote drivers enabling it to accept reports from the SoC blocks and PMGR. This alone is enough to save around half a Watt on a 14" M1 Pro MacBook Pro when idle. That is around a 20% decrease in idle power consumption! There is obviously still work to be done to reach macOS levels of idle and suspend time, but this is a significant step forward.Machines with the base M1 SoC have an older variant of PMP, which is not compatible with the variant found on the M1 Pro and later SoCs.

dd-dreams is working on enabling PMP support on these machines, so stay tuned!PMP support has not yet been validated on every machine we support, and we do not plan to ship it enabled by default until it is merged upstream. Users comfortable with making Devicetree changes may define APPLE_USE_PMP in their device’s Devicetree (e.g. t8112-j415.dts) to enable it.Bluetooth fixes!Bluetooth and WiFi have a long history of contention and interference. Both operate around the same 2.4 GHz frequencies and are typically both present in a given device. If not dealt with, this can cause packet loss and dropouts. There are a number of strategies to deal with this. In modern systems, WiFi and Bluetooth are typically integrated into the same controller. This allows the controller to monitor active 2.4 GHz WiFi and Bluetooth connections at the same time. By default, each connection is allocated a “fair” share of the available airtime, however this can cause issues when latency is important, or when some connections require minimal interruption. A connection that is actively streaming audio must be given priority over a keyboard, or a scan for 2.4 GHz WiFi broadcasts.Unfortunately nothing is ever simple with Broadcom, and coexistence configuration is done using vendor-specific extensions to the Bluetooth Host Controller Interface (HCI). These were previously not supported in the upstream Linux kernel, causing our Bluetooth controllers to drop audio packets when, for example, KDE Connect would trigger a Bluetooth scan. chaos_princess recently added support for these commands to the kernel Bluetooth stack, and since BlueZ, the userspace Bluetooth daemon, marks all audio streams as high priority, these commands can be triggered whenever a connection is streaming audio. Bluetooth audio dropouts are now a thing of the past!Hiding in plain sightOur struggles with the display controller (DCP) have been well documented at this point. The firmware interface is enormous, unstable between versions, and frustratingly limited in weird ways that make no sense. Once we had enough of it working to get basic display support, attention turned to other pieces of hardware and no one really had the time to invest in further DCP work.