Leon Notes

UEFI BIOS Editor

2019-02-23T00:01:00.003+08:00

This utility can parse the standard UEFI BIOS image to extract the firmware volumes, firmware files, sections, variables IFR, etc.

Update History

Sep 07, 2026

Added Intel mFIT tooling (Tools → mFIT Config…): view, search, diff and edit mFIT platform-config XML files, cross-check a config against an opened ROM (regions, master access, every named soft strap), and decompose an image through your own mfit.exe.
Added soft-strap decode (Tools → Decode Straps…): bit-level flash-descriptor soft straps decoded with schemas harvested from your own mfit.exe — 7 platform generations, schema auto-matched from the ROM's CSE firmware version, SMIP straps included.
Strap values can be modified through mFIT itself: edit in the grid, rebuild with Intel's tool, verified automatically.
Compare ROMs is one window with four tabs now — Variables, Flash Map, Setup and Straps — sharing one Base/Other selection.
Compare Variables (byte-level variable merge) overhauled: resizable, status/GUID/size columns, search, CSV export, scroll-locked hex views with next-diff jump, and unsaved-change tracking on merged ROMs.
Device Path Converter rewritten: labeled panes, live byte-format options, Copy buttons, resizable.
Info tab shows Intel platform facts (SPI components, CSE firmware and generation, descriptor lock state) and selected soft straps.
Fixed some bugs.

Sep 05, 2026

Releases are now also published on GitHub: github.com/iorlvskyo/UefiBiosEditor-Releases.
Much faster opening of large images (the firmware and PCD trees now load on demand).
Fixed some bugs.

Jul 19, 2026

Moved to .NET 8. The .NET 8 Desktop Runtime is required now.
Added Setup browser: browse the Setup screens interactively from the HII data, with dynamic visibility and values joined to their variables.
Added Flash Map: whole-flash usage (per-FV used/free/%) reverse-engineered from the image.
FFS editing: Replace accepts a larger file now (the FV is rebuilt automatically), and Insert FFS / Remove FFS / Export Decompressed were added.
The saved image is re-parsed to verify itself after Save As.
AMD support improved: PSP / BIOS firmware directories, AMD microcode, and zlib PEI FVs are parsed now.
Intel OSSE region is parsed (layout table, BPDT boot partitions, $CPD modules), in the firmware tree and in Flash Map.
The toolbar search runs across all tabs now and reports the matches per tab.
Added Compare ROMs and Compare Setup to diff two opened images.
Added Data Inspector (Ctrl+I).
Setup settings and the variable list can be exported.
High-DPI support, unsaved-change warning, and other UI improvements.
Fixed some bugs.

Apr 16, 2026

Fixed issues.
Improved ME parser.
Support Boot Guard.
Support AMD (testing).

Oct 05, 2022

Fixed an exception for the old PCD version.
Improved the code to find FIT and Microcode.

Apr 16, 2022

Updated the EfiCompress code to fix the exception when when decompressing some BIOS.

Feb 26, 2020

Fixed some bugs.

Feb 23, 2020

Improved the parsing speed.
DEPEX can be parsed.

Feb 20, 2020

Update UI.
Fixed some bugs.
Search and Find are available in VFR.

Feb 10, 2020

Fixed an UNI exception for some BIOS.

Jan 30, 2020

Improved EFI Variable.
Fixed some bugs.

Jan 19, 2020

Fixed some bugs.

Oct 24, 2019

Fixed some bugs.

Aug 07, 2019

Added language support.

Aug 02, 2019

Added Variable compare function.
The selected image name will be shown on the title.
Fixed some bugs.

Feb 22, 2019

Fixed the problem that IFR couldn't be found.
Fixed some bugs.

Feb 21, 2019

Added BootOption editor.
Added DevicePath converter.
Variable list is sortable now.
Fixed some bugs.

May 18, 2018

Changed FFS2 ExtendedSize to UINT64.
Fixed some bugs.

Dec 19, 2017

Fixed some BIOS couldn't find IFR data.

Nov 20, 2017

Variable compatibility enhanced.

Nov 05, 2017

IFR interpreter improved.
Convert UNI to text.
Convert IFR from text.
Convert IFR from binary.

Oct 29, 2017

Fixed some bugs.
IFR interpreter improved.
Firmware Contents Signed supported.

May 11, 2017

Parse the default variable value.

September 05, 2016

Implemented VFR browser. It now can view the contents of VFR and UNI in the VFR page.
EFI Compress and Tiano Compress supported.

June 28, 2016

The first version released.

Download: the latest version is on GitHub Releases.

DevicePath Converter

2017-03-29T11:11:00.003+08:00

This utility can convert the UEFI device path.

Update History
Nov 01, 2017

Fixed the minor bug.

May 16, 2017

Fixed the minor bug.

March 29, 2017

The first version released.

Download:
DevicePathConverter.7z

HID Report Descriptor Parser

2015-02-10T17:47:00.001+08:00

I studied HID a while ago, so I developed an application to convert HID report descriptor.
Please try it if you are interested.

Link：Google Drive

HID over I2C Device

2015-01-20T18:10:00.000+08:00

如果一個I2C Device是相容於HID規範的話，從Register 0位置便可讀取出HID Descriptor。
這邊有個範例，讀出來的資料如下：
1E 00 00 01 A0 03 02 00 03 00 2A 00 00 00 00 00
04 00 05 00 AA AA BB BB 11 00 00 00 00 00

在此可對應到此表格：

Byte Offset	Field	Size(Bytes)	Example
0	wHIDDescLength	2	1E
2	bcdVersion	2	01
4	wReportDescLength	2	3A0
6	wReportDescRegister	2	02
8	wInputRegister	2	03
10	wMaxInputLength	2	2A
12	wOutputRegister	2	0
14	wMaxOutputLength	2	0
16	wCommandRegister	2	04
18	wDataRegister	2	05
20	wVendorID	2	AAAA
22	wProductID	2	BBBB
24	wVersionID	2	11
26	RESERVED	4	0

此Table為Device的Information，除了最基本的VID、DID外，還有各個Register的Index指出Data該從哪邊讀與該從哪邊寫。
而wReportDescRegister是Report Descriptor的Index，從此Index將會讀取出一大串的Data，可參考wReportDescLength先配置好存放這些Data的記憶體空間。
關於一個Device的所支援的各種Type都會在這個Descriptor裡面，而一個Descriptor可能會有好幾組Usage Page與Report ID。
例如一個Touch Panel可能會支援Finger與Pen，而這兩個所使用的Report ID是不同的，所以需要去解析每個Report，去取得所要的資料。

Report Descriptor

這邊將探討如何去解析Report Descriptor。
Report Descriptor裡面是由一個個Item所組成的，可分為Short Items與Long Items，通常使用Long Items的情況為，需要存放額外的大量資料時才使用Long Items，否則一般都是用Short Items，長度為1到5 bytes。

可以先判斷一個Item是Short Item或Long Item：
Short Items:

先看第一個Byte (Offset 0)，可以分成三個部分並對應到下表：

bSize	Numeric expression specifying size of data
0	0 bytes
1	1 bytes
2	2 bytes
3	4 bytes

bType	Numeric expression identifying type of item where
0	Main
1	Global
2	Local
3	Reserved

bTag	Numeric expression specifying the function of the item
[data]	Optional data

Data長度可參考bSize，對Short Item來說最多就是4個Bytes。

Long Items:

如果第一個Byte (Offset 0)是0xFE，那這個便是Long Item，而第二個Byte就用來表示整個Data Size，第三個Byte為其Tag，而後面就是整個Data部分。

在此簡單舉一個例子：
05 0D 09 04 A1 01 85 0C 95 01 75 08 26 FF 00 15
00 81 03 09 54 81 02 05 0D 09 22 A1 02 09 42 15
00 25 01 75 01 95 01 81 02 81 03 09 47 81 02 95
05 81 03 75 10 09 51 95 01 81 02 05 01 75 10 95
01 55 0E 65 11 09 30 26 0C 28 35 00 46 03 0A 81
02 46 A2 05 09 31 26 88 16 81 02 C0 05 0D 09 22

這是一部分的Report Descriptor，從第一個Byte開始。
05: 00000101b Tag: 0000b Type: 01b Size: 01b
Type: 01b (Global Items)
Tag: 0000b (Usage Page)
Data: 0D (Digitizer)

09: 00001001b Tag: 0000b Type: 10b Size: 01b
Type: 10b (Local Items)
Tag: 0000b (Usage)
Data: 04 (Touch Screen)

A1: 10100001b Tag: 1010b Type: 00b Size: 01b
Type: 00b (Main Items)
Tag: 1010b (Collection)
Data: 01 (Application)

85: 10000101b Tag: 1000b Type: 01b Size: 01b
Type: 01b (Global Items)
Tag: 1000b (Report ID)
Data: 0C

95: 10010101b Tag: 1001b Type: 01b Size: 01b
Type: 01b (Global Items)
Tag: 1001b (Report Count)
Data: 01

75: 01110101b Tag: 0111b Type: 01b Size: 01b
Type: 01b (Global Items)
Tag: 0111b (Report Size)
Data: 08

26: 00100110b Tag: 0010b Type: 01b Size: 10b
Type: 01b (Global Items)
Tag: 0010b (Logical Maximum)
Data: 00FF

15: 00010101b Tag: 0010b Type: 01b Size: 01b
Type: 01b (Global Items)
Tag: 0010b (Logical Minimum)
Data: 00

81: 10000001b Tag: 1000b Type: 00b Size: 01b
Type: 00b (Main Items)
Tag: 1000b (Input)
Data: 03

以此類推，可以看到每個Item就是這樣串起來的。
解析整個Report Descriptor並不難，但需要一直對照Spec，可參考HID1_11.pdf。

Input Register

Input Register可從wInputRegister這個位置讀出來，但還是必須先做一些前置處理，否則會不知道它的Layout（每個資料所在的Offset，如X、Y軸）。
這部分的資訊可從Report Descriptor取得。
Example:（這不是一個完整的Report Descriptor）
Usage Page (Digitizer)
Usage (Touch Screen)
Collection (Application)
Report ID (0x0C)
Report Count (1)
Report Size (8)
Input (0x03)
Usage (Reserved)
Input (0x02)
Usage Page (Digitizer)
Usage (Finger)
Collection (Logical)
    Usage (Tip Switch)
    Report Size (1)
    Report Count (1)
    Input (0x02)
    Input (0x03)
    Usage (Reserved)
    Input (0x02)
    Report Count (5)
    Input (0x03)
    Report Size (16)
    Usage (Reserved)
    Report Count (1)
    Input (0x02)
    Usage Page (Generic Desktop Controls)
    Report Size (16)
    Report Count (1)
    Usage (X)
    Input (0x02)
    Usage (Y)
    Input (0x02)
End Collection ()

上面共有9個Input，首先可以注意在Input前面有Report Count與Report Size，每看到一個新的Report Count或Report Size，就以新的值來取代。
所以上面的例子：
Input 1st Length: 8 bits
Input 2nd Length: 8 bits
Input 3rd Length: 1 bits
Input 4th Length: 1 bits
Input 5th Length: 1 bits
Input 6th Length: 5 bits
Input 7th Length: 16 bits
Input 8th Length: 16 bits
Input 9th Length: 16 bits

而在第8個Input前的Usage (X)是Usage Page (Generic Desktop Controls)的X座標值，第9個Input前的Usage (Y)為Y的座標值。

以下為從Input Register讀出來的資料：
2A 00 0C 00 01 05 01 00 81 00 2B 01 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 1C A9

前面兩個Byte為整個資料的長度：2A (42個Bytes)
0C為對應的Report ID，代表讀回來的Register是對應到這個Report。
前面有提到一個Panel可能有支援Finger與Pen等。所以從Device讀出來的Report Descriptor會有好幾組Usage Page，每一組可能都會有對應的Report ID。
所以讀回來的Input Register會處理前，要先比對一下是不是相同的ID，不是的話就再換下一個Usage Page。

而在這3個Bytes後面就是實際上要使用的Data，可以從剛剛上面的Input，來推算出對應的Usage的Offset。
Usage (Tip Switch)的值: 05 (bit 0)
Usage (X)的值: 0081
Usage (Y)的值: 012B

PCD (Platform Configuration Database) - Part 3 (DXE)

2014-10-22T14:48:00.000+08:00

將接續上一篇，繼續探討DXE部分。

