EDK II Flash Description File (FDF) Specification

May 2010 Revision 1.22

FDF

Acknowledgements
THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Intel products are not intended for use in medical, life saving, or life sustaining applications. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. A license is hereby granted to copy and reproduce this specification for internal use only. No other license, express or implied, by estoppel or otherwise, to any other intellectual property rights is granted herein. Intel disclaims all liability, including liability for infringement of any proprietary rights, relating to use of information in this specification. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted herein. This specification is an intermediate draft for comment only and is subject to change without notice. Readers should not design products based on this document. *Other names and brands may be claimed as the property of others.

Copyright 2007- 2010 Intel Corporation. All rights reserved.

ii

May 2010

Version 1.22

FDF

Revision History
Revision 1.0 1.1 1.2 1.21 Revision History Initial release. Updated based on errata Updated based on enhancement requests Updated based on enhancement requests and errata Added support for SMM_CORE Added support for CAPSULE_FLAGS_INITIATE_RESET Added Block Statements to all Capsule sections Added Auto keyword to FFS alignment Rule processing for file type lists is alphabetical, i.e., files are added in alphabetical order Definitions in DSC file are now global to both DSC and FDF files PCD Values may be constructed using C-style expressions provided the result of the expression matches the datum type of the PCD FeatureFlagExpression is now defined as a C-style expression using C relational, equality and logical numeric and bitwise operators and/or arithmetic and bitwise operators that evaluate to a value that matches the Datum Type of the PCD. Precedence and associativity follow C standards Grammatical and formatting editing Date December 2007 August 2008 June 2009 March 2010

1.22

May 2010

Version 1.22

May 2010

iii

FDF

iv

May 2010

Version 1.22

Contents
1 Introduction..................................................................................................... 1
1.1 Overview ........................................................................................................................... 1 1.2 Related Information........................................................................................................... 2 1.3 Terms................................................................................................................................ 2 1.4 Target Audience................................................................................................................ 5 1.5 Conventions Used in this Document................................................................................. 5 1.5.1 Data Structure Descriptions .................................................................................. 5 1.5.2 Pseudo-Code Conventions ................................................................................... 5 1.5.3 Typographic Conventions ..................................................................................... 6

FDF Design Discussion ................................................................................. 9

2.1 Processing Overview ........................................................................................................ 9 2.1.1 Platform Configuration Database (PCD) Settings ............................................... 11 2.2 Flash Description File Format ......................................................................................... 11 2.2.1 Section Entries .................................................................................................... 11 2.2.2 Comments........................................................................................................... 11 2.2.3 Valid Entries ........................................................................................................ 12 2.2.4 Naming Conventions........................................................................................... 12 2.2.5 !include Statements............................................................................................. 13 2.2.6 Macro Statements ............................................................................................... 13 2.2.7 PCD Names ........................................................................................................ 14 2.2.8 Conditional Statements (!if...).............................................................................. 14 2.3 [FD] Section .................................................................................................................... 15 2.3.1 FD TOKEN Statements....................................................................................... 15 2.3.2 FD DEFINE statements....................................................................................... 16 2.3.3 FD SET statements............................................................................................. 16 2.3.4 FD Region Layout ............................................................................................... 17 2.4 [FV] Section .................................................................................................................... 19 2.4.1 DEFINE Statements............................................................................................ 20 2.4.2 Block Statements ................................................................................................ 20 2.4.3 FV SET Statements ............................................................................................ 21 2.4.4 APRIORI Scoping ............................................................................................... 21 2.4.5 INF Statements ................................................................................................... 22 2.4.6 FILE Statements ................................................................................................. 23 2.5 [Capsule] Section............................................................................................................ 26 2.5.1 UEFI Implementation .......................................................................................... 27 2.5.2 Capsule SET Statements.................................................................................... 27 2.5.3 Capsule Data ...................................................................................................... 27 2.6 [VTF] Section .................................................................................................................. 28 2.6.1 Options Statement .............................................................................................. 28 2.6.2 Component Statements ...................................................................................... 28 2.7 [Rule] Section.................................................................................................................. 28

1.22

May, 2010

FDF

2.8 [OptionRom] Section....................................................................................................... 30 2.9 [UserExtensions] Section................................................................................................ 30

FDF File Format Specification..................................................................... 31

3.1 Introduction ..................................................................................................................... 31 3.1.1 Valid Line Extension Examples........................................................................... 32 3.2 FDF Definition ................................................................................................................. 32 3.2.1 Common Definitions............................................................................................ 33 3.2.2 MACRO Statements............................................................................................ 37 3.2.3 Conditional Directive Statements ........................................................................ 38 3.2.4 !include Statements............................................................................................. 42 3.3 Header Section ............................................................................................................... 42 3.4 [Defines] Section............................................................................................................. 44 3.5 [FD] Section .................................................................................................................... 46 3.6 [FV] Sections................................................................................................................... 51 3.7 [Capsule] Section............................................................................................................ 60 3.8 [Rule] Section.................................................................................................................. 69 3.9 [VTF] Section .................................................................................................................. 76 3.10 PCI OptionRom Section................................................................................................ 80 3.11 UserExtensions Section................................................................................................ 81

Appendix A Sample Flash Description File ......................................................................... 83 Appendix B Common Error Messages ................................................................................. 91
B.1 [FD] Syntax Errors: ......................................................................................................... 91 B.2 [FV] Syntax Errors: ......................................................................................................... 91 B.3 [CAPSULE] Syntax Errors: ............................................................................................. 91 B.4 [Rule] Syntax Errors: ...................................................................................................... 91

Appendix C Reports ............................................................................................................... 93

C.1 [FD] Reports: .................................................................................................................. 93 C.2 [FV] Reports: .................................................................................................................. 93 C.3 [CAPSULE] Reports: ...................................................................................................... 93

vi

May, 2010

1.22

FDF

Tables
Table 1.EDK Build Infrastructure Support Matrix ......................................................................... 2 Table 2.Valid Variable Names for PATH statements ................................................................. 14

Version 1.22

May 2010

vii

FDF

viii

May 2010

Version 1.22

FDF

Figures
Figure 1. EDK II Build Data Flow ........................................................................................... 10 Figure 2. EDK II Create Image Flow ...................................................................................... 10

Version 1.22

May 2010

ix

FDF

May 2010

Version 1.22

FDF

Introduction

1 Introduction
This document describes the EDK II Flash Description (FDF) file format. This format was designed to support new build requirements of building EDK and EDK II modules within the EDK II build infrastructure. The EDK II Build Infrastructure supports generation of current Unified EFI, Inc. (UEFI 2.1 and PI 1.2) compliant binary images. The FDF file is used to describe the content and layout of binary images. Binary images described in this file may be any combination of boot images, capsule images or PCI Options ROMs.

Note: EDK II FDF file formats have no similarity to EDK FDF file formats. New utilities and functionality
have been provided to process these files.

1.1 Overview
EDK II tools use INI-style text-based files to describe components, platforms and firmware volumes. The EDK II Build Infrastructure supports generation of binary images compliant with Unified EFI Forum (UEFI) specifications UEFI 2.1 and Platform Initialization (PI) 1.0. The EDK II build processes, defined in the EDK II Build Specification, use separate steps to create EFI images. EDK Build Tools are included as part of the EDK II compatibility package. In order to use EDK II Modules or the EDK II Build Tools, EDK II DSC and FDF files must be used. The EDK II FDF file is used in conjunction with an EDK II DSC file to generate bootable images, option ROM images, and update capsules for bootable images that comply with the UEFI specifications listed above. The FDF file describes the content and layout of binary images that are either a boot image or PCI Option ROMs. This document describes the format of EDK II FDF files that are required for building binary images for an EDK II platform. The goals are: Compatibility No compatibility with EDK FDF files exists in format or tools. Simplified platform build and configuration
The FDF files simplify the process of adding EDK components and EDK II modules to a firmware volume on any given platform.

The EDK build tools are provided as part of the EdkCompatibilityPkg which is included in EDK II. Table 1 shows the FDF compatibility between platform, module and component builds.

Version 1.22

May 2010

Introduction

FDF

Table 1. EDK Build Infrastructure Support Matrix

EDK FDF EDK Build Tools EDK II Build Tools YES NO EDK II FDF NO YES EDK DSC YES NO EDK II DSC NO YES

1.2 Related Information

The following publications and sources of information may be useful to you or are referred to by this specification: Extensible Firmware Interface Specification, Intel, 2001, http://developer.intel.com/ technology/efi. definitions of terms, abbreviations, documents and specifications:.

Note: See the glossary sections in the EFI 1.10 Specification for additional required or recommended Note: See the master Framework glossary in the Framework Interoperability and Component

Specifications help system for additional required or recommended definitions of terms, abbreviations, documents and specifications: http://www.intel.com/technology/framework/ spec.htm. Unified Extensible Firmware Interface Specification, Version 2.3, Unified EFI, Inc, 2006, http://www.uefi.org. Platform Initialization Specification, Version 1.1, Unified EFI, Inc., 2006, http:// www.uefi.org. Intel Platform Innovation Framework for EFI Specifications, Intel, 2006, http:// www.intel.com/technology/framework/.
http://sourceforge.net/projects/edk2/files/ EDK II Module Writers Guide, Intel, 2010. PCD Infrastructure, Intel, 2009. EDK II User Manual, Intel, 2010. EDK II C Coding Standard, Intel, 2010. EDK II DSC Specification, Intel, 2010. EDK II INF File Specification, Intel, 2010. EDK II FDF Specification, Intel, 2010. EDK II Build Specification, Intel, 2010. VFR Programming Language, Intel, 2010.

1.3 Terms
The following terms are used throughout this document to describe varying aspects of input localization: BDS
Framework Boot Device Selection phase.

BNF
BNF is an acronym for Backus Naur Form. John Backus and Peter Naur introduced for the first time a formal notation to describe the syntax of a given language.

Component
An executable image. Components defined in this specification support one of the defined module types.

May 2010

Version 1.22

FDF

Introduction

DXE
Framework Driver Execution Environment phase.

DXE SAL
A special class of DXE module that produces SAL Runtime Services. DXE SAL modules differ from DXE Runtime modules in that the DXE Runtime modules support Virtual mode OS calls at OS runtime and DXE SAL modules support intermixing Virtual or Physical mode OS calls.

DXE SMM
A special class of DXE module that is loaded into the System Management Mode memory.

DXE Runtime
Special class of DXE module that provides Runtime Services

EBNF
Extended Backus-Naur Form meta-syntax notation with the following additional constructs: square brackets [] surround optional items, suffix * for a sequence of zero or more of an item, suffix + for one or more of an item, suffix ? for zero or one of an item, curly braces {} enclosing a list of alternatives and super/subscripts indicating between n and m occurrences.

EDK Compatibility Package (ECP)

The EDK Compatibility Package (ECP) provides libraries that will permit using most existing EDK drivers with the EDK II build environment and EDK II platforms.

EFI
Generic term that refers to one of the versions of the EFI specification: EFI 1.02, EFI 1.10, UEFI 2.0, UEFI 2.1, UEFI 2.2 or UEFI 2.3.

Foundation
The set of code and interfaces that glue implementations of EFI together.

Framework
Intel Platform Innovation Framework for EFI consists of the Foundation, plus other modular components that characterize the portability surface for modular components designed to work on any implementation of the Tiano architecture.

GUID
Globally Unique Identifier. A 128-bit value used to name entities uniquely. A unique GUID can be generated by an individual without the help of a centralized authority. This allows the generation of names that will never conflict, even among multiple, unrelated parties. GUID values can be registry format (8-4-4-4-12) or C data structure format.

HII
Human Interface Infrastructure. This generally refers to the database that contains string, font, and IFR information along with other pieces that use one of the database components.

IFR
Internal Forms Representation. This is the binary encoding that is used for the representation of user interface pages.

Library Class
A library class defines the API or interface set for a library. The consumer of the library is coded to the library class definition. Library classes are defined via a library class .h file that is published by a package.

Library Instance
An implementation of one or more library classes.

Version 1.22

May 2010

Introduction

FDF

Module
A module is either an executable image or a library instance. For a list of module types supported by this package, see module type.

Module Type
All libraries and components belong to one of the following module types: BASE, SEC, PEI_CORE, PEIM, SMM_CORE, DXE_CORE, DXE_DRIVER, DXE_RUNTIME_DRIVER, DXE_SMM_DRIVER, DXE_SAL_DRIVER, UEFI_DRIVER, or UEFI_APPLICATION. These definitions provide a framework that is consistent with a similar set of requirements. A module that is of module type BASE, depends only on headers and libraries provided in the MDE, while a module that is of module type DXE_DRIVER depends on common DXE components. For a definition of the various module types, see module type.

Package
A package is a container. It can hold a collection of files for any given set of modules. Packages may be described as one of the following types of modules: source modules, containing all source files and descriptions of a module binary modules, containing EFI Sections or a Framework File System and a description file specific to linking and binary editing of features and attributes specified in a Platform Configuration Database (PCD,) mixed modules, with both binary and source modules Multiple modules can be combined into a package, and multiple packages can be combined into a single package.

Protocol
An API named by a GUID.

PCD
Platform Configuration Database.

PEI
Pre-EFI Initialization Phase.

PPI
A PEIM-to-PEIM Interface that is named by a GUID.

Runtime Services
Interfaces that provide access to underlying platform-specific hardware that might be useful during OS runtime, such as time and date services. These services become active during the boot process but also persist after the OS loader terminates boot services.

SAL
System Abstraction Layer. A firmware interface specification used on Intel Itanium Processor based systems.

SEC
Security Phase is the code in the Framework that contains the processor reset vector and launches PEI. This phase is separate from PEI because some security schemes require ownership of the reset vector.

UEFI Application
An application that follows the UEFI specification. The only difference between a UEFI application and a UEFI driver is that an application is unloaded from memory when it exits regardless of return status, while a driver that returns a successful return status is not unloaded when its entry point exits.

UEFI Driver
A driver that follows the UEFI specification.

May 2010

Version 1.22

FDF

Introduction

UEFI Specification Version 2.3

Current version of the EFI specification released by the Unified EFI Forum.

UEFI Platform Initialization Specification 1.2

Current version of the PI specification released by the Unified EFI Forum.

Unified EFI Forum

A non-profit collaborative trade organization formed to promote and manage the UEFI standard. For more information, see www.uefi.org.

VFR
Visual Forms Representation.

1.4 Target Audience

This document is intended for persons performing UEFI or PI compliant platform development and support for different platforms.

1.5 Conventions Used in this Document

This document uses typographic and illustrative conventions described below.

1.5.1 Data Structure Descriptions

Intel processors based on 32 bit Intel architecture (IA 32) are "little endian" machines. This distinction means that the low-order byte of a multibyte data item in memory is at the lowest address, while the high-order byte is at the highest address. Processors of the Intel Itanium processor family may be configured for both "little endian" and "big endian" operation. All implementations designed to conform to this specification will use "little endian" operation. In some memory layout descriptions, certain fields are marked reserved. Software must initialize such fields to zero and ignore them when read. On an update operation, software must preserve any reserved field. The data structures described in this document generally have the following format:

Summary:
A brief description of the data structure.

Prototype:
An EBNF-type declaration for the data structure.

Parameters:
Explanation of some terms used in the prototype.

Example:
Sample data structure using the prototype.

1.5.2 Pseudo-Code Conventions

Pseudo code is presented to describe algorithms in a more concise form. None of the

Version 1.22

May 2010

Introduction

FDF

algorithms in this document are intended to be compiled directly. The code is presented at a level corresponding to the surrounding text. In describing variables, a list is an unordered collection of homogeneous objects. A queue is an ordered list of homogeneous objects. Unless otherwise noted, the ordering is assumed to be FIFO. Pseudo code is presented in a C-like format, using C conventions where appropriate. The coding style, particularly the indentation style, is used for readability and does not necessarily comply with an implementation of the Extensible Firmware Specification.

1.5.3 Typographic Conventions

This document uses the typographic and illustrative conventions described below:
Typographic Convention Typographic convention description

Plain text Plain text (blue) Bold Italic BOLD Monospace

The normal text typeface is used for the vast majority of the descriptive text in a specification. Any plain text that is underlined and in blue indicates an active link to the crossreference. Click on the word to follow the hyperlink. In text, a Bold typeface identifies a processor register name. In other instances, a Bold typeface can be used as a running head within a paragraph. In text, an Italic typeface can be used as emphasis to introduce a new term or to indicate a manual or specification name. Computer code, example code segments, and all prototype code segments use a BOLD Monospace typeface with a dark red color. These code listings normally appear in one or more separate paragraphs, though words or segments can also be embedded in a normal text paragraph. Words in a Bold Monospace typeface that is underlined and in blue indicate an active hyperlink to the code definition for that function or type definition. Click on the word to follow the hyperlink. This symbol VAR defined by the utility or input files. In code or in text, words in Italic Monospace indicate placeholder names for variable information that must be supplied (i.e., arguments).

Bold Monospace
$(VAR)

Italic Monospace

Note: Due to management and file size considerations, only the first occurrence of the reference on

each page is an active link. Subsequent references on the same page will not be actively linked to the definition and will use the standard, non-underlined BOLD Monospace typeface. Find the first instance of the name (in the underlined BOLD Monospace typeface) on the page and click on the word to jump to the function or type definition.

The following typographic conventions are used in this document to illustrate the Extended Backus-Naur Form.
[item] {item} <item> Square brackets denote the enclosed item is optional. Curly braces denote a choice or selection item, only one of which may occur on a given line. Angle brackets denote a name for an item.

May 2010

Version 1.22

FDF

Introduction

(range-range)

Parenthesis with characters and dash characters denote ranges of values, for example, (a-zA-Z0-9) indicates a single alphanumeric character, while (0-9) indicates a single digit. Characters within quotation marks are the exact content of an item, as they must appear in the output text file. The question mark denotes zero or one occurrences of an item. The star character denotes zero or more occurrences of an item. The plus character denotes one or more occurrences of an item. A superscript number, n, is the number occurrences of the item that must be used. Example: (0-9)8 indicates that there must be exactly eight digits, so 01234567 is valid, while 1234567 is not valid. A superscript number, n, within curly braces followed by a comma , indicates the minimum number of occurrences of the item, with no maximum number of occurrences. A superscript number, n, within curly brackets, preceded by a comma ,indicates a maximum number of occurrences of the item. A super script number, n, followed by a comma , and a number, m, indicates that the number of occurrences can be from n to m occurrences of the item, inclusive.

item ? * + item{n}

item{n,}

item{,n} item{n,m}

Version 1.22

May 2010

Introduction

FDF

May 2010

Version 1.22

FDF

FDF Design Discussion

2 FDF Design Discussion

This section of the document provides an overview to processing Flash Description File (FDF) used to create firmware images, Option ROM images or bootable images for removable media. For the purposes of this design discussion, the FDF file will be referred to as FlashMap.fdf. By convention, the name "FlashMap.fdf" has been used for the flash description file. This is only a convention and developers can maintain different flash description files using different file names, for example a given size or model of flash part. The file can have any name, however it is recommended that developers use the FDF extension for all flash description files. The remainder of this document uses "FDF" instead of "Flash Description File." The EDK II Build generates UEFI 2.3 and PI 1.2 compliant binary images. The tools provided in the EDK and the EdkCompatibilityPkg module support earlier versions of the specifications. Because PI 1.2 describes a new flash format, modules written for previous specifications that touch flash must be modified to work with the new flash image format.

Note: Path and Filename elements within the FDF are case-sensitive in order to support building on
UNIX style operating systems. The backslash "\"character is not used for the same reason.

2.1 Processing Overview

The FDF file describes information about flash parts as well as rules for combining binaries (Firmware Image) built from a DSC file. Additionally, if a DSC file specifies a FLASH_DEFINITION file, then the EDK II parsing utilities will scan the FDF file to gather PCD information that can be used by AutoGen utilities for building components or modules. The output of the first phase of an EDK II build (as defined in the EDK II Build Specification) generates valid PE32/PE32+/Coff image files. The second phase of the build process consumes the images generated during the first phase, using statements and rules defined in the FDF file to process the PE32/PE32+/Coff images files into one or more EFI sections. The EFI sections may get combined with other optional sections (version, depex, user interface) sections, into EFI Firmware File system (FFS) Sections. FFS images are put into Firmware Volumes (FVs,) and finally, the FV sections are combined into one or more Flash Device binary image (FD). The following diagrams illustrate the process flow for generating the PE/PE32+/Coff files that will be used for Flash Image files.

Version 1.22

May 2010

FDF Design Discussion

FDF

Figure 1. EDK II Build Data Flow

The following diagram shows the overview of the process used to create final image files. Figure 2. EDK II Create Image Flow

It should be noted that some SEC, PEI_CORE and/or PEIM modules are coded XIP (eXecute In Place) running directly from ROM, rather than from memory. For modules that always execute from ROM, the relocation (.reloc) section of the PE32 image can be removed (after running a fix up tool) as a space saving technique. Some PEIM modules may run from either ROM or from memory. There are several methods that can be used to retain this information (as well as the .reloc sections of stripped images). Due to this possibility, the SEC, PEI_CORE and PEIM descriptions are different from the remaining module types. The default for all SEC, PEI_CORE and PEIM modules is to strip the .reloc section. The modules coded to use REGISTER_FOR_SHADOW should not have the .reloc section stripped. Also of note, not all of the INF files listed in the FDF file need to be listed in the DSC file. Since the DSC file is primarily used to generate makefiles for a build, binary only modules do not need to be listed in a DSC file, and can be listed in the FDF file.

