UEFI Drivers & UEFI Driver Model

 

 1. UEFI Drivers

UEFI Drivers是UEFI Image的一种，UEFI Drivers与UEFI Applications的区别：

Objects managed by UEFI-based firmware:

对UEFI Drivers来说，比较重要的是EFI System Table, Memory, Handles, Images, Events。

2. UEFI Drivers的分类

UEFI Drivers可分为两大类：UEFI Driver Model Driver和UEFI Non Driver Model Driver.

1>. Service Drivers

这种Driver会在一个或多个Service Handle上加载一个或多个Protocol，并在它的Entry Point里会返回EFI_SUCCESS。

2>. Initializing Drivers

这种Driver不会产生任何Handle，也不会增加任何Protocol到Handle Database，它只会进行一些初始化操作，并且返回错误代码。所以这种Driver执行完就会从系统内存中卸载。

3>. Root Bridge Drivers

这种Driver会产生一个或多个Control Handle，而且包含一个Device Path Protocol和一个对芯片跟总线提供的I/O资源软件方式抽象出来的Protocol。最常见的是为PCI Root Bridge产生handles的一个Driver，并且产生的Handle上面支持Device Path Protocol和PCI Root Bridge I/O Protocol.

4>. UEFI Driver Model Drivers

a. Bus Drivers

这种Driver会在Handle Database中产生一个或多个Driver Handle或Driver Image handle，并在Handle上安装一个或多个Driver Binding Protocol的实例。这种Driver在调用Driver Binding Protocol的Start()函数时会产生新的Child Handles，而且会在新的Child Handles上增加另外的I/O Protocol。

b. Device Drivers

与Bus Drivers的区别是不会产生新的Child Handles，只会在现有的Child Handle上增加另外的I/O Protocol。

c. Hybrid Drivers

同时具有Bus Drivers和Device Drivers的特征，既会在现有的Handle上增加I/O Protocol，也会产生新的Child Handles。

注：对应的Handle Type可参见：http://blog.csdn.net/celiaqianhj/article/details/6764433

3. UEFI Driver Model出现的目的

随着硬件总线结构的发展，Bus的种类和数量都在增加，在Preboot的环境下，就需要有一种简单的方式来描述和管理平台上的Bus和Device。UEFI Driver Model就提供了一种简单的方式，具体形式则是Protocols Services和Boot Services。目前为止支持的Bus类型有PCI、USB等等。

1>. 兼容性

遵循 2.3.1 Spec的UEFI Driver Model Drivers必须可以与1.1/2.0 Spec保持兼容性。

2>. 简单性

遵循 2.3.1 Spec的UEFI Driver Model Drivers必须易于实现，易于维护。

3>. 易伸缩性

The UEFI Driver Model必须可以适应不同类型的平台，包括嵌入式系统，笔记本，台式机以及工作站和服务器。

4>. 灵活性

The UEFI Driver Model必须支持可以枚举平台上所有的设备，或者只枚举启动到特定系统所要求的设备。

5>. 可扩展性

The UEFI Driver Model必须可以扩展以支持未来的Bus类型。

6>. 可移植性

UEFI Driver Model Drivers必须可以移植到不同平台或者不同的处理器架构上。

7>. 共存性

Drivers必须可以与其他的Driver或System Firmware共存，且没有资源冲突。

8>. 可以描述复杂的总线拓扑结构

9>. 可执行文件保持最小

10>. 解决了Legacy Option Rom的约束和局限性（Limitation）。

4. Driver的初始化

 一个Driver Image文件可以从不同的媒介上被加载，这些媒介包括：ROM，Flash，硬盘，软盘，CD-ROM或者是从网络连接上。

当一个Driver Image被发现之后，它可以通过Boot Service LoadImage()被加载到系统内存（LoadImage()加载一个PE/COFF格式的Image到系统内存）。同时会为这个Driver创建一个Handle，并且在这个Handle上创建一个Loaded Image Protocol 的实例（EFI_Loaded_Image_Protocol）。包含Loaded Image Protocol 的实例的Handle被称为Image Handle。此时，这个Driver还没有被启动，它只是存在于内存中等待被启动。

我们可以通过Boot Service StartImage()来启动这个Driver。

UEFI Driver Model Drivers必须符合以下几个严格的规则：

1>. 不允许接触任何的硬件，相反的，只允许这个Driver在它自己的Image Handle上安装Protocol实例。

2>. UEFI Driver Model Drivers必须安装一个Driver Binding Protocol到它的Image Handle上，可选择的安装Driver Configuration Protocol, Driver Diagnostics Protocol, Component Name Protocol。另外，如果一个Driver希望可以被卸载，它可以选择更新Load Image Protocol来提供自己的Unloaded功能。

3>. 如果在执行Boot  Service ExitBootService()时，一个Driver希望执行一些特定操作，那么它可以创建一个在调用Boot  Service ExitBootService()时被触发的Event（with a notification function）。

包含Driver Binding Protocol实例的Image Handle被称为Driver Image Handle。

5.UEFI Driver与DXE Driver的区别：

1>. 不需要依赖Dependency来决定执行的顺序

2>. 必须可以被重复执行

3>. 不需要即时启动

4>. 支持硬体的热插拔（Hot-Plug）

5>. 支持软体的热插拔（Unload）

6>. 所有的Function都是Device（Handle）结合Driver（Protocol）所达成

 

 

Refer:

Unified Extensible Firmware Interface Specification, Version 2.3.1 

Driver Writer’s Guide For UEFI 2.0

Beyond BIOS, Second Edition