小華的部落格

Dump TCG log

2025-05-25T22:38:00.000-07:00

Dump TCG log

一個簡易的方式在UEFI Shell底下，先找到TPM2 的ACPI Table ,再從Table中找到紀錄TCG log的記憶體位址(一般UEFI PCD目前都是設定0x10000 大小，但進入OS後，OS有可能會加大這塊的內容) ，然後分析TCG log中的每一筆紀錄的Event , 然後重新計算Digest ，這樣子可以呈現出BIOS交給OS前，TCG log中所記錄的TPM PCR可能的值會是甚麼. 底下是部分實作的程式碼，幫助大家了解流程.

// Loop through all ACPI tables to find TPM2

Status = GetAcpiTableBySignature(SIGNATURE_32('T','P','M','2'), &Table);

Tpm2Table = (EFI_TPM2_ACPI_TABLE_V4 *) Table;

if (Tpm2Table == NULL) {

Print(L"[Fail] TPM2 ACPI Table not found\n");

return EFI_NOT_FOUND;

}

Print(L"TPM2 ACPI Table found\n");

Print(L"Event Log Start Address: 0x%lx\n", Tpm2Table->Lasa);

Print(L"Event Log Length: %u bytes\n", Tpm2Table->Laml);

Print(L"******** TCG Log Dump ******** \n");

PrintHexAndAscii((UINT8 *) Tpm2Table->Lasa, (UINTN) Tpm2Table->Laml); // Print partial event data

Print(L"******** TCG Events ******** \n");

// 儲存 PCR0 到 PCR23 的最後 Digest

PCRDigest PcrDigests[PCR_COUNT];

ZeroMem(PcrDigests, sizeof(PCRDigest) * PCR_COUNT);

MY_ACPI_TCG2_EVENT *TcgEvent = (MY_ACPI_TCG2_EVENT *)(UINTN)Tpm2Table->Lasa;

UINT8 *LogEnd = (UINT8 *)(UINTN)(Tpm2Table->Lasa + Tpm2Table->Laml);

UINTN EventIndex = 0;

while ((UINT8 *)TcgEvent < LogEnd) {

UINT8 *EventStart = (UINT8 *)TcgEvent;

//TODO: 1. 處理EV_NO_ACTION

2.CalculateDigest (CombinedData, CombinedDataSize, PcrDigests[PcrIndex].Digest, AlgId);

}

...

// 1.找到事件起始位置。

// 2.依序讀出：

// PCRIndex（4 bytes）

// EventType（4 bytes）

// DigestCount（4 bytes）

// 3.每個 Digest 結構：

// AlgorithmId（2 bytes）

// Digest（對 SHA128 而言，是 20 bytes, SHA256 而言，是 32 bytes..etc）

// 3.接著是 EventDataSize（4 bytes）

// 4.再來是 EventData

#pragma pack(1)

typedef struct {

UINT32 PCRIndex; // 4 bytes

UINT32 EventType; // 4 bytes

UINT32 DigestCount; // 4 bytes

// 之後是 DigestList 和 EventData

UINT8 Event[]; // 可變長度，儲存 Digest 和 EventData (參考前面說明)

} MY_ACPI_TCG2_EVENT;

#pragma pack()

#define PCR_COUNT 24 // PCR0 到 PCR23，共 24 個 PCR

// 儲存每個 PCR 的最後一筆 Digest

typedef struct {

UINT8 Digest[64]; // 假設 Digest 最長為 64 字節 (可以根據實際需要調整)

UINTN DigestSize; // Digest 大小

} PCRDigest;

UINTN

GetHashSizeFromAlgo(

IN TPMI_ALG_HASH HashAlgo

)

