追踨法蘭克

2012年5月18日 星期五

PEI and DXE Q&A

PEI 和DXE的Q&A,這些是我剛開始學習UEFI時所做的筆記,大約是兩、三年前,看完之後可以更了解UEFI在做什麼。

PEI Q&A:

1. 請寫出開機到os分哪些階段。
:SEC->PEI->DXE->BDS->TSL->RT->AL

2. SEC階段最主要做哪些事?
(1)建立cach as ram.
(2)找到PEI CORE,並驗證其是否正確
(3)在找到BFV 把控制權交給PEI.

3. SEC是什麼組言寫的?
:組合語言



4. 什麼是Boot firmware volume?
:第一個被執行的Firmware volume, 遵循EFI FILE SYSTEM, 包含PEI CORE和PEIM,在開機時SEC會到固定位置找到BFV.

5. PEI最主要做哪些事?
(1)detecting and recovery 壞掉的FV.
(2)初始化系統記憶體
(3)把控制權交給DXE

6. PEI有哪些元件?功能為何?
(1)PEI Core:可以視為PEI的核心,用來Dispatch PEIM和提供基本的Service.
(2)PEI Module:被PEI Core所Dispatch來做各種任務和初始化。功能有對processor、chipset、device做基本的初始,和其他特定的功能。
(3)PPI: PEIM和PEIM之間溝通的介面。
(4)PEI Dispatcher:為PEI Core的一部分,用來搜尋和執行 PEIM.
(5)PEI Service:功能由PEI Core所提供給PEIM使用。

7. PEI Service 有哪些?各Service 功能?
(1)PPI Service.
(2)Boot Mode Service.
(3)HOB Service.
(4)Firmware Volume Service.
(5)Memory Service.
(6)Stats Code Service.

8. PEI的code在哪裡執行?
: cach as ram.

9. PEI Dispatch 四大Rule.
:PEIM未被Dispatch、PEIM為正確的格式、PEIM為可信賴的、PEIM的Dependency條件以符合.

10. 什麼是dependency?dpendency關係記錄在哪裡?如何表示?
:一個PEIM在執行時,有可能會用到其他PEIM的功能,所以要等其他PEIM先執行後、並install PPI至PPI Database中,該PEIM才能使用該PPI也才能繼續執行下去。dependency關係存放在FV的一個特殊的section中。一個PEIM有可能會需要很多其他PEIM先執行才能執行,所以表示
 方法用Boolean運算子AND、OR、NOT和Sequencnig運算子Before、After來表示。

11. 如何dispatch other Fv?
:不一定所有的PEIM都在BFV中,有可能在其他的FV,所以要用Dispatch other FV的機制。
 此時需要一個特別的PEIM來告訴PEI Core說其他FV還有PEIM要Dispatch,所以當PEI Core
Dispatch到這個PEIM時,會把其他FV的PEIM的Dispatch順序加到PEI Core的搜尋algorithm中。

12. 什麼是Notification
:假設一個PEIM有十個function,在執行完九個後,最後一個function需要其他PEIM的功能,但該PEIM尚未被Dispatch,此時可以用Notify的功能告訴PEI Core,需要某PPI才能執行,然後就繼續Dispatch其他PEIM,當有PPI被install,就會和Notify的PPI GUID做比對,如果是Notify的PPI就跳回到下Notify的PEIM去把剩下的function執行完。提供了一個Call back的機制。

13. 什麼是PPI
: PEIM和PEIM的溝通介面,當PEIM要提供功能給其他PEIM使用時,需要先Install一個PPI至PPI DataBase中,其他的PEIM就可以透過PEI Core來使用該PPI。PPI的欄位分為GUID和Interface。GUID是128bit的資料,它是唯一性的,即使不同人在同一時間建立也不會相同。Interface是一個function pointer,用來指向PPI所提供的Function.

