Asahi Linux 7.1 Mitigates macOS 27 Boot and SMC Regressions, Advances M3 Platform Support
The Asahi Linux 7.1 progress report details critical hotfixes for APFS boot picker and SMC battery driver regressions introduced in recent macOS betas. It also highlights major driver enablement on M3 SoCs and a novel custom-firmware approach for the Apple Video Decoder.
macOS 27 Boot Picker Regression Fixed via APFS Flag
To bootstrap Linux on Apple Silicon, the Asahi Installer configures a minimal 2.5 GB APFS container running a skeleton macOS installation. This architecture convinces Apple's boot tooling to execute the m1n1 stage-1 bootloader. While this arrangement operated cleanly from macOS 12 to macOS 26, the macOS 27 Golden Gate developer beta broke compatibility, causing Asahi targets to disappear from both the Startup Disk utility and the system boot picker.
The regression stems from a bootable volume metadata flag set by the macOS Installer. Prior to macOS 27, the system boot tools ignored this flag, but the new beta actively enforces it. Setting this flag on the Asahi APFS container fully restores volume visibility in the boot picker. The project has updated its installer with a corrective option and is currently testing a native Linux tool developed by chaos_princess to patch existing volumes.
SMC Firmware ABI Breakage Triggers Emergency Shutdowns
Upgrading to macOS 27 also applies permanent global firmware updates to system coprocessors, including the System Management Controller (SMC). The Linux power supply driver interacts with the SMC to manage battery states, health telemetry, and charge thresholds.
In macOS 27, Apple modified the SMC firmware ABI, altering a battery management interface return type from a 32-bit integer to a single byte. Unprepared for this change, the Linux driver interpreted the unexpected response as a critical battery failure and initiated an emergency system shutdown. This has been addressed in the downstream kernel starting with version 7.0.12, which implements compatibility for both ABI specifications. Because these global firmware updates cannot be downgraded without a full DFU restore, the team strongly advises against installing developer betas on production hardware.
M3 Platform Integration and Driver Parity
Architectural continuity in Apple Silicon has accelerated the enablement of M3-series SoCs. Because Apple's I2S controller, Numerically Controlled Oscillator (NCO), and speaker/headset amplifier ICs have remained unchanged since the M1, enabling full audio support on M3 hardware required only minor Devicetree modifications and configuration updates for asahi-audio and speakersafetyd.
Similarly, Apple's CPU frequency switching architecture has remained consistent since the base M2. Consequently, the existing cpufreq driver operates on M3, M3 Pro, M3 Max, and M3 Ultra SoCs using updated Devicetree files, enabling proper big.LITTLE scheduling, dynamic clock scaling, and SMC hardware sensor access. Additional core drivers, including PCIe, Wi-Fi, Bluetooth, NVMe, and input devices, are now functional on M3 platforms, largely developed by Yureka.
Developing Custom Firmware for the Apple Video Decoder
The Apple Video Decoder (AVD) features a unique design compared to other SoC blocks. Rather than utilizing RTKit or EPIC RTOS abstractions, AVD relies on a dedicated ARM Cortex-M3 coprocessor driving fixed-function video decoding pipelines for AVC, HEVC, VP9, and AV1. Historically, XNU extracted the AVD firmware and configurations directly from the macOS AVD kernel extension (kext). However, because each SoC variant utilizes a slightly different AVD revision, tracking these dynamic firmware offsets inside the installer is highly fragile.
The Asahi team is circumventing this proprietary dependency by writing custom firmware for the Cortex-M3. Since the AVD hardware does not cryptographically verify the firmware at its reset vector, the coprocessor will execute arbitrary code once signaled. The custom firmware's primary role is to configure interrupt handlers, allowing a native Linux driver to program the underlying hardware directly. Developers Jamie, R, and Eileen laid the groundwork for this by emulating the original AVD firmware inside QEMU to trace bus and register transactions.