{

switch (HashAlgo) {

case TPM_ALG_SHA1: return 20;

case TPM_ALG_SHA256: return 32;

case TPM_ALG_SHA384: return 48;

case TPM_ALG_SHA512: return 64;

case TPM_ALG_SM3_256:return 32;

default: return 0;

}

// Hex + ASCII Dump

VOID

PrintHexAndAscii(IN UINT8 *Data, IN UINTN Length)

{

for (UINTN i = 0; i < Length; i += 16) {

Print(L"%08x: ", i);

// Print hex

for (UINTN j = 0; j < 16; j++) {

if ((i + j) < Length) {

Print(L"%02x ", Data[i + j]);

} else {

Print(L" ");

}

Print(L" ");

// Print ASCII

for (UINTN j = 0; j < 16; j++) {

if ((i + j) < Length) {

CHAR8 c = (CHAR8)Data[i + j];

if (c >= 0x20 && c <= 0x7E) {

Print(L"%c", c);

} else {

Print(L".");

}

Print(L"\n");

}

// Covert to EventType string

CONST CHAR16* GetEventTypeString(UINT32 EventType)

{

// Standard event types

switch (EventType) {

case EV_PREBOOT_CERT: return L"EV_PREBOOT_CERT(0x00000000)";

case EV_POST_CODE: return L"EV_POST_CODE(0x00000001)";

case EV_NO_ACTION: return L"EV_NO_ACTION(0x00000003)";

case EV_SEPARATOR: return L"EV_SEPARATOR(0x00000004)";

case EV_ACTION: return L"EV_ACTION(0x00000005)";

case EV_EVENT_TAG: return L"EV_EVENT_TAG(0x00000006)";

case EV_S_CRTM_CONTENTS: return L"EV_S_CRTM_CONTENTS(0x00000007)";

case EV_S_CRTM_VERSION: return L"EV_S_CRTM_VERSION(0x00000008)";

case EV_CPU_MICROCODE: return L"EV_CPU_MICROCODE(0x00000009)";

case EV_PLATFORM_CONFIG_FLAGS: return L"EV_PLATFORM_CONFIG_FLAGS(0x0000000A)";

case EV_TABLE_OF_DEVICES: return L"EV_TABLE_OF_DEVICES(0x0000000B)";

case EV_COMPACT_HASH: return L"EV_COMPACT_HASH(0x0000000C)";

case EV_NONHOST_CODE: return L"EV_NONHOST_CODE(0x0000000F)";

case EV_NONHOST_CONFIG: return L"EV_NONHOST_CONFIG(0x00000010)";

case EV_NONHOST_INFO: return L"EV_NONHOST_INFO(0x00000011)";

case EV_OMIT_BOOT_DEVICE_EVENTS: return L"EV_OMIT_BOOT_DEVICE_EVENTS(0x00000012)";

// EFI specific event types (0x80000000 and above)

case EV_EFI_VARIABLE_DRIVER_CONFIG: return L"EV_EFI_VARIABLE_DRIVER_CONFIG(0x80000001)";

case EV_EFI_VARIABLE_BOOT: return L"EV_EFI_VARIABLE_BOOT(0x80000002)";

case EV_EFI_BOOT_SERVICES_APPLICATION: return L"EV_EFI_BOOT_SERVICES_APPLICATION(0x80000003)";

case EV_EFI_BOOT_SERVICES_DRIVER: return L"EV_EFI_BOOT_SERVICES_DRIVER(0x80000004)";

case EV_EFI_RUNTIME_SERVICES_DRIVER: return L"EV_EFI_RUNTIME_SERVICES_DRIVER(0x80000005)";

case EV_EFI_GPT_EVENT: return L"EV_EFI_GPT_EVENT(0x80000006)";

case EV_EFI_ACTION: return L"EV_EFI_ACTION(0x80000007)";

case EV_EFI_PLATFORM_FIRMWARE_BLOB: return L"EV_EFI_PLATFORM_FIRMWARE_BLOB(0x80000008)";

case EV_EFI_HANDOFF_TABLES: return L"EV_EFI_HANDOFF_TABLES(0x80000009)";

case EV_EFI_PLATFORM_FIRMWARE_BLOB2: return L"EV_EFI_PLATFORM_FIRMWARE_BLOB2(0x8000000A)";

case EV_EFI_HANDOFF_TABLES2: return L"EV_EFI_HANDOFF_TABLES2(0x8000000B)";

case EV_EFI_HCRTM_EVENT: return L"EV_EFI_HCRTM_EVENT(0x80000010)";

case EV_EFI_VARIABLE_AUTHORITY: return L"EV_EFI_VARIABLE_AUTHORITY(0x800000E0)";

case EV_EFI_SPDM_FIRMWARE_BLOB: return L"EV_EFI_SPDM_FIRMWARE_BLOB(0x800000E1)";

case EV_EFI_SPDM_FIRMWARE_CONFIG: return L"EV_EFI_SPDM_FIRMWARE_CONFIG(0x800000E2)";

// Add

//case EV_EFI_SPDM_DEVICE_BLOB: return L"EV_EFI_SPDM_DEVICE_BLOB(0x800000E1)"; // 和 EV_EFI_SPDM_FIRMWARE_BLOB 相同

//case EV_EFI_SPDM_DEVICE_CONFIG: return L"EV_EFI_SPDM_DEVICE_CONFIG(0x800000E2)"; // 和 EV_EFI_SPDM_FIRMWARE_CONFIG 相同

default: return L"UNKNOWN(0x%08x)"; // Unknown event type

}

#pragma pack(1)

typedef struct { // Refer to Tcg2Acpi.c

EFI_ACPI_DESCRIPTION_HEADER Header; // "TPM2"

// Flags field is replaced in version 4 and above

// BIT0~15: PlatformClass This field is only valid for version 4 and above

// BIT16~31: Reserved

UINT32 Flags;

UINT64 AddressOfControlArea;

UINT32 StartMethod;

UINT8 PlatformSpecificParameters[12]; // size up to 12

UINT32 Laml; // Optional

UINT64 Lasa; // Optional

} EFI_TPM2_ACPI_TABLE_V4;

#pragma pack()

// Signature macro

//#define SIGNATURE_32(A,B,C,D) ((UINT32)(A) | ((UINT32)(B)<<8) | ((UINT32)(C)<<16) | ((UINT32)(D)<<24))

EFI_STATUS

GetAcpiTableBySignature (

IN UINT32 Signature,

OUT EFI_ACPI_DESCRIPTION_HEADER **OutTable

)

{

EFI_CONFIGURATION_TABLE *ConfigTable = gST->ConfigurationTable;

EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *Rsdp = NULL;

EFI_ACPI_DESCRIPTION_HEADER *Xsdt;

UINT64 *EntryPtr;

UINTN EntryCount;

// Step 1: Find RSDP

for (UINTN i = 0; i < gST->NumberOfTableEntries; i++) {

if (CompareGuid(&ConfigTable[i].VendorGuid, &gEfiAcpi20TableGuid)) {

Rsdp = (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *)ConfigTable[i].VendorTable;

break;

}

if (Rsdp == NULL) {

Print(L"[Error] ACPI 2.0 RSDP not found\n");

return EFI_NOT_FOUND;

}

// Step 2: Get XSDT

Xsdt = (EFI_ACPI_DESCRIPTION_HEADER *)(UINTN)(Rsdp->XsdtAddress);

if (Xsdt->Signature != EFI_ACPI_6_3_EXTENDED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE) {

Print(L"[Error] XSDT Signature mismatch (found: %08X)\n", Xsdt->Signature);

return EFI_NOT_FOUND;

}

// Step 3: Traverse XSDT entries

EntryCount = (Xsdt->Length - sizeof(EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);

EntryPtr = (UINT64 *)(Xsdt + 1); // entries come right after the header

for (UINTN i = 0; i < EntryCount; i++) {

EFI_ACPI_DESCRIPTION_HEADER *Hdr = (EFI_ACPI_DESCRIPTION_HEADER *)(UINTN)EntryPtr[i];

if (Hdr->Signature == Signature) {

*OutTable = Hdr;

return EFI_SUCCESS;

}

return EFI_NOT_FOUND;

}

EFI_STATUS

EFIAPI

CalculateDigest (

IN UINT8 *Data,

IN UINTN DataSize,

OUT UINT8 *Digest,

IN UINT16 AlgId

)

{

BOOLEAN Status;

if (AlgId == TPM_ALG_SHA256) {

Status = Sha256HashAll (Data, DataSize, Digest);

} else {

// 支援其他演算法

return EFI_UNSUPPORTED;

}

if (!Status) {

return EFI_DEVICE_ERROR;

}

return EFI_SUCCESS;

}

2025-01-21T00:43:00.000-08:00

祝大家蛇年新年快樂

Penny 說我很久沒更新了，所以來更新一下~

Git Tag

2020-02-13T23:27:00.000-08:00

1.搜尋遠端上面的特定字串的Tag:

C:\> git ls-remote --tags origin "00.02.04"
7dd870355e439cfb8a818b6cd31f3c77f2ce40dc refs/tags/BiosRelease/project1/00.02.04
88138555a49907d6935fe55a8261e226668ba770 refs/tags/BiosRelease/MockingbirdCmlH/00.02.04
a98bce225711b983d729fcdb25542c6e8fdebac8 refs/tags/BiosRelease/project2/00.02.04
3cd9b00479436f67fef2e44955571218e80b6046 refs/tags/BiosRelease/project3/00.02.04
c1286cb71e39bf869ae0d70208479c3683dd0989 refs/tags/BiosRelease/project4/00.02.04

2.列出遠端上的全部Tag

C:\> git ls-remote --tags origin

2019-06-12T08:27:00.000-07:00

GIT 小幫手

1.如何知道某個CommitID是來自於哪個分支
git branch -a --contains 68b6100

<會繼續補充>

紀錄一下好用的Git Alias

2019-02-20T00:40:00.001-08:00

紀錄一下好用的Git Alias
C:\Users\<UserName>\.gitconfig

[alias]
lg1 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all

lg2 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all

lg = !"git lg1"

cc=!git clean -ffd && git submodule foreach --recursive git clean -fd && git reset --hard && git submodule foreach --recursive git reset --hard && git submodule update --init --recursive && git remote prune origin && git remote update --prune

ccall=!git clean -ffdx && git submodule foreach --recursive git clean -xfd && git reset --hard && git submodule foreach --recursive git reset --hard && git submodule update --init --recursive && git remote prune origin && git remote update --prune
st=!git status

pp=!git pull && git clean -ffd && git submodule foreach --recursive git clean -fd && git reset --hard && git submodule foreach --recursive git reset --hard && git submodule update --init --recursive && git remote prune origin && git remote update --prune

[git version 2.22.0 and above]

cc=!git clean -ffd && git submodule foreach --recursive 'git clean -fd' && git reset --hard && git submodule foreach --recursive 'git reset --hard' && git submodule update --init --recursive && git remote prune origin && git remote update --prune

ccall=!git clean -ffdx && git submodule foreach --recursive 'git clean -xfd' && git reset --hard && git submodule foreach --recursive 'git reset --hard' && git submodule update --init --recursive && git remote prune origin && git remote update --prune
st=!git status

pp=!git pull && git clean -ffd && git submodule foreach --recursive 'git clean -fd' && git reset --hard && git submodule foreach --recursive 'git reset --hard' && git submodule update --init --recursive && git remote prune origin && git remote update --prune

-----------------------------------
Git Pull常遇到的問題 : error: cannot lock ref ‘xxx’: ref xxx is at

git gc --prune=now
git update-ref -d refs/remotes/origin/ccc/xxx/yyy
git remote update --prune

---------------------------------
搜尋Tag

git tag -l '*Loki*'

UEFI Shell Utility - pwrtest.efi

2018-02-05T09:13:00.000-08:00

The pwrtest.efi is an UEFI Shell tool that help developer to confirm RTC wake function from a system(Support on both Intel and AMD platform).

最近在幫忙ODM看一個RTC Wake 問題，所以就順便寫了一個TOOL來驗證一些東西。原本遇到的問題也解決了，所以就順便把這個小TOOL分享一下給有需要的人使用。

Usage:
pwrtest -s3 -t 10 -w 60 ; 系統會在10 sec delay 後進入S3，然後在60 sec 後喚醒(Wake up)
pwrtest [-h|-s3|-s4|-s5|-s|-ss|-sx|-cb|-r]
-h help
-s3|-s4|-s5 ;選擇系統的Sx State (Intel platform)
-cb ;做coldboot ，我是透過 gRT->ResetSystem() 方式去做的
-ss ; 做Shutdown，我是透過 gRT->ResetSystem() 方式去做的
-sx value ; 支援AMD platform去做Sx State，因為填的SLP_TYP值不同.
value = 3/4/5 for AMD platform(S3/S4/S5)
value = 5/6/7 for Intel Platform (S3/S4/S5)
e.g,
pwrtest -sx 4 -t 5 -w 30 ; For AMD Platform, Put system to S4 after 5 sec, then wake after 30 sec.
pwrtest -sx 6 -t 5 -w 30 ; For INTEL Platform, Put system to S4 after 5 sec, then wake after 30 sec.
pwrtest -s3 -t 5 -w 30 ; For INTEL Platform, Put system to S3 after 5 sec, then wake after 30 sec.
pwrtest -r ; Warm boot
pwrtest -cb ; Cold boot

[註]
- S3 功能只能喚醒系統，喚醒後會當機，因為我沒有支援Reset Vector(Not support)
- 有些系統S4/S5 並不支援RTC wake up，所以請跟你們的BIOS/EC確認，因為這個工具只是去填RTC Enable bit & RTC Alarm interrupt而已。

Download (Password: harrison):

version 1.1 : pwrtest

紀錄一下WinDbg裡面比較常用到的指令集

2018-01-15T22:47:00.000-08:00

AMLI裡面比較常用到的指令集

AMLI(? for help)-> ?
?

Help - ? [<Cmd>]
Clear Breakpoints - bc <bp list> | *
Disable Breakpoints - bd <bp list> | *
Enable Breakpoints - be <bp list> | *
List Breakpoints - bl
Set Breakpoints - bp <MethodName> | <CodeAddr> ...
Clear Event Log - cl
Dump Event Log - dl
Dump Object Count Table - dc
Dump Heap - dh [<Addr>]
Dump Stack - ds [/v] [<Addr>]
Dump Name Space Object - dns [[/s] [<NameStr> | <Addr>]]
Dump Data Object - do <Addr>
Find NameSpace Object - find <NameSeg>
Continue Execution - g
Read Byte from Port - i <Port>
Read Word from Port - iw <Port>
Read DWord from Port - id <Port>
List All Contexts - lc
Display Nearest Method - ln [<MethodName> | <CodeAddr>]
Notify NameSpace Object - notify <Obj> <Value>
Write Byte to Port - o <Port> <Byte>
Write Word to Port - ow <Port> <Word>
Write DWord to Port - od <Port> <DWord>
Step Over AML Code - p
Quit to Kernel Debugger - q
Display Context Info. - r <Context>
Run Method - run <MethodName> | <CodeAddr> [<ArgList>]
Set Debugger Options - set [traceon | traceoff] [nesttraceon | nesttraceoff] [spewon | spewoff]
[dbgbrkon | dbgbrkoff] [lbrkon | lbrkoff] [errbrkon | errbrkoff]
[verboseon | verboseoff] [logon | logoff] [logmuton | logmutoff]
Trace Into AML Code - t
Interpreter Trace Mode - trace [trigon] [trigoff] [level=<n>]
[add=<TrigPtStr] [zap=<TrigPtList>]
Unassemble AML code - u [<MethodName> | <CodeAddr>]

AMLI(? for help)->

ACPI 裡面比較常用到的指令集
!acpicache displays all of the ACPI tables cached by the hardware application layer (HAL)

!acpiinf displays information on the configuration of the ACPI

!acpiirqarb displays the contents of the ACPI IRQ arbiter structure

!facs displays a Firmware ACPI Control Structure

!fadt displays a Fixed ACPI Description Table

!mapic displays an ACPI Multiple APIC Table

!nsobj displays an ACPI namespace object

!nstree displays a section of the ACPI namespace tree

!rsdt displays the ACPI Root System Description Table

!acpikd.help For a complete list of ACPI-related extensions.

Reference
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/acpi-debugging

如何透過DevCon.exe 去開跟關你的Device Manager內的設備

2018-01-10T07:38:00.003-08:00

如何透過DevCon.exe 去開跟關你的Device Manager內的設備

當你安裝WDK, Visual Studio 或是Windows SDK時，這些安裝檔裡面就會包含DevCon.exe。

我的DevCon.exe是在底下這個路徑內找到的:

C:\Program Files (x86)\Windows Kits\10\Tools\x64\DevCon.exe

當然，如果你想要自己Build source code的話，你也可以從底下的路徑找到這個source code:

https://github.com/Microsoft/Windows-driver-samples/tree/master/setup/devcon

我自己也用VS2013 成功建構出來這個執行檔，只是有個小地方要注意，就是你build code之前，要用command prompt(Build environment)先執行底下的指令，先把msg.h 建立出來，不然你沒辦法用專案檔案去compiler , 因為會出現會找不到msg.h的ERROR.

C:\DevCon > mc msg.mc 會產生msg.h

底下就是一些基本的指令操作:

1)先找你要開關的Device的HWID(我是存到一個文字檔慢慢找):

devcon hwids * > D:\hwids.txt

2) 使用底下指令去disable , 記得在HW ID前面加@

devcon /r disable "@ACPI\DELL0812\3&31FF937C&0"

3) 使用底下指令去enable, 記得在HW ID前面加@，然後HWID要用" "包起來.

devcon /r enable "@ACPI\DELL0812\3&31FF937C&0"

4) 使用底下指令去重新scan hardware

devcon rescan

5) 使用底下指令可以做重新開機動作

devcon reboot

至於其他跟寫driver時會用到的指令功能，大家就看底下微軟的詳細說明囉~

Reference
https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon-examples

ACPICA Programmer Reference Guide

2016-11-01T13:10:00.007-07:00

隨手記錄ㄧ下AE_NOT_FOUND 出現的ㄧ些原因.

AE_NOT_FOUND : The name was not found in the namespace
AE_NOT_FOUND : A valid RSDP could not be located.
AE_NOT_FOUND : There is no table with this Signature currently loaded, or the table of the specified Instance is not loaded.

AE_NOT_FOUND : The object referenced by the combination of the Object and Pathname was not found within the namespace.

AE_NOT_FOUND: The child object parameter is the last object of the given type within the parent — a next child object was not found. If Child is NULL, this exception means that the parent object has no children.

AE_NOT_FOUND: One or more of the segments of the pathname refers to a non-existent object.

AE_NOT_FOUND: A valid ACPI table was not found at the specified Address.

AE_NOT_FOUND: An ACPI table with Signature was not found.

範例:
ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.ECDV.ECIN] (Node 008E3F28), AE_NOT_FOUND (20160930/psparse-632)
ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.ECDV._REG] (Node 008E3F70), AE_NOT_FOUND (20160930/psparse-632)
ACPI Error: Method parse/execution failed [\_SB.PCI0._INI] (Node 008D5790), AE_NOT_FOUND (20160930/psparse-632)
ACPI Error: Method parse/execution failed [\ALSD._STA] (Node 008DD4C8), AE_NOT_FOUND (20160930/psparse-632)

不進步就是退步

2016-02-19T22:30:00.001-08:00

-- 以下並非以偏概全，純屬個人工作體驗 --

幾年前加入了一家日商公司，原本抱持著可以跟世界上製作第一台NB的公司裡的業界前輩學習更深入的BIOS知識，但發現事實是殘酷的，經過了多年後的改變，那邊慢慢的研發精神已經沒有那麼積極了，我不會說這家公司很糟，因為還是有很多日本/台灣/大陸/其他Region同事還是努力的在做事情，但是一家公司的文化卻讓肯做事情的人事情越做越多，不肯做事情/事情做不好的人越做越少，乃至於冗員就越來越多，聊八卦破壞團隊精神的人就多(做不好不會被裁員)。

而開發的方面，日商還是擁有許多比較封閉的開發方式，而「閉門造車」或許有其好處也有相對的壞處，而在一個世界潮流改變很快速的地方，如果不能一直學習成長，那就只能讓人超車。

因此，幾經嘗試改變周遭同事態度失敗和思考之後，我決定離開那些負面思考/消極態度的同事以及封閉的開發方式的環境，以避免個人養老心態的產生和負面心態的養成。所以在去年所以我選擇加入了另一家外商公司，開始學習不一樣領域的知識，並繼續讓自己保持正向的思考與競爭力。

然而，在這個新的工作領域中，我的工作內容暫時不需要自己去寫程式，雖然暫時放棄的寫程式的機會，但是我卻多了許多的機會去接觸不同的人事物，並讓自己反省過去到底浪費的多少生命在ㄧ些「不必要的人事物」上面。

然而「不進步就是退步」，在最近看到ㄧ些前日商台灣同事連被詢問留下機會都沒有，就被直接裁員，最近才在找工作，心中更是感概萬千。

雖然很想幫忙，但面對到友情/現實時，我們也只能選擇性幫忙。畢竟社會是現實的，冗員與戰力你只能選擇有戰力的幫忙，否則接納到冗員的公司也只能自求多福了。

所以，在世界競爭激烈的環境之下，唯有自己持續進步，在遇到這種公司關閉/退出市場或是裁員時，我們才能在裡面繼續生存下去。
2016.02 Harrison

Compiler intrinsics(內建函數)

2015-02-23T23:00:00.003-08:00

EDK2 中開/關VC++內建函數的方式

平常如果你使用Compiler /Oi 選項時，Compiler自己遇到內建函數時會自己去產生CODE到你的程式碼之中，如果你想要自己寫這些內建函數時，就必須要用/Oi- 去關閉他，以免被當成內建函數而出現Compiler error訊息。

例如，我想在我自己的xxx.c 中自己實作一個 ceil() 函數，那你可以透過EDK2 build option override方式在xxx.dsc 中來對你的xxx.inf 設定Compiler option，他只會影響你的xxx.inf。

$(MY_PATH)\xxx.inf {
<BuildOptions>
*_*_X64_CC_FLAGS = /Oi-
}

開啟CMD.EXE並一次執行多個DOS指令的方式(Command Prompt and Batch file)

2014-12-25T22:33:00.001-08:00

這篇文章是分享如何開啟CMD.EXE時並一次執行多個DOS指令的方式。

為什麼要分享這個冷知識?
因為現在是冬天了，所以很冷。

好吧，我承認這是個很無聊的一篇文章，大家就將就點看吧 :)

首先呢，我們都知道Command Prompt 是執行CMD.EXE後就會產生出來的一個畫面，那我們能不能寫個批次檔去執行CMD.EXE又可以執行很多筆指令呢? 答案是可以的，做法就是寫個批次檔，然後透過"雙引號"去把所有指令包起來，指令跟指令中間加入 && 就可以了：

CMD.EXE "指令1 && 指令2 && 指令3....&&指令n"

底下就是兩個批次檔的範例，批次檔內會去執行簡單的DOS指令，執行完畢後會出現一個Command Prompt停在那邊。

那大家可能會好奇我用在哪裡? 因為我使用SlickEdit 去編寫BIOS CODE，因為懶惰，所以想說我只要開啟 BUILD TIP底下任何一個檔案，然後按個鈕，我就可以進入到工作目錄並且設定好Visual Studio 的環境讓我可以直接Compiler code....就醬~

※ 上圖可以看到我在SlickEdit 內開啟了一個檔案，叫做NT32Pkg.dsc ，然後我設定了兩個快捷鈕，這兩個快捷鈕可以讓我選擇設定VS2012/VS2010的環境，按下去之後他會幫我呼叫設定環境的批次檔，環境設定好之後會直接幫我進入到NT32Pkg.dsc 目錄(E:\UDK2014.SP1\NT32Pkg)，然後我就可以很方便地在Command Prompt內做我要做的事情了。

底下是我在那兩個快捷鍵內的設定值，有分成CMD.EXE的設定方式跟BATCH的方式，差別就只是在於呼叫CMD.EXE去做事情還是自己寫個批次檔，然後呼叫那個批次檔而已。

CMD.EXE的方式:

cmd /E:ON /V:ON /k  ""C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\VsDevCmd.bat" && cd/d "%f\..""

BATCH FILE的方式(除了描述在快捷鈕之外，要多寫一個批次檔):

"C:\Apps\TEST.bat" %f

TEST.bat的內容:
@ECHO OFF
CALL "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\VsDevCmd.bat"
cd/d "%1\.."
CMD.EXE

上述中的%f 是SlickEdit內的參數，%f = 目前檔案的完整路徑。
以上面的範例來說:

%f = e:\UDK2014.SP1\Nt32Pkg\Nt32Pkg

最後，我承認科技使用來自於人的惰性，不然也不會有這個冷知識可以分享，哈~

Intel® UEFI Development Kit Debugger Tool (Intel UDK Debugger and OVMFPkg)

2014-12-23T22:36:00.003-08:00

這篇文章是紀錄我自己架設 QEMU + OVMF + Intel UDK + WinDbg 環境的筆記。

QEMU : 他是一個Open Source的處理器仿真器與模擬器。
http://wiki.qemu.org/Main_Page

OVMF : 他是一個UEFI EDK2 codebase裡面的一個專案，用來讓UEFI BIOS可以跑在虛擬機器(Virtual Machine)上面，在這裡的範例就是跑在QEMU裡面。
http://tianocore.github.io/ovmf/

Intel UDK Debugger : 這是INTEL開發的一個Source Level Debugger，他需要配合WinDbg(微軟提供的)才能做除錯的動作。

Intel Uefi Development Kit Debugger Tool

下面這張圖是我實際的架設環境，我在Windows 8.1裡面安裝了Intel UDK跟WinDbg然後透過虛擬的COM Port來與 QEMU裡面的BIOS.BIN(OVMF.FD)溝通。

安裝與設定(Install and Setup)

STEP1 : Download UDK2014.SP1 ，OvmfPkg and OptionRomPkg

我是把它們一起放在E:\UDK2014.SP1; 然後先準備好Compiler環境，並產生OVMF.FD. (環境的部分請參考UDK2014與OVMF的說明)。

確定Compiler 環境沒問題後，跟隨下面步驟來產生UEFI BIOS ROM。

1).先產生 OVMF.FD

