DXR165の備忘録

自分用の備忘録です。

UEFI BIOS Boot Mechanisms  

最終更新日 2017/10/08 16:26

2017/10/04現在、主流と思われるUEFI Specification Version 2.5 / Advanced Configuration and Power Interface Specification Version 6.2よりブートに関係する部分をGoogle翻訳により和訳しメモしておきます。

出典
Unified Extensible Firmware Interface Forum
http://www.uefi.org/specifications


Unified Extensible Firmware Interface Specification 
Version 2.5 Errata A
January, 2016




1 Introduction
このUnified Extensible Firmware Interface(以下、UEFI)仕様では、オペレーティングシステム(OS)とプラットフォームファームウェア間のインタフェースについて説明しています。 UEFIの前には、Extensible Firmware Interface Specification 1.10(EFI)がありました。その結果、一部のコードと特定のプロトコル名でEFIの指定が保持されます。特に指定のない限り、この仕様のEFI指定はUEFIの一部であると見なすことができます。
このインタフェースは、プラットフォーム関連の情報と、OSローダおよびOSで使用可能なブートおよびランタイムサービスコールを含むデータテーブルの形式です。これらは一緒になって、OSを起動するための標準的な環境を提供します。この仕様は、純粋なインタフェース仕様として設計されています。したがって、この仕様では、プラットフォームファームウェアが実装する必要があるインターフェイスと構造のセットを定義しています。同様に、仕様では、OSが起動時に使用するインタフェースと構造のセットが定義されています。ファームウェア開発者が必要な要素を実装する方法を選択するか、またはOSの開発者がこれらのインタフェースと構造を利用する方法を選択するかは、開発者にとって残された実装の決定です。
この仕様の目的は、OSとプラットフォームファームウェアがOSブートプロセスをサポートするために必要な情報のみを通信する方法を定義することです。これは、プラットフォームおよびファームウェアによってOSに提示される、ソフトウェアで表示可能なインターフェイスの正式で完全な抽象的な仕様によって実現されます。
この正式な定義を使用すると、サポートされているプロセッサ仕様と互換性のあるプラットフォーム上で動作するように意図されたシュリンクラップOSは、プラットフォームやOSのカスタマイズを行うことなく、さまざまなシステム設計で起動することができます。また、プラットフォームの革新により、OSのブートシーケンスに新しいコードを記述することなく、プラットフォーム機能を強化する新しい機能を導入することもできます。
さらに、抽象的な仕様は、レガシーデバイスとファームウェアコードを時間の経過とともに置き換えるルートを開きます。新しいデバイスタイプおよび関連するコードは、OSブートサポートコードに影響を与えずに、同じ定義された抽象インターフェースを介して同等の機能を提供することができます。
この仕様は、モバイルシステムからサーバーまでのあらゆるハードウェアプラットフォームに適用されます。この仕様では、プロトコルインタフェースの選択とともに、一連のコアサービスが提供されています。プロトコルインタフェースの選択は、様々なプラットフォーム市場セグメントに合わせて時間をかけて進化していくことができます。同時に、この仕様では、OEMが差別化を可能にするための最大限の拡張性とカスタマイズ能力が認められています。この中で、UEFIの目的は、従来の「PC-AT」スタイルのブート・ワールドから従来のAPIを使用しない環境への進化の道筋を定義することです。

1.1 UEFIドライバモデル拡張
起動デバイスへのアクセスは、一連のプロトコルインターフェイスを通じて提供されます。 UEFIドライバーモデルの1つの目的は、「PC-AT」スタイルのオプションROMの代わりを提供することです。 UEFIドライバーモデルに書き込まれたドライバーは、ブート前環境のブートデバイスにアクセスするように設計されていることを指摘することが重要です。高性能でOS固有のドライバに代わるものではありません。
UEFIドライバモデルは、起動前環境で実行されるモジュール式のコード(ドライバとも呼ばれます)の実行をサポートするように設計されています。これらのドライバは、プラットフォーム上のハードウェアバスおよびデバイスを管理または制御することができ、またはソフトウェア由来のプラットフォーム固有のサービスを提供することができる。
UEFIドライバモデルには、プラットフォームがUEFI準拠のOSをブートするために必要なバスドライバとデバイスドライバの組み合わせを設計および実装するために、UEFIドライバライタに必要な情報も含まれています。
UEFIドライバーモデルは汎用的に設計されており、あらゆるタイプのバスまたはデバイスに適合させることができます。 UEFI仕様では、PCIバスドライバ、PCIデバイスドライバ、USBバスドライバ、USBデバイスドライバ、およびSCSIドライバの書き方について説明しています。従来のオプションROMイメージとの互換性を維持しながら、PCIオプションROMにUEFIドライバを格納できるようにする追加の詳細情報が提供されています。
UEFI仕様の設計目標の1つは、ドライバイメージをできるだけ小さく保つことです。ただし、ドライバが複数のプロセッサアーキテクチャをサポートする必要がある場合、サポートされている各プロセッサアーキテクチャ用にドライバオブジェクトファイルも出荷する必要があります。このスペースの問題に対処するために、この仕様ではEFIバイトコード仮想マシンも定義しています。 UEFIドライバは、単一のEFIバイトコードオブジェクトファイルにコンパイルできます。 UEFI仕様準拠のファームウェアには、EFIバイトコードインタープリタが含まれている必要があります。これにより、複数のプロセッサアーキテクチャをサポートする単一のEFIバイトコードオブジェクトファイルを出荷することができます。もう一つの省スペース技術は、圧縮の使用です。この仕様では、UEFIドライバのサイズを縮小し、UEFIドライバがROMデバイスに格納されるときのオーバーヘッドを削減するために使用される圧縮アルゴリズムと圧縮解除アルゴリズムを定義しています。
UEFI仕様に含まれる情報は、OSV、IHV、OEM、およびファームウェアベンダーが、この仕様に準拠するファームウェアを設計および実装するために使用できます。標準プロトコルインターフェイスを生成するドライバ、およびUEFI準拠のブートに使用できるオペレーティングシステムローダオペレーティングシステム。


