Asahi Linux发布Linux 7.3进展报告

进展报告：Linux 7.3

进展报告：Linux 7.3

好吧，我们又来了。Linux 7.3 已经发布，过去几个月里发生了很多事情，所以让我们开始另一篇 Asahi Linux 的进展报告吧！

上游化工作持续推进

一如既往，上游化工作正在稳步推进。除了针对底层 SoC 块的常规补丁外，本周期有两个主要驱动程序进入了列表：macaudio 和 avd。让 macaudio 做好提交准备是一项挑战。

Apple Silicon 设备上的音频子系统相当特殊，需要相当数量的核心 ALSA 变更才能正确支持它。Apple 还使用了已经在上游支持的扬声器、耳机放大器的特殊变体，这些驱动程序也需要进行一些相当重大的修改。

我们之前已经详细讨论过这项工作，现在我们终于处于可以提交主驱动程序进行审查的位置。该驱动程序和 Devicetree 变更代表了我们的补丁集中相当大的一部分，大约 3100 行。

AVD 则完全是另一回事。AVD 驱动程序在我们的下游树中仅仅停留了不到 3 个月就已经上了列表。这是我们针对主要 SoC 组件的最短周转时间，预示着未来某个时候向“上游优先”开发模式的转变。这是极好的消息，因为 AVD 驱动程序和相关 Devicetree 变更大约有 13000 行代码。

此外，本周期还首次出现了 M4 Pro 和 Max 设备，以及 M5 的 Devicetree，这要归功于 Yureka 的不懈努力。像往常一样，这些初始 Devicetree 是基础版本，仅足以将 SoC 启动到 TTY，但进一步的启用工作正在推进中。请密切关注！

我们也开始在实际可行的情况下转向“上游优先”的方法。用于新设备的 TI USB-PD 和 SPMI 驱动程序的变更，以及 Thunderbolt 的初步支持，都是先在上游开发的。看到我们在上游化方面的努力开始取得回报，我们感到非常激动！

M3 系列正式发布

上次，我们通过 Asahi 安装程序上的 EXPERT 标志宣布了对 M3 系列机器的初步支持。我们很高兴地宣布，早期采用者几乎没有遇到任何问题，因此 M3 支持现在无需 EXPERT 标志即可普遍使用！

我们还对 M3 支持进行了多项改进，最显著的是启用了 DCP。除了性能和电池续航时间的提升外，这还允许我们在 M3 系列设备上启用睡眠功能，并使 MacBook 的刘海区域变得可用！请留意未来几天内的 m1n1 和内核更新。

拥挤的家园

上次，我们预告了在 m1n1 中支持虚拟化支持 SPTM 的 macOS 版本，这可以在 M4 系列机器上进行逆向工程。M5 带来了一个新的挑战，因为支持它的所有 macOS 版本都需要使用 Exclaves。

Exclaves 是运行在由 Secure Kernel 控制的隔离环境中的小型应用程序。在 M5 系列 SoC 及更高版本上，macOS 使用它们来执行诸如将“正在使用相机”指示器绘制到屏幕上的敏感任务。

XNU 通过 SPTM 与 Secure Kernel 及其 Exclaves 通信，使用的是另一个名为 Tightbeam 的 IPC 协议。与 SPTM 类似，如果 XNU 找不到正在运行的 Exclaves，它将会 panic。从概念上看，这一切与 Arm 自家的 TrustZone 功能非常相似。

虽然有些 Exclaves 可以通过更改命令行上的某些设置来绕过，但我们预测这种情况不会总是如此。因此，Sven 开始研究如何将所有这些内容整合到 m1n1 中。首先进行的调查是尝试将 Secure Kernel 和 Exclave 用户空间放在与 SPTM 和 macOS 并列的另一个 VM 中。

噢，这行得通，我们现在已经可以在 m1n1 的 EL1 下启动三个 VM 了！也许我们可以开始向逃离 VMware 的公司推销 m1n1 了……有了这个，我们现在可以在 M4 和 M5 系列机器上虚拟化和逆向工程 macOS 了。

Hello Triangle(s)！