a. E:\UDK2014.SP1>edksetup.bat

b. E:\UDK2014.SP1>build -DDEBUG_ON_SERIAL_PORT=TRUE -DSOURCE_DEBUG_ENABLE

2). 在把OVMF.FD複製一份，並修改檔案名稱為bios.bin (rename)

(我是放在 E:\UDK2014.SP1\Build\Ovmf3264\DEBUG_VS2012x86\FV\bios.bin)

a.E:\UDK2014.SP1> cd E:\UDK2014.SP1\Build\Ovmf3264\DEBUG_VS2012x86\FV
b.E:\UDK2014.SP1\Build\Ovmf3264\DEBUG_VS2012x86\FV> copy OVMF.FD bios.bin

STEP2: 安裝(Install) WinDbg

STEP3: 安裝Virtual Serial Port，你可以選擇Com0Com或是VSPD(Virtual Serial Port Driver)，因為Com0Com 是免費(Free)，另一個要破解(VSPD v7.2)，所以我這邊就只介紹Com0Com 就好，破解版的我就自己知道就好這邊就不介紹了。

1) 先執行一個Cmd.exe with Admin (管理者權限)

bcdedit -set TESTSIGNING ON

2)重新開機 (Reboot)

3) 安裝Com0Com 2.2.2.0 (For Windows 8.1/Win7 x64 bit)

com0com-2.2.2.0-x64-fre-signed.zip