AutoGen.h
typedef struct {
UINT32             PcdSetupConOutColumn_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0;
UINT32             PcdSetupConOutRow_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0;

DYNAMICEX_MAPPING ExMapTable[DXE_EXMAPPING_TABLE_SIZE];
UINT32             LocalTokenNumberTable[DXE_LOCAL_TOKEN_NUMBER_TABLE_SIZE];
GUID               GuidTable[DXE_GUID_TABLE_SIZE];
STRING_HEAD        PcdWinNtMemorySize_0d79a645_1d91_40a6_a81f_61e6982b32b4[1];
STRING_HEAD        PcdWinNtPhysicalDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4[1];
STRING_HEAD        PcdWinNtVirtualDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4[1];
STRING_HEAD        PcdWinNtFileSystem_0d79a645_1d91_40a6_a81f_61e6982b32b4[1];
STRING_HEAD        PcdWinNtSerialPort_0d79a645_1d91_40a6_a81f_61e6982b32b4[1];
STRING_HEAD        PcdWinNtGop_0d79a645_1d91_40a6_a81f_61e6982b32b4[1];
STRING_HEAD        PcdWinNtUga_0d79a645_1d91_40a6_a81f_61e6982b32b4[1];
STRING_HEAD        PcdWinNtConsole_0d79a645_1d91_40a6_a81f_61e6982b32b4[1];

VARIABLE_HEAD      PcdHardwareErrorRecordLevel_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header[1];
VARIABLE_HEAD      PcdPlatformBootTimeOut_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header[1];
VARIABLE_HEAD      PcdSetupConOutColumn_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header[1];
VARIABLE_HEAD      PcdSetupConOutRow_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header[1];

UINT8              StringTable[12]; /* PcdWinNtMemorySize_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
UINT8              StringTable_1[100]; /* PcdWinNtPhysicalDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
UINT8              StringTable_2[26]; /* PcdWinNtVirtualDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
UINT8              StringTable_3[106]; /* PcdWinNtFileSystem_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
UINT8              StringTable_4[20]; /* PcdWinNtSerialPort_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
UINT8              StringTable_5[52]; /* PcdWinNtGop_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
UINT8              StringTable_6[52]; /* PcdWinNtUga_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
UINT8              StringTable_7[52]; /* PcdWinNtConsole_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
UINT8              StringTable_8[32]; /* PcdHardwareErrorRecordLevel_d3705011_bc19_4af7_be16_f68030378c15 */
UINT8              StringTable_9[16]; /* PcdPlatformBootTimeOut_d3705011_bc19_4af7_be16_f68030378c15 */
UINT8              StringTable_10[38]; /* PcdSetupConOutColumn_d3705011_bc19_4af7_be16_f68030378c15 */

SIZE_INFO          SizeTable[DXE_SIZE_TABLE_SIZE];

UINT16             PcdHardwareErrorRecordLevel_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0;
UINT16             PcdPlatformBootTimeOut_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0;

BOOLEAN            PcdBootState_d3705011_bc19_4af7_be16_f68030378c15[1];

UINT8              SkuIdTable[DXE_SKUID_TABLE_SIZE];

} DXE_PCD_DATABASE_INIT;

typedef struct {
UINT8 dummy; /* PCD_DATABASE_UNINIT is emptry */
} DXE_PCD_DATABASE_UNINIT;

typedef struct {
DXE_PCD_DATABASE_INIT    Init;
DXE_PCD_DATABASE_UNINIT Uninit;
} DXE_PCD_DATABASE;

typedef struct {
PEI_PCD_DATABASE PeiDb;
DXE_PCD_DATABASE DxeDb;
} PCD_DATABASE;

AutoGen.c

DXE_PCD_DATABASE_INIT gDXEPcdDbInit = {
80U, /* PcdSetupConOutColumn_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0 */
25U, /* PcdSetupConOutRow_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0 */

/* VPD */

/* ExMapTable */
{
    { 0U, 0U, 0U },
},
/* LocalTokenNumberTable */
{
    offsetof(DXE_PCD_DATABASE, Init.PcdWinNtMemorySize_0d79a645_1d91_40a6_a81f_61e6982b32b4) | PCD_TYPE_STRING,
    offsetof(DXE_PCD_DATABASE, Init.PcdWinNtPhysicalDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4) | PCD_TYPE_STRING,
    offsetof(DXE_PCD_DATABASE, Init.PcdWinNtVirtualDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4) | PCD_TYPE_STRING,
    offsetof(DXE_PCD_DATABASE, Init.PcdWinNtFileSystem_0d79a645_1d91_40a6_a81f_61e6982b32b4) | PCD_TYPE_STRING,
    offsetof(DXE_PCD_DATABASE, Init.PcdWinNtSerialPort_0d79a645_1d91_40a6_a81f_61e6982b32b4) | PCD_TYPE_STRING,
    offsetof(DXE_PCD_DATABASE, Init.PcdWinNtGop_0d79a645_1d91_40a6_a81f_61e6982b32b4) | PCD_TYPE_STRING,
    offsetof(DXE_PCD_DATABASE, Init.PcdWinNtUga_0d79a645_1d91_40a6_a81f_61e6982b32b4) | PCD_TYPE_STRING,
    offsetof(DXE_PCD_DATABASE, Init.PcdWinNtConsole_0d79a645_1d91_40a6_a81f_61e6982b32b4) | PCD_TYPE_STRING,
    offsetof(DXE_PCD_DATABASE, Init.PcdHardwareErrorRecordLevel_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header) | PCD_TYPE_HII | PCD_DATUM_TYPE_UINT16,
    offsetof(DXE_PCD_DATABASE, Init.PcdPlatformBootTimeOut_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header) | PCD_TYPE_HII | PCD_DATUM_TYPE_UINT16,
    offsetof(DXE_PCD_DATABASE, Init.PcdSetupConOutColumn_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header) | PCD_DATUM_TYPE_UINT32 | PCD_TYPE_HII,
    offsetof(DXE_PCD_DATABASE, Init.PcdSetupConOutRow_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header) | PCD_DATUM_TYPE_UINT32 | PCD_TYPE_HII,
    offsetof(DXE_PCD_DATABASE, Init.PcdBootState_d3705011_bc19_4af7_be16_f68030378c15) | PCD_DATUM_TYPE_UINT8 | PCD_TYPE_DATA,
},
/* GuidTable */
{
    { 0x8BE4DF61, 0x93CA, 0x11D2, { 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03, 0x2B, 0x8C }},
},
{ 0U }, /* PcdWinNtMemorySize_0d79a645_1d91_40a6_a81f_61e6982b32b4[1] */
{ 12U }, /* PcdWinNtPhysicalDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4[1] */
{ 112U }, /* PcdWinNtVirtualDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4[1] */
{ 138U }, /* PcdWinNtFileSystem_0d79a645_1d91_40a6_a81f_61e6982b32b4[1] */
{ 244U }, /* PcdWinNtSerialPort_0d79a645_1d91_40a6_a81f_61e6982b32b4[1] */
{ 264U }, /* PcdWinNtGop_0d79a645_1d91_40a6_a81f_61e6982b32b4[1] */
{ 316U }, /* PcdWinNtUga_0d79a645_1d91_40a6_a81f_61e6982b32b4[1] */
{ 368U }, /* PcdWinNtConsole_0d79a645_1d91_40a6_a81f_61e6982b32b4[1] */

/* PcdHardwareErrorRecordLevel_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header[1] */
{
    { 420U, offsetof(DXE_PCD_DATABASE, Init.PcdHardwareErrorRecordLevel_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0), 0U, 0x0U }
},
/* PcdPlatformBootTimeOut_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header[1] */
{
    { 452U, offsetof(DXE_PCD_DATABASE, Init.PcdPlatformBootTimeOut_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0), 0U, 0x0U }
},
/* PcdSetupConOutColumn_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header[1] */
{
    { 468U, offsetof(DXE_PCD_DATABASE, Init.PcdSetupConOutColumn_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0), 0U, 0x0U }
},
/* PcdSetupConOutRow_d3705011_bc19_4af7_be16_f68030378c15_Variable_Header[1] */
{
    { 468U, offsetof(DXE_PCD_DATABASE, Init.PcdSetupConOutRow_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0), 0U, 0x4U }
},

/* StringTable */
{0x36, 0x00, 0x34, 0x00, 0x21, 0x00, 0x36, 0x00, 0x34, 0x00, 0x00, 0x00}, /* PcdWinNtMemorySize_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
{0x61, 0x00, 0x3a, 0x00, 0x52, 0x00, 0x57, 0x00, 0x3b, 0x00, 0x32, 0x00, 0x38, 0x00, 0x38, 0x00, 0x30, 0x00, 0x3b, 0x00, 0x35, 0x00, 0x31, 0x00, 0x32, 0x00, 0x21, 0x00, 0x64, 0x00, 0x3a, 0x00, 0x52, 0x00, 0x4f, 0x00, 0x3b, 0x00, 0x33, 0x00, 0x30, 0x00, 0x37, 0x00, 0x32, 0x00, 0x30, 0x00, 0x30, 0x00, 0x3b, 0x00, 0x32, 0x00, 0x30, 0x00, 0x34, 0x00, 0x38, 0x00, 0x21, 0x00, 0x6a, 0x00, 0x3a, 0x00, 0x52, 0x00, 0x57, 0x00, 0x3b, 0x00, 0x32, 0x00, 0x36, 0x00, 0x32, 0x00, 0x31, 0x00, 0x34, 0x00, 0x34, 0x00, 0x3b, 0x00, 0x35, 0x00, 0x31, 0x00, 0x32, 0x00, 0x00, 0x00}, /* PcdWinNtPhysicalDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
{0x46, 0x00, 0x57, 0x00, 0x3b, 0x00, 0x34, 0x00, 0x30, 0x00, 0x39, 0x00, 0x36, 0x00, 0x30, 0x00, 0x3b, 0x00, 0x35, 0x00, 0x31, 0x00, 0x32, 0x00, 0x00, 0x00}, /* PcdWinNtVirtualDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
{0x2e, 0x00, 0x21, 0x00, 0x2e, 0x00, 0x2e, 0x00, 0x5c, 0x00, 0x2e, 0x00, 0x2e, 0x00, 0x5c, 0x00, 0x2e, 0x00, 0x2e, 0x00, 0x5c, 0x00, 0x55, 0x00, 0x64, 0x00, 0x75, 0x00, 0x50, 0x00, 0x6b, 0x00, 0x67, 0x00, 0x5c, 0x00, 0x44, 0x00, 0x45, 0x00, 0x42, 0x00, 0x55, 0x00, 0x47, 0x00, 0x5f, 0x00, 0x56, 0x00, 0x53, 0x00, 0x32, 0x00, 0x30, 0x00, 0x31, 0x00, 0x32, 0x00, 0x78, 0x00, 0x38, 0x00, 0x36, 0x00, 0x5c, 0x00, 0x49, 0x00, 0x41, 0x00, 0x33, 0x00, 0x32, 0x00, 0x00, 0x00}, /* PcdWinNtFileSystem_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
{0x43, 0x00, 0x4f, 0x00, 0x4d, 0x00, 0x31, 0x00, 0x21, 0x00, 0x43, 0x00, 0x4f, 0x00, 0x4d, 0x00, 0x32, 0x00, 0x00, 0x00}, /* PcdWinNtSerialPort_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
{0x55, 0x00, 0x47, 0x00, 0x41, 0x00, 0x20, 0x00, 0x57, 0x00, 0x69, 0x00, 0x6e, 0x00, 0x64, 0x00, 0x6f, 0x00, 0x77, 0x00, 0x20, 0x00, 0x31, 0x00, 0x00, 0x00}, /* PcdWinNtGop_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
{0x55, 0x00, 0x47, 0x00, 0x41, 0x00, 0x20, 0x00, 0x57, 0x00, 0x69, 0x00, 0x6e, 0x00, 0x64, 0x00, 0x6f, 0x00, 0x77, 0x00, 0x20, 0x00, 0x31, 0x00, 0x00, 0x00}, /* PcdWinNtUga_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
{0x42, 0x00, 0x75, 0x00, 0x73, 0x00, 0x20, 0x00, 0x44, 0x00, 0x72, 0x00, 0x69, 0x00, 0x76, 0x00, 0x65, 0x00, 0x72, 0x00, 0x20, 0x00, 0x43, 0x00, 0x6f, 0x00, 0x6e, 0x00, 0x73, 0x00, 0x6f, 0x00, 0x6c, 0x00, 0x65, 0x00, 0x20, 0x00, 0x57, 0x00, 0x69, 0x00, 0x6e, 0x00, 0x64, 0x00, 0x6f, 0x00, 0x77, 0x00, 0x00, 0x00}, /* PcdWinNtConsole_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
{0x48, 0x00, 0x77, 0x00, 0x45, 0x00, 0x72, 0x00, 0x72, 0x00, 0x52, 0x00, 0x65, 0x00, 0x63, 0x00, 0x53, 0x00, 0x75, 0x00, 0x70, 0x00, 0x70, 0x00, 0x6f, 0x00, 0x72, 0x00, 0x74, 0x00, 0x00, 0x00}, /* PcdHardwareErrorRecordLevel_d3705011_bc19_4af7_be16_f68030378c15 */
{0x54, 0x00, 0x69, 0x00, 0x6d, 0x00, 0x65, 0x00, 0x6f, 0x00, 0x75, 0x00, 0x74, 0x00, 0x00, 0x00}, /* PcdPlatformBootTimeOut_d3705011_bc19_4af7_be16_f68030378c15 */
{0x53, 0x00, 0x65, 0x00, 0x74, 0x00, 0x75, 0x00, 0x70, 0x00, 0x43, 0x00, 0x6f, 0x00, 0x6e, 0x00, 0x73, 0x00, 0x6f, 0x00, 0x6c, 0x00, 0x65, 0x00, 0x43, 0x00, 0x6f, 0x00, 0x6e, 0x00, 0x66, 0x00, 0x69, 0x00, 0x67, 0x00, 0x00, 0x00}, /* PcdSetupConOutColumn_d3705011_bc19_4af7_be16_f68030378c15 */

/* SizeTable */
{
    12U, 12U, /* PcdWinNtMemorySize_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
    100U, 94U, /* PcdWinNtPhysicalDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
    26U, 26U, /* PcdWinNtVirtualDisk_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
    106U, 78U, /* PcdWinNtFileSystem_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
    20U, 20U, /* PcdWinNtSerialPort_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
    52U, 26U, /* PcdWinNtGop_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
    52U, 26U, /* PcdWinNtUga_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
    52U, 52U, /* PcdWinNtConsole_0d79a645_1d91_40a6_a81f_61e6982b32b4 */
},

1U, /* PcdHardwareErrorRecordLevel_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0 */
10U, /* PcdPlatformBootTimeOut_d3705011_bc19_4af7_be16_f68030378c15_VariableDefault_0 */

{ 1U }, /* PcdBootState_d3705011_bc19_4af7_be16_f68030378c15[1] */

/* SkuIdTable */
{ 0U, },
};