3 Boot Manager
UEFIブートマネージャは、アーキテクチャ上定義されたグローバルNVRAM変数を変更して設定できるファームウェアポリシーエンジンです。ブートマネージャーは、UEFIドライバーとUEFIアプリケーション(UEFI OSブートローダーを含む)をグローバルNVRAM変数で定義された順序でロードしようとします。プラットフォームのファームウェアは、通常のブートではグローバルNVRAM変数で指定されたブート順序を使用する必要があります。プラットフォームファームウェアは、余分なブートオプションを追加したり、ブート順序リストから無効なブートオプションを削除する可能性があります。
プラットフォームファームウェアは、ファームウェアブートプロセスで例外条件が検出された場合に、ブートマネージャに付加価値機能を実装することもできます。付加価値機能の1つの例は、ドライバが初めてロードされたときに起動が失敗した場合、UEFIドライバをロードしないことです。別の例では、ブートプロセスで重大なエラーが検出された場合、OEM定義の診断環境で起動します。
UEFIのブートシーケンスは、次のもので構成されています。
•ブート順序リストは、グローバルに定義されたNVRAM変数から読み込まれます。この変数への変更は、次のプラットフォームのリセット後に有効になることが保証されています。ブート順序リストは、ブート対象の情報を含むNVRAM変数のリストを定義します。各NVRAM変数は、ユーザーに表示できるブートオプションの名前を定義します。
•変数には、ハードウェアデバイスへのポインタと、ロードするUEFIイメージを含むハードウェアデバイス上のファイルも含まれます。
•変数には、OSのパーティションとディレクトリへのパスと、他の設定固有のディレクトリも含まれる場合があります。
NVRAMには、UEFIイメージに直接渡されるロードオプションも含まれます。プラットフォーム・ファームウェアは、ロード・オプションに含まれている内容を認識していません。ロードオプションは、プラットフォームのファームウェアブートポリシーを設定するためにグローバルNVRAM変数に書き込むときに、上位ソフトウェアによって設定されます。この情報は、UEFI OSローダーの場所と異なる場合は、OSカーネルの場所を定義するために使用できます。


3.5 Boot Mechanisms
EFIは、EFI_SIMPLE_FILE_SYSTEM_PROTOCOLまたはEFI_LOAD_FILE_PROTOCOLを使用してデバイスから起動できます。

EFI_SIMPLE_FILE_SYSTEM_PROTOCOLをサポートするデバイスは、そのデバイスを起動可能にするためにファイルシステムプロトコルを具体化する必要があります。

デバイスが完全なファイルシステムをサポートしない場合、EFI_LOAD_FILE_PROTOCOLが生成され、イメージを直接マテリアライズすることができます。

ブートマネージャは、最初にEFI_SIMPLE_FILE_SYSTEM_PROTOCOLを使用してブートを試みます。 それが失敗した場合、EFI_LOAD_FILE_PROTOCOLが使用されます。



3.5.1 Boot via the Simple File Protocol
EFI_SIMPLE_FILE_SYSTEM_PROTOCOLを使用して起動すると、FilePathは、そのデバイスを「話す」デバイスを指すデバイスパスから開始します
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL。

FilePathの次の部分は、起動可能なイメージを含むサブディレクトリを含むファイル名を指します。

ファイル名がヌルのデバイスパスである場合、あいまいなファイル名を持つリムーバブルメディアデバイスに対して定義されたルールを使用して、メディア上でファイル名を検出する必要があります(下の3.5.1.1項を参照)。


指定されたファイルシステムのフォーマットは12.3節に含まれています。

ファームウェアは、UEFIファイルシステムを理解するEFI_SIMPLE_FILE_SYSTEM_PROTOCOLを生成する必要がありますが、EFI_SIMPLE_FILE_SYSTEM_PROTOCOLインタフェースを使用してファイルシステムを抽象化することができます。


3.5.1.1 Removable Media Boot Behavior
リムーバブルメディアデバイスでは、FilePathにサブディレクトリを含むファイル名を含めることはできません。

FilePathList [0]は、プラットフォーム内の不揮発性メモリに格納され、いつでも変更できるメディアと同期して保持することはできません。

リムーバブルメディアデバイスのFilePathList [0]は、EFI_SIMPLE_FILE_SYSTEM_PROTOCOLまたはEFI_BLOCK_IO_PROTOCOLをサポートするデバイスを指します。

FilePathList [0]には、ファイル名またはサブディレクトリは含まれません。

FilePathList [0]がEFI_SIMPLE_FILE_SYSTEM_PROTOCOLをサポートするデバイスを指している場合、システムファームウェアは、デフォルトのファイル名を\ EFI \ BOOT \ BOOTx64.EFI形式(x64マシンの場合)で追加して、リムーバブルメディアFilePathList [0]から起動しようとします。

machine type short-nameはPE32 +イメージフォーマットアーキテクチャを定義します。

各ファイルにはUEFIイメージタイプが1つのみ含まれています。システムは1つ以上のイメージタイプからの起動をサポートしています。 表12に、UEFIイメージ・タイプを示します。

3.5.2 Boot via LOAD_FILE PROTOCOL


7 Services — Runtime Services
7.2 Variable Services
変数は、情報と属性(キー)と任意のデータ(値)の識別で構成されるキーと値のペアとして定義されます。 変数は、プラットフォームに実装されたEFI環境と、EFI環境で実行されるEFI OSローダーおよびその他のアプリケーション間で渡されるデータを格納する手段として使用することを目的としています。
変数の実装はこの仕様では定義されていませんが、変数はほとんどの場合永続的でなければなりません。 これは、プラットフォーム上のEFI実装は、少なくとも明示的に削除または上書きされるまで、システムがブートするたびに、格納用に渡された変数が保持され、使用可能になるように配列を配置する必要があることを意味します。 この種の不揮発性ストレージの提供は、一部のプラットフォームでは非常に制限される可能性があるため、他の情報伝達手段を使用できない場合は、変数を控えめに使用する必要があります。

Table 33 lists the variable services functions described in this section:
Table 33. Variable Services Functions
Name Type Description
GetVariable Runtime Returns the value of a variable.
GetNextVariableName Runtime Enumerates the current variable names. 
SetVariable Runtime Sets the value of a variable.
QueryVariableInfo() Runtime Returns information about the EFI variables


9 Protocols — Device Path Protocol
9.1 Device Path Overview
デバイスパスは、デバイスへのプログラムパスを定義するために使用されます。

デバイスパスの主な目的は、OSローダなどのアプリケーションが、インタフェースが抽象化している物理デバイスを特定できるようにすることです。

