Asahi Linux 7.1 進捗レポート

 (asahilinux.org)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Linux 7.1時点で、Asahi LinuxではM3対応の拡大、macOS 27ベータ互換性、AVDビデオデコード、m1n1 1.6.0の変更が同時進行している
  • macOS 27 Golden Gateデベロッパーベータでは、Asahiの起動項目がStartup Diskとブートピッカーから消えたが、パーティションとデータは残っており、APFS起動フラグの設定で復旧可能
  • SMCファームウェアの変更によりバッテリー管理の戻り値が変わり、特定条件で緊急シャットダウンが発生したが、downstreamカーネル 7.0.12以降は両方のfirmware ABIを処理する
  • M3系では、オーディオ、CPU周波数切り替え、big.LITTLEスケジューリング、SMCセンサー、PCIe、WiFi、Bluetooth、NVMe、キーボード、トラックパッドがLinuxで動作するが、まだAsahi Installer対応の段階ではない
  • AVDはAppleファームウェアの代わりに独自ファームウェアとV4L2ドライバーでAVCハードウェアデコードに向けて前進しており、m1n1 1.6.0はstage 2ビルドにRustを要求するため、ディストリビューションへの影響が大きい

macOS 27で消えたAsahi起動項目

  • Macで電源ボタン長押しで開くブートピッカーやStartup Diskアプリに表示されるAsahi項目は、実際のOSパーティションではない
  • AppleのブートツールはAPFSコンテナ内の「有効なmacOSインストール」しか扱えないため、Asahi Installerは2.5GBのAPFSコンテナを作成し、m1n1をカーネルのように入れた最小macOS構成を使っている
  • この方式はmacOS 12からmacOS 26まで変更なしで動作し、Appleは実際のXNUカーネルではないraw binaryを起動したときだけ現れていたツールのバグも一部修正した
  • macOS 27 Golden Gateデベロッパーベータ以降、一部ユーザーはStartup DiskとブートピッカーからAsahi項目が消える問題を経験した
    • diskutilで確認したところ、Asahi関連のパーティションはディスク上に残っており、データ損失はなかった
    • 同じマシンでmacOS 26のブートツールを使うと、Asahiは引き続き起動できた
  • macOS Installerは再起動前にAPFSメタデータを設定しており、追加調査の結果、この値はボリュームを起動可能として示すフラグだった
    • macOS 27以前のブートツールはこのフラグを無視していた
    • AsahiのAPFSコンテナにフラグを手動設定すると、macOS 27のブートピッカーに再び表示される
  • 新しいAsahiインストールでは、Asahi Installerがこのフラグを自動設定する
  • 既存インストールを修正するためのインストールモードも追加された
    • macOS 27デベロッパーベータをインストールしたあとAsahiにアクセスできない場合は、installerを再実行して「Fix macOS 27 boot picker compatibility」オプションを使う必要がある
  • Linuxから問題を修正するプログラムも作られたが、自動配布前にさらに多くのテストデータが必要
    • テストするには、macOS 27へアップグレードする前に asahi-fix27 リポジトリをcloneし、Linuxでビルド・実行する
    • その後macOSでAsahiボリュームを起動対象として選択できれば、動作したことになる
    • 結果や問題はAsahiの community channels で共有すればよい

SMCファームウェア変更とバッテリードライバーの緊急シャットダウン

  • macOS 27には、SMCを含むglobal firmwareを使うすべての周辺機器のファームウェア更新が含まれる
  • SMCはバッテリー管理を担当し、Linuxのpower supplyドライバーはSMCと通信して充電状態、電圧、放電完了までの残り時間、バッテリー状態の情報を取得する
  • 同じドライバーは、バッテリー寿命を延ばすためにSMCファームウェアインターフェース経由で充電開始・停止しきい値も設定する
  • macOS 27のSMCファームウェアは、あるバッテリー管理インターフェースの戻り値を32ビット整数から1バイトへ変更した
  • この変更により、Asahiドライバーが特定条件でバッテリー故障と判断し、システム保護のため緊急シャットダウンを開始していた
  • downstreamカーネルにはすでにパッチが適用されており、7.0.12以降はpower supplyドライバーが両方のfirmware ABIを処理する

