EFI_SECTIONtype. Prior to creating the EFI section files, PEI Foundation and PEIM images may be processed into either a terse image, or have the .reloc section removed (for images that will always execute directly from ROM).
EFI_OPTIONAL_IMAGE_HEADER64) or non-IPF (
AddressOfEntryPointis set to the optional header's
AddressOfEntryPoint. Additionally, the
Subsystementry from the optional header's
Subsystementry will be packed into one byte.
ImageBasein the TE header come from the optional Header. If the optional header's
NumberOfRvaAndSizesis greater than 0, then the relocation data from the optional header
Sizeis set based on the content of the optional header's
NumberOfRvaAndSizesis greater than 1, then the debug data from the optional header's
Sizeis set in the TE header's
NumberOfSectionsin the file which needs to be packed into a single byte of the TE header. The number of sections must be less than 255 for this to succeed.
.relocsection is at the end of the file. While most .reloc sections are fairly small in comparison to the other sections of the files, removing all of the .reloc sections in combination with using Terse images for the PEI foundation and PEIMs that do not register for shadow (see UEFI/PI specs) can shrink a platform image by several hundred bytes.
StrippedSize) is adjusted by subtracting the length of the
DataDirectory VirtualAddressis set to 0, as is the
0x00004545) will be modified by setting the
EFI_IMAGE_FILE_RELOCS_STRIPPEDbit. The IPF header uses a similar data structure to IA32, X64 and EBC data structures. The naming within the data structures is consistent. Therefore, regardless of the machine type, both the
SizeOfInitializedDataare adjusted by subtracting the length of the
.relocsection. If the
NumberOfRvaAndSizesis greater than the
EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC, then the
Sizeare both set to 0. Finally, the
.relocsection's header is modified, setting the
EFI SECTIONfiles. EFI_SECTION headers must be present on all leaf sections. The EFI Section header (see above) will be prefixed to the file or data section (
USER_INTERFACEdata can be generated "on-the-fly" rather than creating a separate Unicode file first).
.datasection headers (if they exist) are overwritten with the
text) is copied into the
Nameentry, while the remaining sections are set as follows:
Flagsvalue is a bit-wise OR of
.datasection, the Flags value is a bit-wise OR of
relocsection, the Flags value is a bit-wise OR of
debugsection, the Flags value is a bit-wise OR of
EFI_COMMON_SECTION_HEADERwill be prefixed to the file.
EFI_COMMON_SECTION_HEADER"type" field defines the data that follows. Table 4 lists the section type value. All EFI section files start with the
EFI_COMMON_SECTION_HEADER. For example, a zero-length section has a
EFI_SECTION_USER_INTERFACE, the format of each section is the
EFI_COMMON_SECTION_HEADERprefixed to a file containing data. Refer to the definitions for
EFI_SECTION_USER_INTERFACEin the UEFI specifications for more information.
EFI_SECTIONheader must be present along with additional header information. The encapsulation EFI Section header will be prefixed to the file or data section. There are three encapsulation
EFI_SECTIONtypes. The first two types listed have extended header information.
EFI_SECTION_COMPRESSIONheader, while the GUID defined section uses an
CompressionTypefield must be set to 0x01 for standard compression, or 0x00 if the image is not compressed.
PI_STDcompression is supported for this section type.
EFI_GUID_DEFINED_SECTION,which is used for non-standard compression (see above) the named GUID that defines the section follows the
EFI_COMMON_SECTION_HEADER. After this GUID are two additional
UINT16parameters, the first is the
DataOffsetwhich contains the offset in bytes from the beginning of the common header to the first byte of the data. An Attributes parameter is a bit field code which declares specific characteristics of the section contents.
EFI_SECTIONfiles. The format of the binary data is 8-bit aligned, with a single byte per op-code, with op-codes that require a GUID value (
PUSH) being followed by 16 bytes to contain the GUID value. See Table 6 below.
EFI_SECTIONfile can be created, and the
EFI_COMMON_SECTION_HEADERwill be prefixed to the file.
FfsFileHeaderdata structure is a GUID value with a structure of
FfsFileHeader.Sizearray is computed using the size of all files, including all pad files, plus the size of the header. The size value must be less than
FfsFileHeader.IntegrityCheck.Checksum.Headeris set to
0, as are the
FileHeader.State, prior to calculating (and setting) the checksum of the header. If the
FFS_ATTRIB_CHECKSUMbit is set in the
FfsFileHeader.Attributes, then the checksum for the remainder of the FFS content must be generated and placed in the
Checksum.Filepart of the
FfsFileHeader.Stateis zeroed, the
EFI_FILE_DATA_VALIDbits are set.
APRIORIand one DXE
APRIORIfile in a given firmware volume.
PEI_APRIORI_FILE_NAME_GUID, will specify the order of invocation of PEIMs by the PEI foundation. This is a special file, of the type,
EFI_FV_FILETYPE_FREEFORMwith a single
EFI_SECTION_RAWand has the format:
DXE_APRIORI_FILE_NAME_GUID, will specify the dispatch order of drivers by the DXE foundation. This is a special file, of the type
EFI_FV_FILETYPE_FREEFORMwith a single
EFI_SECTION_RAWand has the same format as the
FV_INFOstructure is used to identify the name of the files that will be created in the FV directory.
EFI_FIRMWARE_VOLUME_HEADERdefinition in Section 3) is constructed using the following information.
ZeroVector) are set to zero. The
FvFileSystemGuidis assigned a PI Specification defined GUID (
EFI_FIRMWARE_FILE_SYSTEM2_GUID) that identifies it as a PI compliant Firmware Volume. The
Signatureis set to "
_FVH" and the reserved byte is set to zero. The PI Specification defined
Revisionis set to
FvLengthfield, such that the final
FvLengthis complete length of the firmware volume, including the header (and extended header information). Also, as an FFS file is added to the FV, if the driver executes from ROM, the base address of the driver will be adjusted (re-based) within the FFS file to the physical location in ROM (
BaseAddress + offset).
Attributes(defined in the FDF file) are set that define the capabilities and power-on defaults of this FV. These come from the
FvAttributesof the FV_INFO data structure. The
HeaderLengthis set to size of header, including the size of the
BlockMapdata array is a mapping of the FFS files - giving the length (in blocks) and block size for each FFS file in the FV, starting with the first FFS file. This is an index of the blocks, and does not specify each FFS by name. If an extended header is required, it must be placed immediately following the
BlockMapdata array. The
ExtHeaderOffsetis set to the location of the extended header. Each block will be aligned on the largest value specified by the
EFI_FVB2_ALIGNMENTattribute. Note that it is permissible to use variable block length devices, and as such, each block entry would have the
BlockMap[index].NumBlocks = 1, while the
BlockMap[index].BlockLengthwould vary according to the size of the FFS file (plus any padding value needed to align the next block on a natural boundary).
ExtHeaderOffsetis set to zero. If an extended header is present, it is followed by zero or more variable length extension (
FvLengthis complete), the
Checksumfield is set to zero and a checksum is calculated on the header so that a valid header will sum to zero (and placed into the
tools_def.txtfile (refer to Section 5) the TianoCompress.exe application can be used to compress an EFI image - FV, FFS and/or SECTION. The following shows two lines that are in the
tools_def.txtfile to identify the TianoCompress tool.
tools_def.txtfile. If a match is found, then the executable tool associated in the GUID is executed on the encapsulated data defined in the FDF file. Since the tool is not present during a system boot, any optional tool must be able to provide code that can be used by any decompression, signing or verification drivers during boot. The following shows the use of the
TianoCompressGUID in a sample FDF file for an FVMAIN image that contains all post-PEI modules.
E76CB2EC) is the EFI Name for the firmware volume, while the second (following the
SECTION GUIDEDstatement) identifies the tool (TianoCompress.exe) that will be used on the FV section specified within the curly brackets after the GUID.
[FD]section at the location specified. Data structures in the FDF are typically used to initialize the data area for use by EFI drivers, and as such, may require an FV header to identify the region (such as NV storage) in Flash.
EFI_SECTIONFiles above) will have an
EFI_PCI_EXPANSION_ROM_HEADERprefixed to the EFI file (aligned on a 4-byte boundary). The header structure is defined in the PCI industry standard specification, and is shown below.
Signaturevalue of the PCI 3.0 version header is defined as
0xAA55, and the
EfiSignatureis defined as
InitializationSizeis the number of 512-byte blocks of the driver image plus the size of this header. The
EfiSubsystemis set to the value of PE32 Optional Header's Subsystem value, while the
EfiMachineTypeis set to the
EFI_IMAGE_FILE_HEADER's Machine Type. The
CompressionTypefield is set to either
0x0000for no compression, or
0x0001for standard EFI compression - no other compression types are permitted. The reserved bits are typically set to 0 However they may be used. The
EfiImageHeaderOffsetis set to the size of this header, while the
PcirOffsetis the offset to the EFI header, (the Option ROM header size plus any padding bytes to align the driver on its natural alignment boundary). Additionally, the PCI Data Structure (PCI 3.0 compliant is the default) is also inserted. The Vendor ID and Device ID are inserted into the PCI Data Structure. The
CodeRevisionare determined from the input file header information, while the
ImageLengthfield is set to the Option ROM Header's InitializationSize field. All other fields are currently set to 0 by the reference implementation's EfiRom tool.
CapsuleGuiddefines the format of the capsule data - including any optional header information. The format for a capsule is shown in Figure 15.