デバイスパスの集合は、通常、名前空間と呼ばれます。

たとえば、ACPIは、ASL(ACPI Source Language)で書かれた名前空間の周りにあります。

可能な限りEFIがACPIを置き換えずにACPIに代わってしまうことを考えると、EFIのACPIネームスペースを利用することは理にかなっているようです。

ただし、ACPIネームスペースは、オペレーティングシステムのランタイムで使用するように設計されており、プラットフォームのファームウェアやOSローダーには適していません。

このため、EFIはデバイスパスと呼ばれる独自の名前空間を定義します。

デバイスパスは、ACPIネームスペースを最大限活用するように設計されています。

デバイスパスの主要な構造の1つは、ACPIネームスペースへのリンケージを定義します。

デバイスパスは、ACPIが標準の列挙アルゴリズムでバスに接続するギャップを埋めるためにも使用されます。

デバイスパスは、バス上で使用されているデバイスに関する情報を、標準の列挙メカニズムと関連付けることができます。

デバイスパスは、ファイルが存在すべき場所、またはファイルがロードされた場所のメディア上の場所を定義するためにも使用されます。

デバイスパスの特殊なケースは、レガシーメディアからのレガシーオペレーティングシステムのオプションのブートをサポートするためにも使用できます。

デバイスパスは、OSローダとオペレーティングシステムが、プラットフォームファームウェアがどのデバイスをブートデバイスとして使用しているかを知ることができるように設計されています。

これにより、オペレーティングシステムは、プラットフォームファームウェアと一致するシステムのビューを維持することができます。

これの一例は、ブートデバイスおよびコンソールとしてネットワーク接続を使用している「ヘッドレス」システムです。

このような場合、ファームウェアは、オペレーティングシステムに、ネットワークアダプタおよびネットワークプロトコル情報をコンソールとして使用し、これらのデバイスのデバイスパス内のブートデバイスとして使用します。


9.2 EFI Device Path Protocol

Protocol Interface Structure
//*******************************************************
// EFI_DEVICE_PATH_PROTOCOL
//*******************************************************
typedef struct _EFI_DEVICE_PATH_PROTOCOL {
UINT8 Type;
UINT8 SubType;
UINT8 Length[2];
} EFI_DEVICE_PATH_PROTOCOL;



9.3 Device Path Nodes
Device Pathノードには主に6つのタイプがあります。

Hardware Device Path.
このデバイスパスは、システムのリソースドメインにデバイスがどのように接続されるかを定義します。リソースドメインは、システムの共有メモリ、メモリマップI / O、およびI / Oスペースです。

ACPI Device Path.
このデバイスパスは、列挙が業界標準の方法で記述されていないデバイスを記述するために使用されます。これらのデバイスは、ACPI名前空間でACPI AMLを使用して記述する必要があります; このデバイスパスは、ACPIネームスペースへのリンケージです。

Messaging Device Path.
このデバイスパスは、システムのリソースドメイン外のデバイスの接続を記述するために使用されます。このデバイスパスは、SCSI IDなどの物理的なメッセージング情報、またはネットワークプロトコルIPアドレスなどの抽象的な情報を記述できます。

Media Device Path.
このデバイスパスは、ブートサービスによって抽象化されているメディアの部分を記述するために使用されます。たとえば、メディアデバイスパスは、ハードドライブ上のどのパーティションが使用されているかを定義できます。

BIOS Boot Specification Device Path.
このデバイスパスは、レガシーオペレーティングシステムの起動を指示するために使用されます。 BIOSブート仕様バージョン1.01に基づいています。 この仕様を取得するための詳細については付録Qを参照してください。

End of Hardware Device Path.
サブタイプに応じて、このデバイスパスノードは、デバイスパスインスタンスまたはデバイスパス構造の終わりを示すために使用されます。


9.3.1 Generic Device Path Structures
Type
Type 0 1 Type 0x01 – Hardware Device Path
Type 0x02 – ACPI Device Path
Type 0x03 – Messaging Device Path
Type 0x04 – Media Device Path
Type 0x05 – BIOS Boot Specification Device Path
Type 0x7F – End of Hardware Device Path

Sub-Type 
Varies by Type. 

Length
Length of this structure in bytes. Length is 4 + n bytes.

Specific Device Path Data
Type and Sub-Type define type of data. Size of data is included in Length.


9.3.2 Hardware Device Path

9.3.2.1 PCI Device Path
Type 1 – Hardware Device Path
Sub-Type 1 – PCI
Length 6 bytes
Function (4,1)
PCI Function Number
Device (5,1)
PCI Device Number

9.3.5 Messaging Device Path

9.3.5.5 USB Device Paths
Type 3 – Messaging Device Path
Sub-Type 5 – USB
Length 6 bytes.
USB Parent Port Number (4,1)
USB Parent Port Number
Interface (5,1)
USB Interface Number



9.3.3 ACPI Device Path
このデバイスパスには、デバイスのプラグアンドプレイハードウェアIDと対応する一意の永続IDを表すACPIデバイスIDが含まれています。

 ACPI IDは、デバイスに関連付けられたACPI _HID、_CID、_UIDのデバイス識別オブジェクトに格納されます。

ACPIデバイスパスには、プラットフォームファームウェアからオペレーティングシステムに提供されるACPIネームスペースと正確に一致する必要がある値が含まれています。

_HID、_CID、_UIDのデバイス識別オブジェクトの詳細については、ACPI仕様を参照してください。

_HIDと_CIDの値は、ACPI名前空間に表示されるオプションのデバイス識別オブジェクトです。

_HIDのみが存在する場合は、_HIDを使用して、ACPIドライバによって列挙されるすべてのデバイスを記述する必要があります。

_CIDは、存在する場合、OSが接続するために重要な情報を含んでいます
汎用ドライバ(例えばPCIバスドライバ)であり、_HIDにはOS固有の情報が含まれ、デバイス固有のドライバを接続する。

ACPIバスドライバは、デバイス用の標準バス列挙子が存在しない場合にのみ、デバイスを列挙します。

_UIDオブジェクトは、再起動後も変更されないデバイスのシリアル番号スタイルのIDをOSに提供します。

オブジェクトはオプションですが、同じ_HIDを報告する2つのデバイスがシステムに含まれている場合に必要です。

_UIDは、同じ_HID値を持つすべてのデバイスオブジェクト間で一意である必要があります。

