UEFI/PI (5) Driver Execution Environment

DXE Overview

1. DXE Overview
   Driver Execution Enviroment (DXE)是 PI SPEC.裡的第二個phase，在這個phase中有許多的東西被啟動或初始化。同時，EFI services、protocols及driver都在這個時候被implement或support。DXE也建立了許多system table。
2. Importance of DXE
   Without DXE
   1. 每個人的coding style 不同，同時，每家code base也可能不一樣。因此，BIOS的feature的實作方式也會因為vendor不同而有所差異，這造成了移植的困難。
   2. 一個單一的source file控制整個啟動流程，造成開發新的feature或更改上的困難。
   With DXE
   1. DXE參考OS的做法，driver及library都定義得很清楚，因此也很容易實作模組化的 driver。
3. DXE Foundation's Function
   DXE Foundation是DXE Phase的核心，他有許多的functions可以使用。下面分成四個部分來介紹DXE Foundation。
     
   1. Initialize Platform
      DXE Foundation initial Chipset及platform。 其中一個function會load driver來建構環境，最後boot manager 及OS
   2. Dispatch DXE
      DXE foundation會先dispatch DXE driver，他會處理相關的相依問題。
   3. Dispatch UEFI
      在dispatch DXE driver後，DXE foundation會去dispatch UEFI driver，而UEFI driver是沒有相依問題的。
   4. Load Boot Manager
      每一個driver在entry point的地方都必須註冊與那些protocol相依，因此Load Boot Manager可以依此做initial 的排序。最後會將control交給下一個phase - BDS。
4. DXE Foundation Properties
   DXE Foundation有許多的特性，以下一一介紹。
   1. HOB List Dependent
      上一個phase PEI會將所有的hardware, reosurce的 state放到HOB傳給DXE，因此，DXE無須知道hard-coded address
   2. No Hardware Specifics
      DXE drivers必須透過Architecture Protocols(APs)來與硬體溝通。因此不可以假定現在使用的是哪個硬體然後去使用它特定的東西，例如address。
   3. No Hard-Code Address
      因為沒有hard-coded的address，在system memory任何地方都可以load DXE foundation。
5. DXE Components
   DXE 同樣有許多的component，以下一一介紹。
   1. Drivers
      負責初始化Processor、Chipset及Platform。而DXE Driver 更是負責建構APs。
   2. Foundation
      負責Dispatch drivers、建立Boot services、Runtime Services及DXE Services。
   3. Architectural Protocols(APs)
      因為沒有hard-coded的address，在system memory任何地方都可以load DXE foundation。
   4. EFI System Table
      EFI system table存放了指標指向包含了UEFI Service tables、 Configuration tables、 Handle databases及console devices
   5. Dispatcher
      DXE Dispatcher會依照相依以正確的順序啟動 driver。
6. DXE Phase Flow
   DXE的執行階段可以分成幾個步驟:
   1. DXE Foundation Initial Services，包含UEFI Service及DXE Service。
   2. DXE Foundation Dispatch DXE drivers。
   3. DXE Dispatcher 搜尋FV裡面是否有priori file，依照順序將driver load到memory。
   4. 接著尋找FV裡剩下的Driver並Load進memory。
   

Data Structures and Events

1. Data Structures
   
   
   
2. Events
   因為Event是與CPU architecture不相關的，因此UEFI使用event來作為object、protocol之間的訊號。 解釋下圖，主要可以分成Singnal events及wait events。
   
    
   1. Exit Boot Service Events
      是當呼叫ExitBootService()的時候從wait event轉回signaled state。
   2. Set Virtual Address Map Events
      SetVirtualAddressState()
   3. Periodic Timer Events
      是週期性觸發的event
   4. One Shot Timer Events
      可以指定時間觸發的timer event
   5. Wait Event
3. EFI System Table
   
   
   

DXE Foundation

