A.1 Design Discussion

Directive statements are permitted within the EDK INF files.

A.1.1 [defines] Section

The [defines] section of an EDK INF file is used to define variable assignments that can be used in later build steps. The EDK parsing utilities process local symbol assignments made in this section. Note that the sections are processed in the order listed here, and later assignments of these local symbols do not override previous assignments.

This section will typically use one of the following section definitions:

[define]
[defines]
[defines.IA32]
[defines.X64]
[defines.IPF]
[defines.EBC]

Note: The [define] section tag is only valid for EDK INF files. EDK II INF files must use the 'defines' keyword.


The format for entries in this section is:

Name = Value

The following is an example of this section.

[defines]
  BASE_NAME      = DiskIo
  FILE_GUID      = CA261A26-7718-4b9b-8A07-5178B1AE3A02
  COMPONENT_TYPE = BS_DRIVER

The following table lists the possible content of this section.

Table 6 EDK [defines] Section Elements
Tag Required Value Notes
BASE_NAME Yes A single word This is a single word identifier that will be used for the component name.
COMPONENT_TYPE Yes One of the EDK I Component Types See Table EDK I Component (module) Types for possible values
FILE_GUID No--Optional for Libraries, Required for all other component types Guid Value Registry (8-4-4-4-12) Format GUID
EDK_RELEASE_VERSION No--Optional Hex Value A Hex version number, 0x00020000
EFI_SPECIFICATION_VERSION No--Optional HexValue A Hex version number, 0x00020000
MAKEFILE_NAME No--Optional Filename.ext The name of the Makefile to be generated for this component
CUSTOM_MAKEFILE No--Optional Filename.ext This specifies the name of a custom makefile that should be used, instead of a generated makefile. NOTE: EDK INF components specifying a custom EDK style makefile cannot be used in an EDK II build.
BUILD_NUMBER No--Optional Set this four digit value in the generated Makefile Normally not used in INF files.
C_FLAGS No--Optional Microsoft C Flags to use with for a cl commands for this module Normally not used in INF files. Typically, an EDK INF file will provide a separate nmake section to specify different build parameters.
FFS_EXT No--Optional File Extension The FFS extension to use for this component, refer to the table _EDK I Component (module) Types for the default FFS extension. This value is used to create a component PKG file.
FV_EXT No--Optional File Extension The FV extension to use for this component, refer to the table _EDK I Component (module) Types for the default FV extension.
SOURCE_FV No--Optional Word If present, the variable is set at the beginning of the generated makefile
VERSION No--Optional Four digit integer If present, this value will be used for the VERSION section of the FFS.
VERSION_STRING No--Optional String If present, this value will be used to generate the UNICODE file for the VERSION section of the FFS.

The following table lists the available COMPONENT_TYPE values supported by EDK INF files.

Table 7 EDK Component (module) Output File Extensions
COMPONENT_TYPE EDK II Extension EDK File, FFS or FV Extension Description
LIBRARY .lib .lib Library component linked as part of the build with other components.
FILE From file name or .FFS From file name or .FFS Raw file copied directly to FV
Apriori .bin .SEC This EDK INF component is not supported in the EDK II build - it is created from content in other EDK II build meta-data files.
EFI Binary Executable .efi .pe32 PE32/PE32+/Coff binary executable. The extension of the file has changed for EDK II builds which generate processed (GenFw) images.
AcpiTable .acpi .SEC An ACPI Table.
Legacy16 .bin .SEC The MODULE_TYPE for a Legacy16 when migrating to EDK II should be specified as USER_DEFIND. The .rom or .bin file should be included under a [binaries] section. In EDK, the COMPONENT_TYPE of Legacy16 was mostly used to specify PCI Option ROMs.
BINARY .bin .FFS
CONFIG .bin .SEC
LOGO .bin .SEC The MODULE_TYPE for a LOGO when migrating to EDK II should be specified as USER_DEFINED. The .bmp file should be include under a [binaries] section. In EDK, the COMPONENT_TYPE of LOGO was used to specify a .bmp file.
RAWFILE .raw .RAW
FVIMAGEFILE .fv .FVI
SECURITY_CORE .efi .SEC Modules of this type are designed to start execution at the reset vector of a CPU. They are responsible for preparing the platform for the PEI Phase. Since there are no standard services defined for SEC, modules of this type follow the same rules as modules of type Base and typically include some amount of CPU specific assembly code to establish temporary memory for a stack. Modules of this type may optionally produce services that are passed to the PEI Phase in HOBs and those services must be compliant with the PEI CIS.
PEI_CORE .efi .PEI This module type is used by PEI Core implementations that are complaint with the PEI CIS.
COMBINED_PEIM_DRIVER .efi .PEI
PIC_PEIM .efi .PEI
RELOCATABLE_PEIM .efi .PEI When migrating to EDK II, this type of module should use the register for shadow PPI, and set the [defines] entry: SHADOW = TRUE
PE32_PEIM .efi .PEI This module type is used by PEIMs that are compliant with the PEI CIS
BS_DRIVER .efi .DXE This module type is either the DXE Core or DXE Drivers that are complaint with the DXE CIS. These modules only execute in the boot services environment and are destroyed when ExitBootServices() is called.
RT_DRIVER .efi .DXE This module type is used by DXE Drivers that are complaint with the DXE CIS. These modules execute in both boot services and runtime services environments. This means the services that these modules produce are available after ExitBootServices() is called. If SetVirtualAddressMap() is called, then modules of this type are relocated according to virtual address map provided by the operating system.
SAL_RT_DRIVER .efi .DXE This module type is used by DXE Drivers that can be called in physical mode before SetVirtualAddressMap() is called and either physical mode or virtual mode after SetVirtualAddressMap() is called. This module type is only available to IPF CPUs. This means the services that these modules produce are available after ExitBootServices().
BS_DRIVER .efi .SMM This module type is used by DXE Drivers that are loaded into SMRAM. As a result, this module type is only available for IA-32 and x64 CPUs. These modules only execute in physical mode, and are never destroyed. This means the services that these modules produce are available after ExitBootServices().
APPLICATION .efi .APP This module type is used by UEFI Applications that are compliant with the EFI 1.10 Specification or the UEFI 2.0 Specification. UEFI Applications are always unloaded when they exit.
EFI USER INTERFACE .ui .ui
EFI VERSION .ver .ver
EFI DEPENDENCY .dpx .dpx