_HIDのAPCI名前空間に_UIDが存在しない場合は、ACPIデバイスパスの_UIDフィールドにゼロの値を格納する必要があります。

ACPIデバイスパスは、ハードウェアデバイスパスで定義されていないデバイスの記述にのみ使用されます。

PCI仕様ではPCIルートブリッジのプログラミングモデルが定義されていないため、_HID(存在する場合は_CIDとともに)がPCIルートブリッジを表すために必要です。

ACPIデバイスパスには、_HIDフィールドと_UIDフィールドのみを含む単純なサブタイプと_HID、_CID、および_UIDフィールドを含む拡張サブタイプの2つのサブタイプがあります。

ACPIデバイスパスノードは、_HIDおよび_UID値の数値32ビット値のみをサポートします。

拡張ACPIデバイスパスノードは、_HID、_UID、および_CIDの値の数値と文字列の両方の値をサポートします。

その結果、ACPI Device Pathノードは小さくなり、可能であれば不揮発性ストレージに格納される可能性のあるデバイスパスのサイズを縮小するために使用する必要があります。

_HIDフィールドに文字列値が必要な場合、または_UIDフィールドに文字列値が必要な場合、または_CIDフィールドが必要な場合は、展開されたACPIデバイスパスノードを使用する必要があります。

拡張ACPIデバイスパスノードの文字列フィールドが存在する場合、対応する数値フィールドは無視されます。

ACPIデバイスパスノードと拡張ACPIデバイスパスノードの_HIDフィールドと_CIDフィールドは、32ビットの圧縮EISAタイプのIDとして格納されます。

次のマクロは、プラグアンドプレイハードウェアIDからこれらのEISAタイプのIDを計算するために使用できます。

EFIデバイスパスノードの_HIDフィールドと_CIDフィールドを計算するために使用されるプラグアンドプレイハードウェアIDは、ACPIテーブルに一致するエントリを作成するために使用されるプラグアンドプレイハードウェアIDと一致する必要があります。

このマクロによって生成された圧縮EISAタイプのIDは、ACPIテーブルに格納されている圧縮されたEISAタイプのIDとは異なります。

その結果、ACPIデバイスパスノードからの圧縮されたEISAタイプのIDは、ACPIテーブルの圧縮されたEISAタイプのIDと直接比較できません。


Type 2 – ACPI Device Path.
Sub-Type 1 ACPI Device Path.
Length 12 bytes.
_HID (4,4)
Device’s PnP hardware ID stored in a numeric 32-bit compressed EISA-type ID. This value must match the corresponding _HID in the ACPI name space.
_UID (8,4)
Unique ID that is required by ACPI if two devices have the same _HID. This value must also match the corresponding _UID/_HID pair in the ACPI name space. Only the 32-bit numeric value type of _UID is supported; thus strings must not be used for the _UID in the ACPI name space.



9.3.6 Media Device Path
This Device Path is used to describe the portion of the medium that is being abstracted by a boot
service. An example of Media Device Path would be defining which partition on a hard drive was
being used.

9.3.6.1 Hard Drive
ハードドライブメディアデバイスパスは、ハードドライブ上のパーティションを表すために使用されます。

各パーティションには少なくともハードドライブデバイスパスノードがあり、それぞれがパーティションテーブルのエントリを記述します。

EFIは、MBRおよびGPTパーティショニング形式をサポートしています。

 パーティションは、それぞれのパーティションテーブルのエントリに応じて1から始まる番号に従って番号が付けられます。

パーティションは、LBAゼロで始まるEFIで処理されます。

パーティション番号0は、生のハードドライブまたは生の拡張パーティションを表すために使用できます。

新しいパーティションフォーマットが将来サポートされるように、パーティションフォーマットはデバイスパスに保存されます。

ハードドライブデバイスパスには、ディスクシグネチャとディスクシグネチャタイプも含まれています。

ディスク署名はOSによって維持され、Device Pathノードを分割するためにEFIによってのみ使用されます。

ディスク署名は、OSが物理的にシステム内を移動した後でもディスクを検出できるようにします。

セクション3.1.2は、ハードドライブメディアデバイスパスを処理するための特別なルールを定義しています。

これらの特別なルールにより、ディスクの場所が変更され、ディスクからのシステム起動が可能になります。

Type 4 – Media Device Path
Sub-Type 1 – Hard Drive
Length 42 bytes.
Partition Number 4 4
Describes the entry in a partition table, starting with entry 1.
Partition number zero represents the entire device. Valid
partition numbers for a MBR partition are [1, 4]. Valid partition
numbers for a GPT partition are [1,
NumberOfPartitionEntries].
Partition Start 8 8
Starting LBA of the partition on the hard drive
Partition Size 16 8
Size of the partition in units of Logical Blocks
Partition Signature 24 16 
Signature unique to this partition:
• If SignatureType is 0, this field has to be initialized with 16
zeroes.
• If SignatureType is 1, the MBR signature is stored in the
first 4 bytes of this field. The other 12 bytes are initialized
with zeroes.
• If SignatureType is 2, this field contains a 16 byte
signature.
Partition Format 40 1
Partition Format: (Unused values reserved)
0x01 – PC-AT compatible legacy MBR (see Section 5.2.1).
Partition Start and Partition Size come from
PartitionStartingLBA and PartitionSizeInLBA for
the partition.
0x02 – GUID Partition Table (see Section 5.3.2).
Signature Type 41 1
Type of Disk Signature: (Unused values reserved)
0x00 – No Disk Signature.
0x01 – 32-bit signature from address 0x1b8 of the type
0x01 MBR.
0x02 – GUID signature.



9.4 Device Path Generation Rules
9.4.2 Rules with ACPI _HID and _UID
ACPI仕様で説明したように、ACPIは_HID、_CID、_UIDなど、いくつかの異なる種類のデバイス識別オブジェクトをサポートしています。

_UIDデバイス識別オブジェクトはACPIではオプションであり、同じIDを持つ複数の_HIDが存在する場合にのみ必要です。

ACPI名前空間が_UIDを実装していない場合、ACPIデバイスパス構造には_UIDフィールドにゼロが含まれている必要があります。

_UIDフィールドは、再起動後も保持される一意のシリアル番号です。

ACPI名前空間内のデバイスが_HIDを持ち、_CRS(Current Resource Setting)で記述されている場合は、ACPIデバイスパス構造で記述する必要があります。

