开宗明义—UEFI介绍 (二)

最新推荐文章于 2025-04-07 00:00:00 发布

老衲不依

最新推荐文章于 2025-04-07 00:00:00 发布

阅读量2.4k

点赞数 8

分类专栏： UEFI 文章标签： arm开发 microsoft

本文链接：https://blog.csdn.net/heshuangzong/article/details/127115488

版权

UEFI 专栏收录该内容

10 篇文章

订阅专栏

UEFI介绍

声明

上一篇介绍了UEFI的发展历史，以及对UEFI在ARM嵌入式领域的生态状况做了简单的调研。本篇旨在对UEFI规范和PI规范的内容以及二者之间的关系做一个简单的梳理。

本篇参考内容主要来源于以下3方面：
(1) 微信公众号“ Wolf UEFI社区 ”系列文章。
(2) 《UEFI原理与编程》—戴正华。
(3) UEFI Spec和PI Spec官方文档。

1.UEFI 规范和PI规范的关系

通过阅读UEFI Spec和PI Spec中的introduction可知，UEFI主要侧重于接口规范，而PI主要侧重于接口应该如何实现。

实际上，PI规范是关于如何实现UEFI接口的标准。许多固件号称自己是UEFI固件，实际上他们只是实现了UEFI接口，并不一定遵守PI规范。

这里我们再强调一下：UEFI纯粹地是一个接口规范，它不会具体涉及平台固件是如何实现的。“如何实现”这一内容是PI（Platform Initialization）要解决的问题。

2. UEFI和PI各自定义的范畴

上一篇《开宗明义—UEFI介绍 (一)》我们介绍了UEFI的发展。下面重点介绍UEFI论坛是如何对UEFI和PI这两个规范进行管理的。或者说，UEFI论坛究竟如何制定这两种规范。

因为Intel已完成了初版的EFI规范和实现，在得到全行业的认同之后，论坛已算是基本形成。

UEFI论坛在华盛顿注册为非营利性公司。它负责开发，促进和管理UEFI规范的演进，并不断推动UEFI采用的低门槛化。

UEFI成员管理采用分级制：发起者，贡献者和使用者。关于该分级，Welcome to Unified Extensible Firmware Interface Forum上有更详尽的描述。发起者包括：Intel，AMD，AMI，Apple， Dell， HP，IBM，Insyde， Lenovo， Microsoft，和Phoenix。

下图展示了论坛的基本构成和相应的角色：

在这里插入图片描述

其中有两个很重要的工作组：PI工作组（The Platform Initialization Working Group，简称PIWG）和UEFI规范工作组（The UEFI Specification Working Group，简称USWG）。

PI工作组（The Platform Initialization Working Group，简称PIWG）是专门制定Spec中PI（ Platform Initialization ，平台初始化）部分的工作组。UEFI规范工作组（The UEFI Specification Working Group，简称USWG）则是主要负责UEFI Spec推进工作的部门。

可以说，UEFI论坛的基本成型的过程就是UEFI初版规范的制定过程，毕竟，论坛就是为规范而生的，在制定规范过程中的自然分工就是论坛的初期结构。

而论坛各个组织的分工，也决定了UEFI和PI规范各自的范畴。下图展示了UEFI系统的结构和两个规范的范畴。
在这里插入图片描述

3. UEFI 和PI 的区别

3.1 UEFI规范

UEFI规范主要定义了平台固件和操作系统\操作系统加载器之间的接口。它的主要目的是：为操作系统的启动营造一个标准的执行环境。

如何为操作系统创造一个标准的启动环境呢？UEFI规定了：

固件向操作系统或操作系统加载器提供标准的接口和结构集合,并屏蔽平台硬件信息。
固件要向操作系统或操作系统加载提供哪些接口和服务。平台固件和操作系统或操作系统加载器之间只能通过这些标准接口交互。

可见UEFI 协议的实体内容是：一组核心服务以及一组协议接口。

UEFI标准接口采用数据表 (EDK2中称之为系统表) 的形式提供服务，主要包括启动服务（Boot Service, BS）和运行时服务(Runtime Service ,RT)，以及隐藏在BS之后的各种Protocols。