以上是在Compile過程中，Build Tool為PCD DXE所生成的檔案，跟PEIM的很相似，但多了一些沒看過的PCD。。
上面有個PCD_DATABASE，裡面分了PeiDb與DxeDb，在一開始的EntryPoint中會呼叫BuildPcdDxeDataBase，並把PEI_PCD_DATABASE從HOB複製過來。

PCD DXE的GetWorker與SetWorker。

GetWorker:

VOID *
GetWorker (
IN UINTN               TokenNumber,
IN UINTN               GetSize
)

在一開始會做一些前置處理，判斷傳進來的TokenNumber判斷是PEI的PCD還是DXE的PCD。
然後把對應的LocalTokenNumber、LocalTokenNumber、StringTable、PcdDb的Pointer另取出來。
IsPeiDb = (BOOLEAN) ((TokenNumber + 1 < PEI_LOCAL_TOKEN_NUMBER + 1) ? TRUE : FALSE);

透過Mask單獨取得Offset。
Offset = LocalTokenNumber & PCD_DATABASE_OFFSET_MASK;

接下來會依照各種不同PCD Type做不同的處理：
PCD_TYPE_VPD:
傳回VPD (Vital Product Data)中特定的Offset的資料。
VPD_HEAD *VpdHead;
VpdHead = (VPD_HEAD *) ((UINT8 *)PeiPcdDb + Offset);
return (VOID *) (UINTN) (PcdGet32 (PcdVpdBaseAddress) + VpdHead->Offset);

PCD_TYPE_HII|PCD_TYPE_STRING:
PCD_TYPE_HII:
透過Offset取得Variable Head，裡面有著GUID與Name的Index。
VariableHead = (VARIABLE_HEAD *) ((UINT8 *)PeiPcdDb + Offset);

Guid = &(PeiPcdDb->Init.GuidTable[VariableHead->GuidTableIndex]);
Name = (UINT16*)&StringTable[VariableHead->StringIndex];

會先判斷是否為PCD_TYPE_HII|PCD_TYPE_STRING或PCD_TYPE_HII，再去做不同的處理，差別只是在於在GetVariable失敗時，
PCD_TYPE_HII|PCD_TYPE_STRING會於StringTable取得預設的資料（字串），而PCD_TYPE_HII會直接以DefaultValueOffset去取得對應的預設值。
if ((LocalTokenNumber & PCD_TYPE_ALL_SET) == (PCD_TYPE_HII|PCD_TYPE_STRING)) {
StringTableIdx = *(STRING_HEAD*)((UINT8 *) PcdDb + VariableHead->DefaultValueOffset);
VaraiableDefaultBuffer = (VOID *) (StringTable + StringTableIdx);
...
} else {
VaraiableDefaultBuffer = (UINT8 *) PcdDb + VariableHead->DefaultValueOffset;
...
}

PCD_TYPE_STRING:
先取得該PCD的STRING_HEAD (StringTableIdx (UINT32))，裡面存放著對應StringTable的Offset。
StringTableIdx = * (STRING_HEAD*) ((UINT8 *) PeiPcdDb + Offset);
return (VOID *) (&StringTable[StringTableIdx]);

PCD_TYPE_DATA:
直接透過Offset取得Data。
return (VOID *) ((UINT8 *)PeiPcdDb + Offset);

SetWorker:

EFI_STATUS
SetWorker (
IN          UINTN               TokenNumber,
IN          VOID                *Data,
IN OUT      UINTN               *Size,
IN          BOOLEAN             PtrType
)

透過Token Number取得該PCD的LocalTokenNumber (Offset、PCD Type、Data Type)。
LocalTokenNumber = PeiPcdDb->Init.LocalTokenNumberTable[TokenNumber];

會先判斷Data Type是不是Pointer，通常像String之類的，會被歸類為Pointer。
要注意到在Build Tool會在PCD Database中，先宣告好固定長度的陣列來存放String等其它Data。
如果PtrType為True，而傳入的Size又大於原先預留好的最大值的話，就會造成問題，這邊就先擋掉並回傳MaxSize。
if (PtrType) {
//
// Get MaxSize first, then check new size with max buffer size.
//
GetPtrTypeSize (TokenNumber, &MaxSize, PeiPcdDb);
if (*Size > MaxSize) {
    *Size = MaxSize;
    return EFI_INVALID_PARAMETER;
}
} else {
if (*Size != PeiPcdGetSize (TokenNumber + 1)) {
    return EFI_INVALID_PARAMETER;
}
}

當某個PCD被修改時會去呼叫，為該PCD註冊Notify的Function。
可以透過PCD Library的LibPcdCallbackOnSet來進行註冊會比較方便。
if ((TokenNumber + 1 < PEI_NEX_TOKEN_NUMBER + 1) || (TokenNumber + 1 >= PEI_LOCAL_TOKEN_NUMBER + 1 || TokenNumber + 1 < (PEI_LOCAL_TOKEN_NUMBER + DXE_NEX_TOKEN_NUMBER + 1))) {
InvokeCallbackOnSet (0, NULL, TokenNumber + 1, Data, *Size);
}

跟GetWorker一樣會判斷傳進來的TokenNumber判斷是PEI的PCD還是DXE的PCD。
然後把對應的LocalTokenNumber、LocalTokenNumber、StringTable、PcdDb的Pointer另取出來。

透過Mask單獨取得Offset，並取得Data。
Offset = LocalTokenNumber & PCD_DATABASE_OFFSET_MASK;
InternalData    = (VOID *) ((UINT8 *) PeiPcdDb + Offset);

接下來會依照各種不同PCD Type做不同的處理：
PCD_TYPE_VPD:
可能是上述幾個Type都不支援在PEI修改NVS，所以這邊就直接return回EFI_INVALID_PARAMETER。

PCD_TYPE_STRING:
傳入的資料為一串Array，資料長度可能會變動，所以先更改Current Size。
SizeTable中有兩個欄位，一個是Max Size，一個是Current Size。
之後再透過CopyMem，將傳入的Data Copy到StringTable中。
if (SetPtrTypeSize (TokenNumber, Size, PeiPcdDb)) {
CopyMem (StringTable + *((STRING_HEAD *)InternalData), Data, *Size);
return EFI_SUCCESS;
} else {
return EFI_INVALID_PARAMETER;
}

PCD_TYPE_HII:
PCD_TYPE_HII|PCD_TYPE_STRING:
透過SetVariable將資料存於NVS並更新PCD Database內的資料。
VariableHead = (VARIABLE_HEAD *) (PcdDb + Offset);

Guid = GuidTable + VariableHead->GuidTableIndex;
Name = (UINT16*) (StringTable + VariableHead->StringIndex);
VariableOffset = VariableHead->Offset;
Status = SetHiiVariable (Guid, Name, Data, *Size, VariableOffset);

if (EFI_NOT_FOUND == Status) {
if ((LocalTokenNumber & PCD_TYPE_ALL_SET) == (PCD_TYPE_HII|PCD_TYPE_STRING)) {
    CopyMem (StringTable + *(STRING_HEAD *)(PcdDb + VariableHead->DefaultValueOffset), Data, *Size);
} else {
    CopyMem (PcdDb + VariableHead->DefaultValueOffset, Data, *Size);
}
Status = EFI_SUCCESS;
}

PCD_TYPE_DATA:
PtrType的處理方式跟PCD_TYPE_STRING很像。
if (PtrType) {
if (SetPtrTypeSize (TokenNumber, Size, PeiPcdDb)) {
    CopyMem (InternalData, Data, *Size);
    return EFI_SUCCESS;
} else {
    return EFI_INVALID_PARAMETER;
}
}

其餘基本型態只是透過轉型來處理。
switch (*Size) {
case sizeof(UINT8):
    *((UINT8 *) InternalData) = *((UINT8 *) Data);
    return EFI_SUCCESS;

case sizeof(UINT16):
    *((UINT16 *) InternalData) = *((UINT16 *) Data);
    return EFI_SUCCESS;

case sizeof(UINT32):
    *((UINT32 *) InternalData) = *((UINT32 *) Data);
    return EFI_SUCCESS;

case sizeof(UINT64):
    *((UINT64 *) InternalData) = *((UINT64 *) Data);
    return EFI_SUCCESS;

default:
    ASSERT (FALSE);
    return EFI_NOT_FOUND;
}

PCD (Platform Configuration Database) - Part 2 (PEI)

2014-10-20T18:57:00.000+08:00

這篇將探討PCD背後的原理，PEI與DXE都分別提供PPI與Protocol給予其它Driver使用，雖然一般都是透過PcdLib來存取Dynamic類型的PCD，但實際上PcdLib是使用PPI或Protocol來達成存取PCD的目的。

AutoGen.h
typedef struct {
DYNAMICEX_MAPPING ExMapTable[PEI_EXMAPPING_TABLE_SIZE];
UINT32             LocalTokenNumberTable[PEI_LOCAL_TOKEN_NUMBER_TABLE_SIZE];
GUID               GuidTable[PEI_GUID_TABLE_SIZE];

UINT8              StringTable[1]; /* _ */

SIZE_INFO          SizeTable[PEI_SIZE_TABLE_SIZE];

UINT8              SkuIdTable[PEI_SKUID_TABLE_SIZE];
SKU_ID             SystemSkuId;
} PEI_PCD_DATABASE_INIT;

typedef struct {
UINT64   PcdS3BootScriptTablePrivateDataPtr_a1aff049_fdeb_442a_b320_13ab4cb72bbc[1];

UINT32   PcdFlashNvStorageFtwWorkingBase_a1aff049_fdeb_442a_b320_13ab4cb72bbc[1];
UINT32   PcdFlashNvStorageFtwSpareBase_a1aff049_fdeb_442a_b320_13ab4cb72bbc[1];
UINT32   PcdFlashNvStorageVariableBase_a1aff049_fdeb_442a_b320_13ab4cb72bbc[1];
} PEI_PCD_DATABASE_UNINIT;

typedef struct {
PEI_PCD_DATABASE_INIT    Init;
PEI_PCD_DATABASE_UNINIT Uninit;
} PEI_PCD_DATABASE;

AutoGen.c
PEI_PCD_DATABASE_INIT gPEIPcdDbInit = {
/* VPD */

/* ExMapTable */
{
    { 0U, 0U, 0U },
},
/* LocalTokenNumberTable */
{
    offsetof(PEI_PCD_DATABASE, Uninit.PcdFlashNvStorageFtwWorkingBase_a1aff049_fdeb_442a_b320_13ab4cb72bbc) | PCD_TYPE_DATA | PCD_DATUM_TYPE_UINT32,
    offsetof(PEI_PCD_DATABASE, Uninit.PcdFlashNvStorageFtwSpareBase_a1aff049_fdeb_442a_b320_13ab4cb72bbc) | PCD_TYPE_DATA | PCD_DATUM_TYPE_UINT32,
    offsetof(PEI_PCD_DATABASE, Uninit.PcdFlashNvStorageVariableBase_a1aff049_fdeb_442a_b320_13ab4cb72bbc) | PCD_TYPE_DATA | PCD_DATUM_TYPE_UINT32,
    offsetof(PEI_PCD_DATABASE, Uninit.PcdS3BootScriptTablePrivateDataPtr_a1aff049_fdeb_442a_b320_13ab4cb72bbc) | PCD_DATUM_TYPE_UINT64 | PCD_TYPE_DATA,
},
/* GuidTable */
{
    {0x00000000, 0x0000, 0x0000, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}},
},
/* StringTable */
{ 0 }, /* _ */

/* SizeTable */
{
    0U, 0U, /* _ */
},
/* SkuIdTable */
{ 0U, },
0U
};

以上是在Compile過程中，Build Tool為PCD PEIM所生成的檔案。
可以注意到這邊只有少數幾組PCD，原因是PCD PEIM中不會包含只在DXE被使用的PCD。
而這個PEI_PCD_DATABASE，最後會透過HOB傳給PCD DXE。
建立HOB的過程可參考BuildPcdDatabase。

整個Structure分為Init與Uninit的部分，兩個差別是在於，如果有定義好預設值的Dynamic PCD，其預設值會被放在Init裡面，但如果在DSC裡定義的值為0或NULL的話，會被視為無預設值，且會放置於Uninit中。