_CRSは、デバイスが他の標準によってマッピングされていないことを意味します。

_CRSは、非標準デバイスをプラグアンドプレイデバイスにするためにACPIによって使用されます。

ACPIネームスペースの設定方法により、ACPIドライバは標準的な方法でデバイスを設定できます。

_CIDが存在すると、ACPI Device PathノードまたはExpanded ACPI Device Pathノードを使用する必要があるかどうかが決まります。

Table 93. ACPI _CRS to EFI Device Path Mapping
---------------------------------------------------------------------------
PCI Root Bus -> ACPI Device Path: _HID PNP0A03, _UID
---------------------------------------------------------------------------

ルートPCIブリッジのサポートには、EFIデバイスパスに特別なルールが必要です。

ルートPCIブリッジは、通常、独自のバスを消費し、PCIバスを生成するチップセットに含まれるPCIデバイスです。

典型的なデスクトップおよびモバイルシステムでは、ルートPCIブリッジは1つだけです。

大規模なサーバーシステムには、通常複数のルートPCIブリッジがあります。

ルートPCIブリッジの動作は、現在のPCI仕様では定義されていません。

ルートPCIブリッジは、PCIバスを消費して生成するPCI対PCIブリッジと混同しないでください。

PCI-PCIブリッジの動作と構成は、現在のPCI仕様で完全に規定されています。

ルートPCIブリッジは、PNP0A03のプラグアンドプレイIDを使用します。これは、ACPIデバイスパス_HIDフィールドまたは拡張ACPIデバイスパス_CIDフィールドに格納され、ACPIネームスペースと一致します。

ACPIデバイスパス構造の_UIDは、ACPI名前空間の_UIDと一致する必要があります。




9.6 EFI Device Path Display Format Overview
このセクションでは、EFIデバイスパスプロトコルとテキストの間の推奨される変換について説明します。 また、これらを実装するための標準プロトコルについても説明します。 目標は次のとおりです。
•標準化された表示形式。 これにより、ドキュメントおよびテストツールは、複数のベンダーが提供するドライバからの出力を理解することができます。
•読みやすさを向上させる。 デバイスのパスは人が読む必要があるため、フォーマットは解読できる形式で、業界標準のデータ提示手段を可能な限り維持する必要があります。 この場合、表示専用フォームと解析可能フォームの2つのフォームがあります。
•必要に応じて、テキストからバイナリ形式への往復変換、およびテキストの損失なし。
•コマンドラインの解析が簡単です。 デバイスパスは、シェルから実行されるUEFIアプリケーションのコマンドラインに表示される可能性があるため、アプリケーションまたはシェルによって基本コマンドライン処理を禁止してはいけません。

9.6.1 Design Discussion


9.6.1.6 Text Device Node Reference
Parameter Types
Table 95. EFI Device Path Option Parameter Values

EISAID 
ACPI仕様で使用される形式の7文字のテキスト識別子。 最初の3文字は大文字または小文字のアルファベットでなければなりません。 2番目の4文字は、数字、大文字または小文字の16進数です。 オプションで、番号0にすることもできます。



Table 96. Device Node Table


Type: 2 (ACPI Device Path)
SubType: 1 (ACPI Device Path)
HID=PNP0A03
PciRoot(UID)
The UID parameter is an integer. It is optional but required for display.
The default value is zero.





Type: 4 (Media Device Path)
SubType: 1 (Hard Drive)
HD(Partition,Type,Signature,Start, Size)
HD(Partition,Type,Signature) (Display Only)
The Partition is an integer representing the partition number. It is
optional and the default is 0. If Partition is 0, then Start and Size are
prohibited.
The Type is an integer between 0-255 or else the keyword MBR (1) or
GPT (2). The type is optional and the default is 2.
The Signature is an integer if Type is 1 or else GUID if Type is 2. The
signature is required.
The Start is a 64-bit unsigned integer. It is prohibited if Partition is 0.
Otherwise it is required.
The Size is a 64-bit unsigned integer. It is prohibited if Partition is 0.
Otherwise it is required.


12 Protocols - Media Access
12.1 Load File Protocol
This section defines the Load File protocol. This protocol is designed to allow code running in the
boot services environment to find and load other modules of code.

12.4 Simple File System Protocol
This section defines the Simple File System protocol. This protocol allows code running in the EFI
boot services environment to obtain file based access to a device.
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL is used to open a device volume and return an
EFI_FILE_PROTOCOL that provides interfaces to access files on a device volume.


13 Protocols - PCI Bus Support
13.2.1 PCI Root Bridge Device Paths
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOLは、ドライバがサービスを利用できるようにハンドルにインストールする必要があります。 EFI_PCI_ROOT_BRIDGE_IO_PROTOCOLに加えて、
EFI_DEVICE_PATH_PROTOCOLも同じハンドルにインストールする必要があります。 EFI_DEVICE_PATH_PROTOCOLの詳細については、第9章を参照してください。
通常、ACPIデバイスパスノードは、PCIルートブリッジを記述するために使用されます。システム内のバス階層に応じて、追加のデバイスパスノードがこのACPIデバイスパスノードに先行する場合があります。デスクトップシステムには通常、PCIルートブリッジが1つしか含まれていないため、EFI_PCI_ROOT_BRIDGE_IO_PROTOCOLとEFI_DEVICE_PATH_PROTOCOLのハンドルが1つあります。サーバーシステムには複数のPCIルートブリッジが含まれている可能性があるため、それぞれのPCIルートブリッジのハンドルこれらのハンドルのうち、
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOLおよびEFI_DEVICE_PATH_PROTOCOLが含まれます。どの場合も、PCIルートブリッジのACPIデバイスパスノードの内容は、そのシステムのACPIテーブルにある情報と一致する必要があります。
表112に、デスクトップシステムのPCIルートブリッジのデバイスパスの例を示します。 現在、デスクトップシステムには通常、1つのPCIルートブリッジが含まれています。 このデバイスパスは、ACPIデバイスパスノードとデバイスパスエンド構造で構成されています。 _HIDおよび_UIDは、PCIルートブリッジのACPIテーブル記述と一致していなければなりません。 PCIルートブリッジが1つしかないシステムの場合、_UID値は通常0x0000です。 このデバイスパスの簡略表記は、ACPI(PNP0A03,0)です。

