在 Apple Silicon Mac 上运行 Linux 从来不是简单的「装系统」问题，而是一场与苹果安全启动链的深度博弈。Fedora Asahi Remix 作为首个针对 M3 芯片提供正式支持的发行版，其启动流程凝聚了社区多年逆向工程的结晶。本文将从固件工程的角度，逐层拆解从 SecureROM 到 Linux 内核的完整链路，揭示 UEFI 仿真、设备树动态注入、引导组件版本协同等关键技术点的工程实现细节。
Apple Silicon 的安全启动链与破解入口
理解 Fedora Asahi Remix 的启动流程，必须先理解 Apple Silicon 设备独特的启动架构。与传统 x86 PC 不同，Apple M 系列芯片采用类似 iOS 的安全启动模型，整个启动过程由硬件根信任（Hardware Root of Trust）逐级验证。苹果设备的启动流程从片上 ROM（SecureROM）开始，这是固化在芯片中的不可更改代码，负责验证并加载下一阶段引导程序。SecureROM 读取 NOR Flash 中的 LLB（Low-Level Bootloader）或 iBoot1，通过硬件绑定的密钥进行签名验证。如果验证失败，设备会进入 DFU（Device Firmware Update）模式，等待外部程序注入。
M3 芯片延续了这一架构，但其安全策略比前代更加严格。苹果在 T2 芯片之后的 Mac 中引入了「安全启动策略」概念，允许用户在恢复模式中选择「完整安全」「中等安全」或「低安全」模式。Fedora Asahi Remix 的安装必须依赖「低安全」模式，因为 Linux 引导程序需要绕过或替换苹果的验证链。这一限制意味着 M3 上的 Linux 启动本质上是在苹果安全框架内找到合法的「后门」—— 利用苹果为开发和调试预留的机制。
苹果为开发者提供的调试接口是整个 Asahi 项目的突破口。通过 Recovery 模式下的特定命令，设备可以加载未经签名验证的外部程序，这正是 m1n1 项目的切入点。m1n1 本身不是一个完整的操作系统，而是一个微型引导环境，设计用来替代 iBoot/XNU，承担早期硬件初始化和后续引导链的建立工作。
m1n1 双阶段引导的设计哲学
m1n1 是 Asahi Linux 项目的核心组件，其设计体现了「最小特权」和「渐进式初始化」的工程原则。整个 m1n1 被拆分为两个阶段，这种拆分并非随意，而是针对 Apple Silicon 硬件特性和安全模型精心设计的。
第一阶段（m1n1 stage 1）的职责极其有限但至关重要。它由 Asahi Linux 安装程序从恢复模式注入，安装时使用机器特定的内部密钥进行签名，这一签名过程符合苹果的 Secure Boot 策略，因此被硬件接受。第一阶段的核心任务是定位并加载第二阶段，它将 EFI 系统分区的 PARTUUID 硬编码在内部，确保只能从预期的系统分区启动。这个设计既保证了启动来源的确定性，又避免了外部存储设备可能带来的安全风险。
第一阶段从 <ESP>/m1n1/boot.bin 加载第二阶段，这里的 ESP（EFI System Partition）必须位于内部 NVMe 存储上，不支持外部 USB 存储设备启动。这一限制源于苹果的硬件枚举逻辑 —— 外部设备在早期启动阶段可能尚未完成初始化。值得注意的是，第一阶段还将当前启动的 ESP 的 PARTUUID 传递给下一阶段，作为设备树节点 /chosen/asahi,efi-system-partition 的属性值。这一信息在后续阶段用于定位正确的引导分区。
第二阶段（m1n1 stage 2）承担了大部分硬件初始化工作，这也是 Asahi 项目工作量最大的部分。它负责选择适合当前平台的设备树（Device Tree，简称 DT），填充动态属性，并加载 U-Boot。与第一阶段的「不可变」特性不同，第二阶段可以随系统升级而更新，因为苹果的签名机制只验证到第一阶段为止。分发版（如 Fedora Asahi Remix）负责维护和升级第二阶段。
m1n1 stage 2 的硬件初始化策略遵循一个重要原则：将「魔法」初始化代码集中在 m1n1 中，而非放入 Linux 驱动。苹果硬件（尤其是 Apple Silicon）存在大量需要特定寄存器序列才能正常工作的组件，这些序列通常由 macOS 的 XNU 内核在启动时执行。m1n1 接管这一职责，使得 Linux 内核能够保持相对「纯净」，只需与标准的设备树接口交互。这种设计极大地提高了向前兼容性 —— 例如，M2 平台的 PCIe 支持只需更新设备树，无需修改 Linux 驱动程序。
设备树的动态注入与版本协同
设备树（Device Tree）是 ARM 架构描述硬件的核心机制，Fedora Asahi Remix 在 M3 上的启动过程中，设备树的处理是技术复杂度最高的环节之一。与 x86 系统的 ACPI 不同，设备树需要在引导早期阶段被构建并传递给内核，而 M3 平台的特殊性在于大量硬件信息无法静态编码。
m1n1 stage 2 在加载 U-Boot 之前，会根据检测到的 SoC 型号选择对应的设备树基础文件，然后动态注入运行时才能确定的信息。这些动态属性包括：内存控制器配置、时钟树设置、电源域状态、IOMMU（DART）映射表等。苹果芯片的 DART（Device Address Resolution Table）是一种高性能 IOMMU，用于隔离外设的内存访问权限，保护系统安全。不同 M3 变体的 DART 配置差异显著，必须由 m1n1 根据具体芯片型号注入正确的参数。
Fedora Asahi Remix 的设备树策略是「全量打包」。所有支持的 SoC 设备树都被编译并打包进 m1n1 stage 2 镜像，m1n1 在运行时根据硬件检测结果选择正确的文件。这一设计简化了系统更新流程 —— 用户只需更新 m1n1 包，所有平台的设备树随之更新。然而，这也带来了版本协同的复杂性。
设备树、内核、m1n1、U-Boot 四者之间存在微妙的版本依赖关系。新的内核功能可能依赖于 m1n1 新增的设备树属性或初始化代码；如果 m1n1 未更新，内核可能无法识别某些硬件，或在初始化阶段崩溃。反之，如果设备树引入了新的绑定（Binding）而内核不支持，可能导致驱动程序探测失败。Asahi 文档明确建议用户在更新内核时同步更新 m1n1，并在遇到启动问题时尝试「降级」设备树版本。
设备树绑定（Binding）的上游状态也是需要关注的因素。尚未上游的绑定可能在审查过程中发生不兼容变更，导致已发布的内核在特定平台上无法启动。例如，t600x 系列的 AIC2 中断控制器绑定变更就曾导致旧内核完全无法启动。Asahi 团队在处理这类问题时，会临时维护「兼容」版本的设备树，同时推动绑定最终上游化。
UEFI 仿真与 GRUB 引导
在 m1n1 stage 2 完成硬件初始化和设备树准备后，下一环是 U-Boot 的加载与执行。U-Boot 在 Asahi 系统中扮演双重角色：它既是硬件初始化链的一环，也是标准 UEFI 环境的提供者。Fedora Asahi Remix 选择了 U-Boot 作为 UEFI 实现，而非使用单独的 OVMF（Open Virtual Machine Firmware），这一选择有其工程考量。
Fedora Asahi Remix 使用的 U-Boot 是 Asahi 维护的分支（asahi-releng），该分支包含了专门为 Apple Silicon 设计的 EFI 系统分区自动检测逻辑。标准 U-Boot 依赖 EFI 变量来选择启动设备，但 Apple Silicon 平台缺乏持久化 EFI 变量存储 —— 没有可用的 NVRAM 模拟方案。Asahi 分支通过读取 m1n1 注入的 /chosen/asahi,efi-system-partition 属性来定位正确的 ESP，绕过了传统 UEFI 的启动顺序管理机制。
U-Boot 加载后，它初始化更多外设（键盘、USB 等），并提供标准的 UEFI 服务。接下来，它从 <ESP>/EFI/BOOT/BOOTAA64.EFI 加载 GRUB（或任何其他 arm64 UEFI 二进制）。Fedora Asahi Remix 使用 GRUB 作为默认引导程序，这与上游 Fedora 的选择一致。GRUB 负责加载 Linux 内核映像、Initramfs，并传递命令行参数。
值得注意的是，U-Boot 会对设备树进行轻微修改，主要是根据控制台选择设置 stdout-path。在 Asahi 配置中，系统会判断用户是否使用物理键盘 / UART 控制台，并相应调整设备树的串口配置。这一细节确保了启动日志能够正确输出到预期目标。
固件分发的工程挑战
Fedora Asahi Remix 作为发行版，需要将 Asahi 项目的底层组件打包并分发给用户。这一过程涉及多个固件组件的协同更新，每个组件都有其独特的构建和部署流程。
m1n1 的构建相对简单，官方仓库提供完整的构建脚本。关键构建步骤包括：克隆带 submodule 的 Git 仓库，设置 RELEASE=1 编译标志（关闭 verbose 日志），输出 build/m1n1.bin。U-Boot 需要切换到 Asahi 维护分支（asahi-releng），使用 apple_m1_defconfig 配置，然后编译生成 u-boot-nodtb.bin。设备树则来自 Asahi 维护的 Linux 内核树，编译后生成 arch/arm64/boot/dts/apple/*.dtb。
将这些组件打包成可部署的 boot.bin（m1n1 stage 2）需要使用 Asahi 提供的 update-m1n1 脚本。该脚本的执行逻辑是：依次拼接 m1n1.bin、所有设备树（*.dtb）、以及 gzip 压缩后的 U-Boot 二进制。U-Boot 必须 gzip 压缩是因为 m1n1 的镜像格式不是自描述的，压缩有助于边界识别。
固件分发的另一个挑战是「供应商固件」（Vendor Firmware）的处理。Apple Silicon 设备中存在部分无法自由分发的固件文件（如 WiFi/Bluetooth 固件），这些文件在安装时从 macOS Recovery 中提取，存储在 /usr/lib/asahi-boot/ 目录下。Fedora Asahi Remix 的安装程序负责这一提取过程，确保系统在首次启动时即具备完整的固件支持。
调试与故障排查的参数建议
理解启动流程的工程细节，对于故障排查至关重要。当 Fedora Asahi Remix 在 M3 上无法启动时，定位问题阶段的首要任务是确定失败发生的环节。
如果问题发生在 m1n1 阶段（通常表现为屏幕完全黑屏或无任何输出），可以尝试在安装时保留旧版本 m1n1 备份。macOS 和 Recovery 模式可以直接访问 FAT32 格式的 ESP，因此可以通过 diskutil list 和 diskutil mount 命令挂载分区，手动替换 m1n1/boot.bin 文件。这一方法允许在无法进入 Linux 系统的情况下进行「降级」或「修复」操作。
如果 m1n1 能够运行但 Linux 无法启动，问题可能出在设备树不匹配或 m1n1 版本过旧。一种调试手段是通过 Recovery 模式设置 NVRAM 变量 boot-args=-v，启用内核 verbose 模式，将启动日志输出到 UART 控制台。UART 输出在 Apple Silicon 上需要特殊的适配器或使用虚拟串口，但它是定位内核早期崩溃点的关键手段。
m1n1 的版本信息目前并未显式注入设备树，这给依赖性检查带来困难。未来可能的改进方向是将 m1n1 版本写入 /chosen/m1n1,version 属性，使 Linux 驱动能够在初始化前检查版本是否满足要求。这一设计可以避免在 m1n1 版本不足时驱动进行危险操作（如访问未初始化的硬件寄存器），可能导致系统硬锁定。
Fedora Asahi Remix 在 M3 上的启动流程是开源社区与闭源硬件博弈的典范。从 SecureROM 到 Linux 内核，每一层都涉及对苹果专有协议和硬件特性的深度逆向工程。理解这一流程不仅有助于故障排查，也为在其他 ARM 平台上实现类似支持提供了可复用的方法论。
参考资料
- Asahi Linux 文档：《Boot Process Guide》https://asahilinux.org/docs/alt/boot-process-guide/
- Asahi Linux 文档：《Apple Silicon Boot Flow》https://asahilinux.org/docs/fw/boot/
- Fedora Asahi Remix 文档：《How it's made》https://docs.fedoraproject.org/en-US/fedora-asahi-remix/how-its-made/
- Asahi Linux：《Progress Report: Linux 6.17》https://asahilinux.org/2025/10/progress-report-6-17/