You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 0de2f14
Browse filesBrowse the repository at this point in the historyBrowse files
</li></ul></div><p>After almost three years of 6.x series kernels, Linux 7.0 is finally here.
47
49
That means it’s also time for another Asahi progress report!</p><h2id=automate-everything>Automate Everything</h2><p>Users of alternate distros and keen-eyed individuals may have noticed some
48
50
changes to the Asahi Installer. After almost two years, we finally got around
49
51
to pushing an updated version of the installer to the CDN! Two years is a long
</li><liclass=nav-spacer></li></ul></div><p>Linux 7.1 is now here, and of course with it comes another progress report. We’ve got M3
47
+
progress, Apple bugs, and more!</p><h2id=welcome-back-master-boot-record>Welcome back Master Boot Record</h2><p>When you long-press the power button on your Mac to bring up the boot picker (or use the
48
+
Startup Disk application), what you see listed as Asahi is not actually the partition
49
+
with the operating system on it. Apple’s boot tooling will only work with what it considers
50
+
to be a “valid” macOS installation inside an APFS container. So that we can use Apple’s
51
+
bootloader and avoid needing users to run commands from Recovery every time they want to
52
+
use Asahi, the Asahi Installer creates a small APFS container (2.5 GB) with just enough
53
+
of macOS on it to convince Apple’s tools that it is a bootable installation of macOS with
54
+
m1n1 as its kernel. This arrangement worked completely unchanged from macOS 12 to macOS 26,
55
+
and Apple even fixed a couple of bugs in their tools that are only encountered when attempting
56
+
to boot raw binaries that are not a real XNU kernel.</p><p>Shortly after the release of the macOS 27 Golden Gate developer beta however, we began
57
+
receiving reports that people were no longer able to boot into Linux on their
58
+
machines — the option had simply disappeared from both Startup Disk and the boot picker!
59
+
Obviously this is quite concerning, and so we made investigating this a priority.</p><p>Inspecting the disk using diskutil revealed that all Asahi-related partitions were still
60
+
present on the disk after upgrading to macOS 27. No data loss was occurring, which is a
61
+
positive sign. Additionally, Asahi was still bootable on the same machine when using the
62
+
boot tooling from a second install of macOS 26.</p><p>chaos_princess began inspecting Apple’s own macOS Installer and old streams from way back
63
+
when we were first poking at Apple’s boot tools. The macOS Installer sets some APFS
64
+
metadata before rebooting the machine, which further investigation revealed to be a flag
65
+
that marks the volume as bootable. Until macOS 27, the boot tooling simply ignored this
66
+
flag entirely. After setting the flag manually on an Asahi APFS container, it becomes
67
+
available in the macOS 27 boot picker with no further changes.</p><p>Going forward, all new Asahi installs will have this flag set automatically by the
68
+
Asahi Installer. We’ve also added an installer mode that will fix existing installations.
69
+
If you’ve installed the macOS 27 developer beta and cannot access your Asahi install, please
70
+
run the installer again and use the “Fix macOS 27 boot picker compatibility” option.</p><p>chaos_princess has also developed a program that can be run from Linux to fix the issue.
71
+
While we would eventually like to deploy this fix automatically, we need more testing
72
+
data to confirm that it is reliable and will not destroy anyones’ filesystems. That’s where
73
+
you come in. If you are willing to help us test this, clone <ahref=https://github.com/AsahiLinux/asahi-fix27>this repo</a>,
74
+
then build and run it from Linux <em>before</em> upgrading to macOS 27. If your Asahi volume
75
+
is still selectable as a boot target from macOS, it has worked. Do be sure to let us
76
+
know how it went by popping in to one of our <ahref=https://asahilinux.org/community>channels</a>
77
+
on OFTC or Matrix, especially if you run in to any issues.</p><h2id=three-bytes-forcing-shutdowns>Three bytes forcing shutdowns</h2><p>macOS 27 also brings firmware updates for all peripherals with global firmware, including
78
+
the SMC. One of the SMC’s myriad functions is battery management. Our Linux power supply
79
+
driver talks to the SMC to get information such as charge state, voltage, time until empty and
80
+
battery health. The driver also uses the SMC’s firmware interface to configure charge
81
+
start and stop thresholds to prolong the life of the battery. macOS 27’s SMC firmware
82
+
changed one of the battery management interfaces from returning a 32-bit integer to
83
+
returning a single byte. This change confuses our driver, which under certain conditions
84
+
considers the battery as having failed and initiates an emergency shutdown to protect
85
+
the system. We have already patched this in the downstream kernel; starting with version
86
+
7.0.12, the power supply driver can deal with both firmware ABIs.</p><h2id=on-installing-betas>On installing betas</h2><p>Bugs like these are an important reminder that developer betas are just that, developer
87
+
betas. It is ill-advised to install them on production machines. The two issues we
88
+
have had so far have luckily minor, but that doesn’t mean that all future issues will
89
+
be too. Global firmware updates are effectively permanent too, and can only be rolled
90
+
back with a DFU restore of the machine. Please refrain from installing developer betas
91
+
going forward. We have sacrificial machines we use to test these things on your behalf,
92
+
there is no need to risk your own expensive hardware and important data.</p><h2id=the-more-things-change>The more things change…</h2><p>Designing and validating computer platforms and the ICs that go into them is extremely
93
+
expensive and time consuming, so it makes very little sense to make changes to existing
94
+
designs when they are not necessary. Early on in the project, we made a bet that Apple
95
+
would agree and refrain from making constant breaking changes to either. Discounting a
96
+
few of the larger SoC blocks like the GPU that are almost required to change every
97
+
generation, this bet has largely paid off.</p><p>Audio on an Apple Silicon laptop involves a few different ICs and SoC blocks. The
98
+
defacto industry standard for audio ICs is I<sup>2</sup>S, an I<sup>2</sup>C-based bus
99
+
optimised for audio data. Apple’s I<sup>2</sup>S controller has remained unchanged
100
+
since M1. All of these audio ICs also need a stable clock source, which must be
101
+
configurable to accommodate the wide variety of audio data rates. Apple’s Numerically
102
+
Controlled Oscillator (NCO) has also remained unchanged since M1. Apple have also used
103
+
the exact same speaker and headset amplifier chips in almost all Apple Silicon machines.
104
+
So, when chaos_princess started adding speaker and headphone jack support to M3 machines,
105
+
little more was required than some trivial Devicetree additions and config files for
106
+
asahi-audio and speakersafetyd. As such, M3 machines now sport high-quality audio output
107
+
on Asahi Linux!</p><p>M3 machines have also grown support for both CPU frequency switching and proper big.LITTLE
108
+
task scheduling. Apple have not changed how CPU frequency switching works since the base
109
+
M2, meaning that all M3 and M3 Pro/Max/Ultra SoCs required nothing more than Devicetree
110
+
changes to work with our existing cpufreq driver. Tasks should now be more intelligently
111
+
placed on either efficiency or performance cores according to their requirements, and the
112
+
CPU cores themselves should clock up and down based on load. This will both save energy
113
+
<em>and</em> improve performance!</p><p>Adding support for the SMC’s hardware sensors was similarly trivial; the SMC’s firmware is
114
+
not materially different across machines, so once again nothing more than a few Devicetree
115
+
changes was required here.</p><p>On top of the above, we also have PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad, and
116
+
other core SoC block drivers working in Linux for M3 series machines. Most of this work
117
+
has come by way of <ahref=https://fedi.yuka.dev/yuka>Yureka</a>, who has been very busy hacking
118
+
on both m1n1 and Linux with her M3 series machines for a while now. We still have a ways
119
+
to go before we can start enabling Asahi Installer support for these machines, but progress
120
+
is rapid so watch this space!</p><h2id=were-writing-firmware-now>We’re writing firmware now?</h2><p>Most of the complicated hardware on this platform uses complicated firmware blobs. Most
121
+
of this is based on RTKit, an RTOS-like firmware framework used by Apple to present a mostly
122
+
standardised interface for the kernel to talk to the various bits of hardware. There are
123
+
exceptions to this, however. Some blocks, like DCP and AOP, use RTKit as the basis for their
124
+
firmware, but layer yet another set of abstractions called EPIC on top of it. Others still,
125
+
like the Broadcom WiFi/Bluetooth chipset, use third-party firmware that Apple has no direct
126
+
control over. Then, there’s the Apple Video Decoder (AVD).</p><p>AVD is special. Its firmware is neither RTKit nor EPIC, it’s a secret third thing. The
127
+
hardware itself is essentially an ARM Cortex-M3 controlling a series of fixed-function hardware
128
+
units for decoding video frames encoded in AVC (H.264), HEVC (H.265), VP9, and AV1 on more recent
129
+
SoCs. The CM3 runs a blob of firmware that exposes an interface for XNU to point it to video
130
+
data, and then programs the actual decoder hardware itself. This would normally be fine, however
131
+
Apple made the interesting choice of bundling both the AVD’s firmware and a pile of configuration
132
+
data <em>inside</em> the AVD kext. Making matters worse, each SoC has a slightly different AVD variant.
133
+
This is logistically challenging, as the Asahi Installer would have to constantly be updated
134
+
with (and keep track of) Apple’s changes to the offsets of the firmware data in the kext.
135
+
We <em>could</em> do this, but what if there’s a better way?</p><p>The firmware loaded by XNU is not verified by the CM3. It will begin executing from
136
+
its reset vector when signalled, no matter what is actually there. What if we
137
+
just… used our own firmware?</p><p>Since the firmware is effectively just there to abstract away the underlying video
138
+
decoder hardware, it doesn’t actually matter what it does, so long as it installs
139
+
interrupt handlers for the various hardware blocks. If we understand what the underlying
140
+
hardware expects, we can just program it all from a Linux driver. To do this, we need
141
+
to understand how the firmware drives each decoder.</p><p>Being standard Cortex-M3 code, it is possible to run the AVD firmware in an emulator.
142
+
A number of solutions exist to do this, including QEMU, which allows you to single-step
143
+
your program and inspect bus and register operations. The groundwork for this was laid
144
+
many years ago by Jamie, R and Eileen, who through a combined effort managed to reverse
145
+
engineer the instructions and data formats required by the AVC and VP9 decoders.</p><p>The XNU kext also applies a unique set of tunables to each AVD revision. We are not
146
+
entirely certain what these do, so applying these essentially needs to be a replay of
147
+
MMIO writes made by XNU. We need to keep track of each AVD revision, each set of tunables,
148
+
and which revision they need to be applied to. This would be impossible to maintain
149
+
satisfactorily in an upstream Linux kernel driver, so this should also probably live
150
+
in firmware.</p><p>While not much work happened on this front for a long time, new contributor <ahref=https://github.com/sofus13>sofus</a>
151
+
recently stepped up to fill the gap. With a blob of custom AVD firmware that simply
152
+
installs interrupt handlers and applies each variant’s set of tunables, he was able to
153
+
write a working V4L2 driver for the AVC hardware! The hardware can decode 10-bit AVC-encoded
154
+
video up to 4K, and works well with software that implements the V4L2 Request API.
155
+
Keeping the firmware basic and stateless, with userspace and the kernel being responsible
156
+
for parsing all video data and programming the decoders themselves, also enables us to
157
+
more easily support other video acceleration APIs like VA-API and Vulkan Video at some
158
+
point in the future.</p><p>There’s still some work to do before we can ship AVD support to users. AVD supports VP9,
159
+
HEVC and even AV1 on some SoCs, but we have not implemented support for any of these yet.
160
+
Some devices also have quirks that must be tested and accounted for in the driver. We
161
+
hope to have something shippable for you all in the not too distant future!</p><h2id=a-large-m1n1-release>A large m1n1 release</h2><p>We have also recently tagged version 1.6.0 of m1n1. This is a consequential
162
+
release for distros, as it is the first version that requires Rust for stage 2
163
+
builds. Previously, m1n1 only made use of Rust when built with chainloading
164
+
support. Stage 1 m1n1 replaces the XNU kernel in Apple’s boot tooling, and is used
165
+
only to mount the EFI System Partition and chainload Stage 2 m1n1 from there. A
166
+
little while ago however, we made the decision to move GPU initialisation into
167
+
m1n1. This removed the need for the kernel driver to deal with the floating point
168
+
numbers found in Apple’s hardware initialisation data, and also greatly simplified
169
+
the Devicetree bindings. The version of the GPU driver we eventually submit to
170
+
the Linux Kernel Mailing List will therefore rely on m1n1 to do this initialisation
171
+
for it. We also ported the Apple Device Tree parsing code to Rust, which is
172
+
consumed by just about every other part of m1n1.</p><p>Given that m1n1 is effectively firmware, it uses <code>no_std</code> Rust and targets <code>aarch64-none-softfloat</code>.
173
+
To avoid pulling in superfluous dependencies, you can pass <code>BUILDSTD=1</code> to <code>make</code> to build <code>core</code>
174
+
and <code>alloc</code> without requiring a full <code>softfloat</code> toolchain to be installed.</p><p>Version 1.6.0 also brings a whole host of improvements to M3 series support, including
175
+
support for the SPMI controller and PCIe initialisation. We also now support tunnelling
176
+
the SoC’s hardware UART directly over DebugUSB with <ahref=https://github.com/AsahiLinux/kisd>kisd</a>,
177
+
which can be used to achieve much the same functionality as the Central Scrutiniser.
178
+
Much of this work is also courtesy of Yureka.</p><p>We are also laying the groundwork for M4 and A18 Pro (MacBook Neo) support, with better
179
+
handling of Apple’s non-macOS boot mode and support for new power domain metadata found
180
+
in the Apple Device Tree.</p><h2id=thanks-again>Thanks again!</h2><p>As always, we would like to thank our generous supporters on <ahref=https://github.com/sponsor/AsahiLinux>GitHub Sponsors</a>
181
+
and <ahref=https://opencollective.com/asahilinux>Open Collective</a>, without whom we would not be
182
+
able to continue working on unfinished M1 and M2 features or work on M3, M4 and A18 Pro
183
+
support while supporting our enthusiastic new contributors!</p><divclass=post-bottom>James Calligeros · <spanclass=publishdate>2026-06-30</span></div></div></div></section><footerid=footer>
184
+
<divclass=footer-menu>
185
+
<divclass=footer-logo>
186
+
<ahref=/>
187
+
<imgsrc=/img/AsahiLinux_logomark.svgclass=logoalt="Asahi Linux logo">
188
+
</a>
189
+
<spanclass=license>Licensed under CC BY-SA 4.0</span>
190
+
<spanclass=disclaimer>Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. All other product names, logos, and brands are property of their respective owners.
191
+
<spanclass=kawaii-disclaimer>Kawaii Asahi Linux logo by <ahref=https://github.com/SAWARATSUKI/Logos>SAWARATSUKI</a> (see link for license).</span>
<li><ahref=/about>About</a></li><li><ahref=/code-of-conduct>Code of Conduct</a></li><li><ahref=/copyright>Copyright policy</a></li></ul></div></div></footer></body></html>
0 commit comments