Asahi Linux 7.1 进展报告

# 进度报告：Linux 7.1 — Asahi Linux 来源：https://asahilinux.org/2026/06/progress-report-7-1/ Linux 7.1 现已到来，随之而来的自然是又一份进度报告。我们带来了 M3 的进展、Apple 的 Bug，以及更多内容！ ## 欢迎回来，主引导记录 当你长按 Mac 上的电源键调出启动选择器（或使用启动磁盘应用程序）时，列表中所显示的“Asahi”并非实际装有操作系统的那个分区。Apple 的启动工具只会与它认为 APFS 容器内“有效”的 macOS 安装进行交互。为了让我们能够利用 Apple 的引导加载程序，避免用户每次想使用 Asahi 时都需要从 Recovery 运行命令，Asahi 安装程序会创建一个较小的 APFS 容器（2.5 GB），其中仅包含足以让 Apple 工具相信这是一个可引导的 macOS 安装的内容，并以 m1n1 作为其内核。这种安排从 macOS 12 到 macOS 26 一直完全有效，Apple 甚至修复了其工具中只有在尝试引导并非真正 XNU 内核的裸二进制文件时才会遇到的几个 Bug。 然而，在 macOS 27 Golden Gate 开发者测试版发布后不久，我们开始收到报告，称用户无法再在其机器上引导进入 Linux —— 无论是启动磁盘还是启动选择器中都完全找不到这个选项！这显然非常令人担忧，因此我们将其作为优先事项进行调查。 使用 diskutil 检查磁盘后发现，升级到 macOS 27 后，磁盘上所有与 Asahi 相关的分区仍然存在。没有发生数据丢失，这是一个积极的信号。此外，在相同机器上使用另一个 macOS 26 安装的启动工具时，Asahi 仍然可以引导。 chaos\_princess 开始检查 Apple 自己的 macOS 安装程序以及我们最早研究 Apple 启动工具时的旧数据流。macOS 安装程序在重启机器前会设置一些 APFS 元数据，进一步调查发现这是一个标记卷为可引导的标志。直到 macOS 27，启动工具都完全忽略了这个标志。在手动为 Asahi APFS 容器设置该标志后，它便可在 macOS 27 的启动选择器中显示，无需其他更改。 今后，所有新的 Asahi 安装都会由 Asahi 安装程序自动设置此标志。我们还添加了一个安装程序模式，可以修复现有的安装。如果你已安装 macOS 27 开发者测试版且无法访问 Asahi 安装，请重新运行安装程序并选择“修复 macOS 27 启动选择器兼容性”选项。 chaos\_princess 还开发了一个可以在 Linux 下运行的程序来修复此问题。虽然我们最终希望自动部署此修复，但需要更多测试数据来确认其可靠性，并且不会破坏任何人的文件系统。这就需要你帮忙了。如果你愿意帮助我们测试，请克隆此仓库 (https://github.com/AsahiLinux/asahi-fix27)，然后在升级到 macOS 27*之前*在 Linux 下构建并运行它。如果你的 Asahi 卷在 macOS 中仍可作为引导目标选择，则说明修复成功。请务必通过 OFTC 或 Matrix 上的某个频道 (https://asahilinux.org/community) 告诉我们结果，特别是如果你遇到任何问题的话。 ## 三个字节导致强制关机 macOS 27 还为所有具有全局固件的外设带来了固件更新，包括 SMC。SMC 的众多功能之一是电池管理。我们的 Linux 电源供应驱动程序与 SMC 通信以获取充电状态、电压、剩余时间、电池健康等信息。该驱动程序还利用 SMC 的固件接口来配置充电起始和停止阈值，以延长电池寿命。macOS 27 的 SMC 固件更改了其中一个电池管理接口，从返回 32 位整数改为返回单个字节。这一变化混淆了我们的驱动程序，在某些条件下驱动程序会认为电池已失效并启动紧急关机以保护系统。我们已经在下游内核中打了补丁；从版本 7.0.12 开始，电源供应驱动程序可以同时处理这两种固件 ABI。 ## 关于安装测试版 像这样的 Bug 是一个重要的提醒：开发者测试版就是测试版，不建议在生产机器上安装。我们目前遇到的两个问题幸好都是小问题，但这并不意味着所有未来问题也会如此。全局固件更新实际上是永久性的，只能通过机器的 DFU 恢复来回滚。请勿再安装开发者测试版。我们有专用的牺牲机器来代表你们测试这些东西，没有必要冒险使用你自己的昂贵硬件和重要数据。 ## 万变不离其宗 设计和验证计算机平台及其中的 IC 极其昂贵且耗时，因此在没有必要时对现有设计进行更改是毫无意义的。在项目早期，我们押注 Apple 会同意这一点，并避免不断地对两者进行破坏性更改。除去 GPU 等几乎每一代都需要更改的少数较大 SoC 模块，这一赌注基本得到了回报。 Apple Silicon 笔记本电脑上的音频涉及几个不同的 IC 和 SoC 模块。音频 IC 的事实行业标准是 I2S，这是一种基于 I2C 的优化用于音频数据的总线。Apple 的 I2S 控制器自 M1 以来一直未变。所有这些音频 IC 还需要一个稳定的时钟源，该时钟源必须可配置以适应各种音频数据速率。Apple 的数字控制振荡器（NCO）自 M1 以来也一直未变。Apple 在几乎所有 Apple Silicon 机器上都使用了完全相同的扬声器和耳机放大器芯片。因此，当 chaos\_princess 开始为 M3 机器添加扬声器和耳机插孔支持时，所需的只不过是一些简单的设备树添加以及 asahi-audio 和 speakersafetyd 的配置文件。因此，M3 机型现在在 Asahi Linux 上拥有了高质量音频输出！ M3 机型还增加了对 CPU 频率切换和适当的 big.LITTLE 任务调度的支持。自 M2 基础款以来，Apple 并未更改 CPU 频率切换的工作方式，这意味着所有 M3、M3 Pro/Max/Ultra SoC 只需进行设备树更改即可与我们现有的 cpufreq 驱动程序配合使用。现在，任务应该能根据其需求更智能地被分配到能效核心或性能核心上，CPU 核心本身也会根据负载进行升降频。这将既节省能源又提升性能！ 为 SMC 的硬件传感器添加支持也同样简单；SMC 的固件在不同机器之间并无实质性差异，因此这里同样只需要几个设备树更改即可。 除此之外，我们在 Linux 中针对 M3 系列机器还拥有 PCIe、WiFi、蓝牙、NVMe、键盘、触控板以及其他核心 SoC 模块驱动程序。这些工作大部分来自 Yureka (https://fedi.yuka.dev/yuka)，她一直在用自己的 M3 系列机器忙于破解 m1n1 和 Linux。距离我们能够为这些机器启用 Asahi 安装程序支持还有一段路要走，但进展迅速，敬请期待！ ## 我们现在开始编写固件了？ 这个平台上大多数复杂的硬件都使用了复杂的固件二进制块。其中大部分基于 RTKit，这是一个类似 RTOS 的固件框架，Apple 用它来为内核与各种硬件部件通信提供基本标准化的接口。但也有例外。某些模块（如 DCP 和 AOP）以 RTKit 为基础，但在其上又叠加了另一套称为 EPIC 的抽象。其他模块（如 Broadcom WiFi/蓝牙芯片组）则使用第三方固件，Apple 无法直接控制。然后，还有 Apple 视频解码器（AVD）。 AVD 很特别。它的固件既不是 RTKit 也不是 EPIC，而是一个秘密的第三种东西。该硬件本质上是一个 ARM Cortex-M3 控制器，控制着一系列固定功能硬件单元，用于解码 AVC（H.264）、HEVC（H.265）、VP9 以及较新 SoC 上的 AV1 编码的视频帧。CM3 运行着一份固件二进制，它暴露了一个接口供 XNU 指向视频数据，然后自行对实际的解码器硬件进行编程。这本身通常没问题，但 Apple 做了一个有趣的选择：将 AVD 的固件以及一堆配置数据都捆绑在 AVD 内核扩展内部。更糟糕的是，每个 SoC 都有一个略有不同的 AVD 变体。这在物流上很有挑战性，因为 Asahi 安装程序必须不断更新（并跟踪）Apple 对内核扩展中固件数据偏移量的更改。我们*可以*这样做，但有没有更好的方法呢？ XNU 加载的固件并不会被 CM3 验证。当收到信号时，CM3 会从其复位向量开始执行，无论那里实际是什么内容。如果我们直接... 使用我们自己的固件呢？ 由于该固件实际上只是用来抽象底层视频解码器硬件，因此只要它能安装各个硬件模块的中断处理程序，它具体做什么其实并不重要。如果我们理解了底层硬件期望什么，我们就可以直接从 Linux 驱动程序中对所有内容进行编程。要做到这一点，我们需要了解固件是如何驱动每个解码器的。 作为标准的 Cortex-M3 代码，可以在模拟器中运行 AVD 固件。有几种解决方案可以实现这一点，包括 QEMU，它允许你单步执行程序并检查总线和寄存器操作。这项基础工作多年前由 Jamie、R 和 Eileen 打下，他们通过共同努力成功逆向工程了 AVC 和 VP9 解码器所需的指令和数据格式。 XNU 内核扩展还会为每个 AVD 修订版应用一组独特的调节参数。我们不完全清楚这些参数的作用，因此应用它们基本上需要重放 XNU 进行的 MMIO 写入操作。我们需要跟踪每个 AVD 修订版、每组调节参数以及它们需要应用到哪个修订版。这在上游 Linux 内核驱动程序中难以令人满意地维护，因此这部分最好也放在固件中。 虽然这方面很长时间没有太多工作，但新贡献者 ofus (https://github.com/sofus13) 最近主动填补了空白。通过一份自定义的 AVD 固件二进制，它仅安装中断处理程序并应用每个变体的调节参数集，他成功地为 AVC 硬件编写了一个可工作的 V4L2 驱动程序！该硬件可以解码高达 4K 的 10 位 AVC 编码视频，并且能与实现 V4L2 Request API 的软件良好配合。保持固件基本且无状态，由用户空间和内核负责解析所有视频数据并自行对解码器编程，这也使我们将来能够更轻松地支持其他视频加速 API，如 VA-API 和 Vulkan Video。 在可以向用户发布 AVD 支持之前，还有一些工作要做。AVD 支持 VP9、HEVC，甚至在某些 SoC 上支持 AV1，但我们尚未实现其中任何一项。某些设备还存在一些怪癖，需要在驱动程序中进行测试和考虑。我们希望在不远的将来能够为大家提供可发布的内容！ ## 一个大型 m1n1 版本 我们最近还为 m1n1 打了版本 1.6.0 的标签。这对发行版来说是一个重要的版本，因为它是第一个在第二阶段构建中需要 Rust 的版本。此前，m1n1 仅在构建时启用了链式加载支持时才使用 Rust。第一阶段 m1n1 替换了 Apple 启动工具中的 XNU 内核，仅用于挂载 EFI 系统分区并从那里链式加载第二阶段 m1n1。然而不久前，我们决定将 GPU 初始化移至 m1n1 中。这消除了内核驱动程序处理 Apple 硬件初始化数据中浮点数的需要，并且还大大简化了设备树绑定。因此，我们最终提交给 Linux 内核邮件列表的 GPU 驱动程序版本将依赖 m1n1 来完成此初始化。我们还将对 Apple 设备树解析的代码移植到了 Rust，m1n1 几乎所有其他部分都使用了该代码。 鉴于 m1n1 实际上是固件，它使用 `no_std` Rust 并以 `aarch64-none-softfloat` 为目标。为了避免引入多余的依赖，你可以向 `make` 传递 `BUILDSTD=1` 来构建 `core` 和 `alloc`，而无需安装完整的 `softfloat` 工具链。 版本 1.6.0 还带来了对 M3 系列支持的大量改进，包括对 SPMI 控制器和 PCIe 初始化的支持。我们现在还支持通过 kisd (https://github.com/AsahiLinux/kisd) 将 SoC 的硬件 UART 直接隧道传输到 DebugUSB，这可用于实现与中央审查器非常相似的功能。这些工作的大部分同样归功于 Yureka。 我们还在为 M4 和 A18 Pro（MacBook Neo）支持奠定基础，包括更好地处理 Apple 的非 macOS 启动模式，以及支持 Apple 设备树中发现的新电源域元数据。 ## 再次感谢！ 一如既往，我们要感谢我们在 GitHub Sponsors (https://github.com/sponsor/AsahiLinux) 和 Open Collective (https://opencollective.com/asahilinux) 上慷慨的支持者，没有你们，我们将无法继续完成 M1 和 M2 的未竟功能，也无法在支持热情的新贡献者的同时推进 M3、M4 和 A18 Pro 的支持工作！ James Calligeros · 2026-06-30