14. 什麼是HOB?
:由PEI階段傳送給DXE的資訊只能透過HOB來傳送,所以他包含DXE所需的所有資訊,如PHIT, Physical Memory, Firmware Volume, Dxe Core, Dxe Stack/BSP, Guid HoB。它是Linking list的資料結構,標頭為PHIT,其中包含了Boot Mode的資訊。尾巴是Termination,如果搜尋HOB時找到Termination表示沒有此HOB。 Guid HOB是由chipset vendor提供的資訊,有自己的格式,不想被其它人所使用,是屬於private information。

15. Recovery 的步驟
(1)由platform policy來決定是否要Reset platform.
(2)不管platform有沒有Reset,Core Dispatcher都會做Reset,然後重新Dispatch,只Dispatch有標為Recovery的PEIM
(3)讀取Boot Mode來決定要Dispatch哪些PEIM.

16. 什麼是S3 Resume、要注意哪些事?
:S3是ACPI所定義的一個sleep state. 在進入S3時會把所有hardware的資訊存到系統記憶體中,然後把系統電源幾乎都關掉,只剩下系統記憶體的電源,而且會把記憶體的Refresh Rate調低到至少不會資料遺失。
 在S3 Resume時:
 (1)會把系統電源恢復,並把記憶體的hardware資訊restore回去。
 (2)PEI Core和PEIM不能去使用OS所佔用的系統記憶體位置。所以不能做記憶體初始化的動作。
 (3)不能進入DXE,因為會破壞到記憶體內容。
 (4)PEIM用Special hardware save table 來restore boot configuration和把控制權交給OS Resume Vector.


DXE Q&A:

1. DXE階段做哪些事?
(1)幾乎所有硬體的初始化都在這做完。
(2)產生EFI System Table, 來提供各種Service供後面階段使用。
(3)把控制權交給BDS來Boot OS.

2. DXE有哪些元件?各有什麼功能?
(1)DXE Core: 可視為DXE的核心,用來Dispatch DXE Driver和產生EFI System Table,以提供Boot Service、Runtime Service、DXE Service.
(2)DXE Driver: 被DXE Core所讀取,用來做各種的硬體初始化、產生Protocol和其他Service.
(3)DXE Dispatch: DXE Core的一部分,以正確的順序來搜尋和執行DXE Driver。
(4)DXE Architecture Protocol: 由DXE Driver所產生,是DXE Core和hardware溝通的唯一介面,所以沒有install完全會不能開機。
(5)EFI System Table: 包含了許多pointer, 如:所有EFI system Table、configuration Table、handle database, and console device.

3. DXE用什麼元件找到FV?用什麼方式?用什麼方式將Driver讀至Memory中?
:用Firemware volume block driver. 以memory mapped IO的方式。 PE/COFF Loader.

4. DXE Architecture Protocol有哪些?各有什麼功能?
(1)Security: 提供DXE Core 驗證Firmware Volume中的程式是否可以使用。
(2)CPU: 提供CPU的Service如管理cach、管理中斷、取得處理器頻率、查詢處理器的timer。
(3)Metronome: 提供一個微小的延時,百萬分之一秒為單位。
(4)Timer: 提供固定時間的中斷,使在DXE Core的Timer Service 能正常運作。
(5)BDS: BDS主體,當DXE Core Dispatch完所有Driver後,會將控制權交給BDS.
(6)Watch Dog Timer: 提供enable和disable,為了防止code在執行發生死當,在code執行前enable watch dog
,如果一段時間watch dog沒被關掉,則Reset系統。
(7)Runtime: 提供Service來轉換Runtime Service和Runtime Driver由Physical mapping 轉成 Virtual Mapping.以供OS使用。
(8)Variable: 提供Service來取得和設定環境變數。
(9)Monotonic Counter: 利用CPU內部所提供的64 bit計數器來計算CPU執行頻率。
(10)Reset: 提供Service來Reset或shutdown platform.
(11)Status Code: 提供Service給Dxe Core和Dxe Driver 傳送Status Code 給log 或device.
(12)Real Time Clock: 提供Service來取得和設定目前時間、日期,且能設定鬧鐘時間及日期。

