Home

(INF) File Specification

1. LibraryClasses IPF Cannot use PERF or MDEMEM Can use MDE from the common section PalLib S MDE UefiPalLib UefiPalLib inf TimerLib MDE BaseTimerLibNullTemplate BaseTimerLibNullTemplate inf In the previous example the directory and filename for a library instance is the recommended instance and may not be the actual library linked to the module as the platform integrator may choose a different library instance to satisfy a library class dependency 2 2 7 Conditional Directive Statements lif Conditional statements are NOT permitted in the EDK II INF files Version 1 24B March 2015 14 INF Overview EDK II INF File Specification 2 2 8 Expressions Expressions are supported in specific statements within the EDK II INF files The expression syntax is defined in the EDK II Expression Syntax Specification 2 3 EDK II INF Format The remainder of this chapter describes the EDK II INF file format Note EDK Il accommodates distribution of binary modules so in addition to handling standard module builds the INF can also specify information about a binary module EDK II INF files may be created by package installation tools using the UEFI Distribution Package description files that accompany a distribution package All content except section tag names within the EDK II INF file is case sensitive All newly created EDK II INF files must be written to be case sensitive
2. This information can be derived from an XML Distribution Package file or is created by a module developer creating a new module information INF file This is an optional section 49 March 2015 Version 1 24B EDK II INF File Specification Prototype lt Header gt lt SourceHeader gt lt Abstract gt lt Description gt lt Copyright gt lt CopyName gt lt Date gt lt Year gt lt DateList gt lt DateRange gt lt CompInfo gt lt License gt lt BinaryHeader gt lt Filename gt Version 1 24B EDK II INF File Format lt SourceHeader gt lt BinaryHeader gt lt Comment gt lt Space gt lt Space gt file lt TS gt lt Filename gt lt EOL gt lt Abstract gt lt Description gt lt Copyright gt n lt EOL gt lt License gt HH lt EOL gt lt MTS gt lt AsciiString gt lt EOL gt lt EOL gt lt MTS gt lt AsciiString gt lt EOL gt W D lt EOL gt lt MTS gt lt CopyName gt lt Date gt lt CompInfo gt Portions lt MTS gt Copyright c lt MTS gt lt Year gt lt TS gt lt DateList gt lt DateRange gt 2 0 9 0 9 0 9 lt CommaSpace gt lt Year gt lt CommaSpace gt lt Year gt lt TS gt lt Year gt 0x20 0x7e lt MTS gt All rights reserved lt TS gt lt BR gt lt EOL gt lt MTS gt lt AsciiString gt lt EOL gt Ww lt EOL g
3. INF Overview EDK II INF File Specification Pcd common gEfiGenericPlatformTokenSpaceGuid PcdFlashNvStorageVariableSize gEfiGenericPlatformTokenSpaceGuid PcdFlashNvStorageVariableBase 2 14 5 DYNAMIC_EX The content for the PCD entry is the PCD s Name PCD s Token Space Guid C name followed by a period and the PCD s C name and an optional Default value These entries are separated by the pipe character This section may be present in I NF files that describe a binary only module This type of PCD is one of the recommended formats for modules that will be distributed in binary format This section uses one of the following section definitions PcdEx PcdEx common PcdEx IA32 PcdEx X64 PcdEx IPF PcdEx EBC The following is an example of the PCD DYNAMIC_EX type PcdEx common gEfiGenericPlatformTokenSpaceGuid PcdFlashNvStorageFtwWorkingSize gEfiGenericPlatformTokenSpaceGuid PcdFlashNvStorageFtwWorkingBase gEfiGenericPlatformTokenSpaceGuid PcdFlashNvStorageFtwSpareSize gEfiGenericPlatformTokenSpaceGuid PcdFlashNvStorageFtwSpareBase Note For binary Let modules only PATCHABLE_IN_MODULE or DYNAMIC_EX PCDS may be specified FixedPcd DYNAMIC and FeaturePcd sections are not permitted for binary distribution of modules 2 15 Depex Section 33 The EDK II Depex section is a replacement for the DPX_SOURCE file using in EDK the file is specified in the nmake section of an EDK INF file This section is us
4. U U U U EDK II INF File Specification include s lt Attrs gt lt EOL gt lt PATH gt lt Attributes gt include s lt Attrs gt lt Archs gt lt VarName gt lt Platform gt vn lt arch gt IA32 X64 IPF EBC common lt OA gt PROCESSOR lt Word gt Platform nt32 PLATFORM lt MACRO gt lt RelDir gt lt MacroName gt lt Word gt EDK_SOURCE EFI_SOURCE BUILD_DIR SOURCE_DIR Ir Alt lt Word gt RCE Foundation Efi RCE Foundation RCE Foundation Framework RCE Foundation Include URCE Foundation Efi Include RCE Foundation Framework Include Foundation Include IndustryStandard RC RCI RCI E D F D j Foundation Core Dxe Foundation Library Dxe Include A 2 4 libraries Section 108 Summary Defines the optional libraries section tag for EDK INF files The libraries section is used to define a LIBS macro in the EDK component s makefile All libraries listed in the libraries common libraries PROCESSOR and libraries PROCESSOR PLATFORM sections are added to the LIBS definition as either LIB_DIR LibName or PROCESSOR LibName The libraries are specified without path information The standard Macro Definitions are not permitted in
5. lt TailCmt gt lt FS gt lt Value gt lt FFE gt if pcddatumtype BOOLEAN lt Boolean gt elif pcddatumtype lt NumValUint8 gt elif pcddatumtype lt NumValUint16 gt elif pcddatumtype lt NumValUint32 gt elif pcddatumtype lt NumValUint 64 gt else lt StringVal gt UINTS8 UINT16 UINT32 UINT64 lt StringType gt lt CArray gt lt UnicodeString gt lt CString gt lt FS gt lt FeatureFlagExpress gt lt CommentBlock gt lt CommentBlock gt lt Boolean gt lt TS gt lt TS gt lt Usage gt lt TS gt lt CmtOrEol gt lt Comment gt lt EOL gt CONSUMES SOMETIMES CONSUMES PRODUCES SOMETIMES PRODUCES UNDEFINED The feature flag expression determines whether the entry line is valid If the expression evaluates to FALSE then the entry line is ignored by the EDK II build system 71 March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format 1UsageBlock and NUsageBlock The 1UsageBlock location after the entry is preferred if there is only one Usage for the PCD entry this may also be referred to as a tail comment If a PCD has multiple usages then all CommentBlock statements must precede the entry Values If a value is specified in an element and no value is set in the platform file the platform will use the value specified here rather than the default value specified in the DEC fil
6. 2 4 Defines Section This is a required section The Defines section of EDK II INF files is used to define variable assignments that can be used in later build steps The parsing utilities process any local symbol assignments defined in this section The EDK II parsing utilities will use some of this section s information for generating AutoGen c and AutoGen h files Note that the sections are processed in the order listed in the INF file and later assignments of these local symbols override previous assignments Defines The format for entries in this section is Name Value The following is an example of a driver s Defines section Defines INF_VERSION 0x00010018 BASE_NAME DxeIpl FILE_GUID 86D70125 BAA3 4296 A62F 602BEBBB9081 VERSION_STRING 1 0 MODULE_ TYPE PEIM ENTRY_POINT PeimInitializeDxeIpl MODULE_UNI_FILE DxeIpl uni The following is an example of a library s Defines section Defines INF_VERSION 0x00010018 BASE_NAME BaseMemoryLib FILE_GUID fd44e603 002a 4b29 9f5f 529e815b6165 MODULE_TYPE BASE VERSION_STRING 1 0 LIBRARY_CLASS BaseMemoryLib Drivers may expose library functionality such as a DXE_CORE module that may implement functions that satisfy the BaseMemoryAllocation library class In this instance the driver module would also specify the LIBRARY_CLASS in the Defines March 2015 Version 1 24B EDK II INF File Specification INF Overview section Other DXE drivers that
7. ENTRY IMAGE_ENTRY_POINT SAFESEH NO BASE 0 DRIVER PDB PDBSTRIPPED OUTPUT_PATH MSFT DEBUG_VS2008x86_IA32_ASLPP_FLAGS MSFT DEBUG_VS2008x86_IA32_OBJCOPY_FLAGS MSFT DEBUG_VS2008x86_IA32_MAK MSFT DEBUG_VS2008x86_IA32_ASMLINK_F DEBUG_VS2008x86_IA32_VFRPP_FLAGS DVFRCOMPILE FIS MODULE_NAME StrDefs h MSFT DEBUG_VS2008x86_IA32_ASLCC_FLAGS TC Dmain ReferenceAcpiTable DEBUG_VS2008x86_IA32_APP_FLAGS DEBUG_VS2008x86_IA32_DLINK_FLAGS nologo E ZIC nologo c FIAutoGen h nologo E TC NOLOGO NODEFAULTLIB ICF 10 MAP ALIGN 32 pdata D MACHINE X86 LTCG DLL SUBSYSTEM EFI_BOOT_SERVICE_DRIVER DEBUG OUTPUT_PATH BASE_NAME pdb BASE_NAME _Stripped pdb nologo E C FIAutoGen h objcopy not needed for E FLAGS nologo AGS nologo tiny March 2015 Version 1 24B EDK II INF File Specification Sample Binary INF Files Note In the above example the backslash character is used to show a line continuation for readability Use of a backslash character in the actual INF file is not permitted Version 1 24B March 2015 137 Sample Binary INF Files EDK II INF File Specification 138 March 2015 Version 1 24B EDK II INF File Specification Appendix G Module Types Table 9 EDK II Module Types FILE TYPE MODULE_ TYPE EDKII Desc
8. SOMETIMES CONSUMES Event gEfiEventReadyToBootGuid SOMETIMES CONSUMES Event gEf JU Event LegacyBootGuid Version 1 24B March 2015 135 Sample Binary INF Files 136 SHE SHE H AsBuilt Se Sk GE ee H H H tt SOMETIMES CONSUMES EfiGlobalVariableGuid g VALID_ARCHITECTUR Variab PcdEx IA32 El n EDK II INF File Specification le The following information is for reference only and not required by the build tools IA32 X64 IPF EBC MSFT DEB Symbol MSFT DEB UG_VS2008x86_IA32_SYMRENAME_FLAGS renaming not needed for UG_VS2008x86_IA32_ASLDLINK_FLAGS ReferenceAcpiTable SUBSYSTEM CONSOLE NODEFAULTLIB BUG_VS2008x86_IA32_VFR_FLAGS BUG_VS2008x86_IA32_PP_FLAGS f nologo E TC FIAutoGen h EBUG_VS2008x86_IA32_OPTROM_FLAGS EBUG_VS2008x86_IA32_SLINK_FLAGS e NOLOGO LTCG MSFT zd Zi MSFT Gs32768 D D MSFT DEBUG_VS2008x86_IA32_GENFW_FLAGS D D DI EBUG_VS2008x86_IA32_ASM_FLAGS nol go Ze WX W3 Cx coft DEBUG_VS2008x86_IA32 ASL FLAGS MSFT DEBUG_VS2008x86_IA32_CC_FLAGS D UNICODE olib2 G nologo c WX GS W4 FIAutoGen h EHs c GR GF Gy Zi Gm MSFT MSFT MSFT IGNORE 4001 OPT REF OPT SECTION xdata D SECTION
9. These include e Creating anew component INF file that specifies BUILD_TYPE xxx and then creating a build PROCESSOR xxx section in the platform DSC file e Creating a new component INF file and a makefile for the component and specifying BUILD_TYPE MAKEFILE in the INF file Then add a build PROCESSOR makefile section to the DSC file that describes how to build the component using the makefile Typically this will be commands to copy the file to the DEST_DIR and then invoking nmake e Trivial customizations can be accomplished by adding or modifying the nmake sections in the component INF file This may require defining PLATFORM in the EDK DSC file and then adding a new nmake PROCESSOR PLATFORM section in the component INF file e Another option is to define a variable in the component INF file passing it to the component makefile via the DSC makefile common section and then using IFDEF statements in the build PROCESSOR COMPONENT _TYPE section to perform custom steps B 2 Changing Files in an EDK Library Library INF files are shared among different platforms However not all platforms require all the same source files To customize the library INF files for different platforms simply define PLATFORM either on the command line or in the DSC file and then make customizations in the sources PROCESSOR PLATFORM section of the library I NF file An alternative t
10. lt DblQuote gt lt WS gt lt AsciiString gt lt EOL gt March 2015 Version 1 24B EDK II INF File Specification lt Comment gt lt UnicodeString gt lt HexDigit gt lt HexByte gt lt HexNumber gt lt HexVersion gt lt Major gt lt Minor gt lt DecimalVersion gt lt VersionVal gt lt GUID gt lt RegistryFormatGUID gt lt RHex4 gt lt RHex8 gt lt RHex12 gt lt RawH2 gt lt RawH4 gt lt OptRawH4 gt lt Hex2 gt lt Hex4 gt lt Hex8 gt lt Hex12 gt lt Hex16 gt Version 1 24B EDK II INF File Format lt AsciiString gt lt EOL gt L lt QuotedString gt a fA FO 9 Ox 0X lt HexDigit gt lt HexDigit gt Ox 0X lt HexDigit gt Ox lt Major gt lt Minor gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt 0 0 9 0 9 0 9 4 lt HexVersion gt 0 9 0 9 lt RegistryFormatGUID gt lt CFormatGUID gt lt RHex8 gt lt RHex4 gt lt RHex4 gt lt RHex4 gt lt RHex12 gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt RHex4 gt lt RHex4 gt lt RHex4 gt lt RHex4 gt lt RHex4 gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt Ox
11. Module Type to Component Type Mapping EDK II Module Type EDK Component Type BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER UEFI_ DRIVER UEFI_APPLICATION LIBRARY BASE LIBRARY SECURITY_CORE PEI_CORE COMBINED_PEIM_DRIVER PIC_PEIM RELOCATABLE_PEIM BS_DRIVER RT_DRIVER SAL_RT_DRIVER APPLICATION SEC SECURITY_CORE PEI_CORE PEI_CORE PEIM COMBINED_PEIM_DRIVER See NOTE below PEIM PIC_PEIM PEIM RELOCATABLE_PEIM DXE_CORE BS_DRIVER DXE_DRIVER BS_DRIVER with a Dependency Section DXE_RUNTIME_DRIVER RT_DRIVER DXE_SAL_DRIVER SAL_RT_DRIVER DXE_SMM_DRIVER BS_DRIVER UEFI_ DRIVER UEFI_APPLICATION BS DRIVER without a Dependency Section APPLICATION Note The EDK II build system does not support creation of COMBINED_PEIM_DRIVER EFI leaf sections 142 March 2015 Version 1 24B
12. OX lt RawH2 gt Ox 0X lt RawH4 gt Ox 0X lt OptRawH4 gt lt RawH4 gt 0x 0X lt OptRawH4 gt lt OptRawH4 gt lt RawH4 gt Ox 0X lt OptRawH4 gt lt OptRawH4 gt lt OptRawH4 gt lt RawH4 gt March 2015 40 EDK II INF File Format 41 lt CFormatGUID gt lt CArray gt lt NList gt lt RawData gt lt Integer gt lt Number gt lt HexNz gt lt NumNz gt lt GZ gt lt TRUE gt lt FALSE gt lt BoolType gt lt MACRO gt lt MACROVAL gt lt PcdName gt lt PcdCName gt lt TokenSpaceGuidCName gt lt UINT8 gt lt UINT16 gt lt UINT32 gt lt UINT64 gt lt UINT8z gt EDK II INF File Specification lt Hex8 gt lt CommaSpace gt lt Hex4 gt lt CommaSpace gt lt Hex4 gt lt CommaSpace gt lt Hex2 gt lt CommaSpace gt lt Hex2 gt lt CommaSpace gt lt Hex2 gt lt CommaSpace gt lt Hex2 gt lt CommaSpace gt lt Hex2 gt lt CommaSpace gt lt Hex2 gt lt CommaSpace gt lt Hex2 gt lt CommaSpace gt lt Hex2 gt lt Nlist gt lt CArray gt lt HexByte gt lt CommaSpace gt lt HexByte gt lt TS gt lt Number gt lt Cs gt lt Number gt lt EOL gt lt TS gt 0 9 1 9 0 9 lt Integer gt lt HexNumber gt x1 xFFFFFFFFFFFFFFFF 1 18446744073709551615 lt NumNz gt lt HexNz gt TRUE true True 0x1 0x01 1 lt GZ gt FALSE
13. Refer to the EDK II Build Specification section 8 4 1 for PCD processing rules 67 March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format Summary Defines the PcdType section content for EDK II module I NF files If a default value is specified on the entry line it must match the datum type specified in the DEC file that declares this PCD The Datum Type values are defined in the PI Specification PCD expressions are single lines with two or three fields fields are separated using the pipe 1 character Empty Fields are permitted The EDK II Build system will generate an As Built INF file that can be delivered with a binary distribution Only PatchPcd and PcdEx section types are valid for in As Built INF file Tools that create As Built information must expand any macro values used by the tools during the module build The format of the lt commentBlock gt is the recommended format that will guarantee that the information is correctly inserted into UEFI Distribution Package description files by the Intel UEFI Packaging Tool included in the EDK II base tools project Each PCD name must only be listed once in a section PCD names listed in architectural sections must not be listed in the common architectural section PCDs should be either architectural in nature or common to all architectures The module developer should note that all recommended values may be overridden by values specified by a plat
14. Sources PeiServicesTablePointer c Packages MdePkg MdePkg dec LibraryClasses March 2015 Version 1 24B EDK II INF File Specification Sample Library INF Files DebugLib E 2 DxeCoreMemoryAllocationLib inf Memory Allocation Library instance dedicated to DXE Core The implementation borrows the DxeCore Memory Allocation services as the primitive for memory allocation instead of using UEFI boot services in an indirect way It is assumed that this library instance must be linked with DxeCore in this package Copyright c 2008 2010 Intel Corporation All rights reserved lt BR gt 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 This program and the accompanying materials are licensed and made IMPLIED Defines INF_VERSION 0x00010018 BASE_NAME DxeCoreMemoryAllocationLib FILE GUID 632F3FAC 1CA4 4725 BAA2 BDECCF9A111C MODULE_TYPE DXE_CORE VERSION_STRING 1 0 LIBRARY_CLASS MemoryAllocationLib DXE_CORE The following information is for refe
15. The module will use the named GUID For GUID type of e Event CONSUMES means that the module has an event waiting to be signaled i e the module registers a notification function and calls the function when it is signaled e System Table this means that the module will use a GUI Ded entry in the system table e Variable this means that the module may use the variable entry e HII the formset may be registered into HII by this module e TokenSpaceGuid this means that an Token Space GUID will be required for PCD entries used in this module e Hob this means that a HOB may need to be present in the system e File FV this means that a file must be present in an FV such as a module that loads a processor microcode patch file e GUID this means that a module may use this GUID that does not fit into the defined GUID types PRODUCES PRODUCES means that a module will produce a GUID that does not fit into the defined PROTOCOL or PPI types This module always produces a named GUID For GUID type of e Event this means that module will signal all events in an event group e System Table this means that the module will produce a GUIDed entry in the system table e Variable this means that the module will write the variable e HII PRODUCES is not valid for this GUID type e TokenSpaceGuid PRODUCES is not valid for this GUID type e Hob this means that the HOB will be produced by the module e File FV this
16. The standard Macro Definitions are not permitted in this section Version 1 24B March 2015 109 EDK INF File Specification 110 Prototype lt Nmake gt lt attrs gt lt Archs gt lt plat gt lt arch gt lt expression gt lt IEP gt lt DS gt lt CSI gt lt CPF gt lt APF gt lt LSF gt lt EBC gt lt DEF gt lt STATEMENTS gt Parameters CFlags EDK II INF File Specification nmake lt attrs gt lt EOL gt lt expression gt lt Archs gt lt plat gt nmake lt attrs gt D lt arch gt lt Word gt IA32 X64 IPF EBC common lt IEP gt lt DS gt lt CSI gt lt CPF gt lt APF gt lt LSF gt lt EBC gt lt DEF gt IMAGE ENTRY_POINT lt CName gt lt EOL gt DPX SOURCE lt Filename gt lt EOL gt C_STD_INCLUDE lt CFlags gt lt EOL gt C_PROJ_FLAGS lt CFlags gt lt EOL gt ASM_PROJ_FLAGS lt AFlags gt lt EOL gt LIB_STD_FLAGS lt LFlags gt lt EOL gt EBC_C_STD_FLAGS lt String gt lt EOL gt EBC_LIB_STD_FLAGS lt String gt lt EOL gt lt Word gt lt Word gt lt String gt lt EOL gt Valid NMAKE Makefile syntax This content must be valid compiler flags for the Microsoft C compiler cl exe AFlags This content must be valid flags for the Microsoft Assembler ml exe LFlags This content must be valid flags for the M
17. in BuildOptions sections that are encapsulated by quotation marks are not expanded by tools and do not need to be local to the I NF file The expectation is that macros in the quoted values will be expanded by external build scripting tools such as nmake or gmake they will not be expanded by the build tools The macro statements are positional in that only statements following a macro definition are permitted to use the macro a macro cannot be used before it has been defined Macros defined in common sections may be used in the architecturally modified sections of the same section type Macros defined in architectural sections cannot be used in other architectural sections nor can they be used in the common section Section modifiers in addition to the architectural modifier follow the same rules as architectural modifiers Within the EDK II INF File macros are expanded except within quotes not evaluated during the parsing of the file Example LibraryClasses common DEFINE MDE MdePkg Library BaseLib MDE BaseLib inf m LibraryClasses X64 LibraryClasses IA32 Can use MDE cannot use MDEMEM DEFINE PERF PerformancePkg Library TimerLib PERF DxeTscTimerLib DxeTscTimerLib inf LibraryClasses X64 PEIM Can use MDE and PERF DEFINE MDEMEM MDE PeiMemoryAllocationLib MemoryAllocationLib MDEMEM PeiMemoryAllocationLib inf
18. source type file such as local module header files Vfr files etc Each source file must be listed only once per section Files listed in architectural sections are not permitted to be listed in the common architectural section This section is not valid for a generated As Built binary INF file March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format Prototype lt Sources gt Sources lt com_attribs gt lt EOL gt lt TS gt TABLE_NAME lt Eq gt lt SimpleWord gt lt EOL gt lt SourceFileStmts gt lt com_attribs gt common lt attribs gt lt attribs gt lt attrs gt lt TS gt Sources lt attrs gt lt attrs gt Ll lt arch gt lt SourceFileStmts gt lt MacroDefinition gt lt SourceFileEntry gt lt SourceFileEntry gt lt TS gt lt Filename gt lt Options gt lt EOL gt lt Options gt lt FS gt lt Family gt lt opt1 gt lt opt1 gt lt FS gt lt TagName gt lt opt2 gt lt opt2 gt lt FS gt lt ToolCode gt lt opt3 gt lt opt3 gt lt FS gt lt FeatureFlagExpress gt lt Family gt MSFT GCC INTEL lt Wildcard gt lt TagName gt lt ToolWord gt lt ToolCode gt CommandCode lt FeatureFlagExpress gt lt Boolean gt Parameters Filename Paths listed in the filename elements ofthe Sources section must be relative to the directory the INF file resides in
19. 1 24B March 2015 111 EDK INF File Specification 112 Prototype lt sources gt a lt attrs gt H lt Archs gt lt archs gt HE lt EdkArch gt CrS lt plat gt i lt DefineStatement gt i lt EdkExpression gt HE lt Family gt L lt Filename gt lt Path gt A Examples sources common BsDataHubStatusCode c BsDataHubStatusCode h EDK II INF File Specification source s lt attrs gt lt EOL gt lt MacroDefinition gt lt EdkExpression gt lt Archs gt sources lt attrs gt if COMPONENT_TYPE defined in defines lt archs gt lt plat gt else D H lt archs gt if COMPONENT_TYPE defined in defines lt EdkArch gt lt EdkArch gt else lt arch gt lt arch gt IA32 x64 IPF Common gt PLATFORM PROCESSOR lt Word gt DEFINE lt Word gt lt PATH gt lt EOL gt TABLE_NAME lt Word gt lt EOL gt lt Filename gt lt Family gt lt EOL gt MSFT Ecc m INTEL Woe lt Path gt lt Word gt lt Extension gt lt Macro gt lt Word gt SW March 2015 Version 1 24B EDK II INF File Specification Appendix B Build Changes and Customizations B 1 Customizing EDK Compilation for a Component There are several mechanisms for customizing the build for a firmware component
20. 2 12 LibraryClasses Section The EDK II INF LibraryClasses section is used to list the names of the library classes that are required or optionally required by a component A library class instance as specified in the DSC file will be linked into the component The Library Class Recommended Instance path must be absolute using the global variable WORKSPACE to construct the path Library classes listed in architectural sections must not be listed in common LibraryClasses sections The architectural section modifier is used as a restriction to mask items from architectures that are not applicable This section uses one of the following section definitions LibraryClasses LibraryClasses common LibraryClasses IA32 LibraryClasses X64 LibraryClasses IPF LibraryClasses ERC The format for entries in this section is LibraryClassNamel LibraryClassName2 LibraryClassName3 WORKSPACE Path To RecommendedLibInstanceName inf The comment using the double hash marks specifies the module developer s recommended library instance This is information that the platform integrator can use to help select a library instance for a given library class during a build The package Version 1 24B March 2015 28 INF Overview EDK II INF File Specification developer may also provide a recommended library instance The defined library instance defined in a DSC file that satisfies a Library Class will be added to the LIBS definition
21. FALSE gEfiMdePkgTokenSpaceGuid PcdDriverDiagnosticsDisable Pcd IA32 gEfiNt32PkgTokenSpaceGuid PcdWinNtMemorySizeForSecMain PatchPcd IA32 AsBuilt gEfiMdePkgTokenSpaceGuid PcdDebugPrintErrorLevel 0x80000040 0x00004118 3 9 Sources Sections 73 These sections are optional Summary Defines the Sources section content All file names specified in this section must be in the directory containing the INF file or in sub directories of the directory containing the INF file The common architecture modifier in a section tag must not be combined with other architecture type doing so will result in a build break All paths are relative to the directory containing the INF file If the filename is listed as myfile c the file must be located in the same directory as the INF file Absolute paths in the filename are prohibited There can be multiple sources sections depending on the target processor Example sources sections are listed below The parsing utility creates a directory path for each file DEST_DIR MyFile c and looks up the makefile template for the COMPONENT_TYPE EDK or MODULE_TYPE EDK II to emit It is not permissible to mix EDK and EDK II style files within a module The macro TABLE_NAME may be used in existing EDK I NF files that point to ACPI tables this value will be ignored by EDK II build tools All HII Unicode format files must be listed in this section as well as any other
22. Includes section for pure EDK II Modules or library instances All include paths are generated by tools by parsing the package files specified in the Packages section This section is not required for binary module INFs 2 9 Protocols Section The Protocols section of the EDK II INF file is a list of the global Protocol C Names that are used by the module developer These C names are used by the parsing utility to lookup the actual GUID value of the PROTOCOL that is located in the EDK II package DEC files and then emit a data structure to the module s AutoGen c file Protocols listed in architectural sections must not be listed in common Protocols sections The architectural section modifier is used as a restriction to mask items from architectures that are not applicable This section uses one of the following section definitions Protocols Protocols common Protocols IA32 Protocols x64 Protocols IPF Protocols EBC The formats for entries in this section is gEfiProtocolCName The following is an example of the Protocols section Protocols gEfiDecompressProtocolGuid gEfiLoadFileProtocolGuid 2 10 Ppis Section 27 The Ppis section of the EDK II INF file is a list of the global PPI C Names that are used by the module developer These C names are used by the parsing utility to lookup the actual GUID value of the PPI that is located in the EDK II package DEC files and then emit a data structure to the module s Aut
23. MODULE_TYPE UEFI_DRIVER VERSION_STRING 1 0 ENTRY_POINT AbcDriverEntryPoint UNLOAD_IMAGE AbcUnload Example EDK Il Library Defines INF_VERSION 0x00010018 BASE_NAME LzmaCustomDecompressLib FILE_GUID 22f8406f 43 492f 82f5 4e8ala58e6d2 MODULE_TYPE BASE VERSION_STRING 1 0 LIBRARY_CLASS CustomDecompressLib 3 5 BuildOptions Sections These sections are optional for EDK II INF files Summary Defines the BuildOptions section content These sections are used to define the custom definitions for individual tools There are two styles for options a replacement of any previous definition for this module only of the flags or commands used specified by the double equal sign to process the module code or an append option specified by the single equal sign which will be appended to the previous definition When the single equal sign is used the string to the left is appended typically used to override a single flag When the double sign is used then any previous definition reference build requires that it must be defined tools det Get file will be cleared and the left value replaces the entire previous definition The double equal sign must be used to replace a command specified by the PATH attribute appending is not an option For the DPATH attribute can use either the replace or append and is used to expand Version 1 2
24. RecommendedInstance MDE BaseLib BaseLib inf BaseLib 3 7 Packages Sections These are optional sections If there are files listed under a Sources section then the INF file is required to list the MdePkg MdePkg dec file as the first file in a Packages section This section is also required if the module uses PCDs for both source and the binary As Built INF modules Summary Defines the Packages section tag that is used in EDK II module INF files Note that the path may include a reference to environment variable WORKSPACE If the directory path starts with a word rather than a MACRO or WORKSPACE the path is relative to the WORKSPACE environment variable Packages must be listed in the order that may be required for specifying include path statements for a compiler For example the MdePkg MdePkg dec file must be listed before the MdeModulePkg MdeModulePkg dec file If there are PCDs listed in the generated As Built INF the packages that declare any PCDs must be listed in this section Each package filename must be listed only once per section Package filenames listed in architectural sections are not permitted to be listed in the common architectural section Version 1 24B March 2015 66 EDK II INF File Format EDK II INF File Specification The common architecture modifier in a section tag must not be combined with other architecture type doing so will result in a build break Packages listed under th
25. This value is used to call the specified function before calling into the library itself This only applies to components that are libraries This value is used to call the specified function before calling into the library itself This boolean operator is used by SEC PEI_CORE and PEIM modules to indicate if the module was coded to use REGISTER _FOR_SHADOW If the value is TRUE the reloc section of the PE32 image is not removed otherwise the reloc section is stripped to conserve space in the final binary images The default value is FALSE 19 March 2015 Version 1 24B EDK II INF File Specification Tag PCI_DEVICE_ID PCI_VENDOR_ID PCI_CLASS_CODE PCI_COMPRESS UEFI_HII_RESOURCE_SECTI ON DEFINE SPEC CUSTOM_MAKEFILE DPX_SOURCE Version 1 24B Required Not required Required for UEFI PCI Option ROMs Not required Required for UEFI PCI Option ROMs Not required Required for UEFI PCI Option ROMs Not required UEFI PCI Option ROMs Not required Driver Only Not required Not required Not required Not Required Driver Only Value Hex Number Hex Number Hex Number TRUE FALSE TRUE FALSE Name Value CName Value Family File Filename March 2015 INF Overview Notes The PCI Device Id for this device The PCI Vendor Id for this device The PCI Class Code for this device This flag is used by tools to com
26. UserExtensions Sections These are optional sections Summary Defines the optional EDK II INF file UserExtensions section tag The build tools must have an a priori knowledge of how to process any items in this section Each UserExtensions section must have a unique set of UserId IdString and Arch values The common architecture modifier in a section tag must not be combined with other architecture type doing so will result in a build break This means that the same UserId can be used in more than one section provided the IdString or Arch values are different The same IdString values can be used ifthe UserId or Arch values are different The same UserId and the same IdString can be used if the Arch values are different Any UserExtensions Sections that are present in the source INF with a Userld of TianoCore will be copied into the As Built INF file UserExtensions sections with other Userld values will not be copied to the As Built INF file Files listed in a UserExtensions TianoCore ExtraFiles section must be included in a UEFI Distribution Package 75 March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format Prototype lt UserExtensions gt UserExtensions lt com_attribs gt lt EOL gt lt statements gt lt com_attribs gt lt com_arch gt lt attribs gt lt com_arch gt lt IdContent gt common lt attribs gt lt IdContent gt lt TS gt
27. a C flag macro can be specified without a value require the in a macro DEFINE statement Removed references to system environment variables in the Macros section and removed table Revised EBNF for PCD sections to allow more precise definitions Specify how PCD values are obtained Changed definition of a C Array to ensure that an empty array is not specified Allow any non zero value to be TRUE Use separate EBNF for each PCD datum type also explain the PCD usages describe in section 2 what sections are valid for binary only modules and what sections are prohibited in binary only modules Clarify that C data arrays must be byte arrays for PCD value fields both C format and registry format GUID structures are not permitted in VOID PCD value fields March 2015 Version 1 24B EDK II INF File Specification 1 22 with Updates cont d December 2011 Errata A The character is optional for the header comment block Cont in EDK INF files Prohibit specifying something an a common section and in an architecturally specific section something that is architecture specific cannot be common to all architectures Removed FFE from entries as they have no meaning nothing changes build does not break if they are there 1 22 w Updates June 2012 Errata B Section 1 3 page 5 Updated specs definition to include released errata Section 3 8 page 67 Removed Value field for DynamicEx PCDs listed in a generated
28. and EDK II platforms EFI Generic term that refers to one of the versions of the EFI specification EFI 1 02 EFI 1 10 or any of the UEFI specifications FDF EDK II Flash definition file This file is used to define the content and binary image layouts for firmware images update capsules and PCI option ROMs FLASH This term is used throughout this document to describe one of the following e An image that is loaded into a hardware device on a platform traditional ROM image e An image that is loaded into an Option ROM device on an add in card e A bootable image that is installed on removable bootable media such as a Floppy CD ROM or USB storage device e An image that is contains update information that will be processed by OS Runtime services to interact with EFI Runtime services to update a traditional ROM image e A UEFI application that can be accessed during boot at an EFI Shell Prompt prior to hand off to the OS Loader Foundation The set of code and interfaces that holds 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 Th
29. be different from the licenses used for distributing the module with source code License content will not be localized e If this tag is present the tools will use this content when generating the binary As Built INF e Ifthe Doxygen tag is not present in the source INF the tools will use the License content from the Source I NF file when generating a binary As Built INF e Inthe binary As Built INF the Doxygen tag must not be present Example t file EFI Framework Base Memory Library Implementation of a base memory library that provides minimum functionality for accessing memory Copyright c 2006 2008 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 tt 3 4 Defines Section This is a required section Summary This describes the required Defines section used in EDK II INF files This file is created during installation of a UEFI distribution package or by the developer and is an input to the new build tool parsing
30. first then C D is processed and finally the two results are added A B C D Space and tab characters are permitted around field separators 2 2 4 Naming Conventions The EDK II build infrastructure is supported under Microsoft Windows Linux and MAC OS X operating systems All directory and file names must be treated as case sensitive because of multiple environment support e The use of special characters in directory names and file names is restricted to the dash underscore and period characters respectively _ and e Period characters must not be followed by another period character File and Directory names must not start with or a e Space characters must never be used in the directory path specified by the system environment variable WORKSPACE Directory names and file names within the WORKSPACE directory tree must not contain space characters e Directory Names must only contain alphanumeric dash underscore and period characters two sequential period characters are not permitted it is recommended that the name start with an alpha character e All files except those listed in the Packages sections must reside in the directory containing the INF file or in sub directories of the directory containing the INF file e Additionally all EDK II directories that are architecturally dependent must use a name with only the first character capitalized la32 Ipf X64 and Ebc are v
31. gt lt BoolAbStmt gt lt BoolAb gt lt GuidCName gt lt BoolAbExpress gt lt BoolAbExpressCont gt Example Depex EDK II INF File Format lt NTs gt lt Bool gt lt BoolExpressCont gt lt MTS gt AND OR lt MTS gt lt NTs gt lt Bool gt lt FullDxe gt lt FullPei gt lt FullSmm gt lt EOL gt lt DxeStatements gt lt TS gt END lt SorAbStmt gt lt GuidAbStmt gt lt BoolAbStmt gt lt PeiStatements gt lt TS gt END lt BoolAbStmt gt lt DepAbInstruct gt lt FullDxe gt BEFORE AFTER lt TS gt lt GuidCName gt lt TS gt PUSH lt TS gt lt CFormatGUID gt lt TS gt SOR lt TS gt lt BoolAbStmt gt lt TS gt lt BoolAb gt lt BoolAbExpress gt TRUE FALSE lt GuidCName gt lt TS gt lt CName gt A Guid C Name lt NTs gt lt Bool gt lt BoolAbExpressCont gt lt MTS gt AND OR lt MTS gt lt NTs gt lt Bool gt gEfiFirmwareVolumeBlockProtocolGuid AND gEfiAlternateFvBlockGuid AND gEfiFaultTolerantWriteLiteProtocolGuid Depex SOR gEfiProtocolIDependOnGuid Depex common SOR gEfiProtocolIDependOnGuid Depex IA32 DXE_SMM_DRIV Version 1 24B ER March 2015 88 EDK II INF File Format EDK II INF File Specification TRUE Depex IA32 DXE_DRIVER TRUE AND gEfiAlternateFvBlockGuid 3 15 Binaries Section 89 Summary Defines the
32. gt SHADOW lt Eq gt lt BoolType gt lt EOL gt lt OptionRomInfo gt lt TS gt CUSTOM_MAKEFILE lt Eq gt lt CustomMake gt lt EOL gt lt TS gt DPX_SOURCE lt Eq gt lt Filename gt lt EOL gt lt TS gt SPEC lt MTS gt lt Spec gt lt EOL gt lt TS gt lt UefiHiiResource gt lt EOL gt lt TS gt MODULE_UNI_FILE lt Eq gt lt Filename gt lt EOL gt lt MacroDefinition gt a zA Z0 9 a zA Z0 9 UEFI_HII_RESOURCE_SECTION lt Eq gt lt TrueFalse gt lt Family gt lt FS gt lt Filename gt PEI_ PCD DRIVER DXE_PCD_ DRIVER lt Identifier gt lt Eq gt lt DecimalVersion gt lt KeywordType gt NULL lt SimpleWord gt lt FS gt lt ModuleTypes gt March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format lt ModuleTypes gt lt ModuleType gt lt Space gt lt ModuleType gt lt FFE gt lt FS gt lt Expression gt lt SpecVersion gt lt HexVersion gt 0 9 0 9 lt OptionRomInfo gt lt TS gt PCI_VENDOR_ID lt Eq gt lt UINT16 gt lt EOL gt lt TruFal gt Parameters lt TS gt PCI_DEVICE_ID lt Eq gt lt UNIT16 gt lt EOL gt lt TS gt PCI_CLASS CODE lt Eq gt lt UINT8 gt lt EOL gt lt TS gt PCI_REVISION lt Eq gt lt UINT8 gt lt EOL gt lt TS gt PCI_COMPRESS lt Eq gt lt TruFal gt lt EOL gt TRUE FALSE Filename Filenames listed in the Defines
33. in the output makefile LIBS LIBS LIB_DIR LibInstanceName Note The above is not the name of the INF file but the name of the library file that was generated during the instance s compilation Refer to the EDK II DSC File Specification for rules to select library class instances Note For binary driver or application modules this is a list of the library instances in comments that were used to create the binary efi executable file The following is an example of the library class section LibraryClasses MemoryAllocationLib BaseMemoryLib PeiServicesTablePointerLib CustomDecompressLib TianoDecompressLib UefiDecompressLib EdkPeCoffLoaderLib CacheMaintenanceLib ReportStatusCodeLib PeiServicesLib PerformanceLib HobLib BaseLib PeimEntryPoint DebugLib 2 13 Packages Section 29 The Packages section lists all of the EDK II declaration files that are used by the component Data from the INF and the DEC files is used to generate content for the AutoGen c and AutoGen h files Packages listed in architectural sections must not be listed in common Packages sections The architectural section modifier is used as a restriction to mask items from architectures that are not applicable The locations of the packages listed in this section will be used in generating include path statements for compiler tool chains The packages must be listed in the order that resolves any include dependencies This section uses one
34. in the section modifier must be a member of the Module Types listed after the LIBRARY_CLASS keyword in the Defines section If no module types are listed after the LIBRARY_CLASS keyword in the Defines section then the library is compatible with all module types so all module types may be used as a section modifier The common architecture modifier in a section tag must not be combined with other architecture type doing so will result in a build break If the MODULE_TYPE iS UserDefined the build tools must exit gracefully and provide the user with an error message stating that the Depex section header does not provide enough information to determine the type of the Depex section If the module is not a library no LIBRARY_CLASS in the Defines section and the MODULE_TYPE iS SEC SMM_CORE DXE_CORE PEI_CORE UEFI_DRIVER or UEFI_APPLICATION a Depex section is not permitted If one is found the build tools must exit gracefully and provide the user with an error message stating the Depex section is not valid for the MODULE_TYPE If the module is a library with a LIBRARY_CLASS statement in the Defines section and there is no module type defined in Depex section s modifier and there is a MTL defined with a ModuleTypeList statement following by the LIBRARY_CLASS statement in the Defines section and each module type in MTL is PEIM DXE_DRIVER DXE_SAL_DRIVER DXE_RUNTIME_DRIVER DXE_SMM DRIVER Or UEFI_DRIVER the build tools must c
35. inheritance Not recommended but gives complete control to the driver writer Each Depex section tag listed in an INF file must be unique If there are multiple Depex sections that have the same section tag i e Depex 1A32 DXE_DRIVER and another Depex A32 DXE_DRIVER section in the same INF the build must break If a DPX_SOURCE is specified in the Defines section the Depex section is ignored and the file specified in the DPX_SOURCE is used instead When processing the file the INF file name specified in the lt Guidstmt gt and lt DepInstruct gt statement is replaced by the FILE_GUID value from the INF file translated to a POSIX C structure as shown below INTERFACENAME OFO5DE03 8A1B 408C 8F84 B547F593E463 Ox0FO5DE03 Ox8AlB 0x408C Ox8F 0x84 OxB5 0x47 OxF5 0x93 OxE4 0x63 The term SoR is ignored as part of the dependency processing The DXE driver is to remain on the Schedule on Request SOR queue until the DXE Service Schedule is Version 1 24B March 2015 84 EDK II INF File Format EDK II INF File Specification 85 called for this DXE The dependency expression evaluator treats this operation like a No Operation NOP There are three types of dependency sections PEI SMM and DXE permitted by specifications The SMM dependency section uses the same grammar as the DXE dependency section The optional tags identified as lt DepexType gt in the EBNF below must be used at th
36. lt CommentBlock gt lt Boolean gt lt TS gt lt UseOrFieldOpt gt lt CmtOrEol gt lt UsageField gt lt GuidTypeField gt lt TS gt lt Usage gt lt TS gt lt TS gt lt GuidType gt lt TS gt lt Comment gt lt EOL gt CONSUMES SOMETIMES CONSUMES PRODUCES SOMETIMES PRODUCES UNDEFINED Event File Fv GUID HII HOB SystemTable TokenSpaceGuid lt VariableType gt UNDEFINED Variable Variable lt TS gt lt VariableName gt lt UnicodeString gt The feature flag expression is currently ignored by the EDK II build system Version 1 24B March 2015 82 EDK II INF File Format EDK II INF File Specification 1UsageBlock and NUsageBlock The 1UsageBlock location after the entry is preferred if there is only one If a GUID has multiple usages then all CommentBlock statements must precede the entry Usage One or more Usage comment lines may be specified for a given GUID If more than one Usage then the comment section following the Usage must be provided explaining the different usages UNDEFINED Usage Typically this entry will be used when tools creating installing UEFI Distribution Packages encounter a missing or misspelled usage UNDEFINED may also be used for GUIDs that identify different types of information CONSUMES CONSUMES means that a module may use this GUID that does not fit into the defined PROTOCOL or PPI types
37. lt com_PEArchAttrs gt In lt EOL gt lt AbPcdEx gt common lt PEArchAttrs gt D lt arch gt lt attrs gt lt TS gt PcdEx lt attrs gt lt NUsageBlockAb gt lt TS gt lt PcdName gt lt TailCmt gt lt EOL gt lt HiiComment gt lt NUsageBlock gt lt TS gt lt Usage gt lt MTS gt lt HiiInfo gt lt TS gt lt CmtOrEol gt lt TS gt lt TS gt L lt QuotedString gt lt FS gt lt CName gt lt Offset gt lt TS gt lt PcdName gt lt FS gt lt ValUse gt lt AsBuiltValue gt lt TailCmt gt lt NUsageBlock gt lt TS gt lt PcdName gt lt FS gt lt ValOffUse gt lt AsBuiltValue gt lt Offset gt lt TailCmt gt lt FS gt lt NumValUint32 gt In lt NList gt if pcddatumtype BOOLEAN 0x00 0x01 elif pcddatumtype lt UINT8z gt elif pcddatumtype lt UINT16z gt elif pcddatumtype lt UINT32z gt UINT8 UINT16 UINT32 March 2015 70 EDK II INF File Format lt PcdEntries gt lt PFieldli gt lt Value gt lt StringVal gt lt StringType gt lt FFE gt lt 1UsageBlock gt lt NUsageBlock gt lt FeatureFlagExpress gt lt CommentBlock gt lt CmtOrEol gt lt Usage gt Parameters FeatureFlagExpress EDK II INF File Specification elif pcddatumtype UINT64 lt UINT64z gt else lt AsBuiltByteArray gt lt NUsageBlock gt lt TS gt lt PcdName gt lt PFieldi gt
38. means that a module creates a file that is present in an FV such as a file that contains a microcode patch e GUID this means that a module will produce a GUID that does not fit into the defined PROTOCOL PPI or GUID types 83 March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format Example Guids EfiDebugImageInfoTable gEfiHobMemoryAllocModuleGuid Q gEfiAbcVariableGuid PRODUCES Variable L XYZ Sets the variable Event registered to EFI_HII_SET_KEYBOARD_LAYOUT_EVENT_GUID group which will be triggered by EFI_HII_DATABASE_PROTOCOL SetKeyboardLayout SOMETIME CONSUMES Event gEfiHiiKeyBoardLayoutGuid 3 14 Depex Sections These are optional sections Summary Defines the optional EDK II INF file Depex section content The Depex section is a replacement for the dependency file specified by the driver writer The DPX_SOURCE in the Defines section an EDK INF file will over ride the dependency specified here This section can be used for inheritance from libraries by supporting logical AND ing of the different Depex expressions together The Rules would be as follows e EDKII INF Depex section and inheritance from libraries is supported via AND ing the different Depex expressions together EDK II INF The Defines section s keyword DPX_SOURCE would override Depex section and let module owner force a Depex independent of the Depex
39. must precede the entry UNDEFINED Typically this entry will be used when tools creating installing UEFI Distribution Packages encounter a missing or misspelled usage UNDEFINED is also valid when the Protocol is not used as a Protocol and the GUID value of the Protocol is used for something else CONSUMES This module does not install the protocol but needs to locate a protocol Not valid if the Notify attribute is true PRODUCES This module will install this protocol Not valid if the Notify attribute is true Version 1 24B March 2015 78 EDK II INF File Format EDK II INF File Specification SOMETIMES CONSUMES This module does not install the protocol but may need to locate a protocol under certain conditions such as if it is present If the Notify attribute is set then the module will use the protocol named by GUID via a registry protocol notify mechanism SOMETIMES_PRODUCES This module will install this protocol under certain conditions Not valid if the Notify attribute is true TO_START The protocol is consumed by a Driver Binding protocol Start function Thus the protocol is used as part of the UEFI driver model Not valid if the Notify attribute is true BY_START The protocol is produced by a Driver Binding protocol Start function Thus the protocol is used as part of the UEFI driver model Not valid if the Notify attribute is true NOTIFY This specifies whether this is a Protocol or ProtocolNotify If set th
40. not specified fora Driver REQUIRED fora Library Only Module Not required Driver Only Not required Driver Only Not required Driver Only Not required Library Only Not required Library Only Not required SEC PEIM and PEI_CORE Driver modules only Value Word List Word List PEI_PCD_DR IVER or DXE_PCD_D RIVER CName CName CName CName TRUE FALSE EDK II INF File Specification Notes One Library Class that is satisfied by this Library Instance one or more LIBRARY_CLASS lines may be specified by a module The reserved keyword NULL must be listed for library class instances that do NOT support a library class keyword Only required for the two PEI_PCD_DRIVER or DXE_PCD_DRIVER PCD Driver modules This is the name of the driver s entry point function If a driver chooses to be unloadable then this is the name of the module s function registered in the Loaded Image Protocol It is called if the UEFI Boot Service Unloadl mage is called for the module which then executes the Unload function disconnecting itself from handles in the database as well as uninstalling any protocols that were installed in the driver entry point The CName is the name of this module s unload function This only applies to components that are libraries It is required for EDK II libraries if the module s INF contains a Constructor element
41. of the following section definitions Packages Packages common Packages IA32 Packages xX64 Packages IPF Packages ERC The path must be relative to the directory pointed to by the WORKSPACE system environment variable to construct the path MdeModulePkg MdeModulePkg dec WORKSPACE MdeModulePkg MdePkg MdePkg dec WORKSPACE MdePkg The following is an example of a packages section March 2015 Version 1 24B EDK II INF File Specification INF Overview Packages MdeModulePkg MdeModulePkg dec MdePkg MdePkg dec If there are files listed under the Sources section then the MdePkg MdePkg dec file must be specified in this section The MdePkg contains information that is required by the EDK II build system in order to compile or assemble source files using external compilers or assemblers When generating the As Built binary INF the tools must include all packages that declare PCDs used by this module Binary only INF files must include this section if a PatchPcd or PcdEx section contains PCD entries 2 14 PCD Sections These sections are used for specifying PCD information and are valid for EDK II modules only The entries for these sections are looked up from the package declaration files DEC for generating the AutoGen c and AutoGen h files The PCD s Name PcdName is defined as PCD Token Space GUID C name and the PCD C name separated by a period character Unique PCDs are identified using the f
42. section must be relative to the directory the NF file is in Use of and in the directory path is not permitted Use of an absolute path is not permitted The file name specified in the MODULE_UNI_FILE entry must be a UCS 2LE encoded file with an extension of uni UN or Uni MODULE_TYPE Drivers and applications are not allowed to have a MODULE_TYPE of BASE Only libraries are permitted to a have a MODULE_TYPE of BASE A INF file can be used to specify other binary files types such as logo images or legacy16 option ROMs The USER_DEFINED module type must be used in all cases where the module type is not a member of lt Edk2ModuleType gt INF VERSION For new INF files the version value must be set to 0x00010018 Tools that process this version of the INF file can successfully process earlier versions of the INF file this is a backward compatible update There is no requirement to change the value in existing INF files if no other content changes This may also be specified as decimal value 1 24 EDK RELEASE VERSION This optional value may be set to the major minor number of the EDK II release required for modules to function correctly UEFI_SPECIFICATION_VERSION The UEFI_SPECIFICATION_VERSION must only be set in the INF file if the module depends on UEFI Boot Services or UEFI Runtime Services or UEFI System Table fields or UEFI core behaviors that are not present in the UEFI 2 1 version The version number f
43. the executable can be located under a directory specified in the system environment PATH variable only the filename is required Otherwise a WORKSPACE relative path or an absolute path must be given If an absolute path is used the build system will fail the build if the executable cannot be found CommandCode A keyword that uniquely identifies a specific command the fourth field Several CommandCode keywords have been predefined See table below for the pre defined keywords and functional mappings The wildcard character is permitted only for the FAMILY DLL and DPATH attributes see Attributes below March 2015 62 EDK II INF File Format EDK II INF File Format EDK II INF File Specification Table 5 Predefined Command Codes CommandCode Function APP C compiler for applications ASL ACPI Compiler for generating ACPI tables ASLCC ACPI Table C compiler ASLDLINK ACPI Table C Dynamic linker ASLPP ASL C pre processor ASM A Macro Assembler for assembly code in some libraries ASMLINK The Linker to use for assembly code generated by the ASM tool cc C compiler for PE32 PE32 Coff images DLINK The C dynamic linker MAKE Required for tool chains This identifies the utility used to process the Makefiles generated by the first phase of the build PCH The compiler for generating pre compiled headers PP The C pre processor command SLINK The C static linker TIANO This special keyword identifies a compression too
44. this section This is an optional section March 2015 Version 1 24B EDK II INF File Specification EDK INF File Specification Prototype lt Libraries gt libraries lt attrs gt lt EOL gt lt LibName gt lt attrs gt lt archs gt lt platform gt lt archs gt lt arch gt lt arch gt lt platform gt libraries lt attrs gt lt arch gt IA32 X64 IPF EBC common platform nt32 PROCESSOR lt platform gt platform PLATFORM lt Word gt lt LibName gt lt Word gt Example Libraries common EfiProtocolLib EfiDriverLib A 2 5 nmake Section Summary Defines the nmake section tag for EDK I NF files These sections are used to make a direct addition to the component s output makefile EFI section nmake PROCESSOR PLATFORM nmake PROCESSOR and nmake common are processed if present The section data is simply copied directly to the component makefile before the build commands are emitted Filenames specified in this section are relative to the EDK INF file or the EDK DSC file This is an optional section This section is not permitted in EDK II modules Note that the C_STD_INCLUDE line is usually used to clear any flags that might have been set by the Microsoft tool chain setup scripts therefore no lt CFlags gt are printed and the line in the Example is the most common usage
45. utilities Elements may appear in any order within this section The version for this specification is 0x00010018 and new versions of this specification must increment the minor 0018 portion of the specification code for backward compatible changes and increment the major number for non backward compatible specification changes This value may also be specified as a decimal value 1 24 The Defines section assigns values to the symbols that describe the component Some items are emitted to the output makefile others are used to create filenames during the build Some symbols are emitted to the generated C files Version 1 24B March 2015 52 EDK II INF File Format EDK II INF File Specification The FILE_GUID is required for all EDK II modules This GUID is used to build the FW volume file list used by build tools to generate the final firmware volume as well as processed in some SMM PEI or DXE DEPEX statements All new EDK II INF files must include the statement INF_VERSION 0x00010018 in this section where the number varies according to the release of this specification It is a HexVersion type where the 0x0001 is the major number and the 0018 is the minor number This version of the specification provides full backward compatibility to all previous versions This means that tools that process this version of the specification can also process earlier versions of EDK II I NF files This version of the specification removes content
46. with other architecture type doing so will result in a build break Each GUID must be listed only once per section GUI Ds listed in architectural sections are not permitted to be listed in the common architectural section The format of the lt commentBlock gt is the recommended format that will guarantee that the information is correctly inserted into UEFI Distribution Package description files by the Intel UEFI Packaging Tool included in the EDK II base tools project The usages in the comment block describe how the GUID is used in the C code A binary INF file must not contain any FeatureFlagExpression content 81 March 2015 Version 1 24B EDK II INF File Specification Prototype lt Guids gt lt com_attribs gt lt attribs gt lt attrs gt lt GuidsStatements gt lt GuidSpec gt lt 1UsageBlock gt lt NUsageBlock gt lt FeatureFlagExpress gt lt CommentBlock gt lt UseOrFieldOpt gt lt UsageField gt lt GuidTypeField gt lt CmtOrEol gt lt Usage gt lt GuidType gt lt VariableType gt lt VariableName gt Parameters FeatureFlagExpress EDK II INF File Format Guids lt com_attribs gt lt EOL gt lt GuidsStatements gt common lt attribs gt lt attrs gt lt TS gt Guids lt attrs gt D lt arch gt lt NUsageBlock gt lt TS gt lt GuidSpec gt lt 1UsageBlock gt lt CName gt lt FS gt lt FeatureFlagExpress gt lt CommentBlock gt
47. word This is a single word identifier that will be used for the component name COMPONENT_TYPE Yes One of the EDK See Table EDK Component Component Types module Types for possible values FILE GUID No Optional Guid Value Registry 8 4 4 4 12 Format GUID for Libraries Required for all other component types EDK_RELEASE_VERS No Optional Hex Value A Hex version number 0x00020000 ION EFI_SPECIFICATIO No Optional HexValue A Hex version number 0x00020000 N_VERSION 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 Normally not used in INF files value in the generated Makefile C_FLAGS No Optional Microsoft C Flags Normally not used in INF files to use with for a cl Typically an EDK INF file will commands for this provide a separate nmake section module to specify different build parameters FFS_EXT No Optional File Extension The FFS extension to use for this component refer to the table EDK 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 ED
48. would require a library instance for the BaseMemoryAllocation class could specify the DXE_CORE INF file as the recommended instance for satisfying the required library class instance Appendix G lists the available MODULE_TYPE values supported by EDK II INF files The EDK II Defines section is common to all architectures and does not permit using architectural modifiers in the section tag name The following table shows EDK II unique elements of a defines section that may be required for generating the AutoGen c and AutoGen h files Library modules must never specify driver elements Version 1 24B March 2015 16 INF Overview EDK II INF File Specification Note Any lines not starting with one of the tag names defined in the table below are added to the top of the INF s generated makefile exactly as typed on the line in the INF file Note COMBINED_PEIM_ DRIVER is a driver that may be dispatched by either the PEI Core or the Dxe Core EDK Il only references the first possible dispatch instance 17 Table 1 EDK Il Defines Section Elements Tag INF_VERSION BASE_NAME EDK_RELEASE_VERSION PI_SPECIFICATION_VERSIO N Value 0x00010018 Required REQUIRED REQUIRED A single word Not Hex Double required Word Not Decimal or required special format of hex Notes This identifies the INF spec version Tools use this value to handle parsing of previous releases of the specification if there are incompatible ch
49. 0 9 lt NoL gt a zA Z0 9 0 A Z a zA Z0 9 2 lt NoL gt a zA Z0 9 0 lt Field2 gt lt FS gt lt FeatureFlagExpress gt lt FeatureFlagExpress gt lt Boolean gt lt AsBuiltInfo gt lt TS gt lt MTS gt Q LIB_INSTANCES lt WS gt lt LibInstance gt lt LibInstance gt lt TS gt lt TS gt lt InfFile gt lt EOL gt Parameters 65 March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format Fieldl This is a keyword that uniquely identifies a library class required to successfully execute the driver Filename Filenames listed in the Recommended Instance comment in the LibraryClasses section are relative to the system environment variable WORKSPACE Use of and in the directory path is not permitted If the Recommended Instance INF file is a member a Package the Package contains a DEC file the Package DEC file of must also be present in the Packages section Use of an absolute path is prohibited FeatureFlagExpress The feature flag expression is currently ignored by the EDK II build system Example LibraryClasses common DEFINE MDE WORKSPACE MdePkg Library RecommendedInstance MDE BaseDebugLibNull BaseDebugLibNull inf DebugLib UefiDriverModelLib PcdComponentNameDisable RecommendedInstance MDE UefiDriverModelLib UefiDriverModelLib inf PcdDriverDiagnosticsDisable UefiDriverEntryPoint UefiLib
50. 10013 BASE_NAME StatusCodeRuntimeDxe MODULE_UNI_FILE StatusCodeRuntimeDxe uni FILE_GUID FEDEOA1B BCA2 4A9F BB2B DIFD7DEC2EIF MODULE_TYPE DXE_RUNTIME_DRIVER VERSION_STRING 1 0 ENTRY_POINT StatusCodeRuntimeDxeEntry The following information is for reference only and not required by the build tools VALID_ARCHITECTURES IA32 X64 EBC VIRTUAL_ADDRESS_MAP CALLBACK VirtualAddressChangeCallBack Sources SerialStatusCodeWorker c RtMemoryStatusCodeWorker c DataHubStatusCodeWorker c StatusCodeRuntimeDxe h StatusCodeRuntimeDxe c Packages MdePkg MdePkg dec MdeModulePkg MdeModulePkg dec Intel Intel lFrameworkPkg IntelFrameworkPkg dec lFrameworkModulePkg IntelFrameworkModulePkg dec LibraryClasses OemHookStatusCodeLib SerialPortLib UefiRuntimeLib MemoryAllocationLib UefiLib UefiBootServicesTableLib UefiDriverEntryPoint II obLib PcdLib PrintLib ReportStatusCodeLib DebugLib BaseMemoryLib BaseLib March 2015 Version 1 24B EDK II INF File Specification Sample Driver INF Files SynchronizationLib Guids gEfiDataHubStatusCodeRecordGuid SOMETIMES PRODUCES UNDEFINED DataRecord Guid gEfiStatusCodeDataTypeDebugGuid SOMETIMES PRODUCES UNDEFINED Record data type gMemoryStatusCodeRecordGuid SOMETIMES CONSUMES HOB gEfiEventVirtualAddressChangeGuid CONSUMES Event gEfiStat
51. 4B March 2015 58 EDK II INF File Format EDK II INF File Specification 59 the system environment PATH variable prior to processing any commands Other user defined attributes can be specified in this section using either the append or replace Usage of these overrides is implementation specific Macro use is permitted in the BuildOptions sections and must follow the rule that Macros used in this section must be defined locally within the INF file use of externally defined MACROs is prohibited Additionally a MACRO that appears inside of a quoted string in R Values following an append or replace is permitted as parsing tools are not required to expand those macro values Macros within quoted strings do not need to be defined locally Macro statements MACRO that are encapsulated in double quotation marks are not expanded nor are they processed by parsing tools as double quotation marks indicate a string that must be treated as a single entity Macro statements in comments must also be ignored by parsing tools Macros are not allowed on the left side of the assignment statement left of the equal sign The EDK II build system will provide an option to create an As Built INF file that can be used for binary distributions This section will be completed listing all of the option flags for every application that was used to create the binary Since these As Built flags are within comment sections the actual f
52. 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 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 The EDK II build system also permits modules of type USER_DEFINED These modules will not be processed by the EDK II Build system Package A package is a container It can hold a collection of files for any given set of modules Packages may be described as containing zero or more of any of the following 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 PCD Platform Con
53. As Built INF file Appendix F page 120 Replaced invalid FW with PE32 for file type of the binary image Section 2 7 pages 25 amp 26 Clarified binary file types are leaf sections removed LIB as EDK II build system does not support distribution of binary libraries Section 2 7 page 25 Removed GUID encapsulation section keyword from the Binaries section lt FileType gt definition the binary file must be a leaf file type Section 3 2 page 37 require lt Depex gt sections for PEIM DXE_DRIVER DXE_RUNTIME_ DRIVER DNR SALL DRIVER and DNR MM DRIVER Table 3 page 23 and Section 3 5 page 60 Removed references to build_rule txt this file is used by tools no user editing is required Section 3 15 page 84 amp 85 Separated out the SUBTYPE_GUID entry inthe Binaries section lt FileType gt definition as this entry requires a GUID value also added text to only allow unique SUBTYPE_GUID lt GuidValue gt pairs per section Section 3 2 1 pages 44 amp 45 Fixed the DOS lt EOL gt character sequence Section 3 11 page 76 Clarify what goes into a generated Binary INF file for Protocols Added a generated binary INF in Appendix F Cleanup of tables in Appendix G Updated Example INF files in Appendix D and Appendix E Section 3 4 Added description of ENTRY_POINT and UNLOAD_IMAGE elements in the Defines section Version 1 24B March 2015 5 EDK II INF File Specification 1 22 w Errata C U
54. BSD LICENSE ON AN AS IS BASIS WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND EITHER EXPRESS OR IMPLIED Defines INF_VERSION 0x00010008 BASE_NAME Fat FILE_GUID 961578FE B6B7 44c3 AF35 6BC705CD2BI1F MODULE_TYPE UEFI_DRIVER VERSION_STRING build tools VALID_ARCHITECTUR Se OSE Oe E H HR el Co Binaries Ia32 PE32 Ia32 Fat efi Binaries X64 PE32 X64 Fat efi Binaries IPF 1 0 IA32 X64 IPF EBC March 2015 Ve The following information is for reference only and not required by the rsion 1 24B EDK II INF File Specification Sample Binary INF Files Wel Binaries E32 Ipf Fat efi EBC PE32 Ebc Fat efi Binaries ARM PE32 Arm Fat efi F 2 MdeModulePkg Core RuntimeDxe inf file Module that produces EFI runtime virtual switch over services This runtime module installs Runtime Architectural Protocol and registers CalculateCrc32 boot services table SetVirtualAddressMap amp ConvertPointer runtime services table Copyright c 2006 2012 Intel Corporation All rights reserved lt BR gt 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 f
55. Binaries section One and only one EFI_SECTION_USER_INTERFACE is allowed in a FFS image therefore one and only one UI UI Or UNI_UI can be included in any one Binaries section One and only one EFI_SECTION_FREEFORM_SUBTYPE_GUID is allowed in a FFS image therefore one and only one SUBTYPE_GUID with a unique GUID Value can be included in any one Binaries section March 2015 Version 1 24B EDK II INF File Specification Prototype lt Binaries gt lt BinariesStatements gt lt com_attribs gt lt attribs gt lt attrs gt lt UiExpression gt lt UiOptions gt lt UiFile gt lt UiType gt lt VerExpression gt lt VerOptions gt lt VerFile gt lt VerType gt lt SubTypeGuid gt lt GuidOpts gt lt GuidValue gt lt BinaryFiles gt lt FileOpts gt lt Options gt lt Opt1 gt lt Opt2 gt lt Opt3 gt Version 1 24B EDK II INF File Format Binaries lt com_attribs gt ln lt EOL gt lt UiExpression gt lt VerExpression gt lt BinariesStatements gt lt MacroDefinition gt lt BinaryFiles gt lt SubTypeGuid gt common lt attribs gt lt attrs gt lt TS gt Binaries lt attrs gt D lt arch gt lt TS gt lt UiFile gt lt UiOptions gt lt EOL gt lt FS gt lt Target gt lt FS gt lt FeatureFlagExpress gt lt UiType gt lt FS gt lt Filename gt UNI_UI UI lt TS gt lt VerFile gt lt VerOptions gt lt EOL gt lt FS gt lt
56. Binaries tag is required for EDK II INF files for Binary Modules This is a required section for Binary Modules Only Each binary file must be listed only once per section Files listed in architectural sections are not permitted to be listed in the common architectural section The common architecture modifier in a section tag must not be combined with other architecture type doing so will result in a build break There can be multiple Binaries sections depending on the target processor Example binaries sections are listed below Each binary file s path is relative to the location of the component s INF file The parsing utility creates a directory path for each file DEST_DIR Path OUTPUT and copies each file or a processed version of a UCS 2LE encoded User Interface or Version section to the OUTPUT directory No makefile is produced as binary files are only used by the third phase of a build creating FV FD or similar binary files All file names specified in this section must be in the directory containing the I NF file or in sub directories of the directory containing the INF file When a binary INF file is generated by tools during a source build if a symbol file such as a PDB or SYM file is generated the tools must add the file to this section using a binary file type of DISPOSABLE One and only one EFI_SECTION_VERSION is allowed in a FFS image therefore one and only one VER VER Or UNI_VER can be included in any one
57. Definition The INF definitions describe the content of a module either source or binary as well as external dependencies on packages that contain declarations of GUIDs Protocols PPIs and Library Classes The platform integrator will can select library instances that will be used for a given library class providing greater flexibility to the module developer It is not possible to code a module to a specific implementation of a library instance It is only possible to code a module to use a library class The Defines section must appear before any other section except the header The header when specified is always the first section of an INF file The remaining sections may be specified in any order within the I NF file Summary The EDK II Module Information INF file has the following format using the EBNF Version 1 24B March 2015 36 EDK II INF File Format lt EDK_II_INF gt EDK II INF File Specification lt Header gt lt Defines gt lt BuildOptions gt lt LibraryClasses gt lt Packages gt lt Pcds gt lt Sources gt lt Protocols gt lt Ppis gt lt Guids gt lt Binaries gt if LIBRARY CLASS is declared in Defines Section lt Depex gt elif MODULE_TYPE USER_DEFINED MODULE_TYPE UEFI_DRIVER lt Depex gt elif MODULE_TYPE PEIM MODULE_TYPE DXE_ DRIVER MODULE_TYPE DXE_ RUNTIME DRIVER MODULE_TYPE DXE SAL DRIVER MODULE_TYPE DXE_SMM DRIVER lt Depex gt eli
58. E WinNtLib COMPONENT_TYPE LIBRARY A 2 3 includes Section Summary Defines the optional includes paths for EDK INF files only These sections should never be used in EDK II INF files These sections are used to define the include paths for compiling the component source files Valid sections for EDK include the includes PROCESSOR PLATFORM includes PROCESSOR and includes common sections NOTE EDK uses both include and includes section header types These sections are processed if present These paths are used to define the INC macro and is written to the component s makefile This is an optional section The standard Macro Definitions are not permitted within this section For EDK modules the path must include either the EFI_SOURCE or EDK_SOURCE environment variable This section also allows for specifying individual header files that will be added to the INC macro using the FI Microsoft or include GCC switch This is an optional section Version 1 24B March 2015 107 EDK INF File Specification Prototype lt Includes gt lt Attrs gt lt Attributes gt lt Archs gt lt arch gt lt VarName gt lt Platform gt lt PATH gt lt MACRO gt lt MacroName gt lt RelDir gt Example Includes common SU tw Ep Ze A gt An Ze e bi D Di opp P Dh GO DK_SO DK_SO DK_SO DK_SO DK_SO DK_SO DK_SO DK_SO U
59. E 1 PeiServicesTablePointerLib inf 4 Se ose OSE SHE t SESE SHEE HEHE SHE HE SE HER 126 file for the table pointer Instance of PEI Services Table Pointer Library using global variable PEI Services Table Pointer Library implementation that retrieves a pointer to the PEI Services Table from a global variable Not available to modules that execute from read only memory Copyright ei 2007 2012 Intel Corporation All rights reserved lt BR gt 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 Defines INF_VERSION 0x00010018 BASE_NAME PeiServicesTablePointerLib MODULE_UNI_FILE PeiServicesTablePointerLib uni FILE_GUID 1c747f 6b 0a58 4 9ae 8ea3 0327a4fal0e3 MODULE_TYPE PEIM VERS ION_STRING 1 0 LIBRARY_CLASS PeiServicesTablePointerLib PEIM PEI_CORE SEC CONSTRUCTOR PeiServicesTablePointerLibConstructor VALID_ARCHITECTURES IA32 X64 IPF EBC EBC is for build only
60. E SKU1 MyPlatformPkg Skul Pei DEFINE OPENSSL_FLAGS DOPENSSL_SYSNAME_UWIN DOPENSSL_SYS_UEFI Table 4 Macro Usages MACRO DEFINITION MACRO USAGE DEFINE MY_MACRO test1 MY_MACRO test2 test3 inf DEFINE MY_MACRO test1 MY_MACRO test2 test3 inf DEFINE MY_MACRO test3 inf test1 test2 MY_MACRO DEFINE MY_MACRO test3 test1 test2 MY_MACRO inf DEFINE MY_MACRO test1 test2 test3 inf MY_MACRO 3 2 3 Conditional Statements The conditional statements are not permitted anywhere within the INF file 3 2 4 include Statement The include statement is not permitted in an EDK II INF file 3 2 5 Special Comment Blocks This section defines special format comment blocks that contain information about this module These comment blocks are not required They may appear at the end of any section within the INF file however it is preferred that they appear at the end of the file The format of these comment blocks is the recommended format that will guarantee that the information is correctly inserted into UEFI Distribution Package description files If this comment block appears in a Source INF file the EDK II build tools must copy this comment block into the generated As Built binary INF file These comment blocks are only required for modules that use C calls to perform actions using UEFI defined functions listed in below There are three predefined types of comments The Event types which describe timer delays used by the Boot
61. EBC DRIVER_BINDING COMPONENT_NAME COMPONENT_NAME2 gDiskIoDriverBinding gDiskIoComponentName gDiskIoComponentName2 March 2015 Version 1 24B EDK II INF File Specification Sample Driver INF Files So D D Pa urces omponentName c iskIo h iskTlow e ckages MdePkg MdePkg dec Ei U braryClasses efiBootServicesTableLib MemoryAllocationLib B B U U D Pr g g aseMemoryLib aseLib efiLib efiDriverEntryPoint ebugLib otocols EfiDiskIoProtocolGuid BY_START EfiBlockIoProtocolGuid TO_START D 2 StatusCodeRuntimeDxe I NF file tt Se Sk SE Sk OSE SE OSE SE OSE OSE EOE SEE file Status Code Runtime Dxe driver produces Status Code Runtime Protocol Copyright c 2006 2012 Intel Corporation All rights reserved lt BR gt 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 Version 1 24B March 2015 121 Sample Driver INF Files EDK II INF File Specification 122 Defines INF_VERSION 0x000
62. ES gEfiSimpleTextOutProtocolGuid SOM E TIMES CONSUMES gEfiGr aphicsOutputProtocolGuid SOMETIMES CONSUMES gEfiHi iFontProtocolGuid SOMETIMES_CONSUMES Consumes if gEfiGraphicsOutputProtocolGuid uninstalled March 2015 E bo Q iw Version 1 24B EDK II INF File Specification Sample Binary INF Files gEfiUgaDrawProtocolGuid SOMETIMES_PRODUCES User chooses to produce it gEfiComponentNameProtocolGuid SOMETIMES_PRODUCES User chooses to produce it gEfiComponentName2ProtocolGuid SOMETIMES_PRODUCES User chooses to produce it gEfiDriverConfigurationProtocolGuid SOMETIMES PRODUCES User chooses to produce it gEfiDriverConfiguration2ProtocolGuid SOMETIMES_PRODUCES User chooses to produce it gEfiDriverDiagnosticsProtocolGuid SOMETIMES_PRODUCES User chooses to produce it gEfiDriverDiagnostics2ProtocolGuid Kee s Guids IA32 CONSUMES Event CONSUMES Event PRODUCES Event RuntimeDriverSetVirtualAddressMap signals this event gEfiEventVirtualAddressChangeGuid SOMETIMES_CONSUMES SOMETIMES_CONSUMES UNDEFINED gEfiStatusCodeDataTypeDebugGuid CONSUMES Event CONSUMES Event gEfiEventExitBootServicesGuid SOMETIMES CONSUMES UNDEFINED gEfiStatusCodeSpecificDataGuid
63. E_FILE_PATH lt PathOnly gt lt EOL gt MICROCODE_ALIGNMENT lt HexNumber gt lt EOL gt MICROCODE_FILE_PATH lt PathOnly gt lt EOL gt PLATFORM_BDS_FILE_PATH lt PathOnly gt lt EOL gt RESTRICTED_BDS_ FILE PATH lt PathOnly gt lt EOL gt lt PATH gt lt Word gt lt Extension gt lt PATH gt lt Word gt MAKEFILE CUSTOM _MAKEFILE lt Filename gt lt Variable gt lt Path gt lt Word gt lt MacroName gt WORKSPACE EFI_SOURCE EDK_SOURCE lt RegistryFormatGUID gt EFI_APRIORI_GUID EFI_ACPI_TABLE_STORAGE_GUID EFI_DEFAULT_BMP_LOGO_GUID EFI_PEI_APRIORI_FILE NAME GUID APPLICATION AcpiTable APRIORI BINARY BS_DRIVER CONFIG FILE FVIMAGEFILE LIBRARY LOGO LEGACY16 March 2015 Version 1 24B EDK II INF File Specification EDK INF File Specification MICROCODE PE32_PEIM PEI_CORE RAWFILE RT_DRIVER SAL_RT_DRIVER SECURITY_CORE COMBINED_PEIM DRIVER PIC_PEIM RELOCATABLE_PEIM lt MacroName gt lt Word gt Example EDK Driver Defines BASE_NAME DiskIo FILE_GUID CA261A26 7718 4b9b 8A07 5178B1AE3A02 COMPONENT_TYPE BS_DRIVER Example EDK Library Defines BASE_NAM
64. E_RUNTIME_DRIVER MODULE_TYPE BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER EDK II Extension ef ef ef ef ef ef ef EDK II INF File Specification Description Modules of this type can be ported to any execution environment This module type is intended to be use by silicon module developers to produce source code that is not tied to any specific execution environment 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 This module type is used by PEI Core implementations that are complaint with the PEI CIS This module type is used by PEI Ms that are compliant with the PEI CIS This module type is used by DXE Core implementations that are compliant with the DXE CIS This module type is used by 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 This module type is used by DXE Drive
65. F File Specification This module type is used by PEI Core implementations that are complaint with the PEI CIS When migrating to EDK II this type of module should use the register for shadow PPI and set the defines entry SHADOW TRUE This module type is used by PEIMs that are compliant with the PEI CIS 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 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 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 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 a
66. F Overview SUBTYPE_GUID This binary is an EFI_SECTION_FREEFORM_SUBTYPE_GUID leaf section TE This binary is an EFI_SECTION_TE leaf section UNI_VER This is a UCS 2LE encoded file that needs to be used to create an EFI_SECTION_VERSION leaf section VER This binary is an EFI_SECTION_VERSION leaf section UNI_UI This is a UCS 2LE encoded file that needs to be used to create an EFI_SECTION_USER_INTERFACE leaf section UL This binary is an EFI_SECTION_USER_INTERFACE leaf section BIN This binary is an EFI_SECTION_RAW leaf section RAW This binary is an EFI_FV_FILETYPE_RAW leaf section COMPAT16 This binary is an EFI_SECTION_COMPATIBILTY16 leaf section FV This binary is an EFI_SECTION_FIRMWARE_VOLUME_IMAGE leaf section Note The section names listed above refer to leaf section type values rather than the name of the data structure The following are examples of different types of Binaries sections Binaries common UNI_UI DxeIpl ui UNI_VER DxeLoad ver Version 1 24B March 2015 26 INF Overview EDK II INF File Specification Binaries IA32 DXE_DEPEX Ia32 DxeIpl dpx MYTOOLS PE32 Ia32 DEBUG DxeIpl efi DEBUG MYTOOLS PE32 Ia32 RELEASE DxeIpl efi RELEASE MYTOOLS DISPOSABLE Ia32 DEBUG DxeIpl pdb Binaries X64 DXE_DEPEX X64 DxeIpl dpx MYTOOLS PE32 X64 DxeIpl efi MYTOOLS Binaries IPF DXE_DEPEX IPF DxeIpl dpx MYTOOLS PE32 Ipf DxeIpl efi MYTOOLS 2 8 Includes Section Never use an
67. General Rules This section covers the format for the EDK II module INF files While the EDK code base and tools treated libraries completely separate from modules the EDK II code base and tools process modules with libraries being considered a module that produces a library class 2 2 1 Section Entries To simplify parsing the EDK II meta data files continue using the INI format This style was introduced for EDK meta data files when only the Windows tool chains were supported It was decided that for compatibility purposes that INI format would continue to be used EDK II formats differ from the defacto format in that the semi colon character cannot be used to indicate a comment Leading and trailing space tab characters must be ignored Duplicate section names must be merged by tools This description file consists of sections delineated by section tags enclosed within square brackets Section tag entries 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 Sources X64 Sources IPF 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 Version 1 24B March 2015 10 INF Overview EDK II INF File Specification tags is from right to left with section
68. IGURATION DIAGNOSTICS BOOT_WITH_FULL_CONFIGURATION_PLUS_DIAGNOTICS DEFAULT BOOT_WITH DEFAULT_SETTINGS S2_RESUME BOOT_ON_S2_RESUME March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format S3_RESUME BOOT_ON_S3_RESUME S4_RESUME BOOT_ON_S4_RESUME S5_RESUME BOOT_ON_S5_RESUME FLASH_UPDATE BOOT_ON_FLASH_ UPDATE BOOT_MFG MODE BOOT WITH MFG MODE SETTINGS RECOVERY_FULL BOOT_IN_ RECOVERY _MODE RECOVERY_MINIMAL RECOVERY_NO_CHANGE RECOVERY_DIAGNOSTICS RECOVERY_DEFAULT RECOVERY_S2_ RESUME RECOVERY_S3_RESUME RECOVERY_S4_RESUME RECOVERY_S5_RESUME RECOVERY_FLASH_UPDATE UNDEFINED lt HobSection gt lt TS gt Hob lt attribs gt lt EOL gt lt HobBlock gt lt attribs gt lt attr gt lt TS gt Hob lt attr gt lt attr gt e lt arch gt lt HobBlock gt lt CommonDescription gt lt TS gt lt HobType gt lt UsageField gt lt EOL gt lt HobType gt PHIT MEMORY ALLOCATION LOAD_PEIM RESOURCE_DESCRIPTOR FIRMWARE_VOLUME FIRMWARE_VOLUME2 MEMORY_POOL GUID_TYPE UEFI_CAPSULE CPU UNUSED UNDEFINED Parameters Event Usage CONSUMES The module registers a notification function and requires that it be executed for the module to fully function SOMETIMES CONSUMES A module registers a notif
69. II modules 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 Version 1 24B March 2015 1 Introduction EDK II INF File Specification 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 Extensible Firmware Interface Development Kit the original implementation of the Intel Platform Innovation Framework for EFI Specifications developed in 2007 EDK II EFI Development Kit version II that provides updated firmware module layouts and custom tools superseding the original EDK 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
70. INF files and to define the tool chain for building Defines the build tip directory for the current platform For example this may be EDK_SOURCE Platform Anacortes_870 For a component defines the directory of the component source files For acomponent defines the directory typically under BUILD_DIR where the component object files are to be built Specifies the directory where EFI libraries are deposited after building Typically BUILD_DIR PROCESSOR Specifies the directory where final component binaries are deposited during build Typically BUILD_DIR PROCESSOR Unused but typically BUILD_DIR PROCESSOR Name of the DSC file as specified on the command line Can be used for dependencies in the makefiles Name of the I NF file for a given component Can be used for dependencies in the makefiles Common component type BS driver application etc have predefined file name extensions assigned dxe app etc If there is a deviation from the convention or a new unknown to the utility component type is being built then FV_EXT may need to be defined for the component so the utility knows the result file name extension This information is necessary to generate dependencies in makefile out Name of the output makefile for the component Default is makefile This value can be overridden to support building different variations of a component in the same DEST_DIR directory This symbol can
71. K 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 96 March 2015 Version 1 24B EDK II INF File Specification EDK INF File Specification The following table lists the available COMPONENT_TYPE values supported by EDK INF files Version 1 24B March 2015 97 EDK INF File Specification Table 7 EDK Component module Output File Extensions EDK II INF File Specification COMPONENT_ TYPE LIBRARY FILE Apriori EFI Binary Executable AcpiTable Legacy16 BINARY CONFIG LOGO RAWF ILE FVIMAGEF ILE SECURITY_CORE EDK II Extension lib From file name or FFS bin ef acpi bin bin bin bin raw ef EDK File FFS or FV Extension lib From file name or FFS SEC pe32 SEC SEC FFS SEC SEC RAW PV SEC Description Library component linked as part of the build with other components Raw file copied directly to FV 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 PE32 PE32 Coff binary executable The extension o
72. KIND EITHER EXPRESS OR IMPLIED Defines INF_VERSION 0x00010018 BASE_NAME SmmCorePerformanceLib MODULE_UNI_FILE SmmCorePerformanceLib uni FILE_GUID 36290D10 0F47 42c1 BBCE E191C7928DCF MODULE_TYPE SMM_CORE VERSION_STRING 1 0 March 2015 Version 1 24B EDK II INF File Specification Sample Library INF Files PI_SPECIFICATION_VERSION 0x0001000A LIBRARY_CLASS PerformanceLib SMM_COR CI CONSTRUCTOR SmmCorePerformanceLibConstructor The following information is for reference only and not required by the build tools VALID_ARCHITECTUR El n IA32 X64 3E E HEE HR HR Sources SmmCorePerformanceLib c SmmCorePerformanceLibInternal h Packages MdePkg MdePkg dec MdeModulePkg MdeModulePkg dec LibraryClasses MemoryAllocationLib UefiBootServicesTableLib PeaLib TimerLib BaseMemoryLib BaseLib DebugLib SynchronizationLib SmmServicesTableLib Protocols gEfiSmmBase2ProtocolGuid CONSUMI gEfiSmmAccess2ProtocolGuid CONSUM El Wei El Wei Guids PRODUCES UNDEFINED Install protocol CONSUMES UNDEFINED SmiHandlerRegister gSmmPerformanceProtocolGuid PRODUCES UNDEFINED Install protocol CONSUMES UNDEFINED SmiHandlerRegister gSmmPerformanceExProtocolGuid Ped gEfiMdePkgTokenSpaceGuid PcdPerformanceLibraryProper
73. O nologo _WINDDK3790x1830_ _CC_FLAGS Qwd1418 810 _MYTOOLS_ _CC_FLAGS Qwd1418 810 VS2003_ _CC_FLAGS wd4244 WINDDK3790x1830_ _CC_FLAGS wd4244 MYTOOLS_ _CC_FLAGS wd4244 RELEASE_MYTOOLS_IPF_ASM_FLAGS N us X explicit M ilp64 N so W3 MSFT _ _ _ FLAGS od MACRO 3 6 LibraryClasses Sections These are optional sections Summary Defines the EDK II LibraryClasses section content The Library Class entries are single lines with one or two fields separated by the pipe character The optional MODULE_TYPE refers to the supported Module Type and may be a comma separated list of supported module types The EDK II build system will provide an option to generate an As Built INF that can be used to distribution binary modules Since a binary distribution does not build the library instances that were linked into the binary are listed in comments rather than as library class keywords and recommended instances Tools that create As Built information must expand any macro values used by the tools during the module build Listing a library class keyword outside of the As Built information is prohibited Each library class keyword must only be listed once in a library classes section Library class keywords listed in architectural sections are not permitted to be listed in the common architectural section The common architecture modifier in a section tag must not be com
74. O SUBSYSTEM CONSOLE NODEFAULTLIB IGNORE 4086 MAP OPT REF DEBUG MACHINE 1386 LTCG Kernel32 1ib MSVCRTD 1ib Gdi32 1ib User32 1ib Winmm lib MSFT DEBUG_ _IA32_CC_FLAGS nologo W4 WX Gy c D UNICODE D EFI32 Od DSTRING_ARRAY_ NAME SecMainStrings FIS DEST_DIR_DEBUG AutoGen h EHs c GF Gs8192 Zi Gm For BuildOptions sections in the INF file the entries with a common left side of the will be either appended or replace previous entries based on the replace or append assignment character sequence Sections with identical architecture modifiers are appended to each other Common Section Architectural Section Example BuildOptions Common MSFT _ _ _CC_FLAGS nologo BuildOptions Common MSFT _ _ _CC_FLAGS Od BuildOptions IA32 MSFT _ _IA32_CC_FLAGS D EFI32 For IA32 architecture builds of an EDK II INF file would logically be MSFT _ _IA32_CC_FLAGS nologo Od D EFI32 For X64 architecture builds of an EDK II INF file would logically be MSFT _ _IA32_CC_FLAGS nologo Od 2 7 Binaries Section The Binaries section is used to specify the binary files that are distributed as part of a Binary Module The binary files listed are not used by the MAKE portion of a platform build but are used by other tools to generate an image suitable for either an Application FD or FV A pipe character is used to separate the fields If the file is in a sub d
75. OE OSE OE RHE HE Module that lays Disk I O protocol on every Block I O protocol This module produces Disk I O protocol to abstract the block accesses of the Block I O protocol to a more general offset length protocol to provide byte oriented access to block media It adds this protocol to any Block I O interface that appears in the system that does not already have a Disk I O protocol File systems and other disk access code utilize the Disk I O protocol Copyright c 2006 2012 Intel Corporation All rights reserved lt BR gt 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 Defines INF_VERSION 0x00010018 BASE_NAME DiskIoDxe MODULE_UNI_FILE DiskIoDxe uni FILE_GUID 6B38F7B4 AD98 40e9 9093 ACA2B5A253C4 MODULE_TYPE UEFI_DRIVER VERSION_STRING 1 0 ENTRY_POINT InitializeDiskIo The following information is for reference only and not required by the build tools Se Sk OSE SRE OE SE HE VALID_ARCHITECTUR ti We ll IA32 X64 IPF
76. Options Section Elements 22 Table 3 EDK II BuildOptions Variable Descrptons teense teense eeeeeeeeeeeeeeeeeeees 23 Table4 M ero U8sages ur me Eee 47 Table 5 Predefined Command Codes u a era sde 64 Table 6 EDK defines Section Elements 96 Table 7 EDK Component module Output File Extensions nen 98 Table 8 S5ymbolDeseription 2 2 ee ea 116 Table 9 EDK IlM d l Types anne 139 Table 10 Module Type to Component Type Mapping cccceeeeceeeeneeeeeeeteeeeeseeeeeseeneeeneeeeeeaeees 142 Version 1 24B March 2015 xiii EDK II INF File Specification 14 March 2015 Version 1 24B EDK II INF File Specification 1 Introduction This document describes the EDK II build information INF file format This format supports the new build requirements of build EDK components and EDK II modules within the EDK II build infrastructure The EDK II Build Infrastructure supports creation of binary images that comply with Unified EFI UEFI 2 4 and UEFI Platform Infrastructure PI 1 3 specifications 1 1 Overview This document describes the format of EDK II INF files that has the following requirements Compatible Backward compatibility with the existing INF file formats Changes made to this specification must not require changes to existing I NF files Simplified platform build and configuration Simplify the build setup and configuration for a given platform The process of adding EDK and EDK II firmware components to a firmw
77. RIBUTE specific attributes if required gt string In this section the following table describes each of the variables that are shown above Version 1 24B March 2015 22 INF Overview EDK II INF File Specification Table 3 EDK Il BuildOptions Variable Descriptions Variable Required FAMILY NO TARGET YES TAGNAME YES ARCH YES TOOLCODE YES ATTRIBUTE YES Wildcard No Yes Yes Yes NO NO Source Conf tools_def txt defines the FAMILY values for example MSFT INTEL or GCC Typically this field is used to help the build tools determine whether the line is used for Microsoft style Makefiles or the GNU style Makefiles By not specifying the FAMILY the tools assume the flags are applicable to all families Conf tools_def txt file defines two values DEBUG and RELEASE Developers may define additional targets Conf tools_def txt file defines several different tag names these are defined by developers the default tag name MY TOOLS is provided in the template for tools_def txt and set in the Conf target txt file Conf tools_def txt defines at least four architectures IA32 X64 IPF and EBC This tag must use all capital letters for the tag Additional Architectures such as PPC or ARM may be added as support becomes available The tool code must be one of the defined tool codes in the Conf tools_def txt file The flags defined in this section are appended to flags defin
78. S gt AsBuilt lt EOL gt lt AsBuiltFfe gt lt TS gt lt FamId gt lt ToolFlags gt lt Eq gt lt CFlags gt lt EOL gt lt TS gt lt CFlagsContd gt lt EOL gt lt CFlags gt lt FlagExpr gt lt PathExpr gt lt CmdExpr gt lt Other gt lt Family gt lt TS gt lt FamId gt lt ToolFlags gt lt Equal gt lt CFlags gt lt EOL gt lt TS gt lt FamId gt lt ToolPath gt lt Equal gt lt PATH gt lt EOL gt lt TS gt lt FamId gt lt ToolCmd gt lt ReplaceEq gt lt PathCmd gt lt EOL gt lt OtherTool gt lt MacroDefinition gt lt TS gt lt FamId gt lt ToolOther gt lt Equal gt lt String gt lt EOL gt MSFT GCC INTEL lt Usr gt lt Wildcard gt lt ToolWord gt lt AppendEq gt lt ReplaceEg gt lt Eq gt lt TS gt lt TS gt lt Target gt _ lt TagName gt _ lt tarch gt _ lt CmdCode gt lt ToolSpec gt _FLAGS lt ToolSpec gt _DPATH March 2015 60 EDK II INF File Format EDK II INF File Specification lt ToolCmd gt lt ToolSpec gt _PATH lt ToolOther gt lt ToolSpec gt _ lt Attribute gt lt Target gt lt Wildcard gt Target lt TagName gt lt Wildcard gt TagName lt CmdCode gt CommandCode lt CommandName gt CommandExecutable lt Attribute gt Attribute lt tarch gt IA32 X64 IPF EBC lt OA gt lt Wildcard gt lt CFlags gt 0x20 Ox7e lt PathCmd gt l
79. Section gt lt ValidArchitectures gt lt ArchL gt lt EbcCmt gt lt EventSection gt lt CommonDescription gt lt EventBlock gt lt UsageField gt lt EventType gt lt Usage gt lt Description gt lt BootModeSection gt lt BootModeBlock gt lt BootModeType gt EDK II INF File Specification lt ValidArchitectures gt lt EventSection gt lt BootModeSection gt lt HobSection gt lt EOL gt lt TS gt VALID_ARCHITECTURES lt Eq gt lt ArchL gt lt EOL gt lt Arch gt lt Space gt lt Arch gt lt EbcCmt gt lt EOL gt lt Space gt EBC is for build only lt TS gt Event lt EOL gt lt EventBlock gt n lt TS gt ap lt EOL gt lt TS gt lt TS gt lt Description gt lt EOL gt WM lt TS gt lt ROL gt lt CommonDescription gt lt TS gt lt EventType gt lt UsageField gt lt EOL gt lt TS gt lt TS gt lt Usage gt EVENT_TYPE_PERIODIC_TIMER EVENT_TYPE_RELATIVE_TIMER UNDEFINED CONSUMES SOMETIMES_ CONSUMES PRODUCES SOMETIMES PRODUCES UNDEFINED lt AsciiString gt lt TS gt BootMode lt EOL gt lt BootModeBlock gt lt CommonDescription gt lt TS gt lt BootModeType gt lt UsageField gt lt EOL gt FULL BOOT_WITH FULL _CONFIGURATION MINIMAL BOOT_WITH MINIMAL CONFIGURATION NO_CHANGE BOOT_ASSUMING_NO_CONF
80. Services SetTimer call EVENT_TYPE_PERIODIC_TIMER Event is to be signaled periodically EVENT_TYPE_RELATIVE_TIMER Event is to be signaled in x 100ns units UNDEFINED This will appear when a UEFI Distribution Package tool was unable to parse the comment spelling error when creating a distribution package and the tool installed the distribution package using this value 45 March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format The BootMode types which describe the BootMode values in the Boot Services SetBootMode and GetBootMode calls FULL Equivalent to BOOT_WITH_FULL_CONFIGURATION MINIMAL Equivalent to BOOT_WITH_MINIMAL CONFIGURATION NO_CHANGE Equivalent to BOOT_ASSUMING_NO_CONFIGURATION_CHANGES DIAGNOSTICS Equivalent to BOOT_WITH_FULL_CONFIGURATION DEFAULT Equivalent to BOOT_WITH_FULL_CONFIGURATION S2_RESUME Equivalent to BOOT_ON_S2_ RESUME S3_RESUME Equivalent to BOOT_ON_S3_RESUME S4_RESUME Equivalent to BOOT_ON_S4_ RESUME S5_RESUME Equivalent to BOOT_ON_S5_RESUME FLASH UPDATE Equivalent to BOOT_ON_FLASH UPDATE RECOVERY_FULL Equivalent to BOOT_IN_RECOVERY_MODE BOOT_MFG MODE Equivalent to BOOT _WITH MFG MODE SETTINGS The following items are defined as special boots that may use the bit field values 100001b 111111b per the PI PEI specification table 6 Since this comment block is informational no attempt is made to map these items to specific bit patterns RECOVERY
81. Target gt lt FS gt lt FeatureFlagExpress gt lt VerType gt lt FS gt lt Filename gt UNI_VER VER lt TS gt SUBTYPE_GUID lt GuidOpts gt lt EOL gt lt FS gt lt GuidValue gt lt FileOpts gt lt EOL gt lt CName gt lt RegistryFormatGUID gt lt TS gt lt FileType gt lt FileOpts gt lt EOL gt lt FS gt lt Filename gt lt Options gt lt EOL gt lt FS gt lt Target gt lt Opt1 gt lt FS gt lt Family gt lt Opt2 gt lt FS gt lt TagName gt lt Opt3 gt lt FS gt lt FeatureFlagExpress gt March 2015 90 EDK II INF File Format lt Target gt lt Family gt lt Usr gt lt TagName gt lt FeatureFlagExpress gt lt FileType gt lt Edk2FileType gt Parameters FeatureFlagExpress EDK II INF File Specification lt ToolWord gt lt Wildcard gt MSFT GCC INTEL lt Usr gt lt wildcard gt lt ToolWord gt ToolWord lt Wildcard gt lt Boolean gt lt Edk2FileType gt ACPI ASL PE32 PIC FV PEI_DEPEX DXE_DEPEX SMM_DEPEX TE m BIN RAW COMPAT16 DISPOSABLE The feature flag expression is currently ignored by the EDK II build system Note For more information about the following parameters refer to the Build Specification for a description of the tools_def txt file In order for the entries in the INF file to be valid there must be a matching definition in the too
82. The wildcard character is permitted after it has been defined one time for a tool chain 61 March 2015 Version 1 24B EDK II INF File Specification Version 1 24B TagName Arch A keyword that uniquely identifies a tool chain group the second field Wildcard characters are permitted if and only if a command is common to all tools that will be used by a developer As an example if the development team only uses IA32 Windows workstations the ACPI compiler can be specified as DEBUG_ _ _ASL_PATH and RELEASE_ _ _ASL_PATH A keyword that uniquely identifies the tool chain target architecture the third field This flag is used to support the cross compiler features such as when a development platform is IA32 and the target platform is X64 Using this field a single TagName can be setup to support building multiple target platform architectures with different tool chains As an example if a developer is using Visual Studio NET 2003 for generating IA32 platform and uses the WINDDK version 3790 1830 for X64 or IPF platform images a single tag see the MYTOOLS PATH settings in the generated Conf tools_def txt or provided BaseTools Conf tools_def template file The wildcard character is permitted if and only ifthe same tool is used for all target architectures CommandExecutable The full executable name such as cl exe or gcc with the preceding path specifying the exact location of the command If
83. Use of and in the directory path is not permitted FeatureFlagExpress The feature flag expression is currently ignored by the EDK II build system TagName A keyword that uniquely identifies a tool chain group the second field Wildcard characters are permitted if and only if a command is common to all tools that will be used by a developer As an example if the development team only uses IA32 Windows workstations the ACPI compiler can be specified as DEBUG_ _ ASL PATH and RELEASE_ _ ASL PATH CommandCode A keyword that uniquely identifies a specific command the fourth field Several CommandCode keywords have been predefined however users may add additional keywords with appropriate modifications to build_rule txt See table below for the Version 1 24B March 2015 74 EDK II INF File Format EDK II INF File Specification pre defined keywords and functional mappings The wildcard character is permitted only for the FAMILY DLL and DPATH attributes see Attributes below Family Family is keyword that uniquely identifies a tool chain family The Family must be either a wildcard character meaning any Family or it must match a defined value for a Family label in the tools_def txt file for at least one tool chain TagName specified in tools_def txt or the TagName field that follows this field in the entry Example Sources common RS E DrSk1o h ComponentName c Sources IA32 Ta32 Diskes h 3 10
84. UserExtensions lt IdContent gt lt IdContent gt lt UserId gt lt IdString gt lt attrs gt lt attrs gt re lt arch gt lt UserId gt a zA Z a zA Z0 9_ TianoCore lt IdString gt lt NormalizedString gt lt SimpleWord gt lt ReservedWord gt lt ReservedWord gt PRE_PROCESS POST_PROCESS ExtraFiles lt statements gt Content is build tool chain specific Parameters UserId Words that contain period must be encapsulated in double quotation marks Tastr ng Normalized strings that contain period or space characters must be encapsulated in double quotation marks The IdString must start with a letter Example UserExtensions Edk2AcpiTable 1 0 Any content may go here 3 10 1 UserExtensions TianoCore ExtraFiles Section This is an optional section Defines the optional EDK II INF file UserExtensions TianoCore ExtraFiles section tag The EDK II build tools must not process any files listed in this section Summary This section is used by the Intel UEFI Packaging Tool that is distributed as part of the EDK II BaseTools to locate files listed under this section header and add them to the UEFI distribution package When installing a UEFI distribution package these files will be installed in the module s directory tree Version 1 24B March 2015 76 EDK II INF File Format EDK II INF File Specification Prototype lt UserExtensions gt UserEx
85. _MINIMAL RECOVERY_NO_CHANGE RECOVERY_DIAGNOSTICS RECOVERY_DEFAULT RECOVERY_S2_RESUME RECOVERY_S3_ RESUME RECOVERY_S4_ RESUME RECOVERY_S5_RESUME RECOVERY_FLASH_UPDATE UNDEFINED This will appear when a UEFI Distribution Package tool was unable to parse the comment spelling error when creating a distribution package and the tool installed the distribution package using this value The Hand Off Block types refer to the various HOBs as defined by the PI specification HOB Code Definitions Modules that use GetHobList and CreateHob should list this content PHIT the Phase Handoff Information Table PHIT Hob MEMORY_ALLOCATION Describes all memory ranges LOAD_PEIM This refers to EFI_HOB TYPE_LOAD PEIM UNUSED RESOURCE_DESCRIPTOR describes resource properties FIRMWARE_VOLUME FIRMWARE _VOLUME2 location and type of firmware volumes MEMORY_POOL describes memory pool allocations GUID_TYPE for HOB types not define by the PI specification UEFI_CAPSULE describes UEFI capsule memory pages CPU describes processor information UNUSED the HOB s content can be ignored UNDEFINED This will appear when a UEFI Distribution Package tool was unable to parse the comment spelling error when creating a distribution package and the tool installed the distribution package using this value Version 1 24B March 2015 46 EDK II INF File Format Prototype lt FixedComment
86. alid architectural directory names A32 IPF and EBC are not acceptable directory names and may cause build breaks From a build tools perspective IA32 is not equivalent to la32 or ia32 e Absolute paths are not permitted in EDK II INF files All paths specified are relative to the WORKSPACE system environment variable relative to an EDK II package directory defined as a directory containing a DEC file or relative to the directory containing the I NF file 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 may contain space characters in paths on Windows systems Version 1 24B March 2015 12 INF Overview EDK II INF File Specification Note The tools_def txt file and BuildOptions sections are the places that permit the use of space characters in 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 INF files Architecture keywords IA32 IPF X64 and EBC are used by build tools and in meta data 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 la32 pf X64 and Ebc do not automatically c
87. anges This is a single word identifier that will be used for the component name The minimum revision value across the module and all its dependent libraries If a revision value is not declared in the module or any of the dependent libraries then the tool may use the value of 0 which disables checking The minimum revision value across the module and all its dependent libraries If a revision value is not declared in the module or any of the dependent libraries then tools may use the value of 0 which disables checking The PI_SPECIFICATION_VERSION must only be set in the INF file if the module depends on services or system table fields or PI core behaviors that are not present in the PI 1 0 version For example if a module depends on definitions in Pl 1 1 that are not in Pl 1 0 then PI_SPECIFICATION_VERSION must be 0x0001000A March 2015 Version 1 24B EDK II INF File Specification Tag UEFI_SPECIFICATION_VERS ION FILE GUID MODULE_TYPE BUILD_NUMBER VERSION_STRING MODULE_UNI_FILE Required Not required REQUIRED REQUIRED Optional REQUIRED Optional Value Decimal or special format of hex GUID Value UINT16 Value String Filename INF Overview Notes The minimum revision value across the module and all its dependent libraries If a revision value is not declared in the module or any of the dependent libraries then tools may use the value of 0 which d
88. arch 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format FileType SUBTYPE_GUID The file type SUBTYPE_GUID is shorthand for the EFI_FREEFORM_SUBTYPE_GUID_SECTION section FileType DISPOSABLE The file type DISPOSABLE does not represent content for the EFI_SECTION_DISPOSABLE These files will not be processed by EDK II build tools but rather may specify other types of files that may be used such as PDB or SYMS files generated for symbolic debugging Example Binaries common UNI_UI DxeIpl ui UNI_VER DxeLoad ver Binaries 1a32 DXE_DEPEX Release DxeIpl dpx MYTOOLS PE32 Debug Ia32 DxelIpl efi DEBUG MYTOOLS PE32 Release Ia32 DxeIpl efi RELEASE MYTOOLS DISPOSABLE Debug Ia32 DxeIpl pdb DEBUG Binaries X64 DXE_DEPEX Debug X64 DxeIpl dpx MYTOOLS PE32 Debug X64 DxeIpl efi DEBUG F MYTOOLS DISPOSABLE Debug X64 DxeIpl pdb DEBUG Binaries IPF DXE_DEPEX Debug IPF DxeIpl dpx MYTOOLS PE32 Debug Ipf DxeIpl efi DEBUG MYTOOLS DISPOSABLE Debug Ipf DxeIpl pdb DEBUG Version 1 24B March 2015 92 EDK II INF File Specification Appendix A EDK I NF File Specification This appendix covers the format of the original EDK INF files However the format of comments in the EDK INF may vary from this specification as the original EDK parsing tool ProcessDSC only looked for a specific se
89. are Relative path and filename ext Filename ext The following is an example for sources sections 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 All UCS 2LE encoded files must be listed in the source section If a UCS 2LE encoded file A uni has the statement include B uni and B uni has a statement include C uni both files must be listed in the INF Sources section 21 March 2015 Version 1 24B EDK II INF File Specification INF Overview Specifying a file in an architectural section and in the common architecture section is prohibited a file cannot be specific to a single architecture and also be general for all architectures 2 6 BuildOptions Section Content in the BuildOptions section defines module specific tool chain flags that must be used as the default flags for a module These flags are appended to any standard flags that are defined by the build process In order to replace the standard flags that are defined by the build process an alternate assignment operator must be used is used for replacement while is used to append the flag lines Flags specified in this section can either be appended to the standard flags defined in the Conf tools_def txt or replace the standard flags In addition to flags other tool attrib
90. are defined will have a value of zero A macro defined in a section that is common to all architectures is also value for sections that have architectural modifiers It is recommended that if the tools encounter a macroval as in MACRO that is not defined the build tools must break Prototype lt MacroDefinition gt lt TS gt DEFINE lt MTS gt lt MACRO gt lt Eq gt lt Value gt lt EOL gt lt Value gt lt PATH gt lt CFlags gt lt Filename gt Parameters Path Definitions Whitespace characters are not permitted in path statements While some operating systems permit using space characters or special characters within a path element the EDK II build system will not support whitespace characters and will only permit alphanumeric characters and the dot dash underline forward and back slash characters in file names Use of and in the directory path is not permitted Use of an absolute path is not permitted It is also permitted although not specified in the EBNF for lt PATH gt to end have the path end with the file separator character as in MdePkg Version 1 24B March 2015 44 EDK II INF File Format EDK II INF File Specification Examples DEFINE TEST test DEFINE TEST1 test DEFINE TEST2 MyFile c DEFINE TEST3 TEST1 TEST2 DEFINE TEST4 TEST TEST2 DEFINE GEN_SKU MyPlatformPkg GenPei DEFIN
91. are volume on any given platform was also simplified Distributing Modules Enable easy distribution of modules both in source and binary form Individual modules may be compiled and distributed in binary form which may be integrated into a platform image or into an option ROM image 1 2 Related Information The following publications and sources of information may be useful to you or are referred to by this specification e Unified Extensible Firmware Interface Specification Version 2 5 Unified EFI Inc 2014 http www ueft org e UEFI Platform Initialization Specification Version 1 4 Unified EFI Inc 2013 http www uefi org e UEFI Platform Initialization Distribution Package Specification Version 1 0 with Errata B Unified EFI Inc 2014 http www uefi org e Intel Platform Innovation Framework for EFI Specifications Intel 2007 http www intel com technology framework e https github com tianocore tianocore github io wiki EDK II Specifications EDK II Module Writers Guide Intel 2010 EDK II User Manual Intel 2010 EDK II C Coding Standard Intel 2014 EDK II DSC Specification Intel 2015 EDK II DEC File Specification Intel 2015 EDK II FDF Specification Intel 2015 Version 1 24B March 2015 1 EDK II INF File Specification Introduction EDKII Build Specification Intel 2015 Multi String UNI File Format Specification Intel 2014 EDK II Exp
92. aries 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 Version 1 24B March 2015 101 EDK INF File Specification EDK II INF File Specification 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 S EDK_SOURCE Foundation Efi S EDK_SOURCE Foundation EDK_SOURCE Foundation Framework EDK_SOURCE Foundation Include EDK_SOURCE Foundation Efi Include EDK_SOURCE Foundation Framework Include EDK_SOURCE Foundation Include IndustryStandard EDK_SOURCE Foundation Core Dxe EDK_SOURCE Foundation Library Dxe Include A 1 5 nmake Section The optional EDK nmake section may also include a ProcessorName to res
93. attrs gt lt TS gt FixedPcd lt attrs gt Pcd lt com_pcdAttrs gt lt EOL gt common lt pcdAttrs gt lt attrs gt lt TS gt Ped lt attrs gt PcdEx lt com_pcdexAttrs gt lt EOL gt common lt pcdexAttrs gt lt attrs gt lt TS gt PcdEx lt attrs gt FeaturePcd lt com_FFArchAttrs gt lt EOL gt lt FeatureEntriesStmts gt lt FeatureEntries gt common lt FFArchAttrs gt lt attrs gt lt TS gt FeaturePcd lt attrs gt lt NUsageBlock gt lt TS gt lt PcdName gt lt FfField1 gt lt TailCmt gt lt 1UsageBlock gt lt EOL gt lt FS gt lt Boolean gt lt FfField2 gt lt FS gt lt FFE gt March 2015 Version 1 24B EDK II INF File Specification lt AsBuiltPcdSec gt lt BuiltPatchPcd gt lt com_PPArchAttrs gt lt PPArchAttrs gt lt BuiltPcdEx gt lt com_PEArchAttrs gt lt attrs gt lt PEArchAttrs gt lt AbPcdEx gt lt NUsageBlockAb gt lt HiiComment gt lt Hiilnfo gt lt ValuePcd gt lt ValUse gt lt ValueOffsetPcd gt lt valoffUse gt lt offset gt lt AsBuiltByteArray gt lt AsBuiltValue gt Version 1 24B EDK II INF File Format lt BuiltPatchPcd gt lt BuiltPcdEx gt PatchPcd lt com_PPArchAttrs gt lt EOL gt lt ValueOffsetPcd gt common lt PPArchAttrs gt lt attrs gt lt TS gt PatchPcd lt attrs gt PcdEx
94. ause 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 INF files must use the forward slash character to separate directories as well as directories from filenames Example C Work Edk2 edksetup bat File names must 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 are NOT permitted in the INF files 2 2 6 Macro Statements Use of MACRO statements in the EDK II I NF files is limited to local usage only global or external macros are not permitted This decision was made in order to support UEFI s PI Distribution Package Specification requirements Macro statements are permitted in the EDK II INF files Macro statements assign a Value to a Variable Name and are only valid during the processing of the INF specifying the value If a value is not specified then the MACRO has a value of zero Token names reserved words defined in the EDK II meta data file specifications cannot be used as macro names As an example using PLATFORM_NAME as a macro name is not permitted as it is a token defined in the DSC file s Defines section Any defined MACRO definitions will be expanded by tools when they encounter the en
95. be used to provide more selectivity of files in the component INF files If assigned then the utility will also process any files in the INF file under sections sources PROCESSOR PLATFORM includes PROCESSOR PLATFORM and libraries PROCESSOR PLATFORM As the utility processes each source file in the component INF file this symbol gets assigned the name of the file less the file extension March 2015 Version 1 24B EDK II INF File Specification Symbols Symbol Name PACKAGE L G If defined then the utility will create a package file named DEST_DIR BASE_NAME pkg and copy with macro expansion the package COMPONENT_TYPE PACKAGE section from the DSC file to the output file PACKAGE_ FILE L If defined then the utility will not generate a package file The build can then use the value PACKAGE_FILE to have GenFfsFile use an existing package file for creating the firmware file Version 1 24B March 2015 117 Symbols EDK II INF File Specification 118 March 2015 Version 1 24B EDK II INF File Specification Appendix D Sample Driver I NF Files The following INF file example are from EDK II MdeModulePkg Universal Disk Diskl oDxe Diskl oDxe inf and ntelFrameworkModulePkg Universal StatusCode RuntimeDxe StatusCodeRuntimeDxe inf driver modules Version 1 24B March 2015 119 Sample Driver INF Files EDK II INF File Specification D 1 Diskl oDxe I NF file 120 file Se Sk
96. bined with other architecture type doing so will result in a build break The use of any form of the word NULL as in Null or null as a keyword in the entries is prohibited Version 1 24B March 2015 64 EDK II INF File Format EDK II INF File Specification Prototype lt LibraryClasses gt LibraryClasses lt com_attrs gt lt EOL gt lt Statements gt lt com_attrs gt common lt attrs gt lt attrs gt lt Archs gt lt TS gt LibraryClasses lt attrs gt lt Archs gt lt arch gt lt MODULE_TYPE gt lt MODULE_TYPE gt lt ModuleType gt lt FS gt lt ModuleType gt lt ModuleType gt BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER SMM_CORE DXE_SMM_DRIVER DXE_RUNTIME_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION USER_DEFINED lt Statements gt lt SourceContent gt lt AsBuiltInfo gt lt SourceContent gt lt TS gt lt SourceStmts gt lt MacroDefinition gt lt SourceStmts gt lt RecInstanceCmt gt lt Filename gt lt EOL gt lt TS gt lt Keyword gt lt Field2 gt lt EOL gt lt RecInstanceCmt gt lt MTS gt RecommendediInstance lt MTS gt lt NoN gt A MO 2Z lt NoU gt a tv zA TV Z0 9 lt NoL gt a km zA TV 20 9 lt Keyword gt A Z a zA Z0 9 0 2 A Z a zA 20 9 4 lt NoN gt a zA Z0 9 1 A Z lt NoU gt a zA Z0 9 0 A Z a zA Z
97. block describe how the Protocol is used in the C code A binary INF file must not contain any FeatureFlagExpression content 77 March 2015 Version 1 24B EDK II INF File Specification Prototype lt Protocols gt lt com_attribs gt EDK II INF File Format Protocols lt com_attribs gt lt EOL gt lt ProtoStatments gt common lt attribs gt lt attribs gt lt attrs gt lt TS gt Protocols lt attrs gt lt attrs gt D lt arch gt lt ProtoStatements gt lt NUsageBlock gt lt TS gt lt ProtocolSpec gt lt 1UsageBlock gt lt EOL gt lt ProtocolSpec gt lt CName gt lt FS gt lt FeatureFlagExpress gt lt 1UsageBlock gt lt CommentBlock gt lt NUsageBlock gt lt CommentBlock gt lt FeatureFlagExpress gt lt Boolean gt lt CommentBlock gt lt TS gt lt UsageField gt lt TS gt lt Comment gt lt EOL gt lt UsageField gt lt TS gt lt Usage gt lt TS gt lt Notify gt lt Notify gt lt TS gt NOTIFY lt TS gt lt Usage gt PRODUCES SOMETIMES PRODUCES CONSUMES SOMETIMES CONSUMES TO_START BY_START UNDEFINED Parameters FeatureFlagExpress The feature flag expression is currently ignored by the EDK II build system l1UsageBlock and NUsageBlock The 1UsageBlock location after the entry is preferred if there is only one usage for the Protocol entry If a Protocol has multiple usages then all CommentBlock statements
98. compiled linked and what platform configuration database items PCDs are exposed Binary distribution of EDK II modules allows original device manufactures ODMs to distribute proprietary drivers without distributing source code for inclusion in a firmware image EDK II modules may be located in sub directories of a package a collection of related objects If a module is a Library creating the module directory in the Library sub directory of a package is strongly recommended An Include package subdirectory may also be required Header files for modules that define a library class must be placed in the Include Library directory using the Library Class Name for the file name The Include directory and sub directories contain header files that define either a library class API or pre defined industry standard data elements One and only one header file defines the library class API Multiple library instances can produce the functionality of a library class The use of library class API headers allows for platform integrators to select a library instance that is suitable for their platform This usage model frees the driver developer from coding a module to specific library instances Libraries are really nothing more than modules with pre defined APIs 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 con
99. ctory portion of a filename Microsoft operating systems that normally use a backslash character for separating directory names will interpret the forward slash character correctly Use of and in the directory path is not permitted Use of an absolute path is not permitted March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format CArray All C data arrays used in PCD value fields must be byte arrays The C format GUID style is a special case that is permitted in some fields that use the lt CArray gt nomenclature End of Line Characters The DOS End Of Line 0x0D 0x0A character must be used for all EDK II meta data files All Nix based tools can properly process the DOS EOL characters Microsoft based tools cannot process the Nix style EOL characters 3 2 2 MACRO Statements Use of MACRO statements is optional Summary Macro statements are characterize by a DEFINE line Macro statements in INF files are only permitted to describe a path shortcut name or used to provide a shorter text string in C Flags in the BuildOptions section If the Macro statement is within the Defines section then the Macro is common to the entire file with local definitions taking precedence if the same MACRO name is used in subsequent sections then the MACRO value is local to only that section Macro statements in comments must be ignored by parsing tools Macro statements that are referenced before they
100. d and maintain the state of the static FlashMap files with the EDK II DSC and FDF files Version 1 24B March 2015 105 EDK INF File Specification 106 Prototype lt Defines gt lt attribs gt lt attrs gt lt arch gt lt PlatformName gt lt expression gt lt Filename gt lt PathOnly gt lt MakefileType gt lt PATH gt lt Path gt lt Variable gt lt GuidOrVar gt lt EdkCompType gt EDK II INF File Specification defines lt attribs gt lt EOL gt lt expression gt lt attrs gt defines lt attrs gt D lt arch gt lt PlatformName gt IA32 x64 W IPF EBC common lt Word gt PLATFORM platform BASE NAME lt Word gt lt EOL gt COMPONENT_TYPE lt EdkCompType gt lt EOL gt FILE_ GUID lt GuidOrVar gt lt EOL gt EDK_RELEASE_VERSION 0x00020000 lt EOL gt MAKEFILE NAME lt Filename gt lt EOL gt CUSTOM MAKEFILE lt Filename gt lt EOL gt BUILD_NUMBER lt Integer gt lt EOL gt BUILD_TYPE lt MakefileType gt lt EOL gt FFS_EXT lt Word gt lt EOL gt FV_EXT lt Word gt lt EOL gt SOURCE_FV lt Word gt lt EOL gt PACKAGE CompressPEIM lt EOL gt VERSION_NUMBER lt Integer gt 1 4 lt EOL gt VERSION_STRING lt String gt lt EOL gt GENERIC_CAPSUL
101. e common architecture section must not be listed in sections that have other architecture modifiers Prototype lt Packages gt Packages lt com_attrs gt lt EOL gt lt Statements gt lt com_attrs gt common lt attrs gt lt attrs gt lt Archs gt lt TS gt Packages lt Archs gt lt Archs gt lt arch gt lt Statements gt lt MacroDefinition gt lt PkgStatements gt lt PkgStatements gt lt TS gt lt Filename gt lt Field2 gt lt EOL gt lt Field2 gt lt FS gt lt FeatureFlagExpress gt lt FeatureFlagExpress gt lt Boolean gt Parameters Filename Paths listed in the Packages section are relative to the system environment variable WORKSPACE Use of and in the directory path is not permitted The package path must be in the directory tree identified by the WORKSPACE system environment variable Use of an absolute path is prohibited FeatureFlagExpress The feature flag expression is currently ignored by the EDK II build system Example Packages MdePkg MdePkg dec MdeModulePkg MdeModulePkg dec Packages IA32 DEFINE CPUS IA32FamilyCpuPkg CPUS DualCore DualCore dec 3 8 PCD Sections The PCD sections are optional If the source module code contains any Patchable in Module or DynamicEx PCDs then this section must be generated in the As Built INF file listing each PCD with its lt CommentBlock gt content if available
102. e end of the line and may not be placed within the section tags Only gPkgTSGuid PcdFoo TRUE BOOLEAN 0x00000015 in the following example is processed by tools the remainder of the line is ignored gPkgTSGuid PcdFoo TRUE BOOLEAN 0x00000015 EFI_FOO_MEMORY Note Blank lines and lines that start with the hash character must be ignored by build 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 No Such LTD All rights reserved Comments are terminated by the end of line 11 March 2015 Version 1 24B EDK II INF File Specification INF Overview 2 2 3 Valid Entries Processing of the line is terminated if a comment is encountered Processing of a line is terminated by the end of the line Items in quotation marks are treated as a single token and have the highest precedence All expressions must be written using in fix notation operators are written between the operands Parenthesis surrounding groups of operands and operators must be used to determine the order in which operations are to be performed All other processing occurs from left to right In the following example B C is processed first then result is added to A followed by adding 2 finally 3 is added to the result A B C 2 3 In the next example A B is processed
103. e 29 2 14 PCD Setl nsaaa se ee 30 2 14 1 FIRED AT BUILD E 31 2 14 2 PATCHABLE IN MODULE 2 31 2 143 FEATURE EE 32 214 4 DYING MIG see 32 e 32 2 15 EE Eed 33 2 16 UserExtensions Section EE 34 2 16 1 UserExtensions TianoCore ExtraFiles Gechon nennen 34 Version 1 24B March 2015 9 EDK II INF File Specification 3 EDK II INF File Format E 35 3 1 General US Tee ansacaune ceeeotere 35 3 11 B ckslash 2 ee engen ger 36 3 1 2 Whilespacech araglersin are rn 36 3 1 3 Paths for File Names amp 220 ee le 36 3 2 Component INF Befinilion success lee 36 3 2 1 Common Definitions u ae a 37 3 22 MAGRO Statements reena a aaa a ke 45 3 2 3 Conditional Statements sees ee 47 3 2 4 ncludeStalement ues ee ee 47 3 2 5 Special Comment Blocks nun de 47 3 3 Header Sectio Naes iea a a a Gul devon idee a a a causes 49 3 4 Defines Setio EE 53 35 B ildOptions Secti NS EE 59 3 6 LibraryClasses Sections ee 65 3 7 Packages Sections net eek 67 3 8 SC ONS EE 68 3 9 SOUNGES EENEG Geet ine 73 3 10 Hertert 76 3 10 1 UserExtensions TianoCore ExtraFiles Gechon 77 Bl ht GE EE 78 3 12 TPIS SECU OMS Sake eege eo ata aba Ss ee ee CR ae 80 3 13 Guids Sections fale seen een eseeeaee 82 3 14 Depex Sections ee ee 85 3 15 EE e EE 90 Appendix A EDK INF File Specification unuuunnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 95 Ack REENERT 95 AAN defines e EE 95 A 1 2 sources Sec
104. e Ifthe Module is a Library with a MODULE_TYPE of BASE the generic e Depex and generic with only architectural modifier entries Le Depex 1A32 are not permitted It is permitted to have a Depex section if one ModuleType modifier is specified i e Depex common PEIM e Ifthe ModuleType is USER_DEFINED then a Depex section is optional If a PEI SMM or DXE DEPEX section is required the user must specify a ModuleType of PEIM to generate a PEI_DEPEX section a ModuleType of DXE_DRIVER to generate a DXE_DEPEX section or a ModuleType of DXE_SMM_ DRIVER to generate an SMM_DEPEX section e Ifthe ModuleType is SEC UEFI_APPLICATION UEFI_DRIVER PEI_CORE SMM _ CORE Or DXE_CORE NO Depex sections are permitted and all library class Depex sections are ignored e Module types PEIM DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SAL_DRIVER and DXE_SMM DRIVER require a Depex section The Depex section headers start with one of the following Depex Depex IA32 Depex X64 Depex IPF Depex EBC Depex common When generating the As Built binary INF during a build the complete dependency expression including dependencies from library instances will be listed in comments The following are examples of Depex section Depex TRUE m Depex IA32 DXE_DRIVER Depex IA32 DXE_RUNTIME_DRIVER gEfiPcdProtocolGuid 2 16 UserExtensions Section The EDK II UserExtensions sections allow for extending the INF with custom
105. e start of a depex listing The depex expression for a given type is terminated by the start of a new optional section tag the start of a new section or the end of file Drivers with MODULE_TYPE Set to SEC PEI_CORE DXE_CORE SMM_CORE UEFI_DRIVER and UEFI_APPLICATION cannot have Depex sections Libraries and modules that are USER_DEFINED may have a Depex section All remaining drivers PEIM DXE_DRIVER DXE_SAL DRIVER DXE_RUNTIME DRIVER and DXE_SMM DRIVER module types must have a Depex section Libraries of type SEC PEI_CORE DXE_CORE SMM_CORE and UEFI_APPLICATION are not allowed to have a Depex The MODULE_TYPE entry in the Defines section for a library only defines the module type that the build system must assume for building the library It does not define the types of modules that a library may be linked with Instead the LIBRARY_CLASS entry in the Defines section optionally lists the supported module types that the library may be linked against Libraries of type BASE are not permitted to have generic i e Depex and generic with only architectural modifier i e Depex 1A32 entries Library of type BASE are permitted to have a Depex section if one ModuleType modifier is specified i e Depex common PEIM When using the ModuleType as a section modifier for example Depex IA32 PEIM for drivers the ModuleType must match the value of MODULE_TYPE entry in the Defines section For Libraries the ModuleType used
106. e that declares the PCD The value must always match the Datum type as specified in the DEC file When specifying a value for PCD here expression or macros are not permitted only actual values are permitted UNDEFINED Typically this entry will be used when tools creating installing UEFI Distribution Packages encounter a missing or misspelled usage CONSUMES This module always gets the PCD entry This is the only usage allowed for Feature PCDs PRODUCES The module always sets the PCD entry SOMETIMES CONSUMES The module gets the PCD entry under certain conditions or execution paths SOMETIMES PRODUCES The module sets the PCD entry under certain conditions or execution paths AsBuiltByteArray A byte array containing exactly the number of bytes as specified as the maximum number of bytes in the DSC file used for the patchable in module PCD when the binary was created Any additional bytes for a value of less than the maximum number of bytes will be zero filled For example if the actual value of the array was only 4 bytes but 10 bytes were allocated during the build the tools will zero fill remaining bytes in the example 6 additional bytes of 0x00 will be added Version 1 24B March 2015 72 EDK II INF File Format EDK II INF File Specification Examples FixedPcd gEfiMdePkgTokenSpaceGuid PcdFSBClock 600000000 gEfiMdePkgTokenSpaceGuid PcdMaximumUnicodeStringLength FeaturePcd gEfiMdePkgTokenSpaceGuid PcdComponentNameDisable
107. eader file defined in the package that declares the library class 53 Refer to the EDK II Module Writer s Guide for more information about writing drivers and libraries Additionally a driver module may expose internal implementations of a library class making the internal implementations public As an example a DXE_CORE implementation that uses internal functions that provide the functionality of the EDK II Base Memory Library The DXE_CORE module that provides these functions for example DxeMain inf can expose them for use by other DXE drivers that depend on the BaseMemoryLib library class The OptionRom statements must be included for UEFI PCI Option ROMs and can only be used with a MODULE_TYPE Of UEFI_DRIVER The optional MODULE_UNI_FILE entry is used to locate an UCS 2LE format file which can be used for localization of the module s Abstract and Description from the header section The content of the file can be generated by tools during the installation of a distribution package that conforms to the UEFI Platform Initialization Distribution Packaging Specification or by module developers creating new content The FixedComments sections that follow a defines section are to permit tools to work March 2015 Version 1 24B EDK II INF File Specification with UEFI Distribution Packaging Specification requirements Version 1 24B March 2015 EDK II INF File Format 54 EDK II INF File Format Prototype EDK II INF File Sp
108. ecification Note The entry INF_VERSION BASE_NAME FILE_GUID and MODULE_TYPE are required for EDK II Modules The VERSION_STRING entry is highly recommended 55 lt Defines gt lt DefineStatements gt lt BaseName gt lt UefiHiiResource gt lt CustomMake gt lt PcdDriverType gt lt Spec gt lt LibClass gt lt KeywordType gt Defines lt EOL gt lt DefineStatements gt lt TS gt INF_VERSION lt Eq gt lt SpecVersion gt lt EOL gt lt TS gt BASE_NAME lt Eq gt lt BaseName gt lt EOL gt lt TS gt FILE_GUID lt Eq gt lt RegistryFormatGUID gt lt EOL gt lt TS gt MODULE_TYPE lt Eq gt lt Edk2ModuleType gt lt EOL gt lt TS gt UEFI_SPECIFICATION_VERSION lt Eq gt lt VersionVal gt lt EOL gt lt TS gt PI_SPECIFICATION_VERSION lt Eq gt lt VersionVal gt lt EOL gt lt TS gt LIBRARY_CLASS lt Eq gt lt LibClass gt lt EOL gt lt TS gt BUILD_NUMBER lt Eq gt lt NumValUint16 gt lt EOL gt lt TS gt VERSION_STRING lt Eq gt lt DecimalVersion gt lt EOL gt lt TS gt PCD_IS_ DRIVER lt Eq gt lt PcdDriverType gt lt EOL gt lt TS gt ENTRY_POINT lt Eq gt lt CName gt lt FFE gt lt EOL gt lt TS gt UNLOAD_IMAGE lt Eq gt lt CName gt lt FFE gt lt EOL gt lt TS gt CONSTRUCTOR lt Eq gt lt CName gt lt FFE gt lt EOL gt lt TS gt DESTRUCTOR lt Eq gt lt CName gt lt FFE gt lt EOL gt lt TS
109. ed for specifying a Depex expression not a binary file In the As Built INF files this section contains a comment that lists the full dependency expression including Depex statements AND d from library instances linked against a module Binary depex files are listed in Binaries sections of the INF files Having a common Depex section and architectural Depex sections is prohibited Having multiple module type modifiers for common and architectural sections is permitted For example Depex common DXE_DRIVER Depex common DXE_RUNTIME_DRIVER is valid This section can be used with an inheritance from libraries by supporting logical AND ing of the different Depex expressions together Since more than one type of dependency expression may be required for modules DXE SMM modules as well as components of type COMBINED_PEIM_DRIVER not supported by the EDK II build system section modifier tags have been defined For module types that prohibit the use of a Depex section all Depex sections from library instances must be ignored These are only required if more than one dependency expression is required for a module The format of the depex section tag is Depex lt Arch gt lt ModuleType gt Additionally the rules for specifying DEPEX sections are as follows e Ifthe Module is a Library then a Depex section is optional March 2015 Version 1 24B EDK II INF File Specification INF Overview
110. ed in the tools_def txt file for individual tools EXCEPTION If the INF MODULE_TYPE defined in the Defines section is USER_DEFINED then the flags listed in this section are the only flags used for the TOOLCODE command specified in Conf tools_def txt The attribute must be specific to the tool code and must be a valid attribute handled by the build system Note Regarding the EDK and EDK II distinctions in the table Many EDK INF files must be processed by the EDK II build system but no EDK INF specification exists Therefore items of this kind are listed in Appendix A for completeness This limits what can be in an EDK INF file as well Developers should use extreme caution when specifying items in this section The EDK II build is designed to support multiple compilers and tool chains expecting that code is written in ANSI C If custom tool flags are required by a module developers must make sure that all consumers of the module are aware of the specific tools and tag names required 23 March 2015 Version 1 24B EDK II INF File Specification INF Overview Note The lines are shown with the backslash character to indicate a line continuation they are not allowed in the actual INF file BuildOptions common MSFT DEBUG_ _IA32_DLINK_FLAGS out BIN_DIR SecMain exe base 0x10000000 pdb BIN_DIR SecMain pdb LIBPATH VCINSTALLDIR Lib LIBPATH VCINSTALLDIR PlatformSdk Lib NOLOG
111. ed up by tools from the DEC files and the PCD s C name that must be specified in the DEC files to limit accidental duplicate PCD C Name collisions A default value that the module developer suggests to use for the PCD is optional TokenSpaceGuidCName PcdCName Values of PCDs defined in this file override the default values specified in the EDK II package declaration DEC file The platform integrator can specify values in the DSC and FDF files that will override any settings in this file If a default value is not specified the build system will use 1 values from the FDF file 2 values from the DSC file or 3 values from the DEC file Expressions or Feature Flag Expressions may be used on PCD entry lines If there are files listed in a Binaries section and this is a PatchPed section and the third field of an entry is a Hex number 0x00000012 then the value is an offset into a binary image The format for this type of entry is PcdName Value HexValue For all other instances the format for this type of entry is PcdName Value FeatureFlagExpression When a FeatureFlagExpression is present if the expression evaluates to TRUE then the PCD entry is valid If the expression evaluates to FALSE then the EDK II build tools must ignore the entry 2 14 1 FIXED AT BUILD 31 The content for the PCD entry is the PCD s Name PCD s Token Space Guid C name followed by a period character then the PCD s C name and an
112. eloper creating a new EDK component or library information INF file This is an optional section Version 1 24B March 2015 103 EDK INF File Specification EDK II INF File Specification Prototype lt Header gt e no l lt EOL gt lt Copyright gt lt License gt lt ModuleName gt lt Abstract gt W T lt EOL gt lt Abstract gt re Abstract lt EOL gt lt Sentence gt lt EOL gt HM n lt EOL gt lt ModuleName gt Module Name lt EOL gt L lt Sentence gt lt EOL gt un n lt EOL gt lt Copyright gt Copyright c lt Date gt lt CompExtra gt lt EOL gt HM n lt EOL gt lt License gt lt LicenseSentence gt lt EOL gt HM n lt EOL gt Example i be 3E E GR OSE OE RHR 104 Copyright c 2004 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 Module Name EdkFrameworkPr
113. en the module will use this protocol named by GUID via a registry protocol notify mechanism Example protocols gEfiDecompressProtocolGuid gEfiLoadFileProtocolGuid 3 12 Ppis Sections These are optional sections If the source module code contains any PPIs then this section must be generated in the As Built INF file listing each PPI with its lt CommentBlock gt content Summary Defines the EDK II INF file PPIs section content This is a list of the global PPI C Names that are referenced in the EDK II Module s C code Each PPI must be listed only once per section PPIs listed in architectural sections are not permitted to be listed in the common architectural section The common architecture modifier in a section tag must not be combined with other architecture type doing so will result in a build break The format of the lt commentBlock gt is the recommended format that will guarantee that the information is correctly inserted into UEFI Distribution Package description files by the Intel UEFI Packaging Tool included in the EDK II base tools project The usages in the comment block describe how the PPI is used in the C code A binary INF file must not contain any FeatureFlagExpression content 79 March 2015 Version 1 24B EDK II INF File Specification Prototype lt Ppis gt lt com_attribs gt EDK II INF File Format Ppis lt com_attribs gt lt EOL gt lt PpiStatements gt common lt att
114. exSection gt lt DxeDepex gt lt DxeDepexStatements gt lt PeiDepex gt lt PeiDepexStatements gt lt SmmDepex gt lt GuidStmt gt lt DepInstruct gt lt SorStmt gt lt BoolStmt gt lt Bool gt lt GuidCName gt lt NTs gt Depex lt com_attribs gt lt EOL gt lt DepexSection gt lt AsBuiltDepex gt common lt attribs gt lt attrs gt lt TS gt Depex lt attrs gt lt arch gt lt Module gt lt DepexModuleType gt PEIM DXE_DRIVER DXE_SMM_DRIVER DXE_RUNTIME_DRIVER DXE_SAL_DRIVER UEFI_DRIVER USER_DEFINED lt PeiDepex gt lt SmmDepex gt lt DxeDepex gt lt DxeDepexStatements gt END lt EOL gt lt SorStmt gt lt GuidStmt gt lt BoolStmt gt lt PeiDepexStatements gt END lt EOL gt lt BoolStmt gt lt DepInstruct gt lt DxeDepex gt BEFORE AFTER lt GuidCName gt lt EOL gt PUSH lt CFormatGUID gt lt EOL gt SOR lt BoolStmt gt lt EOL gt lt Bool gt lt BoolExpress gt TRUE FALSE lt GuidCName gt lt EOL gt lt CName gt A Guid C Name NOT lt TS gt March 2015 Version 1 24B EDK II INF File Specification lt BoolExpress gt lt BoolExpressCont gt lt AsBuiltDepex gt lt FullDxe gt lt DxeStatements gt lt FullPei gt lt PeiStatements gt lt FullSmm gt lt GuidAbStmt gt lt DepAbInstruct gt lt SorAbStmt
115. f MODULE_TYPE PEI_CORE MODULE_TYPE DXE_CORE MODULE_TYPE SMM CORE MODULE_TYPE UEFI_APPLCIATION Do not specify a depex section lt UserExtensions gt 3 2 1 Common Definitions Summary The following are common definitions used by multiple section types 37 March 2015 Version 1 24B EDK II INF File Specification Prototype lt Word gt lt SimpleWord gt lt ToolWord gt lt FileSep gt lt Extension gt lt File gt lt PATH gt lt RelativePath gt lt DirName gt lt FullFilename gt lt Filename gt lt Chars gt lt Digit gt lt NonDigit gt lt Identifier gt lt CName gt lt AsciiChars gt lt CChars gt lt Db1Quote gt Version 1 24B EDK II INF File Format a zA Z0 9_ a zA Z0 9 _ Alphanumeric characters with optional period dash and or underscore _ characters A period character may not be followed by another period character No whitespace characters are permitted a zA Z0 9 a zA Z0 9_ A word that cannot contain a period character A Z a zA Z0 9 A word that must start with a capital letter and is allowed to contain additional alphanumeric characters Whitespace characters are not permitted wym a zA Z0 9_ One or more alphanumeric characters lt Word gt lt Extension gt lt MACROVAL gt lt FileSep gt lt RelativePath gt lt Word gt lt FileSep gt lt DirName gt lt Word gt l
116. f the file has changed for EDK II builds which generate processed GenFw images An ACPI Table 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 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 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 March 2015 Version 1 24B EDK II INF File Specification PEI_CORE COMBINED_PEIM_ DRI VER PIC_PEIM RELOCATABLE_PEIM PE32_PEIM BS_DRIVER RT_DRIVER SAL_RT_DRIVER BS_DRIVER Version 1 24B ef ef ef ef ef ef ef ef ef PEI PEI PEI PEI PEI DXE DXE DXE SMM March 2015 EDK IN
117. false False 0x0 0x00 0 lt TRUE gt lt FALSE gt A Z A Z0 9_ CR lt MACRO gt y lt TokenSpaceGuidCName gt lt PcdCName gt lt CName gt lt CName gt Ox OX x0 xFF Ox OX x0 xFFFF Ox OX xO xFFFFFFFF Ox OX x0 xFFFFFFFFFFFFFFFF 0x 0X lt HexDigit gt lt HexDigit gt March 2015 Version 1 24B EDK II INF File Specification lt UINT16z gt lt UINT32z gt lt UINT64z gt lt ShortNum gt lt IntNum gt lt LongNum gt lt LongLongNum gt lt NumValUint8 gt lt NumValUint16 gt lt NumValUint32 gt lt NumValUint 64 gt lt ModuleType gt lt ModuleTypeList gt lt IdentifierName gt lt Boolean gt lt EOL gt lt OA gt lt arch gt lt Edk2ModuleType gt Version 1 24B EDK II INF File Format Ox 0X lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt Ox 0X lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt Ox 0X lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt lt HexDigit gt 0 255 0 65535 0 4294967295 0 18446744073709551615 lt ShortNum gt lt UINT8
118. figuration Database PEI Pre EFI Initialization Phase PEI M An API named by a GUID Version 1 24B March 2015 Introduction EDK II INF File Specification PPI A PEIM to PEIM Interface that is named by a GUID Protocol An API 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 tanium 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 SKU Stock Keeping Unit SMM System Management Mode A generic term for the execution mode entered when a CPU detects an SMI The firmware in response to the interrupt type will gain control in physical mode For this document SMM describes the operational regime for IA32 and x64 processors that share the OS transparent characteristics 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 succes
119. file Each file is added to the macro of INC_DEPS which can be used in a makefile dependency expression Binary files must not be listed in this section EDK II INF files may have a Binaries section defined that must be used to define the type and name of the binary files provided by a module This section is optional If it is present and files are listed in this section then the build tools must process the files for AutoGen as well as Makefile generation If this section is not present then the build tools may assume that the binary files listed in the Binaries section have already been processed by the first build step no AutoGen or Makefiles need to be generated If both Sources and Binaries sections are specified the build tools assume that the code provided in the sources section must be built and that the binary files provided are also required for the final image generation process steps Files listed in architectural specific sections must not be listed in common architecture Sources sections The architectural modifier is used to specify additional files that are required over and above the non architectural specific content During builds files are grouped by tools using the common and architecturally specified sections This section will typically use one of the following section definitions Sources Sources common Sources IA32 Sources X64 Sources IPF Sources EBC The formats for entries in this section
120. form integrator in a platform description DSC file The common architecture modifier in a section tag must not be combined with other architecture type doing so will result in a build break It is not permissible to list a PCD name in different PCD type sections Listing a PCD indicates what library function is used to access a PCD only one type of access is permitted for a specified PCD A generated As Built INF file must not contain any FeatureFlagExpression content Version 1 24B March 2015 68 EDK II INF File Format 69 Prototype lt Pcds gt lt SrcPcdSec gt lt PcdEntriesStmts gt lt Patch gt lt com_patchAttrs gt lt patchAttrs gt lt Fixed gt lt com_fixedAttrs gt lt fixedAttrs gt lt Dyn gt lt com_pcdAttrs gt lt pcdAttrs gt lt DynEx gt lt com_pcdexAttrs gt lt pcdexAttrs gt lt FeaturePcd gt lt FeatureEntriesStmts gt lt com_FFArchAttrs gt lt FFArchAttrs gt lt FeatureEntries gt lt TailCmt gt lt FfFieldli gt lt FfField2 gt EDK II INF File Specification lt AsBuiltPcdSec gt lt SrcPcdSec gt lt FeaturePcd gt lt Patch gt lt Fixed gt lt Dyn gt lt DynEx gt lt PcdEntriesStmts gt lt PcdEntries gt PatchPcd lt com_patchAttrs gt lt EOL gt common lt patchAttrs gt lt attrs gt lt TS gt PatchPcd lt attrs gt FixedPcd lt com_fixedAttrs gt lt EOL gt common lt fixedAttrs gt lt
121. gt lt IntNum gt lt UINT16 gt lt LongNum gt lt UINT32 gt lt LongLongNum gt lt UINT64 gt BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER SMM_CORE DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER UEFI_DRIVER UEFI_APPLICATION USER_DEFINED lt ModuleType gt lt ModuleType gt lt TS gt lt MACROVAL gt lt PcdName gt lt TS gt lt BoolType gt lt Expression gt lt TS gt 0x0D Ox0A a zA Z a zA Z0 9 IA32 X64 IPF EBC lt OA gt BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_SAL_DRIVER March 2015 42 EDK II INF File Format EDK II INF File Specification Note Note Note 43 DXE_RUNTIME_ DRIVER SMM_CORE DXE_SMM DRIVER UEFI_DRIVER UEFI_APPLICATION When using the characters or in an expression the expression must be encapsulated in open and close parenthesis Comments may appear anywhere within a INF file provided they follow the rules that a comment may not be enclosed within Section headers and that in line comments must appear atthe end of a statement Parameters At this time expressions are not supported in INF files Expression Expression syntax is defined the EDK II Expression Syntax Specification Unicode String When the lt UnicodeString gt element these characters are string literals as defined by the C99 specificati
122. ication function and calls the function when it is signaled PRODUCES A module will always signal the event SOMETIMES PRODUCES A module will sometimes signal the event Boot Mode Usage CONSUMES The module always supports the given boot mode SOMETIMES CONSUMES The module may support a given boot mode on some execution paths PRODUCES The module will change the boot mode SOMETIMES PRODUCES The module will change the boot mode on some execution paths Hob Usage CONSUMES The HOB must be present in the system SOMETIMES CONSUMES If present the HOB will be used Version 1 24B March 2015 48 EDK II INF File Format EDK II INF File Specification PRODUCES A module will always produce the HOB SOMETIMES PRODUCES The HOB may be produced by the module under some execution paths Usage Keywords are UNDEFINED CONSUMES SOMETIMES CONSUMES PRODUCES and SOMETIMES PRODUCES 3 3 Header Section This is an optional section while this header section is not needed by the EDK II build system it will be used by the build tools for generating As Built INF files from sources This section is also used by the Intel UEFI Packaging Tool that is included with the EDK II build system binaries 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 Abstract Description Copyright License
123. icrosoft Linker lib exe March 2015 Version 1 24B EDK II INF File Specification EDK INF File Specification Example nmake common C_STD_INCLUDE IMAGE_ENTRY_POINT WatchdogTimerDriverlInitialize DPX_SOURCE WatchDogTimer dxs nmake common C_FLAGS C_FLAGS D EDKII_GLUE_LIBRARY_IMPLEMENTATION LIB_STD_FLAGS LIB_STD_FLAGS IGNORE 4006 IGNORE 4221 nmake ia32 C_FLAGS C_FLAGS D MDE_CPU_IA32 nmake x64 C_FLAGS C_FLAGS D MDE_CPU_X64 nmake ipf C_FLAGS C_FLAGS D MDE CPU PF nmake ebc EBC_C_STD_FLAGS EBC_C_STD_FLAGS D EDKII_GLUE_LIBRARY_IMPLEMENTATION EBC_LIB_STD_FLAGS EBC_LIB_STD_FLAGS IGNORE 4006 IGNORE 4221 EBC_C_STD_FLAGS EBC_C_STD_FLAGS D MDE_CPU_EBC A 2 6 sources Section Summary Defines the sources section tag is required for EDK INF files NOTE EDK uses both source and sources in the section header There can be multiple sources sections depending on the target processor Example sources sections are listed below The parsing utility creates a directory path for each file DEST_DIR MyFile c and looks up the makefile template for the COMPONENT_TYPE EDK to emit It is not permissible to mix EDK and EDK II style files within a module The macro TABLE_NAME may be used in existing EDK I NF files that point to ACPI tables this value wil be ignored by EDK II build tools Version
124. in this section that was associated with EDK libraries and components The section now lists only the defined EDK II symbols and format Note Possible values for MODULE_TYPE and their descriptions are listed in the table EDK II Module Types For each module the BASE_NAME and MODULE_TYPE are required The BASE_NAME definition is case sensitive as it will be used to create a directory name during a build Unlike EDK only the Defines section tag is valid for EDK II INF files architectural modifiers for the Defines section tag are not permitted The section is processed in order by the parsing utilities Assignments of variables in other sections override previous assignments The SHADOW keyword is only valid for SEC PEI_CORE and PEIM module types It is an error to declare the SHADOW keyword in other module types The default value of SHADOW is FALSE when the SHADOW keyword is not specified EDK II modules that provide different library class implementations must use multiple LIBRARY_CLASS statements Each LIBRARY_CLASS statement must provide the name of the library class supported followed by the pipe field separator and then a space delimited list of module types the library instances supports The following is an example of specifying multiple library classes LIBRARY_CLASS FOO PEI_CORE PEIM LIBRARY_CLASS BAR DXE_CORE DXE_DRIVER DXE_SMM_DRIVER Note Each library class requires a h
125. intel EDK II Module Information I NF File Specification March 2015 Revision 1 24 w Errata B EDK II INF File Specification 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 sho
126. ion Package Specification Standardize Common data definitions for all specifications Grammatical formatting and spelling changes Replaced should with wording saying that it is recommended Added PCI_COMPRESS definition in Defines section Added the DPX_SOURCE statement back into the Defines section Added VALID_ ARCHITECTURES comment definition back to the Defines section to formalize this comment which may be used by tools This had been removed from the 1 22 spec as it was assumed that tools could determine valid architectures other than ALL architectures by the use of architectural modifiers in section tags Removed restriction about comments in the DPX_SOURCE file C style comments are allowed Updated DEPEX content for USER_DEFINED module types Removed EDK content from EBNF in Chapter 3 as this chapter only describes the content for EDK II INF files for clarity moved EDK content from descriptions in Chapter 2 to Appendix A Added EBNF for lt Extension gt Added rules for how macros can be shared between sections Update the EBNF for paths so that a macro can have a path that does not end with a file separator also allow using a path and filename as a macro value clarify that macros are only expanded in the EDK II INF files never evaluated during the initial parsing of the file Removed duplicate content and added the scoping rules for Macros clarified MACRO summary made the value optional so that
127. ional portion of the value is the considered the minor number changing anytime there is a change in the code that would result in a binary image that was not identical to the binary image created prior to the change BuildNumber The optional build number must be NumValUint16 If not present the EDK II build tools will use the BUILD_NUMBER from the DSC file If the DSC file does not include the build number the EDK II build tools will use a value of 0 If the Build number is greater than 0 the generated INF file must contain this entry Spec The user is required to ensure that a valid C name is used for the name of the specification and provide the decimal version of the specification For example SPEC USB_SPECIFICATION_VERSION 2 0 is a valid statement These statements are used to generate define statements in the auto generated C files UefiHiiResource This is an optional tag used to identify UEFI compliant drivers that must have a UEFI_HII_RESOURCE_SECTION generated as part of the efi image file If not specified the default is false DPX_SOURCE The path and filename must be relative to the INF file and located within the module s directory tree The file must contain only DEPEX statements as defined in the UEFI PI Specification that are valid for the module type C style Comments are not in the file Contents of this file completely override any dependency expressions listed in Depex sections and all inherited dependenc
128. irectory then the relative to the INF file path must be included as part of the file name The first field is the FileType which will let a platform integrator know the provided file s format while the last three fields are optional Three defined targets NOOPT DEBUG and RELEASE are provided as part of the EDK II build environment The wildcard character is permitted in the fields Additional information such as what flags were used during the build can also be added in the comments preceding an entry or in an in line comment that follows the entry Version 1 24B March 2015 24 INF Overview EDK II INF File Specification 25 Files listed in this section do not require generation of AutoGen or Makefiles during the pre processing build steps It is prohibited to list a file in the common architectural section and also in a specific architectural section Binary files can be common to all architectures or specific to individual architectures not both The architectural section modifier is used as a restriction to mask binaries from target architectures that are not applicable During a build the tools will group binaries in listed in the common sections with the binaries listed for the architecture needed by the build This section uses one of the following section definitions Binaries Binaries common Binaries IA32 Binaries X64 Binaries IPF Binaries ERC The formats for entries in this section are FileType Relati
129. is 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 GUID also refers to an API named by a GUID 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 3 March 2015 Version 1 24B EDK II INF File Specification Introduction HOB Hand off blocks are key architectural mechanisms that are used to hand off system information in the early pre boot stages IER Internal Forms Representation This is the binary encoding that is used for the representation of user interface pages INF EDK II Module Information File This file describes how the module is coded For EDK this file describes how the component or library is coded as well as providing some basic build information 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 See the EDK 2 0 Module Development Environment Library Specification for some example library classes Library Instance An implementation of one or more library classes See the EDK 2 0 Module Development Environment Library Specification for a list of sample library instances Module
130. isables checking The UEFI_SPECIFICATION_VERSI ON must only be set in the I NF file if the module depends on UEFI Boot Services or UEFI Runtime Services or UEFI System Table fields or UEFI core behaviors that are not present in the UEFI 2 1 version For example if a module depends on definitions in UEFI 2 2 that are not in UEFI 2 1 then UEFI_SPECIFICATION_VERSI ON must be 0x00020014 Registry 8 4 4 4 12 Format This value is required for all EDK II format INF files required for EDK driver INF files not required for EDK libraries This is the type of module One of the EDK II Module Types For Library Modules the MODULE_TYPE must specify the MODULE_TYPE of the module that will use the driver This optional element if present or set in the DSC file is used during the creation of the EFI_VERSION_SECTION for this module if it is not present then the BuildNumber field of the EFI_VERSION_SECTION will be set to 0 If present this value will be used to generate the UCS 2LE encoded file for the VERSION section of the FFS unless a ver or ver_ui file has been specified in the Binaries section A UCS 2LE encoded file containing localization strings the file path if present is relative to the directory containing the INF file Version 1 24B March 2015 18 INF Overview Tag LIBRARY_CLASS PCD_IS_DRIVER ENTRY_POINT UNLOAD_IMAGE CONSTRUCTOR DESTRUCTOR SHADOW Required Typically
131. l used to generate compression sections as well as the library needed to uncompress an image in the firmware volume VFR The VER file compiler which creates IFR code VFRPP The C pre processor used to process VFR files Attribute Flags 63 A keyword to uniquely identify a property of the command the fifth and last field Several pre defined attributes have been defined DLL FAMILY FLAGS GUID OUTPUT and PATH Use quotation marks if and only if the quotation marks must be included in the flag string The following example shows the format for the required quoted string C Program Files Intel EBC Lib EbcLib 1lib Normally the quotation characters are not required as everything following the equal sign to the end of the line is used for the flag Must be a valid string for the tool specified The string will be appended to the end of the tool s flags from the tools_def txt Both Microsoft and GCC evaluate options from left to right on the command line This allows disabling some flags that may have been specified in the tools_def txt by providing an alternate flag i e if the tools_def CC FLAGS defines O2 and an O1 options is specified for this module the module will compile with O1 size not with O2 speed Space characters are allowed Macros are also permitted to be used in Flag strings March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format Example BuildOptions common DEFINE MACR
132. lag string can be extended to a new comment line without using the line extension character Tools that create As Built information must expand any macro values used by the tools during the module build The standard Macro Definitions are not permitted within this section for an As Built INF file Build options listed in architectural sections will be appended to build options listed in the common architectural section Comments in this section must appear on a separate line they may not be appended after statements The common architecture modifier in a section tag must not be combined with other architecture type doing so will result in a build break March 2015 Version 1 24B EDK II INF File Specification Prototype lt BuildOptions gt lt com_attrs gt lt attrs gt lt Archs gt lt BuildStmts gt lt AsBuiltStmts gt lt AsBuiltFfe gt lt CFlagsContd gt lt BuildOptStmts gt lt FamId gt lt FlagExpr gt lt PathExpr gt lt CmdExpr gt lt Other gt lt OtherTool gt lt Family gt lt Usr gt lt Equal gt lt AppendEq gt lt ReplaceEq gt lt ToolSpec gt lt ToolFlags gt lt ToolPath gt Version 1 24B EDK II INF File Format BuildOptions lt com_attrs gt lt EOL gt lt BuildStmts gt common lt attrs gt lt Archs gt lt TS gt BuildOptions lt attrs gt D lt arch gt lt BuildOptStmts gt lt AsBuiltStmts gt lt TS gt lt T
133. lization Distribution Package Specification Description A detailed description of what the module does BinaryDescription A detailed description of what the module does that may be different from a source abstract e If this line is present the tools will use this line when generating the binary As Built INF e If the Doxygen tag is not present the tools will use the primary Description from the Source INF file when generating a binary As Built INF e Inthe binary As Built INF the Doxygen tag must not be present e The INF file will always have an English version of the Description Other localized versions of the description will be stored in the UCS 2LE encoded file specified in the Defines section s MODULE_UNI_ FILE Note This file permits the Intel UEFI Packaging Tool to process localized module content described in the UEFI Platform Initialization Distribution Package Specification Copyright The copyright date should be modified if there is a functional change to the source code Since binaries are constructed from source the binary file uses the same copyright date as the source INF Copyright data will not be localized License One or more licenses that the module with source code is released under License content will not be localized 51 March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format BinaryLicense One or more licenses that the binary module is released under that may
134. ls_def txt file The tool chain tag name must also match the one used for the build Target A keyword that uniquely identifies the build target This keyword is used to bind command flags to individual commands Refer to the Build Specification for the exact format ofthe tools_def txt file The tools_def txt file defines a label to specify different items such as executables options and locations The label is broken up into fields which are separated by an underscore character The Target must be either a wildcard character meaning all targets or it must be specified in the first field of at least one ofthese labels Three values NOOPT DEBUG and RELEASE have been pre defined Users may wantto add other definitions such as PERF SIZE or SPEED and define their own set of FLAGS to use with these tags TagName TagNames must also appear in at least one Label specified in the tools_def txt file The TagName must be either a wildcard character meaning any TagName or it must match a defined value for a TagName label in the tools_def txt file for the tool chain tag name specified Family is keyword that uniquely identifies a tool chain family The Family must be either a wildcard character meaning any Family or it must match a defined value for a Family label in the tools_def txt file for at least one tool chain TagName specified in tools_def txt or the TagName field that follows this field in the entry M
135. 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 This module type is used by UEFI Drivers that are compliant with the EFI 1 10 Specification or the UEFI 2 x Specification These modules provide services in the boot services execution environment UEFI Drivers that return EFl_ SUCCESS are not unloaded from memory UEFI Drivers that return an error are unloaded from memory This module type is used by UEFI Applications that are compliant with the EFI 1 10 Specification or the UEFI 2 x Specification UEFI Applications are always unloaded when they exit User defined extension This is the compiled dependency section for SMM PEIM or DXE modules A dependency section may also be generated from a dependency source dxs file if specified in the Sources section This is a processed User Interface section 141 Module Types EDK II INF File Specification FILE TYPE MODULE_ TYPE EDK II Description Extension EFI Version Section Any the code for these ver This is a processed Version sections is included as section part of any module and no separate INF is required This following table shows the mapping of EDK II Module Types to EDK Component Types Table 10
136. mplementation of the UEFI Specification Version 1 24B March 2015 6 Introduction EDK II INF File Specification 1 5 3 Typographic Conventions This document uses the typographic and illustrative conventions described below Typographic Convention Plain text Plain text blue Typographic convention description 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 cross reference Click on the word to follow the hyper link Bold Italic 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 BOLD Monospace Bold Monospace VAR 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 ina Bold Monospace typeface that is underlined and in blue indicate an active hyper link to the code definition for that function or type definition Click on the word to follow the hyper link This symbol VAR defined by the utility or input files Note Italic Mon
137. nd are never destroyed This means the services that these modules produce are available after ExitBootServices 99 EDK INF File Specification EDK II INF File Specification 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 ui ui INTERFACE 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 Dxelpl h DxeLoad c sources la32 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
138. ns will be combined by tools with the second section s content appended to the section content that was first in the file e Sections with architectural modifiers are appended by tools to section content with either the common or no architectural modifiers if it exists The combined result is then considered a complete section 3 1 1 Backslash The backslash character in this document is only for lines that cannot be displayed within the margins of this document The backslash character must not be used to extend a line over multiple lines in the INF file 3 1 2 Whitespace characters Whitespace space and tab 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 3 1 3 Paths for File Names Note that for specifying the path for a file name if the path value starts with a dollar sign character a local MACRO variable is being specified White space characters are not permitted in path names Note The use oft and in a path element is prohibited For all EDK II INF files the directory path must use the forward slash character for separating directories For example MdePkg Include should be specified Unless otherwise noted all file names and paths must be relative to the directory where the INF file is located 3 2 Component I NF
139. o this method is to simply create a new INF file for the library and then use it in place of the existing library INF file B 3 Customizing EDK II Compilation for a Module Common Definitions The preferred method for customizing a build is to copy the source module directory to a new directory and modifying the INF file and module sources This method is preferred over the EDK methods as build reproducibility is more easily accomplished Additional customizations for build options should be made in the platform description DSC file While it is permitted to use the BuildOptions section to define custom compiler flags this section should only be used as a last resort The default flags Version 1 24B March 2015 113 Build Changes and Customizations EDK II INF File Specification defined the tools_def txt file provide the best known size and speed optimizations and the platform DSC file can override the defaults in its BuildOptions section 114 March 2015 Version 1 24B EDK II INF File Specification Appendix C Symbols One of the core concepts of this utility is the notion of symbols Use of symbols follows the makefile convention of enclosing within for example EDK_SOURCE As the utility processes files during execution it will often perform parsing of variable assignments These variables can then be referenced in other sections of the DSC file Variable assignments will be saved internally in either a local or global symbol
140. oGen c file PPIs listed in architectural sections must not be listed in common Ppis sections The architectural section modifier is used as a restriction to mask items from architectures that are not applicable March 2015 Version 1 24B EDK II INF File Specification INF Overview This section uses one of the following section definitions Ppis Ppis common Ppis IA32 Ppis X64 Ppis IPF Ppis EBC The formats for entries in this section is gEfiPpiCName The following is an example of the Ppis section Ppis gEfiPeiMemoryDiscoveredPpiGuid gEfiFindFvPpiGuid 2 11 Guids Section The Guids section of the EDK II INF file is a list of the global GUID C Names that are used by the module and not already included These C names are used by the parsing routine to lookup the actual GUID value that is located in the EDK II package DEC files and then emit a data structure to the module s AutoGen c file GUID C names listed in architectural sections must not be listed in common Guids sections The architectural section modifier is used as a restriction to mask items from architectures that are not applicable This section uses one of the following section definitions Guids Guids common Guids IA32 Guids X64 Guids IPF Guids EBC The formats for entries in this section is gEfiGuidCName Usage comment The following is an example of the Guids section Guids gEfiDebugImageInfoTable gEfiHobMemoryAllocModuleGuid
141. ollowing format to identify the named PCD PcdTokenSpaceGuidCName PcdCName PCDs listed in architectural sections must not be listed in common architectural sections It is not possible for a PCD to be valid for only IA32 and also valid for any architecture A PCD may be valid for IA32 and X64 and invalid for EBC and IPF usage so mixing of specific architectural modifiers is permitted This section defines how a module has been coded to access a PCD A PCD can only be accessed using the function defined by the UEFI specification for a single type therefore mixing PCD section types is not permitted There are five defined PCD types Do not confuse these types with the data types of the PCDs The five types are FeaturePcd in code identified as FEATURE_FLAG FixedPcd FIXED_AT_BUILD PatchPcd PATCHABLE_IN_MODULE and two dynamic types of PCDs Pcd DYNAMIC and PcdEx DYNAMIC_EX The two recommended types that are commonly used in modules are Feature PCD and the dynamic PCD form The PCD is used for configuration when the PCD value is produced and consumed by drivers during execution the value may be user configurable from setup or the value is produced by the platform in a specified area It is associated with modules that are released in source code The dynamic form is the most flexible method as platform integrators may chose a to use a different type such as fixed for a given platform without modifying the module s I NF file
142. on L string not actual Unicode characters is included in a value the build tools may be required to expand the ASCII string between the quotation marks into a valid UCS 2LE encoded string The build tools parser must treat all content between the field separators excluding white space characters around the field separators as ASCII literal content when generating the AutoGen c and AutoGen h files Comments CFlags Strings that appear in comments may be ignored by the build tools An ASCII string matching the format of the ASCII string defined by lt UnicodeString gt L Foo for example that appears in a comment must never be expanded by any tool 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 tool MACRO values that appear in quoted strings in CFlags content must not be expanded by parsing tools OA Other Architecture One or more user defined target architectures such as ARM or PPC The architectures listed here must have a corresponding entry in the EDK II meta data file Conf tools_def txt Only IA32 X64 IPF and EBC are routinely validated ExtendedLine The use of the Extended Line format is prohibited FileSep FileSep refers to either the backslash or forward slash characters that are used to separate directory names All EDK II INF files must use the forward slash character when specifying the dire
143. on 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 Any comment not associated with a defined comment format is considered a global comment e Global comments must be separated from formatted comments by a blank line Field separators for lines that contain more than one field is the pipe character 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 Note 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 was used to uniquely identify the PCD Aline terminates with either an end of line character or a comment e Except for binary As Built INF files generated by the tools when processing numeric values either integer or hex leading zeros specified in the entry may be ignored For example 0x00000000000000000000001 can be a valid value for a UINTS data type as the actual value is 1 The generated binary As Built INF file must use zero byte filled in order to specify a the length of a vorp PCD value Version 1 24B March 2015 35 EDK II INF File Specification EDK II INF File Format e Sections with duplicate tags such as two section tags BuildOptio
144. optional Default value These fields are separated by the pipe character If a module is coded for only FIXED_AT_BUILD PCDs it can only be used during a build from source files This section must not be present in an INF file that describes a binary only module This section uses one of the following section definitions FixedPcd FixedPcd common FixedPcd IA32 FixedPcd X64 FixedPcd IPF FixedPcd EBC gEfiMdePkgTokenSpaceGuid PcdFSBClock 600000000 The following is an example of the PCD FIXED_AT_ BUILD type March 2015 Version 1 24B EDK II INF File Specification INF Overview FixedPcd common gEfiEdkModulePkgTokenSpaceGuid PcdMaxSizeNonPopulateCapsule gEfiEdkModulePkgTokenSpaceGuid PcdMaxSizePopulateCapsule 2 14 2 PATCHABLE_IN_MODULE The PCD entry content is the PCD s Name PCD s Token Space Guid C name followed by a period and the PCD s C name and an optional Default value This section may be present in INF files that describe a binary only module This type of PCD is one of the recommended formats for modules that will be distributed in binary format These fields are separated by the pipe character This section uses one of the following section definitions PatchPcd PatchPcd IA32 PatchPcd X64 PatchPcd IPF PatchPcd EBC PatchPcd common The following is an example of the PCD FIXED_AT_BUILD type PatchPcd common gEfiGenericPlatformTokenSpaceGuid PcdFlashNvStorageVariableSize gEfiGenericPlatf
145. or the UEFI 2 3 1 specification is the hex value 0x0002001F The minor number of the specification version is a 2 digit number where the 2 3 1 is actually 2 31 The major number must be incremented on a revision that would result in a minor number greater than 99 PI_SPECIFICATION_VERSION Version 1 24B The PI_SPECIFICATION_VERSION must only be set in the INF file if the module depends on services or system table fields or Pl core behaviors that are not present in the PI 1 0 version The version number for the 1 2 PI specification is the hex value 0x00010014 The minor number of the specification version is a 2 digit number where the 1 2 is actually 1 20 The major number must be incremented on a revision that would result in a minor number greater than 99 March 2015 56 EDK II INF File Format EDK II INF File Specification VERSION_STRING This is typically a decimal number and if not specified an empty string will be provided This value will be converted by the build tools from an ASCII string into a null terminated Unicode string that contains a text representation of the version A platform integrator may specify a different version string for an FFS version section in the FDF file if more than just this value is needed It is recommended that the decimal number be used in such a manner as the integer portion of the value is considered the major number changing when there is a functional non backward compatible change The fact
146. or the code for the module For modules that will be distributed as binaries the PatchPed and PcdEx are the only supported types The FeaturePcd is used to enable some code paths the EDK II build system will generate a const statement for these PCDs Similar in function the dynamic PcdEx type can be used with modules that are released as binary However the access methods for this style prevents using these PCDs as any other PCD type source code must change in order for a PcdEx to be used as a FixedPcd Version 1 24B March 2015 30 INF Overview EDK II INF File Specification The FixedPcd and PatchPcd are static and only the PatchPcd can have the value changed in a binary prior to including the module in a firmware image The content of this section is the PCD Token Space Guid C Name followed by a period character and then the C name of the PCD The default value is optional See chapter 3 Module Information INF Format Specification later in this document for definition of the content Every PCD PcdName is identified by two parts the PCD s Token Space Guid C Name and the PCD s C Name these two items are separated by a period character This section uses one of the following section definitions PcdType PcdType common PcdType IA32 PcdType X64 PcdType IPF PcdType EBC The required entries for this section are the PCD Token Space Guid C Name s for the PCD that will be look
147. ormTokenSpaceGuid PcdFlashNvStorageVariableBase 2 14 3 FEATURE_FLAG The content for the PCD entry is the PCD s Name PCD s Token Space Guid C name followed by a period and the PCD s C name and an optional Default value of either TRUE Or FALSE 1 or 0 These fields are separated by the period character This section must not be present in INF files that describe a binary only module This section uses one of the following section definitions FeaturePcd FeaturePcd common FeaturePcd IA32 FeaturePcd X64 FeaturePcd IPF FeaturePcd EBC The following is an example of the PCD FEATURE_FLAG type FeaturePcd common gEfiEdkModulePpkgTokenSpaceGuid PcdDxeIplSupportCustomDecompress gEfiEdkModulePpkgTokenSpaceGuid PcdDxeIplSupportTianoDecompress gEfiEdkModulePpkgTokenSpaceGuid PcdDxeIplSupportEfiDecompress gEfiEdkModulePkgTokenSpaceGuid PcdDxeIplBuildShareCodeHobs 2 14 4 DYNAMIC The content for the PCD entry is the PCD s Name PCD s Token Space Guid C name followed by a period and the PCD s C name and an optional Default value These entries are separated by the pipe character While this section is the recommended method for coding PCD access methods it must not be present in INF files that describe a binary only module This section uses one of the following section definitions Pcd Pcd common Pcd IA32 Pcd X64 Pcd IPF Pcd EBC The following is an example of the PCD DYNAMIC type Version 1 24B March 2015 32
148. ospace In code or in text words in Italic Monospace indicate placeholder names for variable information that must be supplied e arguments 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 lt item gt 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 range range item 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 itemtnt The plus character denotes one or more occurrences of an item A
149. otocolLib inf Abstract Component description file EE March 2015 Version 1 24B EDK II INF File Specification EDK INF File Specification A 2 2 defines Section Summary This describes the required define tag which is required in all EDK INF files This file is created by the developer and is an input to the new build tool parsing utilities Elements may appear in any order within this section This is a required section The define sections defines symbols that describe the component Some items are emitted to the output makefile The FILE_GUID is required for all EDK components that are not libraries This guid is used to build the FW volume file list used by build tools to generate the final firmware volume as well as processed in some SMM PEI or DXE DEPEX statements Note Possible values for COMPONENT_TYPE and their descriptions are listed in the table Component module Types For each component the BASE_NAME and COMPONENT_TYPE are required The COMPONENT_TYPE definition is case sensitive The default FV extension can be overridden by defining the symbol FV_EXT Section defines PROCESSOR PLATFORM is used with EDK components only The section is processed in order by the parsing utilities Assignments of variables in other sections do not override previous assignments Platform integrators that will be using EDK components that require a static FlashMap h and or FlashMap inc must code them by han
150. ound 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 Defines INF_VERSION 0x00010018 BASE_NAME RuntimeDxe FILE_GUID B601F8C4 43B7 4784 95B1 FA226CBAOCEE MODULE_TYPE DXE_RUNTIME_DRIVER VERSION_STRING 1 0 Packages IA32 MdePkg MdePkg dec MdeModulePkg MdeModulePkg dec Binaries PE32 Ru TA32 ntimeDxe efi DXE_DEP Version 1 24B EX RuntimeDxe depex March 2015 133 Sample Binary INF Files 134 PatchPcd IA32 CON SUMES EDK II INF File Specification gEfiMdePkgTokenSpaceGuid PcdDebugPrintErrorLevel 0x80000047 0x1EC8 CON gEfiMdePkgTokenSpaceGuid PcdDebugPropertyMask 0x27 0x1 CON Protoco SUM PI S fl Q E SUM P3 S gEfiMdePkgTokenSpaceGuid PcdReportStatusCodePropertyMask 0x07 0x1E ls TA32 PRODUCES gEfiRu CON gEfiLo ntimeArchProtocolGuid SOMETIMES CONSUMES SUMES adedImageProtocolGuid SOMETIMES_CONSUMES greePr CON gEfiPc otocolGuid SUMES dProtocolGuid Ei SOM E TIMES CONSUMES gEfiDevicePathProtocolGuid CON gEfiSt SUMES atusCodeRuntimeProtocolGuid pI SOMETIMES_PRODUCES gEfiDr iverBindingProtocolGuid SOM E TIMES CONSUM
151. pdates Section 1 3 updated UDP Errata version of the UEFI PI Distribution Package Spec Section 2 7 and 3 15 added a binary file type of DISPOSABLE which will not be processed by the EDK II tools e Section 3 6 3 8 clarify that the As Built INF file is always generated by the build system Section 3 7 clarify that this section is required to list all dependent packages for PCDs listed in an As Built INF file Section 3 8 clarify the types of PCDs that will be generated in As Built INF files Section 3 3 Added Doxygen tags for Binary Header Copyright from the Source INF file containing the date of the last functional update to the source files is also the date that should be used for a Binary As Built INF file Put the BUILD_NUMBER element back into the Defines section this was inadvertently removed in Errata A Clarify that all entries are required within a Binary Header section Prohibit FeatureFlagExpressions for PCDs GUIDs Protocols and PPIs in the generated As Built INF files Fixed CRLF to be the correct hex bytes Reformatted the Header EBNF Removed unused EBNF entry lt ValPcds gt Added Reference to EDK II Build Specification for PCD processing rules Remove sentences referring to lengths of PCD VOID entries in section 2 14 Clarify that the Unicode format files are UCS 2LE encoded August 2013 1 22 w Errata D Updates Clarified that only UserExtensions sec
152. press a PCI Option ROM image file the default if not specified is FALSE This boolean operator is used to indicate that the module will require a separate HII resource section in the efi image file The value must be a directory name and the name can be used with and character sets This allows shortening of lines typed by users A User specified define CName Value pair that will be included in the AutoGen h file A user written makefile that will be used the INF file will not be parsed The Family is one of MSFT or GCC followed by a field separator character then the filename of the makefile in the same directory as the INF file To keep GCC compatibility the user must generate two Makefiles one for MSFT such as makefile and another for GCC such as GNUmakefile If present the file must contain all DEPEX statements as defined in the UEFI PI specification as the tools will process the file ignoring any content in Depex sections in this file AND all inherited dependencies from libraries This allows the module owner to force a Depex independently Use of this option is not recommended for normal use 20 INF Overview EDK II INF File Specification 2 5 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
153. processing The format for a user extension is UserExtensions UserID Identifier Having data elements under the section header is not required The EDK II build tools do not use this section When generating the As Built binary INF during a build this section is copied from the original source INF file if the Userld is TianoCore Other UserExtensions sections will not be copied The reference tools ignore all content within a UserExtensions section The following is an example of a UserExtensions section UserExtensions NoSuchCorp MyProcess_1 2 NoSuch bat 2 16 1 UserExtensions TianoCore ExtraFiles Section The EDK II UserExtensions TianoCore ExtraFiles section allow for distributing extraneous files that are associated with a module Files listed in this section are not processed by EDK II build tools These files must exist in the directory or sub directories of the directory containing the INF file Version 1 24B March 2015 34 INF Overview EDK II INF File Specification Note The Intel UEFI Packaging Tool will parse this section and for all files listed in this file add the file to the module distribution using the UEFI Distribution Package Distribution The section header must be UserExtensions TianoCore ExtraFiles Having data elements under the section header is not required The following is an example of a UserExtensions TianoCore ExtraFiles section User Extensions TianoCo
154. re Readme txt 35 ExtraFiles March 2015 Version 1 24B EDK II INF File Specification Version 1 24B March 2015 INF Overview 36 EDK II INF File Specification 3 EDK II INF File Format This section of the document describes the EDK II INF sections using an Extended Backus Naur Form Note The elements of the EDK INF file see Appendix A and the EDK II INF files differ 3 1 General Rules The general rules for all EDK II INI style documents follow Note Path and Filename elements within the INF are case sensitive in order to support building on UNIX style operating systems Additionally names that are C variables or used as a macro are case sensitive Other elements such as section tags or hex digits in the INF file are not case sensitive The use of and in paths and filenames is strictly prohibited Note This document uses a backslash character to indicate that a line that cannot be displayed in this document on a single line Within the INF specification each entry must appear on a single line e Multiple INF files may exist in a directory however either the FILE_GUID or the VERSION_STRING must be unique to the INF file It is recommended that the BASE_NAME also be unique and match the INF filename as in BaseLib inf will use a BASE_NAME Of BaseLib e Text in section tags text between square brackets is not case sensitive e A section terminates with either another secti
155. reate a related Depex section for each module type in XML If the module is a library and the MODULE_TYPE is not BASE with a LIBRARY_CLASS statement in the Defines section and it has no MTL defined without a March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format ModuleTypeList statement following by the LIBRARY_CLASS statement in the Defines section a Depex section is not permitted If one is found the build tools must exit gracefully and provide the user with an error message stating the Depex section is not valid for the module If the module is a library with a LIBRARY_CLASS statement in the Defines section and the MODULE_TYPE iS UEFI_DRIVER the Depex section must map to a DxeDepex section in the XML For a binary INF file the Depex section will contain the full dependency expression including the dependencies from the linked libraries in a comment Version 1 24B March 2015 86 EDK II INF File Format EDK II INF File Specification Note A UEFI_DRIVER which is not included in an FD image such as a driver that will be loaded from the shell or stored in a PCI option ROM will not have an FFS DEPEX section generated by the tools Note Capitalization in the Prototypes listed below does not match the capitalization used in the PI 87 Specification Prototype lt Depex gt lt com_attribs gt lt attribs gt lt attrs gt lt Module gt lt DepexModuleType gt lt Dep
156. rence only and not required by the build tools VALID_ARCHITECTURES IA32 X64 IPF EBC Sources MemoryAllocationLib c Version 1 24B March 2015 127 Sample Library INF Files EDK II INF File Specification E 3 128 DxeCoreMemoryAllocationServices h Packages MdePkg MdePkg dec LibraryClasses DebugLib BaseMemoryLib SmmcCorePerformanceLib inf file SR SE OSE SR OSE OSE OE OR r E SESE t d t d ir s ps HEHE Performance library instance used by SMM Core This library provides the performance measurement interfaces and initializes performance logging for the SMM phase It initializes SMM phase performance logging by publishing the SMM Performance and PerformanceEx Protocol which is consumed by SmmPerformanceLib to logging performance data in SMM phase This library is mainly used by SMM Core to start performance logging to ensure that SMM Performance and PerformanceEx Protocol are installed at the very beginning of SMM phase Copyright c 2011 2012 Intel Corporation All rights reserved lt BR gt 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
157. ression Syntax Specification Intel 2014 VFR Programming Language Intel 2012 EDK II Platform Configuration Database Infrastructure Description Intel 2009 e INI file Wikipedia http en wikipedia org wiki INI_file e CNow C Programming Information Langston University Tulsa Oklahoma J H Young 1999 2011 http c comsci us syntax expression ebnf html 1 3 Terms The following terms are used throughout this document to describe varying aspects of input localization BaseTools The BaseTools are the tools required for an EDK II build 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 DEC EDK II Package Declaration File This file declares information about what is provided in the package An EDK II package is a collection of like content DEPEX Module dependency expressions that describe runtime process restrictions Dist This refers to a distribution package that conforms to the UEFI Platform Initialization Distribution Package Specification DSC EDK II Platform Description File This file describes what and how modules libraries and components are to be built as well as defining library instances which will be used when linking EDK
158. ribs gt lt attribs gt lt attrs gt lt TS gt Ppis lt attrs gt lt attrs gt T lt arch gt lt PpiStatements gt lt NUsageBlock gt lt TS gt lt PpiSpec gt lt 1UsageBlock gt lt PpiSpec gt lt CName gt lt FS gt lt FeatureFlagExpress gt lt 1UsageBlock gt lt CommentBlock gt lt NUsageBlock gt lt CommentBlock gt lt FeatureFlagExpress gt lt Boolean gt lt CommentBlock gt lt TS gt lt UsageField gt lt TS gt lt Comment gt lt EOL gt lt UsageField gt lt TS gt lt Usage gt lt TS gt lt Notify gt lt Notify gt 4 lt TS gt NOTIFY lt TS gt lt Usage gt PRODUCES SOMETIMES PRODUCES CONSUMES SOMETIMES CONSUMES UNDEFINED Parameters FeatureFlagExpress The feature flag expression is currently ignored by the EDK II build system 1UsageBlock and NUsageBlock The 1UsageBlock location after the entry is preferred if there is only one usage for the PPI entry If a PPI has multiple usages then all CommentBlock statements must precede the entry UNDEFINED Typically this entry will be used when tools creating installing UEFI Distribution Packages encounter a missing or misspelled usage UNDEFINED is also valid when the PPI is not used as a PPI and the GUID value of the PPI is used for something else CONSUMES This module does not install the PPI but needs to locate a PPI Not valid if the Notify true PRODUCES This module
159. ription Extension Library BASE SEC PEI_CORE lib Library component used in the PEIM DXE_CORE build for linking against DXE_DRIVER components DXE_RUNTIME_DRIVER DXE_SAL_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_ DRIVER UEFI_ APPLICATION USER_DEFINED File USER_DEFINED bin In EDK this was used to specify various types of source or binary files Legacy16 USER_DEFINED bin or In EDK this was used to specify rom various types of binary files BINARY USER_DEFINED bin or In EDK this was used to specify rom various types of binary files CONFIG USER_DEFINED bin In EDK this was used to sepcify INI text files that were processed by different tools into binary files LOGO USER_DEFINED bmp The MODULE_TYPE for aLOGO when migrating to EDK II should be specified as USER_DEFINED The bmp file should be included under a binaries section In EDK the COMPONENT_TYPE of LOGO was used to specify a bmp file in the sources section RAWFILE USER_DEFINED raw In EDK this was used to specify various types of binary files FVIMAGEFILE N A fv APRIORI Not Supported bin Distribution of an Aprior file is not supported These files are created during image generation stage based on content of a FDF file In EDK the file was just a text file with a single line for each driver Version 1 24B March 2015 139 Module Types FILE TYPE BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DX
160. rs 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 140 March 2015 Version 1 24B EDK II INF File Specification FILE TYPE DXE_SAL_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_DRIVER UEFI_APPLICATION USER_DEFINED EFI Dependency Section EFI User Interface Section Version 1 24B MODULE_ TYPE DXE_SAL_DRIVER SMM_CORE DXE_SMM_DRIVER UEFI_ DRIVER UEFI_ APPLICATION USER_DEFINED Any the code for these sections is included as part of any module and no separate INF is required Any the code for these sections is included as part of any module and no separate INF is required March 2015 EDK II Extension efi efi efi efi efi bin or rom dpx ul Module Types Description 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 This module is the SMM Core This
161. s defining an architecture having a higher precedence than a section which uses common or no architecture extension as the architecture Note Content within a section IS case sensitive IA32 la32 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 Duplicate sections two sections with identical section tags will be merged by tools with the second section appended to the first If architectural modifiers are used in the section tag the section is merged by tools with content from common sections if specified with the architectural section appended to the first into an architectural section For example given the following Sources ACommonFile c Sources IA32 eet Se Sources X64 CLOLK64 Cc After the first pass of the tools when building the module for IA32 the source files will logically be Sources IA32 ACommonFile c Brorlas2 e When building the module for X64 the source files will logically be Sources X64 ACommonFile c CforxX64 c The Defines section tag prohibits use of architectural modifiers All other sections can specify architectural modifiers 2 2 2 Comments The hash character indicates comments in the Module Information INF file In line comments terminate the processing of a line In line comments must be placed at th
162. sful return status is not unloaded when its entry point exits UEFI Driver A driver that follows the UEFI specification UEFI Specification Version 2 4 Current UEFI version UEFI Platform Initialization Distribution Package Specification Version 1 0 The current version of this specification includes Errata B UEFI Platform Initialization Specification 1 3 Current version of the UEFI PI specification 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 VPD Vital Product Data that is read only binary configuration data typically located within a region of a flash part This data would typically be updated as part of the firmware build post firmware build via patching tools through automation on a manufacturing line as the FLASH parts are programmed or through special tools 5 March 2015 Version 1 24B EDK II INF File Specification Introduction 1 4 Target Audience Those performing UEFI development and support for platforms and distributable modules 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 multi byte data item in memory is at the lowe
163. st 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 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 i
164. superscript number n is the number occurrences of the item that must be used Example 0 9 indicates that there must be exactly eight digits so 01234567 is valid while 1234567 is not valid March 2015 Version 1 24B EDK II INF File Specification Introduction item n 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 item n A superscript number n within curly braces preceded by a comma indicates a maximum number of occurrences of the item item n m A superscript number n followed by acomma and anumber m indicates that the number of occurrences can be from ntom occurrences of the item inclusive Version 1 24B March 2015 8 EDK II INF File Specification 2 INF Overview This section of the document describes the decisions regarding the format of the EDK II module INF files The INF files are used by EDK II utilities that parse build meta data files INF DEC DSC and FDF files to generate AutoGen c and AutoGen h and Makefile GNU makefile files for the EDK II build infrastructure The EDK II INF meta data file describes properties of a module how it is coded what it provides what it depends on architecture specific items features etc regarding the module INF files generated during a build that allow distribution of binary modules describe how the module was
165. t lt Comment gt lt Space gt lt Space gt BinaryHeader lt EOL gt lt BinaryAbstract gt nn lt EOL gt lt BinaryDescription gt n lt EOL gt lt Copyright gt nn lt EOL gt lt BinaryLicense gt lt EOL gt lt Word gt lt Extension gt March 2015 50 EDK II INF File Format EDK II INF File Specification lt BinaryAbstract gt lt MTS gt lt AsciiString gt lt EOL gt lt BinaryDescription gt lt MTS gt lt AsciiString gt lt EOL gt lt BinaryLicense gt lt MTS gt lt AsciiString gt lt EOL gt lt EOL gt Parameters Abstract A brief one line description of what the module does BinaryAbstract A brief one line description of what the module does that may be different from a source abstract If AS line is present the tools will use this line when generating the binary As Built INF e Ifthe Doxygen tag is not present the tools will use the primary Abstract from the Source I NF file when generating a binary As Built INF e Inthe binary As Built INF the Doxygen tag must not be present e The INF file will always have an English version of the Abstract Other localized versions of the abstract will be stored in the UCS 2LE encoded file specified in the Defines section s MODULE_UNI_FILE Note This file permits the Intel UEFI Packaging Tool to process localized module content described in the UEFI Platform Initia
166. t INF file is broken out into sections in a manner similar to the other build meta data files However the intent of a module s INF file is to define the source files libraries and definitions relevant to building the module creating binary files that are either raw binary files or PE32 PE32 coff format files The different sections are described in detail in this chapter In general the original EDK parsing utilities read each line from the Libraries or Components sections of the build description DSC file process the INF file on a line to generate a makefile and then continued with the next line EDK II parsing utilities are token based which permits an element to span multiple lines The EDK II utilities check both EDK and EDK II INF files and if required generate C code files based on the content of the EDK II INF Refer to the EDK II Build Specification for more information regarding these auto generated files One major difference between EDK and EDK II is support for non Microsoft development environments Because modules may be distributed to developers that use these environments both source code and the meta data files need to be UNI X GCC clean One little known fact regarding the Microsoft tools and operating systems is their ability to process the forward slash character as a directory separator All EDK II INF files MUST use this forward slash character for all directory paths specified 2 2 Information File
167. t MACROVAL gt lt PATH gt lt FileSep gt lt File gt lt PATH gt lt FileSep gt lt File gt a zA Z0 9_ 0 9 a zA Z_ lt NonDigit gt lt Chars gt lt Identifier gt A valid C variable name 0x21 Ox7E 0x21 0x23 0x5B 0x5D Ox7E lt EscapeSequence gt 0x22 March 2015 38 EDK II INF File Format 39 lt EscapeSequence gt lt TabSpace gt lt TS gt lt MTS gt lt Tab gt lt Space gt lt CR gt lt LF gt lt CRLF gt lt WhiteSpace gt lt ws gt lt Eq gt lt FieldSeparator gt lt FS gt lt Wildcard gt lt CommaSpace gt lt Cs gt lt AsciiString gt lt EmptyString gt lt CFlags gt lt PrintChars gt lt QuotedString gt lt CString gt lt NormalizedString gt lt GlobalComment gt EDK II INF File Specification MN n Ce EI NEW b 00 WR EA lt DblQuote gt lt Tab gt lt Space gt lt TabSpace gt lt TabSpace gt 0x09 0x20 0x0D 0x0A lt CR gt lt LF gt lt TS gt lt CR gt lt LF gt lt CRLF gt lt WhiteSpace gt lt TS gt lt TS gt myn lt TS gt lt FieldSeparator gt lt TS gt wen lt Space gt lt Space gt lt TS gt lt AsciiChars gt lt DblQuote gt lt DblQuote gt lt AsciiString gt lt TS gt lt CChars gt lt DblQuote gt lt PrintChars gt lt DblQuote gt L lt QuotedString gt lt DblQuote gt lt Word gt lt Space gt
168. t TOOLPATH gt lt FileSep gt lt CommandName gt lt TOOLPATH gt lt PATH gt lt ABS_PATH gt lt PATH gt lt ABS_PATH gt a zA Z Parameters All of the keywords that make up the left side of the expression must be alphanumeric only no special characters are permitted For more information about the following parameters refer to the Build Specification for as description of the tools_def txt file In order for the entries in the INF file to be valid there must be a matching definition in the tools_def txt file The tool chain tag name must also match the one used for the build Family Must match a FAMILY name defined in the EDK II tools_def txt file If not present then the entry is valid for all tool chain families TOOLPATH Paths listed in the BuildOptions section are relative to the system environment variable EDK_TOOLS_PATH or they may be absolute Use of and in the directory path is not permitted If the absolute format is used the module cannot be distributed using a UEFI Distribution Package Target A keyword that uniquely identifies the build target the first field where fields are separated by the underscore character Three values NOOPT DEBUG and RELEASE have been pre defined This keyword is used to bind command flags to individual commands Users may want to add other definitions such as PERF SIZE or SPEED and define their own set of FLAGS to use with these tags
169. t of tokens Due the extensive use of MACRO statements in the EDK components and libraries INF files EDK INF files cannot be processed by tools to create a distribution that complies with the UEFI Platform Initialization Distribution Package Specification 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 8A0 7 5178B1AE3AO2 COMPONENT_TYPE BS_DRIVER The following table lists the possible content of this section Version 1 24B March 2015 95 EDK INF File Specification Table 6 EDK defines Section Elements EDK II INF File Specification Tag Required Value Notes BASE _ NAME Yes A single
170. table The local symbol table is purged following processing of individual component INF files Global symbol values persist throughout execution of the utility Local symbol values take precedent over global symbols The following table describes the symbols generated internally by the utility They can be overridden either on the command line in the DSC file or in individual INF files The G L column indicates whether the symbol is typically a global or a local symbol Version 1 24B March 2015 115 Symbols 116 EDK II INF File Specification Table 8 Symbol Description Symbol Name EDK_SOURCE EP SOURCE PROCESSOR BUILD_DIR SOURCE_DIR DEST_DIR LIB_DIR BIN_DIR OUT_DIR DSC_FILENAME INF_ FILENAME FV_EXT MAKEFILE_NAME PLATFORM FILE G L G G L Description Defines the root directory of the local EDK source tree for example C EFI2 0 If not defined as an environmental variable when the tool is invoked the utility will attempt to determine a reasonable value based on the current working directory Defines the root directory of the local EDK source tree for example C EFI2 0 If not defined as an environmental variable when the tool is invoked the utility will attempt to determine a reasonable value based on the current working directory Defines the target processor for which the code is to be built This symbol will typically be used to include or exclude source files in component
171. tains assembly code Since the ECP can be used with existing EDK tools which is only supported by Microsoft 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 build system compatible I NF files for non Windows based tool chains and use just the basename inf for the filename of EDK only INF files used by the EDK build system Note Path and Filename elements within the INF are case sensitive in order to support building on UNIX style operating systems Note GUID values are used during runtime to uniquely map the C names of PROTOCOLS PPIS PCDS and other variable names Note This document uses a backslash to indicate that a line that cannot be displayed in this document on a single line Within the DSC specification each entry must appear on a single line Note The total path and file name length is limited by the operating system and third party tools It is recommended that for EDK II builds that the WORKSPACE directory be either a directory under a Version 1 24B March 2015 9 EDK II INF File Specification INF Overview subst drive in Windows s build as an example or be located in either the opt directory or in the user s home username directory for Linux and OS X 2 1 Processing Overview Each module or componen
172. tensions lt TcEf gt lt EOL gt lt FileNames gt lt TcEf gt TianoCore lt DblQuote gt ExtraFiles lt DblQuote gt lt FileNames gt lt TS gt lt RelativePath gt lt File gt lt EOL gt Parameters FileNames Paths listed in the filename elements of the this section must be relative to the directory the I NF file resides in Use of and in the directory path is not permitted Example UserExtensions TianoCore ExtraFiles Readme txt 3 11 Protocols Sections These are optional sections If the source module code contains any protocols then this section must be generated in the As Built INF file listing each protocol with its lt CommentBlock gt content Summary Defines the optional EDK II INF file Protocols section tag This is a list of the global PROTOCOL C Names that are referenced in the EDK II Module s C code Each protocol must be listed only once per section Protocols listed in architectural sections are not permitted to be listed in the common architectural section The common architecture modifier in a section tag must not be combined with other architecture type doing so will result in a build break The format of the lt CcommentBlock gt is the recommended format that will guarantee that the information is correctly inserted into UEFI Distribution Package description files by the Intel UEFI Packaging Tool included in the EDK II base tools project The usages in the comment
173. 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 100 March 2015 Version 1 24B EDK II INF File Specification EDK INF File Specification 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 libr
174. tion EE 100 AST libraries Sections 101 A 1 4 includes Section ME 101 AAAS imak SCHON EE 102 A 2 EDK FIIE SPESIHCANON See Sen ees 102 PP ME 103 A22 defines SOCUON E 105 A223 includes SECON EE 107 P24 libraries EE 108 A 2 5 nmake Seelon usa a 109 R 2 6 SOUFEES WEE 111 Appendix B Build Changes and Customizations uuuz uuunnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 113 B 1 Customizing EDK Compilation for a Component nenn 113 B 2 Changing Files in an EDK Ebrar nasse 113 B 3 Customizing EDK II Compilation for a Module Common Definitions 113 1 March 2015 Version 1 24B EDK II INF File Specification Appendix C Symbols E 115 Appendix D Sample Driver INF EAR 119 D 1 Diskl oDxe INF Tiley anne Hs 120 D 2 StatusCodeRuntimeDxe INF file REENEN 121 Appendix E Sample Library INF Files 222 2 ee 125 E 1 PeiServices LablePointerhiBetint unse sense ee 126 E 2 DxeCoreMemoryAllocation Lib inf EEN 127 E 3 SmmCorePerformance ib Inf 128 Appendix F Sample Binary INF Files 22 2 ee 131 F 1 FatBinPkg EnhancedFatDxe Fat int 4444444444 44H nn nnHHannnnnnannenn nam nun naar 132 F 2 MdeModulePkg Core RuntimeDX Inf NEEN 133 Appendix G let HEN KE 139 Version 1 24B March 2015 1 EDK II INF File Specification 12 March 2015 Version 1 24B EDK II INF File Specification Tables Table 1 EDK II Defines Section Elements kk 17 Table 2 EDK II Build
175. tions with a Userld of TianoCore will be copied into the As Built INF generated by the EDK II build tools Clarify that Depex section tags must be unique Clarify the use of Depex sections in library modules March 2014 1 24 Updates Change revision number of this specification from 1 22 to 1 24 Update INF_VERSION to 0x00010017 Added MODULE_UNI_FILE entry to the Defines section this file must end with an extension of uni UNI or Uni Added reserved TianoCore user extension for ExtraFiles Allow Space and Unicode characters in the directory path identified by the system environment variable WORKSPACE August 2014 March 2015 Version 1 24B EDK II INF File Specification 1 24 w Updates December 2014 Errata A Revised ordering of the top level EBNF for an INF file to match the output of the Intel R UEFI Distribution Packaging Tool at the start of chapter 3 2 Updated specification dates in section 1 2 and added two new specs Updated INF_VERSION to 0x00010018 Allow specifying the INF_VERSION value as a decimal value such as 1 24 Modified Section 2 14 allowing Feature Flag Expressions removed expression syntax from the Common EBNF as it is now covered by its own specification 1 24 w Updates March 2015 Errata B Update link to the EDK II Specifications fixed the name of the Multi String UNI File Format Specification Update usage UNDEFINED in Parameters sections for G
176. trict 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 A 2 EDK File Specification The general rules for all EDK INI style documents follow Note Path and Filename elements within the INF are case sensitive in order to support building on UNIX style operating systems A section terminates with either another section definition or the end of the file Summary Component EDK INF description 102 March 2015 Version 1 24B EDK II INF File Specification EDK INF File Specification lt EDK_INF gt lt Header gt lt Defines gt lt Sources gt lt Includes gt lt Libraries gt lt Nmake gt A 2 1 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 t Copyright License m Module Name EdkFrameworkProtocolLib inf i Abstract Component description file j EE This information a dev
177. try in the section except when the macro is within double quotation marks in build options sections The expectation is that these macros will be expanded by scripting tools such as make or nmake Macros can be used to define a path a filename any combination of path and file names or content that will appear in the right side of a statement in the BuildOptions section Macros for paths and files can be defined and used in Defines LibraryClasses Sources Binaries and Packages sections Macro Definition statements that appear within a section of the file other than the Defines section are scoped to the section they are defined in If the Macro statement is within the Defines section then the Macro is common to the entire file with local definitions taking precedence if the same MACRO name is redefined in subsequent sections then the MACRO value is local to only that section In the following example the MACRO IFMP is used to fit a long directory filename pair on to a single line March 2015 Version 1 24B EDK II INF File Specification INF Overview DEFINE IFMP IntelFrameworkModulePackage Using the macro for example in a Packages section looks like IFMP IntelFrameworkModulePackage dec Macros are evaluated where they are used in statements not where they are defined It is recommended that tools break the build and report an error if an expression cannot be evaluated Macros used in build flags
178. tyMask Version 1 24B March 2015 129 Sample Library INF Files EDK II INF File Specification CONSUMES Note In the above example the backslash character is used to show a line continuation for readability Use of a backslash character in the actual INF file is not permitted 130 March 2015 Version 1 24B EDK II INF File Specification Appendix F Sample Binary I NF Files The following are example I NF files for the binary modules EnhancedFatDxe in the FatBinPkg The second example is a generated binary INF file for the RuntimeDxe driver in the MdeModulePkg Version 1 24B March 2015 131 Sample Binary INF Files EDK II INF File Specification F 1 FatBinPkg EnhancedFatDxe Fat inf 132 file Binary FAT32 EFI Driver for IA32 X64 IPF and EBC arch This UEFI driver detects the FAT file system in the disk It also produces the Simple File System protocol for the consumer to perform file and directory operations on the disk Copyright c 2007 2010 Intel Corporation All rights reserved lt BR gt 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
179. uids Protocols PPls and PCDs in chapter 3 Add clarification of the Event Types in chapter 3 Added UEFI PI PEI Boot Mode declarations in 3 2 5 to the list while keeping the synonyms that were already defined Added descriptions as well Adding HOB type UNUSED from the PI Specification Version 1 24B March 2015 7 EDK II INF File Specification 8 March 2015 Version 1 24B EDK II INF File Specification Contents 1 Introduction E 1 Re 1 1 2 Related Information ea ee 1 eK gt EEE ER EHELEUTE ERLRUR ELLE NIEHRETRIRIER EEE ES EREEFEHEEEENEE 2 1 4 Target Audienee nn en ee 5 1 5 Conventions Used in this Document 6 1 0 1 Data Structure Desenptons een a ENEE 6 1 5 2 Pseudo Code Conventions 22 4444u44n4annnnnnnnnnnannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnanannn 6 1 5 3 Typographic ue ee 6 2 INF MS E 9 2 1 Processing e e EE 10 2 2 Information File General Rules men en 10 SEET 10 2 22 COMMENTS ee ae ee 11 22 3 Valid ie ae 12 2 2 4 Naming ele 12 2 2 5 linclude Statements 80 anna 13 2 2 6 Macro EEN 13 2 2 7 Conditional Directive Statements je 14 228 EXPTOSSI N ana 15 2 3 EDK II INF OP Va nee ie Zee nee 15 SEN 15 2 5 Sources Section getest geen Eeer Eed eEeeiedeg 21 2 6 BuildOptions SOC le 22 2 7 Binaries Section E 24 28 ee EE e E 27 2 9 Protocols Section see ee ee 27 2 19 Ppis SQCUOM EE 27 211 Guids A VON Ne ra een 28 2 12 L braryGlasses SOCOM DE 28 2 13 Packages SCH e
180. uld not design products based on this document Other names and brands may be claimed as the property of others Copyright 2007 2015 Intel Corporation All rights reserved 2 March 2015 Version 1 24B Revision History EDK II INF File Specification Version 1 24B Revision Revision History Date 1 0 Initial release December 2007 1 1 Updated based on errata August 2008 1 2 Updated based on enhancement requests June 2009 1 21 Updated to support UEFI 2 3 and PI 1 2 specifications March 2010 Added new element UEFI_HII_RESOURCE_SECTION to Defines section Added new SMM_CORE module type Updated for clarification e Permit NULL values in place of PCD default values Updated to correct items listed in the errata document e Permit whitespace characters between token elements Fixed BuildOptions separator between Family and the tool change information to match the implementation Changes to appearance for readability e Moved EDK INF description from sections 2 and 3 to an Appendix User feature requests e Updated the description of the FeatureFlag Expression for all occurrences in Chapter 3 to be either a Shell style or a C style expression 1 22 Grammatical and formatting changes May 2010 March 2015 EDK II INF File Specification 1 22 w Errata A Updates December 2011 Updated to support UEFI version 2 3 1 and updated spec release dates in Introduction Clarify UEFI s PI Distribut
181. usCodeDataTypeStringGuid SOMETIMES_CONSUMES UNDEFINED Protocols gEfiStatusCodeRuntimeProtocolGuid PRODUCES gEfiDataHubProtocolGuid SOMETIMES_CONSUMES Needed if Data Hub is supported for status code FeaturePcd gEfiMdeModulePkgTokenSpaceGuid PcdStatusCodeReplayIn CONSUMES gEfiIntelFrameworkModulePkgTokenSpaceGuid PcdStatusCodeUseOEM CONSUMES gEfiIntelFrameworkModulePkgTokenSpaceGuid PcdStatusCodeUseDataHub CONSUMES gEfiMdeModulePkgTokenSpaceGuid PcdStatusCodeUseMemory CONSUMES gEfiMdeModulePkgTokenSpaceGuid PcdStatusCodeUseSerial CONSUMES Pcd gEfiMdeModulePkgTokenSpaceGuid PcdStatusCodeMemorySize 128 gEfiMdeModulePkgTokenSpaceGuid PcdStatusCodeUseMemory SOMETIMES CONSUMES Depex TRUE Note In the above example the backslash character is used to show a line continuation for readability Use of a backslash character in the actual INF file is not permitted Version 1 24B March 2015 123 Sample Driver INF Files EDK II INF File Specification 124 March 2015 Version 1 24B EDK II INF File Specification Appendix E Sample Library INF Files The following INF file are examples of INF files for the EDK II MdePkg library PeiServicesTablePointerLib and the MdeModulePkg libraries DxeCoreMemoryAllocationLib inf and SmmCorePerformanceLib inf Version 1 24B March 2015 125 Sample Li brary INF Files EDK II INF File Specification
182. utes may have the item either appended or replaced The left side content of a statement may appear in both common and architectural sections For example MSFT DEBUG_ _ _CC_FLAGS may be listed in a common section while MSFT DEBUG_ _IA32_CC_FLAGS may be listed in the architectural section If the operator is a single character the flags from the architectural section are appended to the flags from the common section Using this section may limit the ability of a module to be compiled with different tool chains or with different build systems and is therefore discouraged Valid content is within this section is limited to the following description Table 2 EDK Il BuildOptions Section Elements Tag Value Notes S FAMILY S TARGET _S TAGNAME Flags for Used to specify module specific flags ARCH _ TOOLCODE _ FLAGS specific tool of the module that will use the zZ codes for driver this module S FAMILY S TARGET _ TAGNAME The fully Used to replace a specific command ARCH _ TOOLCODE _ PATH qualified such as forcing the ASL to be iasl Si path an instead of asl executable S FAMILY S TARGET _ S TAGNAME _ A fully A path that will be added to the ARCH _ TOOLCODE _DPATH qualified system Environment s PATH variable path prior to executing a command S FAMILY S TARGET _S TAGNAME Attribute This permits overriding other ARCH _ TOOLCODE _ ATT
183. ve path and filename ext DEBUG GCC UNIXGCC TRUE FileType Filename ext GCC FIleType Relative path and filename ext RELEASE FileType Filename ext RELEASE FileType Filename ext The FileType falls into one of the following Pl defined types GUID This binary is an EFI_SECTION_GUID_DEFINED encapsulation section The EDK II build system does not support binary files of this type ACPI The binary is ACPI binary code generated from an ACPI compiler There is not Pl defined type for this file it uses an EFI_SECTION_RAW leaf section ASL The binary is an ACPI Table generated from an ACPI compiler There is no PI defined type for this file it uses an EFI_SECTION_RAW leaf section DISPOSABLE Unlike other file types listed in this section the file will not be placed in a leaf section of type EFI_SECTION_DISPOSABLE but rather it is a binary file that will be ignored by the build tools Useful for distributing PDB files with binary modules UEFI_APP The binary file is a PE32 UEFI Application which will be placed into an FFS file of typeEFI_FV_FILETYPE_APPLICATION PE32 This binary is an EFI_SECTION_PE32 leaf section PIC This binary is an EFI_SECTION_PIC leaf section PEI DEPEX This binary is an EFI_SECTION_PEI_DEPEX leaf section DXE_DEPEX This binary is an EFI_SECTION_DXE_DEPEX leaf section SMM_DEPEX This binary is an EFI_SECTION_SMM_DEPEX leaf section March 2015 Version 1 24B EDK II INF File Specification IN
184. will load this PPI Not valid if the Notify attribute is true Version 1 24B March 2015 80 EDK II INF File Format EDK II INF File Specification SOMETIMES CONSUMES This module does not install the PPI but may need to locate a PPI under certain conditions or execution paths If the Notify attribute is set then the module will use the PPI named by GUID via a registry PPI notify mechanism SOMETIME PRODUCES This module will load this PPI under certain conditions or execution paths Not valid if the Notify attribute is true NOTIFY This specifies whether this is a Ppi or PpiNotify If set to the module requires or consumes a PPI named by GUID via a register PPI notify mechanism Example ppis gEfiPeiMemoryDiscoveredPpiGuid gEfiFindFvPpiGuid 3 13 Guids Sections These are optional sections If the source module code contains any GUIDs other than PPI or PROTOCOL GUIDs then this section must be generated in the As Built INF file listing each GUID with its lt commentBlock gt content Summary Defines the EDK II INF file Guids section content This is a list of the global GUID C Names that are referenced in the module s code but not already referenced in the INF Unique GUID C names may be published in the DEC file or come from a Distribution Package surface area description The C Names used in this section are formatted using the external name The common architecture modifier in a section tag must not be combined
185. y expressions that would normally have been inherited from libraries linked to the module Use of this feature is not recommended for normal use OptionRomInfo These statements are used by developers of stand alone PCI Option ROM drivers They allow the developer to forego creation of an FDF file in the package directory Only the INF file and a DSC file are required for pure PCI Option ROM development ENTRY_POINT CName This is the name of the driver s entry point function UNLOAD_IMAGE CName If a driver chooses to be unloadable then this is the name of the modules function registered in the Loaded Image Protocol It is called if the UEFI Boot Service Unloadl mage is called for the module which then executes the Unload function disconnecting itself from handles in the database as well as uninstalling any protocols that were installed in the driver entry point The CName is the name of this module s unload function 57 March 2015 Version 1 24B EDK II INF File Specification EDK II INF File Format Example EDK II Driver Defines INF_VERSION 0x00010018 BASE NAME PlatformAcpiTable FILE GUID 7E374E25 8E01 4FEE 87F2 390C23C606CD MODULE_TYPE DXE_DRIVER VERSION_STRING 1 0 EDK_RELEASE_VERSION 0x00020000 UEFI_SPECIFICATION_VERSION 0x00020014 Example UEFI Driver Defines INF_VERSION 0x00010018 BASE_NAME Abc FILE_GUID DA87D340 15C0 4824 9BF3 D52286674BEF

(INF) File Specification

Contents

Download Pdf Manuals

Related Search

Related Contents