Asahi Linux 7.1 進捗レポート

/ ブログ / 進捗レポート: Linux 7.1 進捗レポート: Linux 7.1 以前のLinux 7.1が登場し、もちろんそれに伴い、別の進捗レポートが公開されました。M3の進捗、Appleのバグなどがあります！ マスターブートレコードへようこそ Macの電源ボタンを長押ししてブートピッカーを起動すると（または「起動ディスク」アプリケーションを使用すると）、Asahiとして表示されるのは、実際にはオペレーティングシステムが搭載されているパーティションではありません。Appleのブートツールは、APFSコンテナ内の「有効な」macOSインストールと見なされるものでのみ機能します。Appleのブートローダーを使用し、ユーザーがAsahiを使用するたびにリカバリからコマンドを実行する必要がないように、Asahiインストーラーは、Appleのツールがm1n1をカーネルとしてブート可能なmacOSインストールであると納得させるのに十分なmacOSのみを含む小さなAPFSコンテナ（2.5 GB）を作成します。この配置はmacOS 12からmacOS 26まで完全に変更なく機能し、Appleは実際のXNUカーネルではない生バイナリをブートしようとした場合にのみ発生するツール内のいくつかのバグも修正しました。 しかし、macOS 27 Golden Gate開発者ベータのリリース直後、マシンでLinuxを起動できなくなったという報告を受け始めました。そのオプションは「起動ディスク」からもブートピッカーからも単に消えていたのです！これは明らかにかなり懸念されることであり、そのため我々はこれを調査することを優先しました。 diskutilを使用してディスクを検査したところ、macOS 27にアップグレードした後も、Asahi関連のすべてのパーティションがディスク上に存在することが明らかになりました。データ損失は発生しておらず、これは良い兆候です。さらに、macOS 26の2番目のインストールからのブートツールを使用した場合、同じマシンでAsahiはまだブート可能でした。 chaos_princessは、Apple自身のmacOSインストーラーと、Appleのブートツールを初めて調査した頃の古いストリームを検査し始めました。macOSインストーラーは、マシンを再起動する前にいくつかのAPFSメタデータを設定しますが、さらなる調査により、それがボリュームをブート可能としてマークするフラグであることが判明しました。macOS 27までは、ブートツールはこのフラグを完全に無視していました。Asahi APFSコンテナでこのフラグを手動で設定すると、それ以上の変更なしにmacOS 27ブートピッカーで利用可能になります。 今後、すべての新しいAsahiインストールでは、Asahiインストーラーによってこのフラグが自動的に設定されます。また、既存のインストールを修正するインストーラーモードも追加しました。macOS 27開発者ベータをインストールしていて、Asahiインストールにアクセスできない場合は、インストーラーを再度実行し、「macOS 27ブートピッカー互換性を修正」オプションを使用してください。 chaos_princessは、この問題を修正するためにLinuxから実行できるプログラムも開発しました。最終的にはこの修正を自動的に展開したいと考えていますが、それが信頼性があり、誰のファイルシステムも破壊しないことを確認するために、さらに多くのテストデータが必要です。ここで皆さんの出番です。これをテストするのにご協力いただける場合は、このリポジトリをクローンし、macOS 27にアップグレードする前にLinuxからビルドして実行してください。AsahiボリュームがmacOSからブートターゲットとしてまだ選択可能であれば、成功です。OFTCまたはMatrixのいずれかのチャネルにアクセスして、特に問題が発生した場合は、どのように進んだかをお知らせください。 シャットダウンを強制する3バイト macOS 27は、SMCを含むグローバルファームウェアを備えたすべての周辺機器のファームウェアアップデートも提供します。SMCの数ある機能の1つはバッテリー管理です。私たちのLinux電源ドライバはSMCと通信して、充電状態、電圧、空になるまでの時間、バッテリーの状態などの情報を取得します。このドライバはSMCのファームウェアインターフェースを使用して、バッテリーの寿命を延ばすために充電開始および停止のしきい値を設定します。macOS 27のSMCファームウェアは、バッテリー管理インターフェースの1つを、32ビット整数を返すものから1バイトを返すものに変更しました。この変更は私たちのドライバを混乱させ、特定の条件下でバッテリーが故障したとみなし、システムを保護するために緊急シャットダウンを開始します。私たちはすでにこれをダウンストリームカーネルでパッチしており、バージョン7.0.12以降、電源ドライバは両方のファームウェアABIに対応できます。 ベータ版のインストールについて このようなバグは、開発者ベータ版が単なる開発者ベータ版であるという重要な注意喚起です。本番マシンにインストールすることは推奨されません。これまでに発生した2つの問題は幸い軽微でしたが、将来のすべての問題もそうであるとは限りません。グローバルファームウェアアップデートも実質的に永続的であり、マシンの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用のいくつかの些細なDevicetreeの追加と構成ファイル以上のものはほとんど必要ありませんでした。その結果、M3マシンはAsahi Linuxで高品質のオーディオ出力をサポートするようになりました！ M3マシンは、CPU周波数切り替えと適切なbig.LITTLEタスクスケジューリングの両方のサポートも獲得しました。Appleは、ベースM2以降、CPU周波数切り替えの仕組みを変更していません。つまり、すべてのM3およびM3 Pro/Max/Ultra SoCは、既存のcpufreqドライバで機能するためにDevicetreeの変更以外は何も必要としませんでした。タスクは、その要件に応じて、効率コアまたはパフォーマンスコアに、よりインテリジェントに配置されるようになり、CPUコア自体も負荷に基づいてクロックアップおよびクロックダウンするようになります。これにより、エネルギーを節約し、パフォーマンスを向上させることができます！ SMCのハードウェアセンサーのサポートを追加することも同様に些細なことでした。SMCのファームウェアはマシン間で実質的に違いがないため、ここでもいくつかのDevicetreeの変更以外は何も必要ありませんでした。 上記の他に、M3シリーズマシン向けに、PCIe、WiFi、Bluetooth、NVMe、キーボード、トラックパッド、およびその他の主要なSoCブロックドライバもLinuxで動作するようになりました。この作業のほとんどは、M3シリーズマシンでm1n1とLinuxの両方で忙しくハッキングしていたYurekaによるものです。これらのマシンのAsahiインストーラーサポートを有効にするまでにはまだ道のりがありますが、進歩は急速ですのでご期待ください！ 今、ファームウェアを書いていますか？ このプラットフォーム上の複雑なハードウェアのほとんどは、複雑なファームウェアブロブを使用しています。このほとんどはRTKitに基づいており、Appleがカーネルがさまざまなハードウェアと通信するためのほぼ標準化されたインターフェースを提供するために使用するRTOSライクなファームウェアフレームワークです。ただし、例外もあります。DCPやAOPのような一部のブロックは、RTKitをファームウェアの基盤として使用しますが、その上にEPICと呼ばれる別の抽象化レイヤーを重ねます。Broadcom WiFi/Bluetoothチップセットのように、Appleが直接制御できないサードパーティのファームウェアを使用するものもあります。そして、Appleビデオデコーダー（AVD）があります。 AVDは特別です。そのファームウェアはRTKitでもEPICでもなく、秘密の第三のものです。ハードウェア自体は本質的にARMです