この記事について
- この記事はOpenBMCのFlash Layout and Filesystem Documentationを和訳したものです。
- 筆者が調査していた時(2020年10月)のREADMEを翻訳していますので、最新版は記述が変わっている場合もあると思います。
- 機械翻訳を少し手直して掲載していますが、表現を変えた方がよいというご指摘は歓迎です。編集リクエストお願いします。
翻訳元
https://github.com/openbmc/docs/blob/master/architecture/code-update/flash-layout.md
ライセンス: Apache License 2.0
OpenBMC Flash Layout and Filesystem Documentation
この説明は以下にフォーカスしています。
- flashのセットアップ方法、code updateアプリはすぐ使える状態に整えることを要求されています。
- それはLinux filesystemをどのようにセットアップするかも含みます
- filesystem layout, オーバレイ、ブートオプション、
- フラッシュモジュールが更新され、新しいイメージが起動する方法。
コード更新インターフェースの詳細については、code-update.mdを参照してください。
Design considerations
Boot loading and init
システムの初期化とブートストラップのために、Das U-Boot をブートローダーとして選択しました。
システムの基本的な初期化後、ブートローダーはプロンプトを表示したり、自動ブートを開始したりします。ブートイメージを選択するためのコマンドやデータは、ブートローダー環境(u-boot環境変数)に保存されます。ブートローダーは、圧縮されたカーネル、initrdイメージ、およびデバイスツリーをメモリにコピーしてから、制御をカーネルに移します。カーネルは、フラッシュパーティションやツリーに埋め込まれたカーネルコマンドラインなど、デバイスツリーで渡された情報を使用して、自身とシステムを初期化します。
Runtime management
ランタイム管理では、systemd システムおよびサービスマネージャーが、そのconfiguration、依存関係、堅牢なリカバリのためのトリガーされたアクションのサポートを選択します。
systemdでは、実行を開始する前に、ルートファイルシステムとすべてのバイナリをマウントする必要があります。/dev、/sys、および/procのファイルシステムは、systemdを起動する前にマウントできます。 systemdファイル階層のデバイス を参照してください。
Root filesystem
ルートファイルシステムのストレージには、read-onlyボリュームが選択されます。
これにより、すべての実行可能ファイルと静的データファイルを含むファイルシステムコンテンツの大部分をread-onlyのファイルシステムイメージに保全します。
read-onlyのファイルシステムイメージを置き換えると、コンテンツで使用されているスペースをビルド時に確認でき、変更を使用しない圧縮ファイルシステムを選択できます。
Filesystem Hierarchy Standard FHS に準拠するための努力が払われています。具体的には、現在のブートの一時的なデータは/runに格納され、ほとんどのアプリケーションのデータは/varに格納されます。一部の情報は、引き継がれるシステム構成データディレクトリ/etcに保存されます。これは主に、ネットワークアドレス、ユーザーID、sshホストキーなどの従来のconfigurationです。
フラッシュスペースを節約するために、xz圧縮を使用したsquashfsを選択して、読み取り専用のファイルシステムコンテンツを保存します。これは、eMMCではなく、接続されているフラッシュストレージが制限されているシステム（以下のJFFS2およびUBIオプションを参照）に適用されます。
ルートファイルシステムを読み込むために、initramfsはsquashfsと書き込み可能なファイルシステムを見つけてマウントし、それらをoverlayfsとマージし、結果にchrootを実行して、systemdを起動します。
または、BMCのアクティブなイメージを見つけるための情報をU-Boot環境に保存し、initスクリプトでイメージをマウントしてからsystemdを起動することもできます。
この方式選択はプラットフォームの実装によって異なります。詳細は、以下の「Supported Filesystem Choices」セクションにあります。
Supported Filesystem Choices
OpenBMCは、次のタイプのファイルシステムのcode-updateをサポートしています。
ファイルシステムがフラッシュに保存される方法、システムの起動/初期化中にファイルシステムがインスタンス化される方法、コードの更新によってファイルシステムが処理される方法など、ファイルシステムごとに追加情報が提供されます。
Writable Filesystem Options
JFFS2 on MTD partition
ファイルシステムの大部分は、ブロックエミュレーションドライバー(mtdblock) を使用して、MTDパーティションのread-only squashfsに格納されます。2番目のMTDパーティションは、JFFS2ファイルシステムを使用して読み取り/書き込みでマウントされます。このread-writeファイルシステムは、ファイルシステムスペース全体にマウントされ、すべてのファイルとディレクトリに書き込むことができます。
このファイルシステムスタックでは、マウントをinitramfsから実行する必要があります。
initramfsは、busyboxに基づく基本システムと、MTDパーティションを名前で検索する3つのカスタムスクリプト（init、shutdown、update）で構成されています。これらのスクリプトはobmc-phosphor-initfs によってインストールされます。
code-updateモードでは、read-writeファイルシステムからのsquashfsイメージとホワイトリストファイルがinitramfsによってRAMにコピーされ、ルートoverlayfsインスタンスのアセンブルに使用されます。実行時にイメージをインストールすることで、フラッシュを自由に変更できます。
正常なシャットダウンにより、残りのイメージが同じ名前の生のMTD(like-named raw MTD)パーティションに書き込まれ、ホワイトリストに登録されたファイルが書き込み可能なオーバーレイファイルシステムに書き込まれます。または、code-updateモードが選択されていない場合は、正常なシャットダウン中にパーティションがアンマウントされるまで、イメージの日付を遅らせる必要があります。
これは、OpenBMCのデフォルトのファイルシステムです。
これは、AspeedTechnologyのAST2400およびAST2500システムオンチップコントローラーをベースにしたいくつかのBMCシステムで使用されています。
これらのSOCは1GBと2GBのDDRRAMをサポートしますが、接続されているフラッシュストレージは通常数十MBであるため、ファイルシステムをRAMにステージングすることは問題ではありません。
UBI on MTD partition
ファイルシステムの大部分は、UBIブロックエミュレーションドライバー(ubiblock) を使用して、静的UBIボリュームの読み取り専用squashfsに格納されます。
ファイルの更新を保存するために、UBIFSボリュームが/varに使用され、overlayfsを使用して/etcおよび/homeディレクトリにマウントされます。
これらのマウントは、 systemdが開始される前にpreinit-mounts パッケージによってインストールされたinitスクリプトによって実行されます。
UBIを選択すると、read-writeオーバーレイへの書き込みを、read-write MTDパーティションだけでなく、UBI領域全体に分散できます。
Das U-bootの環境変数領域はは、引き続きフラッシュの固定的なセクターに保存されます。
Das U-boot環境変数には、同じフラッシュ内のUBIデバイス内のUBIボリュームを読み取るのに十分なMTDパーティション定義が格納されています。
bootcmdスクリプトは、FITイメージからカーネルをロードし、それをbootargsに渡して、ペアになっているUBIボリューム内のsquashfsを見つけてマウントします。
このオプションは、「obmc-ubi-fs」OpenBMCディストリビューション機能を介して有効になります。JFFS2サブシステムと同じBMCサブシステムで使用されますが、ファイルシステムの少なくとも2つ分のコピーを格納するのに十分なフラッシュストレージがある構成を対象としています。
これは、二重化フラッシュストレージで実現できます。AST2500のコントローラーなど、一部のコントローラーでは、障害時に代替フラッシュからの起動が許可されており、このUBIオプションはこの機能をサポートしています。この機能サポートにより、各カーネルのコピーが各フラッシュに保存され、U-Boot環境が使用するカーネルを選択します。
ext4 on eMMC
This is a work in progress. See the eMMC Design Document.
Auxiliary Filesystems
tmpfs は/tmp、/runなどに使用され、/dev、/proc、および
/sys は、FHSで指定されているように、通常のカーネル特殊ファイルシステムでサポートされています。
その他
RaspberryPiおよびx86QEMUマシン用に追加のBitbakeレイヤー構成が存在しますが、主にコードの開発と調査のために提供されています。これらの環境のcode-updateはサポートされていません。