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

Converg.

ものづくり関係の備忘録

【EDK II】 .UNI File Format

EDK II OSX UEFI

第四弾・・・。眠い。備忘録。

概要

Unicode string fileのフォーマットについての備忘録。
このファイルは,Unicodeファイル内で複数のレイアウトとフォーマットをサポートする。この多彩さが,言語または文字識別子によって,文字をグルーピングすることを可能にする。

Unicode String File Format

EDK II Unicode fileはマッピングされたトークン名に,RFC4646言語コードによって識別される文字をローカライズできる。
EDK II Unicode fileのフォーマットはUTF-16LE。文字内容はUCS-2でなければらない。

文字列の末尾は,次のうち最初に見つかったもので決定される。

・制御文字
・コメント
・ファイルの終わり
・空白行

String File内でコメントはどこにあっても良い。すべてのファイルは,Unicode BOM(Byte Order Mark)文字で始まらなければならない。
従って,編集する際は,UTF-16LEファイル内でUCS-2文字列をサポートするエディタを使用する必要がある。

Common EBNF

以下のEBNFは,UCS-2文字列リテラルを表現するため,(ダブル)クオテーションマーク文字を使用している。下記でセミコロンはコメントである。
(一部上付き文字を"^"つけて書いているので注意)

<US> ::= " "

<Letter> ::= { (\u0041-\u005A) }     ; 文字 A - Z
             { (\u0061-\u007A) }     ; 文字 a - z

<Digit> ::= (\u0030-\u0039)     ; 文字 0 - 9 

<MS> ::= <US>+

<ME> ::= {<MS>} {<EOL>}

<CommentLine> ::= "//" <US>* <PCHars> <EOL>

<BlankLine> ::= <EOL>

<Chars> ::= (\u0001-\uF6FF)

<PChars> ::= { (\u0020-\uF6FF) } {<OpChar>}

<OpChars> ::= "\x" [{<Letter>} {<Digit>}] {4} "\"

<VChars> ::= (\u0021-\uF6FF)

<UnicodeLines> ::= <Token> <Me>
                   [<Ldef> [<String> <ME>]+]+

<Ldef> ::= <CtrlChar> "language" <MS> <LangCode><ME>

<HexDigitU> ::= {<Digit>}
                { (\u0041-\u0046) }     ; 文字 A - F
                { (\u0061-\u0066) }     ; 文字 a - f

<CtrlChar> ::= <US>* "#"

<Token> ::= <CtrlChar> "string" <MS> <Identifier>

<Identifier> ::= <Letter> [{<Letter>} {<Digit>} {<UN>}]*

<LangCode> ::= <RFC4646>

<RFC4646> ::= <Letter>^(2,8) [<ShortExt> <LongExt>*]

<ShortExt> ::= "-" [{<Letter>} {<Digit>}]^(1,8)

<LongExt> ::= "-"  [{<Letter>} {<Digit>}]^(1, )

<UDblQuote> ::= \u0022     ; ダブルクオテーション文字「”」

<String> ::= <UDblQuote> <SContent>* <UDblQuote>

<SContent> ::= {<PChars>} {<Attributes>}