デベロッパーベータ導入への警告

  • macOS 27で発生した2つの問題は、デベロッパーベータが実際にデベロッパーベータであることを示している
  • デベロッパーベータを本番マシンにインストールすることは推奨されない
  • これまでに起きた2つの問題は運よく小さな問題だったが、今後の問題もすべて小さいという保証はない
  • global firmwareの更新は事実上恒久的であり、元に戻すにはマシンをDFU restoreする必要がある
  • Asahi側はテスト用の犠牲マシンを使っているため、ユーザーが高価なハードウェアや重要データを危険にさらす必要はないと考えている

M3系対応の進展

  • コンピュータプラットフォームとICの設計・検証はコストと時間がかかるため、不必要な既存設計変更は合理的ではない
  • Asahiプロジェクトは、AppleがプラットフォームやICで継続的に互換性を壊す変更を入れないという前提に依拠しており、GPUのように世代ごとに変わりやすい大きなSoCブロックを除けば、おおむねその通りだった

  • オーディオ出力

    • Apple SiliconノートPCのオーディオは複数のICとSoCブロックを使用する
    • オーディオICの事実上の業界標準は、オーディオデータ向けに最適化されたI2CベースのバスであるI2S
    • AppleのI2Sコントローラーと安定したクロックソースであるApple NCOはM1以降変わっていない
    • AppleはほぼすべてのApple Siliconマシンで同じスピーカー・ヘッドセットアンプチップを使用している
    • M3マシンにスピーカーとヘッドホンジャック対応を追加する際に必要だった作業は、主に小規模なDevicetree追加とasahi-audio、speakersafetyd設定ファイルだった
    • M3マシンはAsahi Linuxで高品質なオーディオ出力をサポートする

  • CPU周波数とbig.LITTLEスケジューリング

    • M3マシンはCPU周波数切り替えと適切なbig.LITTLEタスクスケジューリングにも対応した
    • AppleはベースM2以降、CPU周波数切り替え方式を変更していない
    • M3、M3 Pro、M3 Max、M3 Ultra SoCは、既存のcpufreqドライバーに対するDevicetree変更だけで動作する
    • タスクは要件に応じて効率コアまたは性能コアへより賢く配置され、CPUコアは負荷に応じてクロックを上げ下げする
    • この変更は省エネルギーと性能向上の両方をもたらす

  • センサーと主要デバイス

    • SMCファームウェアはマシン間で大きな差がないため、SMCハードウェアセンサー対応にもいくつかのDevicetree変更しか必要なかった
    • M3系マシンでは、PCIe、WiFi、Bluetooth、NVMe、キーボード、トラックパッド、そのほかの主要SoCブロック用ドライバーもLinuxで動作する
    • この作業のかなりの部分は、M3系マシンでm1n1とLinuxを扱ってきた Yureka が担当した
    • Asahi Installer対応をM3マシンで有効化するにはまだ作業が必要だが、進捗は速い

