PCI Expansion ROMs
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
目录
一、PCI Expansion ROMs
1. PCI Expansion ROM Contents
1.1 PCI Expansion ROM Header Format
1.2 PCI Data Structure Format
1.3 Device List Format
二、Firmware Power-on Self Test(POST) Firmware
1. PC- compatible Expansioin ROMs(Code Type 0)
1.1 Expansion ROM Header Extensions
1.2 POST Firmware Extensions
1.3 Resizing of Expansion ROMs During INIT
1.4 Image Structure and Length
1.5 Memory Usage
1.6 Verification of BIOS Support
1.7 Permanent Memory
1.8 Temporary Memory
1.9 Memory Locations
1.10 Permanent Memory Size Limits
1.11 Multiple Request for Memory
1.12 Protected Mode
1.13 Run-Time Expansion ROM Size
1.14 Relocation of Expansion ROM Run-time Code
1.15 Expansion ROM Placement Address
1.16 VGA Expansion ROM
1.17 Expansion ROM Placement Alignment
1.18 BIOS Boot Specification
1.19 Extended BIOS Data Area (EBDA) Usage
1.20 POST Memory Manager (PMM) Functions
1.21 Backward Compatibility of Option ROMs
1.22 Option ROM and IRET Handling
1.23 Stack Size Requirement by Expansion ROM
1.24 Configuration Code for Expansion ROM
1.25 DMTF Server Management Command Line Protocol(SM CLP) Support
2. UEFI Exponsion ROM (Type3)
一、PCI Expansion ROMs
传统的PCI本地总线规范提供了一种机制，在这种机制中，设备可以提供可用于特定于设备的初始化和可能的系统引导功能的扩展ROM代码。
介绍这些扩展ROM的格式、内容和代码入口点。同时介绍符合本规范3.0及以上版本的系统固件对扩展盘提供的服务和执行环境。
扩展ROM中的信息与ISA插件卡现有的Intel x86扩展ROM头兼容，但它也将支持其他机器架构。
PCI扩展ROM代码从来没有执行到位。它总是从ROM设备复制到RAM，并从RAM执行(初始化)。初始化后，代码被扩展ROM移动到RAM中的最终执行位置，假设扩展ROM代码符合这个规范，3.0或更高版本。这支持动态调整代码大小(用于初始化和运行时)，并在执行运行时代码时提高速度。
1. PCI Expansion ROM Contents
PCI设备扩展ROM可能包含用于多处理器架构的代码(可执行或解释)。这可以在一个物理ROM中实现，它可以包含不同系统和处理器架构所需的任意多的代码映像(见图5-1)。每个映像必须从512字节的边界开始，并且必须包含PCI Expansion ROM header。每个映像的起始点取决于之前映像的大小。ROM中的最后一幅映像在头文件中有一个特殊的编码来识别它是最后一个映像。
1.1 PCI Expansion ROM Header Format
每个ROM映像所需的信息被分成两个不同的区域。其中一个区域，即ROM头，需要位于ROM映像的开头。第二个区域，PCI数据结构，必须位于映像的前64kb。PCI扩展ROM报头的格式如下所示。偏移量是从映像开始的十六进制数，每个字段的长度以字节为单位给出。
ROM Signature : ROM签名是一个双字节字段，第一个字节包含55h，第二个字节包含AAh。这个签名必须是ROM的每个映像的ROM地址空间的前两个字节。
Pointer to PCI Data Structure: PCI数据结构指针是一个小端格式的两个字节指针，指向PCI数据结构。这个指针的参考点是ROM映像的开始。
1.2 PCI Data Structure Format
PCI数据结构必须位于ROM映像的前64kb内，而且必须是双字对齐。PCI数据结构包含以下信息:
| Signature | 这四个字节为PCI Data提供了一个惟一的签名结构。字符串“PCIR”是“P”在偏移量0 处，“C”在偏移量1处，以此类推。 |
| Vendor Identification | 厂商标识字段为16位字段，与这个设备的配置空间中的厂商标识字段定义相同 |
| Device Identification | 设备标识字段为16位字段，与这个设备配置空间中的设备标识字段定义相同 |
| Device List Pointer | 设备列表指针(Device List Pointer)是一个双字节指针，采用小端格式，指向该ROM支持的设备id列表。该指针的起始参考点(“偏移零”)是PCI数据结构的开始(签名字段的第一个字节)。该字段仅在修订版3.0(及更高版本)PCI数据结构中存在。如果扩展ROM不支持设备列表，该字段的值将为0000h。当“Code Type”字段的值为3 (UEFI)时，该字段必须为0000h。 |
| PCI Data Structure Length | PCI Data Structure Length是一个16位的字段，定义了从数据结构开始的数据结构的长度(签名字段的第一个字节)。该字段采用小端格式，以字节为单位。 |
| PCI Data Structure Revision | PCI Data Structure Revision字段是一个8位字段，用于标识数据结构修订级别。当前规范的修订级别是3。 |
| Class Code | “类码”字段为24位字段，与本设备“配置空间”中的“类码”字段的字段和定义相同。 |
| Image Length | Image Length字段是一个两字节字段，表示映像的长度。该字段为小端格式，单位为512字节。 |
| Revision Level | Revision Level字段是一个双字节字段，包含ROM映像中供应商代码的修订级别。 |
| Code Type | 代码类型字段是一个单字节字段，它标识ROM中包含的代码类型。对于特定的处理器和系统架构或解释代码，代码可以是可执行的二进制代码。分配了以下代码类型:
|
| Last Image Indicator | 该域中的第7位表示这是否是最后的映像，值为1表示“最后一个映像”，值为0表示后面是另一个映像。0-6位被保留。 |
| Maximum Run-Time Image Length | Image Length字段是一个两个字节的字段，表示在执行初始化代码后映像的最大长度。该字段位小端格式，单位为512字节。这个字段将用于确定运行时映像大小是否足够小，适合系统中剩余的内存。该字段仅在PCI数据结构的3.0版及以后版本中出现。 |
| Pointer to Configuration Utility Code Header | 这个指针是一个小端格式的两个字节指针，它指向在5.2.1.24节中描述的配置代码块开始的扩展ROM的配置实用程序代码头表。这个指针的起始参考点(“偏移零”)是扩展ROM映像的开始。该字段仅在修订版3.0(及更高版本)PCI数据结构中存在。如果扩展ROM不支持配置实用程序代码头，则该字段的值为0000h。当“Code Type”字段的值为3 (UEFI)时，该字段必须为0000h。 |
| Pointer to DMTF CLP Entry Point | 这个指针是一个小端格式的两字节指针，它指向这个ROM支持的DMTP CLP代码的执行入口点。这个指针的起始参考点(“偏移零”)是扩展ROM映像的开始。该字段仅在修订版3.0(及更高版本)PCI数据结构中存在。如果扩展ROM不支持第5.2.1.25节中所述的DMTF CLP代码入口点，则该字段中的值为0000h。当“Code Type”字段的值为3 (UEFI)时，该字段必须为0000h。 |
1.3 Device List Format
3.0版本(或更高版本)定义了一个设备列表指针，它指向Code Type不是3 (UEFI)的扩展ROM镜像支持的设备id列表。
这个指针的起始参考点(“偏移零”)是PCI数据结构的开始(签名字段的第一个字节)。如果这个字段不存在(即，它的内容为零)，那么扩展ROM只支持PCI数据结构中设备ID字段中列出的一个特定的设备ID。但是，如果这个字段是非零，那么它必须指向一个设备列表表。该表格式如表5-1所示。
二、Firmware Power-on Self Test(POST) Firmware
本节中关于BIOS (POST firmware)的描述仅与PCI Expansion rom的管理相关。POST固件通过几个步骤来配置PCI扩展ROM。这些步骤描述如下:
- POST固件检查PCI总线拓扑，分别检查每个PCI设备。如果设备在配置空间中实现了Expansion ROM Base Address register，然后POST固件继续下一步。
请注意，多功能PCI设备上的各个功能可能都有一个扩展ROM基本寄存器的实现。
注意，没有定义检查和初始化PCI设备的顺序。 - POST固件使能扩展ROM在一个未使用的内存地址。
- POST固件检查扩展ROM中的前两个字节是否有AA55h签名。如果找到了该签名，则存在ROM。否则，没有ROM被附加到设备上，POST固件继续执行步骤10。
- 如果ROM被附加，POST固件必须在ROM中搜索具有适当代码类型的映像。以下步骤可用于搜索多个映像。
•如果指针有效(非零)，检查指针的目标位置。如果指针无效，则无法定位更多的映像。
•目标位置必须包含签名字符串“PCIR”。如果没有有效的签名，则无法定位更多的映像。
•如果签名字符串是有效的，检查Code Type字段，以确定它对预期的执行环境类型是否正确。(有关更多信息，请参阅Code Type字段条目)。
•如果“Code Type”字段不合适，则BIOS需要按照下一步的描述继续搜索“Images”。如果“Code Type”字段是正确的，则BIOS继续执行下面的步骤5。
•BIOS应该检查“Last Image”字段，以确定是否有更多的映像。如果没有其他映像，BIOS应该继续执行步骤9。
•如果有更多的映像，映像长度字段应该检查，以确定下一个映像的起始位置。映像长度被添加到当前映像的起始地址(不是映像0) - 在选择了正确的映像之后，POST Firmware将验证供应商ID和设备ID字段与设备中对应的字段相匹配。
- 如果厂商ID匹配但设备ID不匹配，POST固件将检查设备列表指针。假设设备列表指针不为零，POST固件将检查设备列表以找到与设备ID匹配的设备。0000h表示设备列表的结束。
请注意，Code Type 3 (UEFI)的扩展rom不支持设备列表指针。对于其他代码类型，只有符合本规范3.0或更高版本的扩展rom支持设备列表指针。POST固件不应该检查设备列表指针字段，直到它确认PCI数据结构修订级别为3或更高。 - 在找到合适的映像之后，POST Firmware决定是否有足够的空间将映像复制到RAM中，以便为初始化做准备。这是通过检查最大运行时映像长度字段来完成的。
请注意，只有符合该规范3.0或更高版本的扩展rom才支持最大运行时映像长度字段。POST固件不应该检查最大运行时图像长度字段，直到它确认PCI数据结构修订级别为3。
请注意，如果映像是PCI 2.1兼容的扩展ROM，则POST固件必须继续检查映像，以确定是否存在符合此规范3.0或更高版本的相同供应商ID和设备ID的扩展ROM。符合本规范2.1或更早版本的扩展ROM只能在无法找到符合本规范3.0或更高版本的扩展ROM时被POST固件使用。 - 系统固件必须在将Option ROM映像复制到RAM之前确认该映像具有有效的校验和。此校验和使用当前映像大小计算，详情见5.2.1.4部分
- 然后，POST固件将适当数量的数据复制到RAM中。要复制的数据量是通过检查头中的PCI数据结构中的Image Length字段来确定的。
- POST固件然后禁用Expansion ROM Base Address register。
后续步骤将根据“代码类型”字段的值有所不同。
1. PC- compatible Expansioin ROMs(Code Type 0)
本节描述POST固件在处理时执行的其他步骤“Code Type”字段值为0的ROM镜像，表示该镜像为Intel x86兼容PC。
1.1 Expansion ROM Header Extensions
PCI扩展ROM图像的标准头为pc兼容性稍作扩展(代码类型0).代码类型0头使用偏移量03h作为扩展ROMINIT函数的入口点。
1.2 POST Firmware Extensions
POST固件将整个扩展ROM映像复制到RAM地址，如上所述。RAM地址的变化取决于扩展ROM是否将自己标识为符合该规范3.0或更高版本。(PCI数据结构中的Revision字段值为03h表示符合。)
如果扩展ROM是兼容的，那么POST 固件将遵循以下步骤:
- POST固件将把扩展ROM放在RAM中的一个地址，这个地址可能不是最终的运行时执行地址。该地址将低于1Mib地址边界。
- POST固件将调用INIT函数入口点，并提供表5-2中描述的6个参数
- 作为INIT函数的一部分，Expansion ROM代码必须放置最终的运行时扩展ROM镜像到POST固件提供的运行时地址。
请注意，扩展ROM代码必须确保设备处于静止状态，直到中断服务例程在最终的运行时位置就位。在连接中断服务程序时必须小心。在安装中断服务程序时，可能会出现中断。 - POST固件在这一步不会写保护包含运行时扩展ROM代码的RAM。在符合此规范3.0或更高版本的系统中，写保护步骤将延迟到执行扩展ROM代码的安装部分(如果有的话)。
- POST固件将从临时RAM位置删除旧映像。
如果扩展ROM不符合本规范3.0或更高版本，那么POST固件将遵循以下步骤:
- POST固件将把扩展ROM放在RAM内的遗留兼容性地址(通常是0C 0000h到0E 0000h)。
- POST固件将调用INIT函数入口点，并提供表5-3中描述的三个参数。
- POST固件将写保护RAM包含运行时扩展ROM代码。扩展ROM的大小和用于写保护的RAM的数量是通过检查ROM头偏移量2处的当前图像大小字段来确定的。
POST固件应该准备好处理系统中任何符合3.0版本(或更高版本)和不兼容扩展rom的混合版本。
1.3 Resizing of Expansion ROMs During INIT
当调用Expansion ROM INIT函数时，Expansion ROM代码可以减少运行时代码和运行时数据所需的空间量。这允许的扩展ROM在运行时占用最小数量的RAM。
例如，一个设备扩展ROM可能需要24 KiB用于初始化和运行时代码，但运行时代码只需要8 KiB。ROM中的映像将显示24kib的大小(在PCI数据结构中的Image Length字段)，这样POST固件就会将整个内容复制到RAM中。然后当INIT函数运行时，它可以将大小调整到8 KiB。这是通过更新ROM头的当前图像大小字段(偏移量2h)来完成的。
INIT函数完成时，POST固件在本例中看到运行时大小为8 KiB，并可以将下一个扩展固件复制到最优位置。
如果INIT函数希望完全将自己从扩展ROM区域中删除，它将通过向Initialization Size字段(偏移量02h处的字节)写入0来实现。在本例中，不需要生成校验和(因为校验和没有长度)。
1.4 Image Structure and Length
PC兼容的映像有三个与之相关的长度:运行时长度、初始化长度和映像长度。映像长度是图像的总长度，它必须大于或等于初始化长度。图像长度包含在PCI数据结构中的image length字段中。
一旦映像被POST固件复制到RAM中，image Length字段不再被POST固件引用，也不再相关。当扩展ROM大小发生变化时，不需要进行调整。
初始化长度指定包含初始化代码和运行时代码的映像的数量。这是POST固件在执行初始化程序之前将复制到RAM中的数据量。这个长度是在ROM报头中从当前映像大小的2h偏移处计算出来的。初始化长度必须大于或等于运行时长度。
运行时长度指定包含运行时代码的映像的数量。这是当系统运行时，POST固件将留在RAM中的数据量。同样，这是从当前图像大小在ROM头偏移2h处计算出来的。如果在INIT阶段更改了扩展ROM的大小，则必须更新当前映像大小。
PCI Data结构必须包含在映像的运行时部分(如果有的话)中，否则，它必须包含在初始化部分中。
任何时候都要维护校验和是非常重要的。当POST固件检查扩展ROM中的映像时，映像长度的校验和必须为零，否则映像将不会被使用。稍后，当扩展ROM初始化并更新当前映像大小时，校验和必须再次更新以维护有效的映像。
1.5 Memory Usage
PCI固件规范版本2.1和更早的版本中，扩展ROM代码没有可靠地与BIOS共享系统资源的方法，特别是内存。PCI扩展rom试图从Extended BIOS Data Area (EBDA)分配内存或搜索为临时使用而擦除的低内存区域。许多PCI扩展rom无法实现鲁棒的共享内存算法，可能会出现不可预知的行为。
扩展ROM代码必须调用POST内存管理器(PMM)来预留内存，无论是临时使用还是永久使用。这个BIOS函数调用只能在Expansion ROM初始化阶段(INIT阶段)调用。
1.6 Verification of BIOS Support
扩展ROM代码必须先验证系统BIOS是否符合该规范的3.0版本(或更高版本)。如果BIOS是兼容的，扩展ROM代码可以调用PMM函数REQUEST_SYSTEM_MEMORY来获得内存供自己使用。扩展ROM代码还为PMM函数提供了一个参数，用于从BIOS请求永久内存或临时内存。PMM功能的详细信息请参见5.2.1.20节。
请注意，3.0(或更高版本)兼容的扩展ROM不需要向后兼容，并且在系统中可以成功地使用符合该规范2.1版本的BIOS。3.0(或更高版本)扩展ROM是否只支持3.0 bios，或同时支持3.0和2.1 bios，这是一个设计选择。
1.7 Permanent Memory
永久内存将继续分配给扩展ROM，甚至在操作系统引导之后。这是由BIOS更新中断15h的数据完成的，E820h功能(“Get Memory Map”)，显示分配给扩展ROM的内存是预留的，私有的，不可移动的。
此外，BIOS必须支持描述内存预留区域的ACPI内存表。中断15h, E820h函数(“Get Memory Map”)，和ACPI内存表都必须包含扩展rom预留的内存项。
操作系统必须对BIOS进行“Get Memory Map”调用，以了解这个内存预留区域的使用情况。如果操作系统无法理解此内存被保留，则可能会发生不可预知的行为。
1.8 Temporary Memory
当扩展ROM初始化码通过PMM请求临时内存时，BIOS会分配内存，这些内存只能在扩展ROM初始化时使用。这是有用的作为一个缓冲区的扩展ROM代码解压ROM。例如，当扩展ROM初始化代码执行完成后，将控制返回BIOS，此时内存将不再被扩展ROM使用，该区域内的任何数据都可能被擦除或覆盖。
1.9 Memory Locations
当扩展ROM初始化代码请求内存时，它可以指定内存应该位于1mib (F FFFFh)边界之上还是之下。小于1mib边界的内存是非常有限的，扩展rom应该节约这个宝贵的系统资源。
当扩展ROM初始化代码请求超过1mib的永久内存时，假设该代码能够在操作系统可能在保护模式下运行时访问该空间。
请注意，扩展ROM初始化代码将在“大实际模式”中从BIOS调用，10并且该代码将对内存的全部32位地址范围进行数据访问。这将允许访问分配在1mib地址边界以上的任何内存缓冲区。
1.10 Permanent Memory Size Limits
对于超过1个MiB的内存请求，扩展ROM需要将永久分配请求限制在64 KiB(总数)。对于小于1 MiB的永久内存请求，限制为40kib(总数)。永久内存分配的总上限可以由固件(系统BIOS)跟踪。可用的永久内存总量必须在多个扩展ROM之间共享。在请求内存之前，扩展ROM可以使用长度为“0”的PMM函数0 (pmmAllocate)调用进行查询，并使用适当的标志来获得可分配的最大永久内存大小。
1.11 Multiple Request for Memory
扩展ROM初始化代码可以多次调用BIOS来请求内存。扩展ROM初始化代码可以请求临时内存或永久内存任意次数。但是，请求的永久内存总量不能超过1.10节中描述的限制。扩展ROM代码必须总是检查返回的状态代码，以确定所请求的内存是否实际分配给了扩展ROM。
1.12 Protected Mode
当扩展ROM初始化码切换到保护模式时，必须在Big Real Mode(32位平面模式)下返回BIOS控制。此外，在扩展ROM初始化过程中，许多BIOS服务在保护模式下不可用。详细信息请参考32位BIOS服务目录(章节2.3)。
1.13 Run-Time Expansion ROM Size
传统的PCI Local Bus Specification 要求扩展ROM代码在初始化后调整自己的大小，以减少内存空间的使用。然而，BIOS不可能知道，在运行扩展ROM初始化代码之前，扩展ROM是否适合放置扩展ROM的剩余空间。符合本规范3.0或更高版本的扩展ROM将在PCI数据结构头中有一个新字段(最大的运行时映像长度)，表示扩展ROM占用的运行时空间。
扩展ROM代码可能无法知道实际的运行时大小(这受系统中是否存在其他PCI设备的影响)。此运行时大小字段描述在运行初始化代码之后，扩展ROM可能占用的最大运行时大小。
BIOS固件将在调用扩展ROM初始化代码之前检查这个字段。如果剩余空间不足以放置运行时扩展ROM代码，BIOS可能会选择不初始化扩展ROM。
1.14 Relocation of Expansion ROM Run-time Code
PCI规范的先前版本描述了传递给扩展ROM初始化代码。符合此规范3.0或更高版本的扩展ROM将接受第四个参数，该参数描述扩展ROM代码的最终运行时地址。
符合本规范3.0或更高版本的扩展ROM代码必须调用BIOS函数(第2.5.2节)确定BIOS是否符合该规范的3.0版本或更高版本，它将提供第四个参数。
这个新参数允许BIOS固件在其最终运行时位置以外的内存空间中执行Expansion ROM初始化代码。当兼容性区域中剩余的空间不足以让BIOS复制扩展ROM初始化代码，但剩余的空间足以放置正确的运行时代码时，这是很有用的。BIOS可以在最终运行时代码驻留的区域以外的区域初始化扩展ROM代码。在所有情况下，该区域将低于1mib地址边界。
3.0(或更高版本)兼容的BIOS不会提供部分重叠临时INIT地址的运行时地址。这两个地址(如果不同)将是完全独立的内存范围。然而，3.0(或更高版本)兼容的BIOS可能会提供与INIT地址相同的运行时地址，类似于2.1兼容的BIOS现在的功能。在这两种情况下,扩展ROM可以检查CS寄存器和第四个参数(运行时地址)，以确定它们是否是同一个区域。
在将控制返回到BIOS之前，扩展ROM代码将移动运行时代码，如文档前面部分所述。如果扩展ROM代码更新中断向量以指向运行时扩展ROM代码，那么这些中断向量必须指向最终的运行时位置，而不是BIOS可能临时放置的临时位置用于初始化的扩展ROM代码。
例如，存放扩展rom的可用空间为16kib和64 KiB的扩展ROM表明(通过运行时大小字段)它的运行时大小是16 KiB，那么有足够的空间来容纳运行时代码。但是64kib Expansion ROM的初始化代码必须先执行，但是64kib的代码不能放在内存中(只剩下16kib)，所以会初始化失败。
然而，一个符合该规范3.0或更高版本的扩展ROM可以在另一个位置初始化，然后运行时代码被扩展ROM代码移动到它的最终地址。
1.15 Expansion ROM Placement Address
PCI规格的早期版本已经描述了扩展rom将被放置的地址，通常从0C 0000h到0E 0000h。该规范的这个版本现在将该区域从a0000h扩展到F FFFFh。符合本规范3.0或更高版本的系统固件将把符合本规范3.0或更高版本的扩展ROM代码放置在此扩展范围内的任何对齐地址上。
如果扩展ROM没有被标识为3.0(或更高版本)兼容，系统固件将把扩展ROM放置在旧地址范围内(0C 0000h到0E 0000h)。
系统固件必须写保护新范围内PCI扩展ROM运行时代码所在的区域。系统固件必须清楚地了解系统写保护RAM的各个区域的能力。系统固件必须写保护新范围内PCI扩展ROM运行时代码所在的区域。3.0(或更高版本)兼容的扩展ROM可能不能放置在A0000h地址区域;例如，因为系统不支持该区域的写保护。
从A 0000h-B FFFFh开始的区域也是VGA设备的传统帧缓冲区位置。系统固件应该从可用的扩展rom空间中排除此范围，只要支持VGA设备。对于不支持VGA设备的系统，系统固件负责确定在A 0000h-B FFFFh区域放置扩展rom是否存在不可接受的风险。
1.16 VGA Expansion ROM
该规范的早期版本已经声明，VGA扩展rom必须初始化为0C 0000h地址空间。这个要求在这个版本的规范中被取消了。3.0(或更高版本)兼容的VGA扩展ROM可以在扩展ROM放置地址范围内的任何位置进行初始化。
诊断固件和POST固件不应该假设在0C 0000h地址存在一个有效的PCI扩展ROM，那么它就是一个VGA扩展ROM。固件应该查看PCI数据结构中的Class Code字段，用于确定扩展ROM是否属于PCI VGA设备。
3.0(或更高版本)兼容的BIOS可能会选择始终将VGA扩展ROM放在旧版本上0C 0000 h的地址。BIOS负责确定将VGA扩展ROM放在非传统地址是否存在不可接受的风险。
1.17 Expansion ROM Placement Alignment
传统ISA传统扩展rom被放置在内存中，地址对齐在2-KiB边界上。这一传统一直延续到PCI，它导致了扩展rom之间平均1-KiB的差距。
3.0(或更高版本)兼容的扩展rom可以放置在512字节边界上均匀对齐的地址上。然而，BIOS必须了解传统操作系统和传统应用程序，它们将继续在传统的2-KiB边界上寻找扩展ROM。BIOS负责确定在非传统地址放置选项ROM是否存在不可接受的风险。
1.18 BIOS Boot Specification
所有3.0(或更高版本)兼容的扩展rom必须支持http://www.acpica.org/sites/acpica/files/specsbbs101.pdf找到的BIOS引导规范。但是，这个规范取代了BIOS引导规范对扩展ROM放置地址、VGA扩展ROM放置和拓展ROM放置一排的定义。
1.19 Extended BIOS Data Area (EBDA) Usage
Extended BIOS Data Area (EBDA)是一个内存缓冲区，分配在内存的1个MiB地址区域以下。历史上，这个区域被扩展ROM代码用来创建一个永久的内存缓冲区供自己使用。EBDA内存缓冲区是一个共享的系统资源，因此必须一致和谨慎地使用它。
如果扩展ROM需要的内存小于1MiB，则需要通过PMM函数获取。由于管理和访问EBDA内存的复杂性，不鼓励使用EBDA。
如果扩展ROM确定PMM服务不可用，则允许使用EBDA，并遵循以下原则:
详情见spec PCI Firmware Specification3.3
1.20 POST Memory Manager (PMM) Functions
本介绍的PMM新功能是基于现有的PMM 1.01规格,该规范的3.3.3节描述了各种PMM调用的输入参数。flags字段现在扩展为包含位3的定义，如表5-4所示
1.21 Backward Compatibility of Option ROMs
它的目的是3.0(或更高版本)的选项rom的定义与之前的2.1定义兼容。这是可能的单一3.0(或更高版本)选项ROM镜像功能与3.0(或更高版本)兼容的系统固件和2.1兼容的系统固件。Option ROM中的3.0字段和功能将被2.1兼容的系统固件忽略。符合2.1标准的系统固件应该不难定位3.0(或更高版本)选项ROM，并以与本规范2.1版本一致的方式初始化它。
对于同一个PCI设备，也可以有两个独立的ROM映像:一个是2.1兼容的系统固件和一个3.0(或更高版本)兼容的系统固件。在本例中，2.1选项ROM映像必须在映像序列中首先出现。3.0(或更高版本)兼容的系统固件将首先搜索3.0(或更高版本)选项ROM镜像，如果没有找到3.0(或更高版本)选项ROM镜像，则只使用2.1选项ROM镜像。
1.22 Option ROM and IRET Handling
Option rom必须能够处理级别触发的PCI中断模型，其中一个中断可以在多个设备之间共享。Option rom必须实现适当的中断链接机制，并将控制传递给下一个ISR(如果存在)。对于执行IRET和EOI的所有硬件中断，应该有一个默认的System BIOS中断处理程序(承认)。通常，大多数System bios已经安装了一个默认的中断处理程序来处理虚假中断。
注意:Option ROM总是将当前地址(原始的中断向量地址)复制到它的本地缓冲区，然后继续安装它自己的中断向量地址。在ISR调用中，如果一个中断向量地址已经被Option ROM注册，那么它应该调用原始的中断向量地址。在中断ISR链中第一个安装的Option ROM将是在ISR执行期间调用的最后一个Option ROM，在将控制传递给默认的System BIOS处理程序之前。
在Option ROM挂接中断之前，中断可以被留在“中断控制器”中。选项ROM可以在安装了ISR之后解开中断的掩码。默认的系统BIOS中断处理程序不能屏蔽中断，一旦它被可选ROM解除屏蔽
在ISR链中的选项ROM不应该屏蔽级别触发的共享中断“中断控制器”。如果IRQ大于或等于8，系统BIOS默认中断处理程序应该能够通过适当地向主/从中断控制器发出EOI来处理常规的和虚假的中断。
为了保持与当前系统ROM实现的向后兼容性，PCI选项ROM应该通过PCI BIOS Present功能检查3.0(或更高版本)兼容的系统BIOS。如果检测到3.0(或更高版本)兼容的BIOS，那么选项ROM的中断处理程序应该链接到下一个中断处理程序，如本节所述，而不是执行EOI。如果一个3.0
(或以后)兼容的系统BIOS不存在，那么选项ROM应该只有EOI和IRET。
1.23 Stack Size Requirement by Expansion ROM
系统固件将为POST Expansion ROM提供最少4-KiB大小的堆栈。建议系统固件、操作系统和应用程序在运行时调用Expansion ROM时提供最少4-KiB大小的堆栈。
1.24 Configuration Code for Expansion ROM
某些扩展ROM包含配置代码或实用程序代码，最终用户可能会在扩展ROM初始化时执行这些代码。由于此规范的以前版本没有提供任何执行此代码的机制，因此扩展rom代码编写人员实现了各种各样的方法来调用此配置代码。
在许多情况下，扩展ROM代码将在屏幕上放置一个提示符，例如“按F2进入XXXX Configuration实用程序”，并查看键盘敲击查找调用。这在许多情况下引起了问题。无法保证调用击键没有被系统固件分配到其他用途。
将多个功能分配给一个键击可能会导致系统的一部分在扩展ROM初始化期间变得不可访问。此外，扩展ROM必须等待一段任意的时间，以确定用户没有按下击键。这给扩展ROM初始化代码和整个系统POST时间增加了不必要的延迟，特别是在终端用户不需要更改配置的情况下。
从规范的这个版本开始，扩展ROM供应商可以隔离配置代码，系统固件将只在用户特别要求时执行配置代码。扩展ROM头(在章节5.1.2中定义)现在包含一个可选的指针，指向配置代码的头。在POST期间，当系统固件为INIT阶段准备扩展ROM时，系统固件将复制配置实用程序代码(如果存在于ROM映像中)，并将其留在临时内存中，以备以后执行。
在INIT阶段完成时，扩展ROM将自己缩小到最终的运行时大小(没有配置实用程序代码)，配置代码将保留在临时内存中。注意，BIOS直到POST结束时才会写保护运行时扩展ROM映像。这允许扩展ROM配置实用程序代码更新运行时扩展ROM代码的配置参数或由配置实用程序代码。扩展ROM运行时大小必须包括存储配置参数的区域，并且当配置实用程序代码用配置参数更新运行时代码时，大小不能增加。配置实用程序代码还必须更新运行时扩展ROM代码的校验和，以保持运行时映像有效。
系统固件将负责管理所有扩展rom的配置实用程序的位置和执行。但是，扩展ROM可以控制系统固件处理配置实用程序代码的某些方式。有三种可能的情况。
❑Legacy:在这个场景中，扩展ROM映像不包含指向配置实用程序代码头的指针。扩展ROM要么没有配置代码，要么更倾向于在INIT阶段运行配置代码，就像现在兼容2.1的扩展ROM所做的那样。在此场景中，系统固件不管理配置实用程序代码。
❑Hybrid:在这种情况下，扩展ROM有一个有效的配置实用程序代码头。但是，如上面的遗留风格所述，Expansion ROM在INIT阶段运行配置实用程序代码。此外，系统固件保存了一份配置实用程序代码的副本，并可能在稍后的POST中执行它。必须准备好配置实用程序代码，以便在此场景中执行两次。
❑延迟执行:在这种情况下，扩展ROM有一个有效的配置实用程序代码头。与前两个场景不同，配置实用程序不会执行(由INIT阶段的扩展ROM)。配置实用程序代码仅由系统固件在POST中的稍后一点执行。
首选的方法是上面描述的“延迟执行”风格。这允许系统固件以一致和有组织的方式管理配置实用程序代码的执行。
支持配置实用程序代码管理是可选的系统固件。扩展ROM必须调用“PCI BIOS Present”功能，如2.5.2节所述，以确定系统固件是否实现了对扩展ROM配置代码的支持。
1.25 DMTF Server Management Command Line Protocol(SM CLP) Support
Option ROM可以选择性地提供一个入口点，该入口点将通过DMTF SM CLP标准支持设备配置。12该接口将遵循DMTF SM CLP规格1.0.2最终标准中定义的API。这个接口是通过大真实模式下的FAR CALL访问的，在这个模式下，系统ROM将传递一个DMTF SM CLP兼容的配置消息，该配置消息将以该设备或该设备的子设备为目标。该接口可能会被多次调用，以便在预启动时对设备进行完整的配置。System ROM负责为实现中的任何给定容器执行SM CLP UFiTs的任何发现、枚举和后续翻译。选项ROM代码应该假设系统固件将调用大实模式的入口点，并且至少有4 KiB的堆栈和至少128 KiB的扩展内存通过PMM可用。
2. UEFI Exponsion ROM (Type3)
统一可扩展固件接口规范第13.4.2节“PCI Option rom”，版本2.4(http://www.uefi.org)描述了在PCI Expansion ROMs中存储UEFI映像(例如，UEFI驱动程序)的方法。本文档5.2.1章节的描述不适用于UEFI扩展ROMs。