網路城邦
RSS Feed Link 部落格聯播

文章數:18
UEFI Framework - 3 [ EFI Driver Model ]
知識學習科學百科 2013/08/19 16:30:01

Driver基本上是被動的,需要等System通知Driver需要管理的Controller有誰。
如果有 Linux or Windows Driver 的撰寫經驗的話,應該會對這一點比較有感覺。
在這篇文章中可以看到相關的code

為什麼需要在 OS Boot 之前有 EFI Driver Model ?
  1. 因為BIOS INT 19H 無法得知在那個Device中有 OS Loader
  2. EFI Driver Model 只要啟動開機時需要的Device 就可以。
 (# int 19h 負責載入啟動程式磁區,再移交控職權給 boot code的服務常式.)


在這篇文章中有提到Driver的分類

以Driver 的 LifeCycle角度來看
  1. EFI Boot Service  drivers: 在Boot的時後會存在的 Driver,一樣會有自己的Memory及status,在 ExitBootServices後會Release。
  2. EFI Runtime Drivers:自己本身的Memory及status會一直存在。


如果以這張圖來看,可以分出

  1. UEFI Driver Model Driver:需要符合下面提到的 EFI Driver Model 規範。(也就是上面圖中的EFI Driver Model Drivers)
  2. UEFI Non Driver Model Driver:如果有不符合的則為此類Driver。

UEFI Driver Model Driver 


Device Driver (EX: USB KB Driver)

  1. 控制Controller或是Device
  2. Start() 不會Create 任何的Child Handle
  3. Start() 會Produce 一個或多個Protocol   (安裝在Device's Controller Handle)                        


Bus Driver(EX: PCI Bus Driver)

  1. 控制及列舉Bus Controller
  2. Start()會Create一或多個Child Handle
  3. Start()會Produce Bus特定的 I/O Protocol(安裝在Bus Child Controller)
Hybrid Driver (EX: PCI SCSI Host Controller)

  1. 控制及列舉Bus Controller
  2. Start()會Create一或多個Child Handle
  3. Start()會Produce Bus特定的 I/O Protocol (安裝在Bus 本身 Controller Handle或Child Handle)
UEFI Non Driver Model Driver

Service Driver (EX : Boot Integrity Service)
  1. 不會控制到Hardware
  2. 提供Service到其它的Driver
  3. 不會Support Driver Binding Protocol
  4. 通常會在Driver Entry Point 的地方安裝Protocol
  5. Create 一個或多個 Service Handles
  6. 會Produce Service特定的Protocol (安裝進Service Handle)
Initializing Driver (EX:SBDXE_Init)
  1. 通常會接觸到Hardware
  2. 執行一次性的Initialization 運作
  3. 不會Produce任何的Protocol
  4. 當Finished的時後會Unload



Root Bridge Driver (PCI Host Bridge) # 可參考下面的 Host Bug Controller 

  1. 通常會控制部份的Core Chipset
  2. 直接碰觸到硬體
  3. 會Create 一個或多個 Root Bridge Handle
  4. Produce Root Bridge I/O Protocol


EFI Driver Model 規範 
  1. EFI Driver Module不允許碰到任何HardWard,從別一個方面來說,它允許的只有install protocol instance 到 image 的 Handle中。
  2. 一個包含Driver Binding Protocol的Image Handle就稱為Driver Image Handle。
  3. Driver可以選擇性地決定要不要安裝其他Protocol
  4. 允許做自己的Unload() function, 這是optional的function
  5. 如果需要一些特別的操作,可以實作Notification function,在ExitBootServices()時會被觸發到。


下面是optional的protocol
EFI_DRIVER_CONFIGURATION_PROTOCOL
EFI_DRIVER_DIAGNOSTICS_PROTOCOL
EFI_COMPONENT_NAME_PROTOCOL




Driver Initialization
   Driver Image 需要從下面列出的Media中load。
   ROM, flash, hard drives, floppy drives, CD-ROM, or even a network connection.

   Driver Image 可以透過BootService 的 LoadImage() Load PE/COFF 格式的image到System  
     Memory中。

例如: gBS->LoadImage (
               TRUE,
               ImageHandle,
               DevicePath,
               NULL,
               0,
               &FileImageHandle);

將DevicePath上的Driver Image載入到System Memory之後, 取得Handle並存放在FileImageHandle裡。
而FileImageHandle會被掛上一個LOADED_IMAGE_PROTOCOL。

如下圖所示:








在這個時後,Image 還沒被啟動,
需要透過BootService的StartImage()來啟動它。



Host Bus Controller ( Root Bridge Driver )
Firmware Component不會受到 EFI Driver Model規則的影響
像是如下圖的CPU 及 Core Chipset Component
Core Chipset components 產生 m host bridges (Host Bus Controller)

Host Bridges (Host Bus Controller) 
  1. 不屬於EFI Driver Model的任何一種。
  2. 會提供I/O Interface
  3. 包含了DEVICE_PATH_PROTOCOL (如果有對應到實體的Device ex:PCI Bus)
  4. 另一個PROTOCOL會提供I/O的Operation (像下圖的PCI Host Bridge)
下圖是當Device Driver 連結到Device Handle(Host Bridges)的狀態
原本的Device Handle是由XYZ Bus Driver所Create出的Child Handle,
連到Device Handle的Device Driver必需要在自己的Image Handle上安裝Driver Binding Protocol。而Drive Binding Protocol包含下面三個function
  1. Support() :用來檢查Driver是否有支援Controller,以上面的例子而言的話,會檢查Device Handle 有沒有支援DEVICE_PATH_PROTOCOL。
  2. Start() :如果Support的檢查有通過,就可以使用Start()連結Controller
  3. Stop():使Driver停止管理Controller
這三個Function需要透過BootService的 OpenProtocol()得到
Protocol Interface,不用的時後可以用CloseProtocol() Release。
可以透過 System Firmware 管理的 Handle Database取得Controller的資訊

OpenProtocolInformation可以取得使用這個Protocol Interface的component list

Bus Driver 跟 Device Driver只有在概念上的定義有不同,唯一的不同只在於Bus Driver會建立Device Handle 給自己在Bus 上找到的child controller使用

Bus Driver有兩種不同的分類
  1. first call to Start():會呼叫Start()給所有找到的Child Controller,每個Child Controller都會有一個Handle。
  2. multiple calls to Start():多次呼叫 Start()建立 一個個 Child Controller 的Handle 。這個方法對於Fast Boot很有用,可以建立少量的Handle甚至是一個Handle。

在下圖是Bus Controller在呼叫 Start()及 Stop()之前的狀態。
虛線代表Bus Controller的Parent Controller。
如果是Host Bus Controller就不會有Parent Controller。

節點A B C D E代表Bus Controller的Child Controller
當呼叫Start()時,Bus Driver可以選擇只建立其中一個Child,且可以選擇先建立某一個Child。
Driver Binding Protocol的Supported(), Start()以及Stop() function有足夠的彈性能夠這樣做。

Bus Driver必需要install 可操作Bus Service的I/O protocol到各個Child Controller。
像下圖XYZ Bus Driver 建立了一個 XYZ的 Child Device Handle,它support 了DEVICE_PATH_PROTOCOL、IO_PROTOCOL及OVERRIDE_PROTOCOL。

Bus Driver可以選擇性地安裝Bus Specific Driver Override Protocol到每一個Child Handle. 這個Protocol會使用在Driver連接到Child Handle時, 呼叫Boot Service ConnectController(), 
從原本有定義好的一些優先權規則, 找到最適合的Driver安裝到Controller上. 
Bus Specific Driver Override Protocol比一般的Driver搜尋演算法有更高的優先權, 但比Platform Override低. 

ConnectController以及DisconnectController可以用來讓Platform Firmware決定那個Controller要被Start那個不要。

Platform也會決定是否要產生Platform Driver Override Protocol。
這個方式也讓EFI能夠支援HotPlug Events。


UEFI Driver與DXE Driver的區別


在這邊指的UEFI Driver也就是符合EFI Driver規範的Driver
也就是上面圖中的(UEFI Driver Model Driver)
而DXE Driver通常指得是上圖中的(Initializing Driver)
不過明確的定義,還是需要看那隻Driver的運作而定 
  1. 不需要依赖Dependency决定執行的顺序
  2. 必需可以被重覆執行
  3. 不需要即時啟動
  4. 支援硬體的熱插拔(Hot-Plug)
  5. 支持軟體的熱插拔(Unload)
  6. 所有的Function都是Device(Handle)结合Driver(Protocol)所達成

http://william30101.blogspot.tw/2012/05/uefi-framework-3-efi-driver-model.html

最新創作
UEFI Framework - 3 [ EFI Driver Model ]
2013/08/19 16:30:01 |瀏覽 2007 回應 0 推薦 0 引用 0
BDA & CMOS
2013/07/31 22:02:51 |瀏覽 2160 回應 0 推薦 0 引用 0
UEFI Firmware Hierarchy
2013/07/31 00:24:49 |瀏覽 4508 回應 0 推薦 0 引用 0
UEFI Drivers
2013/07/30 20:43:04 |瀏覽 7415 回應 0 推薦 0 引用 0
BIOS basic knowledge - 2 Important HardWare
2013/07/30 00:01:29 |瀏覽 1878 回應 0 推薦 0 引用 1