　さて、今回取り上げたいのはこのSystemReadyである。Arm DevSummit 2020ではまとまったスライドがなくてちょっと困っていたのだが、ちょうど2020年12月1～3日に開催された「OSFC（Open Source Firmware Conference） 2020」でArmが行った発表のスライドが適切なので、以後こちらをベースにご紹介する。

　もともとArmは2018年に、「Arm ServerReady」と呼ばれるプログラムを立ち上げていた（図7）。Armはサーバ市場に参入するに当たり、何かしらの標準的な仕組みなしで参入するのは難しかろうということで2014年にSBSA（Server Base System Architecture）を立ち上げており、以後これは順調に改定されていっているのだが、SBSAだけではまだいろいろと足りないということで、ファームウェアや認証までパッケージにしたのが2018年発表のServerReadyになる。

図7　2018年というのは、「Cortex-A72／A75」のベースとなる「Cosmos Platform」をリリースしたタイミングであり、翌年の2019年に投入される「Neoverse-N1/E1」に向けて環境を整えたのだと、今だと理解できる（クリックで拡大）

　これをもう少し汎用的というか、サーバ以外にも適用できるように範囲を広げたのがSystemReadyだ（図8）。

図8　SBSAやSBBRそのものは引き続きサーバ向けに利用されるが、非サーバ向けにBSA／BBRを新たに追加した形。ACSに関しては今後また変わっていく模様だ（クリックで拡大）

　ただ“汎用的”といっても、サーバとエッジでは当然要求から何から何まで異なるわけで、そこでSystemReadyでは図9に示す6レベルの標準を示した。

図9　実質的には4レベルとなる。先に少し書いた「Raspberry Pi 4 Model B」は「SystemReady IR」かと思ったのだが実は「SystemReady ES」で認証を取得していた（クリックで拡大）

　ここで上の4つは比較的分かりやすい。「SystemReady SR」は、従来ServerReadyとして扱われていたものそのものである。「SystemReady LS」は、対応するOSをLinuxに限ったもので、BBRの対応がLBBR（Linux BBR）になる以外はSystemReady SRと同じ。「SystemReady ES」はSBSAへの対応は不要であるが、BBRの対応はSystemReady SR同様にSBBRとなる。最後が「SystemReady IR」で、これはIoT（モノのインターネット）デバイス向けのもの。BSAとEBBRへの対応が義務付けられている。

　残りの2つのうち「Pre-Silicon」はシリコンパートナーに対して提供するものになる。テープアウトの前にそのIPがコンプライアンス試験に合格していることを認証することで、半導体製造後の検証を容易にするというか、IPの選択に当たって「このIPを利用するとSystemReadyが取得できます」とアピールできることになる形だ。最後の「Security」であるが、これはBBSR（Base Boot Security Specification）への対応であって、UEFIのセキュアブートやセキュアファームウェアアップデートなどをサポートすることでこれに準拠できるようになる。

→次ページマイクロソフトが協力、ラズパイ4などが「SystemReady」の認証を取得