A.1.2 [sources] Section

The [sources] section is used to specify the files that make up the component. Directories names are required for files existing in subdirectories of the component. All directory names are relative to the location of the INF file. Macros are allowed in the source file path. For EDK builds, each file is added to the macro of $(INC_DEPS), which can be used in a makefile dependency expression.

This section will typically use one of the following section definitions:

[sources]
[sources.common]
[sources.IA32]
[sources.X64]
[sources.IPF]
[sources.EBC]

The following example demonstrates entries in this section.

[sources.common]
  DxeIpl.dxs
  DxeIpl.h
  DxeLoad.c

[sources.Ia32]
  Ia32/VirtualMemory.h
  Ia32/VirtualMemory.c
  Ia32/DxeLoadFunc.c
  Ia32/ImageRead.c

[sources.X64]
  X64/DxeLoadFunc.c

[sources.IPF]
  Ipf/DxeLoadFunc.c
  Ipf/ImageRead.c

Binary file types - EDK does not have the flexibility of EDK II, but does provide a method for specifying binary files in the [sources] section. The following lists the mapping of EDK specific binary file types to EFI sections.

SEC_GUID

The binary file is an EFI_SECTION_FREEFORM_SUBTYPE_GUID section.

SEC_PE32

This binary is an EFI_SECTION_PE32 section.

SEC_PIC

This binary is an EFI_SECTION_PIC section.

SEC_PEI_DEPEX

This binary is an EFI_SECTION_PEI_DEPEX section.

SEC_DXE_DEPEX

This binary is an EFI_SECTION_DXE_DEPEX section.

SEC_TE

This binary is an EFI_SECTION_TE section.

SEC_VER

This binary is an EFI_SECTION_VERSION section.

SEC_UI

This binary is an EFI_SECTION_USER_INTERFACE section.

SEC_BIN

The binary is an EFI_SECTION_RAW section.

SEC_COMPAT16

This binary is an EFI_SECTION_COMPATIBILTY16 section.

A.1.3 [libraries] Section

The [libraries] section of the EDK INF is used to list the names of the libraries that will be linked into the EDK component. The library names do not include the directory locations or the extension name of the file. For each library, {LibName}, found, the {LibName} is added to the LIBS definition in the output makefile:

LIBS = $(LIBS) $(LIB_DIR)\{LibName}

This section will typically use one of the following section definitions:

[libraries.common]
[libraries.IA32]
[libraries.X64]
[libraries.IPF]
[libraries.EBC]

The formats for entries in this section is:

LibraryName

The following is an example of a libraries section.

[libraries.common]
  EfiProtocolLib
  EfiDriverLib

A.1.4 [includes] Section

The [includes] section of the EDK INF file is a list of directories to be included on the compile command line. These are included in a section of the Makefile generated by the parsing utilities. For each include path specified, the following line is written to the component's makefile.

INC = $(INC) -I $(SOURCE_DIR)\{path}

The path must be absolute, however the use of the global variable, EDK_SOURCE is recommended to construct the path.

This section will typically use one of the following section definitions:

[includes.common]
[includes.IA32]
[includes.X64]
[includes.IPF]
[includes.Nt32]
[include.common]
[include.IA32]
[include.X64]
[include.IPF]

The formats for entries in this section is:

$(EDK_SOURCE)/path/to/header/files

The following is an example of the [includes] section.

[includes.common]
  $(EDK_SOURCE)FoundationEfi
  $(EDK_SOURCE)Foundation
  $(EDK_SOURCE)FoundationFramework
  .
  $(EDK_SOURCE)FoundationInclude
  $(EDK_SOURCE)FoundationEfiInclude
  $(EDK_SOURCE)FoundationFrameworkInclude
  $(EDK_SOURCE)FoundationIncludeIndustryStandard
  $(EDK_SOURCE)FoundationCoreDxe
  $(EDK_SOURCE)FoundationLibraryDxeInclude

A.1.5 [nmake] Section

The optional EDK [nmake] section may also include a ".ProcessorName" to restrict processing based on the processor name. The section data is simply copied directly to the component makefile, before the build commands are emitted.

This section will typically use one of the following section definitions:

[nmake]
[nmake.common]
[nmake.IA32]
[nmake.X64]
[nmake.IPF]
[nmake.EBC]

The format for entries in this section is any valid Makefile syntax. Refer to make command reference for your tool chains.

The following is an example of the EDK [nmake] section.

[nmake.common]
  IMAGE_ENTRY_POINT = DiskIoDriverEntryPoint