5. 什麼是EFI System Table?
:分別兩部分,左半部是Active Console、EFI boot service table、DXE Service、Handle database。
 右半部為EFI Runtime Service Table、Version Information、System Configuration Table。
 左半部在進入Runtime則無法使用。右半部在進入runtime,如果進入的OS為EFI OS則可以使用,legacy OS 不能使用。

6. 什麼是handle database?
:Handle database 由許多handle所組成,handle是由所多protocol所組成,protocol是由所多function pointer所組成。
一個handle可以是一個Driver、一個Device或一個Service。我們可以透過Handle database 來存取Device.

7. 什麼是SOR?
:Schedule on Request. 當Driver的Dependency Expression裡面的SOR Flag被設起來,表示這個Driver不會被Load也不會被執行,直到這隻Driver被Request以後才會被Load且執行。通常用於當這個Driver的File是存放在一個不可信任的Device上的時候

8. 如果Dxe Driver沒有dependency expression 代表? PEI又?
:表示需要12 個protocol都必需被install後才能被執行。PEI則為TRUE,不用任何PPI先install即可執行。

9. DXE Driver分為哪兩種?
(1)Type1 Non EFI Driver Model,通常執行於DXE的一開始,用來做硬體元件的初始化,或是用來產生Protocol。
(2)Type2 EFI Driver Model, 不會做任何的硬體初始化,用來控制某些特定的硬體,使硬體元件能正常運作,通常在BDS階段做connect用。

10. BDS階段做哪些事?畫出BDS流程圖.
:在Dxe Dispatcher把控制權交給BDS protocol後
(1)初始化BDS Variable
(2)Driver Connet
(3)如果Connet成功-> boot OS,失敗就回去Dxe Dispatcher.

11. BDS會產生哪些Variable?其功能為?
(1)ConIn, ConOut, StdErr, 由這些Variable來決定要初始化哪些Console Device.如鍵盤、滑鼠、螢幕等。
(2)Driver####, DriverOrder, 由這些Variable來決定Driver 被connect的順序。
(3)Boot####, BootOrder, 由這些Variable來決定boot device 的順序。

12. 什麼是SMM?
:System Management Mode,
SMM是一個cpu的特殊操作模式,他用來處理必須馬上處理的一些event,
(1)在EFI管理smm的時候,希望bios programmer去register一些給某些特殊event要用的driver,
比如power button被按下,他會去觸發smi,然後去執行他所regsiter的dirver。
(2)在smm 我們不被允許使用core protocol services.
會跑到不正常的code,導致系統當機。
(3)避免去存取傳統的記憶体resource,因為smm用到的memory與傳統記憶体是有衝突的。
(4)Smmlib 提供方法讓使用者使用dxe core service。

13. 什麼是Firmware Volume? Firmware Volume的目的?
(1)在EFI 架構下,我們通常用Firmware Volume來表示一個實體的儲存元件,
   比如說像FLASH Rom,一個Firmware Volume可以是一個Flash Rom的一部分,
   也可以是很多Flash Rom的集合。
(2)會使用這樣的一種架構,最主要的目的是要定出一個統一的規格,讓在不同的儲存裝置上也能使用同一種檔案格式來儲存。
   在需要更新內容的時候,由於都是使用Firmware Volume的格式,
   根據Firmware Volume的存取方式,我們不必太考慮檔案的位置,也方面做模組化的Update。

14. Firmware Volume protocol 架構圖
:屬於階層式的架構,在高階存取是利用Firmware volume driver來存取,只需要使用高階語法即可存取。低階存取則依據不同的storage device 有不同相對應的Firmware volume block driver來做存取。當上層把命令傳給下層時,會將命令轉成相對應的命令來對storage device做存取。所以不必考慮存取的檔案在什麼storage device中。