AVDビデオデコードと独自ファームウェア

  • Apple Siliconプラットフォームの複雑なハードウェアの多くは、複雑なファームウェアblobを使用している
  • 多くのファームウェアは、Appleがカーネルと複数のハードウェアブロックの間におおむね標準化されたインターフェースを提供するために使っているRTOS風フレームワーク RTKit ベースで動作する
  • DCPやAOPのような一部ブロックは、RTKit上にEPICという追加抽象化を載せている
  • BroadcomのWiFi/Bluetoothチップセットのように、Appleが直接制御していないサードパーティ製ファームウェアを使う場合もある
  • Apple Video Decoder、すなわちAVDは、RTKitでもEPICでもない別系統のファームウェア構造を使っている

  • AVD構造と従来方式の問題

    • AVDハードウェアは、AVC(H.264)、HEVC(H.265)、VP9、最新SoCではAV1のビデオフレームをデコードする固定機能ハードウェアユニットを制御するARM Cortex-M3に近い
    • Cortex-M3はXNUがビデオデータを指し示すためのインターフェースを提供し、実際のデコーダーハードウェアを設定するファームウェアblobを実行する
    • AppleはAVDファームウェアと設定データをAVD kext内部にまとめて格納している
    • SoCごとに少しずつ異なるAVDバリアントを使うため、Asahi Installerがkext内のファームウェアデータオフセット変更を追跡して更新し続けなければならないという運用上の問題が生じる

  • 独自ファームウェアのアプローチ

    • XNUが読み込むAVDファームウェアはCortex-M3上で検証されない
    • 信号を受けるとreset vectorから実行されるため、実際に入っているコードが何であっても実行される
    • ファームウェアの役割は基本的にビデオデコーダーハードウェアを抽象化することなので、各ハードウェアブロックの割り込みハンドラーさえ設置すれば、Linuxドライバー側から直接プログラミングできる
    • 標準的なCortex-M3コードなので、AVDファームウェアはエミュレーター上で実行できる
    • QEMUは単一ステップ実行とバス・レジスター操作の検査をサポートする
    • Jamie、R、Eileenは過去の共同作業で、AVCとVP9デコーダーに必要なコマンドとデータ形式をリバースエンジニアリングしていた
    • XNU kextはAVD revisionごとに固有のtunableも適用する
    • これらの値が正確に何をするのかは完全には分かっていない
    • 適用はXNUのMMIO write再生に近い
    • 各AVD revision、tunable集合、適用対象revisionを追跡する必要がある
    • upstream Linuxカーネルドライバーで満足に保守するのは難しく、この部分もファームウェアに置くのが適切

  • V4L2 AVCドライバー

    • 新しいコントリビューター sofus は、割り込みハンドラーを設置し、各バリアントのtunableを適用する基本的なcustom AVD firmwareを作成した
    • これを土台に、AVCハードウェア向けに動作するV4L2ドライバーを書いた
    • ハードウェアは10-bit AVCエンコード動画を最大4Kまでデコードできる
    • V4L2 Request APIを実装したソフトウェアとうまく動作する
    • ファームウェアを単純でステートレスな形に保ち、userspaceとカーネルがビデオデータ解析とデコーダープログラミングを担当するようにすれば、将来的にVA-APIやVulkan Videoなど他の動画アクセラレーションAPI対応も容易になる
    • ユーザー向けにAVD対応を提供するにはまだ作業が残っている
    • AVDはVP9、HEVC、一部SoCのAV1にも対応するが、まだ実装されていない
    • 一部デバイスのquirksもテストしてドライバーに反映する必要がある
    • 配布可能な形はそれほど遠くない時期を目標にしている

m1n1 1.6.0 リリース

  • m1n1 1.6.0がタグ付けされ、ディストリビューションの観点では影響の大きいリリースとなった
  • このバージョンはstage 2ビルドに初めてRustを要求する
  • 以前はchainloading対応を入れてビルドするときのみRustを使用していた
  • stage 1 m1n1はAppleのブートツールでXNUカーネルの代わりとなり、EFI System Partitionをマウントして、そこからstage 2 m1n1をchainloadするためだけに使われる
  • GPU初期化をm1n1へ移すことにより、カーネルドライバーがAppleハードウェア初期化データ内の浮動小数点値を扱う必要がなくなり、Devicetree bindingも大幅に単純化される
  • 将来Linux Kernel Mailing Listへ提出されるGPUドライバー版は、m1n1がこの初期化を行う前提に依存する
  • Apple Device Tree解析コードもRustへ移植され、m1n1のほぼすべての他の部分で使われている

  • ビルドとターゲット

    • m1n1は事実上ファームウェアなので、no_std Rustを使用し、aarch64-none-softfloatを対象とする
    • 不要な依存関係を引き込まないためには、makeにBUILDSTD=1を渡して、完全なsoftfloatツールチェーンをインストールせずにcoreとallocをビルドできる

  • M3、M4、A18 Pro準備

    • 1.6.0にはM3系対応のための複数の改善も含まれる
    • SPMIコントローラー対応
    • PCIe初期化対応
    • kisd を介したSoCハードウェアUARTのDebugUSB直接トンネリング対応
    • DebugUSB UARTトンネリングはCentral Scrutiniserとほぼ同等の機能を提供できる
    • この作業のかなりの部分もYurekaの貢献によるもの
    • M4とA18 Pro、すなわちMacBook Neo対応のための基礎作業も進行中
    • Appleのnon-macOS boot modeをより適切に処理する
    • Apple Device Tree内の新しいpower domain metadataをサポートする