1. DXE Foundation Code Flow
   DXE Foundation有兩個attributes: Single Threaded Environment and One Interrupt
   1. Single Threaded Environment
      a. 在DXE Foundation的code只會有Boot Strap Processor(BSP)會執行。 b. 其他的application processor都進入 wait mode。
   2. One Interrupt
      a. DXE foundation只使用timer tick作為software的interrupt。 b. 因為只使用timer iterrupt，因此所有的devices都會被pulled c. DXE foundation 會使用event取代multiple interrupts。
2. DXE Main
   
3. DXE Main Source Code
   

Architecture Protocols

1. APs Defined
   DXE藉由DXE Drivers 會產生 Architectural Protocols(APs)抽象化硬體的溝通，以下以三個部份來介紹。
   1. Function
      可以把AP's 想像成脫離platform-specific hardware的wrapper function。舉例來說，CPU AP 管理interrupt、取得processor info、取得processor-based的timer。
   2. Support
      AP's 是low-level的protocols用來支援啟動以及runtime services。我們可以利用higher-level的platform function來使用AP's提供的功能。
   3. Dependency
      有些AP可能會與其他的AP相依，舉例來說，whatchdog 需要IO及timer的access。有三種方式可以解決相依的問題：a. 利用Dependency Grammar來load DXE b. 使用RegistryProtocolNotify()來通知AP被load進去了。 c. 使用Priorl List將預先知道的AP 依照相依順序排好讓dispatcher按照這個順序dispatch。
2. APs' Role
   
   ，藍色的在os runtime會被free掉，灰色則可以繼續使用
3. APs' Location
   

DXE Dispatcher

1. DXE Dispatcher
   DXE Dispatcher 負責load和dispatch FV(Firmware Volume)裡的　DXE及UEFI driver。 DXE Dispatcher主要有幾個目標如下：
   1. Driver可能是由不同的組織、部門所撰寫。因此Dispatcher必須能處理DXE Driver 之間的dispatch 順序
   2. DXE Dispatcher支援例如emergency patches。另外，DXE Dispatcher也讓開發人員更容易整合自己開發的driver。
2. DXE Dispatcher Source Code
   
3. DXE Dispatcher State Machine
   
4. DXE State Machine Example
   

DXE Drivers

1. DXE Driver Type
   DXE drivers包含了device或service code執行在UEFI driver之前。如同之前所提到的，DXE 階段的driver分成兩種，即DXE Driver和UEFI　Driver。下表比較了兩個的不同。 
   
2. BDS Driver
   在DXE階段最後一個driver是BDS( Boot Device Selection) Driver。BDS driver負責建立console( keyboard, video)及執行UEFI Boot Option。 下圖是啟動BDS的示意圖。額外說明的是，因為當Dispatcher load BDS的時候，會先進去她的entry point讀取相依的APs，因此假設仍有未完成的APs則可能回到DXE Dispatcher去load其他的driver。 
   

SMM

System Management Mode(SMM)他是CPU的一個模式，當我們觸發CPU的SMI Pin的時候就會進入SMM Mode。 SMM模式下的執行的程序被稱作SMM處理程序，所有的SMM處理程序只能在稱作系統管理內存（System Management RAM,SMRAM）的空間內運行。 

Ref.

1. SMM Service
   SMM service是高優先權的system management interrupt(SMI)，在runtime的時候仍然可以接管系統。下面分成三個特性及兩個service特點來介紹。 Characteristics
   1. 在SMI的時候，CPU執行pre-defined starting vector。
   2. SMM的code放在SMRAM中，在SMM初始化後會lock起來。
   3. SMI是由hardware event或 system interrupt所產生的。它可以被偵測、清除或disable。
   Services
   1. SMM service是一個handlers的list。並且都是DXE foundation service的subset。
   2. SMM services和DXE foundation services提供同樣的functionality但不同的是SMM locate在SMRAM中。
   3. SMI是由hardware event或 system interrupt所產生的。它可以被偵測、清除或disable。