15. 什麼是Firmware File System
類似FAT32或是NTFS的一種檔案系統,專供Firmware Volume使用。
此檔案系統在Storage Device的基本計算單位是以File為單位。
檔案系統的File是二進位格式,可以節省FV的Size,並且每個檔案都有固定格式的檔頭,遵循Framework Image format來製作。
每個檔案都是從FV的最底端,以連續排列得方式存在。所以FV的Free Space都會是在FV的最頂端。在命名一個File的時候是以GUID來命名,以確保在一個FV裡面不會有重複出現的檔名,造成搜尋檔案錯誤。

16. 什麼是HII?
:Human Interface Infrastructure.
 共通的人機介面架構,使得在字串,字型,輸入裝置跟多國語言都有一套統一的標準來規範。
 主要是提供一個可以調整硬體元件組態設定的介面。所有系統組態設定的Driver都會被加入到Setup Utility裡面供使用者修改組態。

17. 什麼是IFR、VFR?String?
:Internal Forms Representation. 是人無法看懂的語言,由VFR經由VFR Compile產生。
VFR為人所看得懂的語言,由簡單的標籤式語言組成。
:有被VFR所參考到的String,經過VFR Compiler之後會變成相對應的String Token File,方便IFR使用。

18. 如何把字型install到HII Database中。並如何讓使用者使用?使用者設定的資料存在哪裡?請畫圖!
:(1)透過EFI Driver,它是由IFR、String Token、Fonts和EFI Driver source code經由c compile後產生。
 (2)透過EFI Configuration Driver來產生User Interface來給使用者操作。
 (3)NVRAM.

19. CSM的目的
:(1)boot Legacy OS and load traditional OPROM.
 (2)模擬traditional INTs 來讀取 traditional OPROM.
 (3)更新traditional table
 (4)Boot traditional OS

20. CSM(compatibility support Module)的功能
:(1)EFI Compatibility support module code initialization.
 (2)Traditional OPROM dispatch
 (3)Discovery device and update traditional table
 (4)Boot OS
 (5)Thunk和Reverse Thunk 機制
 (6)IBV所提供的Runtime traditional code.

21. 什麼是Thunk?
:因為CSM在boot legacy OS 和 load traditional OPRom時,需要在16bit環境,但EFI是在32bit,所以透過Thunk機制
 來把系統環境切換成16bit,在執行完16 bit程式後,再回到32bit系統環境。Reverse Thunk正好相反,當我們在16bit
 環境,要切換系統環境到32bit,就要透過Reverse Thunk。通常沒有使用到Reverse Thunk,因為我們會希望在16bit執行
 的程式在執行完就回到32bit的系統環境。

22. Legacy support有哪些?
:(1) 主要是支援Boot一個legacy OS,或Boot一個在legacy device的EFI OS.
 (2) 只有ACPI支援的legacy OS 才能被支援。
 (3) DOS雖然不被ACPI所支援,但CSM還是支援,但不保證所有程式都能運作。
 (4) 支援16 bit code的 legacy runtime bios、int18、int19. int18是boot device fail 時呼叫的.
     int 19是boot legacy os 所呼叫的。
 (5) USB legacy device 必須等到INT19 以後才支援,其中包括了USB 鍵盤以及滑鼠。

6 則留言:

  1. 您好, 最近有在去瞭解UEFI 剛好逛到.

    有一點問題比較有爭議跟您講一下:
    EFI後來設計的重點之一
    就是除掉一直以來壓制發展的real mode,
    所以您文章最原先寫SEC phase的工作內容應該有問題

    這個在PI Spec 裡PEI的文件裡有大致敘述
    歡迎再交流 謝謝

    回覆刪除
  2. 您是指 (1)將CPU由real mode 切換到protected mode.
    這條吧!
    也許我比較專注於x86系列CPU,比較沒注意到。
    看來不同的CPU在SEC也許不同吧!

    回覆刪除
  3. 作者已經移除這則留言。

    回覆刪除
  4. 很實用的筆記~感謝分享!!!

    回覆刪除