4) 執行 "C:\Program Files (x86)\com0com\setupc.exe"，並在畫面中輸入下面指令:

Command > Install PortName=COM6 PortName=COM7

5) 確認設備管理員(Device Manager)內有成功安裝driver，並且No yellow bang.

STEP4: 安裝(Install) Intel UDK v1.4

※如果你是Windows 8.1 ，請設定相容性=Windows 7 (Compatibility mode=Windows 7)

1) 安裝過程中會指定WinDbg安裝目錄跟COM port Number，你也可以安裝完畢後，再去修改他的設定檔案(Config File):

"C:\Program Files (x86)\Intel\Intel(R) UEFI Development Kit Debugger Tool\SoftDebugger.ini"

底下是我實作時候的設定:

COM6 = Intel UDK

COM7 = QEMU

2) 安裝後，修改SoftDebugger.ini 加入以及修改底下的描述(RED COLOR)

"C:\Program Files (x86)\Intel\Intel(R) UEFI Development Kit Debugger Tool\SoftDebugger.ini"

[Debug]

Debug=1

[Debug Port]

Channel = Serial

Port = COM6

FlowControl = 0

BaudRate = 115200

Server =

STEP5: 執行Intel UDK Debugger，他會叫出WinDbg

STEP6: 執行QEMU 並且載入UEFI BIOS (Load BIOS.bin)

E:\UDK2014.SP1\Build\Ovmf3264\DEBUG_VS2012x86\FV>"C:\Program Files\qemu\qemu-system-x86_64.exe" -L . -serial COM7

如果有不清楚的部分，可以參考INTEL相關資料。

VC++ 可轉散發套件(Redistributable Package)

2014-12-19T00:59:00.003-08:00

這篇文章只是要告訴大家可轉散發套件(VC++ Redistributable Package) 是幹甚麼的?

1)首先呢，我先在我的Win7 64 bit OS底下安裝VS2008 ，安裝時順便選擇我要裝x64 compiler，這樣子我的開發環境就會有VS2008 32 bit/64 bit compiler 功能!

2) 接著，我建立一個新的VC++空專案(VC++-->General-->Empty Project)，裡面加入我自己的C 語言Source code (Tmake.c 跟Tmake.h)，然後再專案屬性的地方先設定Win32 (Right click Project -->Properties ，在Platform 的地方選"Win32")

3) 先產生一次32 bit的應用程式，他會產生再輸出目錄『Debug\Tmake.exe』

4) 接著，修改專案屬性，改選擇x64 ((Right click Project -->Properties ，在Platform 的地方選"x64")，如果你沒看到x64可以選擇，就是在安裝VisualStudio時沒選擇x64 compiler選項。

5) 然後再產生一次 64 bit的應用程式，他會產生在輸出目錄『x64\Debug\Tmake.exe』

完成了步驟5之後，我就會有兩個執行檔，分別是32 bit版本跟64 bit版本。

底下是我的開發環境 (產生執行檔，但是拿到別台去執行)

OS: Windows 7 64 bit

Visual Studio 2008

底下是我的執行環境 (這台機器上面執行我自己寫的程式)

OS : Windows 8.1 64 bit

Visual Studio 2012/2013

[圖1] 32 bit/64 bit 的主要差別除了暫存器之外就是在於 Calling Convention (呼叫慣例)

所以大家可以看到，我在Win7開發拿到另一台Win8.1 上面執行，而在Win8.1中我只安裝了Visual Studio 2012/2013這兩個版本，但是我的Win7開發時是Visual Studio 2008開發的。

所以，當我在Win8.1底下不管是執行32 bit 版本的Tmake.exe 或是 64 bit 版本的Tmake.exe 我都得到了相同的錯誤訊息。

ERROR MESSAGE: 因為應用程式檔設定不正確,所以無法啟動

[圖 2] 無論32/64 bit 都得到相同的錯誤訊息

假如你看到類似這種錯誤訊息時，只要去安裝可轉發套件，把需要的檔案補足在你的電腦中理論上問題就會消失了，但是 "你要找的到正確的版本的可轉發套件" (後面會講找不到時的解決方式)。

底下版本是VS2008 version v9.0.30729

Microsoft Visual C++ 2008 SP1 可轉散發套件 (x86)

Microsoft Visual C++ 2008 SP1 可轉散發套件 (x64)

底下版本是VS2008 v9.0.30729.6161 (比上面的還新一點)

Microsoft Visual C++ 2008 Service Pack 1 Redistributable Package MFC Security Update

另外，你可以在安裝完畢後，從System Event Log看到你到底安裝了甚麼版本:

Windows Installer 已安裝該產品。產品名稱: Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.6161。產品版本: 9.0.30729.6161。產品語言: 1033。製造商: Microsoft Corporation。安裝成功或錯誤狀態: 0

如果，你安裝完畢後還不能執行的話，那就是版本不同!

如果你從System Event Log 查看，也會看到類似下面的錯誤訊息:

"D:\TmakeJpg\Debug\Tmake.exe" 的啟用內容產生失敗。找不到依存組合 Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"。

意思是說你執行Tmake.exe的電腦內的所能提供的執行環境跟這個應用程式內所要求的版本不同; 從上面的範例可以知道我安裝的都是v9.0.30729.xxxx 但是這個應用程式需要的是9.0.21022.8，這個時候，你有幾個解決方式。

方式1: 從開發的機器上把需要的檔案複製到執行的機器上的Windows\System32 底下
需要的檔案需要配合你的應用程式的類型來複製對應的檔案，例如:

Release Build 64 bit(x64):
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\Amd64\Microsoft.VC90.CRT
Release Build 32 bit(Win32):
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT

msvcm90.dll
msvcp90.dll
msvcr90.dll
Microsoft.VC90.CRT.manifest

Debug Build 64 bit(x64):
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\amd64\Microsoft.VC90.DebugCRT

Debug Build 32 bit(Win32):
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC90.DebugCRT

msvcm90d.dll
msvcp90d.dll
msvcr90d.dll
Microsoft.VC90.DebugCRT.manifest

方式2 : 把前面這些需要的檔案打包變成xxx.exe 再一起拿去執行的電腦安裝與執行.

請參考: http://msdn.microsoft.com/en-us/library/ms235291(v=vs.80).aspx
http://msdn.microsoft.com/en-us/library/aa260978%28VS.60%29.aspx

方式3: 在專案屬性中選擇使用靜態MFC Library. (Win32/X64都要設定一次) 再重新編譯執行檔就可以了。

結論 :

VC++的轉散發套件就是給『跟你開發環境不同』的人去補足需要的Library/DLL之後，才能順利執行你所開發的應用程式。

所以，程式開發者可以選擇『自己打包好所需要的檔案』後再提供給使用者免去使用者無法執行的窘境，或是使用者自己無法執行應用程式時去安裝對應的『轉散發套件』。

[註] 我的測試程式後來採用方式3解決問題! 系統就算不安裝VC++的轉散發套件也沒問題。

WMI ACPI

2014-10-23T21:20:00.001-07:00

今天要整理的筆記是WMI ACPI

在BIOS工程師中，對於WMI ACPI應該大家都有玩過，因為許多的OEM都是開發一些OS端的應用程式，然後再透過WMI 這種方式去跟BIOS的ACPI ASL CODE做溝通，以達到可以讀取Thermal 資訊/EC 資訊/ BIOS Setup Utility 資訊....etc.

在網路上或是微軟的相關文件中，你可以看到主要的架構在於wmiacpi.sys 跟acpi.sys 之間的溝通，對於BIOS工程師來說，如果要去提供這種介面就不得不參考微軟的wmi acpi白皮書上面介紹的內容了，底下是微軟文件的說明:

http://msdn.microsoft.com/en-us/library/windows/hardware/dn614028(v=vs.85).aspx

這份文件中主要的概念有幾個:

1. 他跟你說有一個MOF(Managed Object Format) 是用來給 WMI Core使用的，所以他有個資料庫管理這些MOF檔案；當上層的APP跟WMI Core溝通時，他要去這個資料庫撈對應的MOF資訊，從MOF資訊中取得一些資訊後，才知道怎麼跟你的ACPI溝通!

2.溝通的那個ACPI Device有一個特別的PNPID，也就是PNP0C14 ! 所以BIOS工程師要宣告一個ACPI Device然後底下定義_HID , "PNP0C14" 這樣子才能夠溝通~

3.Wmi Core 溝通的方式就請自行看這篇文章，像是如何透過GUID找到ACPI _WDG內比對GUID然後找到兩個字元後，再去看Flag屬性是否是Method，然後去執行相關的ACPI Method...之類的資訊，因為這些資訊已經在網路上很多，大家也應該熟悉了，這邊就不多描述。底下是對_WDG對應時的C語言格式:

typedef struct
{
     GUID guid;             // GUID that names data block
     union
     {
         CHAR ObjectId[2];  // 2-character ACPI ID  (Data Blocks and Methods)
         struct 
         {
             UCHAR NotificationValue;  // Byte value passed by event handler control method
             UCHAR Reserved[1];
         } NotifyId;
    }
     USHORT InstanceCount;  // Number of separate instances of data block
     USHORT Flags;          // Flags
};

上面的C結構會對應倒ASL的_WDG 內的定義:

   Name(_WDG, Buffer() {
        0x6a, 0x0f, 0xBC,....//GUID
        66, 65,              // Object ID (BA) (兩個字元"BA"，可能會組成WQBA或是WMBA，看Flag)
        3,                   // Instance Count (有幾筆Data items)
        0x01,                // Flags (決定他是不是Method...之類的屬性來決定WQXX/WMXX...etc)
        
    })

那大家可能會問說，你不說運作原理那你要說甚麼?

一般BIOS工程師在Debug時一般就是利用這些運作原理去追ACPI 來找出問題點，一般大家會比較忽略說，那上層的MOF是怎麼加進去資料庫的? 所以這邊會對這部分做一個簡單的說明。在說明之前，我們先看看下面這張圖:

Vbscript : 代表的就是上層APP可以透過像是VBScript/C#....etc之類的去開發你的APP。
Wmi Core : 會去撈MOF 資訊跟Acpi.sys溝通(透過WmiAcpi.sys) 。
ACPI ASL : 你要宣告PNP0C14 ，然後有個Name Object 叫做 _WDG (上面圖畫錯了，懶得改了)。
BIOS Function: 然後透過ACPI ASL的相關Method來實做一些BIOS CODE，像是發個SMI去取得一些資訊，再透過WMI_ACPI ASL往回傳給上層APP...etc.。

Installation wmi acpi方式有兩種:

方式1: MOF包在DLL，並註冊到Registry
1. 增加上述說的那些ASL CODE到你的BIOS

2. 建立一個MOF.DLL (類似OS動態連結檔，不過裡面沒有任何OBJ只有MOF資料)
a. 建立wmiacpi.rc 跟wmiacpi.def 檔案

b. 透過VS2010/2012/2013 的link.exe 將他變成wmiacpi.dll 裡面沒有obj，只有 MOF資料

wmiacpi.rc 內容:

#include <windows.h>
#include <ntverp.h>

#define VER_FILETYPE VFT_DLL
#define VER_FILESUBTYPE VFT_UNKNOWN
#define VER_FILEDESCRIPTION_STR "Resource only DLL containing MOF for ASL code"
#define VER_INTERNALNAME_STR "wmimof"
#define VER_ORIGINALFILENAME_STR "wmimof.DLL"

#include "common.ver"

//
// WMIACPI.SYS requires that the mof resource be named MofResource

MofResource MOFDATA wmiacpi.bmf

wmiacpi.def 的內容就只有一行:

LIBRARY wmiacpi.dll

c. link command :

rc /fo"%OUTDIR%\wmiacpi.res" wmiacpi.rc

link /OUT:"%OUTDIR%\wmiacpi.dll" /NOLOGO /DLL "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib"

"ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEF:"wmiacpi.def" %OUTDIR%\wmiacpi.res /MANIFEST /ManifestFile:"%OUTDIR%

\wmiacpi.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /PDB:"%OUTDIR%\wmiacpi.pdb" /TLBID:1 /NOENTRY /DYNAMICBASE

/NXCOMPAT /MACHINE:X86 /ERRORREPORT:QUEUE

3. 複製MOF.DLL檔案到%windir%\system32 (也就是C:\Windows\System32)

4. 在Registry 的HKEY_LOCAL_MACHINE\CurrentControlSet\Services\WmiAcpi底下新增MofImagePath，然後裡面的值指向 "C:\Windows\System32\MOF.DLL"

5. 重新開機，然後OS偵測到PNP0C14之後就會自動安裝WmiAcpi.sys 然後會去Registry 找到你包在MOF.DLL內的資料，之後用你的APP來透過WMI Core去存取你的ACPI ASL.

※ 這邊說的MOF.DLL就是你透過link.exe 建立出來的檔案，請自行變更你的名稱

方式2: MOF包在ACPI ASL，等發送特定IRP時回給Wmi Core.

1. 增加上述說的那些ASL CODE到你的BIOS

2. 建立一個MOF.BMF (MOF的Binary格式，副檔名隨便給因為你可以在Compiler時指定副檔名)

3. 透過 wmimofck.exe 產生.x 檔案，在把他的內容包到ACPI ASL之中.

a. 首先先在_WDG內定義一個專屬MOF的GUID(切記不能改變GUID值)

Name(_WDG, Buffer() {
.
// This GUID for returning the MOF data
0x21, 0x12, 0x90, 0x05, 0x66, 0xd5, 0xd1, 0x11, 0xb2, 0xf0, 0x00, 0xa0, 0xc9, 0x06, 0x29, 0x10, //
66, 65, // Object ID (BA) 這兩個字元可以自己改，但是要對應到WQXX.
1, // Instance Count
0x00, // Flags
})

b.將Wmiacpi.x 內容複製貼上到Name Object "WQBA"

Name(WQBA), Buffer(){"MOF Binary data from Wmiacpi.x"}

4. 重新開機，然後OS偵測到PNP0C14之後就會自動安裝WmiAcpi.sys 然後會發送特定的IRP，然後ACPI那邊會回給WMI CORE MOF的資訊~

在這兩中方式中，都需要把wmiacpi.mof 檔案先經過一個工具叫做mofcomp.exe compiler
而這個wmiacpi.mof 檔案的內容就是你在微軟文件那邊看到的，例如:

class WMIEvent : __ExtrinsicEvent
{
};

[WMI,
Locale("MS\\0x409"),
Description("This class contains the definition of the package used in other classes"),
guid("{ABBC0F60-8EA1-11d1-00A0-C90629100000}")
]
class Package
{
[WmiDataId(1),
read, write,
Description("16 bytes of data")
] uint8 Bytes[16];

};
...

然後經過mofcomp.exe compiler之後，會產生一個MOF binary 檔案，我把他叫做wmiacpi.bmf。

而這個wmiacpi.bmf 可以經過另一個工具wmimofck.exe 來產生c file / c header file ，如果你想自己寫一個Wmi driver時，可以透過這種方式把來幫助你產生一些需要的程式碼，也可以透過wmimofck.exe來產生VBScript 的Sample code(自動產生)，所以當然也可以透過wmimofck.exe來產生一堆HEX 文字檔來方便你把MOF binary資料包進去ACPI ASL之中。

底下是我的批次檔，用來測試用的，分享給大家參考~

※ 這邊使用到的資訊都是來自於微軟的相關文件，有興趣請自行查詢!

需要用到的工具:
Windows WDK內的wmimofchk.exe (我是安裝WDK for win7 ,目前最新版是WDK 8.1)

Reference

http://msdn.microsoft.com/en-us/library/windows/hardware/dn614028(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542012(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff554794(v=vs.85).aspx

EDK2/EDKII Python Build Tool 兩三事 (Build.py)

2014-09-16T03:01:00.002-07:00

EDK2 Python Build Tool 兩三事

最近因為工作需要，所以不得已逼自己去把EDK2 Python Build source code看完，看完後順便整理一下一些小重點，以免過陣子自己又忘記了。

1)EDK_GLOBAL

這種定義的Macro只能給EDK1 driver使用，因為他會去檢查.inf 內的

INF_VERSION = 0x00010005 ，如果大於或是等於這個值就是當成EDK2，如果找不到這個值就會當成是EDK1。

因為不好用，所以就隨手改了一下CODE，讓他通吃EDK1 + EDK2 + FDF + DSC + DEC + INF

2) Build Rule and Package rule

在EDK2 中，他把EDK1原本的Build Rule & Package Rule 分別描述成:

Tools_def.txt

Build_Rule.txt

[Rule.$(Arch).$(ModuleType]

好不好用看個人，不過如果你要支援原本EDK1 Package Rule時那就對不起啦，你要修改Python source code，不然你做不到。例如說底下的EDK1 的COMPONENT_TYPE = FILE原本對應到某個Package Rule，但是在EDK2內不支援就是不支援，除非自己改python source code.

[Defines]
BASE_NAME = xxxxx
FILE_GUID = 126A4D6A-C404-4200-8779-F327A4A79087
COMPONENT_TYPE = FILE
BUILD_TYPE = MAKEFILE

3) Python v.s SQL

Python build tool 只是拿SQL當成是存放他收集到的資料的一個地方，然後在另一個地方就可以去撈資料庫內的資訊然後寫對應的CODE去分析要幹嘛，所以rebuild的時候最好把這個資料庫暫存檔案刪除。 EX: Conf\.cache\build.db

4) GenSection & GenFFS

以前EDK1的這兩個工具也整合進去Python Build tool內了，所以想了解FDF是怎麼產生FV或是FD的人就請自行研究，不過他是另一隻Tool叫做GenFds.py。

5) AutoGen.c v.s AutoGen.h

偷偷產生的檔案用來存放一些PCD操作/有用到的PCD Value，GUID 定義跟一些偷塞的include... 如果是給PCD database使用的，他還會塞Dynamic PCD給PCD 資料庫當成初始化值。

另外，Library 只會產生AutoGen.h 不會產生AutoGen.c，因為Library通常會跟某個Driver Link，所以等到真正要去產生Module make時，才會去檢查Library 內用到的GUID/PCD ，然後產生在Module's AutoGen.c內。

6) Hard code

恩，很多東西都寫死在Python build tool內，像是nmake command 要增加修改時就要改一改他，不過也是個好處，就是我可以偷加很多東西在裡面，然後不給你source code...哈!!!

7) 產生執行檔

.py 轉成 .exe 方式我自己再用的有兩種，一種是py2Exe不過版本過舊已經不能支援了，所以我採用EDK2 所建議的cx_Freeze 去轉換，轉換時還要搭配你的Python 版本，目前我看到的codebase內使用的是Python 2.7.3，所以應該以這個為主吧! 底下是EDK2 建議的方式:

Using cx_Freeze 4.2.3 with Python 2.7.2

Using cx_Freeze 3.0.3 with Python 2.5.4

8) 嗯...有想到再說~

Python v.s UEFI EDK2 (EDKII)

2014-02-12T20:13:00.001-08:00

這篇文章主要是幫自己紀錄一下學習EDK2 build process時的前置準備動作有哪些，後面會陸陸續續把這篇文章補齊，所以先留下個紀錄吧~

學習方式

對於EDK2來說最大的轉變就是我一直提到的Build process，我常跟我周遭朋友說如果你要學好BIOS或是其他大型軟體專案，中間的『眉角』就是要把大型專案的學習方式分成：

BUILD + CODE

當你有辦法分辨以及分開學習時，你才可以精準的掌握住甚麼是BUILD? 甚麼是CODE?
舉例來說，BUILD的部分就是屬於build rule/compiler rule/package rule ，簡單的說就是透過一些方式來把程式碼產生成binary，依照一些特定的layout來產生成一個BIOS ROM image；至於CODE的部分就屬於程式語言，像是C語言，組合語言的學習! 你唯有了解彼此之間的關係，你才能掌握關鍵處! 這也是我常跟朋友開玩笑說，你真的會"build+code"嗎?!

至於BUILD PROCESS的概念中，我也常常教導朋友去思考為什麼要這樣子做? 他解決了甚麼問題? 有沒有其他方式? 因此我常常由一個批次檔的概念外加一些淺而易懂的範例來讓他們知道說原來BUILD PROCESS原理是如此簡單，不過我沒打算在這邊寫詳細的解說，因為配合著畫圖邊解釋效果比較佳，如果大家有興趣又剛好在業界遇到我時再來跟我討論吧! ^^

所以記得，學習的方式就是BUILD + CODE分開來學!!!

前置動作
有鑑於EDK2 BUILD PROCESS主要的部分已經改成Python 2.5/2.7開發，美其名是為了跨平台而準備，但是實際上卻沒有達成! 畢竟，EDK2在x86中並沒有拿Python 將所有win32 的工具重新寫一次，導致在x86平台中有一部分的python tool跟一部份的win32 tool，所以只能說『某些BUILD TOOLS』跨平台而已! 但是木已成舟，所以現在的x86上就變成了這個怪胎情況了!