<Attributes> ::= "\" {"narrow"} {"wide"} {<UDbleQuote>}
                 {"n"} {"r"} {"t"} {"nbr"} {"\"} {"'"}
定義

LanguageCodes:
言語コードは有効なRFC4646言語コードでなければならない。

EscChar:
文字列中の"\"など,いくつかの標準文字列をインクルードするために,文字列はエスケープ文字を接頭辞としていなければならない。エスケープ文字を接頭辞に必要な文字は次のものを含む;バックスラッシュ「\」,クオテーションマーク「'」,ダブルクオテーションマーク「"」,スラッシュ「/」。
バックスラッシュはいつもエスケープ文字を必要とする。

Token:
トークンは数字,上付き・下付き文字,下線文字,ダッシュ文字を含む。

Include:
include行は,文字ファイル内にあった場合,この仕様に準拠した別ファイルを構文解析するのに用いられる。トークンは同じ言語のためのファイルで重複してはならない。


HII String Pack

HII String Packの作成に利用されるUnicodeファイルのフォーマット:

<StringFileFormat> ::= <CommentLine>*
                       <LanguageDefs>
                       <Content>+

次のEBNFは,HII String Pack作成に使用されるUnicodeファイルに特化した内容を記載している。

<Content> ::= {<CommentLine>} {<BlankLine>}
              {<UnicodeLines>} {<ControlRefactor>}
              {<LanguageDefs>} {<SecurityLines>}
              {<IncludeLines>}


HII String Pack作成に使用するUnicodeファイルの他の定義は下記の通り。

<LanguageDefs> ::= <CtrlChar> "langdef" <MS> <LangCode> <MS>
                   <LangDesc> <EOL>

<LangDesc> ::= <UDblQuote> <Chars> <UDblQuote>

<IncludeLines> ::= <CtrlChar> "include" <UniFile> <EOL>

<UniFile> ::= <UDblQuote> <UniFilename> <UDblQuote>

<UniFilename> ::= <FilenameChars> <MoreFNameChars>* {".uni"}

<FilenameChars> ::= {<Letter>} {<Digit>}

<MoreFNameChars> ::= {<Letter>} {<Digit>} {"_"}

<CtrlChar> ::= "/"

<ControlRefactor> ::= <CtrlChar> "=" <NewCtrlChar> <EOL>

<NewCtrlChar> ::= (0x0021 - 0xF6FF)

サンプルファイル

UEFIのUNI Spec v1.3より引用。

//
// Cpu I/O Strings
// Copyright (c) 2006, Intel Corporation. All rights reserved.<BR>
//
// This program and the accompanying materials are licensed and made
// available under the terms and conditions of the BSD License which
// accompanies this distribution. The full text of the license may
// be found at:
// http://opensource.org/licenses/bsd-license.php
//
// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
// WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
// OR IMPLIED.
//

/=#

#langdef     en-US   "English, US"
#langdef     fr-FR   "Français"

#string     STR_PROCESSOR_VERSION
#language  en-US
"NT32 Emulated Processor"
#language fr-FR 
"Processeur Émulé par NT32"


 

フォントサポート

フォントをサポートするためのEDK II Unicodeファイルの,任意の特徴とエントリをここで定義する。

Syntax:
「#fontdef」・「#font」コマンドの導入,「#string」コマンドを延長,新しいエスケープ文字を追記することで,フォントを拡張する。

Fonts:
との文字列もフォントと関連がある。フォントには,フォントフォント識別子,フォント名,サイズ,スタイルがある。デフォルトでは,文字列はフォント識別子"sysdefault"と関連づけられている。普通これは,標準的なUEFIフォントの19, normalとなっている。

文字列は,最初の #language 属性の前に #string 属性を使用することによって,異なる #font 識別子を使うことが可能になる。

特定の言語の文字列だけ異なる#font属性を使用したい場合は,#language属性の後に#font属性を使用すれば良い。

文字列内の文字も,異なるフォント識別子,フォントサイズフォントスタイルを使用することができる。そのためには,下記の \f エスケープシークエンスを利用すれば良い。これらのエスケープ文字は,EDK2 Build Specificationに記載のものを拡張することができる。

Font Control Character Description
\" ダブルクオテーションの挿入。
\\ バックスラッシュの挿入。
\br Breaking code。
\f!identifier! つぎにつづくもじのフォント識別子を選択する。
\fb 現在の文字列に続く文字を太文字スタイルに切り替える。
\fd 現在の二重下線スタイルに切り替える。現在のスタイルが下線の場合は,二重下線になる。
\fe 次に続く文字をエンボス文字に切り替える。
\fh!integer! 次に続くフォントのサイズを選択する。
\fi 現在の文字列に続く文字を,イタリック文字にする。
\fs 現在の文字列に続く文字を,影文字にする。
\fu 現在の文字列に続く文字を,下線文字にする。
\n キャリッジリターンと改行の挿入。
\narrow 次に続く文字を"狭い"文字にする。
\nbr Non-breaking code。
\r キャリッジリターンの挿入
\wide 次に続く文字を"広い"文字にする。

フォント識別子は#fontdefを使用することにより作成される。

 

#font

#stringsを使用してデフォルトフォントをセットする。

Syntax:

"#font" <MS> font-identifier

Attributes:
font-identifier
==> フォントに関連づけられたCスタイルの識別子。

 

#fontdef

フォント識別子を特定のフォントファミリー,サイズ,スタイルとかんれんづける。

Syntax:

"#fontdef" <MS> font-identifier <MS> <FontOptions> <EOL>

<FontOptions> ::= font-name <MS> font-size [<MS> font-style-list]

font-style-list ::= <UDblQuote> [fs-entries] <UDblQuote>

fs-entries ::= font-style ["|" font-style]*

font-style ::= {"bold"} {"italic"} {"underline"} {"dblunder"}
               {"shadow"} {"emboss"} {"normal"}

font-size ::= (1-9) (0-9)*

 
Attributes:
font-identifier
==> Cスタイルの識別子

font-name
==> フォントファミリー名をクオテーション文字で囲ったもの。例えば,"Arial"や"Times New Roman"など。

font-size
==> ピクセルでフォントたかさを指定するunsigned型のinteger。たとえば,UEFI標準フォントの高さは,19ピクセルなので,font-sizeは19。

font-style
==> フォントスタイルを指定する0以上のキーワード。"|"で仕切る。
仮に"normal"が使用された場合,他のどのフォントスタイルとも組み合わせられない。特に何も指定しなければ,"normal"と解釈される。

 
 

#stringの拡張

EDK II のビルドコマンドは,INFファイルの[Sources]セクションで指定された.uniファイルを構文解析する。ビルドツールは各々のModuleに対して,HII stringファイル中のシンタックスを,AutoGen.cファイル中のバイト配列変換するために,pythonオブジェクトを使用する。
バイト配列を作成するプロセスの詳細は,EDK II Build Specificationを参照すること。

Syntax:

<UnicodeLines> ::= "#string" <MS> <Identifier> <ME>
                   [<FontId>]
                   [<LangLine>]+

<LangLine> ::= "#language" <MS> lang-code <ME> <FontString>

<FontString> ::= [<FontId>] [<strings>]+

<FontId> ::= ["#font" <MS> <font-identifier> <ME>]

<strings> ::= <String> <ME>


[EDK II Specification中の#stringコマンドの拡張]:
font属性は文字列中の文字で使用されるデフォルトフォントを指定する。
もし,#fontが指定されなかった場合,デフォルトのフォント識別子が使用される。

もし,#font属性が#language識別子の前にあった場合,全ての言語にそのfont属性が適用される。
一方で,もし,#font属性が#language識別子の後にあった場合,その言語の文字列の文字にのみ,font属性が適用される。

#fontは一つ以上の箇所に書いてもいい。なお,その場合,言語のフォント識別子が優先される。
 
Description:
#fontdef コマンドはフォント識別子を導入し,それを特定のフォントファミリー,サイズ,スタイルと関連付ける。もし,すでにフォント識別子が定義されている場合は,新たな定義は無視される。

【EDK II】Module開発

EDK II UEFI 自作OS

引き続き第三弾。途中で力尽きて寝落ちすると思います。

EDK IIのModuleとは・・・?

EDK IIのModuleはソースファイルあるいはバイナリファイル,そしてModule定義ファイル(INFファイル)から構成されています。INFファイルはModuleの基本的な情報と,読み込む/生成するライブラリクラス・PCD・Protocol・PPI・GUIDといったインターフェースを記述しています(「EDK II Extended INF Specification」を参照下さい)。

典型的なEDK II Moduleは,ビルドされた後,FFS(Firmware File System)に置かれ,そしてFV(Firmware Volume) Imageに置かれたFirmware Componentです。
Componentとして考えられるのは次のようなものです。

efiバイナリファイルにビルドされ,EFI_PE_SECTIONとしてFFSファイルに置かれるドライバやアプリケーション
・Rawデータバイナリ。例えば,$(WORKSPACE)/MdeModulePkg/Logo/Logo.infはbitmapイメージのロゴを含むRaw Binary Moduleです。
・Device's Option ROMに置かれるOption ROMドライバ
スタンドアローンUEFIドライバ
スタンドアローンUEFIアプリケーション
・ライブラリオブジェクトファイル(.lib)にビルドされ他のModuleに静的にリンクされる,ライブラリインスタンス

ModuleはソースコードのままやEFIバイナリフォーマットでリリースされます。

Module Type

EDK IIは多くのModule Typeを定義しています。
Module typeの用途は次のようなものです。

・Moduleのライフサイクルを示します。
例えば,PEIMはPEI Phaseでディスパッチされます。また,DXE_DRIVERやUEFI_DRIVERはDXE Phaseでディスパッチされます。

・Moduleのバイナリイメージ生成を示します。
例えば,PEIM/DXE_DRIVER TypeのModuleは.efiバイナリイメージに"depex"セクションがあります。UEFI_DRIVERは.efiバイナリイメージに.uiや.verセクションがあります。

・Moduleの適切なライブラリインスタンスを示します。ライブラリインスタンスは,INFファイル内でどんなModule Typeがサポートされるか指示しています。

MODULE_TYPE DESCRIPTION
SEC このModuleはCPUのリセットベクタで実行を開始するよう設計されており,それらはPEI Phaseのためにプラットフォームを準備します。
SECのために定義された標準サービスはないので,このタイプのModuleは同じルールに従います。また,一般的には,スタック用Temporary Memoryを作るための特定のCPUアセンブリコードをいくつか含んでいます。
このModuleは,PEI PhaseにHOBs(Hand-Off-Blocks)という形式でパスされるサービスを生成します。なお,それらのサービスはPIの仕様に準拠していなければなりません。
PEI_CORE このタイプのModuleは,PIの仕様に準拠したPEI Coreの実行により使用されます。
PEIM このタイプのModuleは,PIの仕様に準拠したPEIMsによって使用されます。
DXE_CORE このタイプのModuleは,PIの仕様に準拠したDXE Coreの実行により使用されます。
DXE_DRIVER このタイプのModuleは,PIの仕様に準拠したDXEドライバに使用されます。
それらのModuleはブートサービス環境で実行されるだけでExitBootServices()がコールされた時にdestroyされます。
DXE_RUNTIME_DRIVER このタイプのModuleは,PIの仕様に準拠したDXEドライバに使用されます。
これらのModuleはブートサービス環境でもランタイムサービス環境でも実行可能です。つまりこれは,サービスがExitBootServices()がコールされた後でも使用可能ということです。もし,SetVirtualAddressMap()がコールされたら,このModuleはOSが提供する仮想アドレスマップに従って再配置されます。
DXE_SAL_DRIVER このタイプのModuleは,SetVirtualAddressMap()がコールされる前のPhysical Modeや,SetVirtualAddressMap()がコールされた後のPhysical ModeあるいはVirtual Modeで,DXEドライバに使用されます。このModuleはIPF CPUだけ実行可能です。つまりこれは,Moduleが生成するサービスがExitBootServices()がコールされた後でも実行可能ということです。
DXE_SMM_DRIVER このタイプのModuleは,SMRAMにロードされるDXEドライバに使用されます。結果としてこのModuleはIA32,x64のCPUで実行可能です。これらのModuleはPhysical Modeでのみ実行され,destroyされることは決してありません。つまりこれは,Moduleが生成するサービスがExitBootServices()がコールされた後でも実行可能ということです。
UEFI_DRIVER このタイプのModuleは,UEFIの仕様に準拠したUEFIドライバに使用されます。これらのModuleはBootService実行環境でサービスを提供します。EFI_SUCCESSを返すUEFIドライバはメモリからアンロードされません。一方,errorを返すUEFIドライバはメモリからアンロードされます。
UEFI_APPLICATION このタイプのModuleは,UEFIの仕様に準拠したUEFIアプリケーションに使用されます。UEFIアプリケーションはそれらが終了した時,いつもメモリからアンロードされます。

 

Moduleの作成

ドライバやライブラリModuleは,下記に似たような手順に沿って作成されます。

1. Moduleを置くPackageを作成・選択する。
2. Module用のディレクトリを作成してディレクトリにINFファイルを置く。
3. INFファイルにPackageの依存情報を追記する。
4. INFファイルにPPI,Protorol,GUID,PCDあるいはライブラリクラスの依存情報を追記する。
5. もし,このModuleがPPI,ProtocolあるいはGUIDに依存しており,[depex]セクションをサポートしている場合,INFファイルに[depex]セクションを追記する。
6. ソースファイルを作成し,ソースファイルの相対パスをINFファイルに追記する。


位置

ModuleはリリースされるとPackage内に配布されるので,新しいModuleのために適切なPackageを作成したり選択することが最初のステップです。


Packageの選択

EDK IIのPackageは,似たような定義やModuleを含めるために使用されます。その”似たような”は,次のルールによって判断されるべきです。

Industry standard:
例えば,MdePkgは,PIWG,UEFI,SMBIOS,USB, PCIなど業界規範からの定義を含めています。

Similar technology:
例えば,OptionRomPkgは,Option ROM技術に関連する定義やModuleをグループ化しています。

Business reason:
例えば,IntelFrameworkPkgは,Intelフレームワーク実行のための定義やModuleをグループ化しています。

Platform:
例えば,Nt32PkgはNt32プラットフォームに必要な定義やModuleをグループ化しています。
さらに,Platform PackageはビルドのためにDSC・FDFファイルも提供しています。

Module開発の最初の段階では,Module開発者は適切なPackageを選択するために,目的やModuleのリリース過程を塾考する必要があります。


Moduleディレクトリの追加

Moduleディレクトリの適切なPackageへの追加は,次の方法でなされることが推奨されます。

・ライブラリModuleは"/Library"ディレクトリへ置くこと
・PROTOCOL,PPI,GUIDあるいはライブラリクラスの定義をそれぞれ,"/Include/Protocol","/Include/Ppi","/Include/Guid","/Include/Library"ディレクトリに置くこと
・ドライバModuleを""に置くこと
・アプリケーションModuleを"/Application"ディレクトリに置くこと
・次のようにModuleに推奨された名前を用いること

推奨されるディレクトリ名の慣習 Module Type
XxxPei PEIM,PEI_CORE
XxxDxe DXE_DRIVER,UEFI_DRIVER
XxxRuntimeDxe DXE_RUNTIME_DRIVER
XxxxDxeSal DXE_SAL_DRIVER
XxxxLib Library Instance


 

サンプル:Moduleメタファイル(INF)

Moduleは各々,ModuleのルートディレクトリにINFファイルが必要です。
Moduleは次のアイテムを含むINFファイル(たまにModuleメタファイルと言及される)
です。
・Module名,GUID,Module Typeなど,Moduleの基本情報
・Moduleが依存している任意のPackageのパス
・Module含まれているバイナリファイルあるいはソースファイルのパス
・Moduleに必要とされるProtocol,PPI,GUIDといったインターフェースすべてのリスト
・Moduleに必要とされるPCDやライブラリクラスすべてのリスト
・その他,Module Typeに依存するsectionなど

アプリケーションModule INFの例:

##
[Defines]
 INF_VERSION = 0x00010005
 BASE_NAME = HelloWorld
 FILE_GUID = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 MODULE_TYPE = UEFI_APPLICATION
 VERSION_STRING = 1.0
 UEFI_SPECIFICATION_VERSION = 0x0002001E
 ENTRY_POINT = 0x0002001E

#
# 次の情報はリファレンスのみでビルドツールには必要とされていません。
#
# VALID_ARCHITECTURES = IA32 X64 IPF EBC
#

##
[Sources.common]
 Helloworld.c

##
[Package]
 MdePkg/MdePkg.dec

##
[LibraryClasses]
 UefiBootServicesTableLib
 UefiApplicationEntryPoint
 UefiLib
 DebugLib


下記はライブラリインスタンスPeiServicesTablePointerLib.infのサンプルINF:

[Defines]
 INF_VERSION = 0x00010005
 BASE_NAME = PeiServicesTablePointerLib
 FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
 MODULE_TYPE = PEIM
 VERSION_STRING = 1.0
 LIBRARY_CLASS = PeiServicesTablePointerLib|PEIM
 PEI_CORE SEC
 CONSTRUCTOR = PeiServicesTablePointerLibConstructor
#
# VALID_ARCHITECTURES = IA32 X64 IPF EBC (EBC is for build only)
#
#
[Sources.common]
 PeiServicesTablePointer.c
[Packages]
 MdePkg/MdePkg.dec
[LibraryClasses]
 DebugLib 


 

Package依存情報の追加

INFファイルの[Packages]セクションは,このModuleのPackageへの依存情報をすべて記載します。依存するPackageのDECファイルのパスが,INFファイルの[Packages]セクションに記載されることになります。例えば下記のようになります。

[Packages]
# パスは$WORKSPACEをルートとするパスなので注意してください。
 MdePkg/MdePkg.dec
 IntelFrameworkPkg/IntelFrameworkPkg.dec

ModuleはPackageの依存情報を決定するのに以下のルールに従うべきです。

・MdePkgはすべてのModuleに必要になります。
Intelフレームワークの仕様の定義を使用する場合は,IntelFrameworkPkgが必要になります。
・上記のルール以上に,Protocol,PPI,GUID,PCD,ライブラリクラスを参照することで,より多くのPackageへの依存があります。例えばもし,ModuleがMdeModulePackage内で定義される"HiiLib"クラスから,定義やインターフェースを参照すると,それは同時にMdeModulePkgに依存していることにもなります。


ソースファイルの追加

すべてのModuleのソースコードはINF内の[Sources]セクションに記載され,次のルールに基づいています。
・異なるアーキテクチャのソースは異なるソースセクションに記載されます。

[Sources.common] # すべてのアーキテクチャに有効
 CheckSum.c
...

[Sources.Ia32] # IA32アーキテクチャにのみ有効
 Ia32/Wbinvd.c | MSFT
 ...
 Ia32/WriteMm7.S | GCC
 ...

[Sources.X64] # X64アーキテクチャにのみ有効
 X64/Thunk16.asm
 ...

[Sources.IPF] # IPFアーキテクチャにのみ有効
 Ipf/AsmCpuMisc.s
 ...

[Sources.EBC] # EBCアーキテクチャにのみ有効
 Synchronization.c
 ...

・Tool Tagはツールチェーン別にソースを指定するために使用します。

[Sources.Ia32]
 Ia32/Wbinvd.c | MSFT # MSFTツールを使用したとき,このソースがビルドされます。
 ...
 Ia32/WriteMm7.S | GCC # GCCツールを使用したとき,このソースがビルドされます。
 ...
    "$(CC)" -o ${dst} $(CC_FLAGS) $(INC) ${src}

・すべてのファイルはModuleのメインフォルダ以下に置くこと。"./"の表現は使わないこと。
・すべてのCインクルードファイルは[Sources]セクション内にリスト化されるべきです。

サポートされているTool Tag

EDK IIでサポートされるTool Tagは下記の通りです。

Tool Tag DESCRIPTION
MSFT Microsoft Family Tool Chain
INTEL INTEL Tool Chain
GCC GCC Tool Chain


 

ライブラリクラスリファレンスの追加

ライブラリクラスはいくつかのマクロあるいは構造体定義と関数宣言を抽出します。ライブラリインスタンスは,異なるプラットフォームや一つのプラットフォーム内の異なるPhase(SEC,PEI,DXE)に対して,異なるものになります。それゆえ,ModuleはプラットフォームやPhase動作のライブラリクラスに依存しています。

Module内でライブラリクラスを使う手順は下記の通りです。

1. INF内に記載のライブラリクラスを含むPackageへの依存情報を追記します。
2. INF内に記載のライブラリクラスへの依存情報を追記します。
3. ソースコード中でライブラリクラスヘッダファイルをIncludeします。

C言語のソースファイル内でライブラリクラスヘッダをIncludeする際は,次のようなsyntaxを使用します。

#include <Library/OemHookStatusCodeLib.h>

ヘッダファイルのインクルードパスは,PackageのDEC内[Includes]セクションで定義されるPackageのパブリックインクルードパスからの相対で表します。


 

PCD(Platform Configuration Database)リファレンスの追加

マクロとグローバル変数は,異なるアーキテクチャや異なるプラットフォームでModuleをカスタマイズするために広く使用されます。EDK IIはこれらの手法を置き換えるPCDの概念を紹介しています。
例えば,"FeatureFlag"型のPCDは,いくつかの特徴や機能がPCDの値がTRUEの時に有効化されるという点で,マクロに似ています。逆の場合も同様です。

PCDエントリはPCDのToken Space GUID C Nameにより,"."とC Nameにより定義されます。一つのPCD Token Spaceの中で,PCDのC Nameは固有のものになります。

例えば,PCD gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevelを例に挙げてみると,gEfiMdePkgTokenSpaceGuidはToken Space名であり,PcdDebugPrintErrorLevelはPCDの名前です。なお,gEfiMdePkgTokenSpaceGuidはMdePkg内で定義されるGUIマッピングされています。

gEfiMdePkgTokenSpaceGuid = {0x914AEBE7, 0x4635, 0x459B, {0xAA, 0x1C, 0x11, 0xE2, 0x19, 0xB0, 0x3A, 0x10}}


 

PCDのType

EDK IIは次のようなPCD Typeを提供しています。

Feature flag type PCD このタイプのPCDは,特徴を有効化・無効化するswitch MACROの代替です。これはBOOL型で値はTRUEもしくはFALSEです。
Fixed at build type PCD このタイプのPCDは,PCI Expressベースアドレスといったカスタマイズ可能な値を生成するマクロを代替します。
Patchable in module type PCD このタイプのPCDは,Fixed at build型のPCDにとても似ていますが,値はModuleのPEイメージのコードセクションではなくデータセクションに保存されています。
Dynamic type PCD このタイプのPCDは,他のタイプのPCDとは異なるものです。値は一つのModuleにより割り当てられ,実行中は他のModuleからアクセスされます。PEIMであるPcdPeimやDXEドライバであるPcdDXEは各々,それぞれのPhaseにおいて,使用するDynamic PCDの情報を含むデータベースを整備します。


 

Module INFファイルへのPCDの追加

PCDエントリを参考として引用するために,Token Space Guid NameとPCD NameがINFファイルの[PCD]セクションに追加されなければなりません。

[PCD.common]
 gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength
 gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength
 gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength

プラットフォームインテグレーターがいろんな用途で任意のPCDタイプを使用できるように,Module INFファイルでは一般的なタイプの"PCD"の使用が推奨されます。例えば,デスクトッププラットフォームでは,メモリー長が"Dynamic" PCDとして設計され,その値はMemory Discoveryドライバによって生成されます。しかしながら,いくつかの特殊な組み込みシステム内では,メモリー長が"FixedAtBuild"タイプのPCDとして設計され,その値はいつも固定されています。

PCD Typeを選択する際には制限があります。
もし,PCDの値が配列長のように定数として使用された場合,このPCDのタイプは"FixedPcd"であるべきです。例えば以下のような例があります。

UINT8 MySampleArray[FixedPcdGet16(PcdArrayLength)] = (0);

ライブラリインスタンスは異なるModuleにリンクしうるし,同一のPCDは異なるModuleで異なる値を持ちうるので,ライブラリインスタンスModuleには"FixedPcd"を用いることを避けてください。
単一のModuleでは,2つのPCDを同じ名前で使わず異なる,Token Spaceで使用してください。

PCD Type INF File Section Name
任意のPCD TypeにマッピングされるGeneral Type PCD
Feature Flag FeaturePcd
Fixed At Build FixedPcd
Patchable In Module PatchPcd
Dynamic PCD
CソースコードからPCDの値へのアクセス

ソースコードからPCDの値を得たりセットするには,次の手順にそうべきです。

1. Module INFファイルにPcdLibの依存情報を追記します。
2. MdePkgの依存情報を追記する。
3. ソースコード中にをインクルードする
4. PCDの値にアクセスするために,PcdLibを使用する

Function name INF PCD Section Name
PcdGetx()/PcdSetx() Common get/set function for all PCDs type
FixedPcdGetx() Get/set function for "FeaturePcd"
FixedPcdGetx() Get function for "FixedPcd"
PatchPcdGetx()/PatchPcdSetx Get/set function for "PatchPcd"

例えば,PcdGet32マクロは,PCDのすべてのTypeの値を,
32bit値で得るために使われます。

 //
 // Check driver debug mask value and global mask
 //
 if ((ErrorLevel & PcdGet32(PcdDebugPrintErrorLevel)) == 0){
  return;
 }

Protocol,PPI,GUIDの参照

Protocol,PPI,GUIDは,UEFIアーキテクチャインターフェースの細目であり,
ファームウェアの構成要素のインターフェースを抽出します。
以降は,Moduleからどのようにこれらのインターフェースを参照するのか見ていきましょう。

INFファイルへProtocol,PPI,GUIDの追加

Protocol,PPI,GUIDの名前は,Module INF内の[Protocol],[Ppi],[Guid]に追記する必要があります。例えば,次のようなものです。

[Protocol]
gEfiSampleProtocol


 

ヘッダファイルをソースコードにインクルード

Protocol,PPI,GUIDのヘッダファイルは似たような構造を定義します。ヘッダファイルのパスを探すには次の手順を踏んでください。

Ppiのヘッダファイルは,/Include/Ppi にあります。
・Protocolのヘッダファイルは,/Include/Protocol にあります。
・Guidのヘッダファイルは,/Include/Guid にあります。

ヘッダファイルはModuleソースコードに明確にに含まれなければなりません。
つまり下記のように宣言します。

#include <Protocol/DeviceIo.h>
#include <Ppi/Reset.h>
#include <Guid/GlobalVariable.h>

 

Moduleの依存情報を追加

依存情報は,ドライバのエントリポイントで実行したりディスパッチする条件を与えることになります。これは,PEIMやDXE Moduleにディスパッチする順番を決めるのに役立ちます。

Ppiのヘッダファイルは,/Include/Ppi にあります。
・Protocolのヘッダファイルは,/Include/Protocol にあります。
・Guidのヘッダファイルは,/Include/Guid にあります。

ヘッダファイルはModuleのソースコードに明確に含まれなければなりません。例えば,次のようになります。

#include <Protocol/DeviceIo.h>
#include <Ppi/Reset.h>
#include <Guid/GlobalVariable.h>



 

ライブラリインスタンスへの追加の手順

生成されるライブラリクラスの定義

ライブラリインスタンスは,常に単一のライブラリクラスに関連づけられており,ライブラリクラスにより定義されるすべてのインターフェースを実装します。それゆえ,ライブラリクラス名は,ライブラリインスタンスのINFファイル内の[Defines]セクションに記載しなければなりません。例えば次のように記載します。

[Defines]
 LIBRARY_CLASS = UefiDriverEntryPoint | DXE_DRIVER DXE_RUNTIME_DRIVER

上記では,UefiDriverEntryPointはライブラリインスタンスにより作られたライブラリクラス名です。さらに,"DXE_DRIVER DXE_RUNTIME_DRIVER"はライブラリインスタンスをサポートするModuleのTypeです。


 

ライブラリコンストラクターの定義(Optional)

ライブラリインスタンスModuleは,各々リンクするModuleのエントリポイントによって呼び出されるライブラリコンストラクター関数を定義することができます。ライブラリコンストラクター関数には,任意のライブラリインターフェースが使用される前にいくつかの初期化処理があります。

[Defines]
 ...
 CONSTRUCTOR = HobLibConstructor
ライブラリコンストラクター関数のType

ライブラリインスタンスのModule Typeによって,ライブラリコンストラクター関数は3つのタイプに分けられます。

・BASE module typeのライブラリインスタンス

EFI_STATUS
EFIAPI
BaseConstructor (
 VOID
 )

 
・PEIM,PEI_CORE module typeのライブラリインスタンス

EFI_STATUS
EFIAPI
PeiServiceTablePointerLibConstructor (
 IN EFI_PEI_FILE_HANDLE          FileHandle,
 IN CONST EFI_PEI_SERVICE          **PeiServices
 )

 
・DXE_DRIVER,DXE_CORE,DXE_RUNTIME_DRIVER,UEFI_APPLICATION,UEFI_DRIVER module typeのライブラリインスタンス

EFI_STATUS
EFIAPI
DxeCorePerformanceLibConstructor (
 IN EFI_HANDLE          ImageHandle,
 IN EFI_SYSTEM_TABLE          *SystemTable
 )


 

ライブラリデストラクターの定義(Optional)

ライブラリインスタンスModuleは,DXE_DRIVERやUEFI_DRIVERなどのExitDriver()によって呼び出される,ライブラリデストラクター関数を定義することができます。ライブラリデストラクター関数には,いくつか初期化されない処理があります。

デストラクター関数はINFファイル内で,次のように明確に宣言される必要があります。

[Defines]
 ...
 DESTRUCTOR = HobLibDestructor

デストラクター関数のプロトタイプは,上述したコンストラクター関数と同じです。


ドライバの手順のおまけ

ドライバのエントリポイントの定義

下記のようにPEIM,DXEドライバは,INFファイルの[Defines]セクションで定義されるエントリポイント関数を定義します。

[Defines]
 ...
 ENTRY_POINT = PcdDxeInit

Moduleエントリポイント関数は,そのModule Typeによって異なります。
詳細は下記のようになります。

Concept Description
PEIM Entry Point Library PEIMのモジュールエントリポイントライブラリ。
UEFI Driver Entry Point Library UEFIドライバ,DXEドライバ,DXEランタイムドライバ,DXE SMMドライバのモジュールエントリポイントライブラリ。
UEFI Application Entry Point Library UEFIアプリケーションのモジュールエントリポイントライブラリ。
PEI Services Table Pointer Library PEI Services Tableへのポインタを検索するサービスを提供します。
UEFI Boot Services Table Library EFI Boot Services Tableへのポインタを検索するサービスを提供します。DXEとUEFIのModule Typeのみ実行可能です。
UEFI Runtime Services Table Library EFI Runtime Services Tableへのポインタを検索するサービスを提供します。DXEとUEFIのModule Typeのみ実行可能です。
DXE Services Table Library DXE Service Tableへのポインタを検索するサービスを提供します。DXEのModule Typeのみ実行可能です。


 

HII(Human Interface Infrastructure)を使用するModule

DXE Moduleは,BDS Phase中にブラウザで使用される次のリソースを公開したり更新することができます。

Forms:
ユーザに映し出す必要のあるコンテンツのタイプを記述します。

Strings:
基本的にFormに参照される情報のテキストベース(UCS-2エンコード)表示。

Font/Image:
ローカル上でレンダリングされるコンテンツ。

HIIの詳細は,「UEFI Specification」27章 Human Interface Infrastructure Overviewを参照ください。

Forms

VFRリソースファイルの作成

VFRファイルはFormリソースを記述します。VFRファイルはModuleのディレクトリに置かれ,INFファイル内[Sources]セクションで他のソースと一緒に参照されます。

VFR fileの一例:

#define FORMSET_GUID { 0x9e0c30bc, 0x3f06, 0x4ba6, 0x82, 0x88, 0x9,
0x17, 0x9b, 0x85, 0x5d, 0xbe }
#define FRONT_PAGE_CLASS 0x0000
#define FRONT_PAGE_SUBCLASS 0x0002
#define FRONT_PAGE_FORM_ID 0x1000
#define FRONT_PAGE_ITEM_ONE 0x0001
#define FRONT_PAGE_ITEM_TWO 0x0002
#define FRONT_PAGE_ITEM_THREE 0x0003
#define FRONT_PAGE_ITEM_FOUR 0x0004
#define FRONT_PAGE_ITEM_FIVE 0x0005
#define FRONT_PAGE_KEY_CONTINUE 0x1000
#define FRONT_PAGE_KEY_LANGUAGE 0x1234
#define FRONT_PAGE_KEY_BOOT_MANAGER 0x1064
#define FRONT_PAGE_KEY_DEVICE_MANAGER 0x8567
#define FRONT_PAGE_KEY_BOOT_MAINTAIN 0x9876
#define LABEL_SELECT_LANGUAGE 0x1000
#define LABEL_TIMEOUT 0x2000
#define LABEL_END 0xffff

formset
 guid = FORMSET_GUID,
 title = STRING_TOKEN(STR_FRONT_PAGE_TITLE),
 help = STRING_TOKEN(STR_NULL_STRING),
  classguid = EFI_HII_PLATFORM_SETUP_FORMSET_GUID,

 form formid = FRONT_PAGE_FORM_ID,
  title = STRING_TOKEN(STR_FRONT_PAGE_TITLE);

  banner
   title = STRING_TOKEN(STR_FRONT_PAGE_COMPUTER_MODEL),
   line 0,
   align left;
 
  banner
   title = STRING_TOKEN(STR_FRONT_PAGE_CPU_MODEL),
   line 1,
   align left; 

  banner
   title = STRING_TOKEN(STR_FRONT_PAGE_CPU_SPEED),
   line 1,
   align right;

  banner
   title = STRING_TOKEN(STR_FRONT_PAGE_BIOS_VERSION),
   line 2,
   align left;

   banner
   title = STRING_TOKEN(STR_FRONT_PAGE_MEMORY_SIZE),
   line 2,
   align right;
 
  goto FRONT_PAGE_ITEM_ONE,
   prompt = STRING_TOKEN(STR_CONTINUE_PROMPT),
   help = STRING_TOKEN(STR_CONTINUE_HELP),
   flags = INTERACTIVE,
   key = FRONT_PAGE_KEY_CONTINUE;
 
  label LABEL_SELECT_LANGUAGE;
  //
  // This is where we will dynamically add a OneOf type op-code to
select
  // Languages from the currently available choices
  //
  label LABEL_END;
 
  goto FRONT_PAGE_ITEM_THREE,
   prompt = STRING_TOKEN(STR_BOOT_MANAGER),
   help = STRING_TOKEN(STR_BOOT_MANAGER_HELP),
   flags = INTERACTIVE,
   key = FRONT_PAGE_KEY_BOOT_MANAGER;

  goto FRONT_PAGE_ITEM_FOUR,
   prompt = STRING_TOKEN(STR_DEVICE_MANAGER),
   help = STRING_TOKEN(STR_DEVICE_MANAGER_HELP),
   flags = INTERACTIVE,
   key = FRONT_PAGE_KEY_DEVICE_MANAGER;

  goto FRONT_PAGE_ITEM_FIVE,
   prompt = STRING_TOKEN(STR_BOOT_MAINT_MANAGER),
   help = STRING_TOKEN(STR_BOOT_MAINT_MANAGER_HELP),
   flags = INTERACTIVE,
   key = FRONT_PAGE_KEY_BOOT_MAINTAIN;

 endform;

endformset; 

【EDK II】EDK II Package

EDK II UEFI 自作OS

EDK IIに関する備忘録第二弾。

プロローグ

EDK II Packageは,繰り返しますが,種々のModuleと関連した定義のセットを含んだコンテナです。
それぞれのPackageはEDK II ディストリービューションの単位です。
それらは,ユーザーのディストリービューションやリユースを促進するために,大きなプロジェクトをリリースしたりマネジメントするために使用されます。
全体のプロジェクトソースは,リリースの粒度(granularity)を低減させるため,異なるPackageに分割されます。新たなプロジェクトは異なるソースからリリースされたPackageを使用して作成されます。

EDK II Package

Packageは,DECファイルを併せたModuleのグループをまとめるディレクトリです。

EDK IIはUEFIやPIに準拠したPackageを提供しています(例えば,MdePkgやMdeModulePkgなど)。

MdePkgはEFI1.1,UEFI2.0,UEFI,2.1,PI1.0のスペックを完全な定義と,EDK II MDE(Module Development Environment) Library Specificationにより定義されるLibraryクラスとインスタンスを含んでます。UEFIドライバとPIドライバは,このPackageのみを元に開発できます。

EDK II Packageの詳細な情報は「EDK II User Guide」のSection 2.2にあり,それぞれのPackageのPackage specificationの中に書いています。

Packageディレクト

それぞれのPackageは,異なるソースファイルを分離するためにディレクトリ構造を持ちます。
ルートディレクトリにはInclude,Library,Application,Driversディレクトリがあります。

・Includeディレクトリには,このPackageや他のPackageで使用されるすべてのPublicヘッダファイルがあります。Includeディレクトリ以下には,Ppi,Protocol,Guid,Libraryクラスのヘッダファイルを作成するためのサブディレクトリがあります。
・Libraryディレクトリは,それぞれのライブラリインスタンスModuleを含んでいます。
・Applicationディレクトリは,それぞれのUEFIアプリケーションを含んでいます。
・Driverディレクトリは,ドライバやドライバのグループを含んでいます。

上記の(Libraryインスタンス,Application,Driver)Moduleは,それぞれソースファイルを置く自身のディレクトリを持っています。Moduleはそのディレクトリだけに依存するかもしれませんし,Publicヘッダファイルに依存するかもしれませんしまちまちです。Moduleのソースファイルは,別のModuleのディレクトリにあるソースファイルであってはいけません。

Packageの中のディレクトリ・サブディレクトリのサンプル

・ Package.des -------------> PackageのDECファイル
・ Package.dsc -------------> PackageのDSCファイル
・ Include -------------> Publicヘッダファイル
   ⚪︎ Protocol/ -------------> Public Protocolヘッダファイル
   ⚪︎ Ppi/ -------------> Public PPI(Peim to Peim Interface)ヘッダファイル
   ⚪︎ Guid/ -------------> Public GUIDヘッダファイル
   ⚪︎ IndustryStandard/ -------------> Public Industry Standardヘッダファイル
   ⚪︎ Library -------------> Public Libraryクラスヘッダファイル
・ Library -------------> Libraryインスタンス
   ⚪︎ NameOneLib/ -------------> ライブラリインスタンスNameOneソースとINFファイル
   ⚪︎ NameTwoLib/ -------------> ライブラリインスタンスNameTwoソースとINFファイル
・Application/ -------------> UEFIアプリケーション
   ⚪︎ NameOneApp/ -------------> アプリケーションNameOneソースとINFファイル
   ⚪︎ NameTwoApp/ -------------> アプリケーションNameTwoソースとINFファイル
・NameOneDxe/ -------------> DXEドライバNameOneのソースとINFファイル
・NameTwoPei/ -------------> PEIドライバNameTwoのソースとINFファイル

上記中,仮にPackageの中に関係したソースファイルがない場合は,対応したディレクトリはありません。例えば,もしPackageの中にアプリケーションがない場合は,わざわざからのディレクトリを作る必要はありません。

Package Declaration (DEC) File

それぞれのPackageは,パッケージのパブリックインターフェースを定義するため,一つのDECファイルを含んでいます。パブリックインターフェースとは,パッケージのパブリックヘッダファイル,GUID,PCDです。

DECには,[Defines],[Includes],[LibraryClass],[Guids],[Ppis],[Protocol],[Pcds]のセクションがあります。

[Defines]セクション:
Packageの名前やGUIDなどを定義します。

[Includes]セクション:
パブリックヘッダファイルディレクトリのルートディレクトリをリスト化しないといけません。

[LibraryClass]セクション:
Package/Include/Library ディレクトリ以下にあるライブラリヘッダファイルを含んでいます。
基本的にはそのパスを指定します。

[Guids]セクション:
Package/Include/Library ディレクトリ以下のGUIDについて,GUIDの値を指定します。

[Ppi]セクション:
Package/Include/Ppi ディレクトリ以下のPPIについて,GUIDを指定します。

[Protocols]セクション:
Package/Include/Protocol ディレクトリ以下のProtocolについて,GUIDを指定します。

PCDは,そのタイプ(FeatureFlag,FixedAtBuild,PatchableInModule,Dynamic,DynamicEXなど)によって異なるPCDセクションで宣言しています。PCDが多数のPCDタイプをサポートする場合,そのサポートされたセクションで宣言されません。PCDが宣言されるとき,そのデータ型とデフォルト値が指定されなければなりません。

下記は,DECファイルのサンプルです。追加で情報が加えられたりします。

Example:Package.dec

[Defines]
 DEC_SPECIFICATION = 0x00010005
 PACKAGE_NAME = パッケージ名
 PACKAGE_GUID = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 
 PACKAGE_VERSION = 0.1

[Includes]
 Include # パッケージをincludeするディレクトリ

[LibraryClasses]
 ## Libraryクラス名はLibraryヘッダファイル名と同じ
 OneClassLib | Include/Library/OneClassLib.h

[Guids]
 #GuidCName = {xxxxxxxx, xxxx, xxxx, {xx, xx, xx, xx, xx, xx, xx, xx}},

[Ppis]
 #PpiGuidName = {xxxxxxxx, xxxx, xxxx, {xx, xx, xx, xx, xx, xx, xx, xx}},

[Protocols]
 #ProtocolGuidName = {xxxxxxxx, xxxx, xxxx, {xx, xx, xx, xx, xx, xx, xx, xx}},
[PcdsFeatureFlag]
 #FeatureFlag PCDはBool型なので,値は TRUE か FALSE です。
 #PcdTokenSpaceCGuidName.PcdName | TRUE | BOOLEAN | TokenNumber
 #PcdTokenSpaceCGuidName.PcdName | FALSE | BOOLEAN | TokenNumber

[PcdsFixedAtBuild]
 #PcdTokenSpaceCGuidName.PcdName | DefaultValue | DataType | TokenNumber

[PcdsPatchableInModule]
 #PcdTokenSpaceCGuidName.PcdName | DefaultValue | DataType | TokenNumber

[PcdsDynamic]
 #PcdTokenSpaceCGuidName.PcdName | DefaultValue | DataType | TokenNumber

[PcdsDynamicEx]
 #PcdTokenSpaceCGuidName.PcdName | DefaultValue | DataType | TokenNumber

DECファイルフォーマットの詳細は,「EDK II DEC File Specification」を参照してください。

Package Description(DSC) File

それぞれのPackageはDECファイルとは別にDSCファイルを作成します。
すべてのModuleは,コンパイルとPackageに所属することの証明のため,DSCファイル内に記述されます。
DSCには,[Defines],[LibraryClass],[PCD],[Components]などのセクションがあります。

[Defines]セクション:
ビルド関連の情報をセットします。例えば,ビルドのアウトプットディレクトリ,ビルドターゲット,GUID,そしてビルドアーキテクチャです。

[LibraryClass]セクション:
[Components]セクションに記載されたドライバ・アプリケーションに使用されるLibraryクラスのインスタンスを指定します。

[PCDs]セクション:
[Components]セクションに記載されたModuleによって使用されるPCDタイプと値を構成します。
PCDの値がDECのデフォルト値と等しい場合やPCDタイプが特定の要件を必要としない場合,
PCDはDSCファイルの中で構成されません。その値とタイプはDECファイルの設定がデフォルトになります。
もしすべてのPCDがDSCファイル内で必要とされない場合,[PCDs]セクションは生成されません。

下記は,DSCファイルのサンプルです。情報が追加されたりする可能性があります。

Package.dsc

[Defines]
 PLATFORM_NAME = パッケージ名
 PLATFORM_GUID = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 PLATFORM_VERSION = 0.1
 DSC_SPECIFICATION = 0x00010005
 OUTPUT_DIRECTORY = Build/パッケージ名
 SUPPORTED_ARCHITECTURES = IA32 | IPF | X64 | EBC
 BUILD_TARGET = DEBUG | RELEASE
 SKUID_IDENTIFIER = DEFAULT

[SkuIds]
 0 | DEFAULT #エントリ: 0 | DEFAULTは予約されていて必要

[LibraryClasses]
## もし,[Components]セクション記載のComponentsがより多くのライブラリクラスが使った場合,
## より多くのライブラリインスタンスが必要です。
## library class name | library instance INF file path from package
 DebugLib | MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
 BaseLib | MdePkg/Library/BaseLib/BaseLib.inf
 BaseMemoryLib | MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
 ......

## PCDsセクションは指定されていません。
## なので,すべてのPCDの値はDEC内の値がデフォルトになっています。
## [PcdsFeatureFlag]
## [PcdsFixedAtBuild]

[Components]
## すべてのライブラリ,ドライバ,アプリケーションはここに追加されコンパイルされます。
## PackageディレクトリからModule INFファイルまでのパスを指定します。
 PackageNamePkg/Library/NameOneLib/NameOneLib.inf
 PackageNamePkg/NameOneDxe/NameOneDxe.inf
 PackageNamePkg/NameTwoPei/NameTwoPei.inf

DSCファイルフォームの詳細は「DSC Specification」を参照してください。


Package管理

Packageの作成

今のPackageが要件を満たさない場合や,オリジナルのコードベースがEDK II Packageを分割する場合,新たなPackageが作成されます。新たなPackageを定義するための推奨されるルールは次のようになります。

・同じ機能に関連するModuleはすべて同じPackageに入っているべきです。例えば,異なるチップセットのために異なるPackageが用意されるべきです。
・異なるプラットフォームで共有される一般的なModuleは,別の一つのPackageの中にあるべきである。例えば,MdePkgやMdeModulePkgは共有されています。
・Moduleはリリース要件によってPackageにおさまっていくべきです。もしModuleが特定のカスタマーにだけリリースされる場合,それらのModuleは特定のPackageにおさまっているべきです。

なお,新たなPackageのソースファイルに制限は何もありません。たとえPackageに一つのファイルしかない場合でも,PackageとしてはOKです。
上述したルールに沿って,EDK IIはユーザーの参照用にいくつかのPackageを提供しています。
新たなPackageを追加するとき,次の手順を踏んで作成されます。

ディレクトリ作成の際,PackageNamePkgなどのように意味のあるPackage名を付けます。
・Package内容を記述するために,PackageのルートディレクトリにDECファイル及びDSCファイルを作成します。
・異なるソースファイルを置くため,Packageのサブディレクトリを作成します。

Packageの使用

Packageは,他のModuleやPlatformを開発するために必要なパブリックヘッダファイル,ライブラリクラス,PCD,そしてModuleを提供することができます。
Moduleは所属するPackageに依存していますが,それと同時に他のPackageに依存していることもあり得ます。
PlatformはそのPackage,あるいは別のPackage内にあるModuleによって作成されます。
EDK II Packageは基礎的な開発の単位です。Packageは開発環境を構成するために使用されます。開発要件次第で,開発環境はEDK II projectや他のソースから異なるPackageを導入できます。例えば,UEFIやPIドライバを開発したい場合,UEFI/PIの定義をすべて含むMdePkgが開発環境に必要になります。

以下はPackageに基づいて,どのようにModuleやPlatformを開発するかを示しています。

・PackageのDECファイルやIncludeディレクトリは,Packageのパブリックヘッダファイル・ライブラリクラス・PCDをリスト化します。新しいModuleが開発されたとき,それは今の開発環境ないのすべてのPackageのDECファイルの情報を含んでいます。もし,そのModuleが今の開発環境にないPackageの情報を欲する場合は,そのPackageを開発環境に加える必要があります。

・PackageのDSCファイルは,Packageによって提供されるModuleをリスト化します。開発者は,開発環境内で必要なモジュールを得る(,またそれらの情報をPlatformのDSCファイル内に記述する)ために,すべてのPackageのDSCファイルを検索していきます。そのあと,PlatformのDSCやFDFファイル内でそれらのModuleを記述します。もし新しいPlatformがまだ今の開発環境にないPackageを必要としているときは,そのPackageを追加する必要がありなす。

Packageのアップデート

PackageのDEC・DSCファイルは,このPackageのソースファイルによって生み出される特性を記述します。もしソースファイルが変更・削除・追加された場合は,DEC・DSCファイルもそれに合わせて変更しなければなりません。

DEC・DSCファイルに影響するソースコードの変更はすべて以下で紹介していきます。

1. PackageのIncludeディレクトリの更新

PackageのIncludeディレクトリが変更・削除・追加された場合,DECファイルの[Include]セクションを更新せねばなりません。

Example: Incude section of Package.dec

[Includes]
 Include     # 既存のPackage Includeパス
 LocalInclude     # 新しいIncludeパスを追加

2. GUIDs,PPIs,Protocolsの更新

GUIDの値やPackageのPubulic GUIDヘッダファイルで定義されるGUID Global CNameが変更された時,DECファイルの[Guids]セクションは新たなGUIDの値やGUID CNameに対応するため更新されねばなりません。もし仮にpubilic GUIDヘッダファイルが削除されたとすると,このファイル中で定義されたGUIDはDECファイルの[Guids]セクションから削除しないといけません。また,もし仮に新たなGUIDヘッダファイルがPackage Public Includeディレクトリに追加されたとすると,この新たなGUIDの宣言と値の記載をDECファイルの[Guids]セクションにしないといけません。以上のように,GUIDヘッダファイルと同じように,GUIDの値がPPIヘッダファイル・Protocolヘッダファイルで変更された場合も,同様に[Ppis]あるいは[Protocols]セクションに変更を加えなければいけません。

Example: Guid section of Package.dec

[Guids]
 #gGuidCName = {00000000, 0000, 0000, {00, 00, 00, 00, 00, 00, 00, 00}}
 #上記から,例えば名前と数値を下記のように更新します。
 gNewGuidCName = {00000000, 0000, 0000, {00, 00, 00, 00, 00, 00, 00, 01}}

3. ライブラリクラスの更新

ライブラリクラスヘッダファイルの名前が変更された時,ライブラリクラスヘッダファイルの名前はDEC内の[LibraryClasses]セクションを更新して,新たなライブラリクラス名をヘッダファイルに反映させる必要があります。ライブラリクラス名の変更もまた[LibraryClasses]セクションの更新が必要になります。新たなライブラリクラスが導入された場合も,その名前とヘッダファイルをDEC内の[LibraryClasses]で指定する必要があるでしょう。

Example: LibraryClasses section of Package.dec
[LibraryClasses]
 #OneClassLib |Include/Library/OneClassLib.infを下記のように更新する。
 BaseMemoryLib | MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf

4. PCDsの更新

PCDはPackageのDECファイルで宣言されますが,いずれのヘッダファイルとも関係ありません。しかしながら,Moduleのソースファイルはそれらを利用します。もしPCDがどのModule内にも存在しない場合,その宣言はDECファイルから削除されるべきです。また,そのPCDの設定がDSCファイルにあるはずなので,それも削除すべきです。
Moduleが新たなPCDを必要とするときは,Moduleの存在するPackageのDEC内でPCDを定義する必要があります。そのとき,DECファイルはPCDのタイプとデフォルト値を指定することになるでしょう。

Example: Package.dec

[PcdsFixedAtBuild]
 #新たにFixedAtBuild PCDの追加。下記のフォーマット
 #PcdTokenSpaceCGuidName.PcdName | DefaultValue | DataType | TokenNumber
 gEfiMdeModulePkgTokenSpaceGuid.PcdHelloWorldTime | 1 | UINT32 | 0x40000005

5. Moduleの更新

Module(Library instance,drivers,Application)への変更は,依存しているヘッダファイル・ライブラリクラス・PCDを編集させることになります。そしてそれは,DSCファイルを更新させることにもなります。

もし,ModuleのINFファイル名が変更された場合,そのModuleを参照するDSCファイル内の記述も,変更した新たな名前に更新する必要があります。
もし,Moduleが完全に削除された場合,もうコンパイルされないのでDSCファイルから記載を削除します。
Packageに新たなModuleが追加されたとき,DSCファイル内に追加されてコンパイルされるようにすべきです。

Example: Package.dsc

[Components]
# ModuleのINFファイルへのパスを,Packageをルートディレクトリとして記載します。
 #PackageNamePkg/NameTwoPei/NameTwoDxe.infを下記のように更新
 MdeModulePkg/Application/HelloWorld/HelloWorld.inf

【EDK II】EDK IIの基礎

自作OS EDK II UEFI

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を呼びます。

gtk-fortran Vol.2

gtk-fortran

ボタンの表示

ウィンドウにボタンを表示させるサンプルコードです。

program show_button
  !--------------------------------------------!
  !--- ファイル名は hogehoge.f90 とします。
  !--------------------------------------------!
  use iso_c_binding
  use gtk
  !---
  implicit none
  type(c_ptr) :: window

  !--- GTK+の初期化
  call gtk_init()

  !--- ウィンドゥの設定
  !  第一引数:ウィンドゥの種類
  !    GTK_WINDOW_TOPLEVEL:アプリケーションのメインになるようなウィンドゥ
  !    GTK_WINDOW_POPUP   :クリックした時にポップアップ表示されるようなウィンドゥ
  window = gtk_window_new(GTK_WINDOW_TOPLEVEL)

  !--- タイトルを設定
  call gtk_window_set_title(window, "Hello! World!"//c_null_char)

  !--- ウィンドゥの大きさ設定
  !    第一引数:ウィジェット
  !    第二引数:ウィジェットの幅
  !    第三引数:ウィジェットの高さ
  call gtk_widget_set_size_request(window, 300, 200)

  !--- ボタンウィジェットの作成
  !    第一引数:ボタンのラベル
  button = gtk_button_new_with_label("ボタンテスト"//c_null_char)
  !--- ボタンの配置
  !    第一引数:コンテナウィジェット
  !    第二引数:コンテナ内に配置するウィジェット
  call gtk_container_add(window, button)

  !--- 全てのウィンドゥの表示
  !    第一引数:表示する親ウィジェット
  call gtk_widget_show_all(window)

  !--- メインループ
  call gtk_main()
end program show_button

hogehoge.f90をコンパイルして実行しましょう。

$ gfortran hogehoge.f90 -o hogehoge `pkg-config --cflags --libs gtk-2-fortran` -Wl,-no_pie
$ ./hogehoge


実行すると次のように表示されます。これでボタン表示ができるようになりました。

f:id:convergence_hub:20170115141432p:plain

gtk-fortran Vol.1

gtk-fortran

私がメインで使用しているfortranの、GUIプログラミングについて備忘録として保存してまいります。

gtk-fortranのインストール

gtk-fortranについて、まずは下記を一読ください。
Home · jerryd/gtk-fortran Wiki · GitHub

以降はmacOSにて開発を進めてまいりますが、推奨環境は Linux です。


macOSにて開発なさる方で導入に苦労されている方がいらっしゃれば、エラー内容と共にコメントください。

gtk-fortran開発者殿はmacOSに詳しくないらしく、一部手動でソースコードを手直し、インストールする必要がございます。)




まずは,単純にウィンドウを表示させるサンプルコードです。

program show_window
  !--------------------------------------------!
  !--- ファイル名は hogehoge.f90 とします。
  !--------------------------------------------!
  use iso_c_binding
  use gtk
  !---
  implicit none
  type(c_ptr) :: window

  !--- GTK+の初期化
  call gtk_init()

  !--- ウィンドゥの設定
  !  第一引数:ウィンドゥの種類
  !    GTK_WINDOW_TOPLEVEL:アプリケーションのメインになるようなウィンドゥ
  !    GTK_WINDOW_POPUP   :クリックした時にポップアップ表示されるようなウィンドゥ
  window = gtk_window_new(GTK_WINDOW_TOPLEVEL)

  !--- タイトルを設定
  call gtk_window_set_title(window, "Hello! World!"//c_null_char)

  !--- ウィンドゥの大きさ設定
  !    第一引数:ウィジェット
  !    第二引数:ウィジェットの幅
  !    第三引数:ウィジェットの高さ
  call gtk_widget_set_size_request(window, 300, 200)

  !--- ウィンドゥの表示
  !    第一引数:表示するウィジェット
  call gtk_widget_show(window)

  !--- メインループ
  call gtk_main()
end program show_window

hogehoge.f90をコンパイルして実行しましょう。

$ gfortran hogehoge.f90 -o hogehoge `pkg-config --cflags --libs gtk-2-fortran` -Wl,-no_pie
$ ./hogehoge


実行すると次のように表示されます。これでwindow表示ができるようになりました。

f:id:convergence_hub:20170115122250p:plain

ドバイ

暗号通貨

まさか1年以上ぶりの更新になるとは思いませんでした。
今回は、注目しているドバイの成長戦略(暗号通貨絡み)について綴ります。
(深層学習や自作OSについても、徐々に記事を増やしていければと思います。)

今回は暗号通貨を知る経緯までになる予定です。


バイの経済成長

 皆様はドバイに対してどのようなイメージをお持ちでしょうか?私は一大リゾート都市で富豪が多いイメージですが、実際そのようです。気まぐれでドバイについて調べていました。

バイの経済発展について、時系列を参考文献と共に簡単に追っていきたいと思います。

・〜2007年
 ドバイ経済の現状と課題:
http://www.ndl.go.jp/jp/diet/publication/refer/200907_702/070204.pdf

なるほど、「陸・海・空の インフラ整備、フリーゾーンの整備と外資誘致、 観光・レジャーの振興、不動産保有の自由化、 外国人労働力の活用」によって経済発展してきたのですね。そしてその背景には、政治的安定性があったようです。

一方で、この時点で、今後の課題として、「経済の対外依存性の増大」・「労働の自国民化不足」・「外国人人口の急拡大によるコミュニティの分断」が挙げられています。



・2007年〜2015年
 Dubai Strategic Plan 2015:
www.dubaiplan2021.ae
大きく5つの柱が示されています。

 ● Economic Development
 ● Social Development
 ● Security, Justice, & Safety
 ● Infrastructure, Land, & Environment
 ● Government Excellence

この時期に対外依存しない経済政策を実施し始めたのですね。インフラ政策で自国民の雇用も創出しています。さらにコミュニティの分断についても、Social Developmentの中に"National Identity and Social Cohesion"という文言が明記されており、課題をきちんと認識した上での対策が練られています。
その結果、現在においてもなおドバイは成長し続けています。そんなドバイの将来の政策については、Dubai Plan 2021が発表されています。



・2015年〜2021年
Dubai Plan 2021:
Dubai Plan 2021 | Dubai Plan 2021
計画の柱は次の通りです。

 ● The People: “City of Happy, Creative & Empowered People”
 ● The Society: “An Inclusive & Cohesive Society”
 ● The Experience: “The Preferred Place to Live, Work & Visit”
 ● The Place: “A Smart & Sustainable City”
 ● The Economy: “A Pivotal Hub in the Global Economy”
 ● The Government: “A Pioneering and Excellent Government”

2015年のものと比較して、業績評価指標(Key Prformance Indicator, KPI)が設定されており、その計画において何が達成されれば成功なのか、より具体的に示されている印象を受けます。


6つの柱のうち、私が個人的に注目しているのは2つあり、「The Place」と「The Economy」です。
ビジネス・投資が世界一しやすい経済を目指しながら、インフラ整備によりスマートシティも実現することは非常に興味深いです。
そして、ドバイはそれを実現すべく、Future Accelerators Programsを打ち出しています。
Dubai officially launches Future Accelerators programme - Gulf Business
新しいもの好きの私の興味をそそった部分を引用します。

Dubai Holding: The future of technology
Dubai Holding’s accelerator is working to develop digital solutions using artificial intelligence to increase productivity and provide services within the sectors of hospitality, real estate, and communications. One of the notable entries in DH’s accelerators is a company specializing in “Deep Learning” and building interactive 3D models, while another notable entry works on developing an international market to trade loyalty points, turning them into a form of currency.


人工知能による生産性向上深層学習3Dプリンターを用いた建築、・・・私からすると前から興味があり調べていたことではありますが、青文字については、全く何のことかさっぱりわかりませんでした。

暗号通貨(仮想通貨)とLoyyalを知ったのは、そのloyalty pointsを調べていた時でした。フィンテックと呼ばれるように、経済と技術がうまく組み合わさった面白いものだなと今は感じています。

Loyyalについて以降は書きたいと思います。

(続きは、Loyyalとその暗号通貨について執筆できればと思います。この記事に追記する形で、鋭意編集中です。目次も作る予定です。)