Table 112. PCI Root Bridge Device Path for a Desktop System
Type 0x02 – ACPI Device Path.
Sub Type 0x01 - ACPI Device Path.
Length 0x0C - 12bytes.
_HID (4,4) 0x41D0, 0x0A03  
PNP0A03 – 0x41D0 represents the compressed string ‘PNP’ and is  encoded in the low order bytes.  The compression method is described in the ACPI Specification.
_UID (8,4) 0x0000


16 Protocols — USB Support
16.1 USB2 Host Controller Protocol
セクション16.1とセクション16.1.1は、USB2ホストコントローラプロトコルについて説明します。 このプロトコルは、USB2ホストコントローラのI / O抽象化を提供します。 USB2ホストコントローラは、ユニバーサルシリアルバス(USB)にインタフェースするハードウェアコンポーネントです。 データ構造を処理し、USB上でトランザクションを生成することにより、システムメモリとUSB上のデバイス間でデータを移動します。 このプロトコルは、ユニバーサルシリアルバスを介してすべてのデータトランザクションを実行するためにUSBバスドライバによって使用されます。 また、USBホストコントローラに統合されたUSBルートハブを管理するためのサービスも提供します。 USBデバイスドライバはこのプロトコルを直接使用しません。 代わりに、USBバスドライバによって生成されたI / O抽象化を使用します。 このプロトコルは、USBバスに直接アクセスする必要のあるドライバのみが使用する必要があります。

16.1.1 USB Host Controller Protocol Overview
USBホストコントローラプロトコルは、EFIブートサービス環境で動作するコード(通常はUSBバスドライバ)によって使用され、USBバスを介してデータトランザクションを実行します。さらに、USBバスのルートハブの抽象化も提供します。
EFI_USB2_HC_PROTOCOLで提供されるインタフェースは、USBバス上のデータトランザクションを管理するために使用されます。また、USBルートハブの制御方法も提供します。 EFI_USB2_HC_PROTOCOLは、USB 1.1およびUSB 2.0準拠のホストコントローラの両方をサポートするように設計されています。
EFI_USB2_HC_PROTOCOLは、EHCI、UHCIおよびOHCI標準で動作するように設計された基本機能を抽象化しています。このプロトコルを使用することで、基盤となるUSBホストコントローラがXHCI、EHCI、OHCI、またはUHCI規格に準拠しているかどうかを知ることなく、単一のUSBバスドライバを実装できます。
EFI_USB2_HC_PROTOCOLの各インスタンスは、プラットフォーム内のUSBホストコントローラに対応しています。プロトコルは、USBホストコントローラの親バスタイプのデバイスドライバによって作成されたUSBホストコントローラのデバイスハンドルに接続されています。たとえば、PCIデバイスとして実装されているUSBホストコントローラには、PCIデバイスドライバがEFI_USB2_HC_PROTOCOLのインスタンスを生成する必要があります。





Advanced Configuration and Power Interface Specification
Version 6.2
May 2017

Overview
What is ACPI?
ACPIは、まず、ホストOS内にサブシステムを形成する、アーキテクチャに依存しない電源管理および構成フレームワークとして理解できます。 このフレームワークは、電源状態(スリープ、休止状態、起床など)を定義するハードウェアレジスタセットを確立します。 ハードウェアレジスタセットは、専用ハードウェアおよび汎用ハードウェアでの操作に対応できます。
標準のACPIフレームワークとハードウェアレジスタセットの主な目的は、OSからファームウェアをネイティブに直接呼び出さずに電源管理とシステム構成を可能にすることです。 ACPIは、図0-1および図0-2に示すように、システムファームウェア(BIOS)とOSの間のインターフェイスレイヤーとして機能し、一定の制限とルールを備えています。

Operating System
↑           ↓
ACPI subsystem
System firmware
Figure 0-1. ACPI overview

基本的に、ACPIは、システムファームウェアとOSの間で共有されるデータテーブルと定義ブロックの2種類のデータ構造を定義します。 これらのデータ構造は、ファームウェアとOSとの間の主要な通信メカニズムです。 データテーブルは生データを格納し、デバイスドライバによって消費されます。 定義ブロックは、インタプリタによって実行可能なバイトコードで構成されます。

DATA Tables           
                                   OS
                                   ↓
Definition blocks →   AML interpliter ⇔ ACPI namespace ( Objects )
                                   ↓ 
                               System hardware
Figure 0-2. ACPI structure

この定義ブロックのバイトコードは、ACPIソース言語(ASL)コードからコンパイルされます。 ASLは、ACPIオブジェクトの定義と制御メソッドの記述に使用される言語です。 ASLコンパイラは、ASLをACPIマシン言語(AML)バイトコードに変換します。 AMLは、図0-3に示すように、AMLインタプリタによって処理される言語です。

ASL code
   ↓
ASL compiler
   ↓
[Definition blocks ( AML byte bode )]]
   ↓
AML interpliter
Figure 0-3. ASL and AML

AMLインタプリタはバイトコードを実行し、定義ブロック内のオブジェクトを評価して、バイトコードがループ構成、条件付き評価、アクセス定義済みアドレス空間を実行し、アプリケーションが必要とするその他の操作を実行できるようにします。 AMLインタプリタは、システムメモリ、I / O、PCI構成など、定義されたアドレス空間への読み取り/書き込みアクセス権を持ちます。オブジェクトと呼ばれるエントリポイントを定義することによって、これらのアドレス空間にアクセスします。オブジェクトは直接定義された値を持つことができます。そうでなければ、AMLインタプリタによって評価され、解釈されなければなりません。
列挙可能なオブジェクトのこのコレクションは、ACPI名前空間と呼ばれるOS構成です。名前空間は、システム上のACPIデバイスの階層表現です。システムバスは、これらのACPIデバイスの列挙のルートです。 PCIまたはUSBデバイスのような他のバスで列挙可能なデバイスは、通常、ネームスペースに列挙されません。代わりに、独自のバスがデバイスを列挙し、ドライバをロードします。ただし、すべての列挙可能なバスには、ACPIが通常これらのデバイスのドライバを読み込まないにもかかわらず、ACPIでデバイスのバス固有のアドレスをエンコードできるようにするエンコード技術があります。
一般に_HIDオブジェクト(ハードウェア識別オブジェクト)を持つデバイスは列挙され、そのドライバはACPIによってロードされます。 _ADRオブジェクト(物理アドレスオブジェクト)を持つデバイスは、通常、ACPIによって列挙されず、一般にACPIによってドライバがロードされません。 _ADRデバイスは通常、ACPIを必要とせずにすべての必要な機能を実行できますが、デバイスドライバが機能を実行できない場合、またはドライバがシステムファームウェアと通信する必要がある場合、ACPIはオブジェクトを評価して必要な機能を実行できます。
一例として、PCIはネイティブのホットプラグをサポートしていません。しかし、PCIはACPIを使用してオブジェクトを評価し、PCI上でホットプラグを実行するために必要な機能をACPIが満たすようにするメソッドを定義することができます。
ACPIの追加の側面は、システム操作中に発生するACPI割り込みイベントを処理する実行時モデルです。 ACPIは、これらのイベントを処理するために必要なオブジェクトを評価し続けます。この割り込みベースのランタイムモデルについては、以下のランタイムモデルのセクションで詳しく説明します。

