统一可扩展固件接口(UEFI)规范描述了操作系统和平台固件之间的接口。UEFI之前是可扩展固件接口规范1.10 (EFI)。因此，一些代码和某些协议名称保留了EFI名称。除非另有说明，本规范中的EFI名称可能被认为是UEFI的一部分。
接口采用数据表的形式，其中包含与平台相关的信息，以及OS加载器和OS可用的引导和运行时服务调用。它们共同提供了一个引导操作系统的标准环境。本规范是作为一个纯粹的接口规范设计的。因此，该规范定义了平台固件必须实现的接口和结构集。类似地，该规范定义了操作系统在引导时可能使用的一组接口和结构。固件开发人员如何选择实现所需的元素，或者操作系统开发人员如何选择利用这些接口和结构，这是留给开发人员的实现决策。
该规范的目的是定义一种方法，使操作系统和平台固件仅通信支持操作系统引导过程所必需的信息。这是通过平台和固件提供给操作系统的软件可见接口的正式和完整的抽象规范来实现的。
使用这一正式定义，旨在运行在与受支持的处理器规范兼容的平台上的收缩包装操作系统将能够在各种系统设计上启动，而无需进一步的平台或操作系统定制。该定义还允许平台创新引入新特性和功能，以增强平台的能力，而不需要按照操作系统的引导顺序编写新代码。
此外，抽象规范开辟了一条替代遗留设备和固件代码的路径。新的设备类型和相关代码可以通过相同定义的抽象接口提供同等的功能，同样不会影响OS引导支持代码。
该规范适用于从移动系统到服务器的所有硬件平台。该规范提供了一组核心服务以及一组协议接口。协议接口的选择可以随着时间的推移而发展，并针对不同的平台市场细分进行优化。与此同时，该规范允许oem提供最大限度的可扩展性和定制能力，以实现差异化。在这方面，UEFI的目的是定义一个从传统的“PC-AT”风格的引导世界到一个没有遗留api的环境的进化路径。
1.1 UEFI驱动模型扩展
通过一组协议接口提供对引导设备的访问。UEFI驱动模型的一个目的是提供“PC-AT”风格的选项rom的替代。需要指出的是，写入UEFI驱动模型的驱动程序是为了在预启动环境中访问启动设备而设计的。它们不是设计来取代高性能的、特定于操作系统的驱动程序的。
UEFI驱动模型的设计是为了支持在预启动环境中运行的模块代码块，也称为驱动程序的执行。这些驱动程序可以管理或控制平台上的硬件总线和设备，或者它们可以提供一些软件派生的、特定于平台的服务。
UEFI驱动模型还包含了UEFI驱动编写器设计和实现任何总线驱动和设备驱动的组合所需的信息，一个平台可能需要启动一个兼容UEFI的操作系统。
UEFI驱动模型被设计为通用的，可以适应任何类型的总线或设备。UEFI规范描述了如何编写PCI总线驱动程序、PCI设备驱动程序、USB总线驱动程序、USB设备驱动程序和SCSI驱动程序。提供了额外的细节，允许UEFI驱动程序存储在PCI选项ROM中，同时保持与遗留选项ROM图像的兼容性。
在UEFI规范的设计目标之一是保持驱动器图像尽可能小。然而，如果一个驱动程序需要支持多个处理器体系结构，那么还需要为每个受支持的处理器体系结构提供一个驱动程序对象文件。为了解决这个空间问题，本规范还定义了EFI字节码虚拟机。UEFI驱动程序可以编译为单个EFI字节码对象文件。UEFI规范投诉固件必须包含一个EFI字节码解释器。这允许提供一个支持多个处理器架构的EFI字节码对象文件。另一种节省空间的技术是使用压缩。本规范定义了压缩和解压算法，可用于减少UEFI驱动程序的大小，从而减少在ROM设备中存储UEFI驱动程序时的开销。
包含在UEFI规范中的信息可以被osv、ihv、oem和固件供应商用来设计和实现符合该规范的固件，产生标准协议接口的驱动程序，以及可以用来引导符合UEFI的操作系统的操作系统加载器。
1.2 组织
本规范主要介绍内容如下：
| 章节 | 描述 |
| 引言与概述 | 介绍了一下UEFI规范并描述了UEFI的主要构成 |
| 启动管理 | 管理器用来加载驱动程序和应用程序编写到这个规范。 |
| EFI系统表和分区 | 描述传递给每个兼容的驱动程序和应用程序的EFI系统表，并定义一个基于指南的分区方案。 |
| 块转换表 | 一种用于块I/O的布局和规则集，它提供单个块的电源故障写原子性。 |
| 启动服务 | 包含在引导操作系统之前出现在符合uefi的系统中的基本服务的定义。 |
| 运行时服务 | 包含在引导操作系统之前和之后出现在兼容系统中的基本服务的定义。 |
| 协议 | •EFI加载图像协议描述已加载到内存的UEFI图像。 •设备路径协议提供了在UEFI环境中构建和管理设备路径所需的信息。 •UEFI驱动模型描述了一组服务和协议，适用于每个总线和设备类型。 控制台支持协议定义了I/O协议，处理系统用户在启动服务环境中执行的基于文本的信息的输入和输出。 •媒体访问协议定义了加载文件协议，文件系统格式和媒体格式处理可移动媒体。 •PCI总线支持协议定义PCI总线驱动程序，PCI设备驱动程序和PCI选项ROM布局。所描述的协议包括PCI根桥I/O协议和PCI I/O协议。 •SCSI驱动程序模型和总线支持定义了SCSI I/O协议和扩展SCSI Pass Thru协议，用于抽象访问由SCSI主机控制器产生的SCSI通道。 •iSCSI协议定义了通过TCP/IP传输SCSI数据。 USB支持协议定义了USB总线驱动程序和USB设备驱动程序。 •调试器支持协议描述了一组可选的协议，提供所需的服务，以实现一个源级调试器的UEFI环境。 •压缩算法规范详细描述了压缩/解压缩算法，外加一个标准的EFI解压缩接口，用于启动时使用。 •ACPI协议可用于从平台上安装或删除ACPI表。 •字符串服务:Unicode排序协议允许在启动服务环境中运行的代码对给定语言的Unicode字符串执行词法比较函数;正则表达式协议用于根据正则表达式模式匹配Unicode字符串。 |
| EFI字节码虚拟机 | 定义EFI字节码虚拟处理器及其指令集。它还定义了如何将EBC对象文件加载到内存中，以及从本机代码到EBC代码再转换到本机代码的机制。 |
| 固件更新和报告 | 为提供固件管理支持的设备提供抽象。 |
| 网络协议 | •SNP、PXE、BIS和HTTP启动协议定义了在UEFI启动服务环境中执行时提供对网络设备访问的协议。 •受管网络协议定义了EFI受管网络协议，它提供原始(未格式化)异步网络数据包I/O服务和托管网络服务绑定协议，用于定位MNP驱动支持的通信设备。 •VLAN、EAP、Wi-Fi和Supplicant协议定义了一个协议，为VLAN配置提供可管理性接口。 •蓝牙协议定义。 •TCP、IP、PIPsec、FTP、GTLS和Configurations协议定义了EFI TCPv4 (Transmission Control Protocol version 4)协议和EFI IPv4 (Internet Protocol version 4)协议。 •ARP、DHCP、DNS、HTTP和REST协议定义了ARP (Address Resolution Protocol)协议接口和EFI DHCPv4协议。 •udp和MTFTP协议定义了EFI UDPv4 (User Datagram Protocol version 4)协议，该协议在EFI IPv4协议上接口，并定义了EFI MTFTPv4协议接口，该接口建立在EFI UDPv4协议之上。 |
| 安全引导和驱动程序签名 | 介绍Secure Boot和生成UEFI数字签名的方法。 |
| 人机界面基础设施(HII) | •定义实现人机接口基础设施(HII)所需的核心代码和服务，包括管理用户输入和相关协议的代码定义的基本机制。 •描述用于管理系统配置的数据和api:描述旋钮和设置的实际数据。 |
| 用户标识 | 描述描述平台当前用户的服务。 |
| 安全技术 | 描述用于利用安全技术的协议，包括加密散列和密钥管理。 |
| 各种各样的协议 | Timestamp协议提供了一个独立于平台的接口来检索高分辨率的时间戳计数器。当调用ResetSystem时，重置通知协议提供注册通知的服务。 |
| 附录 | •guid和时间格式。 •基于基本文本的控制台要求，符合efi系统需要提供通信能力。 •设备路径使用数据结构的例子，定义各种硬件设备的引导服务。 •状态代码列出了UEFI接口返回的成功、错误和警告代码。 •通用网络驱动程序接口定义了32/64位硬件和软件通用网络驱动程序接口(UNDIs)。 •使用简单指针协议。 •使用EFI扩展SCISI直通协议。 •压缩源代码的一个压缩算法的实现。 •一个EFI解压缩算法的实现的解压源代码。 •EFI字节码虚拟机操作码列表提供了相应指令集的摘要。 •字母功能列表按字母顺序标识所有UEFI接口功能。 •EFI 1.10协议变更和折旧清单标识了协议、GUID、修订标识符名称变更以及与EFI 1.10规范相比已弃用的协议。 •格式:语言代码和语言代码数组列出了语言代码和语言代码数组的格式。 •平台错误记录描述了用于表示平台硬件错误的常见平台错误记录格式。 •UEFI ACPI Data Table定义了UEFI ACPI表格式。 •硬件错误记录持久性使用。 •引用 •术语表 |
| 指数 | 提供规范中关键术语和概念的索引。 |
1.3 目标
“PC-AT”启动环境对行业内的创新提出了重大挑战。每一个新的平台功能或硬件创新都要求固件开发人员设计越来越复杂的解决方案，并且通常要求操作系统开发人员修改引导代码，然后客户才能从创新中受益。这可能是一个耗时的过程，需要大量的资源投资。
UEFI规范的主要目标是定义一个替代引导环境，可以减轻这些考虑。在这个目标中，该规范类似于其他现有的引导规范。本规范的主要属性可以概括为以下属性:
•一致的、可扩展的平台环境。该规范为固件定义了一个完整的解决方案，以描述所有平台特性和OS的表面平台功能在引导过程中。这些定义非常丰富，足以涵盖一系列当代处理器设计。
•从固件中抽象操作系统。该规范定义了平台功能的接口。通过使用抽象接口，该规范允许在构建OS加载器时，对这些接口下的平台和固件的了解要少得多。这些接口代表了底层平台和固件实现与操作系统加载程序之间定义良好的稳定边界。这样的边界允许底层固件和操作系统加载程序更改，前提是两者都将交互限制在定义的接口上。
•合理的设备抽象，不需要遗留接口。“PC-AT”BIOS接口要求操作系统加载程序对某些硬件设备的工作有特定的了解。该规范为OS加载器开发人员提供了一些不同的东西:抽象接口使构建代码能够在一系列底层硬件设备上工作，而不需要明确了解该范围内每个设备的细节。
•从固件中提取选项ROM。该规范定义了平台功能的接口，包括PCI、USB和SCSI等标准总线类型。受支持的总线类型列表可能会随着时间的推移而增长，因此包含了扩展到未来总线类型的机制。这些定义的接口，以及扩展到未来总线类型的能力，是UEFI驱动模型的组成部分。UEFI驱动模型的一个目的是解决现有“PC-AT”选项rom中存在的广泛问题。像操作系统加载器一样，驱动程序使用抽象接口，因此设备驱动程序和总线驱动程序可以在构建这些接口的基础平台和固件的知识少得多的情况下构建。
•架构上共享的系统分区。扩展平台功能和添加新设备的计划通常需要软件支持。在许多情况下，当这些平台创新在操作系统控制平台之前被激活时，它们必须由特定于平台而不是客户选择的操作系统的代码来支持。解决这个问题的传统方法是在制造期间在平台中嵌入代码(例如，在闪存设备中)。对这种持久存储的需求正在快速增长。该规范定义了大型海量存储媒体类型上的持久存储，供平台支持代码扩展使用，以补充传统方法。规范中明确了这一工作方式的定义，以确保固件开发人员、oem、操作系统供应商甚至第三方可以安全地共享空间，同时添加平台功能。
可以通过多种方式定义提供这些属性的引导环境。实际上，在编写本规范时已经存在几个替代方案，从学术角度来看可能是可行的。然而，鉴于当前围绕受支持的处理器平台的基础设施功能，这些替代方案通常存在很高的进入壁垒。本规范的目的是交付上面列出的属性，同时也认识到一个行业的独特需求，该行业在兼容性方面有相当大的投资，并有大量不能轻易放弃的系统安装基础。这些需求驱动了本规范中包含的附加属性的需求:
•渐进，而非革命。规范中的接口和结构旨在尽可能地减少初始实现的负担。虽然已经小心翼翼地确保在接口本身中维护适当的抽象，但该设计还确保可以重用BIOS代码来实现接口，而只需要最少的额外编码工作。换句话说，在PC-AT平台上，规范最初可以作为基于现有代码的底层实现之上的瘦接口层来实现。同时，抽象接口的引入为将来从遗留代码迁移提供了条件。一旦抽象被确定为固件和OS加载程序在引导期间交互的手段，开发人员就可以随意替换抽象接口下的遗留代码。也可以对硬件遗留进行类似的迁移。由于抽象隐藏了设备的细节，因此可以删除底层硬件，并用提供改进的功能、降低的成本或两者兼备的新硬件取而代之。显然，这需要编写新的平台固件来支持设备，并通过抽象接口将其呈现给操作系统加载器。然而，如果没有接口抽象，删除遗留设备可能根本不可能。
•设计兼容性。系统分区结构的设计还保留了当前在“PC-AT”引导环境中使用的所有结构。因此，构建能够从同一个磁盘引导遗留操作系统或支持efi的操作系统的单个系统是一件很简单的事情。
简化os中立平台增值的加法。该规范定义了一个开放的、可扩展的接口，用于创建平台“驱动程序”。它们可能类似于OS驱动程序，在引导过程中提供对新设备类型的支持，或者它们可能用于实现增强的平台功能，比如容错或安全性。此外，这种扩展平台功能的能力从一开始就被设计到规范中。这旨在帮助开发人员避免将新代码压缩到传统BIOS环境中所固有的许多困难。由于包含了添加新协议的接口，oem或固件开发人员拥有了以模块化方式向平台添加功能的基础设施。由于规范中定义的调用约定和环境，这样的驱动程序可能会使用高级编码语言实现。这反过来可能有助于降低创新的难度和成本。系统分区的选项为这种扩展提供了非易失性内存存储的替代方案。
•以现有投资为基础。在可能的情况下，该规范避免在现有行业规范提供足够覆盖的领域中重新定义接口和结构。例如，ACPI规范为操作系统提供了发现和配置平台资源所需的所有信息。同样，这种对规范设计的哲学选择是为了尽可能降低其采用的障碍。
1.4 目标受众
本文档主要适用于以下读者:
•IHVs和OEMs将实施UEFI驱动器。
•OEM将创建受支持的处理器平台，旨在引导收缩包装操作系统。
•BIOS开发人员，可以是那些创建通用BIOS和其他固件产品的人，也可以是那些修改这些产品以在支持的基于处理器的产品中使用的人。
•操作系统开发人员将调整他们的收缩包装操作系统产品，以在支持的基于处理器的平台上运行。
1.5 UEFI开发综述
UEFI的设计基于以下基本要素:
•重用现有的基于表的接口。为了保持对现有基础设施支持代码的投资，在操作系统和固件中，许多现有规范通常在与受支持的处理器规范兼容的平台上实现，必须在希望遵守UEFI规范的平台上实现。(更多信息请参见附录Q:参考文献。)
•系统分区。系统分区定义了一个分区和文件系统，这些分区和文件系统被设计为允许在多个供应商之间出于不同目的进行安全共享。包含独立的、可共享的系统分区的能力提供了一个机会，可以在不显著增加非易失性平台内存需求的情况下增加平台价值。
•引导服务。引导服务为在引导期间使用的设备和系统功能提供接口。设备访问通过“句柄”和“协议”抽象。通过将底层实现需求排除在规范之外，而不增加消费者访问设备的负担，这有助于重用对现有BIOS代码的投资。
•运行时服务。提供了最小的运行时服务集，以确保适当地抽象操作系统在其正常操作期间可能需要的基础平台硬件资源。
UEFI的主要组成部分及其与平台硬件和操作系统软件的关系如图1-1所示。
图1-1说明了用于完成平台和OS引导的UEFI规范兼容系统的各个组件之间的交互。
平台固件能够从系统分区检索OS加载器映像。该规范提供了各种大容量存储设备类型，包括磁盘、CD-ROM和DVD，以及通过网络进行远程引导。通过可扩展的协议接口，可以添加其他引导媒体类型，尽管如果它们需要使用本文档中定义的其他协议，则可能需要修改操作系统加载器。
一旦启动，操作系统加载程序继续引导整个操作系统。为此，它可以使用EFI引导服务和由本规范或其他必需规范定义的接口来调查、理解和初始化各种平台组件和管理它们的操作系统软件。在引导阶段，EFI运行时服务也可用于OS加载程序。
1.6 UEFI驱动模型
本节描述符合本规范的固件驱动模型的目标。这个驱动模型的目标是为所有类型的总线和设备提供一种实现总线驱动和设备驱动的机制。在编写时，支持的总线类型包括PCI、USB等。
随着硬件架构的不断发展，平台中总线的数量和类型也在不断增加。这种趋势在高端服务器上尤其明显。然而，越来越多的总线类型被设计到桌面系统和移动系统，甚至一些嵌入式系统中。这种日益增加的复杂性意味着在预引导环境中需要一种简单的方法来描述和管理平台中的所有总线和设备。UEFI驱动模型以协议服务和引导服务的形式提供了这种简单的方法。
1.6.1 UEFI驱动模型目标
UEFI驱动模型有以下目标:
•兼容-符合此规范的驱动程序必须保持与EFI 1.10规范和UEFI规范的兼容性。这意味着UEFI驱动模型利用了UEFI 2中的可扩展机制。0规格来添加所需的功能。
•简单-符合本规范的驱动程序必须易于实现和维护。UEFI驱动模型必须允许驱动程序编写器集中于驱动程序正在开发的特定设备。驱动程序不应该关心平台策略或平台管理问题。这些考虑应该留给系统固件。
•可扩展- UEFI驱动模型必须能够适应所有类型的平台。这些平台包括嵌入式系统、移动和桌面系统，以及工作站和服务器。
•灵活- UEFI驱动模型必须支持枚举所有设备的能力，或枚举仅那些设备需要启动所需的操作系统。最小设备枚举提供了对更快速引导能力的支持，而完整设备枚举提供了在系统中存在的任何引导设备上执行OS安装、系统维护或系统诊断的能力。
•可扩展- UEFI驱动模型必须能够扩展到未来的总线类型，因为它们是定义的。
•可移植-写入UEFI驱动模型的驱动程序必须在平台之间和支持的处理器架构之间是可移植的。
•互操作-驱动程序必须与其他驱动程序和系统固件共存，并且必须在不产生资源冲突的情况下这样做。
•描述复杂的总线层次结构- UEFI驱动模型必须能够描述各种总线拓扑，从非常简单的单一总线平台到包含多种类型的总线的非常复杂的平台。
•小的驱动占用- UEFI驱动模型产生的可执行文件的大小必须最小化，以降低整体平台成本。虽然灵活性和可扩展性是目标，但必须将支持这些所需的额外开销保持在最低限度，以防止固件组件的大小变得难以管理。
•解决遗留选项rom问题- UEFI驱动模型必须直接解决和解决遗留选项rom的约束和限制。具体地说，必须有可能构建支持UEFI驱动程序和遗留选项rom的插件卡，这样的卡可以在遗留的BIOS系统和符合UEFI的平台中执行，而无需修改卡上的代码。该解决方案必须提供从遗留选项rom驱动程序迁移到UEFI驱动程序的演进路径。
1.6.2遗留选项ROM问题
支持驱动器模型的想法来自于UEFI规范的反馈，该规范为遗留选项ROM(有时也称为扩展ROM)的替代提供了一个清晰的、市场驱动的需求。人们的看法是，UEFI规范的出现代表了一个机会，通过在UEFI规范框架内工作的替代机制来替代遗留选项ROM映像的构建和操作中隐含的限制。
1.7迁移要求
迁移需求涵盖了从该规范的初始实现到未来所有平台和操作系统都实现该规范的过渡阶段。在此期间，有两个重要的兼容性考虑事项:
•能够继续启动遗留操作系统;
•通过重用尽可能多的现有固件代码，在现有平台上实现UEFI的能力，以将开发资源和时间要求降至最低。
1.7.1遗留操作系统支持
UEFI规范代表了压缩包操作系统和固件在引导过程中进行通信的首选方法。然而，选择一个符合该规范的平台并不意味着该平台就不能支持不了解UEFI规范的现有遗留OS二进制文件。
UEFI规范并不限制选择同时支持UEFI规范和更传统的“PC-AT”引导基础设施的平台设计人员。如果要实现这样的遗留基础设施，那么应该按照在本规范范围之外定义的现有行业实践来开发它。选择在任何给定平台上受支持的遗留操作系统是由该平台的制造商决定的。
1.7.2在遗留平台上支持UEFI规范
UEFI规范经过精心设计，允许对现有系统进行扩展，以最少的开发工作量支持它。特别是，在UEFI规范中定义的抽象结构和服务都可以在遗留平台上得到支持。
例如，要在使用传统BIOS支持操作系统引导的现有和受支持的32位平台上实现这种支持，需要提供一个附加的固件代码层。将服务和设备的现有接口转换为支持本规范中定义的抽象需要这些额外的代码。
1.8文档约定
本文档使用下面描述的排版和说明性约定。
1.8.1数据结构描述
受支持的处理器是“小端”机器。这种区别意味着内存中多字节数据项的低阶字节位于最低地址，而高阶字节位于最高地址。一些受支持的64位处理器可以同时配置为“小端序”和“大端序”操作。所有为符合该规范而设计的实现都使用“小端序”操作。
在某些内存布局描述中，某些字段被标记为保留字段。软件必须将这些字段初始化为零，并在读取时忽略它们。在更新操作中，软件必须保留任何保留字段。
1.8.2协议描述
协议描述一般有以下格式:
协议名称:协议接口的正式名称。
摘要:协议接口的简要描述。
GUID:协议接口的128位GUID (Globally Unique Identifier)。
协议接口结构:一种“c风格”的数据结构定义，包含由该协议接口产生的过程和数据字段。
参数:协议接口结构中各字段的简要说明。
描述:对接口提供的功能的描述，包括调用者应该知道的任何限制和警告。
相关定义:协议接口结构或其任何过程中使用的类型声明和常量。
1.8.3过程描述
过程描述一般有以下格式:
ProcedureName():过程的正式名称。
摘要:对程序的简要描述。
范例:定义调用序列的“C-style”过程头。
参数:过程原型中每个字段的简要描述。
描述:对接口提供的功能的描述，包括调用者应该知道的任何限制和警告。
相关定义:仅由此过程使用的类型声明和常量。
返回状态代码:接口返回的任何代码的描述。实现表中列出的任何状态代码都需要这个过程。可能会返回额外的错误码，但标准遵从性测试不会对这些错误码进行测试，并且使用该过程的任何软件都不能依赖于实现可能提供的任何扩展错误码。
1.8.4指令描述
EBC指令的指令描述一般有以下格式:
InstructionName:指令的正式名称。
语法:对指令的简要描述。
描述:指令所提供的功能描述，并附有详细说明指令编码的表格。
操作:详细描述对操作数执行的操作。
行为和限制:对指令中涉及的每个操作数的行为以及对操作数或指令的任何限制的逐项描述。
1.8.5伪代码约定
提出了伪代码，以更简洁的形式描述算法。本文档中的算法都不是直接编译的。代码以对应于周围文本的级别呈现。
在描述变量时，列表是同构对象的无序集合。队列是同构对象的有序列表。除非另有说明，否则假定顺序为FIFO。
伪代码以类似C的格式显示，在适当的地方使用C约定。编码风格，特别是缩进风格，用于提高可读性，并不一定符合UEFI规范的实现。
1.8.6排版约定
本文档使用的排版和说明性约定如下:
纯文本 标准文本字体用于规范中的绝大多数描述性文本。
纯文本(蓝色) 任何带下划线和蓝色的纯文本表示到交叉引用的活动链接。点击单词跟随超链接。
粗体 在文本中，粗体字体标识处理器寄存器名称。在其他情况下，粗体可以用作段落的开头。
斜体 在文本中，斜体字体可用于强调引入新术语或指示手册或规范名称。
BOLD Monospace 计算机代码、示例代码段和所有原型代码段使用BOLD Monospace字体，颜色为深红色。这些代码列表通常出现在一个或多个单独的段落中，但单词或段也可以嵌入到正常的文本段落中。
Bold Monospace 粗体Monospace字体中带下划线并以蓝色显示的字表示指向该函数或类型定义的代码定义的活动超链接。点击单词跟随超链接。
注意:由于管理和文件大小的考虑，只有在每个页面上第一次出现的引用是一个活动链接。在同一页上的后续引用将不会主动链接到定义，并将使用标准的、无下划线的BOLD Monospace字体。在页面上找到该名称的第一个实例(带下划线的BOLD Monospace字体)，然后单击该单词跳转到函数或类型定义。
Italic Monospace 在代码或文本中，用斜体Monospace表示必须提供的变量信息(即参数)的占位符名称。
1.8.7数字格式
在这个标准中，二进制数由仅由西方阿拉伯数字0和1紧跟着小写b(例如，0101b)组成的任何数字序列表示。
下划线或空格可以包含在二进制数字表示的字符之间，以增加可读性或划定字段边界(例如，0 0101 1010b或0_0101_1010b)。
1.8.7.1十六进制
在本标准中，一个十六进制数以0x表示，在任何数字序列之前只包含西方阿拉伯数字0到9和/或大写英文字母A到F(例如0xFA23)。
下划线或空格可以包含在十六进制数字表示的字符之间，以增加可读性或划定字段边界(例如，0xB FD8C FA23或0xB_FD8C_FA23)。
1.8.7.2小数
在这一标准中，十进制数字由仅由阿拉伯数字0到9组成的任何数字序列表示，而不是紧跟小写b或小写h(例如，25)。
本标准使用以下约定来表示十进制数:
•小数分隔符(即，分隔数字的整数和小数部分)是一个句点;
•千位分隔符(即在数字的一部分中分隔三组数字)是逗号;
•千位分隔符用于整数部分，而不用于数字的小数部分。
1.8.8二进制前缀
本标准使用国际单位制(SI)中定义的前缀来表示十的幂值。请参阅标题“Links to UEFI-Related Documents “相关文档链接”(http://uefi.org/uefi)。
Table 1-1 SI prefixes
| 103 | 1,000 | kilo | K |
| 106 | 1,000,000 | mega | M |
| 109 | 1,000,000,000 | giga | G |
本标准使用ISO/IEC 80000-13《数量和单位——第13部分:信息科学与技术》和IEEE 1514《二元倍数前缀标准》中定义的二进制前缀，用于2的幂值。
Table 1-2 Binary prefixes
| Factor | Factor | Name | Symbol |
| 210 | 1,024 | kibi | Ki |
| 220 | 1,048,576 | mebi | Mi |
| 230 | 1,073,741,824 | gibi | Gi |
例如，4KB表示4000字节，而4KiB表示4096字节。
1.8.9修订数字
UEFI规范的更新被认为是新的修订或勘误表，如下所述:
•当有实质性的新内容或可能改变现有行为的变化时，产生新的修订。新的修订是由专业指定的。次要版本号(例如xx.yy)。在变化非常小的情况下，我们可以使用major.minor.minor命名约定(例如xx.yy.zz)。
•当批准的规范更新中不包括任何重要的新材料或对现有行为的修改时，则生成勘误表版本。勘误表是通过在版本号末尾添加一个大写字母来指定的，例如xx。yy勘误表。
扫一扫
2184
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