雖然我不討厭Python，但也不是擁護者，因為跨平台方式有很多種，他也不是最好的一種! 但是因為EDK2都選擇了Python，所以我也要強迫自己來學習他，秉持著工欲善其事，必先利其器的方式，我們先把除錯工具安裝好，以方便我們去分析與研究EDK2's Build.py

那有哪些東西要先安裝呢? 我個人偏好Visual Studio，因此我選擇了VS2010+PTVS 來當作是Debugger，安裝簡單! 當然你也可以選擇使用Eclipse Classic IDE + PyDev 的除錯方式 (感謝鳥公司John大大傾囊教學)!

所以如果你也想學Python，請跟著我一起安裝:

1. VS2010

2. Python tool for Visual Studio
https://pytools.codeplex.com/

3. Python 2.7.6 (目前EDK2還沒支援到Python 3.x，建議是安裝2.5.x/2.7.x)
http://www.python.org/download/releases/2.7.6/

Eclipse Classic IDE+PyDev

VS2010+PTVS

(未完待續...)

文字檔格式真多，那怎麼去區別ASCII/Big5/UTF-16/UTF-8呢?

2014-01-21T23:37:00.000-08:00

以前處理一些字幕檔的時候，慢慢的累積了一些區別文字檔編碼的經驗，這邊就分享一下個人經驗，不過經驗歸經驗不一定正確，所以各位就將就點看，把他當成是解決你問題的一個進入點，然後再去搜尋相關知識來解決各位遇到的問題吧!

首先，我們先討論一下文字檔到底是啥? 其實不管是甚麼檔案，儲存的時候都是BINARY資料，差別就在於讀取檔案的人想要如何呈現給你看而已~

例如:

執行檔=二進制資料 , OS 讀取表頭判定他可以被執行，然後執行他!
文字檔=二進制資料 , Editor 讀取他然後依照一些編碼原則判定他，然後再去字型檔撈出字型顯示給你看!

所以啦，這篇文章要說的就是模擬一下如果我寫了一個Editor，我要怎麼區別不同的編碼格式!

從上面的圖中可以看到，一開始的時候我會先去讀取兩個位元組，這是因為Unicode(UTF-16)檔案會有一個標記來標記他是Unicode存取方式是Big Endian還是Little Endian (低位元組在記憶體低位址, x86常用) ，所以大家可以把UEFI 中的.uni 用16進制編輯器打開來看看，就會看到檔案最開頭有這個標記可以用來判斷~

如果沒有這個標記的檔案，我們就可以判斷為他可能是ASCII/UTF-8/Big-5的編碼方式，因為Big5是兩個位元組組成，他有他一定的規範，所以可以由這些規範來判別字元是不是Big5或只是單純ASCII的一個位元組而已~

除此之外，還有一個UTF-8比較討厭，因為UTF-16是固定兩個位元組儲存一個字元，所以像是英文"A"就會是0x0041 ，高位元組永遠是0x00，所以為了節省空間所以變成了可變位元組的編碼，因此一個字元可能由1~6 bytes組成，看樣子還有機會繼續延伸咧~

因此可以參考Wiki上的UTF-8的對應方式去判讀一個字元由幾個Bytes組成。

例如: 中文字 [這]

這=E9 80 99 (UTF-8)

第一個位元組的二進制是1110 1001前面的'1'代表全部是3 bytes，而後面的每個位元組的bit7:6就是對應Wiki上說的欄位表示 10xx xxxx, 10xx,xxxx

所以取出來的xxxx xxxxxx xxxxxx

| | |____ 011001 19

| |____________ 000000 0

|_________________ 1001 9

U+9019 就是unicode的中文字 [這]，所以UTF-8 也算是再重新編碼後的一種unicode表示碼!

不知道舉的這些例子看倌們能否了解?!

因為這不是我的專長，我是寫BIOS的，以上是經驗談~ Orz

UEFI Gop driver and PlatformGopPolicy

2014-01-07T01:38:00.002-08:00

最近在除錯我自己從無到有DIY出來的EDKI codebase的問題，所以在這邊留一下筆記來記錄一下UEFI Gop driver遇到的問題~

問題描述:
由於我們的系統比較特別，有eDP Panel 跟LVDS Panel(銷庫存)，所以外掛了一顆eDP-LVDS IC，導致點亮VGA的方式變得複雜了點，另外我的CODEBASE目前還很陽春，所以只支援UEFI mode，也就是我要直接上UEFI GopDriver，而執行到UEFI Gop Driver後系統就當機了，為了這個問題所以把這隻Gop driver 反組譯，然後大致追了一下，然後把追CODE的筆記紀錄在下面!

筆記:
1) 他是一個EFI driver model driver，所以從DriverBinding Start()追進去看他做了甚麼事情
2) 底下是我整理的資料，因為沒有他的Source code，完全靠反組譯去猜測出底下的順序與動作，所以僅供參考，並不一定正確!
3)Root cause: 還不清楚，還在追...哈!

DriverBinding->Start()

{

1..asm{RDTSC};

2.ProgramIGD();

a. OpenProtocol(Pciio) //準備用來讀取PCI Regs

b. Pciio->Attributes(Enable BusMatser,MMIO,IOBASE) //啟動IGD設備

c. OpenProtocol(DevicePath)

d.LocateProtocol (PlatformGopPolicy) //要求Platform firmware(也就是BIOS)提供VBT/Lid/Dock 的資訊

e. PlatformGopPolicy->GetVbt(Address,Size);

f. Config/Read IGD PCI Regs (DeviceId,RevisionId...etc)

g.Read Pch DeviceId and RevisionId.

h.Init MMIO regs // 目前還找不到相關文件說明這些暫存器在幹嘛

i.Out 0x3c2,0x67

j.Config MMIO regs

k. PlatformGopPolicy->PlatformLidStatus()

l. PlatformGopPolicy->PlatformDockStatus() if PlatformGopPolicy's revision > 0x0001 otherwise, ignore it.

m.Create DDEV LinkedList (Display Device) //應該是參考Vbt去建立出來的資訊 CRT->eDP->EFP1->EFP2->EFP3

n.Walk DDEV LinkedList to find out predefined DDEV and then try to enable it. (Hangup here.) //我當機在這裡

o.Others //還沒追...應該是去產生一些protocol (EDID,brightness...etc) 或是devicepath

3.asm{RDTSC};

}

4)會被產生出來的Protocol掛自Child Handle上:

a.DevicePath (09576E91-6D3F-11D2-8E39-00A0C969723B)
b.Undocument protocol (39487C79-236D-4666-87E5-09547CAAE1BC) : 不知道是幹嘛的...
c.EdidDiscovered (1C0C34F6-D380-41FA-A049-8AD06C1A66AA): 用來表示於顯示設備使用這個EDID.
d.GraphicOutput(9042A9DE-23DC-4A38-96FB-7ADED080516A):用來顯示影像
e.EdidActiveProtocol(BD8C1056-9F36-44EC-92A8-A6337F817986) : 正在顯示的設備使用這個EDID

如果SizeOfEdid !=0 代表EDID資料應該是有效的，應該可以檢查此Handle上面有沒有EDID Protocol來得到顯示設備的EDID，就像是Legacy 時呼叫INT 10h.

簡略介紹 EDKI與EDKII (EDK2) 的差別

2013-09-13T00:14:00.003-07:00

這篇文章主要是簡單闡述一下EDKI 與 EDKII 在BIOS工程師眼中的差別在哪裡? !
在討論之前，我們先簡單說一下Package是甚麼東西?

Package是甚麼?

在EDKI裡面，我們在寫UEFI driver的時候並不會有所謂的 "Module" 的概念在裡面。我們開發的時候都是以 driver為單位，並不會考慮一些模組化的問題。

[註] UEFI 的可執行檔案我們的術語是Image或是Driver，所以當你聽到這個術語時把他當成類似EXE執行檔就可以了。

而 EDKII裡面，他加上了 Package這個概念(模組化)。其實可以把它看成是一個目錄，而這個目錄名稱會是"xxxPkg"，而目錄裡面就是一堆相關的UEFI driver。

所謂的相關的UEFI Driver是說，假如你看到目錄名稱是"NetworkPkg"，那麼這個Package裡面的東西就跟Network有關，所以在這個目錄內可以有其他子目錄去存放著 PEI/DXE/SMM/APP 的 Driver或是 Library。

而組成一個 Package的元素(一個PKG目錄內)必定包含一個 *.dec 和 *.dsc

Package的好處是甚麼? 就是"獨立"

在EDKI 的時候，你想單獨產生一個特定的CODE時，你至少"整套CODE"要先產生一次! 而EDKII使用這種"獨立"的概念就不需要整套CODE build完才產生你要的CODE!

但也是因為獨立，所以有很多地方都是為了解決獨立出來問題而去改了一堆Build tool動作跟你描述.dsc還有.FDF的動作。

EDKI與EDKII主要的差別?

- Build process的改變

EDKI : 由ProcessDsc.exe執行將 *.inf 轉換成 makefile 的動作

EDKII: 由Build.py 去處理，同時還會產生 AutoGen.c & AutoGen.h (Parsing *.dec )

- DSC file / FDF file

在EDKI裡，決定一個 driver要放在那一個 firmware volume裡是在"1個.dsc"就可以決定的，通常都會是叫做PlatformDsc.dsc或是 Build.dsc這個檔案!

在檔案內你會透過FV=FVREVOVERY的方式把底下的UEFI Driver通通放進去FVREVOVERY.FV，接著透過Flashmap.fdf去規劃ROM的區域，然後決定 FVMAIN.FV放進去哪個區域。

但是 EDKII為了實現 Package這個概念，所以.dsc不再用來描述UEFI driver要放到哪個FV，而只是拿來決定要不要BUILD這目錄下的UEFI driver而已!

描述那些UEFI DRIVER放到ROM的哪個位置的動作就變成EDKII新的FDF SPEC所描述的那些動作，所以你必須要新的FDF 格式中描述你那些UEFI driver是要放進去ROM裡面的。

- PCD/DEC

因為EDKII還希望做到不用改到Source code就能夠改變CODE的行為，所以延伸出了PCD這種控制方式，不過我是覺得它需要額外寫TOOL去達到他的理念而增加了許多BIOS工程師的麻煩。

PCD我自己是分成兩部分學習，一部分是屬於如何在RUNTIME管理PCD Database的部分，另一部分就是如何透過DEC FILE去產生PCD的預設值以及有哪些PCD LIB與Header file可以存取他，因為這部分牽扯到實作面(靠的是C語言巨集)，所以需要邊開著CODE邊解釋，所以很難使用文章解釋，希望大家有機會在業界遇到我時在幫大家解釋吧^^.