/* LocalTokenNumberTable */
{
    offsetof(PEI_PCD_DATABASE, Uninit.PcdFlashNvStorageFtwWorkingBase_a1aff049_fdeb_442a_b320_13ab4cb72bbc) | PCD_TYPE_DATA | PCD_DATUM_TYPE_UINT32,
    offsetof(PEI_PCD_DATABASE, Uninit.PcdFlashNvStorageFtwSpareBase_a1aff049_fdeb_442a_b320_13ab4cb72bbc) | PCD_TYPE_DATA | PCD_DATUM_TYPE_UINT32,
    offsetof(PEI_PCD_DATABASE, Uninit.PcdFlashNvStorageVariableBase_a1aff049_fdeb_442a_b320_13ab4cb72bbc) | PCD_TYPE_DATA | PCD_DATUM_TYPE_UINT32,
    offsetof(PEI_PCD_DATABASE, Uninit.PcdS3BootScriptTablePrivateDataPtr_a1aff049_fdeb_442a_b320_13ab4cb72bbc) | PCD_DATUM_TYPE_UINT64 | PCD_TYPE_DATA,
},
PEI_PCD_DATABASE_INIT中的LocalTokenNumberTable會在Compile過程中，會決定好每個PCD中的Data在PEI_PCD_DATABASE中的Offset以及Data Type與PCD Type。

#define offsetof(s,m) (UINT32) (UINTN) &(((s *)0)->m)
代入一個Structure的原型與其Member，會算出其Member的Offset為多少。

PCD Type Mask:
PCD_TYPE_DATA
PCD_TYPE_HII
PCD_TYPE_VPD
PCD_TYPE_SKU_ENABLED
PCD_TYPE_STRING

Datum Type:
PCD_DATUM_TYPE_POINTER
PCD_DATUM_TYPE_UINT8
PCD_DATUM_TYPE_UINT16
PCD_DATUM_TYPE_UINT32
PCD_DATUM_TYPE_UINT64

在上面的LocalTokenNumberTable中，共有四個PCD，如果去搜尋整套編譯過的Source Code，可以在某些AutoGen.h看到這些Dynamic PCD的Token Number，並且可以注意到第一個PCD的Token為1，那為何不是從0開始？0是給PCD_INVALID_TOKEN_NUMBER使用（Source Code中有註解），所以第一個PCD是從1開始，只是後面會將Token Number減1，再代入Table取得其相關資料。
#define _PCD_TOKEN_PcdFlashNvStorageFtwWorkingBase 1U
#define _PCD_GET_MODE_32_... LibPcdGet32(_PCD_TOKEN_PcdFlashNvStorageFtwWorkingBase)
#define _PCD_SET_MODE_32_...(Value) LibPcdSet32(_PCD_TOKEN_PcdFlashNvStorageFtwWorkingBase, (Value))

#define _PCD_TOKEN_PcdFlashNvStorageFtwSpareBase 2U
#define _PCD_GET_MODE_32_... LibPcdGet32(_PCD_TOKEN_PcdFlashNvStorageFtwSpareBase)
#define _PCD_SET_MODE_32_...(Value) LibPcdSet32(_PCD_TOKEN_PcdFlashNvStorageFtwSpareBase, (Value))

#define _PCD_TOKEN_PcdFlashNvStorageVariableBase 3U
#define _PCD_GET_MODE_32_... LibPcdGet32(_PCD_TOKEN_PcdFlashNvStorageVariableBase)
#define _PCD_SET_MODE_32_...(Value) LibPcdSet32(_PCD_TOKEN_PcdFlashNvStorageVariableBase, (Value))

#define _PCD_TOKEN_PcdS3BootScriptTablePrivateDataPtr 4U
#define _PCD_GET_MODE_64_... LibPcdGet64(_PCD_TOKEN_PcdS3BootScriptTablePrivateDataPtr)
#define _PCD_SET_MODE_64_...(Value) LibPcdSet64(_PCD_TOKEN_PcdS3BootScriptTablePrivateDataPtr, (Value))

在PPI或Protocol的底層會透過呼叫GetWorker或SetWorker來存取PCD。

GetWorker:

VOID *
GetWorker (
IN UINTN               TokenNumber,
IN UINTN               GetSize
)

透過Token Number取得該PCD的LocalTokenNumber (Offset、PCD Type、Data Type)。
LocalTokenNumber = PeiPcdDb->Init.LocalTokenNumberTable[TokenNumber];

透過Mask單獨取得Offset。
Offset = LocalTokenNumber & PCD_DATABASE_OFFSET_MASK;

接下來會依照各種不同PCD Type做不同的處理：
PCD_TYPE_VPD:
傳回VPD (Vital Product Data)中特定的Offset的資料。
VPD_HEAD *VpdHead;
VpdHead = (VPD_HEAD *) ((UINT8 *)PeiPcdDb + Offset);
return (VOID *) (UINTN) (PcdGet32 (PcdVpdBaseAddress) + VpdHead->Offset);

PCD_TYPE_HII|PCD_TYPE_STRING:
PCD_TYPE_HII:
透過Offset取得Variable Head，裡面有著GUID與Name的Index。
VariableHead = (VARIABLE_HEAD *) ((UINT8 *)PeiPcdDb + Offset);

Guid = &(PeiPcdDb->Init.GuidTable[VariableHead->GuidTableIndex]);
Name = (UINT16*)&StringTable[VariableHead->StringIndex];

透過GetVariable取得Variable Data。
Status = GetHiiVariable (Guid, Name, &Data, &DataSize);

如有錯誤則去取得PCD設定的預設值（如：NOT_FOUND）。
if (Status == EFI_SUCCESS) {
return (VOID *) ((UINT8 *) Data + VariableHead->Offset);
} else {
//
// Return the default value specified by Platform Integrator
//
if ((LocalTokenNumber & PCD_TYPE_ALL_SET) == (PCD_TYPE_HII|PCD_TYPE_STRING)) {
    return (VOID*)&StringTable[*(STRING_HEAD*)((UINT8*)PeiPcdDb + VariableHead->DefaultValueOffset)];
} else {
    return (VOID *) ((UINT8 *) PeiPcdDb + VariableHead->DefaultValueOffset);
}
}

PCD_TYPE_DATA:
直接透過Offset取得Data。
return (VOID *) ((UINT8 *)PeiPcdDb + Offset);

PCD_TYPE_STRING:
先取得該PCD的STRING_HEAD (StringTableIdx)，裡面存放著對應StringTable的Offset。
StringTableIdx = * (STRING_HEAD*) ((UINT8 *) PeiPcdDb + Offset);
return (VOID *) (&StringTable[StringTableIdx]);

SetWorker:

EFI_STATUS
SetWorker (
IN          UINTN               TokenNumber,
IN          VOID                *Data,
IN OUT      UINTN               *Size,
IN          BOOLEAN             PtrType
)

透過Token Number取得該PCD的LocalTokenNumber (Offset、PCD Type、Data Type)。
LocalTokenNumber = PeiPcdDb->Init.LocalTokenNumberTable[TokenNumber];

會先判斷Data Type是不是Pointer，通常像String之類的，會被歸類為Pointer。
要注意到在Build Tool會在PCD Database中，先宣告好固定長度的陣列來存放String等其它Data。
如果PtrType為True，而傳入的Size又大於原先預留好的最大值的話，就會造成問題，這邊就先擋掉並回傳MaxSize。
if (PtrType) {
//
// Get MaxSize first, then check new size with max buffer size.
//
GetPtrTypeSize (TokenNumber, &MaxSize, PeiPcdDb);
if (*Size > MaxSize) {
    *Size = MaxSize;
    return EFI_INVALID_PARAMETER;
}
} else {
if (*Size != PeiPcdGetSize (TokenNumber + 1)) {
    return EFI_INVALID_PARAMETER;
}
}

當某個PCD被修改時會去呼叫，為該PCD註冊Notify的Function。
可以透過PCD Library的LibPcdCallbackOnSet來進行註冊會比較方便。
if (TokenNumber + 1 < PEI_NEX_TOKEN_NUMBER + 1) {
InvokeCallbackOnSet (0, NULL, TokenNumber + 1, Data, *Size);
}

透過Mask單獨取得Offset，並取得Data。
Offset = LocalTokenNumber & PCD_DATABASE_OFFSET_MASK;
InternalData    = (VOID *) ((UINT8 *) PeiPcdDb + Offset);

接下來會依照各種不同PCD Type做不同的處理：
PCD_TYPE_VPD:
PCD_TYPE_HII:
PCD_TYPE_HII|PCD_TYPE_STRING:
可能是上述幾個Type都不支援在PEI修改NVS，所以這邊就直接return回EFI_INVALID_PARAMETER。
尤其PCD_TYPE_HII實際上就是個Variable。
return EFI_INVALID_PARAMETER;

PCD_TYPE_STRING:
傳入的資料為一串Array，資料長度可能會變動，所以先更改Current Size。
SizeTable中有兩個欄位，一個是Max Size，一個是Current Size。
之後再透過CopyMem，將傳入的Data Copy到StringTable中。
if (SetPtrTypeSize (TokenNumber, Size, PeiPcdDb)) {
StringTableIdx = *((STRING_HEAD *)InternalData);
CopyMem (&PeiPcdDb->Init.StringTable[StringTableIdx], Data, *Size);
return EFI_SUCCESS;
} else {
return EFI_INVALID_PARAMETER;
}

PCD_TYPE_DATA:
PtrType的處理方式跟PCD_TYPE_STRING很像。
if (PtrType) {
if (SetPtrTypeSize (TokenNumber, Size, PeiPcdDb)) {
    CopyMem (InternalData, Data, *Size);
    return EFI_SUCCESS;
} else {
    return EFI_INVALID_PARAMETER;
}
}

其餘基本型態只是透過轉型來處理。
switch (*Size) {
case sizeof(UINT8):
    *((UINT8 *) InternalData) = *((UINT8 *) Data);
    return EFI_SUCCESS;

case sizeof(UINT16):
    *((UINT16 *) InternalData) = *((UINT16 *) Data);
    return EFI_SUCCESS;

case sizeof(UINT32):
    *((UINT32 *) InternalData) = *((UINT32 *) Data);
    return EFI_SUCCESS;

case sizeof(UINT64):
    *((UINT64 *) InternalData) = *((UINT64 *) Data);
    return EFI_SUCCESS;

default:
    ASSERT (FALSE);
    return EFI_NOT_FOUND;
}

PCD (Platform Configuration Database) - Part 1

2013-12-26T12:04:00.000+08:00

EDK II相較於EDK來說，除了更模組化的設計（少了許多沒必要且重複的Library...），最大的不同就是多了PCD這個新功能！

依照PCD類型的不同，我們的Module可以讀取在Compiler前就已設定好的Macro，或者是使用Dynamic PCD來讓各個Module相互存取數值。

在EDK時BIOS內的不同Module要互相傳遞數值，最常使用的可能是CMOS、Memory或Variable。
但CMOS可使用的位置並不算多（雖然還算滿多的...），也要顧慮到該位址是否已被占用。
而Memory也要先配置好空間，然後別支Module也要知道該位置，說真的也有點麻煩...
再來就是Variable，Variable說方便是方便，但使用時都要做一些繁瑣動作，例如訂好Name、GUID還有Data Type（雖然PCD也要訂定好GUID與各資料型別等部分，但Compiler會做掉很多地方），對於一般不需保存於NVS的資料，個人比較偏好使用PCD，但其生命周期只有Boot-time而已。

PCD分為五種型態：

PcdsFeatureFlag
PcdsFixedAtBuild
PcdsPatchableInModule
PcdsDynamic
PcdsDynamicEx

某些PCD在編譯時，就會被宣告為使用它的Module裡的常數，所以只能去讀取它原先就定好的值。
其它PCD則是可以在Boot-time時期做存取的動作。

