UEFI Spec 学习笔记章节一

BIOS菜鸟工程师

已于 2024-09-23 22:59:32 修改

阅读量589

点赞数 10

分类专栏： UEFI 文章标签：网络

于 2024-09-23 15:33:36 首次发布

本文链接：https://blog.csdn.net/JUSTIN_TYL/article/details/142459485

版权

UEFI 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

1 - Introduction

本规范描述了操作系统与平台固件之间的接口。UEFI 是 EFI 的升级接口规范，所以中间也就包含了一些 EFI 的代码和 protocol，没有特殊说明EFI也可以看作是 UEFI 的一部分。

UEFI 定义了一系列功能接口和结构包含在一个个数据链表中，中间包含：

在 boot 过程中或则是 Runtime 阶段可能被 OS loader 和 OS 用到的服务。
平台相关的信息。
平台固件必须实现的接口以及结构。
可以供平台固件工程师和系统工程师来选择的接口以及结构。

通过定义一个正式完整的由平台和固件提供给系统的接口，使得系统和平台固件只需要交互必要的信息。同时只要是接口满足此规范，则对于任何满足处理器兼容规范的处理器，可以移植到任意平台，而不需要更多的代码移植和客制化。

规范覆盖移动端到服务器端，可以根据不同的市场划分选择不同的接口；而且可以随着技术更新扩展对应的接口，从而实现无遗留API。

1.1 UEFI Driver Model Extensions

UEFI Driver Model 主要是用于实现一下四个作用：

访问与启动环境中的引导设备：UEFI Driver 通过一系类的协议接口来访问设备，用于替代对于设备 OptionRom 的访问，而不是用于取代系统中的驱动程序。
实现模块化代码：可以控制平台上总线、设备、软件派生的或是平台特定的服务。
兼容 legacy 的设计：UEFI driver model 被设计为通用的，任意的 bus、driver 以及 device 支持，同时也可以保存在 PCI option Rom 之中，兼容 legacy option rom.
减小 Driver 的 size：UEFI 的设计目的中还包括使 driver size 尽可能的减小，但有得 driver 又需要同时兼容多个处理器架构（比如 ARM、 IA32 等），所以 UEFI 定义了一个 EFI Byte Code Virtual Machine（EFI 虚拟字节码机制），单个 UEFI driver 可以编译成单个对象文件，所以 UEFI 平台必须有一个EFI Byte Code 译码器。此外就是通过压缩 driver 来节省空间，UEFI 定义了自己的压缩算法。

1.5 UEFI Design Overview

Reuse of existing table-based interfaces：无论是在系统还是固件中，现有的基于特定处理实现的规范都希望遵循 UEFI spec。
System partition：UEFI 定义的系统分区和文件系统允许不同厂商，不同作用的设备进行安全的数据共享。这个特性可以增加平台的附加价值，而且不需要额外的非易失性平台内存，比如 SPI ROM（用于存放 BIOS 的额）。
Boot services:Boot services 为设备和系统功能提供在 boot 阶段使用的接口。设备访问通过抽象的 handle 和 protocol。这个功能通过使用已有的 BIOS 来实现底层逻辑，从而不需要增加用户访问的负担。
Runtime services：提供最小 runtime 服务用于确保在 OS 正常操作时需要的平台硬件资源抽象。

下图说明了UEFI规范兼容系统中用于完成平台和操作系统引导的各个组件之间的相互作用

1.6 UEFI Driver Model

本节描述符合此规范的固件驱动程序模型的目标。这个驱动模型的目标是为所有类型的总线和设备提供一种实现总线驱动和设备驱动的机制。在撰写本文时，支持的总线类型包括PCI、USB等。随着硬件架构的不断发展，平台中存在的总线数量和类型也在不断增加。这一趋势在高端服务器中尤为明显。然而，一套更加多样化的总线类型正在被设计到桌面和移动系统，甚至一些嵌入式系统中。这种日益增加的复杂性意味着在预启动环境中需要一种简单的方法来描述和管理平台中的所有总线和设备,UEFI Driver Model以protocols services 和boot services 的形式提供了这种简单的方法。