ACPI Initialization
ACPIがどのように動作するかを理解する最良の方法は、時系列です。ユーザがシステムの電源を入れると、システムファームウェアはセットアップ、初期化、および自己テストを完了します。
その後、システムファームウェアは、ブートストラップローダに制御を渡す前に、ファームウェアの初期化中に得られた情報を使用して、必要に応じて様々なプラットフォーム構成および電源インタフェースデータでACPIテーブルを更新する。拡張ルートシステム記述テーブル(XSDT)は、ACPIサブシステムによって使用される最初のテーブルであり、システム上の他のACPIテーブルの大部分のアドレスを含みます。 XSDTは、固定ACPI記述テーブル(FADT)と、初期化時にOSが処理する他の主要テーブルを指します。 OSが初期化されると、FADTはACPIサブシステムを、定義ブロックを含む最初のテーブルであるため、ネームスペースの始まりである差別化システム記述テーブル(DSDT)に指示します。
次に、ACPIサブシステムはDSDTを処理し、ACPI定義ブロックから名前空間を構築し始める。また、XSDTはセカンダリシステム記述テーブル(SSDT)を指し、名前空間に追加します。 ACPIデータテーブルは、システムハードウェアに関するOS rawデータを提供します。
OSがACPIテーブルからネームスペースを構築した後、OSはネームスペース内で遭遇するすべての_HIDデバイスのネームスペースとローディングデバイスドライバをトラバースし始めます。

System firmware
XSDT
[FADT /  SSDTs  /  Major ACPI tabels]

XSDT → DSDT

[DSDT  /  SSDTs] → ACPI namespace
Figure 0-4. ACPI initialization

1 Introduction
ACPI(Advanced Configuration and Power Interface)仕様は、堅牢なオペレーティングシステム(OS)指向のマザーボードデバイス構成と、デバイスとシステム全体の電源管理を可能にする業界共通インタフェースを確立するために開発されました。 ACPIは、オペレーティングシステムが指向する構成と電源管理(OSPM)の重要な要素です。
ACPIは、Power Management BIOSコード、Advanced Power Management(APM)アプリケーションプログラミングインターフェイス(API、PNPBIOS API、マルチプロセッサ仕様(MPS)テーブルなど)の既存のACPI前コレクションを、明確な電力管理および構成インターフェイス仕様に展開しました。 ACPIは、既存の(レガシー)ハードウェアからACPIハードウェアへの秩序ある移行手段を提供し、ACPIとレガシーの両方のメカニズムを単一のマシンに存在させ、必要に応じて使用することができます。
さらに、元のACPI仕様の開始時に構築されたシステム・アーキテクチャーは、歴史的な「プラグ・アンド・プレイ」インターフェースの限界を広げました。 ACPIは、より堅牢で潜在的により効率的な方法で高度なアーキテクチャをサポートするために、既存のマザーボード構成インタフェースを進化させました。
この仕様書で定義されているインタフェースとOSPMの概念は、デスクトップ、モバイル、ワークステーション、およびサーバマシンを含むすべてのコンピュータクラスに適しています。電源管理の観点から、OSPM / ACPIは、システム全体を低電力状態(スリープ状態)にするなど、未使用のデバイスを低電力状態に移行することによって、システムがエネルギーを節約するというコンセプトを推進します。
このドキュメントでは、ACPIハードウェアインターフェイス、ACPIソフトウェアインターフェイス、およびACPIデータ構造について説明します。このインターフェイスは、実装すると、堅牢なOS指向の構成と電源管理(OSPM)をサポートします。


2 Definition of Terms
2.1 General ACPI Terminology
Operating System-directed Power Management (OSPM)
A model of power (and system) management in which the OS plays a central role and uses global information to optimize system behavior for the task at hand.


3 ACPI Concepts
3.7 Configuration and “Plug and Play”
電源管理に加えて、ACPIインターフェイスは、OSPMがマザーボードデバイスの必要なリソースを動的に挿入および削除できるように設定するためのコントロールと情報を提供します。 差別化システム記述テーブル(DSDT)および二次システム記述テーブル(SSDT)を含むACPI定義ブロックは、ACPI名前空間と呼ばれる階層形式のマザーボードデバイスを記述する。 OSは、ハードウェアIDを持つデバイスを探してACPI名前空間を読み込むだけで、マザーボードデバイスを列挙します。
ACPIによって列挙される各デバイスには、デバイスが占有する可能性があるハードウェアリソース、デバイスで現在使用されているリソースを報告するオブジェクト、およびそれらのリソースを構成するオブジェクトを報告するACPI名前空間のACPI定義オブジェクトが含まれます。 この情報は、デバイスを構成するためにプラグアンドプレイOS(OSPM)によって使用されます。


