読者です 読者をやめる 読者になる 読者になる

Converg.

ものづくり関係の備忘録

【EDK II】EDK IIの基礎

UEFIの学習,EDKIIによるModule開発を目的として,EDK ||に関する基礎知識などをまとめていきます。内容は随時追加,構成は変更される場合があります。
備忘録としてここに書き留めます。(随時更新,まとまったらGitBookなどに移動予定)

Module,Package,そしてPlatform

Module

Moduleは,最小のコンパイル可能なコードやプレビルドされたバイナリです。
Moduleはソースコードかバイナリのメタデータ(INF)ファイルを含んでいます。
INFファイルは,Moduleがどんなライブラリクラス,Ppi
GUIDs,Protocols,Pcdsなどの情報を記述するためにビルドシステムに必要となります。

例えば,$WORKSPACE/MdeModulePkg/Universal/Bus/Pci/UhciDxeが,
上述したソースファイルとINFファイルがModuleを構成します。

INFファイルのシンタックスは「EDK II Extended INF Specification」を参照してください。

Package

Packageは0以上のModuleのグループです。
PackageはDECファイルやDSCファイルを含んでいなければなりません。

機能上は,Packageはプロジェクトを論理分割したものです。
Moduleをどこに置くべきか決めるためには,開発者はライセンスやスペックコンプライアンスなどの合理的な判断に依存します。
これらのメタデータファイルやModuleのINFファイルは,
ビルドシステムがオプションに基づいて自動的にMakefileや単一のModuleチップか全体のflashチップを生成します。
DSC,DECファイルのシンタックスについては「EDK II DSC File Specification」や「EDK || DEC File Specification」を参照してください。

Platform

PlatformはPackageにメタファイルを追加した,Packageの特殊なタイプ(呼称)です。
Packageは1つのDSCファイルと,0か1個のFDFファイルを含んでいる必要があります。Flashのアウトプットが欲しい時だけ,FDFファイルを用意する必要があります。

FDFファイルに関しては「EDK || FDF File Specification」を参照してください。

PlatformをEDKからEDK ||への移植方法については「EDK || Platform Port Guide」を参照ください。

Moduleのカスタマイズ

「EDK II User Manual」を使って,Library class/Library instanceとPCDメカニズムの設計目的を理解してください。これらのメカニズムは開発者に対して,ソースコードを変更せずにモジュールをカスタマイズすることを可能にしています。

Library クラス/インスタンス

パフォーマンズやイメージサイズ,Moduleタイプの制限などの要求次第で,開発者は適切なLibraryインスタンスを選ぶことになります。

$WORKSPACE/MdePkg/のcore Packageには,多くのライブラリクラスとそれに対応したインスタンスがあります。
これらのLibraryクラスによって提供されるヘルパー関数のAPIに関する基礎的な情報は,$WORKSPACE/MdePkg/include/libraryディレクトリを参照してください。

PCD

開発者はModuleの外から情報を展開したり,Moduleの中の手続きをコントロールすることに対して,PCDメカニズムは利点があります。
その情報はDSCやDECファイルをコンパイル際に取得できるかもしれませんが,いくつかのファイルはFlashイメージ作成にできたり,実行時に決定されたりするものです。


EDK II 開発のライフサイクル

EDK IIの開発サイクルは,次の4つのフェーズに分割されます。

Phase 1:Packageの作成

PackageはModuleのコンテナです。
開発者はまず最初に,どこにModuleを置くか考えるべきです。
原則としては,IHV/IBVにより新しく開発されるModuleはEDK II core Packageの中に置くべきではありません(例えばMdePkg,MdeModulePkg,IntelFrameworkPkg,IntelFrameWorkModulePkg)。
その一つの理由は,それらのPackageはModule/Platform開発を促進するベースサポート用に作られたものだからです。これらのPackageはBSD licenseなので開発したModuleをオープンソースにするつもりがないなら,core packageの中に入れるべきではありません。

新たなPackageを作るために,開発者はPackageのインターフェースを定義するためにDECファイルを作成する必要があります。インターフェースには下記を含みます。

・他のPackageからのModuleのためのディレクト
・GUIDの値
・Protocol GUIDの値
PPI GUIDの値
・このPackageによりできるPCDエントリの宣言

Phase 2:メタデータと基本的な機能の実装

Packageの中に置くModuleを決めた後,開発者はModuleの動作を示すINFファイルを作成しなければなりません。それは下記のものを含みます。

・Moduleタイプ
・必要なLibraryクラス
・必要なPPI,PROTOCOL,GUID,PCD
・他のModuleとの依存関係(Moduleタイプによりあったりなかったり)

ModuleのINFファイルを見ることで,あまり知らないModuleについて手軽に概要を知ることができます。
INFファイルを作成後,開発者は基本的な機能を実装すべくソースコードを書き始めましょう。

$WORKSPACE/MdePkg/Include/Libraryディレクトリ以下に,
サポート関数を提供する多くのライブラリがあります。また,種々のModuleタイプのための,エントリポイントのライブラリがあります。詳細はヘッダーファイルに書いてあるので是非参照してください。

Phase 3:ビルドのためのDSCファイルの作成

EDK IIでは,DSCファイルがPackageのビルド動作を記述します。それには下記が含まれます。

・ビルドに必要なModule
・種々のModuleタイプのためのLibraryインスタンスの選択
・Moduleによって使用されるPCDエントリの構成

単一PlatformのDSCや各々参照される別PackageのDECファイルが,Packageを定義します。
Package内のすべてのModuleをビルドするために,これらのファイルやModuleのINFファイルが必要です。

Phase 4:Moduleのチューニング

Moduleをチューニングするために下記のものを使用してください。

・コードをリユースするために,EDK II ライブラリ
・configurationのために,EDK II PCDメカニズム

EDK ModuleとEDK II Moduleの違いは,EDK II Moduleが必要であれば静的にも動的にもカスタマイズ可能であることです。

・Static Customizationは,ライブラリインスタンスを選んだり,ビルド時にPCDのFeatureFlagやFixed Typeを決めることが好まれます。
・Dynamic Customizationは,急いで動作をコントロールするためにパッチ可能/動的なPCDを使うことが好まれます。

EDK II Module開発者は,開発のできるだけ早い段階でどんなロジックがModuleの中に生成されるのか熟慮するべきです。例えば,もしなんらかの機能がcore Packageのライブラリクラス内ですでに実装された場合,開発者はその既存のライブラリクラスを使うべきです。

Build Infrastructure

EDK IIビルドシステムは,クロスプラットフォームでビルドできるようにするため,PythonとPortable Cコードに基づいています。
EDK II ビルドツールがメタデータ(DSC,DEC,INFファイル)を構文解析し,それに対応する一つのTop-level Makefile・Module毎のMakefile・Module毎のAutogen.c,Autogen.hが生成されます。

自動生成されるファイル内で,EDK IIビルドツールはModuleで使用される全てのGUIDs,Protocols,PPIs,PCDsを生成します。そして,Moduleのエントリポイント実装時に,使用されるライブラリインスタンスのすべてのconstructorsを呼びます。