1.6.1 UEFI Driver Model Goals

UEFI驱动模型有以下目标:

兼容-符合此规范的驱动程序必须保持与EFI的兼容性1.10规范和UEFI规范。这意味着UEFI驱动模型利用了UEFI 2中的可扩展性机制。O规范中添加了所需的功能。
简单-符合此规范的驱动程序必须易于实现和维护。UEFI驱动模型必须允许驱动程序编写人员专注于正在开发驱动程序的特定设备。驱动程序不应该关心平台策略或平台管理问题。这些考虑应该留给系统固件。
可扩展- UEFI驱动模型必须能够适应所有类型的平台。这些平台包括嵌入式系统、移动和桌面系统，以及工作站和服务器。
灵活- UEFI驱动模型必须支持枚举所有设备的能力，或者只枚举启动所需OS所需的设备。最小设备枚举提供了对更快速引导能力的支持，完整设备枚举提供了在系统中存在的任何引导设备上执行OS安装、系统维护或系统诊断的能力。
可扩展- UEFI驱动模型必须能够扩展到未来的总线类型，因为它们被定义。
可移植-写入UEFI驱动模型的驱动程序必须在平台和支持的处理器架构之间可移植。
可互操作-驱动程序必须与其他驱动程序和系统固件共存，并且必须在不产生资源冲突的情况下这样做。
描述复杂的总线层次结构——UEFI驱动模型必须能够描述各种总线拓扑结构，从非常简单的单一总线平台到包含许多不同类型总线的非常复杂的平台。
驱动程序占用空间小——UEFI驱动模型产生的可执行文件的大小必须最小化，以降低整体平台成本。虽然灵活性和可扩展性是目标，但支持这些所需的额外开销必须保持在最低限度，以防止固件组件的大小变得无法管理。
解决遗留选项rom问题- UEFI驱动模型必须直接处理和解决遗留选项rom的约束和限制。具体来说，必须有可能构建既支持UEFI驱动程序又支持legacy option rom的插件卡，这样的插件卡可以在传统BIOS系统和UEFI兼容平台上运行，而无需修改卡上携带的代码。解决方案必须提供从legacy option rom驱动程序迁移到UEFI驱动程序的演进路径。

1.6.2遗留选项ROM问题

这种支持驱动程序模型的想法来自UEFI规范，该规范为传统选项RoM(有时也称为扩展ROM)的替代方案提供了明确的，市场驱动的需求。人们的看法是，UEFI规范的出现代表了一个机会，可以通过在UEFI规范框架内工作的替代机制取代传统选项ROM映像的构建和操作中隐含的限制。

1.7迁移要求

迁移需求涵盖了从最初实施本规范到未来所有平台和操作系统实施本规范的过渡期。在此期间，两个主要的兼容性考虑因素很重要:

继续启动遗留操作系统的能力;
通过重用尽可能多的现有固件代码，在现有平台上实现UEFI的能力，从而将开发资源和时间要求降至最低。

1.7.1旧版操作系统支持

UEFI规范代表了在引导过程中封装OS和固件通信的首选方法。但是，选择制作符合此规范的平台并不妨碍平台支持不了解UEFI规范的现有legacy OS binaries。UEFI规范并不限制平台设计人员选择同时支持UEFI规范和更传统的“PC-AT”引导基础设施。如果要实现这样的遗留基础设施，则应根据本规范范围之外定义的现有行业实践进行开发。在任何给定平台上支持的遗留操作系统的选择留给该平台的制造商。

1.7.2在传统平台上支持UEFI规范

UEFI规范经过精心设计，允许以最小的开发工作量扩展现有系统以支持它。特别是，UEFI规范中定义的抽象结构和服务都可以在传统平台上得到支持。

