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
</li><liclass=nav-spacer></li></ul></div><p>Another upstream kernel release means it must be time for a progress report!</p><h2id=the-patches-keep-coming>The patches keep coming</h2><p>As always, upstreaming continues. The highlight of this cycle is finally landing
</li></ul></div><p>Another upstream kernel release means it must be time for a progress report!</p><h2id=the-patches-keep-coming>The patches keep coming</h2><p>As always, upstreaming continues. The highlight of this cycle is finally landing
47
49
the SMC core driver, after discussions on the mailing list going all the way back
48
50
to 2022! Along with the core driver, drivers for the SMC’s GPIO controller and
49
51
reboot controller have also been merged. This allows devices which are already
</li><liclass=nav-spacer></li></ul></div><p>Linux 6.18 has released, and we have a bit to talk about for this holiday season progress report!</p><h2id=more-upstreaming-madness>More upstreaming madness</h2><p>Last time, we announced that the core SMC driver had finally been merged upstream after three long
47
+
years. Following that success, we have started the process of merging the SMC’s subdevice drivers
48
+
which integrate all of the SMC’s functionality into the various kernel subsystems. The hwmon driver
49
+
has already been accepted for 6.19, meaning that the myriad voltage, current, temperature and power
50
+
sensors controlled by the SMC will be readable using the standard hwmon interfaces. The SMC is also
51
+
responsible for reading and setting the RTC, and the driver for this function has also been merged
52
+
for 6.19! The only SMC subdevices left to merge is the driver for the power button and lid switch,
53
+
which is still on the mailing list, and the battery/power supply management driver, which currently
54
+
needs some tweaking to deal with changes in the SMC firmware in macOS 26.</p><p>Also finally making it upstream are the changes required to support USB3 via the USB-C ports. This
55
+
too has been a long process, with our approach needing to change significantly from what we had
56
+
originally developed downstream. The changes made to the Synopsis USB controller and the TI USB-PD
57
+
controller drivers have been merged, with only the driver for Apple Type-C PHY (ATCPHY) requiring
58
+
review. ATCPHY is responsible for configuring the physical USB-C connection, detecting and negotiating the
59
+
required protocols and routing signals to and from the relevant controllers. This is required not
60
+
just for USB3, but also all the other protocols one could reasonably expect a USB-C port to carry…</p><h2id=its-always-a-single-line>It’s always a single line…</h2><p>While most of us have been enjoying full microphone support, owners of M2 Pro/Max MacBooks have been
61
+
missing out. Given that the M2 Pro/Max is almost identical to the M1 Pro/Max, it was assumed that this
62
+
would extend to the “Always-On”<supid=fnref:1><ahref=#fn:1class=footnote-refrole=doc-noteref>1</a></sup> Processor, which controls the microphone array. Unfortunately, it seemed
63
+
for a while as though this assumption would not hold. What could be the issue though? A bug in RTKit?
64
+
A change in how AOP is initialised? The only way we were going to find out was by buying a device…</p><p>Armed with a shiny <del>new</del> refurbished 16" MacBook Pro and a fresh Gentoo install, I started digging
65
+
and quickly ran into the first major issue; everything kinda works. The AOP is booted correctly, the
66
+
microphone endpoint is initialised, and the ALSA driver registers a PCM with the correct metadata.
67
+
Trying to open that PCM, however, fails silently. Oh dear.</p><p>Just how does one debug something like this? Perhaps you could run Linux as a guest of m1n1 and
68
+
stare at hexdumps for hours like we do for macOS. Or maybe you’d use the kernel’s builtin debugging
69
+
features like ftrace or kgdb. Knowledge is leveraging all of the debugging facilities available to you
70
+
to quickly and efficiently pinpoint the exact point of failure. Wisdom, however, is <code>printk()</code>.</p><p>And so it was for the next eight hours. <code>printk()</code>, compile, boot. <code>printk()</code>, compile, boot.
71
+
Oops, followed the wrong branch. <code>printk()</code>, compile, boot.</p><p>Eventually, I ended up pretty deep in the DMA core, and came out the other side somewhere near
72
+
IOMMU code. A memory allocation was failing, and this was bubbling back up to the ALSA driver. Following
73
+
along just a little further revealed that the allocation itself wasn’t failing, it was mapping of the
74
+
memory region to an I/O virtual address.</p><p>For a multitude of reasons, the IOMMU core supports imposing a limit on the range of valid addresses
75
+
for a given IOMMU. For DART, we specify these ranges in the Devicetree using the <code>apple,dma-range</code>
76
+
property. If anything tries to map an IOVA outside of the specified range, the driver will return
77
+
an error. The values for this property come from Apple’s Devicetree, but have to be manually entered
78
+
into the Linux Devicetree source. You already know where this is going…</p><p>With the <code>apple,dma-range</code> property removed, one more boot finally gave us what we wanted — working
79
+
mics on an M2 Pro/Max laptop! A patch was quickly applied to the kernel tree and a version tagged off.
80
+
Be sure to update your systems once your distro releases a kernel based on this tag!</p><p>We still have some work to do, however. Even with the <em>correct</em> values in the <code>apple,dma-range</code> property,
81
+
our IOVA allocation still fails. Thankfully, this property is not actually required and isn’t
82
+
specified for the AOP DART in any other SoC’s Devicetree, so M2 Pro/Max MacBook users can at least
83
+
enjoy using their microphones while we figure this out.</p><p>Thanks to the funds made available by our generous supporters on GitHub Sponsors and OpenCollective,
84
+
we are able to afford not only to keep the lights on, but to procure the hardware we need to reverse
85
+
engineer and support the platform. That said, these funds are not an infinite money glitch.</p><p>OpenCollective works predominantly on a reimbursement model, where an invoice for a purchase
86
+
<em>already made</em> must be presented and approved before funds can be released. This means that all of our
87
+
expenses are paid for out of pocket, with a delay of up to 5 weeks between making the purchase and getting
88
+
reimbursed. MacBooks are not cheap, and we do all still have other expenses in our lives. All of this to say,
89
+
we can’t just magic up a device at a moment’s notice and drop everything to look at every bug we encounter.
90
+
Things need to be prioritised, including our non-Asahi commitments. We understand that the wait for this
91
+
has been long and testing on everyone’s patience, and we thank you for bearing with us.</p><h2id=asahi-at-the-congress>Asahi at the Congress</h2><p>It is December, which means the Chaos Communications Congress is almost upon us. We are pleased to
92
+
announce that not only are some of us attending 39C3, but our very own Sven will be giving an
93
+
Asahi-themed <ahref=https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/asahi-linux-porting-linux-to-apple-silicon>talk on Day 4</a>.
94
+
Topics will include our reverse engineering process, what we’ve already achieved, and what the future
95
+
holds. Be sure to check it out, timezone permitting!</p><h2id=a-better-installation-experience>A better installation experience</h2><p>We’ve always said, somewhat tongue-in-cheek, that we want Asahi-the-distro to cease existing.
96
+
At its core, Asahi Linux has always been a reverse engineering project. An “official” Asahi distro,
97
+
be it Asahi ALARM or Fedora Asahi Remix, has always been considered a temporary measure while we work
98
+
with the various upstream projects to integrate our code. By now everyone is aware of our work with
99
+
the Linux kernel, PipeWire, WirePlumber and Mesa, but we also work with less obvious — yet equally
100
+
important — projects.</p><p>Apple Silicon Macs are effectively scaled up iPads, and their SSDs reflect this. These machines use the
101
+
SSD to store the bootloader, firmware, factory calibration data, and data used by the SEP for security.
102
+
Each machine also has a system recovery partition at the end of the disk, and a paired recovery
103
+
environment for each installed macOS instance. If <em>any</em> of these are deleted, your data is toast and
104
+
you will need to DFU restore your Mac.</p><p>This is part of the reason that Fedora Asahi Remix is installed via a disk image. It is far safer
105
+
to allow our installer to sanely partition your Mac’s disk and flash known-good images into the
106
+
relevant partitions. This approach is great for a single-distro pipeline, however comes with
107
+
some serious drawbacks.</p><p>Firstly, it is unrealistic and unfair to expect other distros to take on the release engineering
108
+
burden of building special disk images and installers for a single platform. Not only is this
109
+
a lot of effort for a relatively small user base, it also involves a lot of duplicated effort
110
+
across each distro.</p><p>Secondly — and most importantly for a lot of our users — this approach is rather unhygienic
111
+
from an information security perspective. Flashing a pre-rolled disk image makes it impractical
112
+
to set up disk encryption at install time, and means that we need to manually scramble partition
113
+
UUIDs on first boot.</p><p>In an ideal world, installing Linux on an Apple Silicon Mac should be as easy as using the Asahi
114
+
Installer to prep the machine, then booting your favourite distro’s live image and installing from
115
+
there. Some distros, such as Gentoo, are already taking this approach. Gentoo can get away with
116
+
this because the partitioning is entirely manual and users almost always follow the documentation
117
+
step-by-step; a little guidance and care on the user’s part is enough to avoid most partitioning
118
+
mishaps. However, distros with a graphical installer will typically offer to automatically partition
119
+
a user’s disk with the distro’s defaults. These tools are mostly designed around the PC, and will
120
+
happily wipe out the entire target disk. We obviously cannot allow this to happen, and the fact that
121
+
it is highly likely means that we cannot support a traditional, mainstream install approach. Yet.</p><p>Every partition on GUID Partition Table<supid=fnref:2><ahref=#fn:2class=footnote-refrole=doc-noteref>2</a></sup> disk is marked with a partition type UUID. These are
122
+
standardised, and never change. Apple’s special partitions are included in the standard, allowing
123
+
us to easily identify a Zone of Avoidance for partitioning operations.</p><p>To this end, Neal has been working with the Anaconda team to hide these partitions so that they
124
+
cannot be removed accidentally by Anaconda’s disk partitioning module. Once this work is complete
125
+
and filters through to a release, distros which utilise Anaconda will be safely installable from
126
+
live media! The goal is for Anaconda to present <em>only</em> the free space created
127
+
by the Asahi Installer, enabling fearless automatic partitioning. This also enables users to easily
128
+
specify custom disk setups, such as full disk encryption or nonstandard filesystems if so desired.</p><p>In a similar vein, Neal has also been working with KDE on Plasma Setup, a new onboarding application
129
+
intended to make system setup on first boot a pleasurable experience. Once stable, Plasma Setup will
130
+
allow us to replace the current Calamares-based first boot wizard with a modern, integrated experience!</p><h2id=happy-holidays>Happy holidays!</h2><p>As 2025 comes to a close, we want to thank everyone who has supported us financially on <ahref=https://opencollective.com/asahilinux>Open Collective</a>
131
+
and <ahref=https://github.com/sponsors/asahilinux>GitHub Sponsors</a>, contributed code, reported a bug,
132
+
or even just offered moral support! We will see you all up ahead.</p><divclass=footnotesrole=doc-endnotes>
<p>Remember when this is what GPT stood for? <ahref=#fnref:2class=footnote-backrefrole=doc-backlink>↩︎</a></p></li></ol></div><divclass=post-bottom>James Calligeros · <spanclass=publishdate>2025-12-14</span></div></div></div></section><footerid=footer>
138
+
<divclass=footer-menu>
139
+
<divclass=footer-logo>
140
+
<ahref=/>
141
+
<imgsrc=/img/AsahiLinux_logomark.svgclass=logoalt="Asahi Linux logo">
142
+
</a>
143
+
<spanclass=license>Licensed under CC BY-SA 4.0</span>
144
+
<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.
145
+
<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>
<aclass=post-titlehref=https://asahilinux.org/2025/12/progress-report-6-18/>Progress Report: Linux 6.18</a>
37
+
<summary>Linux 6.18 has released, and we have a bit to talk about for this holiday season progress report!
38
+
More upstreaming madness Last time, we announced that the core SMC driver had finally been merged upstream after three long years. Following that success, we have started the process of merging the SMC’s subdevice drivers which integrate all of the SMC’s functionality into the various kernel subsystems. The hwmon driver has already been accepted for 6. <ahref=https://asahilinux.org/2025/12/progress-report-6-18/title="Read more">... </a></summary>
39
+
<divclass=meta>2025-12-14</div></li><li>
36
40
<aclass=post-titlehref=https://asahilinux.org/2025/10/progress-report-6-17/>Progress Report: Linux 6.17</a>
37
41
<summary>Another upstream kernel release means it must be time for a progress report!
38
42
The patches keep coming As always, upstreaming continues. The highlight of this cycle is finally landing the SMC core driver, after discussions on the mailing list going all the way back to 2022! Along with the core driver, drivers for the SMC’s GPIO controller and reboot controller have also been merged. This allows devices which are already upstream to reboot gracefully, and lays the groundwork for enabling WiFi and Bluetooth upstream. <ahref=https://asahilinux.org/2025/10/progress-report-6-17/title="Read more">... </a></summary>
0 commit comments