3.2 PI 规范

UEFI规范定义了需要实现哪些接口，而PI规范主要定义了平台固件如何实现这些标准接口。

不同的平台供应商可以通过不同的方式来实现UEFI 规范需要的接口和服务。由于不同的厂商之间代码差距太大，不具备互操作性，规范性很低。而在UEFI中，针对这一过程，提出了专门的平台初始化标准（PI Spec）。

UEFI将系统从上电到关机分为7个阶段：SEC—>PEI—>DXE—>BDS—>RT (UEFI & OS Loader )—>AL。其中，PI规范定义了前三个阶段SEC，PEI，DXE 的标准实现。在DXE阶段结束后，UEFI接口所依赖的环境已经ready，剩下的BDS、UEFI+OS Loader和RT一起，属于UEFI规范定义的内容。而AT阶段属于供应商自定义的内容。

UEFI系统的启动阶段如下图所示：
在这里插入图片描述

PI规范是从UEFI 2.0规范中独立出来的，脱胎于Intel的PEI和DXE规范。下图说明了PI的范围。

在这里插入图片描述

4. UEFI系统的启动过程

我们将从上电到操作系统运行都遵循UEFI规范的计算机系统称为UEFI系统。下图展示了UEFI系统的组成。
在这里插入图片描述

4.1 UEFI系统启动介绍

UEFI系统启动的宏观过程：

从操作系统加载器（OS Loader）被加载，到OS Loader执行ExitBootServices()的这段时间，是UEFI环境向操作系统过度的过程。这个过程中，OS Loader可以通过BS和RT使用UEFI提供的服务，将计算机系统资源逐渐转移到自己手中，这个过程称之为TSL(Transient System Load)。

当OS Loader完全掌握了计算机系统资源时，BS也就完成了它的使命。OS Loader调用ExitBootServices()结束BS并回收BS占用的资源，之后计算机进入UEFI Runtime阶段。在 Runtime阶段只有运行时服务继续为OS提供服务，BS已经从计算机中销毁。

但是查看EDK2中的代码，大多数ARM 平台的OS Loader没有这么玩，并没有执行ExitBootServices()结束BS。因此，从DXE阶段执行结束到OS开始运行，UEFI固件拥有所有BS和RT服务。

UEFI系统的7个执行阶段：

下图展示了UEFI系统从上电到关机的7个阶段。

前3个阶段属于PI规范定义的平台初始化阶段，DXE阶段结束后UEFI环境已经准备完毕。

后面4个阶段属于UEFI规范，BDS和TSL是操作系统加载器作为UEFI应用程序运行的阶段。当UEFI 系统出现严重错误不能继续正常运行时，固件会尝试修复错误，这时进入AL期。但PI规范和UEFI规范都没有规定AL期的行为。“？”号表示其行为由系统供应商自定义行为。

在这里插入图片描述

4.2 UEFI系统启动7个阶段

4.2.1 SEC (Security Phase)阶段

安全检测（SEC）阶段,是平台初始化的第一个阶段，计算机上电后进入这个阶段。

SEC阶段的功能

从功能上说，它应该执行以下4任务。

（1）接收并处理系统启动和重启信号。包括系统上电信号，系统重启信号，系统运行过程中的严重异常信号。

（2）初始化临时存储区域(IRAM)。系统运行在SEC阶段时，大部分外设和RAM都没有被初始化，需要先初始化SOC内部的SRAM(最常见的是用于Cache)用于代码和数据的存取，我们称之为临时RAM。

（3）作为可信系统的根。在将控制权转移给下阶段代码前，可以先对其验证。

（4）传递系统参数给下一阶段（PEI）。SEC阶段做完自己的工作后，需要将当前信息通知给PEI。通过传递如下信息给PEI入口函数：

系统当前运行状态。
可启动固件（Boot Firmware Volume）的地址和大小。
临时RAM区域的地址和大小。
栈的地址和大小。

2.SEC阶段执行流程

在这里插入图片描述

4.2.2 EFI 初始化准备 (PEI) 阶段

PEI （Pre-EFI Initialization）阶段主要任务是为DXE准备执行环境。需要将传递到DXE的信息组成HOB(Handoff Block)列表，最终将控制权交到DXE手中。