你暫時可以簡單把他想像成是一個變數宣告的方式，變數會有生命週期(整個RUNTIME或是某一個DRIVER而已)與屬性(唯讀/可讀寫)，可以方便你在CODE裡面存取他!

以上的部分大致上就是EDKI 與EDKII的差別，對於BIOS工程師來說可能會需要去習慣新的DSC/INF/DEC/FDF寫法，以及BUILD.py這個工具的用法，其他的就是要去習慣各家IBV對於PCD的作法!

EDKI與EDKII Reference Code的差別?

EDKI 與 EDKII Reference code的部分，以目前我接觸到的部分來說最大的差別在於"移植的觀念"。

EDKI 身不好移植到不同平台，所以EDKII在這部分是希望能夠好移植，而他的使用的方式是約束大家使用同一個EntryPoint，也就是說在EDKII RC code部分，如果大家的EntryPoint都能指向同一個地方做完一些跟Platform相關的事情之後再跳回去Driver EntryPont，那麼下次如果要移植到不同平台時，我只要把這個共通的EntryPoint改寫就好了。

所以在 RC CODE部分，你會看到他先透過共同的_ModuleEntryPoint，然後再從C_FLAG設定的給EDKII Gule Library的EntryPoint 跳回去你設定的Driver EntryPoint，這就是他主要的改變!

因為EDKII Glue Library做掉一些事情了，所以以前在UEFI Driver內可能一開始會去呼叫InitDxeLib()來初始化gBS/gRT/gST的動作就不用做了，另外Smm Driver寫法也略有不同，其實都是因為被偷做，所以你可以少做!

EDKI與EDKII Code Size的差別?

由於EDKI 本身在LIBRARY撰寫部分並沒有明確規範，所以連結出來的可執行檔的CODE SIZE會比較大，在EDKII上也針對了這部分重新改寫了原來的LIBRARY以減少連結時的CODE SIZE，因此理論上EDKII 環境下產生出來的可執行檔SIZE應該要寫一些。

希望簡略的解釋能更幫助大家在學習EDKII 甚至轉換到EDKII的時候不會驚慌失措，也比較知道為什麼要改成這樣子。

DosBox 模擬器 : 如何自己Compiler

2013-09-12T04:00:00.001-07:00

如果各位是BIOS工程師，但有時候可能有需要在 64 bit OS底下去執行Debug32.exe來看看一些組合語言的東西，但是卻發現在64 bit OS底下，Debug32.exe這隻程式是不能被執行的!

為了解決這個問題，我們通常都會去抓DosBox模擬器來使用，而這邊不是教大家去哪抓，而是跟大家說怎麼去自己抓回來Doxbox source code回來，然後使用VisualStudio 2010 自己Compiler 這個好用的工具。

首先，我們需要去抓Doxbox source code跟一些Library，而 DosBox source code 可以透過SVN抓，但是因為這個DosBox在編譯的過程中會去連結一些Library，所以就先就列出來那些會在設定環境時使用到的部分，要大家要自己先去下載:

Dosbox SVN: http://svn.code.sf.net/p/dosbox/code-0/dosbox/trunk (我是抓Revision 3833)

SDL1.2: http://www.libsdl.org/download-1.2.php

SDL2.0: http://www.libsdl.org/download-2.0.php (執行DosBox.exe 需要他的SDL2.DLL)

SDL_Net 20: http://www.libsdl.org/projects/SDL_net/

Libpng(libpng.lib): http://www.libpng.org/pub/png/libpng.html (我是抓1.6.3)

Zlib(zlib.lib) : http://www.zlib.net/ (我是抓Zlib 1.2.8)

WinCurses(Curses.lib): http://www.baldwin.cx/~john/projects/WinCurses.html (Debug用)

底下是我抓下來後解壓縮放到E:\DosBox的情況:

設定DosBox Compiler環境

1.我們要先產生zlib.lib給LibPng.lib使用，所以透過VS2010 compiler的方式就是先開啟VS2010 commnd prompt，然後鍵入:

E:\DosBox\zlib-1.2.8:\> Nmake /f win32\makefile.msc

在編譯結束後，你會看到zlib.lib被會放在Zlib-1.2.8目錄內。

2.由於DosBox還需要連結libpng.lib，所以我們透過VS2010方案去產生libpng.lib。

所以在開啟VS2010方案檔案前，要先把預設的ZLIB路徑指向我們前面抓的那一個zlib-1.2.8，所以先去修改zlib.props這個檔案，如下圖:

接著開啟方案，然後整個Rebuild Solution.

3.當我們需要的LIB都準備好之後，就可以開啟DOSBOX方案

E:\DosBox\visualc_net\dosbox.sln

4. 因為我們抓的LIB版本比原本設定的還新，所以要去設定方案內的專案屬性內的C++跟Linker的設定：

a. Project Properties->C++->General->Additional Include Directories -->Edit

../include

../src/platform/visualc

../SDL-1.2.15/include

../SDL2_net-2.0.0/include

../lpng163

../zlib-1.2.8

b. Project Properties->Linker->Input->Additional Dependencies-->Edit

       opengl32.lib
       winmm.lib
       ../zlib-1.2.8/zlib.lib
       ../lpng163/projects/vstudio/Debug/libpng16.lib
       ../SDL2_net-2.0.0/lib/x86/SDL2_net.lib
       ../SDL-1.2.15/lib/x86/sdl.lib
       ../SDL-1.2.15/lib/x86/sdlmain.lib
       ../curses/curses.lib
       odbc32.lib
       odbccp32.lib
       ws2_32.lib

5. 如果環境都設定好了，你就可以開始Rebuild，接著等一下子後你就可以看到產生DosBox.exe 到你的Release 目錄內了.

6. 由於產生出來的DosBox.exe 並不能單獨直接執行，還需要一些DLL跟這個執行檔放在同一個目錄內，這些DLL檔案可以從前面抓的那些LIB目錄內找的到，所以我把它集中在同一個目錄內，如下圖所示:

7. 接著你只要執行dosbox.exe (滑鼠點兩下執行)就可以看到模擬器的畫面跑出來，然後我把我自己的E Driver掛在模擬器的K drive，之後就可以在模擬器內的K:\底下找到我放在E:\Debug32.exe並且執行成功:

我的DosBox Compiler環境是在 Window8 64 bit OS，然後使用 Visual Studio 2010的 32bit compiler，所以可以看到我是選Win32 Release build，設定的目錄都是指向x86而不是x64。

希望這邊文章對於想要自己Compiler DosBox但是又一直不成功的人有幫助 ^^

一個關於INT 3h的知識分享

2013-09-11T23:59:00.001-07:00

恩，好久沒來發文章了! 慢慢地最近比較有時間，所以會在寫些文章分享一下知識!

-----------------------------------------------------------------------------------------------------------------

一個關於INT 3h的知識分享

一般來說INT xxh的機器碼會看到是CD imm8 ，例如: CD 19 就是呼叫INT 19h.

而INT3比較特別，他有一個1 byte的OPCODE是0xCC，使用1個BYTE的好處是"他可以覆蓋在任何指令的第一個BYTE而不會去破壞掉原本的指令意思"

而2 bytes的方式就沒這個好處! 如果你了解INTEL 指令，你就會知道一行指令是由Prefix OPCODE.......部分組成的，所以一行指令所代表的機器碼長度不同，因此一個Byte的INT 3h就可以利用這些特性讓Debugger去插入INT 3h的斷點，然後跳到Debug Engine裡面.

底下是範例代碼，一個換掉原本位置的方式:

    lds    bx,BreakToAddress ;Insert INT3h OPCODE to this addrees
    mov al,0CCh                  ;INT 03h opcode
xchg [bx],al                  ;Set INT 3h OPCODE and also save original opcode into AL
   mov    OriginalOpCode,al   ;Save original opcode

EDKII - Build.py

2012-09-19T03:01:00.002-07:00

最近在研究EDKII的 Build process的動作，順便做做筆記!

這個Python Build tool是EDKII/EDK2 的一個Build tool，而底下是Build.py 目前支援的Command line options，因為我還沒追完全部的動作，所以先整理一下比較會使用到的部分:

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

"-a", "--arch", , choices=['IA32','X64','IPF','EBC','ARM'], dest="TargetArch",
"-p", "--platform"dest="PlatformFile"
"-m", "--module",, dest="ModuleFile"
"-b", "--buildtarget", dest="BuildTarget"
"-t", "--tagname", , dest="ToolChain",
"-x", "--sku-id", , dest="SkuId",
"-n", dest="ThreadNumber"
"-f", "--fdf", dest="FdfFile"
"-r", "--rom-image", dest="RomImage"
"-i", "--fv-image", dest="FvImage"
"-C", "--capsule-image", dest="CapName"
"-u", "--skip-autogen", dest="SkipAutoGen"
"-e", "--re-parse", , dest="Reparse"
"-c", "--case-insensitive", dest="CaseInsensitive"
"-w", "--warning-as-error", dest="WarningAsError
"-j", "--log", dest="LogFile"
"-s", "--silent",, dest="SilentMode",
"-q", "--quiet"
"-v", "--verbose"
"-d", "--debug"
"-D", "--define",dest="Macros"
"-y", "--report-file"dest="ReportFile"
"-Y", "--report-type" choices=['PCD','LIBRARY','FLASH','DEPEX','BUILD_FLAGS','FIXED_ADDRESS', 'EXECUTION_ORDER'], dest="ReportType"

"-F", "--flag", dest="Flag",
"-N", "--no-cache", dest="DisableCache"

從上面資料中可以看到-a 或是--arch對他來說應該都是同一個選項.

而底下是一些實際範例的說明，希望對大家有幫助~

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

build.exe -p ACTIVE_PLATFORM

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

ex: build -p DUETPkg\DuetPkg64.dsc

說明: 等同於修改Target.txt內的 ACTIVE_PLATFORM = Nt32Pkg/Nt32Pkg.dsc

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

build -b TARGET

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

ex: build -b DEBUG

說明: 等同於修改Target.txt內的TARGET= DEBUG，以及DSC file: [Defines] BUILD_TARGETS tag

[Defines]
PLATFORM_NAME                  = NT32
PLATFORM_GUID                  = EB216561-961F-47EE-9EF9-CA426EF547C2
PLATFORM_VERSION               = 0.4
DSC_SPECIFICATION              = 0x00010005
OUTPUT_DIRECTORY               = Build/NT32
SUPPORTED_ARCHITECTURES        = IA32
  BUILD_TARGETS                  = DEBUG|RELEASE