4 ACPI Hardware Specification
ACPIは、ACPI互換のOSがACPI互換のハードウェアプラットフォームを制御および通信できる標準的なインターフェイスメカニズムを定義しています。ただし、ACPIハードウェア仕様が実装されている場合、プラットフォームはこのセクションの要件を満たしている必要があります(「ハードウェア削減ACPI」を参照)。
このセクションでは、ACPIのハードウェアの側面について説明します。
ACPIは、プログラミングモデルとその動作として「ハードウェア」を定義します。 ACPIは既存のレガシープログラミングモデルの多くを同じように保つよう努めています。しかし、特定の機能目標を達成するために、指定された機能は、特定のアドレッシングおよびプログラミングスキームに準拠しています。このカテゴリに属する​​ハードウェアを「固定」と呼びます。
ACPIはこれらの変更を最小限に抑えるよう努めていますが、ハードウェアエンジニアは、このセクションを注意深く読んで、レガシー専用ハードウェアモデルをACPI /レガシーハードウェアモデルまたはACPI専用ハードウェアモデルに変換するために必要な変更を理解する必要があります。
ACPIは、ハードウェアを固定または汎用の2つのカテゴリに分類します。固定カテゴリに収まるハードウェアは、ACPIのプログラミングおよび動作仕様を満たしています。一般的なカテゴリに入るハードウェアは、その実装において広範な柔軟性を有する。


5 ACPI Software Programming Model
ACPIは、第4項「ACPIハードウェア仕様」で説明しているように、ACPI互換OSがマシンのコア電源管理機能を制御するために使用するハードウェアレジスタインタフェースを定義します。ACPIは、ACPIシステムの電源管理と構成を制御するための抽象的なインタフェースも提供します。最後に、ACPIは、ACPI互換OSとプラットフォームランタイムファームウェアとの間のインターフェースを定義する。
ハードウェアベンダーが実装を柔軟に選択できるように、ACPIは表を使用してシステム情報、機能、およびそれらの機能を制御する方法を記述します。これらの表には、システムボード上のデバイス、または他のハードウェア標準を使用して検出または電源管理できないデバイスと、第3章「概要」で説明した機能が一覧表示されています。システムで使用可能な電源プレーンとクロックソース、バッテリ、システムインジケータライトなどの説明。これにより、OSPMはシステムコントロールの実装方法を知らなくてもシステムデバイスを制御できます。
このセクションで扱うトピックは次のとおりです。
•ACPIシステム記述テーブルのアーキテクチャが定義され、そのアーキテクチャでOEMが提供する定義ブロックの役割について説明します。
•ACPI名前空間の概念について説明します。

5.3 ACPI Namespace


6 Device Configuration
6.1 Device Identification Objects
6.1.5 _HID (Hardware ID)
This object is used to supply OSPM with the device’s PNP ID or ACPI ID.1
When describing a platform, use of any _HID objects is optional. However, a _HID object must be used to describe any device that will be enumerated by OSPM. OSPM only enumerates a device when no bus enumerator can detect the device ID. For example, devices on an ISA bus are enumerated by OSPM. Use the _ADR object to describe devices enumerated by bus enumerators other than OSPM.
Arguments:
None
Return Value:
An Integer or String containing the HID
A _HID object evaluates to either a numeric 32-bit compressed EISA type ID or a string. If a string, the format must be an alphanumeric PNP or ACPI ID with no asterisk or other leading characters.
A valid PNP ID must be of the form "AAA####" where A is an uppercase letter and # is a hex digit. A valid ACPI ID must be of the form "NNNN####" where N is an uppercase letter or a digit ('0'-'9') and # is a hex digit. This specification reserves the string "ACPI" for use only with devices defined herein. It further reserves all strings representing 4 HEX digits for exclusive use with PCI-assigned Vendor IDs.
Example ASL:
Name (_HID, EISAID ("PNP0C0C")) // Control-Method Power Button
Name (_HID, EISAID ("INT0800")) // Firmware Hub
Name (_HID, "ACPI0003") // AC adapter device
Name (_HID, "MSFT0003") // Vendor-defined device
Name (_HID, "80860003") // PCI-assigned device identifier



参考情報
Unified Extensible Firmware Interface Forum
Home » Developers » Registries
PNP ID AND ACPI ID REGISTRY
http://www.uefi.org/PNP_ACPI_Registry

COMPANY       PNP ID     Approved on Date
MICROSOFT    PNP         03/05/2004
INTEL CORP    ICO         08/10/2000

Vendor IDs are subject to uniqueness requirements and some ID requests may not be available. For instance, Microsoft has reserved the PNP ID’s Vendor ID "PNP" to identify various devices that do not have an existing EISA ID, as well as defining compatibility devices. These IDs are defined in the file(↓).

WINDOWS GENERIC DEVICE IDs
DEVICE ID RANGES

ID range Category
--------  -------------
PNP0xxx System devices
PNP8xxx Network adapters 
PNPAxxx SCSI, proprietary CD adapters 
PNPBxxx Sound, video capture, multimedia
PNPCxxx - Dxxx Modems
--Peripheral Buses--
PNP0A00         ISA Bus
PNP0A01         EISA Bus
PNP0A02         MCA Bus
PNP0A03         PCI Bus
PNP0A04         VESA/VL Bus

ACPI for Developers  // Bumblebee-Project/Bumblebee
https://github.com/Bumblebee-Project/Bumblebee/wiki/ACPI-for-Developers


Compaq Computer Corporation
Phoenix Technologies Ltd.
Intel Corporation
Plug and Play BIOS Specification
Version 1.0A
May 5, 1994

4.0 Configuration Support
4.7 Extended Configuration Services



Compaq Computer Corporation
Phoenix Technologies Ltd.
Intel Corporation
BIOS Boot Specification 
Version 1.01
January 11, 1996

1.0  Introduction
1.2  Related Documents
Plug and Play BIOS Specification 1.0A Compaq/Phoenix/Intel


1.3  Purpose
この仕様の目的は、BIOSがシステム内のすべてのIPL(初期プログラムロード)デバイスを識別し、ユーザーが選択した順序で優先順位を付け、次に各デバイスを順番に調べてブートを試みる方法を説明することです。 プラグアンドプレイBIOS仕様では、ブートプロセス中にBIOSに追加の要件が課せられ、CD-ROM、ネットワークリモートブート、PCMCIAなどのように起動可能なデバイスが増えているため、BIOSの起動がよりインテリジェントになります。 この仕様では、実質的に既存のIPLデバイスからのブートを可能にし、将来のIPLデバイスの定義についても十分に汎用的で柔軟性のあるブートスキームを定義することが重要です。


関連記事

category: PC-HW

tb: 0   cm: 0

コメント

コメントの投稿

Secret

トラックバック

トラックバックURL
→http://dxr165.blog.fc2.com/tb.php/403-3128d1aa
この記事にトラックバックする(FC2ブログユーザー)

プロフィール

最新コメント

カウンター(2012/3/10以降)