10

May 2010

Version 1.22

FDF

FDF Design Discussion

2.1.1 Platform Configuration Database (PCD) Settings

The FD, FV and Capsule sections (and nested sections) permit setting PCD default values. The PCDs set in the FDF file should only be for Addresses, Sizes, and/or other "fixed" information needed to define or create the flash image. Use of PCDs is permitted in the FDF file. The PatchableInModule, Dynamic and DynamicEx PCDs can be accessed or modified during execution.

Note: The PCD values set in this file are assumed to be correct on all conditions that the reset vector in
SEC is executed, such as power-on, reset and ACPI S3 resume. Use of PatchableInModule, Dynamic and DynamicEx PCD types for base addresses is permitted, but when these PCD types are used, module implementations must always access these values through the PcdGet and PcdSet operations to guarantee that stale base address values are never used.

All FLASH related PCD settings MUST be set in the FDF file, not in the platform description (DSC) file. The FDF file has the final values for Flash Related PCDs. If a DSC file contains a duplicate PCD setting, the FDF file's PCD setting takes precedence and build tools should throw a warning message on the PCD defined in the DSC file. Default values from DEC files are not permitted in the EDK II build system for PCDs specified in the FDF file. Additionally, the PCDs used in the FDF file must be specified as:
PcdTokenSpaceGuidCName.PcdCName.

2.2 Flash Description File Format

The EDK II FDF file describes the layout of UEFI/PI compliant binary images located within hardware, removable media or update capsules. The binary files must already exist in order for the build tools to create the final images. Some content, such as PCD definitions, may be used during the creation of binary files.

2.2.1 Section Entries

This description file consists of sections delineated by section names enclosed within square "[]" brackets. Section names are case-insensitive. The different sections and their usage are described below. The text of a given section can be used for multiple section names by separating the section names with a comma. For example:
[Rule.IA32.SEC, Rule.X64.SEC]

The content below each section heading is processed by the parsing utilities in the order that they occur in the file. The precedence for processing these architecture section tags is from right to left, with sections defining an architecture having a higher precedence than a section which uses "common" (or no architecture extension) as the architecture modifier.
Warning: Content within a section IS case sensitive. IA32, Ia32 and ia32 within a section are processed as separate items. (Refer to Naming Conventions below for more information on directory and/or file naming.)

Sections are terminated by the start of another section or the end of the file.

2.2.2 Comments
The hash "#" character indicates comments in the FDF file. In line comments terminate

Version 1.22

May 2010

11

FDF Design Discussion

FDF

the processing of a line unless the preceding character is the extension (backslash \) character. In line comments must be placed at the end of the line, and may not be placed within the section ("[", "]") tags. Only "BsBaseAddress = 0x0000C1000" in the following example is processed by tools; the remainder of the line is ignored:
BsBaseAddress = 0x0000C100 # set boot driver base address

Note: Blank lines and lines that start with the hash # character must be ignored by tools.
Hash characters appearing within a quoted string are permitted, with the string being processed as a single entity. The following example must handle the quoted string as single element by tools.
UI = " # Copyright 2007, NoSuch, LTD. All rights reserved."

Comments are terminated by the end of line.

2.2.3 Valid Entries

Comments must be scripting style, starting with the hash "#" character. Processing of a line is typically terminated by the end of the line. Processing of the line is also terminated if a comment is encountered unless the line is extended using the continuation (backslash \) character. Use of the backslash character \ is permitted to extend lines before or after field separators |, assignment operators = as well as on space characters that are natural boundaries within a LVALUE, such as between different flag values (See Valid Line Extension Examples, below) in all sections of the EDK II meta-data documents. This character must be the last character on a line unless it is followed by a comment. The extension character must be preceded by a space character and must not be followed by a space character unless it is followed by a comment. Use of the backslash character within individual value elements (such as a directory path or a value that should not be split such as a quoted string) is not permitted.

2.2.4 Naming Conventions

The EDK II build infrastructure is supported under Microsoft* Windows*, Linux* and MAC OS/X operating systems. As a result of multiple environment support, all directory and file names are case sensitive. Additionally, the use of special characters in directory and file names is restricted to the dash -, underscore _ and period . characters. Under no circumstances can space characters be used in a directory or file names in EDK II. That said, the build tools must be able to process the tool definitions file: tools_def.txt (describing the location and flags for compiler and user defined tools) which will contain space characters in paths on Windows* systems. This file is the ONLY file that permits the use of space characters is a directory path. The EDK II Coding Style specification covers naming conventions for use within C Code files, and as well as specifying the rules for directory and file names. This section is meant to highlight those rules as they apply to the content of the FDF files. Directory Names must not contain space characters. Directory Names should only contain alphanumeric characters, while the "_" underscore, "-" dash and "." period characters permitted. Directory names should start with an alpha character.

12

May 2010

Version 1.22

FDF

FDF Design Discussion

Additionally, all EDK II directories that are architecturally dependent must use a name with only the first character capitalized. Ia32, Ipf, X64 and Ebc are valid architectural directory names. IA32, IPF and EBC are not acceptable directory names, and may cause build breaks. From a build tools perspective, IA32 is not equivalent to Ia32 or ia32. Architecture keywords (IA32, IPF, X64 and EBC) are used by build tools and in metadata files for describing alternate threads for processing of files. These keywords must not be used for describing directory paths. Additionally, directory names with architectural names (Ia32, Ipf, X64 and Ebc) do not automatically cause the build tools or meta-data files to follow these alternate paths. Directories and Architectural Keywords are similar in name only. All directory paths within EDK II FDF files must use the "/" forward slash character to separate directories as well as directories from filenames. Example:
C:/Work/Edk2/edksetup.bat

File names should also follow the same naming convention required for directories. No space characters are permitted. The special characters permitted in directory names are the only special characters permitted in file names.

2.2.5 !include Statements

The !include statement may appear within an EDK II FDF file. The included file content must match the content type of the current section definition. The argument of this statement is a filename. The full path, relative to the $(WORKSPACE) variable may be given, as in $(WORKSPACE)/Conf/MyIncludeFile.txt, or it may be just the filename, MyIncludeFile.txt. If the later case, parsing tools must check the directory containing this FDF file, and if not found, check the directory containing the platform description (DSC) file (if it is different). If the file is not found, the parsing tools should terminate with an error. Files specified by !include statements may not contain !include statements.

2.2.6 Macro Statements

Variables (or macros) used within the FDF file are typically used for path generation for locating files. The format for specifying a short-cut is:
DEFINE MACRO_NAME = PATH

