UEFI的UEFI Driver_uefi驱动

什么是UEFI Driver

 UEFI Driver是一种特殊类型的驱动程序，用于在计算机启动时加载和初始化硬件设备的软件组件，如显卡、网卡、声卡等。而Driver 是用于控制硬件设备的软件程序，它可以在操作系统中运行，并与操作系统进行交互，以便与硬件设备通信。简单来说，UEFI driver是在计算机启动时加载的，而Driver则是在操作系统中加载的。

UEFI Driver Model

 UEFI Driver的引入，更好的实现了模块化，模块化可以理解为这些UEFI Driver就是用来管理设备的，如果说Driver用来管理显卡，那么显卡的厂商就可以独立撰写一个UEFI Driver，这个Driver可以运行在所有的UEFI环境下面，而不必根据不同的环境进行调整。

 所以对于UEFI Driver的模块化，可以做bindary形式的发布，可以build in 到option rom里面去，对外的入口是非常清晰的。这就是为什么说UEFI Driver把整个firmware扩展了，提高了固件整体的扩展性，可能说之前的固件只能跑跑Application，现在还可以加载很多的Driver，第三方写的一些Device Driver，可能不需要build in到flash上，可以在shell阶段重新加载或在BDS阶段加载。

对于跨平台性，同样一个Driver按照二进制形式进行发布后，就可以在所有follow UEFI规范的平台跑起来，这样的方式大家可以并行开发，平台开发和设备开发分别进行，加快进程，最后协同到一起。（它的优势）

UEFI Driver的分类

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

Non Model Driver：
1、对访问硬件没有要求
2、对是否提供Service没有要求
3、符合EFI Driver规范即可，比较随意

Driver Model Driver（有协议）
1、不直接硬件操作
2、不提供任何Services
3、支持加载卸载，符合Driver Binding Protocol规范

---

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。

UEFI Driver的定义

 在DXE phase加载，加载的时候会去执行UEFI的entry point，执行完以后会去做driver的初始化，install这个driver的protocol，如果是UEFI Driver 那么install的就是Driver binding Protocol和component name Protocol，这样就算是执行完了所有的Driver初始化，entry point就退出了，退出再把控制权返回给UEFI Loader。

 Application是到上面的阶段就结束了，什么痕迹都不存在了，但是对于UEFI Driver来说还没有结束，它的Protocol都已经install完了，这些Protocol都已经在Handle database里面，整个UEFI系统已经开始管理了，虽然entry point已经执行完了，但是protocol还在，仍能被其他模块使用，所以Driver是一直常驻在内存中的，直到控制权由BIOS通过exitbootservice移交到OS Loader，才会被全部释放。或者在存在过程中人为将某个模块的Driver卸载掉。

 Handle Database 用于Protocol的管理，假设某UEFI Driver拥有两个protocol，分别有两个不同的名字，提供不同的Service，那么在entrypoint里面就会installprotocol ，install到handle database里面去，这个Protocol还有可能depend到其他的已经install好的Protocol，并不见得这个Protocol体现的就是从头到尾完整的实现，之所以将BIOS启动系统模块化，目的就是通过模块之间的配合加载完成启动。几乎DXE阶段所有的Driver都会调用protocol。上图表示的是，UEFI Driver在加载的时候depend到handle database里面已加载好的Protocol，随后成功install后又会被其他protocol调用，最终管理Device。
————————————————

UEFI Driver Binding Protocol

 UEFI Driver Binding Protocol是UEFI规范中的一部分，它用于在UEFI框架中匹配到Device Handle后，触发Start()接口将对应的IO Protocol协议绑定到Device Handle上。
 install Driver Binding Protocol，是UEFI spec定义好的Protocol，里面包含三个API：Supported（）、Start（）、Stop（）。
————————————————
Supported()：Check DeviceID 和Vendor ID 来辨别某个Device是否由这个Driver管理，如果是则会启动UEFI的Start（），轮询执行很多次，会影响资源占用和启动时间所以除了check并没有其他安排。

Start（）：由Supported（）确定后被启动，在硬件的controller上install一些子的handle，然后在handle上安装一些所提供的服务（Protocol）和Device path，以供给其他人使用。

Stop（）：通常情况下不会去调用，因为同样花费时间和空间，但从UEFI架构考虑到在某种情况下，设备不需要再使用时，想要释放Driver，调用Stop（）后会将所有install的Protocol进行uninstall，这个设备就不会再被管理同时allocate的资源也会被free。但是，Driver以及安装好的Driver Binding Protocol还在，下次仍然可以重新管理使用。

提示：BDS阶段有时会通过connect/Disconnect serverce来调用设备（Supported/Start/Stop），虽然设备再DXE阶段已经存在或已Load准备好了

以ScsiDisk驱动为例，当ScsiDisk驱动被加载时，它会首先去安装一个BLOCK_IO_PROTOCOL和另外一个SCSI_DRIVER_BINDING_PROTOCOL。当系统在UEFI框架中匹配到这个ScsiDisk驱动时，就会去调用这个SCSI_DRIVER_BINDING_PROTOCOL的Support函数。如果这个驱动符合要求，就会执行Start函数，并将这个驱动和这个设备的BlockIO协议绑定在一起，这样就可以在应用或服务中使用这个设备的BlockIoProtocol的接口来读写这个设备了。

DiskIoDxe Driver 实例

链接: UEFI_DRIVER