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