从功能上讲，PEI可分为两部分：

PEI内核（PEI Foundation）：负责PEI基础服务和流程。
PEIM(PEI Module)派遣器：主要功能是根据Flash文件系统的定义遍历固件卷FV, 找出所有PEIM。并根据PEIM之间的依赖关系按顺序执行PEIM。PEI阶段对系统的初始化主要是由PEIM完成的，不同的PEIM之间可以通过PPI(PEIM—to-PEIM Interface) 完成数据传输。

PEI阶段执行流程如下：
在这里插入图片描述

当PEI模块被加载到内存后，作为一个单独image存在。首先要执行image入口函数_ModuleEntryPoint，该入口函数会调用到PEI 模块入口函数PeiCore。

PEI的执行顺序：

根据SEC阶段传递的信息设置Pei Core Services。
调用PeiDispatcher遍历并执行系统中的PEIMs。
当说要PEIM执行完后，调用PeiServices的LocatePpi服务得到DXE IPL PPI，并调用DXE IPL PPI的入口函数。
找出DXE Image的入口函数，执行DXE Image的入口函数并讲HOB列表传递给DXE。

4.2.3 驱动程序执行环境（DXE）阶段

DXE (Driver Execution Environment) 阶段，执行大部分系统初始化工作。该阶段是 UEFI 系统中加载组件最多的、最重要的一个阶段。从程序设计角度看，DXE阶段和PEI阶段比较类似。DXE阶段执行流程如下：

在这里插入图片描述

从功能角度，DXE分为两部分：

DXE内核：负责DXE基础服务和执行流程。主要包括：系统表，启动服务，运行时服务。
DXE派遣器：负责搜索并安正确的顺序执行DXE驱动。

DXE 驱动是各个独立的模块，以Image的形式被加载和执行。DXE驱动模块之间通过Protocol的方式通信，并以Protocol的方式对外提供接口。

DXE驱动负责初始化处理器、芯片组以及其余平台组件，同时为系统服务、控制台设备和引导设备提供抽象接口。这些组件协同工作，初始化整个硬件平台，提供操作系统启动所需要的服务。

当所有的DXE驱动模块被派遣器调度执行完毕后，系统完成了初始化。DXE内核通过EFI_BDS_ARCH_PROTOCOL找到BDS内核，并调用BDS的入口函数。进而进入BDS阶段。

4.2.4 启动设备选择（BDS）阶段

BDS (Boot Device Selection) 的主要功能是执行启动策略，其主要功能包括：

初始化控制台设备。
Connect 必要的驱动设备。
根据系统设置加载和执行启动项。

如果加载启动项失败，系统将重新执行DXE Dispatcher以加载更多的驱动，然后重新尝试加载启动项。

BDS的启动该策略通过全局变量NCRAM变量配置。这些变量可以通过DXE阶段提供的运行时服务GetVariable()读取，通过SetVariable()设置。例如，变量BootOrder变量定义了启动顺序，变量Boot####定义了各个启动项（####代表4个十六进制大写符号）。

用户通过图形界面选中某个启动项（或启动进入默认的启动项），OS Loader启动，系统进入TSL阶段。

4.2.5 瞬时系统加载（TSL）阶段

前面介绍了从BDS阶段进入TSL阶段的分水岭是OS Loader启动。

TSL （Transient System Load）是操作系统加载器（OS Loader）执行的第一阶段，在这一阶段OS Loader作为一个UEFI应用程序运行，系统资源仍然由UEFI内核控制。当启动服务的ExitBootServices()服务被调用后，系统进入RunTime阶段。

TSL 阶段之所以称为临时系统，在于它存在的目的就是为操作系统加载器准备执行环境。其中，UEFI shell是这个临时系统的人机交互界面。

但是在EDK2代码汇中查找，发现大多数厂商并没有对OS Loader划分为TSL和RT两个阶段，OS Loader一直作为一个阶段执行到OS启动。即，他们的OS Loader应用程序中并没有执行ExitBootServices()服务，所以整个UEFI应用程序阶段BootService和Runtime Serivice的所有服务均可用。