支援者とコントリビューター

  • Asahi Linuxは GitHub Sponsors と Open Collective の支援者に感謝を表している
  • 支援のおかげで、未完成のM1・M2機能、M3・M4・A18 Pro対応、新しいコントリビューター支援を継続できている

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker News のコメント

  • 「オーディオ IC の事実上の業界標準は、オーディオデータ向けに最適化された I²C ベースのバスである I²S」という表現は正確ではない。I²S は I²C とは無関係
    ほとんどの I²S チップには I²C インターフェースが付いているが、これは I²S が生のオーディオデータだけを運び、音量制御やクロック設定のような付加信号を持たないため
    ただしそれは別インターフェースであり、I²C の代わりに SPI の場合もある。実際には I²C よりも SPI の方が I²S に近い

    • その通りで、I²S は SPI にずっと近い
      両者が似た命名体系に従っている理由は、どちらも Philips Semiconductor（現在の NXP）が作ったから
    • I²S は驚くほど単純な設計。プロトコルのハンドシェイクはなく、ただ生の PCM が流れるだけ
      送信側と受信側が異なるサンプルビット深度を双方向で使っても互換性問題が出ないように設計されている点が気に入っている
      https://web.archive.org/web/20070102004400/http://www.nxp.co...

  • モチベーションの高い少数の人々がこうした問題を解いていくのは本当に驚異的

    • 多くの問題はまったく解決されていない。例えば Apple Silicon の PSCI 電源管理インターフェースはいまだ謎
      ほかの Linux デバイスツリーには PSCI コードがあるが、Apple がそれをどう実装したのかは誰も知らない。そのため Asahi ユーザーはほぼ 5 年間、バッテリーが減り続けないようにするハックに頼ってきたし、私の知る限り有望な解決策もまだない
      これがリバースエンジニアリングの光と影。このデバイスにネイティブの Vulkan 1.2 ドライバーができたのは素晴らしいが、そこに至るまで何年もかかった。Apple Silicon の登場から 7 年がたった今も未解決の問題は残っており、最新ハードウェアの大半は全般的にサポートされていない。結局、Linux ユーザーがずっと言ってきた教訓、プロプライエタリドライバーは良くないという結論に戻る

  • XNU がロードするファームウェアを CM3 が検証せず、信号が来ると実際の内容が何であれリセットベクターから実行を始めるという部分が特に気になる
    プロプライエタリで絶えず変わる対象を相手にカスタムファームウェアを書き上げた成果は言葉に尽くせないほどすごいが、Apple が今後もサードパーティ OS を意図的に壊さないことを期待するのとは別に、ファームウェア blob やランタイムにハードウェアプログラミングへ渡すデータにハードウェア署名を導入する可能性は低くなさそうに見える。Apple 側からすれば妥当なセキュリティ上の懸念かもしれない。それでもこの賭けが成功してほしい

  • これが永遠に Fedora “remix” のままなのか気になる。いつかアップストリーム対応が入って Debian ベースのディストリビューションを動かせるようになるのだろうか？
    最後に RPM ベースのディストリビューションを使ったのは、もう 20 年近く前だった気がする

    • パッチをアップストリームに送っているので、最終的にはアップストリーム Linuxに必要なドライバーが入るはず
      もちろんカーネルのフォークもオープンソースなので、Debian aarch64 ルートを持ってきて Asahi カーネルを自分でビルドするか、Fedora ビルドを持ってきて、このマシン上に Debian を自分で構成することを妨げるものはない。ただし多少手間はかかる
      Ubuntu でよければ Ubuntu Asahi もある: https://ubuntuasahi.org/
      検索してみたら、この Wiki 記事もある: https://wiki.debian.org/InstallingDebianOn/Apple/M1
    • 自分の好みは逆なので、このコメントは面白かった。私は RPM ベースのディストリビューションを好み、ほぼどこでも主に Fedora を使っている。M1 Ultra Mac Studio でも Fedora Asahi Remix を使い、クラウドインスタンスの一部でだけたまに Ubuntu と Debian を使っている
      だから、すでに慣れている特定のディストリビューションを使い続けたい気持ちは分かる。作業が少なくて済むし、構造上の微妙な違いを覚える必要も減るから。それでもやむを得ず新しいディストリビューションを使わなければならないとき、例えば Asahi が最初に Arch Linux ARM 専用で出たときのように、そこで得た小さな学びを後悔したことはない
    • Arch もまだ使えるし、Ubuntu Asahi もある
      すべてのディストリビューションがより簡単に移植できるよう、まさにそのためにアップストリーム作業を熱心に進めている
      https://ubuntuasahi.org/
    • Bananas Team が Apple Silicon で標準 Debian を動かす作業をしていて、非公式リポジトリを追加して今インストールする方法もある: https://wiki.debian.org/InstallingDebianOn/Apple/M1#The_Bana...
      まだ自分でインストールしてみてはいない
    • linux-asahi は Void Linux でも利用可能
      https://voidlinux.org/download/#arm%20platforms
      ディストリビューション内の通常の Linux パッケージ: https://github.com/void-linux/void-packages/tree/master/srcp...

  • M3 対応が順調に進んでいるのを見るとうれしい
    M3 対応追加作業を始めると最初に言及されたのは 2 月だった
    「かなり長い間、m1n1 には M3 シリーズ機器に対する基本対応が入っていた。欠けていたのは各機器ごとのデバイスツリーと、M2 から変わった M3 固有のハードウェア特性や変更点をサポートするための Linux カーネルドライバーパッチだった。既存のパッチセットがより管理しやすくなったら、この作業を具体化する意図は常にあった」
    https://asahilinux.org/2026/02/progress-report-6-19/

  • AVD ドライバーに取り組んでいるとのことで期待している

  • M1以降のMacでffmpegやVLCを使うと、AVDは使われるのだろうか？

  • Asahiは実用的な代替になり得るが、この程度の資金と小規模な人員では、開発速度がどうしても遅くならざるを得ないように見える
    記事で述べられているように、すでに築かれた基盤作業があり成果も出ているものの、結局毎年新しいチップ、多数のマイクロコントローラ、GPUの変更を含む新しいMacが出てくるため、追いつくのは不可能だ。だからAsahiチームもM1とM2モデルにより集中しているのだろう
    それでも今のところ、どちらにもアイドル時の電力管理とAlt-DP実装の問題が残っており、多くの人が移行できずにいる。この問題が洗練される頃には、デバイスの価値も大きく下がっているはずだ
    少人数でここまで成し遂げたのは奇跡だが、広範なメディア報道にもかかわらず、結局チームの情熱と意欲は薄れてきたように見え、M1 Airでさえ完成しないように思える

    • 「開発速度がどうしても遅くならざるを得ない」というより、新しいリーダーシップチームが入った際、最新ハードウェア対応の追加よりも既存作業のアップストリーム化を優先すると発表していた
      変更をカーネルにアップストリームするのに時間がかかった
      そして2月にM3への取り組みを開始したと発表しており、進捗も良さそうだ
      「上記に加えて、M3シリーズのデバイスではPCIe、WiFi、Bluetooth、NVMe、キーボード、トラックパッド、その他の主要なSoCブロックのドライバもLinux上で動作している。この作業の大半はYurekaが担当しており、彼女はしばらくの間、M3シリーズのデバイスでm1n1とLinuxの両方を非常に活発にハックしてきた。Asahi Installerでこれらのデバイスのサポートを開始するにはまだ道のりがあるが、進展は速いので注目してほしい！」
      これは破滅というより、才能ある人たちが綿密な作業を成し遂げている姿に近い
    • 数年ごとに1機種だけをターゲットにしてきちんと動くようにできるなら、代替がまったくないよりははるかに良い
      M1サポートは最近かなり実用的で、作業の少なくとも一部は将来のデバイスにも引き継がれそうだ。楽観材料ばかりではないが、失敗が決まっているプロジェクトでもない

  • Appleが小さなチームに資金を出し、ドキュメントとドライバの一部をオープンソースで公開してAsahiを支援してくれたら本当にいいのに
    もちろんそうしないことは分かっているが、夢を見ることはできる。Appleにとってははした金だろうし、そうすれば自社ハードウェアがSilicon Valleyのエンジニアたちにとって事実上の標準としてさらに定着するはずだ

    • Apple自身のHypervisor frameworkがその話にかなり近く、私はUTMアプリでFedoraとArch Linuxのビルドを動かしている。エミュレーションではなくApple Siliconの仮想化を使うように設定しており、UTMはそのフレームワークを包むラッパーだ
      非常に優秀で、数年前にAsahiを消して再フォーマットするきっかけになった
      https://developer.apple.com/documentation/hypervisor
      https://docs.getutm.app/installation/macos/

  • 最近Asahiで大規模言語モデルをどれほど活用しているのか気になる。リバースエンジニアリングには本当に強力なツールだが、それについて何か書いたことはあるのだろうか？

  • このプロジェクトの開発/CIプロセスがどのようなものなのか気になる
    結局、毎回特定のハードウェアにビルドを手動でロードする形なのだろうか、それともある程度自動化できる段階があるのだろうか？

    • m1n1はここでかなり面白いことをいろいろやっている: https://asahilinux.org/docs/sw/tethered-boot/
      実ハードウェアとカーネルの間にごく薄い層を置きつつ、ハードウェアの入出力動作には影響を与えないまま、カーネルのロードとデバッグをリモート制御・自動化できるようにしている