Additionally, pre-defined variables may be usin in the body of the FDF file. The following is an example of using pre-defined variables:
FILE = $(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/FV/Microcode.bin

The following table lists the global variables permitted in generating a path statement as well as variables that can be passed as an argument for a rule.

Version 1.22

May 2010

13

FDF Design Discussion

FDF

Note: Macro definitions from the DSC files [defines] section may also be used in the FDF file without
having to redefine them here. Table 2. Valid Variable Names for PATH statements
Exact Notation Derivation System Environment Variable. System Environment Variable. System Environment Variable. Tool parsing from either the DSC file or via a command line option. Tool parsing from either an EDK INF file or the EDK II DSC files BUILD_NUMBER statement. The EDK II DSC files BUILD_NUMBER takes precedence over an EDK INF files BUILD_NUMBER if and only if the EDK II DSC specifies a BUILD_NUMBER. Future implementation may allow for setting the BUILD_NUMBER variable on the build tools command line.

$(WORKSPACE) $(EDK_SOURCE) $(EFI_SOURCE) $(OUTPUT_DIRECTORY) $(BUILD_NUMBER)

$(NAMED_GUID) $(MODULE_NAME) $(INF_VERSION) $(TARGET)

Tool parsing FILE_GUID statement in the INF file. Tool parsing the BASE_NAME statement in the INF file. Tool parsing the VERSION or VERSION_STRING statement in the INF file. Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line options. Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line options. Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line options.

$(TOOL_CHAIN_TAG)

$(ARCH)

Note: Recommendation: Do not use the $(ARCH) variable in the FDF file unless absolutely necessary.
Additionally, the macros may be used in conditional directive statements located within the FDF file. All MACRO definitions in the FDF file are local to the FDF file. Specific usage of these values within each FDF section is specified in chapter 3 of this document.

2.2.7 PCD Names

Unique PCDs are identified using the format to identify the named PCD:
PcdTokenSpaceGuidCName.PcdCName

The PCD's Name (PcdName) is defined as PCD Token Space Guid C name and the PCD C name - separated by a period "." character.

2.2.8 Conditional Statements (!if...)

Conditional statements are used by the build tools preprocessor function to include or exclude statements in the FDF file. Statements are prefixed by the exclamation "!" character. Conditional statements may appear anywhere within the FDF file.

14

May 2010

Version 1.22

FDF

FDF Design Discussion

Note: A limited number of statements are supported. This specification does not support every conditional statement that C programmers are familiar with.
Supported statements are:
!ifdef, !ifndef, !if, !elseif, !else and !endif

The following is an example of conditional statements.

!ifdef $(FOO) !ifndef $(BAR) # FOO defined, BAR not defined !else # FOO defined, BAR is defined !endif !elseif $(BARFOO) # FOO is not defined, BARFOO is defined as TRUE !elseif $(BARFOO) == "FOOBAR" # FOO is not defined, BARFOO is defined as FOOBAR !else # FOO is not defined while BARFOO is either NOT defined or does not equal "FOOBAR" !endif

2.3 [FD] Section

The [FD] section is made up of the definition statements and a description of what goes into the Flash Device Image. Each FD section defines one flash "device" image. A flash device image may be one of the following: Removable media bootable image (like a boot floppy image,) a System "Flash" image (that would be burned into a system's flash) or an Update ("Capsule") image that will be used to update and existing system flash. Multiple FD sections can be defined in a FDF file. The section header format is [FD.$(FdUiName)] where the $(FdUiName) can be any value defined by the user. If only a single FD is constructed for a platform then $(FdUiName) is optional, and the processing tools will use the DSC file [Defines] section's PLATFORM_NAME value for creating the FD file. An FD section is terminated by any other section header section or the end of the file. This section is required for platform images, and not required for OptionROM images.

2.3.1 FD TOKEN Statements

The Token statements are used to define the physical part. These include the base address of the image, the size of the image, the erase polarity and block information. Only one of each of the valid token names can be defined in any one FD section, except as noted below.
$(Token) = $(VALUE) [| PcdName]

Only one token statement can appear on a single line, and each token statement must be on a single line. Multi-line token statements are not permitted. There are five valid Token names defined by this specification. BaseAddress
The base address of the FLASH Device.

Version 1.22

May 2010

15

FDF Design Discussion

FDF

Size
The size in bytes of the FLASH Device

ErasePolarity
Either 0 or 1, depending on the erase polarity of the Flash Device.

BlockSize
One or More - Size of a block, optionally followed by number of blocks. Multiple BlockSize statements are legal, and the first statement represents block 0 (the first block) and subsequent BlockSize statements represent blocks 1 - N.

NumBlocks
Zero or one - The number of continuous blocks of size, BlockSize. If NumBlocks is not present, the number of blocks defaults to 1.

An optional PcdName may follow the Token statement and is separated from the statement using a pipe "|" character. The PcdName is assigned $(VALUE). Only one PcdName can be assigned a Token's Value.

2.3.2 FD DEFINE statements

DEFINE statements are used to define MACRO definitions that are scoped to the individual FD sections. DEFINE statements are processed in order, so a later DEFINE statement for a given MACRO over-writes the previous definition. The DEFINE statements are typically used for creating short-cut names for directory path names but may be used for identifying other items or values that will be used in later statements. DEFINE $(MACRO) = $(PATH)

The following are examples of the DEFINE statement.

DEFINE DEFINE DEFINE DEFINE DEFINE FV_DIR = $(OUT_DIR)/$(TARGET)_$(TOOL_CHAIN_TAG)/$(ARCH) MDE_MOD_TSPG = gEfiMdeModulePkgTokenSpaceGuid NV_STOR_VAR_SIZE = PcdFlashNvStorageVariableSize FV_HDR_SIZE = 0x48 VAR_STORE_SIZE = $(MDE_MOD_TSPG).$(NV_STOR_VAR_SIZE) - $(FV_HDR_SIZE)

The $(MACRO) can be used elsewhere within the FDF, and is used to create a shorthand notation that can be used elsewhere within the FDF file. When tools process this file, the $(MACRO) name will be expanded in commands or files emitted from the tools. In the following example, $(OUTPUT_DIRECTORY) is a variable, whose value is found in the platform's DSC file, and this file assigns OUT_DIR as the variable name to use, with the same value as $(OUTPUT_DIRECTORY):
DEFINE OUT_DIR = $(OUTPUT_DIRECTORY) DEFINE FV_DIR = $(OUT_DIR)/$(TARGET)_$(TOOL_CHAIN_TAG)/$(ARCH)/FV

If the DSC file declares OUTPUT_DIRECTORY = $(WORKSPACE)/Build/Nt32, TARGET = DEBUG, target.txt uses MYTOOLS for the tool chain, and the platform is IA32, then a statement later in the section that references $(FV_DIR) is interpreted by the tools as being:
$(WORKSPACE)/Build/Nt32/DEBUG_MYTOOLS/IA32/FV

2.3.3 FD SET statements

SET statements are used to define the values of PCD statements. The current PCD maps for regions include extra PCD entries that define properties of the region, so the SET statement can occur anywhere within an FD section. SET statements that occur before any region layout section is a global setting for this FD. SET statements that occur within a FD's region layout section are valid for the

16

May 2010

Version 1.22

FDF

FDF Design Discussion

individual region only. Unlike the DEFINE $(MACRO), the token $(PcdName) cannot be used within the FDF file - other instances within FVs or other FDs can be specified, but using "$(PcdName)" as a variable (shown below) is not permitted.
SET $(PcdName) = $(VALUE)

Additionally, a PCD Name is made up of two parts, separated by a period "." character. The format for a PcdName is:
PcdTokenSpaceGuidCName.PcdCName

The following is an example of the SET statement:

SET gFlashDevicePkgTokenSpaceGuid.PcdEfiMemoryMapped = TRUE

The $(VALUE) specified must match the PCD's datum type and must be the content data. For a PCD that has a datum type of VOID*, the data can be a Unicode string, as in L"text", a valid C data array, as in {0x20015000, 0x32FF, 0x00AA, {0xFFF0000, 0x00}} or a hex value, as in 0x0000000F. The Value may also be computed, using arithmetic operations, arithmetic expressions and or logical expressions. The value portion of the SET statement, when using any of these computations are in-fix expressions that are evaluated left to right, with items within parenthesis evaluated before the outer expressions are evaluated. Use of parenthesis is encouraged to remove ambiguity.

2.3.4 FD Region Layout

Following the FD defines section are lists of Regions which correspond to the locations of different images within the flash device. Currently most flash devices have a variable number of blocks, all of identical size. When "burning" an image into one of these devices, only whole blocks can be burned into the device at any one time. This puts a constraint that all layout regions of the FD image must start on a block boundary. To accommodate future flash parts that have variable block sizes, the layout is described by the offset from the BaseAddress and the size of the section that is being described. Since completely filling a block is not probable, part of the last block of a region can be left empty. To ensure that no extraneous information is left in a partial block, the block should be erased prior to burning it into the device. Regions must be defined in ascending order and may not overlap. A layout region start with an eight digit hex offset (leading "0x" required) followed by the pipe "|" character, followed by the size of the region, also in hex with the leading "0x" characters. The layout region is terminated by the start of another region or an FV Section header. The format for an FD Layout Region is:
Offset|Size [TokenSpaceGuidCName.PcdOffsetCName|TokenSpaceGuidCName.PcdSizeCName]? [RegionType]?

Setting the optional PCD names in this fashion is shortcut. The two regions listed below are identical, with the first example using the shortcut, and the second using the long method:

Version 1.22

May 2010

17

FDF Design Discussion

FDF

0x000000|0x0C0000 gEfiMyTokenSpaceGuid.PcdFlashFvMainBaseAddress| \ gEfiMyTokenSpaceGuid.PcdFlashFvMainSize FV = FvMain 0x000000|0x0C0000 SET gEfiMyTokenSpaceGuid.PcdFlashFvMainBaseAddress = 0x000000 SET gEfiMyTokenSpaceGuid.PcdFlashFvMainSize = 0x0C0000 FV = FvMain

The shortcut method is preferred, as the user does not need to maintain the values in two different locations. The RegionType, if specified, must be one of the following FV, DATA, or FILE. Not specifying the RegionType implies that the region starting at the "Offset", of length "Size" should not be touched. This type of region is typically used for event logs that are persistent between system resets, and modified via some other mechanism (and SMM Event Log module, for example).

Note: Although subregions existed in EDK FDF files, EDK II FDF does not use the concept of
subregions.

2.3.4.1 FV RegionType
The FV RegionType is a pointer to either one of the unique FV names that are defined in the [FV] section or a file specified in an [FV] section's CREATE_FILE = statement. Both of these are files that contains a binary FV as defined by the PI 1.0 specification. The format for the FV RegionType is one of the following:
FV = $(UiFvName)

Or
FV = $(Filename)

Where $(Filename) is a filename defined by the [FV] section's CREATE_FILE = <Filename> statement. The following is an example of FV region type:
0x000000|0x0C0000 gEfiMyTokenSpaceGuid.PcdFlashFvMainBaseAddress \ |gEfiMyTokenSpaceGuid.PcdFlashFvMainSize FV = FvMain

2.3.4.2 DATA RegionType

The DATA RegionType is a region that contains is a hex value or an array of hex values. This data that will be loaded into the flash device, starting at the first location pointed to by the Offset value. The format of the DATA RegionType is:
DATA = { <Hex Byte Data Structure> }

The following is an example of a DATA region type.

0x0CA000|0x002000 gEfiMyTokenSpaceGuid.PcdFlashNvStorageBase| \ gEfiMyTokenSpaceGuid.PcdFlashNvStorageSize DATA = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C }

The !include statement is valid for hex array portion of the DATA RegionType. The

18

May 2010

Version 1.22

FDF

FDF Design Discussion

following is a valid usage for the !include statement.

0x0CA000|0x002000 gEfiMyTokenSpaceGuid.PcdFlashNvStorageBase| \ gEfiMyTokenSpaceGuid.PcdFlashNvStorageSize DATA = { !include NvStoreInit.txt }

2.3.4.3 FILE RegionType

The FILE RegionType is a pointer to a binary file that will be loaded into the flash device, starting at the first location pointed to by the Offset value. The format of the FILE RegionType is:
FILE = $(FILE_DIR)/Filename.bin

The following is an example of the FILE RegionType.

0x0CC000|0x002000 gEfiCpuTokenSpaceGuid.PcdCpuMicrocodePatchAddress| \ gEfiCpuTokenSpaceGuid.PcdCpuMicrocodePatchSize FILE = FV/Microcode.bin

2.3.4.4 Capsule RegionType

The CAPSULE RegionType is a pointer to a capsule section UiName that will be loaded into the flash device, starting at the first location pointed to by the Offset value. The format of the FILE RegionType is:
CAPSULE = UiCapsuleName

The following is an example of the CAPSULE RegionType.

0x0CC000|0x002000 gEfiTokenSpaceGuid.PcdCapsuleOffset| \ gEfiTokenSpaceGuid.PcdCapsuleSize CAPSULE = MyCapsule

2.3.4.5 No RegionType Specified

It is permissible to define a region with no data pre-loaded. For example, event logging needs a data region to store events. This region is filled with data that matches the ErasePolarity bit during the initial installation of the firmware or through UEFI or operating system commands and services. An example of no region type specified is:
0x0CE000|0x002000 gEfiMyTokenSpaceGuid.PcdFlashNvStorageEventLogBase| \ gEfiMyTokenSpaceGuid.PcdFlashNvStorageEventLogBase

2.4 [FV] Section

The [FV] sections are required for platform images, are optional for Capsule images, and are not required for Option ROM only images. The [FV] section defines what components or modules are placed within a flash device file. These sections define the order the components and modules are positioned within the image. The [FV] section consists of define statements, set statements and module statements. A single [FV] section is terminated by the start of another section header or the end of the file. The [FV] section has one required modifier, a user defined section name. The format for

Version 1.22

May 2010

19

FDF Design Discussion

FDF

[FV] section header is: [FV.$(UiFvName)]

The FV $(UiFvName) must be unique for every declared user defined name within the file. The UiFvName is used for specifying the file that will be used in and [FD] section. Nesting of [FV] sections is permitted, making it possible to create a tree structure containing multiple FV sections within a single [FV] section. Nested sections are specified using either the syntax "FILE FV_IMAGE = Name" or "SECTION FV_IMAGE = Name" within the top [FV] Section. Use of the $(UiFvName) modifier permits the user to include, by UiFvName, previously defined sections within another FV section. This eliminates the need to re-specify components or modules in multiple places. This section also specifies how to define content for PI FV Extensions which provides a mapping between a GUID and an OEM file type. The size of EFI_FIRMWARE_VOLUME_EXT_HEADER and EFI_FIRMWARE_VOLUME_EXT_ENTRY sizes will be calculated based on content, while the EFI_FIRMWARE_VOLUME_EXT_ENTRY type must be defined by the platform integrator based on the PI specification, volume 3. The content is limited to the contents of a binary file specified by a FILE statement or a data array specified by a DATA statement. The EFI_FIRMWARE_VOLUME_EXT_ENTRY_OEM_TYPE (using TYPE=0x0001) is only support by including a file or data structure that completes the remainder of the OEM type entry, where the first entry would have to be a UINT32 representing the TypeMask. Additional types defined by the PI spec will be supported in this manner as well.

2.4.1 DEFINE Statements

DEFINE statements are used to define Macro definitions that are scoped to the individual [FV] sections. DEFINE statements are processed in order, so a later DEFINE statement for a given MACRO over-writes the previous definition for the remainder of the section or

sub-section. The DEFINE statements are typically used for creating short-cut names for directory path names, but may be used for identifying other items or values that will be used in later statements.
DEFINE $(MACRO) = $(PATH)

The following are examples of the DEFINE statement.

DEFINE DEFINE DEFINE DEFINE DEFINE EDKMOD = $(WORKSPACE)/EdkModulePkg/ MDE_MOD_TSPG = gEfiMdeModulePkgTokenSpaceGuid NV_STOR_VAR_SIZE = PcdFlashNvStorageVariableSize FV_HDR_SIZE = 0x48 VAR_STORE_SIZE = $(MDE_MOD_TSPG).$(NV_STOR_VAR_SIZE) - $(FV_HDR_SIZE)

2.4.2 Block Statements

BLOCK_ statements are used to define block size and the number of blocks that are needed for FV images that do NOT get put into a physical flash part, such as the recovery image that gets put on a floppy or USB key. BLOCK_SIZE = $(VALUE) NUM_BLOCKS = $(VALUE)

The following is an example of the BLOCK statement:

20

May 2010

Version 1.22

FDF

FDF Design Discussion

BLOCK_SIZE = 512

2.4.3 FV SET Statements

SET statements are used to define the values of PCDs. SET statements globally set a PcdName to a VALUE for this FV. SET <PcdName> = $(VALUE)

The following is an example of the SET statement:

SET gEfiMyTokenSpaceGuid.PcdDisableOnboardVideo = TRUE

The $(VALUE) specified must match the Pcd's datum type and must be the content data. For a PCD that has a datum type of VOID*, the data can be a Unicode string, as in L"text", a valid C data array, as in {0x20002000, 0x32FF, 0x00AA, {0xFFF0000, 0x00}} or a hex value, as in 0x0000000F. The Value may also be computed, using arithmetic operations, arithmetic expressions and or logical expressions. The value portion of the SET statement, when using any of these computations are in-fix expressions that are evaluated left to right, with items within parenthesis evaluated before the outer expressions are evaluated. Use of parenthesis is encouraged to remove ambiguity.

2.4.4 APRIORI Scoping

Within some firmware volumes, an APRIORI file can be created which is a GUID named list of modules in the firmware volume. The modules will be invoked or dispatched in the order they appear in the APRIORI file. Within a Firmware Volume, only one PEI and one DXE Apriori file are permitted. Since nested Firmware Volumes are permitted, Apriori files are limited to specifying the files, not FVs that are within the scope of the FV image in which it is located. (It is permissible for nested FV images to have one PEI and one DXE Apriori file per FV.) Scoping is accomplished using the curly "{}" braces. The following example demonstrates an example of multiple APRIORI files.

Version 1.22

May 2010

21

FDF Design Discussion

FDF

[Fv.Root] DEFINE NT32 = $(WORKSPACE)/EdkNt32Pkg DEFINE BuildDir = \ $(OUTPUT_DIRECTORY)/$(PLATFORM_NAME)/$(TARGET)_$(TOOL_CHAIN_TAG) APRIORI DXE { FILE DXE_CORE = B5596C75-37A2-4b69-B40B-72ABD6DD8708 { SECTION COMPRESS { SECTION PE32 = \ $(BuildDir)/X/Y/Z/B5596C75-37A2-4b69-B40B-72ABD6DD8708-DxeCore.efi SECTION VERSION "1.2.3" } } INF VERSION = "1" ${NT32)/Dxe/WinNtThunk/Cpu/Cpu.inf } FILE FV_IMAGE = EF41A0E1-40B1-481f-958E-6FB4D9B12E76 { SECTION GUIDED 3EA022A4-1439-4ff2-B4E4-A6F65A13A9AB { SECTION FV_IMAGE = Dxe { APRIORI DXE { INF a/a/a.inf INF a/c/c.inf INF a/b/b.inf } INF a/d/d.inf } } }

In the example above, There are three FFS files in the Fv.Root and one Encapsulated FV image, with the build tools creating an APRIORI file that will dispatch the DXE_CORE first, then the CPU module second. In the FV image, named Dxe, there will be at least five FFS files, the APRIORI file, listing the GUID names of a.inf, c.inf and b.inf, which will be dispatched in this order. Once complete, the d.inf module will be dispatched.

2.4.5 INF Statements

The INF statements point to EDK component and EDK II module INF files. Parsing tools will scan the INF file to determine the type of component or module. The component or module type is used to reference the standard rules defined elsewhere in the FDF file. The format for INF statements is:
INF [Options] $(PathAndInfFileName)

Using an INF statement will cause the build tools to implicitly build an FFS file with the EFI_FV_FILETYPE based on the INF module's MODULE_TYPE and content. For example, specifying the following lines in an FV section will generate an FFS file with an EFI_FV_FILETYPE_DRIVER with three sections, the EFI_SECTION_PE32, an EFI_SECTION_VERSION, and an EFI_SECTION_DXE_DEPEX. While there is no version file defined in the INF - it has been specified by the VERSION option; and there is a dependency file specified in the INF file's source file list.
DEFINE EDKMU = $(WORKSPACE)/EdkModulePkg/Universal INF VERSION = "1.1" $(EDKMU)/GenericMemoryText/Dxe/NullMemoryTest.inf

Valid options for the INF file line are:

22

May 2010

Version 1.22

FDF

FDF Design Discussion

RULE_OVERRIDE = RuleName
This permits the platform integrator with a method to override the default rules built into tools, specified in the EDK II Build Specification which follows the UEFI and PI specifications for EFI FileType construction. The default rules are implied by the processor and module type. Using the explicit named rule here may compromise the platform's PI specification compliance. The RuleName is named in a different section of this FDF file.

USE = $(CODE)
The USE = $(CODE) option is used to differentiate if a single INF file is built different ways, for example a single INF file is called out multiple times in the DSC file. Example build the same module for more than one processor architecture. The final value of $(Code) must be of the format $(TARGET)_$(TAGNAME)/$(ARCH). Refer to the $(TARGET), $(TAGNAME) and $(ARCH) definitions below for more information.

VERSION = "String"
The VERSION option is used to create an EFI_SECTION_VERSION section with the FFS file.

UI = "String"
The UI option is used to create an EFI_SECTION_USER_INTERFACE section for an INF that may not have specified one.

$(TARGET)
One and Only One of the valid targets listed in the Platform DSC's [Defines] section, BUILD_TARGETS expression, restricted by the TARGET expression in the targets.txt file. It is up to the developer to ensure that the TARGET has been used to create the PE32/PE32+/Coff image files.

$(TAGNAME)
One of the TOOL_CHAIN_TAG names listed in the tools_def.txt file. It is up to the developer to ensure that the TOOL_CHAIN_TAG has been used to create the PE32/ PE32+/Coff image files.

$(ARCH)
One of the supported architectures listed in the Platform DSC's [Defines] section, SUPPORTED_ARCHITECTURES expression, restricted by the TARGET_ARCH expression in the targets.txt file. It is up to the developer to ensure that the ARCH has been used to create the PE32/PE32+/Coff image files.

The following are examples of INF statements:

DEFINE EDKM = $(WORKSPACE)/EdkModulePkg INF USE = $(Code) $(EDK_SOURCE)/Sample/Universal/Network/Ip4/Dxe/Ip4.inf INF $(EDK_SOURCE)/Sample/Universal/Network/Ip4Config/Dxe/Ip4Config.inf INF RULE_OVERRIDE = CustomDxeCoreCompress $(EDKM)/Core/Dxe/DxeMain.inf

2.4.6 FILE Statements

FILE statements are provided so that a platform integrator can include complete EFI FFS files, as well as a method for constructing FFS files using curly "{}" brace scoping.

FFS file specification syntax is one of the following:

FILE Type $(NAMED_GUID) [Options] FileName

OR

Version 1.22

May 2010

23

FDF Design Discussion

FDF

FILE Type $(NAMED_GUID) [Options] { SECTION SECTION_TYPE = FileName SECTION SECTION_TYPE = FileName }

The first statement is commonly used with EFI_FV_FILETYPE_RAW files, while the second type is used for most other file types. The FileName is typically a binary file, and the consumer of this type of file must have an a priori knowledge of the format. The following describes the information that can be specified a File: Type
EFI FV File Types - one and only one of the following: RAW - Binary data FREEFORM - Sectioned binary data SEC - Sectioned data consisting of an optional pad section, a terse section and an optional raw section. PEI_CORE - Sectioned data consisting of one PE32, one user interface and one version section. DXE_CORE - Sectioned data containing one or more other sections. PEIM - Dispatched by PEI Core DRIVER - Dispatched by DXE core COMBO_PEIM_DRIVER - Combined PEIM/DXE driver containing PEI and DXE depex sections as well as PE32 and version sections. SMM_CORE - Sectioned data containing one or more other sections. DXE_SMM_DRIVER - Dispatched by the SMM Core APPLICATION - Application, so will not be dispatched FV_IMAGE - File contains an FV image 0x00 - 0xFF - Hex values are legal too. See PI specification Volume 3 for details

NAMED_GUID
The $(NAMED_GUID) is usually constructed from an INF file's [Defines] section FILE_GUID element.

Options
The Fixed and Checksum attributes are boolean flags, both default to FALSE, specifying "Fixed" enables the flag to TRUE. The Alignment attribute requires the "= value". Fixed - File can not be moved, default (not specified) is relocate-able. Alignment - Data (value is one of: 1, 2. 4, 8, 16, 32, 64 128, 512, 1K, 2K, 4K, 8K, 16K, 32K, 64K) byte aligned Checksum - This should normally be controlled on an entire FV basis not at the file level, however, we are including this attribute for completeness.

UEFI and PI Specifications have rules for file type construction that, by default, will be used by the tools. In addition to the arguments on the FILE line, for EFI FV File types that are not RAW, additional EFI section information must be specified. To specify additional section information for a file, the EFI Encapsulation Sections must be contained within curly "{}"braces that follow the FILE line, while leaf sections are denoted by an EFI_SECTION type keyword. Encapsulation and leaf section types are described below. The following is an example for using additional sections:
#Encapsulation - Compress

24

May 2010

Version 1.22

FDF

FDF Design Discussion

FILE FOO = 12345678-0000-AAAA-FFFF-0123ABCD12BD { SECTION COMPRESS { SECTION PE32 = $(WORKSPACE)/EdkModulePkg/Core/Dxe/DxeMain.inf SECTION VERSION = "1.2.3" } } # Encapsulation - GUIDED FILE FV_IMAGE = 87654321-FFFF-BBBB-2222-9874561230AB { SECTION GUIDED gEfiTianoCompressionScheme { SECTION PE32 = $(WORKSPACE)/EdkModulePkg/Core/Dxe/DxeMain.inf } } # LEAF Section FILE DXE_CORE = B5596C75-37A2-4b69-B40B-72ABD6DD8708 { SECTION VERSION \ $(BUILD_DIR)/$(ARCH)/D6A2CB7F-6A18-4E2F-B43B-9920A733700A-DxeMain.ver }

2.4.6.1 EFI Encapsulation Sections

There are two types of encapsulation sections, a COMPRESSION section and the GUIDED section. The COMPRESS encapsulation section uses the following format.
SECTION COMPRESS [type] { SECTION EFI_SECTION_TYPE = FILENAME SECTION EFI_SECTION_TYPE = "string" }

The [type] argument is optional, only EFI_STANDARD_COMPRESSION is supported by the PI specification. The current EDK enumerations for compression are a violation of the PI specification, and SECTION GUIDED should be used instead. The EFI_SECTION_TYPE and FILENAME are required sub-elements within the compression encapsulation section. for most sections. However both the VERSION (EFI_SECTION_VERSION) and UI (EFI_SECTION_USER_INTEFACE) may specify a string, that will be used to create an EFI section. The GUIDED encapsulation section uses one of the following formats.
SECTION GUIDED $(GUID_CNAME) [auth] { SECTION EFI_SECTION_TYPE = FILENAME SECTION EFI_SECTION_TYPE = "string" } SECTION GUIDED $(GUID_CNAME) [auth] FILENAME

The required argument is the GUIDED name followed by an optional "auth" flag. If the argument "auth" flag is specified, then the attribute EFI_GUIDED_SECTION_AUTH_STATUS_VALID must be set. For non-scoped statements (the second SECTION statement of the two listed above,) if filename exists the Attribute EFI_GUIDED_SECTION_PROCESSING_REQUIRED must be set to TRUE. The file pointed to by filename is the data. If filename does not exist EFI_GUIDED_SECTION_PROCESSING_REQUIRED is cleared and normal leaf sections must be used.

Version 1.22

May 2010

25

FDF Design Discussion

FDF

2.4.6.2 EFI Leaf Sections

Leaf sections are identified using the EFI_SECTION Type, as specified in the UEFI specification. Arguments to the EFI_SECTION Type include information that will be used to build a leaf section. Nesting of leaf sections within leaf sections is not permitted, as a leaf section is defined as UEFI's smallest entity. The LEAF section is specified using the following format.
SECTION $(LEAF_SECTION) [build #] [Align=X] [Unicode String][Filename]

The following keywords are used for valid $(LEAF_SECTION) Types. PE32 PIC TE DXE_DEPEX SMM_DEPEX PEI_DEPEX VERSION -- Contains either a 16-bit build number or a Unicode string UI--Unicode String COMPAT16 FV_IMAGE LEAF_GUID-- An EFI_GUID and content defined by the GUID RAW

The argument, Build#, is only valid for VERSION leaf section. The number may be specified in the platform description (DSC) file's [Defines] section, BUILD_NUMBER element. EDK INF files may specify a BUILD_NUMBER in the defines section. However, this value is only used if the EDK II DSC file does not contain a BUILD_NUMBER statement. The Filename is only optional for VERSION and UI. A Unicode string is only valid for VERSION or UI if the Filename is not present, and is of the form L"string". The remaining leaf section types require the Filename argument. The file must contain the data for the section.

2.5 [Capsule] Section

The optional [Capsule] sections are used to define the components and modules that make up formatted, variable-length data structure. Capsules were designed for and are intended to be the major vehicle for delivering firmware volume changes to an existing implementation. An update capsule is commonly used to update the firmware flash image or for an operating system to have information persist across a system reset. A [Capsule] header section requires one modifier, the $(UiCapsuleName) modifier. Zero or more [Capsule] sections can be present in a FDF file. The following is the format for the [Capsule] section header:
[Capsule.$(UiCapsuleName)]

The first elements of a [Capsule] section are required Token elements, using the following format.

26

May 2010

Version 1.22

FDF

FDF Design Discussion

$(Token) = $(VALUE)

2.5.1 UEFI Implementation

The UEFI specification defines the EFI_CAPSULE_HEADER structure in the runtime services chapter. The header consists of the following elements. The following tokens are required in a capsule conforming to the UEFI 2.3 specification. EFI_CAPSULE_GUID
The GUID that defines the contents of a capsule, used by the EFI system table, which must point to one or more capsules that have the same EFI_CAPSULE_GUID value.

EFI_CAPSULE_HEADER_SIZE
Size in bytes of the capsule header. If the size specified here is larger than the size of the EFI_CAPSULE_HEADER, then the capsule GUID value implies extended header entries.

EFI_CAPSULE_FLAGS
Currently, three bit flags have been defined: PersistAcrossReset = CAPSULE_FLAGS_PERSIST_ACROSS_RESET InitiateReset = CAPSULE_FLAGS_INITIATE_RESET

and
PopulateSystemTable = CAPSULE_FLAGS_POPULATE_SYSTEM_TABLE

The value of the EFI_CAPSULE_IMAGE_SIZE, which is the size in bytes of the capsule, is determined by the tools. In order to use the InitiateReset flag, the PersistAcrossReset flag must also be set.

2.5.2 Capsule SET Statements

SET statements are used to define the values of PCD statements. SET statements are globally set for the [Capsule] section, those set under the [Capsule] section header are global for all <Capsule> sub-sections within the [Capsule] section. SET $(PcdName) = $(VALUE)

The following is an example of the SET statement.

SET gEfiMyTokenSpaceGuid.PcdSecStartLocalApicTimer = TRUE

The $(VALUE) specified must match the PCD's datum type and must be the content data. For a PCD that has a datum type of VOID*, the data can be a Unicode string, as in L"text", a valid C data array, as in {0x20002000, 0x32FF, 0x00AA, {0xFFF0000, 0x00}} or a hex value, as in 0x0000000F.

2.5.3 Capsule Data

EFI_CAPSULE_DATA follows the EFI_CAPSULE_HEADER token definitions in the [Capsule] section or <Capsule> sub-sections. The content consists of one or more of the following.

2.5.3.1 INF Statements

The INF statement syntax is common to the syntax used for [FV] sections. Refer to section 2.4.4 above.

2.5.3.2 FILE Statements

FILE statement syntax is common to the syntax used for [FV] sections. Refer to

Version 1.22

May 2010

27

FDF Design Discussion

FDF

Section 2.4.5.

2.6 [VTF] Section

The optional [VTF] sections specify information regarding the IPF Boot Strap File (BSF) or the IA32 Volume Top File (VTF). Both the $(ARCH) and the $(UiName) modifier fields are required. The [VTF] section terminates with either the start of another section, or the end of the file. The [VTF] section modifier usage is shown below.
[VTF.$(ARCH).$(UiName)]

Underneath the [VTF] section are specific statements defining information about the VTF file. EDK Bsf.inf files use two different sections, an [OPTIONS] section and a [COMPONENTS] section. For EDK II, the grammar of the [VTF] section statements defines these sections, rather than having separate sub-sections within the [VTF] section. The format for statements within the section is illustrated below.
STATEMENT_NAME = Value

2.6.1 Options Statement

One and only one options statement, "IA32_RST_BIN," is permitted within any one [VTF] section. This value is a path and name of IA32_BIOS reset vector binary (16 byte) file. If needed, this binary can be put into the VTF file.

2.6.2 Component Statements

Within the section, a components sub-section starts with the "COMP_NAME" statement, and terminates with either the start of another sub-section, major section or the end of the file. Certain values for component statements are enumerated values or values that are within a given, specification defined, range. Each of the component sections is used to complete a data structure, using the following sequence.
Name = Region, Type, Version, Checksum Flag, Path of Binary File, Path of the Symbol File, Preferred Size;

2.7 [Rule] Section

The optional [Rule] sections in the FDF file are used for combining binary images, not for compiling code. Rules are use with the [FV] section's module INF type to define how an FFS file is created for a given INF file. The EDK II Build Specification defines the default rules that are implicitly used for creating FFS files. The implicit rules follow the PI 1.2 Specification and UEFI 2.3 Specification. The [Rule] section of the FDF file is used to define custom rules, which may be applied to a given INF file listed in an [FV] section. This section is also used to define rules for module types that permit the user to define the content of the FFS file - when an FFS

28

May 2010

Version 1.22

FDF

FDF Design Discussion

type is not specified by either PI or UEFI specifications. The Rules can have multiple modifiers as shown below.
[Rule.$(ARCH).$(MODULE_TYPE).$(TEMPLATE_NAME)]

If no $(TEMPLATE_NAME) is given then the match is based on $(ARCH) and $(MODULE_TYPE) modifiers. The $(TEMPLATE_NAME) must be unique to the $(ARCH) and $(MODULE_TYPE). It is permissible to use the same $(TEMPLATE_NAME) for two or more [Rule] sections if the $(ARCH) or the $(MODULE_TYPE) listed are different for each of the sections. A [Rule] section is terminated by another section header or the end of file. The content of the [Rule] section is based on the FILE and section grammar of the FV section. The difference is the FILE referenced in the [RULE] is a MACRO. The section grammar is extended to include an optional argument, Optional. The Optional argument is used to say a section is optional. That is to say, if it does not exist, then it is O.K.

Note: The !include statement is valid for any part of the [Rule] section, including an entire [Rule]
section. The generic form of the entries for leaf sections is:
<SectionType> <FileType> [Options] [{<Filename>} {<Extension>}]

When processing the FDF file, the following rules apply (in order): 1. If <SectionType> not defined or not a legal name, then error 2. If <FileType> not defined or not a legal name, then error 3. If [FilePath/FileName], then: Add one section to FFS with a section type of <SectionType> 4. Else: Find all files defined by the INF file whose file type is <FileType> and add each one to the FFS with a section type of <SectionType> in alphabetical order. Add files defined in [sources] followed by files defined in [binaries] 5. If > 1 UI section in final FFS, then error 6. If > 1 VER section in final FFS, then error 7. If > 1 PEI_DEPEX section in final FFS, then error 8. If > 1 DXE_DEPEX section in final FFS, then error 9. If > 1 SMM_DEPEX section in final FFS, then error If a rule specifies a filetype, instead of specifying specific file names, the files that match the extension must be processed in alphabetical order. Example
[Rule.Common.ACPITABLE] FILE FREEFORM = $(NAMED_GUID) { RAW ACPI Optional |.acpi RAW ASL Optional |.aml }

Tools must add the processed .acpi files alphabetically, followed by the .aml files which must also be added alphabetically. The file would contain:
<SOF>a1.acpi, a2.acpi, b1.acpi, b2.acpi, a.aml, b.aml<EOF>

where, start of file is <SOF> and end of file is <EOF>. Refer to the EDK II INF File Specification for a description of the FileType for binary files.

Version 1.22

May 2010

29

FDF Design Discussion

FDF

2.8 [OptionRom] Section

The EDK II [OptionRom] sections allow for extending the FDF for processing of standalone legacy PCI Option ROM images or stand-alone UEFI PCI Option ROM images. A required modifier, DriverName, will specify where in the builds FV directory, the OptionROM file will be placed. If the user is only creating PCI Option ROM images, then the [FV] and [FD] sections are not required. If an FD and FV sections exist, then the tools will create the FD image as well as the Option ROM image. If they are not in the FDF file, then they will only generate the Option ROM image. Each [OptionRom] section terminates with either the start of another section, or the end of the file. The [OptionRom] section header usage is shown below.
[OptionRom.ROMName]

If more than architecture (for example, IA32 and EBC) for the driver is to be bundled in an option rom file, then more than one INF entry (specified by the USE option) can be used to include the other architecture. Having different sections for the same option rom driver for different architectures is not permitted. This is an optional section for platform images.

2.9 [UserExtensions] Section

The EDK II [UserExtensions] sections allow for extending the FDF with custom processing of a flash image. Both the $(UserID) and the $(Identifier) modifier fields are required. Each [UserExtensions] section terminates with either the start of another section, or the end of the file. The [UserExtensions] section modifier usage is shown below.
[UserExtensions.$(UserID).$(Identifier)]

30

May 2010

Version 1.22

FDF

FDF File Format Specification

3 FDF File Format Specification

This section of the document describes the content of the FDF sections using an Extended Backus-Naur Form. Note that EDK and EDK II FDF files are very different. As a side note, there may be modules listed in the DSC file that are not in the FDF file, such as UEFI_APPLICATION.

3.1 Introduction
Path and Filename elements within the FDF are case-sensitive in order to support building on UNIX style operating systems. Text in section tags is case in-sensitive. A section terminates with either another section definition or the end of the file. To append comment information to any item, the comment must start with a hash # character. All comments terminate with the end of line character.
Field separators for lines that contain more than one field are pipe | characters. This character was selected to reduce the possibility of having the field separator character appear in a string, such as a filename or text string. The only notable exception is the PcdName which is a combination of the PcdTokenSpaceGuidCName and the PcdCName that are separated by the period . character. This notation for a PCD name is used to uniquely identify the PCD.

Use of the back slash character \ is permitted to extend lines before or after field separators |, assignment operators = as well as on space characters that are natural boundaries within a LVALUE, such as between different flag values (See Valid Examples, below) in all sections of the EDK II meta-data documents.
This character must be the last character on a line, must be preceded by a space character and must not be followed by a space character. Use of the back slash character within individual value elements (such as a directory path or a value that should not be split such as a quoted string) is not permitted.

A line terminates with either an end of line or comment, unless the comment was preceded by the line extension (back slash \) character.

Whitespace (space, new line, line feed, tab and form feed) characters are permitted between token and field separator elements for all entries. Whitespace characters are not permitted between the PcdTokenSpaceGuidCName and the dot, nor are they permitted between the dot and the PcdCName. Note that for specifying the path for a file name, if the path value starts with a dollar sign $ character, either a local MACRO or system environment variable is being specified. "If the path value" If the path value starts with one of "letter:\", "/". "/" or "\\" the path must be a fully qualified URI location. If it does not, the specified path is relative to the WORKSPACE environment variable. For all FDF files, the directory path must use the forward slash character for separating directories. For example, MdePkg/Include/ is Valid.

Note: If the platform integrator is working on a Microsoft Windows* environment and will not be working
on a non-windows platform, then the DOS-style directory separator can be used. The forward

Version 1.22

May 2010

31

FDF File Format Specification

FDF

slash Unix-style directory separator is mandatory for distributions where the build environment is unknown. Unless otherwise noted, all file names and paths are relative the system environment variable, WORKSPACE. A directory name that starts with a word is assumed by the build tools to be located in the WORKSPACE directory. Each module may have one or more INF files that can be used by tools to generate images. Specifically, the EDK Compatibility Package will contain two INF files for any module that contains assembly code. Because the ECP can be used with existing EDK tools --only supported by Microsoft-based and Intel Windows-based tools--a separate INF file to support the multiple tool chain capability of the EDK II build system must be provided for the modules that contain assembly code. The EDK II ECP will use the basename_edk2.inf for the filename of the EDK II compatible INF files, and use just the basename.inf for the filename of EDK only INF files.

3.1.1 Valid Line Extension Examples

gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueDxeCoreEntry \ | 0x3041000 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueDxeCoreHandoffToBds | \ 0x3041001 C_FLAGS = $(C_FLAGS) /D _TEST1_ \ /D _TEST2_ gPeiNtAutoScanPpiGuid = { 0x0DCE384D, 0x007C, 0x4BA5, \ { 0x94, 0xBD, 0x0F, 0x6E, 0xB6, 0x4D, 0x2A, 0xA9 }}

3.2 FDF Definition

The FDF definitions define the final properties for a flash image - PCD settings in this file override any other PCD settings that may have been set in the platform description (DSC) file.

Summary
EDK II Flash Description File (FDF)

32

May 2010

Version 1.22

FDF

FDF File Format Specification

<EDK2_FDF>

::=

[<Header>] [<IncludeStatement>] [<Defines>] [<FD>] [<FV>] [<Capsule>] [<VTF>] [<Rules>] [<OptionRom>] [<UserExtensions>]

Note: Assignments set as command-line arguments to the parsing tools take precedence over all

assignments defined in the FDF file. If a variable/value assignment is specified on the build tool's command-line, that value will override any variable/value assignment defined in the FDF file.

Note: Conditional statements may be used anywhere within the FDF file, with the ability to group any
item within a section as well as entire sections.

3.2.1 Common Definitions

Summary
The following are common definitions used by multiple section types.

Prototype
<Word> ::= Alphanumeric characters (either text or UNICODE) with optional dash "-" and/or underscore "_" characters. Whitespace characters are not permitted. / "|" One or more alphanumeric characters. A valid C variable name. <String> {<UnicodeString>} {<AsciiString>} <Word> [<Whitespace> <NonWhitespace>]{,} {"'" <BareString> "'"} {"""<BareString> """} {<BareString> } {<QuotedString>} "#" [<AsciiString>] "L" <QuotedString>

<FileSep> <FieldSeparator> <Extension> <CName> <CFlags> <String> <BareString> <QuotedString> <AsciiString> <Comment> <UnicodeString>

::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::=

Version 1.22

May 2010

33

FDF File Format Specification

FDF

<HexDigit> <HexNumber> <HexVersion> <Major> <Minor> <RegistryFormatGUID> <Hex2> <Hex4> <Hex8> <Hex12> <Hex16> <CFormatGUID>

::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::=

(a-fA-F0-9) "0x" [<HexDigit>]{1,} 0x <Major> <Minor> <HexDigit>{4} <HexDigit>{4} <Hex8> - <Hex4> - <Hex4> - <Hex4> - <Hex12> "0x" [<HexDigit>]{2} "0x" [<HexDigit>]{4} "0x" [<HexDigit>]{8} "0x" [<HexDigit>]{12} 0x [<HexDigit>]{16} "{ <Hex8> "," <Hex4> "," <Hex4> ", {" <Hex2> "," <Hex2> "," <Hex2> "," <Hex2> "," <Hex2> "," <Hex2> "," <Hex2> "," <Hex2> " }}" <HexArray1> <HexArray2> { [<HexList>]+ [, <HexSubList>]* } [<HexList>]+ [, <HexSubList>]* <HexNumber> [[,] <HexNumber>]* { {<HexList>} {<HexSubList>} } [{+} {-}] (0-9)+ [{"+"} {"-"}] <Float> (0-9)+ {<HexNumber>} {<NonNegativeInt>} <NonNegativeInt> ["." <NonNegativeInt>] {<HexInt>} {<DecimalNumber>} {"TRUE"} {"1"} {"FALSE"} {"0"} {<True>} {<False>}

<HexArray> <HexArray1> <HexArray2> <HexList> <HexSubList> <Integer> <DecimalNumber> <NonNegativeInt> <HexInt> <Float> <Number> <True> <False> <TrueFalse>

::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::=

34

May 2010

Version 1.22

FDF

FDF File Format Specification

<BoolenValue> <AbsOrRelPath> <AbsolutePath>

::= ::= ::=

{<True>} {<False>} [<AbsolutePath>] <RelativePath> {"$(WORKSPACE)/"} {"$(EDK_SOURCE)/"} {<SysEnv>} {"$(EFI_SOURCE)/"} {$(OUTPUT_DIRECTORY)} {(a-zA-Z)":\"} {\} {"/"} {<MACRO>/} $( <Word> )/ <Word> "/" [<Word> "/"]*

<SysEnv> <RelativePath>

::= ::=

<Whitespace>

::=

{<Tab>} {<Space>} {<NewLine>} {<Return>} {<FormFeed>}

[(A-Z)]{1,}[(_A-Z0-9)]{,} $( <MacroName> )

<MacroName> <MACRO>

::= ::=

<Tab> <Space> <NewLine> <Return> <FormFeed>

<NonWhitespace>

::= ::= ::= ::= ::=

::=

0x09 0x0A 0x0D 0x0C

{<Word>} {<SpecialCharacters>} {<Punctuation>} One of: !@#$%^&*()+=|}{":?><,./;'[]\`~ One of: .,!:;? {<Form1>} {<Form2>} <Value> [<OP> \ [ <Comment>] <EOL> <Value>]+ <Value> [ \ [ <Comment>] <EOL> <OP> <Value>]+ {|} {=} { }

<SpecialCharacters> <Punctuation> <ExtendedLine> <Form1> <Form2> <OP>

::= ::= ::= ::= ::= ::=

Version 1.22

May 2010

35

FDF File Format Specification

FDF

<PcdName> <PcdCName> <TokenSpaceGuidCName> <ShortPcdName> <EOL>

::= ::= ::= ::= ::=

<TokenSpaceGuidCName> "." <PcdCName> <CName> <CName> [<TokenSpaceGuidCname> .] <PcdCName> End Of Line, \r\n, characters.

Note: Comments may appear anywhere within a FDF file, provided they follow the rules that a comment

may not be enclosed within Section headers, and that in line comments must appear at the end of a statement.

Parameter Definitions
Alphanumeric Characters
This is a combination of letters, numbers, and dashes or underscore characters (either text or UNICODE). Whitespace, Special and Punctuation characters are not considered Alphanumeric characters.

Whitespace Characters
With the exception of white space characters within quoted strings, whitespace (space, tab, line feed, form feed and return) characters should be ignored by parsing tools.

Special Characters
For EDK II, INI style documents, special characters include punctuation characters as well as the characters: @#$%^&*()+=~`|\}{]['>< and /.

HexVersion
HexVersion may be used as the argument for specification versions, converting a decimal value into a 32-bit unsigned integer (2.1 becomes 0x0002000A, for 2.10).

Punctuation Characters
Punctuation characters include the following: ., ,, :, ;, !, ' and ?.

End of Line Characters

The end of line characters in the context of the EDK II FDF documents, are the DOS CRLF, or \r\n characters. Carriage Return \r characters and Form feed \f characters are not considered a newline by themselves, although a combination of \r\n is interpreted as a single newline command.

String
This is a combination of Alphanumeric characters, Special characters and Whitespace characters. To embed an end of line character in a string, an escape code notation of back slash-alphanumeric character must be used. A newline, \n character, is interpreted as a either a combination of the carriage return and linefeed characters. A return character, \r, form feed, \f and alarm \a also known as the beep character, may also be embedded.

CFlags
CFlags refers to a string of valid arguments appended to the command line of any third party or provided tool. It is NOT limited to just a compiler executable.

ExtendedLine
The use of the ExtendedLine format is prohibited in section tags. It may be used for items within any section.

36

May 2010

Version 1.22

FDF

FDF File Format Specification

FileSep
FileSep refers to either the back slash \ or forward slash / characters that are used to separate directory names. All EDK II FDF files must use the / forward slash character when specifying the directory portion of a filename. Microsoft operating systems, that normally use a back slash character for separating directory names, will interpret the forward slash character correctly.

TokenSpaceGuidCName
A word that is a valid C variable that specifies the name space for a particular PCD.

PcdCName
A word that is a valid C variable that specifies the name of the token number which a member of the name space specified by the TokenSpaceGuidCName. If no TokenSpaceGuidCName is provided, the name space is assumed to be that of the platform.

3.2.2 MACRO Statements

Macro statements are characterize by a DEFINE line or may be defined on a command line of a parsing tool. Define statements are processed according to the following precedence. Highest Priority 1. Command-line option -D MACRO=Value 2. In Module Section, valid only for the module 3. Most Recent in file 4. Environment Variable Lowest Priority Macro statements may not be referenced before they are defined. Arithmetic operations follow C associativity and precedence. Use of parenthesis is encouraged to remove ambiguity.

Version 1.22

May 2010

37

FDF File Format Specification

FDF

Prototype
<MacroDefinition> <MacroValue> ::= ::= "DEFINE" <MacroName> "=" [<MacroValue>] <EOL> {<AbsOrRelPath>} {<Number>} {<QuotedString>} {<PcdName>} {<BoolExpression>} {<Expression>} {<MACRO>} {<Integer>} {<Hex>} (0-9){1,} 0x (a-fA-F0-9){1,} [L] {<SingleQuotes>} {<DoubleQuotes>} <String> <String>

<Number> <Integer> <Hex> <QuotedString> <SingleQuotes> <DoubleQuotes>

::= ::= ::= ::= ::= ::=

Parameters
Expression
C-style expression using C relational, equality and logical numeric and bitwise operators and/or arithmetic and bitwise operators that evaluate to a value (for PCDs, the value must match the Datum Type of the PCD). Precedence and associativity follow C standards. Along with absolute values, macro names and PCDs may be used within an expression. For both macro names and PCDs, the element must be previously defined before it can be used.

Examples:
DEFINE SECCORE = $(WORKSPACE)/MyPlatform/SecCore DEFINE GEN_SKU = $(WORKSPACE)/MyPlatform/GenPei DEFINE SKU1 = $(WORKSPACE)/MyPlatform/Sku1/Pei

3.2.3 Conditional Directive Statements

Conditional statements may appear anywhere within the file. All conditional directives use macro or Feature Flag PCD values, which must evaluate to either True or False. Directives must be the only statement on a line. String evaluations are not permitted. The expression immediately following the !if statement controls whether the content after the line is processed or not. TRUE is any non-zero and non-NULL value. Each !if within the source code must be matched with a closing !endif. Zero or more #elif statements are permitted, and may be nested, however one and only one #else statement is permitted. Directives must encapsulate either entire sections or elements within a single section, such that they do not break the integrity of the section definitions.

38

May 2010

Version 1.22

FDF

FDF File Format Specification

Directives are in-fix expressions that are evaluated left to right; content within parenthesis is evaluated before the outer statements are evaluated. Use of parenthesis is recommended to remove ambiguity. The values of the Feature Flag PCDs used in the conditional statements must be set in the [PcdsFeatureFlag] section(s) of the DSC file or included in define statements. Default values from DEC files are not permitted. Values in the FDF files are defined only in either the DSC file or the FDF file.

This section may appear after a Feature Flag PCD is used in a conditional directive statement. Therefore, the reference build tools must perform two passes on this file: 1. Obtain the values of the Feature Flags used for the conditional directives 2. Evaluate the conditional statements for inclusion in the build. If the value of a Feature Flag PCD cannot be determined during the first pass, the build will break. Feature flags in the first pass should not be located within a conditional directive.

Version 1.22

May 2010

39

FDF File Format Specification

FDF

Prototype
<Conditional> ::= <IfStatement> <EOL> [<Conditional>]{0,} <Statements>{1,} [<ElseIfConditional>]{0,} [<Conditional>]{0,} [<ElseConditional>]{0,1} [<Conditional>]{0,} !endif <EOL> {!if <ExpressionStatement>} {!ifdef <MACRO>} {!ifndef <MACRO>} {<Sections>} {<SubSections>} {<SectionStatements>} !elseif <ExpressionStatement> <EOL> <Statements>{1,} !else <EOL> <Statements>{1,} {<Expression>} {<MACRO>} (A-Z){1,}(_A-Z0-9){,} $( <MacroName> ) A valid C style expression that evalutes to 0 or 1

<IfStatement>

::=

<Statements>

::=

<ElseIfConditional>

::=

<ElseConditional>

::=

<ExpressionStatement> ::= <MacroName> <MACRO> <Expression> ::= ::= ::=

Parameters
Sections
One or more full or partial sections may be within conditional statements. A section starts with the left bracket [ and terminates with either another section or the end of the file.

Subsections
One or more full or partial subsections may be within conditional statements. A subsection starts with the left arrow < and terminates with either another subsection, another section or the end of the file.

SectionStatements
One or more individual elements may be within the scope of the conditional statements.

MACRO
A macro is said to be defined if and only if it has been set to a non-NULL value.

Expression
C-style expression using C relational, equality and logical numeric and bitwise operators that evaluate to either TRUE (1) or FALSE (0). Values other than zero or one are invalid. Precedence and associativity follow C standards. Along with absolute values, macro names and PCDs may be used within an expression. For

40

May 2010

Version 1.22

FDF

FDF File Format Specification

both macro names and PCDs, the element must be previously defined before it can be used.

Example:
!if $(MyPlatformTspGuid.IPF_VERSION_1) && ! $(MyPlatformTspGuid.IPF_VERSION_2) [VTF.IPF.MyBsf] !ifdef $(IA32RESET) # IPF_VERSION is 1 and IA32RESET defined IA32_RST_BIN = IA32_RST.BIN !endif COMP_NAME = PAL_A COMP_LOC = F COMP_TYPE = 0xF COMP_VER = 7.01 COMP_CS = 1 !if ($(PROCESSOR_NAME) == "M1") COMP_BIN = M1PalCode/PAL_A_M1.BIN COMP_SYM = M1PalCode/PAL_A_M1.SYM !elseif ($(PROCESSOR_NAME) == "M2") COMP_BIN = M2PalCode/PAL_A_M2.BIN COMP_SYM = M2PalCode/PAL_A_M2.SYM !else COMP_BIN = GenPal/PAL_A_GEN.bin COMP_SYM = GenPal/PAL_A_GEN.sym !endif COMP_SIZE = !elseif $(MyPlatformTspGuid.IPF_VERSION_2) [VTF.IPF.MyBsf] !ifdef $(IA32RESET) IA32_RST_BIN = IA32_RST.BIN !endif COMP_NAME = PAL_A COMP_LOC = F COMP_TYPE = 0xF COMP_VER = 7.01 COMP_CS = 1 COMP_BIN = GenPal/PAL_A_GEN.bin COMP_SYM = GenPal/PAL_A_GEN.sym COMP_SIZE = COMP_NAME = PAL_B COMP_LOC = F COMP_TYPE = 0x01 COMP_VER = COMP_CS = 1 COMP_BIN = GenPal/PAL_B_GEN.bin COMP_SYM = GenPal/PAL_B_GEN.sym COMP_SIZE = !else [VTF.X64.MyVtf] IA32_RST_BIN = IA32_RST.BIN !endif

Version 1.22

May 2010

41

FDF File Format Specification

FDF

3.2.4 !include Statements

Summary
Use of this statement is always optional. Defines the !include statement in FDF files. This statement is used to include, at the statements line, a file which is processed at that point, as though the text of the included file was actually in the FDF file. Statements in the !include file(s) are additions to the FDF file, and do not replace information in the FDF file. The included files content must match the content of the section that the !include statement resides, or it may contain completely new sections of the same section type. If the included file contains new sections, then the section being processed in the Platform FDF file is considered to have been terminated. The !include file cannot contain additional !include statements.

Prototype
<IncludeStatement> <File> <QuotedFilename> <SingleQuoteFilename> <DoubleQuoteFilename> <Filename> ::= ::= ::= ::= ::= ::= !include <File> <EOL> {<QuotedFilename>} {<Filename>} {<SingleQuoteFilename>} {<DoubleQuoteFilename>} <Filename> <Filename> [<AbsOrRelPath>] <Word> [. <Word>]

Example (EDK II FDF)

!include myPlatform/NvRamDefs.txt !include myFeatures.mak

3.3 Header Section

Summary
This section contains Copyright and License notices for the INF file in comments that start the file. This section is optional using a format of:
## @file Nt32.fdf # Abstract # # Description # # Copyright # # License # ##

42

May 2010

Version 1.22

FDF

FDF File Format Specification

Prototype
<Header> ::= ## @file [<Filename>]<EOL> [<Abstract>] [<Description>] [<Copyright>] [<License>] ## <EOL> <Word> . <Extension> # <AsciiString> <EOL> # <EOL> [# <AsciiString> <EOL>]+ # <EOL> [# Copyright (c) <Date> , <CompInfo> <EOL>]* # <EOL> [0-9]{4} <AsciiString> [# <LicenseSentence> <EOL>]+ # <EOL>

<Filename> <Abstract>

::= ::=

<Description>

::=

<Copyright>

::=

<Date> <CompInfo> <License>

::= ::= ::=

Version 1.22

May 2010

43

FDF File Format Specification

FDF

Example
## @file Nt32.fdf # Emluation Platform Pseudo Flash Part # # The Emulation Platform can be used to debug individual modules, prior to # creating a real platform. This also provides an example for how to create # an FDF file. # # Copyright (c) 2006 - 2008, NoSuch Corporation. All rights reserved. # # This program and the accompanying materials are licensed and made # available under the terms and conditions of the BSD License which # accompanies this distribution. The full text of the license may be # found at: # http://opensource.org/licenses/bsd-license.php # # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS # OR IMPLIED. # ##

3.4 [Defines] Section

Summary
This section is optional. This section describes the defines section content in the FDF files. This file can be created by a developer and is an input to the EDK II build tool parsing utilities. Elements may appear in any order within this section. The code for this version of the FDF specification is 00010015 and new versions of this specification must increment the minor (0015) portion of the specification code for backward compatible changes, and increment the major number for non-backward compatible specification changes. This section is optional.

44

May 2010

Version 1.22

FDF

FDF File Format Specification

Prototype
<defines> ::= "[defines]" <EOL> ["PART_NAME" "=" <UiNameType> <EOL>] ["FDF_SPECIFICATION" "=" <SpecVer> <EOL>] [<DefineStatements>]* [<SetStatements>]* [<IncludeStatement>]* <AsciiString> "0x00010015" SET <PcdOrMacro> = [<VALUE>] <EOL> {<MacroName>} {<PcdName>} "DEFINE" <MacroName> "=" [<MacroValue>] <EOL> {<AbsOrRelPath>} {<NumValue>} {<MACRO>} {<String>} {<Expression>} {<Boolean>} {<Number>} {<QuotedString>} {<PcdName>} {<MACRO>} {<Expression>} {<BoolExpression>} !include <File> <EOL> [<AbsOrRelPath>] <Word> [. <Extension>]

<UiNameType> <SpecVer> <SetStatements> <PcdOrMacro>

::= ::= ::= ::=

<DefineStatements> ::= <MacroValue> ::=

<VALUE>

::=

<IncludeStatement> ::= <File> ::=

Parameters
BoolExpression
C-style expression using C relational, equality and logical numeric and bitwise operators that evaluate to either TRUE (1) or FALSE (0). Values other than zero or one are invalid. Precedence and associativity follow C standards. Along with absolute values, macro names and PCDs may be used within an expression. For both macro names and PCDs, the element must be previously defined before it can be used.

MacroValue
C-style expression using C relational, equality and logical numeric and bitwise operators and/or arithmetic and bitwise operators that evaluate to a value (for PCDs, the value must match the Datum Type of the PCD). Precedence and associativity follow C standards. Along with absolute values, macro names and PCDs may be used within an expression. For both macro names and PCDs, the element must be previously defined before it can be used. If the Macro Value is not present, then the NULL value.

MacroValue is assumed to have a

Version 1.22

May 2010

45

FDF File Format Specification

FDF

Example
[DEFINES] FDF_SPECIFICATION = 0x00010015 PART_NAME = W25X80 64KB for ZX400 Platform DEFINE BIG_STUFF = False SET gEfiMyPlatformTokenSpaceGuid.MyUsbFlag = True

3.5 [FD] Section

Summary
This is a required section for platform flash parts, and is not required for simple Option ROM creation. This describes the [FD] section tag, which is required in all FDF files. This file is created by the platform integrator and, along with the platform DSC file, is an input to the parsing utilities. For a physical part with variable block size, the token VARIABLE_BLOCKS must be set to TRUE, and the BLOCK_NUMBER value is required immediately following the RegionLayout's Offset|Size line or the PCD names for the Offset|Size. The region size of the region is used to determine the block size. An optional block size value may be specified to allocate a block larger than the region size. All FD files will be created in the $(OUTPUT_DIRECTORY)/$(TARGET)_$(TAGNAME)/FV directory using the values from the individual instance of the build tools. (Build tools get these values after parsing DSC, INF, target.txt, tools_def.txt files and command line options).

46

May 2010

Version 1.22

FDF

FDF File Format Specification

Prototype
<FD> ::= "[FD." <FdUiName> "]" [<CreateFile>] [<Comment>]* <TokenStatements> [<DefineStatements>]* [<SetStatements>]* <RegionLayout>+ {[a-zA-Z][a-zA-Z0-9_]*} {common} "CREATE_FILE" "=" <Word> ".fd" "BaseAddress" "=" <HexNumber> [<SetPcd>] <EOL> "Size" "=" <HexNumber> [<SetPcd>] <EOL> "ErasePolarity" "=" {"0"} {"1"} <EOL> [<BlockStatements>]+ "|" <ShortPcdName> {<FixedBlocks>} {<VariableBlockSize>} "BlockSize" "=" <NumValue> [<SetPcd>] <EOL> ["NumBlocks" "=" <NumValue> <EOL>] "VARIABLE_BLOCKS" = "true" <EOL> {<Integer>} {<HexNumber>} "DEFINE" <MacroName> "=" <MacroValue> <EOL> {<AbsOrRelPath>} {<NumValue>} {<MACRO>} {<String>} {<Expression>} "SET" <PcdName> "=" <PcdValue> <EOL> {<NumValue>} {<HexArray>} {<String>} {<MACRO>} {<Expression>} <Offset> "|" <Size> <EOL> [<PcdOffset> ["|" <PcdSize>] <EOL>] if (VARIABLE_BLOCKS == "true"): [<VarBlock>] [<SetStatements>]* [<RegionType>]

<FdUiName> <CreateFile> <TokenStatements>

::= ::= ::=

<SetPcd> <BlockStatements> <FixedBlocks>

::= ::= ::=

<VariableBlockSize> <NumValue> <DefineStatements> <MacroValue>

::= ::= ::= ::=

<SetStatements> <PcdValue>

::= ::=

<RegionLayout>

::=

Version 1.22

May 2010

47

FDF File Format Specification

FDF

<VarBlock> <BlockSize> <RegionType>

::= ::= ::=

"BLOCK_NUMBER" <NumValue> [<BlockSize>] <EOL> "|" <NumValue> {[<FvType>]+} {[<FileType>]+} {[<CapsuleRegion>]+} {[<DataType>]+} CAPSULE = UiCapsuleName <HexNumber> <HexNumber> <TokenSpaceGuidCName> "." <PcdCName> <TokenSpaceGuidCName> "." <PcdCName> "FV" "=" <FvNameOrFilename> <EOL> "FILE" "=" <BinaryFile> <EOL> "DATA = {" [<EOL>] {<HexValue>} {<HexByteArray>} "}" <EOL> 0x [<HexDigit>]{1,16} <Hex2> ["," <Hex2> [<EOL>]]* [<EOL>] [<PATH>] <Word> . {bin} {dat} {<FvUiName>} {<FvFilename>} {<Word>} {common} [<PATH>] <Word> . fv "$(TARGET)_$(TOOL_CHAIN_TAG)" "/" [$(ARCH) "/" ]

<CapsuleRegion> <Offset> <Size> <PcdOffset> <PcdSize> <FvType> <FileType> <DataType>

::= ::= ::= ::= ::= ::= ::= ::=

<HexValue> <HexByteArray> <BinaryFile> <FvNameOrFilename> <FvUiName> <FvFilename> <BuildId>

::= ::= ::= ::= ::= ::= ::=

Restrictions
For the FvFilename, the PATH is relative to the EDK II environment variable $(WORKSPACE). If an absolute path is not specified, the PATH defaults to the following location, where $(OUTPUT_DIRECTORY) is specified in the EDK II Platform DSC file's [Defines] section. If a path is not present, or the .fv file extensions do not appear in the value, the build system will use a filename based on either a UiFvFilename specified in the FDF file, or the value of an FV section's CREATE_FILE statement:
$(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/FV

For the Binary File, the PATH is relative to the EDK II environment variable: $(WORKSPACE). If not specified, the PATH defaults to the directory location of the EDK II Platform DSC file. If not found, the tools should test the directory location of this FDF file, if different from the directory containing the Platform's DSC file.

48

May 2010

Version 1.22

FDF

FDF File Format Specification

Parameters
CreateFile
Filename to create instead of using the FdUiName.

UiCapsuleName
The UiCapsuleName specified in a [Capsule] section header defined lower down in the file.

PcdValue
The PCD Value may be a specific numeric value, an array of numeric values, a quoted string, an L quoted string (representing a unicode string), an arithmetic expression, a logic expression or a macro from a previously defined macro statement.

Expression
C-style expression using C relational, equality and logical numeric and bitwise operators and/or arithmetic and bitwise operators that evaluate to a value (for PCDs, the value must match the Datum Type of the PCD). Precedence and associativity follow C standards. Along with absolute values, macro names and PCDs may be used within an expression. For both macro names and PCDs, the element must be previously defined before it can be used.

Version 1.22

May 2010

49

FDF File Format Specification

FDF

Example
[FD.FdMain] BaseAddress = 0xFFF00000 | \ gEfiMyPlatformTokenSpaceGuid.PcdFlashAreaBaseAddress Size = 0x102000 ErasePolarity = 1 BlockSize = 0x10000 NumBlocks = 16 BlockSize = 0x1000 NumBlocks = 2 # Offset:Size 0x000000|0x0C0000 gEfiMyPlatformTokenSpaceGuid.PcdFlashFvMainBase| \ gEfiMyPlatformTokenSpaceGuid.PcdFlashFvMainSize FV = FvMain 0x0C0000|0x00A000 gEfiMyPlatformTokenSpaceGuid.PcdFlashNvStorageBase| \ gEfiMyPlatformTokenSpaceGuid.PcdFlashNvStorageSize Data = { # Variable Store 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C, 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x5F, 0x46, 0x56, 0x48, 0xFF, 0x8E, 0xFF, 0xFF, 0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } 0x0CA000|0x002000 gEfiCpuTokenSpaceGuid.PcdCpuMicrocodePatchAddress| \ gEfiCpuTokenSpaceGuid.PcdCpuMicrocodePatchSize FILE = FV/Microcode.bin 0x0CC000|0x002000 # Event Log gEfiMyPlatformTokenSpaceGuid.PcdFlashNvStorageEventLogBase| \ gEfiMyPlatformTokenSpaceGuid.PcdFlashNvStorageEventLogSize 0x0CE000|0x002000 # FTW Working Area gEfiMyPlatformTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase| \ gEfiMyPlatformTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize Data = { 0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C, 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50, 0x85, 0xAE, 0x2D, 0xBF, 0xFE, 0xFF, 0xFF, 0xFF, 0xE4, 0x1F, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF } 0x0D0000|0x010000 # FTW Spare Block gEfiMyPlatformTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase| \ gEfiMyPlatformTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize 0x0E0000|0x020000 gEfiMyPlatformTokenSpaceGuid.PcdFlashFvRecoveryBase| \

50

May 2010

Version 1.22

FDF

FDF File Format Specification

gEfiMyPlatformTokenSpaceGuid.PcdFlashFvRecoverySize FV = FV/FvRecovery.fv

3.6 [FV] Sections

Summary
One or more of theses sections is required for platform images, and not required for simple Option ROM generation. This describes the [FV] section tag, which is required in all FDF files. This file is created by the platform integrator and is an input to the one or more parsing utilities. Note that for a part with variable block size, both the block number and block size must be specified on the same line. Note that FvAttributes, listed below, may be set via PCD settings. Setting the attribute via PCD takes precedence over the FvAttributes settings in this FDF file. If the FvAttribute is not set by either a PCD or an FvAttribute line in the FDF file, then the default value is FALSE - the corresponding bit in the EFI_FV_ATTRIBUTE of the EFI_FIRMWARE_VOLUME_PROTOCOL.GetVolumeAttributes() is set per the FvAttributesSet or FvAttributesClear; items specified in FvAttributesSet are default TRUE, while items in FvAttributesClear are default FALSE. If FV files are created, they will be created in the $(OUTPUT_DIRECTORY)/ $(TARGET)_$(TAGNAME)/FV directory using the values from the individual instance of the build tools. (Build tools get these values after parsing DSC, INF, target.txt, tools_def.txt files and command line options).

Version 1.22

May 2010

51

FDF File Format Specification

FDF

Prototype
<FV> ::= "[FV." <FvUiName> "]" [<DefineStatements>]* [<CreateFile>] [<ExtendedFvEntry>]* [<FvStatements>]* {<Word>} {common} "CREATE_FILE" "=" <NormalFile> FV_EXT_ENTRY_TYPE TYPE = <Hex4> { {FILE = <BinaryFile>} {DATA = <Array>} } <PATH> <Word> [. {bin} {dat}} { <Hex2> ["," <Hex2> [<EOL>]]* [<EOL>] } <EOL> [<BlockStatements>]{0,1} [<SetStatements>]* [<FvAlignment>] [<FvAttributes>]* [<FileSystemGuid>] [<FvNameGuid>] [<PeiAprioriSection>] [<DxeAprioriSection>] [<InfStatements>]* [<FileStatements>]* "DEFINE" <MacroName> "=" <MacroValue> <EOL> {<AbsOrRelPath>} {<NumValue>} {<MACRO>} {<String>} {<Expression>} {<FixedBlocks>} {<VariableBlockSize>} ["BlockSize" "=" <NumValue> <EOL>]{0,1} ["NumBlocks" "=" <NumValue> <EOL>]{0,1} {<Integer>} {<HexNumber>} "BLOCK_NUMBER" <NumValue> [<BlockSize>] <EOL> "|" <NumValue> "SET" <PcdName> "=" <PcdValue> <EOL> {<NumValue>} {<HexArray>} {<String>} {<MACRO>} {<Expression>} "FvAlignment" "=" <FvValidAlign> {"1"} {"2"} {"4"} {"8"} {"16"} {"32"} {"64"} {"128"} {"256"} {"512"} {"1K"} {"2K"} {"4K"}

<FvUiName> <CreateFile> <ExtendedFvEntry>

::= ::= ::=

<BinaryFile> <Array> <FvStatements>

::= ::= ::=

<DefineStatements> <MacroValue>

::= ::=

<BlockStatements> <FixedBlocks>

::= ::=

<NumValue> <VariableBlockSize> <BlockSize> <SetStatements> <PcdValue>

::= ::= ::= ::= ::=

<FvAlignment> <FvValidAlign>

::= ::=

52

May 2010

Version 1.22

FDF

FDF File Format Specification

{"8K"} {"16K"} {"32K"} {"64K"} {"128K"} {"256K"} {"512K"} {"1M"} {"2M"} {"4M"} {"8M"} {"16M"} {"32M"} {"64M"} {"128M"} {"256M"} {"512M"} {"1G"} {"2G"} <FvAttributes> ::= {<Attribute> "=" <TrueFalse>} {"ERASE_POLARITY" = {0} {1}} <EOL> {<FvAttributeSet>} {<FvAttributeClear>} {"MEMORY_MAPPED"} {"STICKY_WRITE"} {"LOCK_CAP"} {"LOCK_STATUS"} {"WRITE_ENABLED_CAP"} {"WRITE_DISABLED_CAP"} {"WRITE_STATUS"} {"READ_ENABLED_CAP"} {"READ_DISABLED_CAP"} {"READ_STATUS"} {"READ_LOCK_CAP"} {"READ_LOCK_STATUS"} {"WRITE_LOCK_CAP"} {"WRITE_LOCK_STATUS"} "WRITE_POLICY_RELIABLE" FileSystemGuid = <NamedGuid> FvNameGuid = <NamedGuid> "APRIORI PEI {" <EOL> [<DefineStatements>] [<InfStatements>]* [<FileStatements>]* "}" <EOL> "APRIORI DXE {" <EOL> [<DefineStatements>] [<InfStatements>]* [<FileStatements>]* "}" <EOL> "INF" [<InfOptions>] <InfFile> <EOL> [<Use>] [<Rule>] [<SetVer>] [<SetUi>] [<UseLoc>]

<Attribute> <FvAttributeSet>

::= ::=

<FvAttributeClear> <FileSystemGuid> <FvNameGuid> <PeiAprioriSection>

::= ::= ::= ::=

<DxeAprioriSection>

::=

<InfStatements> <InfOptions>

::= ::=

Note: The INF option [<UseLoc>] is depreicated and replaced by the simplified USE = statement.
<Use> <Rule> <SetVer> <SetUi> <InfFile> ::= ::= ::= ::= ::= USE = <TargetArch> "RuleOverride" "=" <RuleUiName> "VERSION" "=" <String> "UI" "=" <String> if (MODULE_TYPE == SEC || MODULE_TYPE == PEI_CORE || MODULE_TYPE == PEIM):

Version 1.22

May 2010

53

FDF File Format Specification

FDF

<PATH> <Word> ".inf" ["|" <RelocFlags>] <EOL> else: <PATH> <Word> ".inf" <EOL> <PATH> <AbsolutePath> ::= ::= [<AbsolutePath>] [<BuildId>] <RelativePath> {"$(WORKSPACE)/"} {"$(EDK_SOURCE)/"} {"$(OUTPUT_DIRECTORY)/"} {"$(EFI_SOURCE)/"} <Word> "/" [<Word> "/"]* ["RELOCS_STRIPPED"] ["RELOCS_RETAINED"] "$(TARGET)_$(TOOL_CHAIN_TAG)/" [$(ARCH) "/" ] <KeyString> ["," <KeyString>] <Target> "_" <TagName> "_" <TargetArch> {Target} {$(TARGET)} {TagName} {$(TOOL_CHAIN_TAG)} {"IA32"} {"X64"} {"IPF"} {"EBC"} {[A-Z][A-Z0-9]*} {<type1>} {<type2>} {<type3>} {<type4>} {<type5>} "FILE" <FvType1> "=" <NamedGuid> <Options1> "FILE" <FvType2> "=" <NamedGuid> <Options2> "FILE" RAW "=" <NamedGuidOrPcd> <Options2> FILE NON_FFS_FILE = [<NamedGuid>] <Options2> "FILE" FV_IMAGE "=" <NamedGuidOrPcd> <Options2> {"SEC"} {"PEI_CORE"} {"PEIM"} {"FREEFORM"} {"PEI_DXE_COMBO"} {DRIVER} {"DXE_CORE"} {"APPLICATION"} {SMM_CORE} {SMM} {<NamedGuid>} {PCD( <PcdName> )} {<RegistryFormatGuid>} {<GuidCName>} [<UseLoc>][<FileOpts>] <RelocFlags> "{" [<EOL>] {<Filename>} {<SectionData>} "}" <EOL>

<RelativePath> <RelocFlags> <BuildId> <UseLoc> <KeyString> <Target> <TagName> <TargetArch> <FileStatements>

::= ::= ::= ::= ::= ::= ::= ::= ::=

<type1> <type2> <type3> <type4>

::= ::= ::= ::=

<type5>

::=

<FvType1> <FvType2>

::= ::=

<NamedGuidOrPcd> <NamedGuid> <Options1>

::= ::= ::=

54

May 2010

Version 1.22

FDF

FDF File Format Specification

<Options2>

::=

[<UseLoc>][<FileOpts>] "{" [<EOL>] {<Filename>} {<SectionData>} "}" <EOL> ["FIXED"] ["CHECKSUM"] [<FfsAlignment>] "Align" "=" <FfsValidAlign> {Auto} {"8"} {"16"} {"128"} {"512"} {"1K"} {"4K"} {"32K"} {"64K"} {<FvImage>} {<FdImage>} {<NormalFile>} "FV" "=" <FvUiName> <EOL> "FD" "=" <FdUiName> <EOL> {<Word>} {common} <PATH> <Word> "." <Word> <EOL> [<DefineStatements>]* [<PeiAprioriSection>] [<DxeAprioriSection>] [<EncapsulationSec>]* [<LeafSections>]* {<VerSection>} {<UiSec>} {<FvImgSection>} {<DataSection>} {<DepexExpSection>} "SECTION" [<VerArgs>] "VERSION" <UniArg> "SECTION" [<Alignment>] "UI" <UniArg> "SECTION" [<Alignment>] "FV_IMAGE" <FvImgArgs> [<Alignment>] [<Build>] "BUILD_NUM" "=" <BuildVal> {[a-fA-F0-9]{4}} {"$(BUILD_NUMBER)"} "=" {<StringData>} {<NormalFile>} <EOL> {<UnicodeString>} {<QuotedString>} "=" <FvUiName> "{" <EOL> [<DefineStatements>]* [<ExtendedFvEntry>]* [<FvAlignment>] [<FvAttributes>]* [<PeiAprioriSection>] [<DxeAprioriSection>] [<InfStatements>]*

<FileOpts> <Alignment> <FfsValidAlign>

::= ::= ::=

<Filename> <FvImage> <FdImage> <FdUiName> <NormalFile> <SectionData>

::= ::= ::= ::= ::= ::=

<LeafSections>

::=

<VerSection> <UiSec> <FvImgSection> <VerArgs> <Build> <BuildVal> <UniArg> <StringData> <FvImgArgs>

::= ::= ::= ::= ::= ::= ::= ::= ::=

Version 1.22

May 2010

55

FDF File Format Specification

FDF

[<FileStatements>]* "}" <EOL> <DataSection> <SecData> ::= ::= "SECTION" [<Alignment>] <SecData> <LeafSectionType> [<ChkReloc>] <SectionOrFile> {"COMPAT16"} {"PE32"} {"PIC"} {"TE"} {RAW} {"FV_IMAGE"} {"DXE_DEPEX"} {SMM_DEPEX} {"UI"} {"PEI_DEPEX"} {"VERSION"} {"SUBTYPE_GUID"} if ((LeafSectionType == || LeafSectionType && (MODULE_TYPE == || MODULE_TYPE || MODULE_TYPE [<RelocFlags>] PE32 == TE) SEC == PEI_CORE == PEIM)):

<LeafSectionType>

::=

<ChkReloc>

::=

<SectionOrFile>

::=

{"=" <NormalFile> <EOL>} {<EncapsulationSec>} "SECTION" [<Alignment>] <EncapsuleSection> <EOL> {<CompressSection>} {<GuidedSection>} "COMPRESS" [<CompType>] "{" <EOL> [<EncapsulationSec>]* [<LeafSections>]* "}" <EOL> {"PI_STD"} {"PI_NONE"} "GUIDED" <NamedGuid> [<GuidedOptions>] "{" <EOL> [<EncapsulationSec>]* [<LeafSections>]* "}" <EOL> [<GuidAttr>]{0,2} [<GuidHeaderSize>] <AttrName> "=" <TrueFalse> {"PROCESSING_REQUIRED"} {"AUTH_STATUS_VALID"} "EXTRA_HEADER_SIZE" "=" <NumValue> if ( COMPONENT_TYPE == LIBRARY || LIBRARY_CLASS is declared in defines section of the INF || MODULE_TYPE == USER_DEFINED ): [<Depex>] else if ( MODULE_TYPE == PEIM

<EncapsulationSec>

::=

<EncapsuleSection> <CompressSection>

::= ::=

<CompType> <GuidedSection>

::= ::=

<GuidedOptions> <GuidAttr> <AttrName> <GuidHeaderSize> <DepexExpSection>

::= ::= ::= ::= ::=

56

May 2010

Version 1.22

FDF

FDF File Format Specification

|| MODULE_TYPE == DXE_DRIVER || MODULE_TYPE == DXE_RUNTIME_DRIVER || MODULE_TYPE == DXE_SAL_DRIVER || MODULE_TYPE == DXE_SMM_DRIVER ): <Depex> else if ( MODULE_TYPE == UEFI_APPLICATION && MODULE_TYPE == UEFI_DRIVER && MODULE_TYPE == PEI_CORE && MODULE_TYPE == DXE_CORE && MODULE_TYPE == SMM_CORE && MODULE_TYPE == SEC ): No DEPEX section is permitted <Depex> ::= if (MODULE_TYPE == PEIM): <PeiDepexExp> else if (MODULE_TYPE == DXE_SMM_DRIVER): <SmmDepexExp> [<DxeDepexExp>] else: <DxeDepexExp> "SECTION" [<Alignment>] "PEI_DEPEX_EXP" "=" "{" <PeiDepex> "}" [<BoolStmt>] <EOL> [<DepInstruct>] <EOL> ["end"] <EOL> {<Bool>} {<BoolExpress>} {<GuidCName>} <EOL> {"TRUE"} {"FALSE"} {<GuidCName>} <CName> # A Guid C Name

<PeiDepexExp>

::=

<PeiDepex>

::=

<BoolStmt>

::=

<Bool> <GuidCName> <BoolExpress> <OP> <DepInstruct> <DxeDepexExp>

::= ::= ::= ::= ::= ::=

<GuidCName> [<OP> ["NOT"] <GuidCName> ]* {"AND"} {"OR"} "push" <Filename> "SECTION" [<Alignment>] "DXE_DEPEX_EXP" \ "=" "{" [<EOL>] <DxeDepex> "}" [<SorStmt>] <EOL> [<GuidStmt>] <EOL> [<BoolStmt>] <EOL> [<DepInstruct>] <EOL> ["END"] <EOL> "SOR" <BoolStmt> {"before"} {"after"} <Filename> "SECTION" [<Alignment>] "SMM_DEPEX_EXP" \ "=" "{" [<EOL>] <DxeDepex> "}"

<DxeDepex>

::=

<SorStmt> <GuidStmt> <SmmDepexExp>

::= ::= ::=

Version 1.22

May 2010

57

FDF File Format Specification

FDF

Parameters
CreateFile
Filename to create instead of using the FvUiName. this also allows for a new relative location.

GuidCName
A word that is a valid C variable for a GUID.

Expression
C-style expression using C relational, equality and logical numeric and bitwise operators and/or arithmetic and bitwise operators that evaluate to a value (for PCDs, the value must match the Datum Type of the PCD). Precedence and associativity follow C standards. Along with absolute values, macro names and PCDs may be used within an expression. For both macro names and PCDs, the element must be previously defined before it can be used.

Related Definitions
Note that no space characters are permitted on the left side of the expression (before the equal sign). Target
This value must match a target identifier in the EDK II tools_def.txt file - the first field, where fields are separated by the underscore character. Wildcard characters are not permitted.

TagName
This must match a tag name field in the EDK II tools_def.txt file - second field. Wildcard characters are not permitted.

58

May 2010

Version 1.22

FDF

FDF File Format Specification

Example
[Fv.Root] FvAlignment = 64 ERASE_POLARITY MEMORY_MAPPED STICKY_WRITE LOCK_CAP LOCK_STATUS WRITE_DISABLED_CAP WRITE_ENABLED_CAP WRITE_STATUS WRITE_LOCK_CAP WRITE_LOCK_STATUS READ_DISABLED_CAP READ_ENABLED_CAP READ_STATUS READ_LOCK_CAP READ_LOCK_STATUS = = = = = = = = = = = = = = = 1 TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE

INF VERSION = "1" $(WORKSPACE)/EdkNt32Pkg/Dxe/WinNtThunk/Cpu/Cpu.inf FILE DXE_CORE = B5596C75-37A2-4b69-B40B-72ABD6DD8708 { SECTION COMPRESS { DEFINE DC = $(WORKSPACE)/Build/Nt32/DEBUG_IA32 SECTION PE32 = $(DC)/B5596C75-37A2-4b69-B40B-72ABD6DD8708-DxeCore.efi SECTION VERSION "1.2.3" } } FILE FV_IMAGE = EF41A0E1-40B1-481f-958E-6FB4D9B12E76 { FvAlignment = 512K WRITE_POLICY_RELIABLE = TRUE SECTION GUIDED 3EA022A4-1439-4ff2-B4E4-A6F65A13A9AB { SECTION FV_IMAGE = Dxe { APRIORI DXE { INF $(WORKSPACE)/a/a.inf INF $(EDK_SOURCE/a/c/c.inf INF $(WORKSPACE)/a/b/b.inf } INF a/d/d.inf } } } DEFINE SAMPLE = $(EDK_SOURCE)/Sample INF INF INF INF INF INF INF $(SAMPLE)/Universal/Network/Ip4/Dxe/Ip4.inf $(SAMPLE)/Universal/Network/Ip4Config/Dxe/Ip4Config.inf $(SAMPLE)/Universal/Network/Udp4/Dxe/Udp4.inf $(SAMPLE)/Universal/Network/Tcp4/Dxe/Tcp4.inf $(SAMPLE)/Universal/Network/Dhcp4/Dxe/Dhcp4.inf $(SAMPLE)/Universal/Network/Mtftp4/Dxe/Mtftp4.inf $(SAMPLE)/Universal/Network/SnpNt32/Dxe/SnpNt32.inf

Version 1.22

May 2010

59

FDF File Format Specification

FDF

3.7 [Capsule] Section

Summary
This describes the optional [Capsule] section tag, which may be found in FDF files. If capsule files are created, they will be created in the $(OUTPUT_DIRECTORY)/ $(TARGET)_$(TAGNAME)/FV directory using the values from the individual instance of the build tools. (Build tools get these values after parsing DSC, INF, target.txt, tools_def.txt files and command line options.)

Prototype
<Capsule> ::= "[Capsule" <UiCapsuleName> "]" <EOL> [<CreateFile>] <UefiTokens> [<DefineStatements>]* [<SetStatements>]* [<CapsuleData>]+ "." <Word> "CREATE_FILE" "=" <Word> "DEFINE" <MacroName> "=" <MacroValue> <EOL> {<AbsOrRelPath>} {<NumValue>} {<MACRO>} {<String>} {<Expression>} "SET" <PcdName> "=" <Value> <EOL> "CAPSULE_GUID" "=" <GuidValue> <EOL> ["CAPSULE_HEADER_SIZE" "=" <Bytes> <EOL>] ["CAPSULE_FLAGS" "=" <Flags> <EOL>] {<GuidCname>} {<GuidStructure>} <CName> {<RegistryFormatGUID>} {<CFormatGUID>}

<UiCapsuleName> <CreateFile> <DefineStatements> <MacroValue>

::= ::= ::= ::=

<SetStatements> <UefiTokens>

::= ::=

<GuidValue> <GuidCname> <GuidStructure>

::= ::= ::=

60

May 2010

Version 1.22

FDF

FDF File Format Specification

<Flags> <FlagName>

::= ::=

<FlagName> {"PersistAcrossReset"} {"PersistAcrossReset" "," "InitiateReset"} {"PersistAcrossReset" "," "PopulateSystemTable"} {"PersistAcrossReset" "," "PopulateSystemTable" "," "InitiateReset"} {"PersistAcrossReset" "," InitiateReset" "," "PopulateSystemTable"} {"PopulateSystemTable"} {"PopulateSystemTable" "," "PersistAcrossReset"} {"PopulateSystemTable" "," "PersistAcrossReset" "," "InitiateReset"} {"PopulateSystemTable" "," "InitiateReset" "," "PersistAcrossReset"} {"InitiateReset" "," "PersistAcrossReset"} {"InitiateReset" "," "PersistAcrossReset" "," "PopulateSystemTable"} {"InitiateReset" "," "PopulateSystemTable" "," "PersistAcrossReset"} [<InfStatements>]* [<FileStatements>]* [<FvStatements>]* "INF" [<InfOptions>] <InfFile> <EOL>

<CapsuleData>

::=

<InfStatements> <InfOptions>

::= ::=

[<Use>] [<Rule>] [<SetVer>] [<SetUi>] [<UseLoc>]

Note: The INF option, [<UseLoc>] is depreicated and replaced by the simplified USE = statement. Do
not use this for new implementations.

<Use> <Rule> <SetVer> <SetUi> <InfFile>

::= ::= ::= ::= ::=

USE = <TargetArch> "RuleOverride" "=" <RuleUiName> "VERSION" "=" <String> "UI" "=" <String> if (MODULE_TYPE == SEC || MODULE_TYPE == PEI_CORE || MODULE_TYPE == PEIM): <PATH> <Word> ".inf" ["|" <RelocFlags>] else: <PATH> <Word> ".inf" [<AbsolutePath>] [<BuildId>] <RelativePath> {"$(WORKSPACE)/"} {"$(EDK_SOURCE)/"} {"$(OUTPUT_DIRECTORY)/"} {"$(EFI_SOURCE)/"}

<PATH> <AbsolutePath>

::= ::=

Version 1.22

May 2010

61

FDF File Format Specification

FDF

62

May 2010

Version 1.22

FDF

FDF File Format Specification

<RelativePath> <BuildId>

::= ::=

<Word> "/" [<Word> "/"]* "$(TARGET)_$(TOOL_CHAIN_TAG)" "/" [$(ARCH) "/" {"RELOCS_STRIPPED"} {"RELOCS_RETAINED"} <KeyString> ["," <KeyString>] <Target> "_" <TagName> "_" <TargetArch> {Target} {$(TARGET)} {TagName} {$(TOOL_CHAIN_TAG)} {"IA32"} {"X64"} {"IPF"} {"EBC"} {[A-Z][A_Z0-9]*} {<type1>} {<type2>} {<type3>} {<type4>} "FILE" <FvType1> "=" <NamedGuid> <Options1> "FILE" <FvType2> "=" <NamedGuid> <Options2> "FILE" RAW "=" <NamedGuidOrPcd> <Options2> FILE NON_FFS_FILE = [<NamedGuid>] <Options2> "FILE" FV_IMAGE "=" <NamedGuidOrPcd> <Options2> {"SEC"} {"PEI_CORE"} {"PEIM"} {"FREEFORM"} {"PEI_DXE_COMBO"} {DRIVER} {"DXE_CORE"} {"APPLICATION"} {SMM_CORE} {SMM} {<RegistryFormatGuid>} {<GuidCName>} {<NamedGuid>} {PCD( <PcdName> )} [<UseLoc>] [<FileOpts>] [<RelocFlags>] "{" {<Filename>} {<SectionData>} "}" [<UseLoc>] [<FileOpts>] "{" {<Filename>} {<SectionData>} "}" ["FIXED"] ["CHECKSUM"] [<Alignment>] "Align" "=" <FfsValidAlignment>

<RelocFlags> <UseLoc> <KeyString> <Target> <TagName> <TargetArch> <FileStatements> <type1>

::= ::= ::= ::= ::= ::= ::= ::=

<type2>

::=

<type3>

::=

<type4>

::=

<type5>

::=

<FvType1> <FvType2>

::= ::=

<NamedGuid> <NamedGuidOrPcd> <Options1>

::= ::= ::=

<Options2>

::=

<FileOpts> <Alignment>

::= ::=

Version 1.22

May 2010

63

FDF File Format Specification

FDF

<FfsValidAlign>

::=

{Auto} {"8"} {"16"} {"128"} {"512"} {"1K"} {"4K"} {"32K"} {"64K"} "FvAlignment" "=" <FvValidAign> <EOL> {"1"} {"2"} {"4"} {"8"} {"16"} {"32"} {"64"} {"128"} {"256"} {"512"} {"1K"} {"2K"} {"4K"} {"8K"} {"16K"} {"32K"} {"64K"} {"128K"} {"256K"} {"512K"} {"1M"} {"2M"} {"4M"} {"8M"} {"16M"} {"32M"} {"64M"} {"128M"} {"256M"} {"512M"} {"1G"} {"2G"} {<FvImage>} {<FdImage>} {<NormalFile>} "FV" "=" <FvUiName> <EOL> "FD" "=" <FdUiName> <EOL> {<Word>} {common} <PATH> <Word> "." <Word> <EOL> [<DefineStatements>]* [<PeiAprioriSection>] [<DxeAprioriSection>] [<EncapsulationSec>]* [<LeafSections>]* "APRIORI PEI {" <EOL> [<DefineStatements>] [<InfStatements>]* [<FileStatements>]* "}" <EOL> "APRIORI DXE {" <EOL> [<DefineStatements>] [<InfStatements>]* [<FileStatements>]* "}" <EOL> {<VerSection>} {<UiSec>} {<FvImgSection>} {<DataSection>} {<DepexExpSec>} "SECTION" [<VerArgs>] "VERSION" <UniArg> "SECTION" [<Alignment>] "UI" <UniArg> "SECTION" [<Alignment>] "FV_IMAGE" <FvImgArgs> [<Alignment>] [<Build>] "BUILD_NUM" "=" <BuildVal>

<FvAlignment> <FvValidAlign>

::= ::=

<Filename> <FvImage> <FdImage> <FdUiName> <NormalFile> <SectionData>

::= ::= ::= ::= ::= ::=

<PeiAprioriSection>

::=

<DxeAprioriSection>

::=

<LeafSections>

::=

<VerSection> <UiSection> <FvImgSection>

::= ::= ::=

<VerArgs> <Build>

::= ::=

64

May 2010

Version 1.22

FDF

FDF File Format Specification

<BuildVal> <UniArg> <StringData>

::= ::= ::=

{[a-fA-F0-9]{4}} {"$(BUILD_NUMBER)"} "=" {<StringData>} {<NormalFile>} <EOL> {<UnicodeString>} {<QuotedString>} {<MacroValue>} If (VerSection): "$(INF_VERSION)" else if (UiSection): {"$(INF_VERSION)"} {"$(MODULE_NAME)"} "=" <FvUiName> "{" <EOL> [<DefineStatements>]* [<ExtendedFvEntry>]* [<FvAlignment>] [<FvAttributes>]* [<FileSystemGuid>] [<PeiAprioriSection>] [<DxeAprioriSection>] [<InfStatements>]* [<FileStatements>]* "}" <EOL>

<MacroValue>

::=

<FvImgArgs>

::=

<ExtendedFvEntry>

::=

FV_EXT_ENTRY_TYPE TYPE = <Hex4> { {FILE = <BinaryFile>} {DATA = <Array>} } <PATH> <Word> [. {bin} {dat}} { <Hex2> ["," <Hex2> [<EOL>]]* [<EOL>] } <EOL> "SECTION" [<Alignment>] <SecData> <LeafSectionType> [<ChkReloc>] <SectionOrFile> {"COMPAT16"} {"PE32"} {"PIC"} {"TE"} {RAW} {"FV_IMAGE"} {"DXE_DEPEX"} {SMM_DEPEX} {"UI"} {"PEI_DEPEX"} {"VERSION"} {"SUBTYPE_GUID"} if ((LeafSectionType == || LeafSectionType && (MODULE_TYPE == || MODULE_TYPE || MODULE_TYPE [<RelocFlags>] PE32 == TE) SEC == PEI_CORE == PEIM)):

<BinaryFile> <Array> <DataSection> <SecData>

::= ::= ::= ::=

<LeafSectionType>

::=

<ChkReloc>

::=

<SectionOrFile> <EncapsulationSec> <EncapsuleSection>

::= ::= ::=

{"=" <NormalFile> <EOL>} {<EncapsulationSec>} "SECTION" [<Alignment>] <EncapsuleSection> {<CompressSection>} {<GuidedSection>}

Version 1.22

May 2010

65

FDF File Format Specification

FDF

<CompressSection>

::=

"COMPRESS" [<CompType>] "{" <EOL> [<DefineStatements>]* [<PeiAprioriSection>] [<DxeAprioriSection>] [<EncapsulationSec>]* [<LeafSections>]* "}" <EOL> {"PI_STD"} {"PI_NONE"} "GUIDED" <NamedGuid> [<GuidedOptions>] "{" <EOL> [<DefineStatements>]* [<PeiAprioriSection>] [<DxeAprioriSection>] [<EncapsulationSec>]* [<LeafSections>]* "}" <EOL> [<GuidAttr>]{0,2} [<GuidHeaderSize>] <AttrName> "=" <TrueFalse> {"PROCESSING_REQUIRED"} {"AUTH_STATUS_VALID"} "EXTRA_HEADER_SIZE" "=" <NumValue> {<Word>} {common} "FV" "=" <FvNameOrFilename> <EOL> {<FvUiName>} {<FvFilename>} [<PATH>] ["FV/"] <Word> "." "fv" <Attribute> "=" <TrueFalse> <EOL> {<FvAttributeSet>} {<FvAttributeClear>} {"ERASE_PLARITY"} {"MEMORY_MAPPED") {"STICKY_WRITE"} {"LOCK_CAP"} {"LOCK_STATUS"} {"WRITE_ENABLED_CAP"} {"WRITE_DISABLED_CAP"} {"WRITE_STATUS"} {"READ_ENABLED_CAP"} {"READ_DISABLED_CAP"} {"READ_STATUS"} {"READ_LOCK_CAP"} {"READ_LOCK_STATUS"} {"WRITE_LOCK_CAP"} {"WRITE_LOCK_STATUS"} "WRITE_POLICY_RELIABLE" FileSystemGuid = <NamedGuid> if ( COMPONENT_TYPE == LIBRARY || LIBRARY_CLASS is declared in defines

<CompTyp> <GuidedSection>

::= ::=

<GuidedOptions> <GuidAttr> <AttrName>

::= ::= ::=

<GuidHeaderSize> <FvUiName> <FvStatements> <FvNameOrFilename> <FvFilename> <FvAttributes> <Attribute> <FvAttributeSet>

::= ::= ::= ::= ::= ::= ::= ::=

<FvAttributeClear> <FileSystemGuid> <DepexExpSection>

::= ::= ::=

66

May 2010

Version 1.22

FDF

FDF File Format Specification

section of the INF || MODULE_TYPE == USER_DEFINED ): [<Depex>] else if ( MODULE_TYPE == PEIM || MODULE_TYPE == DXE_DRIVER || MODULE_TYPE == DXE_RUNTIME_DRIVER || MODULE_TYPE == DXE_SAL_DRIVER || MODULE_TYPE == DXE_SMM_DRIVER ): <Depex> else if ( MODULE_TYPE == UEFI_APPLICATION && MODULE_TYPE == UEFI_DRIVER && MODULE_TYPE == PEI_CORE && MODULE_TYPE == DXE_CORE && MODULE_TYPE == SMM_CORE && MODULE_TYPE == SEC): No DEPEX section is permitted <Depex> ::= if (MODULE_TYPE == PEIM): <PeiDepexExp> else if (MODULE_TYPE == DXE_SMM_DRIVER): <SmmDepexExp> [<DxeDepexExp>] else: <DxeDepexExp> "SECTION" [<Alignment>] "PEI_DEPEX_EXP" "=" "{" <PeiDepex> "}" } [<BoolStmt>] <EOL> [<DepInstruct>] <EOL> ["end"] <EOL> {<Boolean>} {<BoolExpress>} {<GuidCName>} <EOL> {"TRUE"} {"FALSE"} {<GuidCName>} <CName> # A Guid C Name

<PeiDepexExp>

::=

<PeiDepex>

::=

<BoolStmt>

::=

<Boolean> <GuidCName> <BoolExpress> <OP> <DepInstruct> <DxeDepexExp>

::= ::= ::= ::= ::= ::=

<GuidCName> [<OP> ["NOT"] <GuidCName> ]* {"AND"} {"OR"} "push" <Filename> "SECTION" [<Alignment>] "DXE_DEPEX_EXP" "=" "{" [<EOL>] <DxeDepex> "}"

Version 1.22

May 2010

67

FDF File Format Specification

FDF

<DxeDepex>

::=

[<SorStmt>] <EOL> [<GuidStmt>] <EOL> [<BoolStmt>] <EOL> [<DepInstruct>] <EOL> ["END"] <EOL> "SOR" <BoolStmt> {"before"} {"after"} <Filename> "SECTION" [<Alignment>] "SMM_DEPEX_EXP" "=" "{" [<EOL>] <DxeDepex> "}"

<SorStmt> <GuidStmt> <SmmDepexExp>

::= ::= ::=

Parameters
UiCapsuleName
Filename that will be used to create an FV file.

CreateFile
Filename to create instead of using the UiCapsuleName.

Depex
Depex sections are prohibited for modules with a MODULE_TYPE of UEFI_DRIVER, UEFI_APPLICATION, PEI_CORE, DXE_CORE or SEC. modules with MODULE_TYPE of USER_DEFINED and all Library instances may or may not have a DEPEX section. Modules that use DXE_RUNTIME_DRIVER as the MODULE_TYPE require a DEPEX section if and only if they are pure DXE Runtime drivers - UEFI Runtime Drivers that use the DXE_RUNTIME_DRIVER MODULE_TYPE must not have a DEPEX section. If a library instance is required by a module that prohibits depex sections, the libraries depex section is ignored. For modules that do require a depex section, the depex section of all dependent libraries is ANDed with the depex section of the module.

Related Definitions
Target
Must match a target identifier in the EDK II tools_def.txt file - the first field, where fields are separated by the underscore character. Wildcard characters are not permitted.

TagName
Must match a tag name field in the EDK II tools_def.txt file - second field. Wildcard characters are not permitted

68

May 2010

Version 1.22

FDF

FDF File Format Specification

Example
[Capsule.Fob] CREATE_FILE = CAPSULE_A.fv CAPSULE_GUID = 42857F0A-13F2-4B21-8A23-53D3F714B840 CAPSULE_HEADER_SIZE = 32 FILE FV_IMAGE = EF41A0E1-40B1-481f-958E-6FB4D9B12E76 { SECTION GUIDED 3EA022A4-1439-4ff2-B4E4-A6F65A13A9AB { SECTION FV_IMAGE = Dxe { APRIORI DXE { INF a/a/a.inf INF a/c/c.inf INF a/b/b.inf } INF a/d/d.inf } } }

3.8 [Rule] Section

Summary
This describes the optional [Rule] section tag found in FDF files. This section is similar to the [FV] section, with the a few exceptions. The INF statements are not permitted within a rules section. Rules are used as templates, normally using variable names instead of fully qualified names, while INF statements are always are fully qualified file names. The following list specifies the allowed variables that may be used exactly as typed:
$(WORKSPACE), $(EDK_SOURCE), $(EFI_SOURCE), $(TARGET), $(TOOL_CHAIN_TAG), $(ARCH), $(MODULE_NAME), $(OUTPUT_DIRECTORY), $(BUILD_NUMBER), $(INF_VERSION), $(NAMED_GUID).

Prototype
<Rules> ::= "[Rule" <RuleArgs> "]" <EOL> <FileStatements> "." <Arch> "." <ModuleType> [<TemplateName>] {"IA32"} {"X64"} {"IPF"} {"EBC"} {"Common"} {[A-Z][A-Z0-9]*} {<EdkComponentType>} {<Edk2ModuleType>}

<RuleArgs>

::=

<Arch>

::=

<ModuleType>

::=

Version 1.22

May 2010

69

FDF File Format Specification

FDF

<Edk2ModuleType>

::=

{"SEC"} {"PEI_CORE"} {"PEIM"} {SMM_CORE} {"DXE_CORE"} {"DXE_DRIVER"} {"DXE_SAL_DRIVER"} {"DXE_SMM_DRIVER"} {"DXE_RUNTIME_DRIVER"} {"UEFI_DRIVER"} {"UEFI_APPLICATION"} {"USER_DEFINED"} {LIBRARY} {APPLICATION} {AcpiTable} {BINARY} {BS_DRIVER} {LOGO} {Legacy16} {Microcode} {PE32_PEIM} {RAWFILE} {RT_DRIVER} {SAL_RT_DRIVER} {SECURITY_CORE} {COMBINED_PEIM_DRIVER} {PIC_PEIM} {RELOCATABLE_PEIM} {PEI_CORE} "." <RuleUiName> <Word> if (MODULE_TYPE == SEC || MODULE_TYPE == PEI_CORE || MODULE_TYPE == PEIM || COMPONENT_TYPE == PEI_CORE || COMPONENT_TYPE == PIC_PEIM || COMPONENT_TYPE == RELOCATABLE_PEIM || COMPONENT_TYPE == SECURITY_CORE || COMPONENT_TYPE == PE32_PEIM ): "FILE" <FvType1> "=" <FileStatement1> <EOL> else if (MODULE_TYPE == DXE_CORE || MODULE_TYPE == DXE_DRIVER || MODULE_TYPE == DXE_SAL_DRIVER || MODULE_TYPE == SMM_CORE || MODULE_TYPE == DXE_SMM_DRIVER || MODULE_TYPE == UEFI_DRIVER || MODULE_TYPE == UEFI_APPLICATION || MODULE_TYPE == USER_DEFINED || COMPONENT_TYPE == BS_DRIVER || COMPONENT_TYPE == COMBINED_PEIM_DRIVER || COMPONENT_TYPE == APPLICATION): {<FileStatement2>} {<FileStatement3>} <EOL> else if (MODULE_TYPE == FV_IMAGE): <FileStatement4> else: "FILE" NON_FFS_FILE "=" [<NamedGuid>] <Options> <EOL> <NamedGuid> [<RelocFlags>] [<Options>] <EOL> FILE <FvType2> = <NamedGuid> [<Options>] <EOL> FILE RAW = <NamedGuidOrPcd>

<EdkComponentType>

::=

<TemplateName> <RuleUiName> <FileStatements>

::= ::= ::=

<FileStatement1>

::=

<FileStatement2>

::=

<FileStatement3>

::=

70

May 2010

Version 1.22

FDF

FDF File Format Specification

[<Options>] <EOL> <FileStatement4> ::= FILE FV_IMAGE = <NamedGuidOrPcd> [<Options>] <EOL> {$(NAMED_GUID)} {<RegistryFormatGuid>} {<Sym>} $( <Word> ) <NamedGuid> {PCD( <PcdName> )} {<GuidValue>} {"SEC"} {"PEI_CORE"} {"PEIM"} {"PEI_DXE_COMBO"} {"FREEFORM"} {"DRIVER"} {"DXE_CORE"} {"APPLICATION"} {SMM_CORE} {SMM} ["RELOCS_STRIPPED"] ["RELOCS_RETAINED"] [<UseLocal>] [<FileOpts>] <FileSpec> <KeyString> ["," <KeyString>] <Target> "_" <TagName> "_" <ToolArch> {<Word>} {"$(TARGET)"} {<Word>} {"$(TOOL_CHAIN_TAG)"} {<Arch>} {"$(ARCH)"} ["Fixed"] ["Checksum"] [<Align>] "Align" "=" <FfsValidAlign> {Auto} {"8"} {"16"} {"128"} {"512"} {"1K"} {"4K"} {"32K"} {"64K"} {<SimpleFile>} {<ComplexFile>} {<Ext>} <LeafSectionType> <FileOpts> <VarFile> <EOL> {"COMPAT16"} {"PE32"} {"PIC"} {"TE"} {"FV_IMAGE"} {"RAW"} {"DXE_DEPEX"} {"UI"} {"PEI_DEPEX"} {SMM_DEPEX} {"VERSION"} {"SUBTYPE_GUID"} {<FilenameVariable>} {<FName>} [<PATH>] <Word> "." <Word> [<PATH>] "$(MODULE_NAME)" "." <Word>

<NamedGuid>

::=

<Sym> <NamedGuidOrPcd>

::= ::=

<FvType1>

::=

<FvType2>

::=

<RelocFlags> <Options> <UseLocal> <KeyString> <Target> <TagName> <ToolArch> <FileOpts> <Align> <FfsValidAlign>

::= ::= ::= ::= ::= ::= ::= ::= ::= ::=

<FileSpec> <SimpleFile>

::= ::=

<LeafSectionType>

::=

<VarFile> <FName> <FilenameVariable>

::= ::= ::=

Version 1.22

May 2010

71

FDF File Format Specification

FDF

<PATH> <AbsolutePath>

::= ::=

[<AbsolutePath>] [<BuildId>] <RelativePath> {"$(WORKSPACE)" "/"} {"$(EDK_SOURCE)" "/"} {"$(OUTPUT_DIRECTORY)" "/"} <Word> "/" [<Word> "/"]* "$(TARGET)_$(TOOL_CHAIN_TAG)/" ["$(ARCH)/"] <Word> "{" <EOL> [<EncapsulationSection>]* [<LeafSections>]* "}" <EOL> {<CompressSection>} {<GuidedSection>} "COMPRESS" [<CompType>] "{" <EOL> [<EncapsulationSec>]* [<LeafSections> <EOL>]* "}" <EOL> {"PI_STD"} {"PI_NONE"} "GUIDED" "$(NAMED_GUID)" [<GAttr>] "{" <EOL> [<EncapsulationSec>]* [<LeafSection>]* "}" <EOL> [<GuidAttr>]{0,2} [<GuidHeaderSize>] <AttrName> "=" <TrueFalse> {"PROCESSING_REQUIRED"} {"AUTH_STATUS_VALID"} "EXTRA_HEADER_SIZE" "=" <NumValue> {<C16Sec>} {<PeSec>} {<PicSec>} {<TeSec>} {<FvSec>} {<RawSec>} {<DxeDepSec>} {<UiSec>} {<VerSec>} {<PeiDepSec>} {<SmmDepSec>} {<SubGuidSec>} "COMPAT16" <C16FileType> [<FileOrExt>] <EOL> "PE32" <Pe32FileType> [<FileOrExt>] <EOL> "PIC" <PicFileType> [<FileOrExt>] <EOL> "TE" <TeFileType> [<FileOrExt>] <EOL>

<RelativePath> <BuildId> <Extension> <ComplexFile>

::= ::= ::= ::=

<EncapsulationSection> ::= <CompressSection> ::=

<CompTyp> <GuidedSection>

::= ::=

<GAttr> <GuidAttr> <AttrName>

::= ::= ::=

<GuidHeaderSize> <LeafSections>

::= ::=

<C16Sec>

::=

<PeSec> <PicSec> <TeSec>

::= ::= ::=

72

May 2010

Version 1.22

FDF

FDF File Format Specification

<RawSec> <DxeDepSec> <SmmDepSec> <UiSec> <VerSec> <PeiDepSec>

::= ::= ::= ::= ::= ::=

"RAW" <RawFileType> [<FileOrExtOrPcd>] <EOL> "DXE_DEPEX" <DdFileType> [<FileOrExt>] <EOL> "SMM_DEPEX" <DdFileType> [<FileOrExt>] <EOL> "UI" <UiFileType> [<FileOrExt>] <EOL> "VERSION" <VerFileType> [<FileOrExt>] <EOL> "PEI_DEPEX" <PdFileType> [<FileOrExt>] <EOL> "GUID" <GuidFileType> [<FileOrExt>] <EOL> {<VarFile>} {<Ext>} {<VarFile>} {<Ext>} {PCD( <PcdName> )} "|" "." [a-zA-Z][a-zA-Z0-9]{0,} {"COMPAT16"} {"SEC_COMPAT16"} [<Align>] {"PE32"} {"SEC_PE32"} [<Align>] [<ChkReloc>] if (MODULE_TYPE == SEC || MODULE_TYPE == PEI_CORE || MODULE_TYPE == PEIM): [<RelocFlags>] {"PIC"} {"SEC_PIC"} [<Align>] {"TE"} {"SEC_TE"} [<Align>] [<ChkReloc>] {<BinTypes>} {<AcpiTypes>} [<Align>] {"BIN"} {"SEC_BIN"} {"RAW"} {ACPI} {ASL} [Optional] {"DXE_DEPEX"} {"SEC_DXE_DEPEX"} {SMM_DEPEX} [<DpxAlign>] ["Optional"] [<Align>] {<UiFile>} {<UiString>} {"UI"} {"SEC_UI"} [<UiOpts>] "STRING" "=" <StringVal> [<Align>] {<UnicodeString>} {<QuotedString>} {<MacroValues>} {"$(INF_VERSION)"} {"$(MODULE_NAME))"

<SubGuidSec> <FileOrExt> <FileOrExtOrPcd> <Ext> <C16FileType> <Pe32FileType>

::= ::= ::= ::= ::= ::=

<ChkReloc>

::=

<PicFileType> <TeFileType> <RawFileType> <BinTypes> <AcpiFileTypes> <DdFileType>

::= ::= ::= ::= ::= ::=

<DpxAlign> <UiFileType> <UiFile> <UiString> <StringVal> <MacroValues>

::= ::= ::= ::= ::= ::=

Version 1.22

May 2010

73

FDF File Format Specification

FDF

<UiOpts> <VerFileType> <VerFile> <VerOpts> <VerString> <VerStringVal>

::= ::= ::= ::= ::= ::=

["Optional"] [<Align>] {<VerFile>} {<VerString>} {"VERSION"} {"SEC_VERSION"} [<VerOpts>] ["Optional"] [<BuildAlign>] "STRING" "=" <VerStringVal> [<BuildAlign>] {<UnicodeString>} {<QuotedString>} {"$(INF_VERSION)"} [<BuildArg>] [<Align>] "BUILD_NUM = $(BUILD_NUMBER)" {"PEI_DEPEX"} {"SEC_PEI_DEPEX"} [<DpxAlign>] {"GUID"} {"SEC_GUID"} [<Align>] "FV_IMAGE" {<FvBin>} {<FvImageSection>} "FV" [<Align>] [<FileOrExt>] <EOL> "FV_IMAGE" <FvImgArgs> "{" <EOL> [<DefineStatements>]* [<FvAlignment>] [<FvAttributes>]* [<ApriorSection>] [<FileStatements>]* "}" <EOL> "FvAlignment" "=" <FvValidAign> <EOL> {"1"} {"2"} {"4"} {"8"} {"16"} {"32"} {"64"} {"128"} {"256"} {"512"} {"1K"} {"2K"} {"4K"} {"8K"} {"16K"} {"32K"} {"64K"} {"128K"} {"256K"} {"512K"} {"1M"} {"2M"} {"4M"} {"8M"} {"16M"} {"32M"} {"64M"} {"128M"} {"256M"} {"512M"} {"1G"} {"2G"} <Attribute> "=" <TrueOrFalse> <EOL> {<FvAttributeSet>} {<FvAttributeClear>} {"ERASE_POLARITY"} {"MEMORY_MAPPED"} {"STICKY_WRITE"} {"LOCK_CAP"} {"LOCK_STATUS"} {"WRITE_ENABLED_CAP"} {"WRITE_DISABLED_CAP"} {"WRITE_STATUS"}

<BuildAlign> <BuildArg> <PdFileType>

::= ::= ::=

<GuidFileType> <FvSec> <FvBin> <FvImgSection> <FvImgArgs>

::= ::= ::= ::= ::=

<FvAlignment> <FvValidAlign>

::= ::=

<FvAttributes> <Attribute> <FvAttributeSet>

::= ::= ::=

74

May 2010

Version 1.22

FDF

FDF File Format Specification

{"READ_ENABLED_CAP"} {"READ_DISABLED_CAP"} {"READ_STATUS"} {"READ_LOCK_CAP"} {"READ_LOCK_STATUS"} {"WRITE_LOCK_CAP"} {"WRITE_LOCK_STATUS"} <FvAttributeClear> <PeiAprioriSection> ::= ::= "WRITE_POLICY_RELIABLE" "APRIORI PEI {" <EOL> [<DefineStatements>]* [<FileStatements>]* "}" <EOL> "APRIORI DXE {" <EOL> [<DefineStatements>]* [<FileStatements>]* "}" <EOL>

<DxeAprioriSection>

::=

Parameters
RuleUiName
A unique single word identifier.

Related Definitions
Target
Must match a target identifier in the EDK II tools_def.txt file - the first field, where fields are separated by the underscore character. Wildcard characters are not permitted.

TagName
Must match a tag name field in the EDK II tools_def.txt file - second field. Wildcard characters are not permitted

Version 1.22

May 2010

75

FDF File Format Specification

FDF

Example
[Rule.IA32.SEC] FILE SEC = $(NAMED_GUID) Fixed Align=32 |.efi [Rule.Common.PEIM] FILE PEIM = $(NAMED_GUID) { TE SEC_TE |.TE PEI_DEPEX SEC_PEI_DEPEX Optional |.Depex VERSION STRING = "$(INF_VERSION)" Optional BUILD_NUM = $(BUILD_NUM) UI UNI_UI Optional | .UNI } [Rule.Common.PEIM.PE32] FILE PEIM = $(NAMED_GUID) { PEI_DEPEX PEI_DEPEX Optional | .dxs COMPRESS { PE32 SEC_PE32 |.EFI VERSION UNI_VER Optional BUILD_NUM = $(BUILD_NUM) | .ver UI UI Optional | .UI } }

3.9 [VTF] Section

Summary
This describes the optional [VTF] section tag found in FDF files. If VTF files will be created, they will be created in the $(OUTPUT_DIRECTORY)/ $(TARGET)_$(TAGNAME)/FV directory using the values from the individual instance of the build tools. (Build tools get these values after parsing DSC, INF, target.txt, tools_def.txt files and command line options.) The following sequence describes each component:
Name = Region Type Version CheckSum_Flag Path_of_Binary_File Path_of_SYM_File Preferred_Size , , , , , , ;

Where,

Name:
Name of the component

Region:
Location in the firmware. Valid locations are:

76

May 2010

Version 1.22

FDF

FDF File Format Specification

PH - Protected Block region, PL - Protected Block region, H - Flashable region, merged L - Flashable region, merged F - First VTF File N - Not in VTF File S - Second VTF File

merged towards the higher address merged towards the lower address towards the higher address towards the lower address

Type:
Component Type. Predefined values are: 0x00 : FIT Header entry 0x01 : PAL_B 0x02 - 0x0E : Reserved 0x0F : PAL_A 0x10 - 0x7E : OEM-defined 0x7F : Unused

Version:
Component Version number (XX.YY) XX - major version number (decimal number, range of 00 to 99) YY - minor version number (decimal number, range of 00 to 99) Checksum_Flag: Checksum Flag (equivalent to CV bit) 0 - Checksum Byte always equals 0, CV=0 1 - calculate Checksum Byte, CV=1

(Checksum:
Byte sum of component + Checksum Byte = modulus 0x100)

Path_of_Binary_File:
Path of the Binary file of the component

Path_of_SYM_File:
Path of the .SYM symbol file of the component

Preferred_Size:
User preferred component size, overrides actual component file size. Valid is equal or greater than the actual file size.

Version 1.22

May 2010

77

FDF File Format Specification

FDF

Prototype
<VTF> ::= "[VTF" <Modifiers> "]" <EOL> [<OptionStatement>] [<ComponentStatements>]+ "." <Arch> "." <UiName> [<ArchList>] "," <Arch> {"IA32"} {"X64"} {"IPF"} <Word> "IA32_RST_BIN" "=" <Filename> [<PATH>] <Word> "." "bin" [<AbsolutePath>] <RelativePath>

<Modifiers> <ArchList> <Arch> <UiName> <OptionStatement> <Filename> <PATH>

::= ::= ::= ::= ::= ::= ::=

78

May 2010

Version 1.22

FDF

FDF File Format Specification

<AbsolutePath>

::=

{"$(WORKSPACE)" "/"} {"$(OUTPUT_DIRECTORY)" "/"} [<BuildId>] <Word> "/" [<Word> "/"]* "$(TARGET)_$(TOOL_CHAIN_TAG)/" ["$(ARCH)/"] "COMP_NAME" "=" <WORD> <EOL> "COMP_LOC" "=" <Location> <EOL> "COMP_TYPE" "=" <CompType> <EOL> "COMP_VER" "=" <Version> <EOL> "COMP_CS" "=" {"1"} {"0"} <EOL> "COMP_BIN" "=" <BinFile> <EOL> "COMP_SYM" "=" <SymFile> <EOL> "COMP_SIZE" "=" <Size> <EOL> <FvUiName> ["|" <Region>] {"F"} {"N"} {"S"} {"H"} {"L"} {"PH"} {"PL"} {"FIT"} {"PAL_B"} {"PAL_A"} {"OEM"} {<Byte>} "0x" [0-9a-zA-Z]{0,1}[0-9a-zA-Z]{1} {"-"} {<Major> "." <Minor>} [0-9]{0,1}[0-9]{1} [0-9]{0,1}[0-9]{1} {"-"} {[<PATH>]* <Word> "." "bin"} {"-"} {[<PATH>]* <Word> "." "sym"} {"-"} {<Integer>} {<HexNumber>} "#" [<String>]

<RelativePath> <BuildId> <ComponentStatements>

::= ::= ::=

<Location> <Region> <CompType>

::= ::= ::=

<Byte> <Version> <Major> <Minor> <BinFile> <SymFile> <Size> <Comment>

::= ::= ::= ::= ::= ::= ::= ::=

Example
[VTF.IPF.MyBsf] IA32_RST_BIN = IA32_RST.BIN COMP_NAME COMP_LOC COMP_TYPE COMP_VER COMP_CS COMP_BIN COMP_SYM COMP_SIZE = = = = = = = = PAL_A F 0xF 7.01 1 PAL_A_GEN.BIN PAL_A_GEN.SYM # # # # # # # # Component Name In the first VTF file Component Type (PAL_A=0x0F, defined in SAL Spec.) Version will come from header of PAL_A binary Checksum_Validity (CV bit) Path of binary Path of SYM symbol Preferred component size in bytes

COMP_NAME = PAL_B COMP_LOC = F COMP_TYPE = 0x01

# Component Name # In the first VTF file # Component Type (PAL_A=0x0F, defined in SAL Spec.)

Version 1.22

May 2010

79

FDF File Format Specification

FDF

COMP_VER COMP_CS COMP_BIN COMP_SYM COMP_SIZE

= = = = =

1 PAL_B.BIN PAL_B.Sym -

# # # # #

Version will come from header of PAL_A binary Checksum_Validity (CV bit) Path of binary Path of SYM symbol Preferred component size in bytes

3.10 PCI OptionRom Section

This is an optional section. This section is used to specify the content of a PCI Option ROM container. A PCI Option ROM image may contain zero or more PCI ROM image files - binary only, and zero or more UEFI driver images, specified by either binary or INF files, that are to be packaged into a single Option ROM image. Additionally, support for a single EFI driver with both native (IA32, X64, IPF, etc). and EBC images in the same PCI Option ROM container is provided.

Prototype
<OptionRom> ::= [OptionRom . <DriverName> ] <EOL> [<Components>]+ [a-zA-Z][a-zA-Z0-9]* {<InfComponent>} {<Binary>} "INF" USE = <TargetArch> <InfFile> [<Overrides>] <EOL> {IA32} {X64} {IPF} {EBC} {[A-Z][A-Z0-9]*} <Path> <Word> ".inf" <EOL> [{"$(WORKSPACE)/"} {"$(EDK_SOURCE)/"} {"$(EFI_SOURCE)/"}] <RelativePath> <Word> "/" [<Word> "/"]* { <EOL> [PCI_VENDOR_ID = <HexNumber> <EOL>] [PCI_CLASS_CODE = <HexNumber> <EOL>] [PCI_DEVICE_ID = <HexNumber> <EOL>] [PCI_REVISION = <HexNumber> <EOL>] COMPRESS = <TrueFalse> <EOL> } <EOL> {<EfiBinary>} {<OtherBinary>} FILE EFI <EfiFileName> [<Overrides>] <EOL> <FullPath> <Word> ".efi" FILE BIN <Filename> <EOL> <FullPath> <Word> "." <Word> <EOL>

<DriverName> <Components> <InfComponent> <TargetArch> <InfFile> <Path>

::= ::= ::= ::= ::= ::=

<RelativePath> <Overrides>

::= ::=

<Binary> <EfiBinary> <EfiFilename> <OtherBinary> <Filename>

::= ::= ::= ::= ::=

80

May 2010

Version 1.22

FDF

FDF File Format Specification

<FullPath> <AbsolutePath>

::= ::=

[<AbsolutePath>] <RelativePath> {"$(WORKSPACE)/"} {"$(EDK_SOURCE)/"} {"$(OUTPUT_DIRECTORY)/"} {"$(EFI_SOURCE)/"}

Related Definitions
TargetArch
Must be a single target architecture only. Multiple lines may be specified to with different TargetArch values. Wildcard characters are not permitted.

DriverName
Specifies the name of the created PCI Option ROM image that will be placed in the builds FV directory.

USE
Specifies the architecture to use to create a PCI Option ROM.

Example
[OptionRom.AtapiPassThru] INF USE = IA32 OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf { PCI_REVISION = 0x0020 } INF USE = EBC OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf

3.11 UserExtensions Section

One or more user extension sections, which are build specific, may be used in the FDF file. This permits definition of custom image creation steps, file formats or build rules. The user must have a priori knowledge of any processing involved for this content.

Prototype
<UserExtension> ::= [UserExtension. <UserUnique> ] <EOL> [<Statements>]+ ::= <UserId> [<Identifier>]

<UserUnique> <UserId> <ReservedUserId> <Identifier> <ReservedId> <Statements>

::= {<Word>} {<ReservedUserId>} ::= TianoCore ::= {<Word>} {<QuotedString>}{<ReservedId>} ::= {PRE_PROCESS} {POST_PROCESS} ::= [<AsciiString> <EOL>]+

Parameters
Statements
Content is user defined, and unique for any given UserId/Identifier pair.

Version 1.22

May 2010

81

FDF File Format Specification

FDF

82

May 2010

Version 1.22

FDF

Appendix A Sample Flash Description File

This section provides a sample FDF file.

Version 1.22

May 2010

83

FDF

Note: This file should NOT be used as is, as data structures and definitions do not exist.
## @file Nt32Pkg.fdf # This is NT32 FDF file with UEFI HII features enabled # # Copyright (c) 2007, Intel Corporation. All rights reserved. # # This program and the accompanying materials are licensed and made available # under the terms and conditions of the BSD License which accompanies this # distribution. The full text of the license may be found at: # http://opensource.org/licenses/bsd-license.php # # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. # ################################################################################ # # FD Section # The [FD] Section is made up of the definition statements and a # description of what goes into the Flash Device Image. Each FD section # defines one flash "device" image. A flash device image may be one of # the following: Removable media bootable image (like a boot floppy # image,) an Option ROM image (that would be "flashed" into an add-in # card,) a System "Flash" image (that would be burned into a system's # flash) or an Update ("Capsule") image that will be used to update and # existing system flash. # ################################################################################ [FD.Fv_Recovery] BaseAddress = 0x0|gEfiNt32PkgTokenSpaceGuid.PcdWinNtFdBaseAddress #The base address of the FLASH Device. Size = 0x002a0000 #The size in bytes of the FLASH Device ErasePolarity = 1 BlockSize = 0x10000 NumBlocks = 0x2a ################################################################################ # # Following are lists of FD Region layout which correspond to the locations of # different images within the flash device. # # Regions must be defined in ascending order and may not overlap. # # A Layout Region start with a eight digit hex offset (leading "0x" required) # followed by the pipe "|" character, followed by the size of the region, also in # hex with the leading # "0x" characters. Like: # Offset|Size # PcdOffsetCName|PcdSizeCName # RegionType <FV, DATA, or FILE> # ################################################################################ 0x00000000|0x00280000

84

May 2010

Version 1.22

FDF

gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashFvRecoveryBase| \ gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashFvRecoverySize FV = FvRecovery 0x00280000|0x0000c000 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageVariableBase| \ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize #NV_VARIABLE_STORE DATA = { ## This is the EFI_FIRMWARE_VOLUME_HEADER # ZeroVector [] 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, # FileSystemGuid: gEfiSystemNvDataFvGuid = # { 0xFFF12B8D, 0x7696, 0x4C8B, \ # { 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50 }} 0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C, 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50, # FvLength: 0x20000 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, #Signature "_FVH" #Attributes 0x5f, 0x46, 0x56, 0x48, 0xff, 0xfe, 0x04, 0x00, #HeaderLength #CheckSum #ExtHeaderOffset #Reserved #Revision 0x48, 0x00, 0x36, 0x09, 0x00, 0x00, 0x00, 0x02, #Blockmap[0]: 2 Blocks * 0x10000 Bytes / Block 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, #Blockmap[1]: End 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ## This is the VARIABLE_STORE_HEADER #Signature: "$VSS" #Size: 0xc000 \ # (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) - \ # 0x48 (HeaderLength) = 0xBFB8 # This can speed up the Variable Dispatch a bit. 0x24, 0x56, 0x53, 0x53, 0xB8, 0xBF, 0x00, 0x00, #FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32 0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } 0x0028c000|0x00002000 #NV_EVENT_LOG gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageEventLogBase| \ gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageEventLogSize 0x0028e000|0x00002000 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageFtwWorkingBase| \ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize #NV_FTW_WORKING DATA = { # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = \ # gEfiSystemNvDataFvGuid = \ # { 0xFFF12B8D, 0x7696, 0x4C8B, \ # { 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50 }} 0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C, 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50, # Crc:UINT32

Version 1.22

May 2010

85

FDF

# WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved 0x77, 0x13, 0x9B, 0xD7, 0xFE, 0xFF, 0xFF, 0xFF, # WriteQueueSize: UINT64 0xE0, 0x1F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 } 0x00290000|0x00010000 #NV_FTW_SPARE gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageFtwSpareBase| \ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize ############################################################################### # # FV Section # # [FV] section is used to define what components or modules are placed within a # flash device file. This section also defines order the components and modules # are positioned within the image. The [FV] section consists of define # statements, set statements and module statements. # ############################################################################### [FV.FvRecovery] FvAlignment = 16 #FV alignment and FV attributes setting. ERASE_POLARITY = 1 MEMORY_MAPPED = TRUE STICKY_WRITE = TRUE LOCK_CAP = TRUE LOCK_STATUS = TRUE WRITE_DISABLED_CAP = TRUE WRITE_ENABLED_CAP = TRUE WRITE_STATUS = TRUE WRITE_LOCK_CAP = TRUE WRITE_LOCK_STATUS = TRUE READ_DISABLED_CAP = TRUE READ_ENABLED_CAP = TRUE READ_STATUS = TRUE READ_LOCK_CAP = TRUE READ_LOCK_STATUS = TRUE ############################################################################### # # The INF statements point to EDK component and EDK II module INF files, which # will be placed into this FV image. # Parsing tools will scan the INF file to determine the type of component or # module. # The component or module type is used to reference the standard rules # defined elsewhere in the FDF file. # # The format for INF statements is: # INF $(PathAndInfFileName) # ############################################################################### ## # PEI Phase modules

86

May 2010

Version 1.22

FDF

## ## # PEI Apriori file example, more PEIM module added later. ## APRIORI PEI { INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf INF IntelFrameworkModulePkg/Universal/StatusCode/Pei/PeiStatusCode.inf } APRIORI DXE { INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf INF Nt32Pkg/MetronomeDxe/MetronomeDxe.inf } INF INF INF INF INF INF INF INF INF INF INF ## # ## INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF INF MdeModulePkg/Core/Pei/PeiMain.inf MdeModulePkg/Universal/PCD/Pei/Pcd.inf IntelFrameworkModulePkg/Universal/StatusCode/Pei/PeiStatusCode.inf Nt32Pkg/BootModePei/BootModePei.inf Nt32Pkg/WinNtFlashMapPei/WinNtFlashMapPei.inf MdeModulePkg/Universal/MemoryTest/BaseMemoryTestPei/BaseMemoryTestPei.inf Nt32Pkg/WinNtAutoScanPei/WinNtAutoScanPei.inf Nt32Pkg/WinNtFirmwareVolumePei/WinNtFirmwareVolumePei.inf MdeModulePkg/Universal/Variable/Pei/VariablePei.inf Nt32Pkg/WinNtThunkPPIToProtocolPei/WinNtThunkPPIToProtocolPei.inf MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf

DXE Phase modules MdeModulePkg/Core/Dxe/DxeMain.inf MdeModulePkg/Universal/PCD/Dxe/Pcd.inf Nt32Pkg/MetronomeDxe/MetronomeDxe.inf Nt32Pkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf Nt32Pkg/ResetRuntimeDxe/ResetRuntimeDxe.inf MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf Nt32Pkg/FvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf IntelFrameworkModulePkg/Universal/DataHubDxe/DataHubDxe.inf MdeModulePkg/Universal/EbcDxe/EbcDxe.inf MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf Nt32Pkg/WinNtThunkDxe/WinNtThunkDxe.inf Nt32Pkg/CpuRuntimeDxe/CpuRuntimeDxe.inf MdeModulePkg/Universal/BdsDxe/BdsDxe.inf MdeModulePkg/Universal/FirmwareVolume/FaultTolerantWriteDxe/FtwLite.inf IntelFrameworkModulePkg/Universal/DataHubStdErrDxe/DataHubStdErrDxe.inf Nt32Pkg/MiscSubClassPlatformDxe/MiscSubClassPlatformDxe.inf Nt32Pkg/TimerDxe/TimerDxe.inf IntelFrameworkModulePkg/Universal/StatusCode/Dxe/DxeStatusCode.inf MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf MdeModulePkg/Universal/WatchDogTimerDxe/WatchDogTimer.inf MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf

Version 1.22

May 2010

87

FDF

INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf INF IntelFrameworkModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf # The following driver follows UEFI specification definition INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf # The following driver follows UEFI specification definition INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf INF IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf INF Nt32Pkg/WinNtBusDriverDxe/WinNtBusDriverDxe.inf INF Nt32Pkg/WinNtBlockIoDxe/WinNtBlockIoDxe.inf INF Nt32Pkg/WinNtSerialIoDxe/WinNtSerialIoDxe.inf INF Nt32Pkg/WinNtGopDxe/WinNtGopDxe.inf INF Nt32Pkg/WinNtSimpleFileSystemDxe/WinNtSimpleFileSystemDxe.inf INF MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf INF MdeModulePkg/Application/HelloWorld/HelloWorld.inf ################################################################################ # # FILE statements are provided so that a platform integrator can include # complete EFI FFS files, as well as a method for constructing FFS files # using curly "{}" brace scoping. The following three FILEs are # for binary shell, binary fat and logo module. # ################################################################################ FILE APPLICATION = c57ad6b7-0515-40a8-9d21-551652854e37 { SECTION COMPRESS PI_STD { SECTION GUIDED { SECTION PE32 = EdkShellBinPkg/FullShell/ia32/Shell_Full.efi } } } FILE DRIVER = 961578FE-B6B7-44c3-AF35-6BC705CD2B1F { SECTION COMPRESS PI_STD { SECTION GUIDED { SECTION PE32 = FatBinPkg/EnhancedFatDxe/Ia32/Fat.efi } } } FILE FREEFORM = 7BB28B99-61BB-11D5-9A5D-0090273FC14D { SECTION COMPRESS PI_STD { SECTION GUIDED { SECTION RAW = MdeModulePkg/Logo/Logo.bmp } } }

################################################################################ # # Rules are use with the [FV] section's module INF type to define # how an FFS file is created for a given INF file. The following Rule are the

88

May 2010

Version 1.22

FDF

# default rules for the different module type. User can add the customized rules # to define the content of the FFS file. # ################################################################################

############################################################################ # Example of a DXE_DRIVER FFS file with a Checksum encapsulation section # ############################################################################ # #[Rule.Common.DXE_DRIVER] # FILE DRIVER = $(NAMED_GUID) { # DXE_DEPEX DXE_DEPEX Optional |.depex # COMPRESS PI_STD { # GUIDED { # PE32 PE32 |.efi # UI STRING="$(MODULE_NAME)" Optional # VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) # } # } # } # ############################################################################ [Rule.Common.PEI_CORE] FILE PEI_CORE = $(NAMED_GUID) { PE32 PE32 |.efi UI STRING ="$(MODULE_NAME)" Optional VERSION STRING ="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) } [Rule.Common.PEIM] FILE PEIM = $(NAMED_GUID) { PEI_DEPEX PEI_DEPEX Optional |.depex PE32 PE32 |.efi UI STRING="$(MODULE_NAME)" Optional VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) } [Rule.Common.PEIM.TIANOCOMPRESSED] FILE PEIM = $(NAMED_GUID) DEBUG_MYTOOLS_IA32 { PEI_DEPEX PEI_DEPEX Optional |.depex GUIDED A31280AD-481E-41B6-95E8-127F4C984779 PROCESSING_REQUIRED = TRUE { PE32 PE32 |.efi UI STRING="$(MODULE_NAME)" Optional VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) } } [Rule.Common.DXE_CORE] FILE DXE_CORE = $(NAMED_GUID) { COMPRESS PI_STD { PE32 PE32 |.efi UI STRING="$(MODULE_NAME)" Optional VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)

Version 1.22

May 2010

89

FDF

} } [Rule.Common.UEFI_DRIVER] FILE DRIVER = $(NAMED_GUID) { DXE_DEPEX DXE_DEPEX Optional COMPRESS PI_STD { GUIDED { PE32 PE32 UI STRING="$(MODULE_NAME)" VERSION STRING="$(INF_VERSION)" } } } [Rule.Common.DXE_DRIVER] FILE DRIVER = $(NAMED_GUID) { DXE_DEPEX DXE_DEPEX Optional COMPRESS PI_STD { GUIDED { PE32 PE32 UI STRING="$(MODULE_NAME)" VERSION STRING="$(INF_VERSION)" } } } [Rule.Common.DXE_RUNTIME_DRIVER] FILE DRIVER = $(NAMED_GUID) { DXE_DEPEX DXE_DEPEX Optional COMPRESS PI_STD { GUIDED { PE32 PE32 UI STRING="$(MODULE_NAME)" VERSION STRING="$(INF_VERSION)" } } }

|.depex

|.efi Optional Optional BUILD_NUM=$(BUILD_NUMBER)

|.depex

|.efi Optional Optional BUILD_NUM=$(BUILD_NUMBER)

|.depex

|.efi Optional Optional BUILD_NUM=$(BUILD_NUMBER)

[Rule.Common.UEFI_APPLICATION] FILE APPLICATION = $(NAMED_GUID) { COMPRESS PI_STD { GUIDED { PE32 PE32 |.efi UI STRING="$(MODULE_NAME)" Optional VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER) } } }

90

May 2010

Version 1.22

FDF

Appendix B Common Error Messages

Standard build tools should throw error messages, halting the build. Warning messages may be emitted from build tools, unless a quiet flag has been set on the command-line.

B.1 [FD] Syntax Errors:

Missing required Token statements - report line number and file name. Size of the FV (%s) is larger than the Region Size 0x%X specified. The named FV (%s) is not listed in the FDF file. Size of the DATA is larger than the region size specified. Size of the FILE (%s) is larger than the region size specified. The region at Offset 0x%X cannot fit into Block array with BlockSize %X. Region: %s is not in the FD address scope.

B.2 [FV] Syntax Errors:

Missing required Token statements - report line number and file name. Incorrect alignment in the FV.

B.3 [CAPSULE] Syntax Errors:

No capsule specific errors, as all capsule errors are captured under other parser errors.

B.4 [Rule] Syntax Errors:

Unable to find rule for INF %s. Module built under different architectures, unable to determine which module to use.

Version 1.22

May 2010

91

FDF

92

May 2010

Version 1.22

FDF

Appendix C Reports
The following reports could be generated by either usage enhancement tools or the build tools. These are only suggestions for reports, and the reference build tools may or may not provide reports matching these types.

C.1 [FD] Reports:

Show layout of each FD, showing all FV images in the FD. Show layout size of FD images. Show total number of bytes in the image. Show the percent utilization of the image with respect to the FD image size.

C.2 [FV] Reports:

Show content of each FV Image in an FD image.

C.3 [CAPSULE] Reports:

Show content of each Capsule image.

Version 1.22

May 2010

93

FDF

94

May 2010

Version 1.22