SKUID_IDENTIFIER               = DEFAULT
FLASH_DEFINITION               = Nt32Pkg/Nt32Pkg.fdf

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

build -a TARGET

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

ex: build -d x64

說明: 等同於修改Target.txt內的TARGET_ARCH = IA32，以及DSC file: [Defines] SUPPORTED_ARCHITECTURES tag (同上範例)

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

build -t TOOL_CHAIN

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

ex: build -t VS2010x86

說明: 等同於修改Target.txt內的TOOL_CHAIN_TAG = VS2008x86

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

build --log=Build.log

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

--log 可以產生建置過程的紀錄檔

快快樂樂學EFI(4)-使用VS2010建立EDKII專案

2012-09-09T23:47:00.000-07:00

這一篇文章說的方式可以適用於VS2008與VS2010，使用Visual Studio建立專案的好處其實就只是有Tag功能，也就是方便你去追CODE改CODE的功能，雖然我都是使用SlickEdit 不過還是跟各位說一下怎麼使用吧~

在建立Visual Studio專案之前，請確認你已經在DOS Command Prompt下成功進入到NT32的EFI Shell模擬環境，如果還沒成功，請先試試看下面方式:

1) E:\MyWorkSpace:\> EdkSetup.bat
2) 修改E:\MyWorkSpace\Conf\Target.txt 內，搜尋關鍵字MYTOOLS ，並把他改成VS2008x86或是VS2010x86，我是用VS2010，所以要改成VS2010x86

3) 先產生 SHELL檔案，透過 E:\MyWorkSpace:\> build -D BUILD_NEW_SHELL
4) 測試看看能不能看到EFI Shell模擬環境E:\MyWorkSpace:\> build run
5) 如果可以看到Shell，則輸入reset 離開模擬環境

如果上面步驟都已經成功，則你可以繼續底下的步驟來設定VS2010的EDKII專案

Step1: 執行VS2010

Step2: 選擇File->New->Project From Existing Code ...

Step3: 出現的畫面上選擇"Visual C++" project type

Step4: Click "Browse" 然後選擇你的工作目錄 (我的是E:\MyWorkSpace)

Step5: 並在File type的地方輸入底下這些附檔名，他的用意是去辨識哪些檔案要加入專案

*.c;*.h;*.asm;*.asm16;*.s;*.inc;*.asl;*.aslc;*.fdf;*.dsc;*.dec;*.inf;*.py

Step6: 繼續下一步，並選擇 "Use external build system" 然後直接按下 "Finish" (後面的其他設定可以忽略)

Step7: 在步驟6結束後，你應該可以看到專案檔被開啟成功，然後在專案的地方按滑鼠右鍵，然後選擇"Properties"

Step8: 選擇左邊的 "NMake" 然後設定 Configuration 成 "All Configurations".

Step 9: 然後再編輯右邊的 "Build Command Line","Rebuild All Command Line" 和 " Clean Command Line" ，分別輸入下面的設定(請依照自己的工作目錄設定):

For Build Command Line:

------------------------------

cd /d E:\MyWorkSpace
set WORKSPACE=E:\MyWorkSpace
call edksetup.bat --nt32

build

For Rebuild All Command Line:

------------------------------

cd /d E:\MyWorkSpace
set WORKSPACE=E:\MyWorkSpace
call edksetup.bat --nt32
build clean

build

For Clean Command Line:

------------------------------

cd /d E:\MyWorkSpace
set WORKSPACE=E:\MyWorkSpace
call edksetup.bat --nt32
build clean

Step10: 確定你的工作目錄下的Conf\Target.txt內的TOOL_CHAIN_TAG有設定成VS2010x86，不然你會沒辦法使用VS2010的專案來Compiler，如果你是使用VS2008則設定成VS2008x86即可!

Step11: 再選擇一次專案的"Properties"，然後選擇左邊的"Debugging"，接著邊及右邊的這兩個選項:

Command : E:\MyWorkSpace\Build\NT32\DEBUG_VS2010x86\IA32\SecMain.exe

Working Directory : E:\MyWorkSpace\Build\NT32\DEBUG_VS2010x86\IA32

Step12: 當上述的動作都完成了，你就可以試試看Rebuild和Start Debugging的功能了.

成功的話，你會看到EFI Shell的模擬畫面!

※ 本篇文章是參考我以前同事部落格所多做的一些說明，如果你需要更仔細的說明，請參考我以前同事 Tim Lewis 的部落格~

快快樂樂學EFI(3)-建立EDKII 環境

2012-09-06T01:01:00.002-07:00

光陰似箭，歲月如梭! 在EDK推出好幾年後，緊接著BIOS界中的另一個大事情就是又來了一個EDKII。

其實EDK II 推出的概念是因為EDK 有許多使用者有一堆抱怨，像是不能跨平台使用啦~不能用"微軟"之外的Compiler啦~東西不夠模組化啦~

因此針對了使用者的抱怨而做了一些修改? (一些嗎? 改的還蠻大的，不過幾乎都是在Build tool端，本身你寫EFI driver的方式沒啥改變)

從寫EFI driver的角度來看，你會發現有許多的EntryPoint全部被導入到EDKII的Library內去做初始化，這個好處是當Platform改變時容易移植到其他平台!

而其他的部分你就要去習慣新的Build tool的語法以及用法了。

不多說，那要怎麼開始呢? 一樣找Google 大神，找EDKII後點擊第一個連結去抓code吧!

1. 先下載 EDKII codebase

UDK2010.SR1.UP1 DownLoad

2.解壓縮到隨便一個目錄，我是解壓縮到 E:\UDK2010.SR1.UP1

3.從說明文件 "UDK2010.SR1.UP1-ReleaseNotes-MyWorkSpace.txt" 內你可以得知下面幾件事情

1) REFERENCE PLATFORMS 有兩種:

a.Desktop - [Nt32Pkg]

Nt32Pkg\Nt32Pkg.dsc

b. DUET - UEFI Simulation Environment directly on Hardware (via boot process)

2) HOW TO BUILD (WINDOWS SYSTEM) 你要如何在windows系統去建構他

a.Setup Build Environment 設定你的建構環境

- Install Microsoft Visual Studio 2008* SP1 in the build machine and make sure that AMD64

complier was selected when installing.

(安裝微軟的VS2008 SP1，在安裝時要確認你有把AMD64 Compiler選項打勾)

- Download "iasl-win-20070508.zip" from "http://www.acpica.org/downloads/Version_20070508.php"

and extract file "iasl.exe" to C:\ASL

(去這個連結抓iasl-win-20070508.zip 這個檔案，並解壓縮後把iasl.exe複製到C:\ASL ，如果

C:\ASL目錄不存在請自己建立)

b . Extract Common Source Code 解壓縮需要的檔案

- Extract files in [UDK2010.SR1.UP1.MyWorkSpace] to the working space directory (e.g C:).

Note the Directory "MyWorkSpace" will be created as a result.

In this case, it is C:\MyWorkspace. There are two BaseTools package one is for Windows
system and another is for UNIX-Like system.

Please make sure BaseTools(Windows).zip is used here. Expand the appropriate BaseTools to

C:\MyWorkSpace

(把UDK2010.SR1.UP1.MyWorkSpace.zip檔案解壓縮後他會產生一個目錄叫做

MyWorkSpace，在這目錄內有需要的檔案，你可以把這個目錄複製到

C:\MyWorkSpace然後再把Windows的Build tool "BaseTools(Windows).zip"也解壓縮到

這個目錄裡面)

因為我是放在E:\MyWorkSpace，所以會長得像下面這樣子:

c. Generate OpenSSL* Crypto Library (產生OpenSSL Crypto 函數庫)

OpenSSL 的 Crypto 函數庫實作了許多資料編碼方法，像是資料摘要函數(使用

MD2/MD4/MD5/SHA雜湊演算法)，對稱式加密函數(使用RC2/RC4/RC5/DES/IDEA

演算法)以及非對稱式加密函數(DSA/RSA 演算法)。

- Open file "C:\MyWorkspace\CryptoPkg\Library\OpensslLib\Patch-HOWTO.txt" and

follow the instruction to install OpenSSL* for UEFI building.

(打開這個目錄下的文件"Patch-HOWTO.txt"，然後跟著他的說明去安裝需要的檔案)

◎ Download OpenSSL 0.9.8w from official website:

http://www.openssl.org/source/openssl-0.9.8w.tar.gz (先把這個檔案抓下來)　

◎ Extract TAR into CryptoPkg/Library/OpenSslLib/openssl-0.9.8w

(把解壓縮出來的目錄openssl-0.9.8w 放到CryptoPkg/Library/OpenSslLib底下)

◎ Apply this patch: EDKII_openssl-0.9.8w.patch, and make installation

(套用以及安裝這個修正)

-----------------------------

For Windows Environment:

-----------------------------
- Make sure the patch utility has been installed in your machine.

(確認你有安裝Patch的工具，如果沒有，請先到下面網站下載及安裝)
Install Cygwin or get the patch utility binary from
http://gnuwin32.sourceforge.net/packages/patch.htm

我是下載下面紅色框框的那一個

安裝後會在我的C:\Program Files (x86)\GnuWin32目錄內

- cd $(WORKSPACE)\CryptoPkg\Library\OpensslLib\openssl-0.9.8w
- "C:\Program Files (x86)\GnuWin32\bin\patch" -p0 -i ..\EDKII_openssl-0.9.8w.patch

- cd ..

- Install.cmd

d. Build Steps (開始Build code吧~)
*** NT32 ***
- Open a command prompt, type command "cd C:\MyWorkspace" to enter the workspace

directory, and then type command "edksetup" to initialize the working environment.
- Type below commands to build platforms "build -t VS2008x86

(進入到你想到的Platform 目錄內，然後輸入build -t VS2008x86 ，然後你就可以

看到開始建構你的Code了，做到這一步就算完成了!)

底下是其他注意事項:

There are two methods to select the tool chain (Use Microsoft Visual Studio 2008* as sample):
- Update TOOL_CHAIN_TAG in file Conf/target.txt: TOOL_CHAIN_TAG = VS2008

- Add -t build option in command line: "build -t VS2008 ... "

For 32-bit VS2008 on 64-bit WINDOWS OS, VS2008x86 should be selected instead of VS2008.
Please refer to tools_def.txt for all supported tool chains and detailed descriptions.

(tools_def.txt will be generated at Conf directory after running "edksetup".)

最後，希望大家都能夠成功建立自己的建構環境!