极客笔记大多数人接触UEFI都是在PC的应用场景上，有在PC上安装过多操作系统的经历的同学，通常会进入UEFI界面设置操作系统引导顺序、CPU虚拟化等设置。UEFI诞生之初也确实是作为BIOS的替代者，主要应用在PC电脑上。
随着手机/平板等移动设备的发展，高通从MSM8998开始使用UEFI替代LK（Little Kernel）作为手机的Bootloader，作为一个嵌入式开发者势必比较好奇，UEFI相比嵌入式常见Bootloader（u-boot、LK等）区别在哪？
UEFI（Unified Extensible Firmware Interface，统一可扩展固件接口）定义了操作系统和平台固件之间的接口，它是UEFI Forum发布的一种标准。它只是一种标准，没有提供实现。
下面让我们通过Tianocore社区提供的EDK2源码一窥UEFI的具体实现，相比其他的Bootloader有什么优势特点。
UEFI入门
启动过程
UEFI系统从上电到关机可分为7个阶段：SEC-> PEI-> DXE-> BDS-> TSL -> RT-> AL
开源嵌入式的Bootloader大多分两个阶段（Stage1、Stage2）。
Stage1：系统资源环境较少情况下部分硬件初始化，为Stage2准备执行环境。
Stage2：系统硬件进一步初始化，定制化功能的实现和操作系统的引导。
进行类比，SEC/PEI可以看作是Stage1，DXE/BDS/TSL可以看作是Stage2。
l SEC阶段/PEI阶段
SEC：Security Phase
PEI：Pre-EFI Initalization
顾名思义，这两个阶段的主要工作是安全校验相关和前期硬件初始化，最重要的是RAM的初始化，让后面的阶段可以执行在外置RAM中。
l DXE阶段/BDS阶段
DXE：Driver Exection Environment
BDS：Boot Device Select
DXE阶段加载各个驱动模块，驱动模块通过Protocol结构体为后续的应用功能执行提供服务，DXE驱动服务在内存中常驻。BDS实现操作系统的启动顺序的设置。
l TSL阶段
TSL：Transient System Load
OSLoader的执行阶段，一般以UEFI应用程序的形式存在。以Android系统为例，需要完成AVB校验，加载Linux Kernel到内存，解析DTB和Kernel cmdline的设置等。
高通的UEFI实现有所精简，SEC和PEI作为Stage1放到了一个Module中实现。
DK2目录
EDK2根目录下很多以*Pkg命令的文件夹，称之为一个Package，是一组功能的集合。例如MdePkg是基础静态库的集合，MdeModulePkg是PEI、DXE启动过程和常见通用驱动框架服务的集合。Package下各个功能目录称之为Module，Module可编译成efi文件动态加载/卸载。
dsc和inf文件相当于是Makefile，定义了Module的编译，生成哪些efi文件，fdf文件将众多的efi文件组织打包成烧录镜像。
UEFI的特点
LK、u-boot等开源的Bootloader都是结构简单的轻量级系统，开发门槛低。UEFI系统虽然较为复杂，但其具有模块扩展性、多任务实现等类操作系统的特性，更易实现复杂功能，且具有较好的开发灵活性，因而高通使用UEFI替换LK作为手机的Bootloader也就不奇怪了。
扩展性
UEFI-统一可扩展固件接口，可扩展性是UEFI的突出优势。这主要体现在UEFI可以动态地加载其它编译好的efi镜像，而u-boot在编译完后并不能动态地加载其它定制化的驱动或者命令。那UEFI是如何实现这一特性地呢？
DXE是UEFI的核心阶段，这一阶段初始化了Boot Services（后面简称BS），BS为后面的引导过程和应用程序的执行提供了几乎所有基础服务接口。看一下BS的结构：
BS中的提供了Image和Protocol的管理接口，Image相关接口提供了efi镜像加载&启动功能，Protocol相关接口则可以找到镜像提供的功能服务。下图描述了Image和Protocol加载到内存后的存储结构，该存储结构揭示了Portocol管理接口如何在Image中找到对应的Protocol服务：接口（HandleProtocol）传入了对应的ImageHandle，则直接通过GUID在IHANDLE的Protocols链表中查找，接口（LocateHandle）没有传对应的ImageHandle则直接在包含所有Protocol的链表中查找。
efi镜像的加载过程：
BDS跳转至TSL阶段时BS调用CoreLoadImage()函数加载TSL的efi镜像，调用过程如下：
CoreLoadImage->CoreLoadImageCommon->CoreInstallProtocolInterfaceNotify
可以看到CoreLoadImage最终申请了一个IHADNLE结构体，并将节点挂到gHandleList列表中。
而后调用CoreStartImage函数最终执行Image的EntryPoint(定义在inf文件中)。
驱动服务模块一般在ModuleEntry中将自身的Protocol注册到ImageHandle中。Protocol的管理接口如何使用就不在赘述。
设备驱动模型
UEFI驱动实现了一种类Linux系统的驱动模型，实现了Host Bus、Driver和Device的架构解耦。(DXE_DRIVER可以看做是一种驱动类型的功能服务，不一定需要硬件支持)
以SCSI驱动为例，在UEFI中的驱动架构大致如下图：
UEFI驱动一般分为两部分，一部分是架构部分的Driver Binding Protocol，一部分是和硬件IO相关的Protocol。Driver Binding Protocol用于在UEFI框架中匹配到Device Handle后，触发Start()接口将对应的IO Protocol协议绑定到Device Handle上。
先看SCSI总线驱动的实现，Start()接口扫描总线上的设备，为设备上的LUN创建Controller Handle(即Device)，并安装SCSI通信协议的IOProtocol：
SCSIBusDriverBindingStart()->ScsiScanCreateDevice()
再看ScsiDisk驱动，安装后匹配到ScsiBus驱动创建的LUN设备，触发Driver Binding Protocol的Start接口，Start接口将BlockIo驱动安装到Controller Handle（即设备）上，这样我们就能在应用或服务中使用BlockIoProtocol的接口读写设备了。
多任务机制
目前接触的嵌入式Bootloader都是单线程系统，但UEFI实现了Linux系统中类似eloop的单线程多任务机制，UE，eloop机制是通过Linux系统的select/epoll系统调用实现了多任务、定时器等机制，那UEFI中是如何实现这一机制的呢？
UEFI中的应用和Event的Notifier可以看作是任务，DXE中初始化的BS提供了事件相关接口实现了异步操作。
Event接口可类比Linux系统中的条件变量，对应的存在create、wait、signal等函数。TPL接口用于提升任务的优先级，当优先级大于31时，中断被关闭，这被用于UEFI锁的实现，因为UEFI中任务的调度依赖时钟中断，关中断后其它任务不会再被调度。
先讲讲任务如何调度的，再来看看如何触发调度。DXE中调用CoreInitializeEventServices函数初始化Event模块，申请了一个事件队列存储调用任务链表，同优先级的在一个按时间排在一个链表中。
Event的调度过程大致如下：
CoreRestoreTpl函数依据gEventPending标志位优先级从高到低遍历任务依次执行，清空后标志位置0。
下面再来看看调度的时机，每一次释放锁的操作，都会触发高于当前任务等级的任务执行，前面说到任务调度依赖时钟中断，中断处理程序进入CoreTimerTick函数有释放锁的操作，高于当前优先级（TPL_APPLICATION）的任务在此时被调度，即每次TimerTick会导致高优先级任务抢占CPU。
时钟中断到CoreTimerTick的过程，DXE中调用CoreNotifyOnProtocolInstallation 函数注册了CPU架构相关的Protocol，其中包含Timer的Protocol。
DxeMain->CoreNotifyOnProtocolInstallation->GenericProtocolNotify:
在注册gTimer之后，GenericProtocolNotify被触发，CoreTimerTick注册到gTimer中断处理函数TimerInterruptHandler中。
以ArmPkg的gTimer为例：
最后看看CoreTimerTick的实现：
先检查Timer的时间，将Timer任务加入调度列表，最后调用CoreReleaseLock（即RestoreTpl）函数触发了任务调度。
小结
u-boot、LK和UEFI等Bootloader各有优劣，无所谓哪一种更好，只有合不合适的情况。目前在嵌入式领域应用最广的BL还是u-boot，结构简单，驱动移植和裁剪的门槛低，可以满足绝大部分嵌入式系统的需求，而UEFI在手机、平板等较复杂的嵌入式硬件更具优势，满足手机设备的多样化需求。
参考文献
-
《UEFI原理与编程》– 戴正华