Hi，大家好，我是编程小6，很荣幸遇见你，我把这些年在开发过程中遇到的问题或想法写出来，今天说一说Note_Driver,希望能够帮助你!!!。

几种特殊的Protocol：

(1):Architectural Protocol：UEFI最基础的Protocol。

(2):Device Path Protocol：一种纯数据的结构体，表示一个设备的可编程路径。

(3):EFI_DRIVER_BINGING_PROTOCOL:用在一个叫做UEFI Driver Model类型的驱动中(这种驱动在DXE阶段安装，在BDS阶段使用)。

开发DXE Driver：

DXE driver只能运行于Boot service 环境，当boot loader调用ExitBootServices()时，所有的boot service将被销毁，此时DXE driver便失效了。一个DXE driver可以当成一个可供调用的库，当我们实现了某个功能然后要与别人共享，但又不想给代码时，我们就可以将它写成一个DXE driver，把编译生成的efi和一个.h文件给出去即可，这一样可以被调用。

开发UEFI Driver：

1.Driver分为两部分：

UEFI Driver Binding Protocol：管理驱动程序；

包括Driver的配对，使用，卸载；

Driver Service本身：驱动程序内容；

配对：检查此设备控制器是否支持此驱动；

使用：将此驱动安装到设备上并启动该硬件设备；

卸载：停止设备并卸载驱动。

(作为一个友好的Driver，通常还要包含一个UEFI Component Name Protocol)。

Driver的加载过程：

Driver的各部分代码包括配对，使用，卸载都写完之后，我们就开始了解加载驱动的细节。

首先，在Shell中使用load命令将驱动文件加载到内存，加载后UEFI会调用gBS->StartImage(...)执行驱动DriverImage的入口函数，然后在入口函数中Driver Binding Protocol会被加载到Handle上（Driver Image Handle或Controller Handle），UEFI开始遍历所有的控制器，让每一个控制器调用CoreConnectSingleController函数，此函数中会调用EDBP的supported函数检查此Driver是否支持该设备控制器。如果支持则执行start。

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

今天的分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。