編按：本文綜合整理自 Asahi Linux 官方進度報告、Phoronix 與社群討論，並加入 Siami 編輯部觀點與分析。
Asahi Linux 團隊發布 Linux 7.1 版本的進度報告，內容涵蓋三大主軸：macOS 27 Golden Gate 開發者 beta 對開機流程造成的災難性破壞、M3 系列 SoC 支援的快速擴張，以及 m1n1 引導載入器 1.6.0 全面擁抱 Rust 的重要里程碑。
macOS 27 beta 踩壞 Asahi 開機鏈
對 Apple Silicon Mac 安裝 Asahi Linux 的用戶而言，蘋果 6 月底發布的 macOS 27 Golden Gate 開發者 beta 帶來一個令人心驚的 bug：升級後 Linux 選項會直接從「開機磁碟」和「啟動選擇器」中消失。
Asahi 團隊深入追查後發現，問題根源是 macOS Installer 在重啟前會在 APFS 容器上設定一個「標記為可開機」的 metadata flag。在 macOS 26 之前的版本中，蘋果的開機工具完全忽略這個 flag，因此無論 flag 設定與否都能啟動 Linux。但從 macOS 27 開始，boot tooling 開始讀取這個 flag — 沒有設定的 Asahi 容器直接被視為「不可開機」。
好消息是，這個問題不需要重灌。Asahi Installer 現在新增了「Fix macOS 27 boot picker compatibility」選項，使用者只要重新跑一次 installer 就能修復。團隊成員 chaos_princess 也寫了一支名為 asahi-fix27 的 Linux 端修補工具，可以在升級 macOS 27 之前先執行，預先把 flag 補上。
「我們最終希望自動部署這個修補，但需要更多測試資料確認它不會破壞任何人的檔案系統。」— Asahi 官方部落格
SMC 電池介面悄悄改了 3 個 byte，Linux 直接強制關機
macOS 27 同時帶來了 SMC 韌體更新，其中一項電池管理介面的回傳格式從 32-bit 整數縮減成單 byte。Asahi 的電源供應驅動（power supply driver）在某些條件下會誤判電池故障，觸發緊急關機保護機制。
這個 bug 已經在下游核心 7.0.12 版本修好，新驅動能同時處理新舊兩種韌體 ABI。團隊藉這個事件提醒使用者：開發者 beta 不應該裝在日常使用的主力機上 — 全域韌體更新本質上是永久的，唯一的退路是 DFU 還原整台機器。
M3 音訊、CPU 頻率、硬體感測器全到位
M3 系列 SoC 的支援進度是這份報告中最振奮的部分。chaos_princess 在嘗試為 M3 機器加入揚聲器與耳機孔支援時發現，由於蘋果從 M1 開始就沒換過 I2S 控制器、NCO 時鐘晶片、揚聲器與耳機放大器晶片，整個音訊鏈只需要新增幾行 Devicetree 設定和 asahi-audio 設定檔就搞定。M3 Mac 現在跑 Asahi Linux 已經能輸出高品質音訊。
CPU 頻率切換和 big.LITTLE 任務排程也跟著通了。蘋果自 M2 基礎版以來就沒改過 CPU 頻率切換機制，因此 M3 全系列（M3、M3 Pro、M3 Max、M3 Ultra）只需要 Devicetree 修改就能用既有的 cpufreq 驅動。任務現在會根據負載自動分配到節能核心或效能核心，CPU 也會依工作負載升降頻，兼顧省電與效能。
SMC 硬體感測器的支援同樣只是 Devicetree 級別的修改，Yureka 一個人就把 PCIe、Wi-Fi、藍牙、NVMe、鍵盤、觸控板等核心 SoC 區塊的驅動從 m1n1 移植到 Linux。距離 M3 進入 Asahi Installer 正式支援名單還有距離，但進度飛快。
為什麼這件事重要
對開源社群而言，Asahi Linux 在做的事情遠超過「讓 Mac 跑 Linux」這麼單純。
這個專案正在做的事，是用開源的方式把 Apple Silicon 從頭到尾逆向工程一次 — 從開機載入器、GPU 驅動、電源管理、視訊解碼器到完整的桌面環境，五年下來累積的程式碼與文件是 ARM 生態系少見的系統性工程。對 Android 手機晶片廠、Raspberry Pi、AWS Graviton 等 ARM 平台來說，這些研究是珍貴的公開教材。
從供應鏈角度來看，蘋果自己就證明了 M1 之後的音訊與時鐘架構可以多年不變，意味著 macOS 27 這次對 SMC 介面的調整更像是「順手清掉技術債」，而不是「封鎖 Linux」。但對 Asahi 團隊來說，這正提醒了一件事：逆向工程的維護成本不會消失，macOS 每年都會改，使用者的硬體需要持續的修補工作。
數據解讀：M3 支援進度等於 M1 當年 beta 水位
Phoronix 引述 Asahi 團隊說法指出，M3 的當前支援進度大約等於 2021 年 M1 第一次發表 Arch Linux ARM beta 時的水位：鍵盤、觸控板、Wi-Fi、NVMe、USB3 都能跑，但部分功能還需要 m1n1 與 Asahi kernel 的本地補丁，尚未送進 Linux 主線 pull request。換言之，現階段 M3 跑 Asahi 還是要有心裡準備 — 安裝容易、日常使用則要靠社群持續維護。
社群端的好消息是 Fedora 43 Asahi Remix 已經有 M3 的 KDE Plasma 工作版本，r/AsahiLinux 上有實機開箱與操作示範。安裝方式仍是 fedora-asahi-remix 官方腳本，安裝前若要裝 macOS 27 beta，請務必先跑 asahi-fix27 工具保留開機選項。
m1n1 1.6.0：Stage 2 全面 Rust 化，GPU 初始化內移
m1n1 是 Asahi Linux 自家的硬體引導載入器，這次釋出的 1.6.0 是分水嶺版本：Stage 2 建置首次要求 Rust 工具鏈。
團隊解釋這個決定的來龍去脈。Stage 1 m1n1 在蘋果的開機工具鏈中扮演 XNU 核心的角色，只負責掛載 EFI 系統磁區並 chainload Stage 2 m1n1。團隊後來決定把 GPU 初始化工作從核心驅動搬到 m1n1，這樣能避免驅動處理蘋果硬體初始化資料中的浮點數，也大幅簡化 Devicetree 綁定。未來送進 Linux 主線的 GPU 驅動會依賴 m1n1 來做這部分初始化，蘋果的 Device Tree 解析程式碼也整個 porting 到 Rust — 它幾乎被 m1n1 的所有其他部分消費。
由於 m1n1 本質上就是韌體，效能與可預測性比什麼都重要，Rust 的記憶體安全保證在這個層級的程式碼中價值特別高。1.6.0 同時帶來 M3 系列的 SPMI 控制器支援、PCIe 初始化，並透過 kisd 把 SoC 的硬體 UART 通道直接 tunnel 到 DebugUSB。團隊也在為 M4 和 A18 Pro（也就是傳聞中的 MacBook Neo）預先鋪墊，包括更完善的「非 macOS 開機模式」處理與蘋果 Device Tree 中新發現的電源域 metadata。
AVD 影片解碼：自寫韌體繞過蘋果的依賴陷阱
最技術性的一段是蘋果 AVD（Apple Video Decoder）的逆向工程。AVD 的硬體本質上是一顆 ARM Cortex-M3 加上多組固定功能解碼單元，支援 AVC（H.264）、HEVC（H.265）、VP9，新一點的 SoC 還支援 AV1。CM3 跑的是蘋果自己寫的韌體，XNU 透過介面指向視訊資料，再由韌體驅動硬體解碼。
麻煩的是，蘋果把 AVD 韌體與一整包設定資料塞在 AVD kext 內部，而且每個 SoC 都有稍微不同的 AVD 變體。Asahi Installer 必須持續追蹤蘋果更新 kext 偏移的變動，長期來看不永續。
團隊的反擊策略很精彩：既然 XNU 載入的韌體根本沒被 CM3 驗證，那他們就自己寫一支韌體。asahi 團隊用 QEMU 模擬 AVD 韌體逐指令分析，搭配 Jamie、R、Eileen 多年累積的逆向工程成果，搞清楚底層硬體的期望介面。新進貢獻者 sofus 寫了一支自製 AVD 韌體，只安裝中斷處理器並套用各變體的 tunables，就寫出能跑的 V4L2 驅動。
硬體可解碼 10-bit AVC 編碼、最高 4K 影片，跟實作了 V4L2 Request API 的軟體配合良好。把韌體保持簡單無狀態、讓使用者空間與核心負責解析視訊資料並編程解碼器，未來能更容易支援 VA-API、Vulkan Video 等其他視訊加速 API。
VP9、HEVC、AV1 的支援還沒寫好，部分 SoC 的特殊行為也要繼續測試，距離實際發給使用者還有距離，但這條技術路線已經被驗證可行。
參考資料：
網友熱門留言 (3)