オープンソースファームウェアが一般向けAMDデスクトップ基板で起動

あるファームウェア専門のコンサルティング会社が、実際に購入できる普通のデスクトップマザーボードで、オープンソースの起動スタックを動かしました。3mdebは、MSI PRO B850P向けのCorebootとAMD openSILの移植版バージョン0.9.0を2026年7月30日に公開し、Phoronixは今回、そのハンズオン検証を公開しました。このボードは、このスタックを動かす初のコンシューマー向けAM5デスクトップシステムです。3mdebは、今年の初めにEPYCサーバー向け基板で同じことをすでに行っています。

すべてのPCマザーボードは、OSが引き継ぐ前にファームウェアを実行します。このAMD基板では、通常この役目はAGESA、つまりAMDのクローズドソースの初期化コードが担い、それを基板メーカーが書いたUEFIファームウェアが包んでいます。どちらも、AMDとMSI以外の誰も中身を確認できないコードです。

クローズドなコードを何が置き換えるのか

openSILは、シリコンの初期化、つまりチップのメモリやI/Oを動作可能な状態にする低レベルの作業を担う、AMD自身のオープンソースライブラリです。Corebootは、UEFIの残りの仕事を置き換えるオープンソースのファームウェアプロジェクトです。この二つを合わせて、AGESAとMSI純正のUEFIファームウェアを置き換えます。

3mdebはその結果をこう述べています。純正ファームウェアと比べて、クローズドソースのファームウェアコードを79.1%削減したというものです。これは、このボードがプロプライエタリなコードをゼロで動いているという意味ではありません。AMDのfTPM 2.0セキュリティモジュールは今もチップ自体の上で動いており、3mdebによれば、チューニングの選択肢はいまもAPCBとPlatform Security Processorに依存しており、どちらも一部はクローズドのままです。

今日時点で動くもの

この移植版が対応するのは、今のところRyzen 8000シリーズ「Phoenix」のみです。PhoronixはRyzen 7 8700G（8コア16スレッド）でテストし、システムがUbuntu 26.04 LTSとWindows 11 25H2の両方で起動することを確認しました。コールドブート時のメモリトレーニング、つまり起動時にDDR5のタイミングを調整する処理には、30秒から60秒かかります。

この基板は、UEFI Secure Boot、ROM Armor 3の書き込み保護、TCG OPALによるディスク暗号化に対応しています。グラフィックスを動かすには実際のエンジニアリングが必要でした。3mdebの2026年6月3日の以前の投稿によれば、I/O拡張チップセットを動かすだけでも、openSILに約6,400行、Corebootに約2,000行の新しいコードが必要でした。グラフィックス初期化には、それに加えてさらに約2,000行が必要でした。

残っている粗さ

Phoronixの検証では、これから試す人が想定しておくべき四つの問題が見つかりました。

問題	影響
UEFIカプセルアップデート	リセットを越えて保持されない
S5電源状態	復元が機能しない
シリアルコンソール	ときどりハングする
WiFiカード	PCIデバイス一覧から間欠的に消える

Ryzen 9000シリーズはまだ対応していません。Linux自体のamdgpuグラフィックスドライバは、この環境ではまだハードフォルトを起こします。3mdeb自身によるグラフィックス作業の説明では、画面を出して起動するにはnomodesetの回避策が必要だとされています。

誤解しやすい点

これは無料配布ではありません。3mdebは、完成したファームウェアを「Dasharo Pro Package」として自社の店舗で販売しています。openSILとCoreboot自体はオープンソースですが、この特定の基板向けに組み立て、テストし、サポートするのは3mdebの商用製品です。

開発者にとっての意味

実際のデスクトップハードウェアで、検証可能なオープンなファームウェアスタックが欲しいなら、これは主流のAM5基板がこれまでで最も近づいた例です。同時に、これは自分で組み立てるプロジェクトではなく、今日購入できる有償製品でもあります。まず、既知の問題一覧を自分の用途と照らし合わせてください。WiFiカードが間欠的に消えることは、ある構成では致命的でも、別の構成では無関係かもしれません。

ファームウェアの透明性とCPUレベルのセキュリティは、今年AMDのハードウェアで共に活発な分野でした。当サイトは2日前に、Zen 6がLinuxの投機的実行に対する緩和策の一つを不要にしたことを取り上げています。オープンなファームウェアスタックは、そうしたチップレベルの保護の代わりにはなりませんが、OSが読み込まれる前に何が動いているかを検証できるようにはします。

自分でファームウェアを作ったり検証したりしているなら、ここに出てくる具体的な数字が現実的な目安になります。一つのチップセットのI/O立ち上げだけで6,400行というのは、Corebootを新しいコンシューマー基板に移植する実際の労力を示しています。オープンファームウェアの取り組みは、ときに趣味プロジェクト程度の規模だと見られがちですが、これはそうではありません。