虽然 M3 的支持现在大多已经与 M1 和 M2 达到了功能对等，但非常明显的例外是 GPU。Apple 的 GPU 团队似乎遵循着 tick-tock 模型，而 M3 的 GPU 与在 M1 和 M2 SoC 上发现的模型相比是一个巨大的转变。我们早在很久以前就提到过 M3 GPU 正由一组新的贡献者进行逆向工程，但自那以后几乎没有什么消息。

在今年的 XDC 上，Alyssa Millburn、Anna Maniscalco 和 TellowKrinkle 就他们逆向工程 M3 GPU 的进展发表了一次演讲。工作进展已经足够让 m1n1 成功初始化 GPU，并且团队能够绘制出一个三角形！

如果你喜欢这些进度报告中的“Think Different”部分，那么这次演讲会很有启发性；Apple 再次做出了许多……有趣的选择，这将需要大量的工程努力才能整合到上游 Mesa 中。如果你对更多细节感兴趣，非常值得一看。

向所有让这项工作成为可能的人致以巨大的感谢。更多进展即将到来，敬请关注。

让你久等了，是吧？

早在 2024 年 1 月，我们犯了一个错误，承诺在当年内提供 Thunderbolt 支持。这是一个我们不会很快重犯的错误。在随后的两年里，我们几乎没怎么提到 Thunderbolt，这不禁让人想问：它在哪里？

它在邮件列表里！

Thunderbolt 最初由 Apple 和 Intel 开发，由 Intel 负责所需硬件的设计和制造。由于 Intel 以（大部分）合理的价格向任何想要的人提供这些控制器，其他人就没有必要费心去设计自己的控制器。直到最近——很大程度上与标准移交至 USB-IF 同步——像 AMD 这样的公司才决定推出自己的控制器。Apple 当然也不例外。

作为其推动大部分硅 IP 内购计划的一部分，Apple 在大多数其他厂商之前做出了自行设计 Thunderbolt 控制器的选择。不出所料，该控制器当然是一颗运行 RTKit 的 Cortex-M3，并搭配了一个定制的 Thunderbolt/USB4 路由器。

在所有搭载 Apple Silicon 的 Mac 上，每个 Thunderbolt 启用的 USB-C 端口都有一个这样的控制器。

由于 Intel 供应市场上其他所有现有的 Thunderbolt 控制器，Linux 内核的 Thunderbolt 子系统实际上就是围绕它们设计的。它对运行机器的硬件拓扑结构做出了许多假设，包括硬件能力以及对某些寄存器和共享内存区域的访问模式。Apple 的控制器打破了许多这些假设。太棒了。

Thunderbolt 控制器还与 PMGR 奇怪地耦合在一起。每个控制器的复位线是通过设置和清除 PMGR MMIO 范围中间的一组位来断言或取消断言的。没有其他硬件模块以这种方式工作，花了些时间才意识到对这些看似随机的 PMGR 写入不仅仅是噪声。

幸运的是，Sven 有能力处理所有这些乱七八糟的事情。这仅仅比预期花的时间稍长一点！虽然启用 Thunderbolt 的补丁集首先被发送到上游（这对我们来说是另一大胜利！），我们也已经将其拉取到我们的下游内核中，现在正在向用户发布！

但是有一个问题。目前，只支持 USB3、XDomain 和 Thunderbolt Networking。你可以插入 USB 设备或将两台 Thunderbolt 计算机连接在一起并让它们互相 ping，但仅此而已。PCIe 和 DisplayPort 隧道——大多数 Thunderbolt 端口所需的功能——尚未支持。等着瞧吧。

Sven 值得巨大的感激，他在所有其他令人难以置信的工作之间，坚持做这个毫无回报的任务近 5 年。

“圣杯，琼斯博士”

在 Asahi Linux 上玩零售 PC 游戏可以说是一个痛点。启用此功能所需的软件栈极其复杂。我们需要将 x86/amd64 二进制文件翻译成 arm64，并且速度要足够快以实现低延迟游戏。在大多数情况下，我们还需要处理 Windows API。O