例如，要在使用传统BIOS支持操作系统启动的现有且受支持的32位平台上完成这样的支持，就需要提供额外的固件代码层。这个额外的代码将需要将服务和设备的现有接口转换为对本规范中定义的抽象的支持。

1.8. 移植要求迁移需求

涵盖了从最初实现本规范到将来所有平台和操作系统实现本规范的过渡时期。在此期间，两个主要的兼容性考虑是重要的:

能够继续引导遗留操作系统;
通过重用尽可能多的现有固件代码，在现有平台上实现UEFI的能力，从而将开发资源和时间要求降至最低。

1.8.1. 旧版操作系统支持

UEFI规范代表了在引导过程中封装操作系统和固件通信的首选方式。然而，选择制作一个符合此规范的平台并不妨碍该平台也支持不了解UEFI规范的现有遗留操作系统二进制文件。UEFI规范并不限制平台设计人员选择同时支持UEFI规范和更传统的“PC-AT”引导基础设施。如果要实现这样的遗留基础设施，则应该根据在本规范范围之外定义的现有行业实践来开发它。选择在任何给定平台上支持的遗留操作系统留给该平台的制造商。

1.8.2. 在传统平台上支持UEFI规范

UEFI规范经过精心设计，允许以最小的开发工作量扩展现有系统以支持它。特别是，UEFI规范中定义的抽象结构和服务都可以在传统平台上得到支持。

例如，要在使用传统BIOS支持操作系统引导的现有且受支持的32位平台上实现这种支持，需要提供额外的固件代码层。为了将服务和设备的现有接口转换为对本规范中定义的抽象的支持，将需要这些额外的代码。

1.9. 本文档中的约定

本文档使用下面描述的排版和说明性约定。

1.9.1. 数据结构描述

支持的处理器是“小端”机器。这种区别意味着内存中多字节数据项的低阶字节位于最低地址，而高阶字节位于最高地址。一些支持的64位处理器可以配置为“小端”和“大端”操作。所有符合此规范的实现都使用“小端”操作。

在一些内存布局描述中，某些字段被标记为保留。软件必须将这些字段初始化为零，并在读取时忽略它们。在更新操作中，软件必须保留任何保留字段。

1.9.2. 协议描述

协议描述通常有以下格式:

协议名称:协议接口的正式名称。

摘要:对协议接口的简要描述。

GUID: 128位的协议接口GUID (global Unique Identifier)。

协议接口结构:一种“c风格”的数据结构定义，包含由该协议接口产生的过程和数据字段。

参数:对协议接口结构中各字段的简要描述。

描述:对接口提供的功能的描述，包括调用者应该知道的任何限制和警告。

相关定义:在协议接口结构或其任何过程中使用的类型声明和常量。

1.9.3. 过程描述

过程描述通常有以下格式:

ProcedureName():过程的正式名称。

摘要:对程序的简要描述。

Prototype:一个定义调用序列的“c风格”过程头。

参数:过程原型中每个字段的简要描述。

描述:对接口提供的功能的描述，包括调用者的任何限制和注意事项应该意识到。

相关定义:仅由此过程使用的类型声明和常量。

返回状态码:接口返回的状态码的描述。该过程需要实现任何状态码如下表所示。

可能会返回额外的错误代码，但它们不会通过标准遵从性测试和任何软件进行测试使用该过程的函数不能依赖于实现可能提供的任何扩展错误码。

1.9.5. 伪代码约定

伪代码以更简洁的形式描述算法。本文档中的任何算法都不打算成为直接编译。代码以与周围文本对应的级别呈现。在描述变量时，列表是同构对象的无序集合。队列是同构对象的有序列表。除非另有说明，否则假定顺序为FIFO。伪代码以类似C的格式呈现，在适当的地方使用C约定。编码风格，特别是缩进风格，用于可读性，并不一定符合UEFI规范的实现。