EFI 基礎知識

這邊看情況再回來修改，主要是目前自己學的也不是很熟悉，只把確定的知識拉出來喇迪賽。

幾個重要的 EFI object type:

• EFI System Table
• Memory
• Handles
• Images
• Events

一般在寫 EFI driver or app，應該最常用到就是 System Table (ST)。裡面有太多的資料結構可供使用，基本可謂之 EFI 的脊骨。 

SystemTable->BootServices
SystemTable->RuntimeServices

這個常寫 EFI driver (app) 應該很熟著用了，反正基礎思想就是以 code 佐 spec 慢慢去試。
再來容易讓別人混淆的就是 Handle database、Handle、Protocol 和 Driver 的相互關係。

Handle database 故名思義，不多說；Handle 可看成  protocol 的 repository，它本身沒什麼屬性，性質也是看存放的 protocol 而訂。這段不廢話，多做些引用 handle 和 protocol 的練習自然就懂了。

Driver 和 Protocol 的關係也是使初接觸的人難以理解。EFI Driver 就是擁有一個或多個函數的 executable EFI image，Protocol 就是 Driver 的函數指標。

所以常常看到 spec 裡面什麼 

"某某 driver consumes protocol 同時又 produces protocol"  

之類的，就不要懷疑了，函數互相調用而已。 單個 protocol 要發佈成 global 都得有個 GUID 識別。其實上面那句有點語法問題，基本上不需要 global 的 function 就不要做成 protocol 了…反正喇喇賽。

下面貼個 protocol interface：

#define EFI_COMPONENT_NAME_PROTOCOL_GUID \ 
  { 0x107a772c,0xd5e1,0x11d4,\
    0x9a,0x46,0x0,0x90,0x27,0x3f,0xc1,0x4d } //GUID

typedef struct _EFI_COMPONENT_NAME_PROTOCOL { 
  EFI_COMPONENT_NAME_GET_DRIVER_NAME       GetDriverName; 
  EFI_COMPONENT_NAME_GET_CONTROLLER_NAME   GetControllerName; 
  CHAR8                                    *SupportedLanguages; 
} EFI_COMPONENT_NAME_PROTOCOL;

一個 GUID，兩個 function pointer，一個 string，這個 protocol 型體就長這樣，其它的也就差不多，使用頻繁自然會懂。

EFI 下的 Image，無論是 application 還是 driver，都擁有 PE / COFF header 描述，Microsoft Windows 和 Unix 下皆可分析其結構，具體情況 wiki 一下，不贄述。

EFI 接觸現在兩個多月，感覺就是個 protocol 和 driver 的世界，這部份搞得清楚來，以後會比較好作事，先寫到這邊，未來有想法再補充。