可在Package中的DEC檔中宣告每個不同的PCD。
以MdePkg.dec為例：
[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE0000000|UINT64|0x0000000a gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangCodes|"engfraengfra"|VOID*|0x0000001c gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLang|"eng"|VOID*|0x0000001d

在DEC中的PCD宣告，可以有多種型態，以上面的例子來說，這些PCDs就宣告了四種型態，並且分別給予它們初始值、資料型別與Token值。

然後可在DSC中定義它實際的PCD型態與初始值。
以MdePkg.dsc為例：
[PcdsFixedAtBuild]
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x0f
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000000
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE0000000

========================================
那如果在DSC定義一個與DEC中所宣告的型態不同會如何？
MdePkg.dec
[PcdsFixedAtBuild,PcdsPatchableInModule]
gEfiMdePkg...Guid.PcdDebugPrintErrorLevel|0x80000000|UINT32|0x00000006

Nt32Pkg.dsc
[PcdsDynamicDefault]
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000040

將會Compile error...
Type [Dynamic] of PCD [gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel] in DSC file doesn't match the type [FixedAtBuild] defined in DEC file.

底下這句話是Spec中所提到的：
Some DEC files define multiple PCD types, but only one type can be used and will be chosen by the platform DSC file.
========================================

在編譯的時候Compiler會為每一支Module自動產生AutoGen.h與AutoGen.c。
關於PCD的部分，它會將使用者在inf中所加入的PCD轉換到上述的兩個檔案，對於不同型態的PCD，則會有不同的處理方式。

以下將會介紹各種不同的PCD：

PcdsFeatureFlag

FeatureFlag顧名思義可以用它來表示一個Feature是On或Off，所以它是一個Boolean值TRUE或FALSE。
可從下面的例子看出，PcdsFeatureFlag型態的PCD，將會被轉換成const的常數，也意味的它只能被唯讀。

Example:
DSC
[PcdsFeatureFlag]
gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport|TRUE

AutoGen.h
#define _PCD_TOKEN_PcdUgaConsumeSupport 11U
#define _PCD_VALUE_PcdUgaConsumeSupport ((BOOLEAN)1U)
extern const BOOLEAN _gPcd_FixedAtBuild_PcdUgaConsumeSupport;
#define _PCD_GET_MODE_BOOL_PcdUgaConsumeSupport _gPcd_FixedAtBuild_PcdUgaConsumeSupport
//#define _PCD_SET_MODE_BOOL_PcdUgaConsumeSupport ASSERT(FALSE) // It is not allowed to set value for a FIXED_AT_BUILD PCD

AutoGen.c
GLOBAL_REMOVE_IF_UNREFERENCED const BOOLEAN _gPcd_FixedAtBuild_PcdUgaConsumeSupport = _PCD_VALUE_PcdUgaConsumeSupport;
========================================

PcdsFixedAtBuild

FixedAtBuild與FeatureFlag挺相似的，最大的不同則是在於它可以宣告多種不同的變數型別，而不是只有局限於Boolean而已。

Example:
DSC
[PcdsFixedAtBuild]
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE0000000

AutoGen.h
#define _PCD_TOKEN_PcdPciExpressBaseAddress 16U
#define _PCD_VALUE_PcdPciExpressBaseAddress 0xE0000000ULL
extern const UINT64 _gPcd_FixedAtBuild_PcdPciExpressBaseAddress;
#define _PCD_GET_MODE_64_PcdPciExpressBaseAddress _gPcd_FixedAtBuild_PcdPciExpressBaseAddress
//#define _PCD_SET_MODE_64_PcdPciExpressBaseAddress ASSERT(FALSE) // It is not allowed to set value for a FIXED_AT_BUILD PCD

AutoGen.c
GLOBAL_REMOVE_IF_UNREFERENCED const UINT64 _gPcd_FixedAtBuild_PcdPciExpressBaseAddress = _PCD_VALUE_PcdPciExpressBaseAddress;
========================================

PcdsPatchableInModule

宣告成PatchableInModule與上面兩種型態的PCD的最大不同是，它可以在Runtime時去變動它的數值。
然後它還有一個特質，通過下面的範例可以注意到，它被宣告成一個全域變數（Global Variable），在PE/COFF的檔案格式中，而全域變數將會被初始化並放置於Data Section之中。並有機會透過外部工具直接修改。
記得Compile完所產生的.efi檔案都是PE（Portable Executable）格式，有興趣的人可以用7z將.efi打開看看。

由於它只被宣告一個全域變數，所以只有同一個Module能夠取存，不能透過它與各Module相互傳遞數值。

Example:
DSC
[PcdsPatchableInModule]
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000000

AutoGen.h
#define _PCD_TOKEN_PcdDebugPrintErrorLevel 17U
#define _PCD_PATCHABLE_VALUE_PcdDebugPrintErrorLevel ((UINT32)0x80000040U)
extern volatile UINT32 _gPcd_BinaryPatch_PcdDebugPrintErrorLevel;
#define _PCD_GET_MODE_32_PcdDebugPrintErrorLevel _gPcd_BinaryPatch_PcdDebugPrintErrorLevel
#define _PCD_SET_MODE_32_PcdDebugPrintErrorLevel(Value) (_gPcd_BinaryPatch_PcdDebugPrintErrorLevel = (Value))

AutoGen.c
volatile UINT32 _gPcd_BinaryPatch_PcdDebugPrintErrorLevel = _PCD_PATCHABLE_VALUE_PcdDebugPrintErrorLevel;
========================================

PcdsDynamic v.s. PcdsDynamicEx

這兩種型態的PCD都是集中於PCD Database作集中管理，有PEI與DXE兩個部分。
型態又可細分為以下幾種：

PcdsDynamicDefault and PcdsDynamicExDefault
PcdsDynamicHii and PcdsDynamicExHii
PcdsDynamicVpd and PcdsDynamicExVpd

在DEC所宣告的Section需要為PcdsDynamic或PcdsDynamicEx，而在DSC中則是它們的子分類。

PcdsDynamicDefault

DynamicDefault型態的PCD的最大優勢是在於，各個Module之間可以藉由這個PCD來互相傳遞數值。
所以它有著多樣化的應用方式，例如預先把某個不會變動的值從HW讀出來，並存到某個PCD裡面，這樣接下來其它的Module就可以不用再經過繁複的動作去存取HW上的值，直接透過PCD即可。

可以看到下面的例子，它會去透過一個Library去存取數值，而不是宣告一個常數或全域變數。

還可注意到一點，在DEC中所定的Token與AutoGen.h的數值並不相同！
其實Spec有提到，不管DEC中如何訂，Compiler都會自己產生一組，這應該是為了避免人為因素而有重複的狀況。
Although the token is auto-generated. A value is required for the Token field; if it is not defined, then the the build will fail.

Example:
DEC
[PcdsDynamic, PcdsDynamicEx]
gEfiMdeModulePkgTokenSpaceGuid.PcdS3BootScriptTablePrivateDataPtr|0x0|UINT64|0x00030000

DSC
[PcdsDynamicDefault]
gEfiMdeModulePkgTokenSpaceGuid.PcdS3BootScriptTablePrivateDataPtr|0x0

AutoGen.h
#define _PCD_TOKEN_PcdS3BootScriptTablePrivateDataPtr 1U
#define _PCD_GET_MODE_64_PcdS3BootScriptTablePrivateDataPtr LibPcdGet64(_PCD_TOKEN_PcdS3BootScriptTablePrivateDataPtr)
#define _PCD_SET_MODE_64_PcdS3BootScriptTablePrivateDataPtr(Value) LibPcdSet64(_PCD_TOKEN_PcdS3BootScriptTablePrivateDataPtr, (Value))
========================================

PcdsDynamicExDefault

多了Ex的DynamicExDefault與DynamicDefault很相似，但如果一個Module不是同時間與整個Platform一起Build的，而是一個外部的Binary，Platform與Binary又需要互相存取某個PCD的數值的話，這時候一開始該PCD就需要宣告成DynamicEx型態的PCD。
但外部的Binary在使用DynamicEx PCD時，必須先知道該PCD的GUID與Token值，才能透過LibPcdGetExXX或LibPcdSetExXX來存取。

Example:
DEC
[PcdsDynamic, PcdsDynamicEx]
gEfiMdeModulePkgTokenSpaceGuid.PcdS3BootScriptTablePrivateDataPtr|0x0|UINT64|0x00030000

DSC
[PcdsDynamicExDefault]
gEfiMdeModulePkgTokenSpaceGuid.PcdS3BootScriptTablePrivateDataPtr|0x0

AutoGen.h
#define _PCD_TOKEN_PcdS3BootScriptTablePrivateDataPtr 196608U
#define _PCD_GET_MODE_64_PcdS3BootScriptTablePrivateDataPtr LibPcdGetEx64(&gEfiMdeModulePkgTokenSpaceGuid, _PCD_TOKEN_PcdS3BootScriptTablePrivateDataPtr)
#define _PCD_SET_MODE_64_PcdS3BootScriptTablePrivateDataPtr(Value) LibPcdSetEx64(&gEfiMdeModulePkgTokenSpaceGuid, _PCD_TOKEN_PcdS3BootScriptTablePrivateDataPtr, (Value))
========================================

PcdsDynamicHii

HII型態的PCD在DSC需定好它所對應的Variable Name、GUID、Offset（位於Variable Data的哪個Offset）還有Default Value。
如果系統中不存在著該Variable，那麼就會從PCD取得DSC所定好的預設值，否則就會回傳該Variable的Data加上Offset。

Example:
DEC
[PcdsDynamic, PcdsDynamicEx]
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0xffff|UINT16|0x40000001

DSC
[PcdsDynamicHii]
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|10

AutoGen.h
#define _PCD_TOKEN_PcdPlatformBootTimeOut 15U
#define _PCD_GET_MODE_16_PcdPlatformBootTimeOut LibPcdGet16(_PCD_TOKEN_PcdPlatformBootTimeOut)
#define _PCD_SET_MODE_16_PcdPlatformBootTimeOut(Value) LibPcdSet16(_PCD_TOKEN_PcdPlatformBootTimeOut, (Value))
========================================

PcdsDynamicExHii

多了Ex的DynamicExHii則意思跟DynamicEx很相似。

Example:
DEC
[PcdsDynamic, PcdsDynamicEx]
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0xffff|UINT16|0x40000001

DSC
[PcdsDynamicExHii]
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|10

AutoGen.h
#define _PCD_TOKEN_PcdPlatformBootTimeOut 1073741825U
#define _PCD_GET_MODE_16_PcdPlatformBootTimeOut LibPcdGetEx16(&gEfiIntelFrameworkModulePkgTokenSpaceGuid, _PCD_TOKEN_PcdPlatformBootTimeOut)
#define _PCD_SET_MODE_16_PcdPlatformBootTimeOut(Value) LibPcdSetEx16(&gEfiIntelFrameworkModulePkgTokenSpaceGuid, _PCD_TOKEN_PcdPlatformBootTimeOut, (Value))
========================================

PcdsDynamicVpd and PcdsDynamicExVpd

VPD (Vital Product Data)，在NVS會有一塊區域被用來儲存VPD的資料，與其它Dynamic PCD不同，VPD只能唯讀，無法在執行期間去修改它的數值。
關於VPD的部分，目前我還沒有機會用到。

以上就先介紹的這個部分，下一篇再來介紹應用與原理。

Package, Component, DEC and DSC

2013-12-17T16:03:00.001+08:00

Package

EDK II與EDK最大的差異就是在於多了Package這個模組化的設計，把具有相同類型的Component、Library與各種Declaration放在這同一個目錄。
而每一個Package都有.dec (EDK II Package Declaration File)還有.dsc (EDK II Package Description File)這兩個檔案。

Component

每一個Component可以當作是EFI的執行檔，編譯完會產生出.efi的檔案。
而Component會在它的inf檔中宣告它的MODULE_TYPE，總共有以下這幾種類型：
BASE, SEC, PEI_CORE, PEIM,
DXE_CORE, DXE_DRIVER, DXE_RUNTIME_DRIVER, DXE_SMM_DRIVER, DXE_SAL_DRIVER, UEFI_DRIVER, UEFI_APPLICATION

但要注意的是BASE這種類型只有Library可以使用。
對一般的開發人員來說，常用的應該只有PEIM、 DXE_DRIVER, DXE_RUNTIME_DRIVER, DXE_SMM_DRIVER, UEFI_DRIVER與UEFI_APPLICATION。

DEC (EDK II Package Declaration File)

Package中有.dec這個檔案來宣告提供給內外部的Component所使用的interface，如：header files所在的位置、Library、GUID、protocol、PCD的宣告...等。
等於它是一個提供者的角色，對於使用者（Component、Library）來說，有用到該Package的資源的話，就需要在其inf加入這個DEC。

DEC中包含了以下這些區塊：
Defines、Includes、LibraryClasses、Guids、Ppis、Protocols與Pcds。

========================================
Includes：描述這個Package的header files都集中放在哪一個目錄底下，所以常可在實際的目錄下看到Library、Protocol、Ppi等資料夾存在。
[Includes]
Include

[Includes.IA32]
Include/Ia32

[Includes.X64]
Include/X64

========================================
Guids、Ppis、Protocols：定義了這個Package所提供的Guids、Ppis與Protocols，在以往EDK使用某個GUID的變數時，都必須在.inf加入有定義這個變數的Library，不然就是要自己宣告一個。
而EDK II中我們只要加入包含它所被宣告的DEC即可使用，這部分Compiler都已經幫我們處理好了。
[Guids]
#GuidCName = {xxxxxxxx,xxxx,xxxx,{xx,xx,xx,xx,xx,xx,xx,xx}}

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

[Protocols]
#ProtocolGuidCName = {xxxxxxxx,xxxx,xxxx,{xx,xx,xx,xx,xx,xx,xx,xx}}

========================================
以下描述的各種PCD型態的宣告與初始值。
[PcdsFeatureFlag]
#FeatureFlag PCD is BOOLEAN type, the value is TRUR or 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中的PCD宣告可以是複合式的宣告。
[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE0000000|UINT64|0x0000000a

DSC (EDK II Package Description File)

每一個Package內通常會有一個.dsc的檔案，用來指定要編譯那些Component與Library，並且定義每一個PCD的類型與實際的初始值，因為DEC檔內只是宣告PCD型態與初始值，而實際上的定義，則是在DSC之中。

DSC中包含了以下這些區塊：
Defines、LibraryClasses、與Pcds。

UDK vs. EDK II

2013-12-11T17:46:00.000+08:00

在網路上會看到有UDK (UEFI Development Kits)跟EDK II這兩個相似的東西，但這兩者有甚麼樣的不同？

EDK II是基於開放原始碼，並由一群自願者所開發與維護。
而UDK是由Intel基於某一個EDK II的特定版本所維護並發佈出來的，相對來講會來的比較穩定。

可經由此去取得EDK II與UDK。
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK2

UEFI Detect Utility - 2014

2013-12-11T16:38:00.001+08:00

已做部分更新，先前版本在某些機台會無法使用。

解壓密碼：leon
UefiDetectUtility_131211.7z

MTRR

2011-11-18T17:58:00.000+08:00

MTRR (Memory type range registers) 是CPU內的一組MSR (Model-specific registers) ，它作用為告訴CPU要如何最佳的存取各個記憶體區段，簡單來說是CPU要以哪種快取模式來進行存取。

通常MTRR的初始化是BIOS的任務。

在UEFI中可以使用EfiReadMsr, EfiWriteMsr, MsrRead64, MsrWrite64...等Function來存取，只要拉相對應的Header與Library就好。

IA32_MTRRCAP, Index: 0xFE, Read-Only.

VCNT (variable range registers count) bits 0 ~ 7 - 指出這個CPU支援幾組動態的MTRR，MTRR也是有數量的，也有機會被塞爆。
FIX (fixed range registers supported) flag, bit 8 - 指出是否支援Fixed range MTRRs (IA32_MTRR_FIX64K_00000 through IA32_MTRR_FIX4K_0F8000)。
WC (write combining) flag, bit 10 - 是否支援write-combining (WC) memory。
SMRR (System-Management Range Register) flag, bit 11 - 是否支援SMRR。

IA32_MTRR_DEF_TYPE, Index: 0x2FF.

Type field, bits 0 ~ 7 - 指出未涵蓋在MTRR所定義的記憶體該以何種Cache為預設值。
FE (fixed MTRRs enabled) flag, bit 10 - Enable或Disable Fixed-range MTRR。
E (MTRRs enabled) flag, bit 11 - Enable或Disable動態的MTRR。

Variable - Range Register Pair

一組MTRR有兩個Registers，Base與Mask，起始索引可參考EDK的定義：
#define EFI_CACHE_VARIABLE_MTRR_BASE 0x200

Type field, bits 0 ~ 7 - 此MTRR所定義的範圍該以何種Cache方式存取。
Valid field, bits 11 - 指出此組MTRR是否有效。
PhysBase field, bits 12 ~ (MAXPHYADDR-1) - 取12 ~ (MAXPHYADDR-1) bits，補上3個0，就是組MTRR的Base Address。
PhysMask field, bits 12 ~ (MAXPHYADDR-1) - 一樣只取12 ~ (MAXPHYADDR-1) bits，補上3個0，再做1的補數運算，即可算出此MTRR的長度，值得注意的是長度需為2的次方。

MAXPHYADD代表是CPU的定址能力，長度依CPU而定。

下表為各種存取方式對應到MTRR的Type：

Memory Type and Mnemonic	Encoding in MTRR
Uncacheable (UC)	00h
Write Combining (WC)	01h
Reserved*	02h
Reserved*	03h
Write-through (WT)	04h
Write-protected (WP)	05h
Writeback (WB)	06h
Reserved*	07h ~ FFh

範例：

MTRR	Index	Value	Type/Size	Range
Base	200	00000006	WriteBack
Mask	201	F80000800	2048MB	0 ~ 7FFFFFFF
Base	202	80000006	WriteBack
Mask	203	FC0000800	1024MB	80000000 ~ BFFFFFFF
略...
Base	206	D8000000	Uncacheable
Mask	207	FF8000800	128MB	D8000000 ~ DFFFFFFF
Base	208	D7000000	Uncacheable
Mask	209	FFF000800	16MB	D7000000 ~ D7FFFFFF
略...

對於MTRR所需要注意的Type有沒有設定為正確的Type，還有MTRR有沒有被塞爆，可能導致某些要使用Cache的Memory區域會因沒有宣告Cacheable，造成效能低落...等。

Memory Map

2011-11-17T17:04:00.000+08:00

上圖擷取自Intel Spec.
以下以Intel Platfrom為例。

左圖是實體記憶體大於4 GB以上，有Remap機制。
右圖是記憶體小於4 GB，無Remap機制發生。

每張圖都有提供兩種觀點，System View與Memory Controller View。
System View為整個系統可以存取的記憶體範圍。
Memory Controller View為實際上Physical Memory的整體分布。

通常TOLUD Base ~ 4 GB這段範圍都被PCI Resource Mapping，所以這塊記憶體位置就被占據了。
因此後來發展了Remap機制，把Reclaim Base ~ Reclaim Limit這段範圍的記憶體將它Mapping至實體記憶體4 GB以下OS invisible Reclaim的位置，以便回收利用那些被PCI Resource所佔據的記憶體。
※TOLUD: Top of Lower Usable DRAM
※TOUUD: Top of Upper Usable DRAM

以下為Reclaim的Pseudo-code:

IF (ADDRESS_IN[38:20] ≥ REMAP_BASE[35:20]) AND

(ADDRESS_IN[38:20] ≤ REMAP_LIMIT[35:20]) THEN

ADDRESS_OUT[38:20] = (ADDRESS_IN[38:20] – REMAP_BASE[35:20]) +
0000000b & TOLUD[31:20]

ADDRESS_OUT[19:0] = ADDRESS_IN[19:0]

ME Base = TOM（Top of Memory，實體記憶體總量）- ME UMA Size。
Reclaim Base = MAX (4GB, ME Base) 看何者為大。
Reclaim Limit = Remap Base + (PCI Resource Total Size - 1);
TOUUD Base = Reclaim Limit + 1。
而TOLUD Base在哪裡則是要看PCI Resource整體分配了多少的空間而定，還有Physical Memory Size而定。

由於Intel Graphics本身沒有獨立的記憶體，所以它使用了Physical Memory當成自己的記憶體，所以這部分並沒有辦法Reclaim回來，可見GFX Stolen與GFX GTT Stolen這兩塊，而T SEG也佔據下面那一塊。

OS存取Reclaim Base ~ Reclaim Limit這段範圍時，它其實是將資料儲存在Physical Memory中OS invisible Reclaim這個地方。
所以支援4 GB以上Memory的OS就可以使用被PCI Resource占據的Memory。
這也是預設的情況下，Windows 32-bit的OS常常只能用到3 GB甚至以下的記憶體。

PCI Configuration Space

2011-10-31T17:44:00.001+08:00

可以透過I/O方式或Memory方式來存取PCI Configuration Space，但在此之前要先算出該Device的PFA (PCI Function Address)。

I/O可透過I/O Port的0xCF8來指定所要存取的PCI Device的Address，然後再透過0xCFC將Data讀出。
其公式為：
Address = 0x80000000 + (Bus << 16) + (Device << 11) + (Function << 8) + Index
其中0x80000000稱之為Enable bit。

I/O Mapped I/O

Memory存取起來則比較方便，但缺點要先取得PCI的Base Address。
其公式為：
Address = Base Address + (Bus << 20) + (Device << 15) + (Function << 12) + Index

Memory Mapped I/O

各個參數的長度：
Bus: 0 ~ 255, Device: 0 ~ 31, Function: 0 ~ 7
可以注意到兩者的Index長度是不同的，透過I/O的話只能存取0 ~ 255的範圍，Memory則可到0 ~ 4095。

在這介紹一下PCI Configuration Registers。
PCI Device與PCI Bridge的前16個Bytes的格式是相同的。

PCI Device Register (Type 0):

0E: Header Type

可藉由bit 0 ~ 7這三個定義來判斷是甚麼Device：
#define HEADER_TYPE_DEVICE 0x00
#define HEADER_TYPE_PCI_TO_PCI_BRIDGE 0x01
#define HEADER_TYPE_CARDBUS_BRIDGE 0x02
且可由第8個Bit判斷該Device是不是Multi Function：
#define HEADER_TYPE_MULTI_FUNCTION 0x80
#define IS_PCI_MULTI_FUNC(_p) ((_p)->Hdr.HeaderType & HEADER_TYPE_MULTI_FUNCTION)

10 ~ 27: Base Address Register

上圖為BAR的Layout，長度為32 bits。
Bit 0: 判斷BAR為Memory還是I/O。

Memory:
Bits 0 ~ 3為ReadOnly。
Bits 1 ~ 2: Address Space的長度，00 - 32 bits、01, 11 - Reserved、10 - 64 bits。
Bit 3: 指出是否為Prefetchable，是的話該Device的Bridge Prefetchable Memory將會指定一段範圍。
Bits 4 ~ 31: Base Address。

I/O:
Bits 0: Reserved。
Bits 2 ~ 31: Base Address。

對BAR填入0xFFFFFFFF會得出一組數值，對此數值做1的補數即可得出這個BAR的長度。
BIOS在Enumerate PCI Device時候，便是以此來取得系統所要分配的PCI Resource。

2C ~ 2F: Subsystem Vendor ID and Subsystem ID

PCI Bridge Register (Type 1):

18 ~ 1A: Primary Bus, Secondary Bus and Subordinate Bus

Primary Bus: 此Bridge的前一個Bus Number是多少。
Secondary Bus: 此Bridge的下一個Bus Number是多少。
Subordinate Bus: 此Bridge底下的最後一個Bus Number是多少。

1C ~ 1D: I/O Base and Limit

指此Bridge所涵蓋的I/O Resource是多少，1C為Base、1D為Limit，一般每個Byte只要看前4個bits就好，I/O Limit會自動補上0xFFF，也就是說I/O Resource至少是以0x1000為一個單位。
如：0x4040的範圍為0x4000 ~ 0x4FFF、0x6050為0x5000 ~ 0x6FFF。

20 ~ 23: Memory Base and Limit

指此Bridge所涵蓋的Memory Resource是多少，20 ~ 21為Base、22 ~ 23為Limit，也只需要看前12個bits就好，Limit會自動補上0xFFFFF，也就是說Memory Resource至少是以0x100000(1MB)為一個單位。
如：Base: 0x5A00, Limit: 0x5AF0範圍是0x5A000000 ~ 0x5AFFFFFF

24 ~ 27: Prefetchable Memory Base and Limit

Prefetchable Memory的範圍。

PCI Device Enumeration:

for (Bus = 0; Bus <= PCI_MAX_BUS; ++Bus) {

for (Device = 0; Device <= PCI_MAX_DEVICE; ++Device) {

for (Func = 0; Func <= PCI_MAX_FUNC; ++Func) {

PciAddress = PCI_ACCRESS_ENABLE_BIT | PciCfgAddr (Bus, Device, Func);

//
// Get Vendor ID and Device ID
//
IoOutput32 (PCI_ADDRESS_INDEX, PciAddress);
VendorId = IoInput16 (PCI_DATA_INDEX);
DeviceId = IoInput16 (PCI_DATA_INDEX + PCI_DEVICE_ID_OFFSET);

if (VendorId == 0xFFFF || DeviceId == 0xFFFF) {

continue;

}

//
// Get HeaderType
//
IoOutput32 (PCI_ADDRESS_INDEX, PciAddress | 0x0C);
HeaderType = IoInput8 (PCI_DATA_INDEX + 0x02);

if (Func == 0 && !(HeaderType & HEADER_TYPE_MULTI_FUNCTION)) {

break;

}

UEFI Detect Utility - 2012

2011-10-28T13:56:00.000+08:00

從踏入UEFI領域後，便陸續的開發這個Tool，目前先發布此版本。
部分功能只針對Phoenix SCT2與Intel HR、CR做開發。
目前提供的主要功能如下：
F1 - PCI
F2 - Variable
F3 - Handle
F4 - Memory, Memory Map
F5 - IO Space (預設的Address只針對Intel HR、CR)
F6 - IO Port
F7 - Flash (只支援Phoenix SCT2)
F8 - SPD (只支援Intel HR、CR)
F9 - MTRR (尚未在AMD Platform上測試...)

其他附屬功能：

儲存資料：Ctrl + S
比較數值：Ctrl + C
截取畫面：Ctrl + P
更新速度：+, -

About尚未加入...
如有Bug請歡迎提出！
原先以EDK1做開發，預計之後將移植到EDK2重新開發，真是個浩大工程...

Real Mode

2011-02-20T16:33:00.000+08:00

在此先補點Hardware的基本觀念好了，以前都只做Windows上的Application，有許多底層的硬體基礎要研究...

早期Intel在1978年所推出的16位元8086 CPU有20條位址線，所以可控制的記憶體最大為1048576Bytes = 1MB(2²⁰)。

Intel CPU list:

CPU	Data Bus	Address Bus	Max Addressable Memory
8086/88	16	20	1MB
80286	16	24	16MB
80386SX	16	24	16MB
80386DX	32	32	4GB
80486SX/DX	32	32	4GB
Pentium	64	32	4GB
Pentium Pro	64	36	64GB

以下為1MB以下各區段的記憶體配置表。
Memory Map:

0xE0000 - 0xFFFFF	BIOS
0xC8000 - 0xDFFFF	I/O BIOS
0xC0000 - 0xC7FFF	Video BIOS
0xB8000 - 0xBFFFF	VGA Color Mode Text RAM
0xB0000 - 0xB7FFF	VGA Monochrome Mode Text RAM
0xA0000 - 0xAFFFF	VGA Graphics Mode RAM
0x00500 - 0x9FFFF	User Program Space
0x00400 - 0x004FF	BIOS Data Area
0x00000 - 0x003FF	Interrupt Vector Table

※其中0xA0000至0xBFFFF為Video RAM

傳統記憶體(Conventional Memory)為640KB以下
延伸記憶體(Extended Memory)為1MB以上
UMB(Upper Memory Block)的範圍為0xA0000至0xFFFFF的位址，大小為384KB

早期CPU的Register只有16bits，所以使用兩個Register來定址，表達方式CS:IP(Code Segment:Instruction Pointer)，而一個Segment的長度為64KB。
其算法為Address = Segment * 16 + Offset
舉例C800:1234的實際位址為C8000 + 1234 = C9234，只要將CS往左偏移4個bits再加上IP即可。

但由於Address Bus只有20bits，CS:IP最高卻可表達到FFFF:FFFF(10FFEF = 1114095Bytes)，超過了1MB界線的話，將會進行為Memory Wrap，如0x10AAAA的位址為0xAAAA。
然而之後的CPU Address Bus都已超過20bits（如80286可定址到16MB的記憶體），若要以用額外的記憶體空間，就必須要將A20 Enable。
有些利用Memory Wrap特性的程式可能最後發生問題了，所以遇到該類型程式還是必須將A20 Disable掉。
FFFF:0010(1MB)至FFFF:FFFF這段空間就稱為HMA(High Memory Area)。

關於A20的開關，這又是一門學問了...

ME沒起來與SPI Flash無法寫入的問題

2011-01-14T17:09:00.000+08:00

這陣子使用了某家給的ME，但卻發生ME沒有起來，且Variable無法寫入，包含用tool刷BIOS...
原來是ME設定中他們只用了某家的Flash型號，而我們是用別家的，自然而然就發生了這樣的狀況。
可以用FITC去修改ME的設定與增加所支援的SPI Flash型號。

於左邊樹狀目錄上的VSCC Table按下右鍵，選擇Add Table Entry...
輸入完Entry Name後，就可在右邊填入Flash的VID、DID與VSCC。
如不知道手邊的Flash資料可於FITC目錄底下的VSCCommn_bin Content.pdf去做查詢的動作。

ASF(Alert Standard Format)

2011-01-04T16:48:00.000+08:00

最近剛好有碰到這東西，記一下找的相關資料，以防這記性越來越差的腦袋忘掉...

ASF(Alert Standard Format)是由DMTF所訂定的標準規範，可使具有ASF功能的電腦能夠遠端監控(Remote monitoring)、遠端管理(Remote management)及遠端控制(Remote control)，可在遠端電腦不具有OS的情況下作控管的功能。
ASF需有內建網路晶片(LOM)或網路卡(NIC)的支援，還有BIOS的啟用等搭配才能夠使用其功能。

其功能有錯誤警報、監控(溫度、系統狀態等)與控制(開、關機)...等。

※DMTF(Distributed Management Task Force)為訂定、開發與維護電腦管理相關標準規範的組織。

請做好EFI的指標動態記憶體配置...

2011-01-04T11:30:00.000+08:00

新年第一帖：
最近使用了某家的Application，但每次執行到EFI_LEGACY_BIOS_PROTOCOL內的FarCall86時必當...
結果原來是該Application中的指標記憶體配置沒做好，以致它的起始位置在1MB以下，覆蓋掉原先的資料造成錯誤。

佔版面時間：
#define EFI_LEGACY_BIOS_PROTOCOL_GUID \
{ 0xdb9a1e3d, 0x45cb, 0x4abb, 0x85, 0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d}

typedef struct _EFI_LEGACY_BIOS_PROTOCOL {
　EFI_LEGACY_BIOS_INT86 Int86;
　EFI_LEGACY_BIOS_FARCALL86 FarCall86;
　EFI_LEGACY_BIOS_CHECK_ROM CheckPciRom;
　EFI_LEGACY_BIOS_INSTALL_ROM InstallPciRom;
　EFI_LEGACY_BIOS_BOOT LegacyBoot;
　EFI_LEGACY_BIOS_UPDATE_KEYBOARD_LED_STATUS UpdateKeyboardLedStatus;
　EFI_LEGACY_BIOS_GET_BBS_INFO GetBbsInfo;
　EFI_LEGACY_BIOS_SHADOW_ALL_LEGACY_OPROMS ShadowAllLegacyOproms;
　EFI_LEGACY_BIOS_PREPARE_TO_BOOT_EFI PrepareToBootEFI;
　EFI_LEGACY_BIOS_GET_LEGACY_REGION GetLegacyRegion;
　EFI_LEGACY_BIOS_COPY_LEGACY_REGION CopyLegacyRegion;
　EFI_LEGACY_BIOS_BOOT_UNCONVENTIONAL_DEVICE BootUnconventionalDevice;
} EFI_LEGACY_BIOS_PROTOCOL;

可用此Protocol執行傳統的Legacy Code或OS。

EFI中的CR (CONTAINING RECORD)

2010-10-05T11:39:00.000+08:00

在EFI中常常可以見到CR這個define，而這個define的作用是，當擁有某個結構成員的位址時，但卻不知整個結構的頭在哪裡的時候，就可利用這個方法來取得整個結構所在的位址，此為CR的定義：
#define _CR(Record, TYPE, Field) ((TYPE *) ((CHAR8 *) (Record) - (CHAR8 *) &(((TYPE *) 0)->Field)))
Record：為該成員的位址
TYPE：為該結構的型態
Field：為在結構中指向的該成員

這個方法可以分開兩段來看：
(CHAR8 *) (Record)：該成員的實際位址
(CHAR8 *) &(((TYPE *) 0)->Field)：該成員在結構中的偏移量

兩個做相減之後便可取得結構頭的位址，最後再來個(TYPE *)作強制轉換。

PCI I/O Protocols

2010-10-04T17:19:00.000+08:00

若要對PCI Device進行讀寫的動作時，可以使用EFI_PCI_IO_PROTOCOL所提供的Function來簡化以前所要做的步驟，以下是PCI IO Protocol的結構：
typedef struct _EFI_PCI_IO_PROTOCOL {
　EFI_PCI_IO_PROTOCOL_POLL_IO_MEM PollMem;
　EFI_PCI_IO_PROTOCOL_POLL_IO_MEM PollIo;
　EFI_PCI_IO_PROTOCOL_ACCESS Mem;
　EFI_PCI_IO_PROTOCOL_ACCESS Io;
　EFI_PCI_IO_PROTOCOL_CONFIG_ACCESS Pci;
　EFI_PCI_IO_PROTOCOL_COPY_MEM CopyMem;
　EFI_PCI_IO_PROTOCOL_MAP Map;
　EFI_PCI_IO_PROTOCOL_UNMAP Unmap;
　EFI_PCI_IO_PROTOCOL_ALLOCATE_BUFFER AllocateBuffer;
　EFI_PCI_IO_PROTOCOL_FREE_BUFFER FreeBuffer;
　EFI_PCI_IO_PROTOCOL_FLUSH Flush;
　EFI_PCI_IO_PROTOCOL_GET_LOCATION GetLocation;
　EFI_PCI_IO_PROTOCOL_ATTRIBUTES Attributes;
　EFI_PCI_IO_PROTOCOL_GET_BAR_ATTRIBUTES GetBarAttributes;
　EFI_PCI_IO_PROTOCOL_SET_BAR_ATTRIBUTES SetBarAttributes;
　UINT64 RomSize;
　VOID *RomImage;
} EFI_PCI_IO_PROTOCOL;

// ++++++++++PCI Configuration Space++++++++++
首先來講如何取得PCI Configuration Space：

以上為PCI Configuration Space配置表Type 0。

先使用LocateHandleBuffer，將所有PCI Device的Handle全都找出來：
gBS->LocateHandleBuffer (ByProtocol, &gEfiPciIoProtocolGuid, NULL, &PciHandleCount, &PciHandleBuffer);

隨後在指定的Handle中將PCI IO Protocol找出來：
gBS->OpenProtocol (PciHandle, &gEfiPciIoProtocolGuid, &PciIo, ImageHandle, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);

以下可取得PCI Device的四個參數：
UINTN Seg;
UINTN Bus;
UINTN Device;
UINTN Function;
PciIo->GetLocation (PciIo, &Seg, &Bus, &Device, &Function);

若要取得整張配置表可以宣告此union型別變數：
typedef union {
　PCI_TYPE00 Device;
　PCI_TYPE01 Bridge;
} PCI_TYPE_GENERIC;
可用其Header Type來判斷它是Device或Bridge，00h與01h...等。

typedef struct {
　PCI_DEVICE_INDEPENDENT_REGION Hdr;
　PCI_DEVICE_HEADER_TYPE_REGION Device;
} PCI_TYPE00;

typedef struct {
　PCI_DEVICE_INDEPENDENT_REGION Hdr;
　PCI_BRIDGE_CONTROL_REGISTER Bridge;
} PCI_TYPE01;

PCI_DEVICE_INDEPENDENT_REGION、PCI_DEVICE_HEADER_TYPE_REGION、PCI_BRIDGE_CONTROL_REGISTER
這三個結構定義可看Spec。

宣告一個PCI_TYPE_GENERIC變數
PCI_TYPE_GENERIC Pci;
PciIo->Pci.Read (PciIo, EfiPciWidthUint32, 0, sizeof (PCI_TYPE_GENERIC) / sizeof (UINT32), &Pci);
第二個參數可以設定每次所要取得的大小，詳情可看其定義。
第三個參數為起始位址，由於要抓整張表所以便填入0。
第四個參數為總共要抓取的次數。
成功後可一一取值，如：
Pci.Device.Hdr.VendorId;
Pci.Device.Device.SubsystemVendorID;

若要取得配置表的其中一個值，可先算出所在位址，如Status位址在06h而大小是16bits，先宣告一個UINT16的變數Status，代入Pci.Read()。
PciIo->Pci.Read (PciIo, EfiPciWidthUint16, 0, 1, &Status);

如果要取得ClassCode的話，而它是3個8bits整數，所以宣告一個UINT8 ClassCode[3]陣列，再呼叫Pci.Read()。
PciIo->Pci.Read (PciIo, EfiPciWidthUint8, 0, 3, ClassCode);

以下可印出整張表的內容：
UINT8 Content;
for (i = 0x00; i <= 0x0F; ++i) { 　for (j = 0x00; j <= 0x0F; ++j) { 　　Status = PciIo->Pci.Read (PciIo, EfiPciIoWidthUint8, ((i * 0x10) + j), sizeof (Content), &Content);
　　PrintAt (j * 3, i, L"%02x", Content);
　}
}

// ++++++++++PCI Base Address Register++++++++++
接下來是Base Address Register的部分，一般PCI Device共有六個BAR，而PCI/PCI Bridge只有兩個BAR，可看Spec。
而BAR又分了IO Space與Memory Space兩種方式，可看其第一個bit決定，0是Memory Space而1是IO Space，也就是基偶之分，EFI也提供了一個結構儲存該BAR的屬性。
typedef struct {
　UINT8 Desc;
　UINT16 Len;
　UINT8 ResType;
　UINT8 GenFlag;
　UINT8 SpecificFlag;
　UINT64 AddrSpaceGranularity;
　UINT64 AddrRangeMin;
　UINT64 AddrRangeMax;
　UINT64 AddrTranslationOffset;
　UINT64 AddrLen;
} EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR;

此時宣告其指標：
EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Resources;
PciIo->GetBarAttributes (PciIo, PciBarIndex, NULL, &Resources);
注意用完Resources後要釋放掉。

Resources->ResType也可判斷BAR的屬性（IO/Memory）。
if (Resources->ResType == 0) {
　PciIo->Mem.Read(PciIo, EfiPciIoWidthUint8, PciBarIndex,0, sizeof (Content), &Content);
} else {
　PciIo->Io.Read(PciIo, EfiPciIoWidthUint8, PciBarIndex, 0, sizeof (Content), &Content);
}
BarIndex按自己所需的BAR代入0~5(P2P Bridge: 0~1)的整數。
至於寫入也是相同方式。

Variable Service

2010-10-02T15:52:00.000+08:00

EFI BIOS使用Variable來儲存各個配置設定，通常存放於NVRAM或CMOS中，這部分就看IBV如何訂定，在DXE階段後可使用Runtime Services所提供的三個服務來存取Variable，基本上一個Variable是由Name、GUID與Data所組成，但其在記憶體中並沒有一定的順序性，所以要找到一個Data就得靠Name和GUID所提供的Index來取得，先介紹這三個Services。

GetNextVariableName(
IN OUT UINTN *VariableNameSize,
IN OUT CHAR16 *VariableName,
IN OUT EFI_GUID *VendorGuid
);
可以透過傳進去的Name與GUID來得到它下一個Name與GUID，並傳出Name的實際Size，如果您不知道任何的Name與GUID的話，此時可填入空的Name與GUID，便會將第一組傳回。

GetVariable(
　IN CHAR16 *VariableName,
　IN EFI_GUID *VendorGuid,
　OUT UINT32 *Attributes OPTIONAL,
　IN OUT UINTN *DataSize,
　OUT VOID *Data
);
可傳回對應Name與GUID的Data，要傳出的Data要先為它配置好一個空間（動態或靜態皆可），如果不知道Data的Size，此時可先傳入一個非0的Size，它會將實際的Size傳出，並傳回EFI_BUFFER_TOO_SMALL的錯誤訊息，接下來再動態配置空間即可。

SetVariable(
　IN CHAR16 *VariableName,
　IN EFI_GUID *VendorGuid,
　IN UINT32 Attributes,
　IN UINTN DataSize,
　IN VOID *Data
);
將傳入的Data寫入至對應的Name與GUID。

Attributes:
#define EFI_VARIABLE_NON_VOLATILE 0x00000001
#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002
#define EFI_VARIABLE_RUNTIME_ACCESS 0x00000004
#define EFI_VARIABLE_HARDWARE_ERROR_RECORD 0x00000008
#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS 0x00000010

淺談EFI Protocol

2010-09-29T22:45:00.000+08:00

EFI的Protocol類似於物件導向中的Interface，它訂定好一個標準，而實作是經由別的程式來完成，而使用也是透過這個標準來使用。
一個Protocol基本上是由數個變數與函式指標所組成的結構，也會跟隨著一個唯一識別的GUID(Globally Unique Identifier)，這部分與PEI階段的PEIM中的PPI滿像的，各個不同程式間可利用方法將所需的功能找出來使用。
安裝一個Protocol時會與自己對應的GUID配在一起，放置於Handle Database中，Handle Database是一個Linked List，每個Handle被串在一起，而Handle底下又與屬於它的所有GUID | Protocol相連。

EFI DRIVER BINDING PROTOCOL原型：
typedef struct _EFI_DRIVER_BINDING_PROTOCOL {
　EFI_DRIVER_BINDING_PROTOCOL_SUPPORTED Supported;
　EFI_DRIVER_BINDING_PROTOCOL_START Start;
　EFI_DRIVER_BINDING_PROTOCOL_STOP Stop;
　UINT32 Version;
　EFI_HANDLE ImageHandle;
　EFI_HANDLE DriverBindingHandle;
} EFI_DRIVER_BINDING_PROTOCOL;

其GUID：
#define EFI_DRIVER_BINDING_PROTOCOL_GUID \
{0x18A031AB,0xB443,0x4D1A,0xA5,0xC0,0x0C,0x09,0x26,0x1E,0x9F,0x71}

extern EFI_GUID gEfiDriverBindingProtocolGuid = EFI_DRIVER_BINDING_PROTOCOL_GUID;
基本上是使用gEfiDriverBindingProtocolGuid這個變數來與EFI DRIVER BINDING PROTOCOL做關聯。

與Protocol常用的相關服務如下：
InstallMultipleProtocolInterfaces (
　IN OUT EFI_HANDLE *Handle,
　...
　);
安裝數個Protocol與搭配的GUID至指定的Handle底下。

UninstallMultipleProtocolInterfaces (
　IN EFI_HANDLE Handle,
　...
　);
移除數個Handle底下的Protocol與所搭配的GUID。

LocateHandleBuffer (
　IN EFI_LOCATE_SEARCH_TYPE SearchType,
　IN EFI_GUID *Protocol OPTIONAL,
　IN VOID *SearchKey OPTIONAL,
　IN OUT UINTN *NoHandles,
　OUT EFI_HANDLE **Buffer
　);
可將全部或以特定的條件將Handle取出。

ProtocolsPerHandle (
　IN EFI_HANDLE Handle,
　OUT EFI_GUID ***ProtocolBuffer,
　OUT UINTN *ProtocolBufferCount
　);
取得指定的Handle底下所有的Protocol GUID陣列，並傳出數量。

OpenProtocolInformation (
　IN EFI_HANDLE Handle,
　IN EFI_GUID *Protocol,
　OUT EFI_OPEN_PROTOCOL_INFORMATION_ENTRY **EntryBuffer,
　OUT UINTN *EntryCount
　);
取得Handle底下指定的GUID的Information Entry陣列，並回傳數量。

LocateProtocol (
　IN EFI_GUID *Protocol,
　IN VOID *Registration OPTIONAL,
　OUT VOID **Interface
　);
以指定的GUID取出第一個Protocol。

HandleProtocol (
　IN EFI_HANDLE Handle,
　IN EFI_GUID *Protocol,
　OUT VOID **Interface
　);
取出Handle中指定的Protocol，以GUID為識別。

OpenProtocol (
　IN EFI_HANDLE Handle,
　IN EFI_GUID *Protocol,
　OUT VOID **Interface OPTIONAL,
　IN EFI_HANDLE AgentHandle,
　IN EFI_HANDLE ControllerHandle,
　IN UINT32 Attributes
　);
類似HandleProtocol()，但提供了更安全的做法，綁訂指定的Handle，避免使用中的Protocol被Uninstall。
此為最後一個參數的定義：
#define EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL 0x00000001
#define EFI_OPEN_PROTOCOL_GET_PROTOCOL 0x00000002
#define EFI_OPEN_PROTOCOL_TEST_PROTOCOL 0x00000004
#define EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER 0x00000008
#define EFI_OPEN_PROTOCOL_BY_DRIVER 0x00000010
#define EFI_OPEN_PROTOCOL_EXCLUSIVE 0x00000020
依需要使用，有些定義可不用CloseProtocol()。

CloseProtocol (
　IN EFI_HANDLE Handle,
　IN EFI_GUID *Protocol,
　IN EFI_HANDLE AgentHandle,
　IN EFI_HANDLE ControllerHandle
　);
為以OpenProtocol()開啟的Protocol解除占用。

於EDK中加入DXE Driver

2010-08-31T20:15:00.000+08:00

建立好EDK環境後，先找到自己要放置Driver的資料夾，這個例子是放在Sample\Platform\Generic\底下，建立一個TestDriver的資料夾。

依序建立以下檔案：
TestDriver.h
========================================
#ifndef _TEST_DRIVER_H_
#define _TEST_DRIVER_H_

#include "Tiano.h"
#include "EfiDriverLib.h"

//
// Function Prototypes
//
EFI_STATUS
EFIAPI
TestDriverEntry (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
);

#endif
========================================

TestDriver.c
========================================
#include "TestDriver.h"

EFI_DRIVER_ENTRY_POINT (TestDriverEntry)

EFI_STATUS
EFIAPI
TestDriverEntry (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS Status;

Status = EfiInitializeDriverLib(ImageHandle, SystemTable);

DEBUG_CODE (
DEBUG ((EFI_D_INFO | EFI_D_LOAD, "Test = %s\n", L"TestDriverEntry"));
)

return Status;
}
========================================

TestDriver.inf
========================================
[defines]
BASE_NAME = TestDriver
FILE_GUID = 7B257F2E-7177-408a-BA46-567C07301F69
COMPONENT_TYPE = BS_DRIVER

[sources.common]
TestDriver.c

[libraries.common]
EdkGuidLib
EfiGuidLib
EfiProtocolLib
EfiDriverLib

[includes.common]
$(EDK_SOURCE)\Foundation
$(EDK_SOURCE)\Foundation\Efi
$(EDK_SOURCE)\Foundation\Framework
.
$(EDK_SOURCE)\Foundation\Include
$(EDK_SOURCE)\Foundation\Efi\Include
$(EDK_SOURCE)\Foundation\Framework\Include
$(EDK_SOURCE)\Foundation\Include\IndustryStandard
$(EDK_SOURCE)\Foundation\Core\Dxe
$(EDK_SOURCE)\Foundation\Library\Dxe\Include
$(EDK_SOURCE)\Sample\Include

[nmake.common]
IMAGE_ENTRY_POINT=TestDriverEntry
========================================

其中.inf的FILE_GUID可由Visual Studio中的Tools->建立GUID這個工具建立。
加入以上檔案後開啟Sample\Platform\Nt32\Build\Nt32.dsc
找一個地方加入這一行：
Sample\Platform\Generic\Test\TestDriver\TestDriver.inf

範例：
#
# Fat File System driver. Default is binary only
#
Other\Maintained\Universal\Disk\FileSystem\EnhancedFat\Dxe\Fat.inf

# By Yourself
Sample\Platform\Generic\Test\TestDriver\TestDriver.inf

存檔後即可build，此時在Console即可印出剛剛程式中的debug訊息：
EventTest = EventTestDriverEntry

Finish！

建立EDK模擬環境與範例HelloWorld編譯

2010-08-12T11:19:00.000+08:00

首先先下載EDK，其次下載EFI Shell，最後再到EDK Apps下載HelloWorld範例檔。

一、解壓縮EDK至C:\根目錄底下。

二、開啟剛下載的EFI Shell，將Shell目錄底下的檔案全部解壓縮至C:\EDK\Other\Maintained\Application\UefiShell\中。

三、再來一樣把HelloWorld解壓縮至此。

四、開啟Sample\Platform\Nt32\Build\Nt32.dsc，找到[Libraries.Platform]這個區塊，
在下面加入Other\Maintained\Application\UefiShell\Library\EfiShellLib.inf；再來找到[Components]區塊，在DEFINE FV=FvRecovery後面添加Other\Maintained\Application\UefiShell\HelloWorld\HelloWorld.inf FV=NULL，之後存檔即可。

編譯前依照您的Visual Studio版本修改Sample\Platform\Nt32\Build\Config.env，找到USE_VC8，只要您是2005(含以上版本)就改為YES。

打開【Visual Studio 命令提示字元】，進入到Sample\Platform\Nt32目錄底下，鍵入SET EDK_SOURCE=C:\EDK，完成後再輸入build編譯即可。

編譯完成後，先執行uefi底下的System.cmd設定好環境變數，最後可到IA32底下執行secmain.exe，這個就是Shell的模擬環境，相同的地方底下也有個剛剛一同建置好的HelloWorld.efi，可在Shell中執行他，預設是放在fsnt0(f9)裝置。

======================================================================

而起始Loading部分的Logo圖檔更換方式有兩種：
一、直接到Sample\Platform\Generic\Logo底下將logo.bmp換掉，再重新編譯一次。

二、開啟Sample\Platform\Nt32\Build\Nt32.dsc到Sample\Platform\Generic\Logo\Logo.inf這一行，修改為Sample\Platform\Generic\Logo\Logo.inf SOURCE_OVERRIDE_PATH=您自己的logo.bmp目錄（不含檔名）。

建立EDK II模擬環境

2010-08-03T19:32:00.000+08:00

EDK II可於此https://github.com/tianocore/edk2下載。

我的系統為Win7 X64，Visual Studio版本為2010，欲編譯的架構為IA32

假設EDK II的存放地點在C:\EDK2\，執行Visual Studio 命令提示字元 (2010)（依您所安裝的VS版本開啟）
目錄切換到C:\EDK2\，執行edksetup.bat佈署環境。
接下來開啟Conf\target.txt，進行編譯前的設置，有以下參數：
ACTIVE_PLATFORM = Nt32Pkg/Nt32Pkg.dsc
TARGET = DEBUG
TARGET_ARCH = IA32
TOOL_CHAIN_CONF = Conf/tools_def.txt
TOOL_CHAIN_TAG = MYTOOLS
MAX_CONCURRENT_THREAD_NUMBER = 1
MULTIPLE_THREAD = Disable
BUILD_RULE_CONF = Conf/build_rule.txt

我只修改MAX_CONCURRENT_THREAD_NUMBER與MULTIPLE_THREAD，若您的CPU為多核心，則可做多執行續的程式編譯，其餘參數可依照自己所需的平台與架構做修改。

另外由於我的系統為X64，VS 2010安裝的路徑為C:\Program Files (x86)\Microsoft Visual Studio 10.0，而Conf/tools_def.txt中並沒有定義VS 2010的變數，此時如要編譯程式將會有錯誤！
接下來開啟tools_def.txt這個文字檔，內有各項工具的定義，唯獨少了VS 2010，此時仿照VS 2008的方式為VS 2010定義一組新變數（或者直接修改VS 2008的變數），接下來搜尋到第二個MYTOOLS（約3083行），底下有各架構的定義，找到IA32 definitions，將他底下括號中的變數修改成剛為VS 2010所定義的變數即可。
其餘方法，自己的編譯器已有定義在內的話：
1. build -t VS2005 (直接指定)
2. 修改tools_def.txt中的MYTOOLS對應的變數。
3. 修改target.txt中的TOOL_CHAIN_TAG對應的變數。如：TOOL_CHAIN_TAG = VS2005

修改完成後，繼續回到Visual Studio 命令提示字元 (2010)，在C:\EDK2\底下鍵入build執行，接下來就等待建置完成。

完成後，輸入cd Build\NT32\DEBUG_MYTOOLS\IA32後，資料夾底下有secmain.exe，這個就是Shell的模擬環境，長得滿像DOS的，基本操作方式也很相似，fsnt0:底下有一些簡單的Apps可執行，如HelloWorld、Timer...等。