Asahi Linux Progress Linux 7.0

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 Everything

Users 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 repo
• Downloading a macOS Python build
• Building m1n1 from a blessed commit
• Bundling Python, m1n1 and the installer
• Uploading the installer bundle to the CDN
• Updating the CDN’s version flag file

This 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 possible
• The light sensor should be able to be calibrated for maximum accuracy
• There are multiple models of light sensor in use, and the OS should not have to care toomuch about that - The 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 kernel
• Ensure your distro ships iio-sensor-proxy

as a dependency of your DE (Fedora Asahi Remix does this) - Shut down your Mac Holdthe power button until “Loading startup options” appears on the display for MacBooks,orfor 5-7 seconds on the desktop machines- Select Options from the Apple boot menu

• Log in with your macOS credentials, then do Command + Shift + T to open a terminal

• Invoke the Asahi Installer by running curl https://alx.sh | sh

• Choose the “Rebuild vendor firmware package” option when prompted

• Quit the installer and reboot once this is done

Solving the energy crisis

Idle 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