Armシステムの開発の容易化する「SystemReady」 - Arm DevSummit 2020

日本時間で10月7日の午前0時より、「Arm DevSummit 2020」がスタートした。もともとTechConからDevSummitへの切り替えは2019年のうちに発表になっていたが、今年はCOVID-19の影響もあり完全オンラインに切り替わっての開催である。

初日の目玉はArm CEOのSimon Segars氏(中央)とNVIDIA CEOのJensen Huang氏(右)による「A Fireside Chat」(Photo01)であるが、ただ蓋を開けてみたらあまり新しい話はなかったので、こちらはまた別に触れるとして、そのSimon Segars氏の基調講演の中で出てきた「Arm SystemReady」(Photo02,03)を取り上げたい。

Photo01:司会進行は左のRene Haas氏(President, IP Products Group)。それはいいのだが、Fireside Chatというからには、仮想背景でいいから暖炉を用意してほしかった
Photo02:「クラウドからエンドポイントまでのデバイスを、ソフトウェアのサポートを含めて迅速に行うための新しいプラットフォーム」
Photo03:「最大のメリットは(SystemReadyに準拠したハードウェア構成にすることで)既存のソフトウェアがすぐに動くようになる」

同氏の講演では詳しい説明はなされなかったが、続くMark Hambleton氏(VP, Open Source Software)の基調講演である「The Software Side of Arm」でもう少し細かい説明が出てきた(Photo04)。

Photo04:SystemReadyで定義される6種類のCertification。上の4つは排他(どれか1つ)だが、下の2つはオプションである。だから、例えばSystemReady ESとSecurity Option、Pre-siliconの3つのロゴが掲載されるものもあり得る

ただ、実はHambleton氏の説明よりも、NXPの「Leveraging the Arm Ecosystem for Edge Processing」というセッションの方が判りやすかった(Photo05)ので、こちらの資料を基にちょっと説明したい。

Photo05:別にArmで“PCを作りたいわけでなく”、Armで“PC風に簡単にシステムを構築したい”というのがSystemReadyの動機である

例えばx86をベースにしたマシンの場合、それがIntelのCPUかAMDのCPUか、とかどこのメーカーのマザーボードか、はあまり考えずにWindows 10なりLinuxのディストリビューション各種なりをインストールできるし、なんならサーバー向けOSでもインストールできる。これはOSのインストーラがそれぞれの構成にあわせて最適なものを自動でインストールする……訳ではなく、要するにx86であればUEFIだったりACPIだったりといった、ハードウェアの差異を吸収して同一のAPIでハードウェアにアクセスするための仕組みが整っており、なのでOSはUEFIなりACPIにアクセスするという形でインプリメントされているから問題が起きないという話なだけである。

ところがArmの場合、こうした共通のAPI層にあたるものが存在しない。これがCortex-MだとCMSISがあって、これである程度の互換性は保てている(ミドルウェアとかRTOSの動作にはCMSISがあれば十分)訳だが、Cortex-Aにはこれにあたるものが存在しない。

厳密に言えば2014年にSBSA(Server Base System Architecture)が発表され、これを利用することでいくつかのOSが比較的スムーズに移植作業が行われる様になったとはいえ、まだx86の域には遠い。

これをもっと改善して、本当に移植作業無しでOSとかミドルウェアが動くような環境を整えよう、というのが今回のSystemReadyとなる。

SystemReadyはPhoto06の様に6種類からなる。基本になるのがBSA(Base System Architecture)で、これはArm-v8AのCPUをベースにしたシステムの共通的なハードウェアを規定すると共に、これをアクセスするための標準的な技法(ClockとかInterrupt、Memory/MMU、Power COntrol、PCIe Device、etc……)を定めている。これに追補の形で提供されるのが先ほども話が出てきたSBSAで、これはサーバー向けの拡張仕様という扱いだ。

Photo06:SBSAも引き続き使われる、というかSystemReadyの要素の1つになった。それはともかくBBR recipeにESBBRが無いのがなぞ。多分SystemReady ESはESBBRになる筈である

もう1つはBBR(Base Boot Requirements)で、この中でACPIとかUEFIといった、システムのブートに必要な要素を定義している。このBBRには「recipe」という、用途に応じた要件分けが行われており、要件に応じてSBBR/ESBBR/EBBR/LBBRの4種類が定められている。

実はArm的には、まずこのSystemReady SRを立ち上げたかったのだろう。現時点でSystemReady SRは、「Windows Server」「Windows 10」「Red Hat Enterprise Linux (RHEL)」「Amazon Linux」「Oracle Linux」をサポートするほか、「VMware ESXi」「SUSE Linux Enterprise Server (SLES)」「CentOS」「Ubuntu」「Kylin OS」「NetBSD」「FreeBSD」もやはりSystemReady SRの環境で動作するとしている。

Photo06の下の2つは全体に対するオプションである。Security Optionは、UEFI Secure BootとFirmwareのUpdateをカバーする仕様で、Pre-siliconは実際にSoCを製造する「前に」シミュレータなどで動作の検証が完了している事を示す。

このSystemReadyを利用することで、

SoCベンダー:製品のターゲットに応じてBSAおよびBBRをインプリメントし、Certificationを取得することで、OSの移植とか動作確認などの作業から解放されることになる。
エンドユーザー:Certified製品を購入してシステムを組めば、そのままOSをすぐにインストールして利用できる。あるいはCertifiedな開発ボードをそのまま突っ込んで、丁度x86で言う所のWhitebox Server的に利用することも可能になる。
Arm:Certificationによる収入が期待できるし、より広範にArmベースSoCをサーバーマーケットに使ってもらえる

という、全員がWin-Winとなる関係が期待できるという話だ。実際NXPはすでにこのSystemReady-SRに基づく製品として同社のLX2160AにSBBRとSBSAの対応を行ったが、作業は非常に簡単だったとのことだった(Photo07)。