You are on page 1of 56

EDK II DEC File Specification

April 2010 Revision 1.22

DEC

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

Copyright 2007 - 2010 Intel Corporation. All rights reserved.

ii

April 2010

Version 1.22

DEC

Revision History
Revision 1.0 1.1 1.2 1.21 Revision History Initial release. Updated based on errata Updated based on enhancement requests Updated based on errata and for enhancement requests Standardized the format for common content. Added support for @Keyword Doxygen tag Added support for @ModuleType Doxygen tags Added support for @ValidList, @DefaultValue and @ValidRange Doxygen tags for PCDs Added PKG_UNI_FILE element to [defines] section Errata and grammatical editing Date December 2007 August 2008 June 2009 January 2010

1.22

April 2010

Version 1.22

April 2010

iii

DEC

iv

April 2010

Version 1.22

DEC

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

DEC File Overview.......................................................................................... 9


2.1 Usage Overview................................................................................................................ 9 2.2 Declaration File Format..................................................................................................... 9 2.2.1 Section Entries ...................................................................................................... 9 2.2.2 Comments........................................................................................................... 10 2.2.3 Valid Entries ........................................................................................................ 10 2.2.4 Naming Conventions........................................................................................... 11 2.2.5 !include Statements............................................................................................. 11 2.2.6 Macro Statements ............................................................................................... 11 2.2.7 PCD Names ........................................................................................................ 12 2.2.8 Conditional Directive Statements (!if...)............................................................... 12 2.3 [Defines] Usage .............................................................................................................. 12 2.4 [Includes] Usage ............................................................................................................. 13 2.5 [guids] Usage .................................................................................................................. 13 2.6 [protocols] Usage ............................................................................................................ 13 2.7 [ppis] Usage .................................................................................................................... 14 2.8 [libraryclasses] Usage..................................................................................................... 14 2.9 [pcds] Usage ................................................................................................................... 14 2.10 [UserExtensions] Usage ............................................................................................... 15

DEC File Format Specification .................................................................... 17


3.1 Introduction ..................................................................................................................... 17 3.2 Common Definitions........................................................................................................ 17 3.3 Header Comment Section............................................................................................... 19 3.4 [Defines] Section............................................................................................................. 21 3.5 [Includes] section ............................................................................................................ 22 3.6 [Guids] Section................................................................................................................ 24 3.7 [Protocols] Section .......................................................................................................... 26 3.8 [PPIs] Section ................................................................................................................. 28 3.9 [LibraryClasses] Section ................................................................................................. 29 3.10 PCD Sections................................................................................................................ 31

Version 1.22

April 2010

DEC

Appendix A DEC Examples ................................................................................................... 37 Appendix B HII String Files ................................................................................................... 45

3.11 [UserExtensions] Section.............................................................................................. 35

A.1 EDK II MdeModulePkg Example .................................................................................... 37 A.2 EDK II Nt32Pkg Example ............................................................................................... 40

Appendix C Module Types..................................................................................................... 47

B.1 Use of HII String File Data.............................................................................................. 45

vi

April 2010

Version 1.22

DEC

Tables
Table 1.Valid Variable Names for PATH statements ........................................................... 12 Table 2. EDK II Module Types ............................................................................................. 47

Version 1.22

April 2010

vii

DEC

viii

April 2010

Version 1.22

DEC

Introduction

1 Introduction
This document describes the EDK II Declaration (DEC) file format. This format was designed to support building packaging and distribution of EDK II modules, as well as for building platforms and modules using the EDK II build infrastructure. The EDK II Build Infrastructure supports generation of UEFI 2.3 and PI 1.2 (Unified EFI, Inc.) compliant binary images.

1.1 Overview
This document describes the format for DEC files with the following goals:

Compatible
The DEC Format must maintain backward compatibility with any existing DEC file formats. This means that the changes made to this specification should not require changes to existing DEC files.

Simplified platform build and configuration


One goal of this format is to simplify the build setup and configuration for a given platform. It was also designed to simplify the process of developing EDK II firmware components.

1.2 Related Information


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

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

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

Version 1.22

April 2010

Introduction

DEC

EDK II DSC Specification, Intel, 2010. EDK II INF File Specification, Intel, 2010. EDK II FDF Specification, Intel, 2010. EDK II Build Specification, Intel, 2010. VFR Programming Language, Intel, 2010.

1.3 Terms
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.

DXE
Framework Driver Execution Environment phase.

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

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

DXE Runtime
Special class of DXE module that provides Runtime Services

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

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

EFI 1.10 Specification


Intel Corporation published the Extensible Firmware Interface Specification. Intel has donated the EFI specification to the Unified EFI Forum, and the UEFI now owns future updates of the EFI specification. See UEFI Specification Version 2.0.

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

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

April 2010

Version 1.22

DEC

Introduction

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

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

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

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

Library Instance
An implementation of one or more library classes.

Module
A module is either an executable image or a library instance.

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. See Table 2.

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

Protocol
An API named by a GUID as defined by this specification or other approved specifications.

PCD
Platform Configuration Database.

PEI
Pre-EFI Initialization Phase.

PPI
A PEIM-to-PEIM Interface that is named by a GUID as defined by the UEFI PI 1.2 Specification.

Version 1.22

April 2010

Introduction

DEC

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

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

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

SKU
Stock Keeping Unit.

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

UEFI Driver
A driver that follows the UEFI specification.

UEFI Specification Version 2.3


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

UEFI Platform Initialization Specification 1.2


Current version of the PI specification released by the Unified EFI Forum. This specification builds on the Intel Platform Innovation Framework for EFI specifications and transfers ownership of most of these specifications from Intel to a non-profit, industry trade organization.

Unified EFI Forum


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

VFR
Visual Forms Representation.

1.4 Target Audience


This document is intended for persons doing EFI development and support for different platforms, as well as development and support for distributable modules. It is most likely only of interest in the event that there is a problem with a build or if a developer needs to perform special customizations of a build for a platform.

April 2010

Version 1.22

DEC

Introduction

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 lowest address, while the high-order byte is at the highest address. Processors of the Intel Itanium processor family may be configured for both "little endian" and "big endian" operation. All implementations designed to conform to this specification will use "little endian" operation. In some memory layout descriptions, certain fields are marked reserved. Software must initialize such fields to zero and ignore them when read. On an update operation, software must preserve any reserved field. The data structures described in this document generally have the following format: Summary: Prototype: Example: A brief description of the data structure. An EBNF-type declaration for the data structure. 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 implementation of the Extensible Firmware Specification.

1.5.3 Typographic Conventions


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

Plain text Plain text (blue) Bold

The normal text typeface is used for the vast majority of the descriptive text in a specification. Any plain text that is underlined and in blue indicates an active link to the crossreference. Click on the word to follow the hyperlink. In text, a Bold typeface identifies a processor register name. In other instances, a Bold typeface can be used as a running head within a paragraph.

Version 1.22

April 2010

Introduction

DEC

Typographic Convention

Typographic convention description

Italic BOLD Monospace

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

Bold Monospace
$(VAR)

Italic Monospace

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

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

The following typographic conventions are used in this document to illustrate the Extended Backus-Naur Form.
[item] {item} <item> (range-range)

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. Parenthesis with characters and dash characters denote ranges of values, for example, (a-zA-Z0-9) indicates a single alphanumeric character, while (0-9) indicates a single digit. Characters within quotation marks are the exact content of an item, as they must appear in the output text file. The question mark denotes zero or one occurrences of an item. The star character denotes zero or more occurrences of an item. The plus character denotes one or more occurrences of an item. A superscript number, n, is the number occurrences of the item that must be used. Example: (0-9)8 indicates that there must be exactly eight digits, so 01234567 is valid, while 1234567 is not valid.

item ? * + item{n}

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. A superscript number, n, within curly brackets, preceded by a comma ,indicates a maximum number of occurrences of the item. A super script number, n, followed by a comma , and a number, m, indicates that the number of occurrences can be from n to m occurrences of the item, inclusive.

item{,n} item{n,m}

April 2010

Version 1.22

DEC

Introduction

Version 1.22

April 2010

Introduction

DEC

April 2010

Version 1.22

DEC

DEC File Overview

2 DEC File Overview


This document describes the format of EDK II package declaration (DEC) files. The DEC files are used by the EDK II utilities that parse EDK II DSC and EDK II INF files to generate AutoGen.c and AutoGen.h files for the EDK II build infrastructure. EDK II modules are located in subdirectories below the directory containing this file. If a module is a Library, the module directory must be created in the Library subdirectory. An Include subdirectory is also required, with the header file for the Library class placed in the sub-directory Include/Library/, and be called LibraryClassName.h. Additional content for the Include directory may include header files and potentially another Industry Standard directory.

Note: Path and Filename elements within the DEC are case-sensitive in order to support building on
UNIX style operating systems.

2.1 Usage Overview


The DEC file supports EDK II module builds. The file is used to define specific information that will be shared between different EDK II Modules. There are six possible sections in the DEC file. Within a DEC file, comments are encouraged, with the hash # character identifying a comment. All text after a comment character must be ignored by any parsing tool. Comment characters can be at the start of a line, or after a data element (there must be one or more white space characters between the data element and the comment character. Examples:
# this is a comment line [includes.common] # This is also a valid comment. [includes.common # This is not valid]

The last example is not valid, as the section header data element format is [text] with the square brackets included as part of the data element.

2.2 Declaration File Format


This section covers the format for the EDK II DEC files.

2.2.1 Section Entries


This declaration 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:
[Includes.X64, includes.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.22

April 2010

DEC File Overview

DEC

tags is from right to left, with sections defining an architecture having a higher precedence than a section which uses common (or no architecture extension) as the architecture.

Note: Content within a section IS case sensitive. IA32, Ia32 and ia32 within a section are processed as

separate items. (Refer to Naming Conventions below for more information on directory and/or file naming.)

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

2.2.2 Comments
The hash # character indicates comments in the Declaration (DEC) file. In line comments terminate the processing of a line unless the preceding character is the extension (backslash \) character. In line comments must be placed at the end of the line, and may not be placed within the section ([,]) tags. Only 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_COMPUTING_UNIT_MEMORY

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

Comments are terminated by the end of line. Doxygen tags are permitted in comment blocks preceding individual GUID, Protocol, PPI and PCD entries. These tags are used as containers for content required by the UEFI Packaging specification, and may also be used by tools. Each section will define the valid Doxygen tags which apply.

2.2.3 Valid Entries


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

10

April 2010

Version 1.22

DEC

DEC File Overview

2.2.4 Naming Conventions


The EDK II build infrastructure is supported under Microsoft* Windows*, Linux* and MAC OS/X operating systems. As a result of multiple environment support, all directory and file names must be treated as case sensitive. Additionally, the use of special characters in directory and file names is restricted to the dash-, underscore _ and period . characters. Under no circumstances can space characters be used in a directory or file names in EDK II. That said, the build tools must be able to process the tool definitions file: tools_def.txt (describing the location and flags for compiler and user defined tools) which will contain space characters in paths on Windows* systems. This file is the ONLY file that permits the use of space characters 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. Directory Names must not contain space characters. Directory Names should only contain alphanumeric characters, while the _ underscore, - dash and . period characters permitted. Directory names should start with an alpha character. Additionally, all EDK II directories that are architecturally dependent must use a name with only the first character capitalized. Ia32, Ipf, X64 and Ebc are valid architectural directory names. IA32, IPF and EBC are not acceptable directory names, and may cause build breaks. From a build tools perspective, IA32 is not equivalent to Ia32 or ia32. Architecture keywords (IA32, IPF, X64 and EBC) are used by build tools and in metadata files for describing alternate threads for processing of files. These keywords must not be used for describing directory paths. Additionally, directory names with architectural names (Ia32, Ipf, X64 and Ebc) do not automatically cause the build tools or meta-data files to follow these alternate paths. Directories and Architectural Keywords are similar in name only. All directory paths within EDK II 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 should also follow the same naming convention required for directories. No space characters are permitted. The special characters permitted in directory names are the only special characters permitted in file names.

2.2.5 !include Statements


The !include statement is NOT permitted in DEC files.

2.2.6 Macro Statements


Macro statements are permitted in the EDK II DEC files. Macro statements assign a Value to a Variable Name, and are only valid during the processing of the DEC specifying the value. If a value is not specified, then the MACRO has no value. Any defined MACRO definitions will be expanded by tools when they encounter the entry in the section. Four environment variables, $(WORKSPACE), $(EDK_SOURCE), $(EFI_SOURCE) and $(EDK_TOOLS_PATH) are never expanded when data is emitted to

Version 1.22

April 2010

11

DEC File Overview

DEC

Makefiles. 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. Table 1. Valid Variable Names for PATH statements
Exact Notation Derivation

$(WORKSPACE) $(EDK_TOOLS_PATH) $(EDK_SOURCE) $(EFI_SOURCE) $(OUTPUT_DIRECTORY) $(TARGET)

System Environment Variable. System Environment Variable. System Environment Variable. System Environment Variable. Tool parsing from either the DSC file or via a command line option. Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line options. Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line options.

$(TOOL_CHAIN_TAG)

2.2.7 PCD Names


Unique PCD names are defined as Pcd Token Space Guid C name and the Pcd C name separated by a period . character: PcdTokenSpaceGuidCName.PcdCName

Note: When using a Pcd name as a Token in a unicode strings file, the Pcd name is converted to all
upper case characters and the . dot character is replaced by an underscore.

2.2.8 Conditional Directive Statements (!if...)


Conditional statements are NOT permitted in EDK II DEC files.

2.3 [Defines] Usage


This is a required section. The [Defines] section is used to track the package's GUID and version, which allows multiple copies of the same package with different versions to exist within a single workspace. If major changes to a package occur, the GUID value of the package must also change. Additionally, the package's version major number may change. Minor changes require incrementing the package's version minor number. In addition, a pointer to a unicode strings file can be specified.

Note: The UCS2 formatted file content must conform to the UEFI HII string file format. The file can be

used to hold non-English string content (eliminating the need to convert a non-English string to a binary data array.) It may also be used to hold prompt and help strings used for HII setup screens and/or other third party tools.

This section will use only one section header:

12

April 2010

Version 1.22

DEC

DEC File Overview

[defines]

The format for entries in this section is:


Name = Value

The following is an example of this section.


[Defines] BASE_NAME FILE_GUID = DiskIo = CA261A26-7718-4b9b-8A07-5178B1AE3A02

2.4 [Includes] Usage


This is an optional section. The [includes] section is used to identify the standard location include directories provide by this EDK II package. The [includes] contains a list of package relative directory names. These directories contain sub-directories or header files. If the Package directory contains the directories, and the Include, Include/Ppis, Include/Protocol and Include/Guid, and header files exist in each of these directories, then all four directories will be listed in this section. Also included in this section are the directories containing headers that may be required for individual EDK II module types. Refer to Table 2 for a list of the valid types. Refer to the [includes] definition later in this document for a complete description of this section and its contents. The [includes] section uses one of the following section definitions:
[includes.common] [includes.IA32] [includes.X64] [includes.IPF] [includes.EBC]

The format for entries in this section is one field, with an optional comment # field as shown below:
Package_Relative/path # Comment such as Keyword List

2.5 [guids] Usage


This is an optional section. This section is used to define the Guid Value for Guid C Names. This section uses one of the following section definitions:
[guids] [guids.IA32] [guids.X64] [guids.IPF] [guids.EBC][guids.common] [guids.IA32, guids.X64] [guids.X64, [guids.IPF]

Format for the entries in this section is two fields with an equal = character separating the fields as shown below.
GuidCName = {C Format Guid Value} # Comment

The Comment section can be used to identify the list of supported module types.

2.6 [protocols] Usage


This is an optional section. This section is used to define the Guid Value for Protocol C Names. This section use ones of the following section definitions:
[protocols] [protocols.IA32] [protocols.X64] [protocols.IPF] [protocols.EBC]

Format for the entries in this section is two fields with an equal = character separating the fields as shown below.

Version 1.22

April 2010

13

DEC File Overview

DEC

ProtocolCName = {C Format Guid Value}

# Comment

The Comment section can be used to identify the list of supported module types.

2.7 [ppis] Usage


This section is used to define the Guid Value for PPI C Names. This is an optional section. This section use ones of the following section definitions:
[ppis] [ppis.IA32] [[ppis.X64] [ppis.IPF] [ppis.EBC]

Format for the entries in this section is two fields with an equal = character separating the fields as shown below.
PpiCName = {C Format Guid Value} # Comment

The Comment section can be used to identify the list of supported module types.

2.8 [libraryclasses] Usage


This section is used to define the headers associated with any new EDK II library classes. A Library Class is declared by a header file specified in this section. The component Library Instances that satisfy a Library Class must use the Library Class Header file, without modification. This is an optional section. Refer to the [libraryclasses] definition later in this document for a complete description of this section and its contents. This section uses one of the following section definitions:
[libraryclasses.common] [libraryclasses.IA32] [libraryclasses.X64] [libraryclasses.IPF] [libraryclasses.EBC]

Format for the entries in this section is two fields, with a pipe | character as the field separator, as shown below.
LibraryClassName|Relative/path/and/header_filename.h

2.9 [pcds] Usage


This section is used to describe basic information about a PCD. Refer to the PI 1.2 Specification for additional information regarding PCDs. Information in this section is used to create entries in the AutoGen.c and AutoGen.h files for EDK II modules. PCDs are usually defined by an industry specification that will define the name, token number, token space guid, datum type. A default value and valid usages may also be given in the industry specification. If a developer needs to create a new PCD, they can, following the conventions listed in the PCD specification listed above. Only PCDs that will be shared between multiple users need to be defined in published architectural specs. If a PCD is only going to be used by a single organization, then a new PCD can be created within the organization, keeping all modules that use the PCD internal to the organization. Every PCD (PcdName) is identified by a two part definition - the PCD's Token Space Guid CName and the PCD CName. These two parts are separated by a period . character. Together, these two parts make up the first field in a PCD Entry.

14

April 2010

Version 1.22

DEC

DEC File Overview

This is an optional section. Refer to the PCD Sections definition later in this document for a complete description of this section and its contents. This section resembles one of the following section definitions:
[PcdsFeatureFlag.common] [PcdsFixedAtBuild.IA32] [PcdsPatchableInModule.X64] [PcdsDynamic.IPF] [PcdsDynamicEx.EBC]

There are five PCD types, Feature Flag, Fixed At Build, Patchable In Module, Dynamic and DynamicEx. The format for entries in the PCDs sections is four fields, with a pipe | character as the field separator, as shown below:
# Comment TokenSpaceGuidCname.PcdCname|DefaultValue|DatumType|Token

The Comment section can be used to identify the list of supported module types as well as to contain conditional test statements for acceptable values.

2.10 [UserExtensions] Usage


The EDK II user extensions section allows for extending the DEC files with custom processing. The format for a user extension is:
[UserExtensions.$(UserID).$(Identifier)]

Data elements under the section header are not required; this is an optional section. Content of in this section is free form. The EDK II build tools available on TianoCore.org do not use this section. The reference tools ignore all content within a [UserExtensions] section. The following is an example of a User Extensions section.
[userextensions.Edk2AcpiTable."1.0"]

Version 1.22

April 2010

15

DEC File Overview

DEC

16

April 2010

Version 1.22

DEC

DEC File Format Specification

3 DEC File Format Specification


3.1 Introduction
This section of the document describes the DEC sections using an Extended BackusNaur Form. The DEC file has the following format (using the EBNF.)
<decFile> ::= <Defines> [<Include>] [<LibraryClass>] [<Guids>] [<Protocols>] [<Ppis>] [<Pcd>] [<UserExtensions>]

The general rules for all EDK II INI style documents follow. To append comment information to any item, the comment must start with a hash "#" character. The comment terminates with the end of line character. A section terminates with either another section definition or the end of the file. Field separators for single 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. Unless otherwise noted, the backslash character \ may be used to extend a line.

Note: Path and Filename elements within the DEC are case-sensitive in order to support building on
UNIX style operating systems.

3.2 Common Definitions


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

Version 1.22

April 2010

17

DEC File Format Specification

DEC

Prototype
<Word> <FieldSeparator> <Extension> <CName> <CFlags> <BareString> <QuotedString> <AsciiString> <Comment> <UnicodeString> <HexDigit> <HexNumber> <RegistryFormatGUID> <Hex8> <Hex4> <Hex12> <CFormatGUID> ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= AlphaNumeric characters "|" One or more alphanumeric characters. A valid C variable Name <String> <Word> [<Whitepace> <NonWhitesapce>]* {"'" <BareString> "'"} {""" <BareString> """} {<BareString> } {<QuotedString>} "#" [<AsciiString>] "L" <QuotedString> [a-zA-Z0-9] "0x" [<HexDigit>]+ <Hex8> <Hex4> <Hex4> <Hex4> <Hex12> "0x" <HexDigit>{8} "-" "0x" <HexDigit>{4} "-" "0x" <HexDigit>{12} "{ ", ", ", ", ", 0x" 0x" 0x" 0x" 0x" 0x" <HexDigit>{8} <HexDigit>{4} <HexDigit>{2} <HexDigit>{2} <HexDigit>{2} <HexDigit>{2} ", 0x" <HexDigit>{4} ", { 0x" <HexDigit>{2} ", 0x" <HexDigit>{2} ", 0x" <HexDigit>{2} ", 0x" <HexDigit>{2} " }}"}

<Integer> <DecimalNumber> <Number> <TrueFalse> <ZeroOne> <BoolVal> <WhiteSpace> <NonWhiteSpace>

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

[0-9]+ [{"+"} {"-"}] <Number> <Integer> ["." <Integer>] {"TRUE"} {"FALSE"} {"1"} {"0"} {<TrueFalse>} {<ZeroOne>} {<Tab>} {<Space>} {<Word>} {<SpecialCharacters>} {<Punctuation>}

18

April 2010

Version 1.22

DEC

DEC File Format Specification

<SpecialCharacters> <Punctuation> <EOL>

::= ::= ::=

One of the following: @#%^&*()+=|}{"></[]\`~'" One of ".", ",", "!", ":", ";" or "?" End Of Line, \n, character

Parameters
AlphaNumeric Characters
This is a combination of letters, numbers, and dash or underscore characters (either text or UNICODE.) White space, Special and Punctuation characters are not considered Alphanumeric characters.

Whitespace Characters
For EDK II, INI style documents a White space character is limited to either a space character or a tab character. New line, form feed and carriage return characters normally associated with the term White space, along with the alarm or beep character are not considered white space characters within EDK II, INI style documents.

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

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

End of Line Characters


The end of line characters in the context of the EDK II INI style documents, is the Newline, or \n character. Carriage Returns, \r and Form feed \f characters are not considered a newline, although a combination of \n\r can be interpreted as a newline character.

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

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

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

3.3 Header Comment Section


The Copyright and License notices for the INF file are in the comments that start the file. The format for the comment section is:

Version 1.22

April 2010

19

DEC File Format Specification

DEC

## @file # Abstract # # Description # # Copyright # # License # ##

This information can be derived from an XML Distribution package file (UEFI Packaging Specification) or from a developer creating a new package declaration (DEC) document. This is an optional section.

20

April 2010

Version 1.22

DEC

DEC File Format Specification

Prototype
<Header> ::= "## @file" <EOL> <Abstract> <Description> "#" <EOL> <Copyright> "#" <EOL> <License> "#" <EOL> "##" <EOL> "# " <Sentence> <EOL> "#" <EOL> ["# "<Sentence> <EOL>]* "#" <EOL> "# " <Sentence> <EOL> "#" <EOL> ["# " <Sentence> <EOL>]+ "#" <EOL>

<Abstract>

::=

<Description>

::=

<Copyright>

::=

<License>

::=

Example
## @file # Framework Module Development Environment Industry Standards # # This Package provides headers and libraries that conform to # EFI/Framework Industry standards. # # Copyright (c) 2006 - 2007, Intel Corporation. # # All rights reserved. # This program and the accompanying materials are licensed and made # available under the terms and conditions of the BSD License which # accompanies this distribution. # The full text of the license may be found at # http://opensource.org/licenses/bsd-license.php # # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR # IMPLIED. # ##

3.4 [Defines] Section


Summary
Defines:
The defines tag in the DEC files.

Version 1.22

April 2010

21

DEC File Format Specification

DEC

This file is required for using EDK II modules and Platforms. The code for this specification is 00010015 and new versions of this specification must increment the minor (0015) portion of the specification code. This section is required. Note that comments may be appended to define statements as well as located anywhere within the [Defines] section.

Prototype
<defines> ::= [defines] <EOL> DEC_SPECIFICATION PACKAGE_NAME PACKAGE_GUID PACKAGE_VERSION [PKG_UNI_FILE <Word> <RegistryFormatGuid> <Integer>{1,} 0x00010015 <Word> {.UNI} {.uni} # 8-4-4-4-12 = = = = = <SpecVer> <EOL> <UiNameType> <EOL> <RegistryGuid> <EOL> <Version> <EOL> <UnicodeFilename> <EOL>]

<UiNameType> <RegistryGuid> <Version> <SpecVer> <UnicodeFilename>

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

[. <Integer>{0,}]

Parameters
UnicodeFilename
A USC2 encoded file containing unicode prompt and help strings for PCD names declared by this package. The format of this file follows the UEFI HII Unicode String format. The entries in the Unicode file use a token which is constructed from a PCD name, with a modifier of _PROMPT or _HELP. The dot in the PCD name is replaced with an underscore character. Each PCD must also be prefixed with the STR_ string.

Version
The hex number consists of two parts, the major number and the minor number. The minor number is always a two digit value, where 1.2 is actually considered 1.20, with the hex value of 0014 for the minor part of the version value.

Example
[DEFINES] DEC_SPECIFICATION PACKAGE_NAME PACKAGE_GUID PACKAGE_VERSION PKG_UNI_FILE = = = = = 0x00010015 MdePkg 5e0e9358-46b6-4ae2-8218-4ab8b9bbdcec 0.3 MdePkgStrings.uni

3.5 [Includes] section


This section is optional.

22

April 2010

Version 1.22

DEC

DEC File Format Specification

Summary
Defines the Include section tag in the DEC files. This section lists the standard include locations provided in the package.

Prototype
<Include> ::= "[includes" [<archs>] "]" <EOL> [<statements>]+ "." <arch> ["," <arch>] [<IncSections>] [", includes." <arch>]* {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} <Path> [<CommentBlock>] <EOL>

<archs> <IncSections> <arch> <statements> <PATH> <Name> <CommentBlock>

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

<Name> ["/" <Name>]* <Word> "#" [" " <String>]

Note: Suggested string format for the Comment Block style is:
# [<Keyword>]* [";" <ModuleType>]* [";" <String>] <EOL> <ModuleTypeList> <ModuleType> ::= ::= <ModuleType> [, <ModuleType>]* {"BASE"} {"SEC"} {"PEI_CORE"} {"PEIM"} {"DXE_CORE"} {"DXE_DRIVER"} {"DXE_RUNTIME_DRIVER"} {"DXE_SAL_DRIVER"} {"DXE_SMM_DRIVER"} {"UEFI_DRIVER"} {"UEFI_APPLICATION"} {"USER_DEFINED"}

Version 1.22

April 2010

23

DEC File Format Specification

DEC

Example
####################################################################### # # Include section - list of Include Paths relative to the DEC file that # are provided by this package. # Comments are used for Keywords and Module Types. # ####################################################################### [Includes.common] Include [Includes.IA32] Include/Ia32 [Includes.X64] Include/X64 [Includes.IPF] Include/Ipf [Includes.EBC] Include/Ebc [Includes.ARM] Include/Arm

# Includes for all processor architectures

# Includes specific to IA32

# Includes specific to X64

# Includes specific to IA64

# Includes specific to EBC

# Includes specific to ARM

3.6 [Guids] Section


Summary
Defines the GUIDs secion tag of the DEC files. This section is optional.

24

April 2010

Version 1.22

DEC

DEC File Format Specification

Prototype
<Guids> ::= "[guids" [<arch>] "]" <EOL> <statements>+ <arch> ["," <arch>] [", guids." <arch>]* {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} <CName> "=" <GuidValue> [<CommentBlock>] <EOL> Valid C Name {<RegistryFormatGUID>} {<CFormatGUID> } # Reg: 8-4-4-4-12 # C: {8, 4, 4, { 2,2,2,2,2,2,2,2 }} "# " [" " <String>]

<archs> <arch> <statements> <CName> <GuidValue>

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

<CommentBlock>

::=

Note: Suggested string format for the Comment Block style is:
# <ModuleType> [";" <ModuleType>]* [";" <String> <EOL>] <ModuleTypeList> <ModuleType> ::= ::= <ModuleType> [, <ModuleType>]* {"BASE"} {"SEC"} {"PEI_CORE"} {"PEIM"} {"DXE_CORE"} {"DXE_DRIVER"} {"DXE_RUNTIME_DRIVER"} {"DXE_SAL_DRIVER"} {"DXE_SMM_DRIVER"} {"UEFI_DRIVER"} {"UEFI_APPLICATION"} {"USER_DEFINED"}

Restrictions
It is not permissible to list a GUID entry under common and under a specific architecture. It is permissible to specify GUID entries under all architectures except common if different GUID values may be required for different architectures.

Version 1.22

April 2010

25

DEC File Format Specification

DEC

Example
####################################################################### # # Global Guid Definition section - list of Global Guid C Name # Data Structures that are provided by # this package. # ####################################################################### [Guids.common] gPcdHobGuid = 0xF2, 0x98, 0xED, 0x58, 0x7B, 0xA6 gEfiWinNtPassThroughGuid = 0x34, 0xE8, 0x56, 0xBC, 0xE3, 0x6E gEfiWinNtCPUSpeedGuid = 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtCPUModelGuid = 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtMemoryGuid = 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtConsoleGuid = 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtUgaGuid = 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtGopGuid = 0x00, 0x80, 0xc7, 0x3c, 0x88, 0x81 gEfiWinNtSerialPortGuid = 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtFileSystemGuid = 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtPhysicalDisksGuid = 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtVirtualDisksGuid = 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiEdkNt32PkgTokenSpaceGuid = 0x61, 0xE6, 0x98, 0x2B, 0x32, 0xB4

{ 0x582E7CA1, }} { 0xCC664EB8, }} { 0xD4F29055, }} { 0xBEE9B6CE, }} { 0x99042912, }} { 0xBA73672C, }} { 0xAB248E99, }} { 0x4e11e955, }} { 0x0C95A93D, }} { 0x0C95A935, }} { 0x0C95A92F, }} { 0x0C95A928, }} { 0x0D79A645, }}

0x68CD, 0x4D44, { 0xB4, 0x3B, 0x3C24, 0x4086, { 0xB6, 0xF6, 0xE1FB, 0x11D4, { 0xBD, 0x0D, 0x2F8A, 0x11D4, { 0xBD, 0x0D, 0x122A, 0x11D4, { 0xBD, 0x0D, 0xA5D3, 0x11D4, { 0xBD, 0x00, 0xABE1, 0x11D4, { 0xBD, 0x0D, 0xccca, 0x11d4, { 0xbd, 0x0d, 0xA006, 0x11D4, { 0xBC, 0xFA, 0xA006, 0x11D4, { 0xBC, 0xFA, 0xA006, 0x11D4, { 0xBC, 0xFA, 0xA006, 0x11D4, { 0xBC, 0xFA, 0x1D91, 0x40a6, { 0xA8, 0x1F,

3.7 [Protocols] Section


Summary
Defines the Protocols section tag. This is a list of the global PROTOCOL C Names and their C Guid values that are declared in the EDK II package (.DEC) file. This is an optional section.

26

April 2010

Version 1.22

DEC

DEC File Format Specification

Prototype
<Protocols> ::= "[Protocols" [<archs>] "]" <EOL> [<statements>]+ "." <arch> ["," <arch>] [<ProtoStatements>] [", protocols." <arch>]* {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} <CName> "=" <GuidValue> [<CommentBlock>] <EOL> Valid C Name {<RegistryFormatGUID>} {<CFormatGUID>} # Reg: 8-4-4-4-12 # {8, 4, 4, { 2,2,2,2,2,2,2,2 }} "#" [<String>]

<archs> <ProtoStatements> <arch> <statements> <CName> <GuidValue>

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

<CommentBlock>

::=

Note: Suggested string format for the Comment Block style is:
# <ProtocolType> [";" <ModuleType>]* [";" <String> <EOL>] <ModuleTypeList> <ProtocolType> <ModuleType> ::= ::= ::= <ModuleType> [, <ModuleType>]* {"PROTOCOL"} {"PROTOCOL_NOTIFIY"} {"BASE"} {"SEC"} {"PEI_CORE"} {"PEIM"} {"DXE_CORE"} {"DXE_DRIVER"} {"DXE_RUNTIME_DRIVER"} {"DXE_SAL_DRIVER"} {"DXE_SMM_DRIVER"} {"UEFI_DRIVER"} {"UEFI_APPLICATION"} {"USER_DEFINED"}

Restrictions
It is NOT permissible to list a Protocol entry under common and under a specific architecture. It is permissible to specify Protocol entries under all architectures except common if different Guid values may be required for different architectures.

Version 1.22

April 2010

27

DEC File Format Specification

DEC

Example
####################################################################### # # Global Protocols Definition section - list of Global Protocols C Name # Data Structures that are provided by # this package. # ####################################################################### [Protocols.common] gEfiWinNtThunkProtocolGuid = { 0x58C518B1, 0x76F3, 0x11D4, { 0xBC, 0xEA, 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 }} gEfiWinNtIoProtocolGuid = { 0x96EB4AD6, 0xA32A, 0x11D4, { 0xBC, 0xFD, 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 }}

3.8 [PPIs] Section


Summary
Defines the optional PPI section tag. This is a list of the global PPI C Names that are referenced in the EDK II packages module C code. This is an optional section.

Prototype
<PPI> ::= "[ppis" [<archs>] "]" <EOL> [<statements>]+ "." <arch> ["," <arch>] [", ppis." <arch>]* {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} <CName> "=" <GuidValue> [<CommentBlock>] <EOL> Valid C Name {<RegistryForamtGUID> } {<CFormatGUID>} # Reg: 8-4-4-4-12 # {8, 4, 4, { 2,2,2,2,2,2,2,2 }}

<archs> <arch> <statements> <CName> <GuidValue>

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

<CommentBlock>

::=

"#" [<String>]

28

April 2010

Version 1.22

DEC

DEC File Format Specification

Note: Suggested string format for the Comment Block style is:
# <PpiType> [";" <ModuleType>]* [";" <String> <EOL>] <ModuleTypeList> <PpiType> <ModuleType> ::= ::= ::= <ModuleType> [, <ModuleType>]* {"PPI"} {"PPI_NOTIFIY"} {"BASE"} {"SEC"} {"PEI_CORE"} {"PEIM"} {"DXE_CORE"} {"DXE_DRIVER"} {"DXE_RUNTIME_DRIVER"} {"DXE_SAL_DRIVER"} {"DXE_SMM_DRIVER"} {"UEFI_DRIVER"} {"UEFI_APPLICATION"} {"USER_DEFINED"}

Restrictions
It is NOT permissible to list a PPI entry under common and under a specific architecture. It is permissible to specify PPI entries under all architectures except common if different Guid values may be required for different architectures.

Example
####################################################################### # # Global Ppis Definition section - list of Global Ppis C Name # Data Structures that are provided by # this package. # ####################################################################### [Ppis.common] gPeiNtThunkPpiGuid 0xB0, 0x03, 0xBF, 0x27, gNtPeiLoadFilePpiGuid 0xF4, 0x00, 0xEF, 0x13, gNtFwhPpiGuid 0xA8, 0x42, 0x13, 0x10, gPeiNtAutoScanPpiGuid 0x0F, 0x6E, 0xB6, 0x4D,

= 0x65, 0xDA = 0xBA, 0xC2 = 0x8A, 0x57 = 0x2A, 0xA9

{ 0x98C281E5, }} { 0xFD0C65EB, }} { 0x4E76928F, }} { 0x0DCE384D, }}

0xF906, 0x43DD, { 0xA9, 0x2B, 0x0405, 0x4CD2, { 0x8A, 0xEE, 0x50AD, 0x4334, { 0xB0, 0x6B, 0x007C, 0x4BA5, { 0x94, 0xBD,

3.9 [LibraryClasses] Section


Summary
Defines the libraryclass tag in the DEC files. The libraryclass section maps the location, relative to the DEC file, of LibraryClassName to the header file for the Library Classes. This section is optional.

Version 1.22

April 2010

29

DEC File Format Specification

DEC

Prototype
<libraryclass> ::= "[libraryclasses" [<attrs>]+ "]" <EOL> [<expression>]+ [", libraryclasses"] <arch> "." {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} <ClassName> "|" <Filename> [<CommentBlock>] <EOL> <Word> # A User Defined Keyword consisting of # alphanumeric characters. No special # characters are permitted. <RelativePath> <File> ".h" A word consisting of alphanumeric characters and optional special characters, dash "-" and underscore "_". Note space characters are not allowed in the name. Any valid path path name relative to this DEC file. Use of the .. character sequence for referencing directories outside of this directory structure is not permitted. "#" [<String>]

<attrs> <arch>

::= ::=

<expression> <ClassName>

::= ::=

<Filename> <File>

::= ::=

<RelativePath>

::=

<CommentBlock>

::=

Note: Suggested string format for the Comment Block style is:
# <ModuleTypeList> [";" <String> <EOL>] <ModuleTypeList> <ModuleType> ::= ::= <ModuleType> [, <ModuleType>]* {"BASE"} {"SEC"} {"PEI_CORE"} {"PEIM"} {"DXE_CORE"} {"DXE_DRIVER"} {"DXE_RUNTIME_DRIVER"} {"DXE_SAL_DRIVER"} {"DXE_SMM_DRIVER"} {"UEFI_DRIVER"} {"UEFI_APPLICATION"} {"USER_DEFINED"}

Restrictions
It is NOT permissible to list a Library Class entry under common and under a specific architecture. It is permissible to specify Library Class entries under all architectures except common if different header filename values are required for different architectures. Paths cannot contain indirect directory references outside of this package's directory tree (use of .. is not allowed in a directory path name.)

30

April 2010

Version 1.22

DEC

DEC File Format Specification

Example
####################################################################### # # Library Class Header section - list of Library Class header # files that are provided by # this package. # ####################################################################### [LibraryClasses.common] UefiRuntimeServicesTableLib|Include/Library/UefiRuntimeServicesTableLib.h UefiLib|Include/Library/UefiLib.h UefiDriverModelLib|Include/Library/UefiDriverModelLib.h UefiDriverEntryPoint|Include/Library/UefiDriverEntryPoint.h UefiDecompressLib|Include/Library/UefiDecompressLib.h UefiBootServicesTableLib|Include/Library/UefiBootServicesTableLib.h TimerLib|Include/Library/TimerLib.h SmbusLib|Include/Library/SmbusLib.h ResourcePublicationLib|Include/Library/ResourcePublicationLib.h PostCodeLib|Include/Library/PostCodeLib.h ReportStatusCodeLib|Include/Library/ReportStatusCodeLib.h PrintLib|Include/Library/PrintLib.h PerformanceLib|Include/Library/PerformanceLib.h PeiServicesTablePointerLib|Include/Library/PeiServicesTablePointerLib.h PeimEntryPoint|Include/Library/PeimEntryPoint.h PeiServicesLib|Include/Library/PeiServicesLib.h PeiCoreEntryPoint|Include/Library/PeiCoreEntryPoint.h PeCoffLib|Include/Library/PeCoffLib.h BaseLib|Include/Library/BaseLib.h [LibraryClasses.IA32] UefiApplicationEntryPoint|Include/Library/UefiApplicationEntryPoint.h UEFI_APPLICATION [LibraryClasses.X64] UefiApplicationEntryPoint|Include/Library/UefiApplicationEntryPoint.h UEFI_APPLICATION [LibraryClasses.IPF] UefiApplicationEntryPoint|Include/Library/UefiApplicationEntryPoint.h UEFI_APPLICATION [LibraryClasses.EBC] UefiApplicationEntryPoint|Include/Library/UefiApplicationEntryPoint.h UEFI_APPLICATION

3.10 PCD Sections


Summary
Defines the Pcds tag in the DEC files. The Pcd is used to define potential values that a module might be coded against, and that a platform will define the final usage This is an optional section.

Version 1.22

April 2010

31

DEC File Format Specification

DEC

Prototype
<pcds> ::= "[" <UsageType> <attrs> "]" <EOL> [<expression>]+ {PcdsFeatureFlag} {PcdsPatchableInModule} {PcdsFixedAtBuild} {PcdsDynamic} {PcdsDynamicEx} "." <arch> [", <UsageType> ." <arch>]* {"IA32"} {"X64"} {"IPF"} {"EBC"} {"common"} [<CommentBlock>] <PcdName> "|" <PcdDefinition> <TokenSpaceGuidCName> "." <PcdCName> <DatumInfo> "|" <Token> [<OrigCommentBlock>] <EOL> Valid C variable name "0x" [a-fA-F0-9]{8} Valid C variable name IF UsageType == FeatureFlag <BoolType> ELSE {<BoolType>} {<NumType>} {<PtrType>} <BooleanDefaultValue> "|" "BOOLEAN" <TrueOrFalse> {<TrueFalse>} {<ZeroOne>] {"TRUE"} {"FALSE"} {"0"} {"1"} <NumDefaultValue> "|" <NumDatumType> <NumVal> {<NonNegativeInt>} {<HexValue>} {"UINT8"} {"UINT16"} {"UINT32"} {"UINT64"} [0-9]+ "0x" [a-fA-F0-9]+ <PtrDefaultValue> "|" "VOID*" {<String>} {<DataArray>}

<UsageType>

::=

<attrs> <arch> <expression>

::= ::= ::=

<PcdName> <PcdDefinition> <PcdCName> <Token> <TokenSpaceGuidCName> <DatumInfo>

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

<BoolType> <BooleanDefaultValue> <TrueOrFalse> <TrueFalse> <ZeroOne> <NumType> <NumDefaultValue> <NumVal> <NumDatumType> <NonNegativeInt> <HexValue> <PtrType> <PtrDefaultValue>

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

32

April 2010

Version 1.22

DEC

DEC File Format Specification

<String> <DataArray> <CommentBlock>

::= ::= ::=

{<AsciiString>} {<UnicodeString>} {<TokenName>} "{" <HexValue> ["," <HexValue>]* "}" [# @ValidRange <RangeValues> <EOL>] [# @ValidList <ValidValueList> <EOL>] [# <String> <EOL>]* "#" [<String>]

<OrigCommentBlock>

::=

Note: Suggested string format for the Original Comment Block style is:
# <ModuleTypeList> [";" <String> <EOL>] <ModuleTypeList> <ModuleType> ::= ::= <ModuleType> [, <ModuleType>]* {"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"} {<ValidRange>} {<RangeExpressions>} ( <ValidRange> ) AND ( <ValidRange> ) ( <ValidRange> ) OR ( <ValidRange> ) {<Integer> "-" <Integer>} {<HexValue> "-" <HexValue>} {LT {<Integer>} {<HexValue>} {GT {<Integer>} {<HexValue>} {LE {<Integer>} {<HexValue>} {GE {<Integer>} {<HexValue>} <NumValue> [, <NumValue>]+ {<Integer>} {<HexValue>} Valid C variable name consisting of characters in range: (A-Z_)

<RangeValues> <RangeExpressions>

::= ::=

<ValidRange>

::=

<ValidValueList> <NumValue> <TokenName>

::= ::= ::=

Parameters
RangeExpressions
This is required to be an in-fix logical expression, evaluated left to right, for a range of values, using Relational, Equality and Logical Operators (LT, LE, GT, GE.) The forms PcdCName and/or PcdTokenSpaceGuidCName.PcdCName are permitted; if only the PcdCName is specified, then the PcdTokenSpaceGuidCName is the same as this PCD's TokenSpaceGuidCName. Parentheses are recommended for clarity.

TokenName
This is the name of a token in a UCS2, UEFI HII format string file specified in the [defines] section of this DEC file. There are two predefined extensions to a PCD token, _PROMPT and _HELP. When tools parse the UCS2 file, the PcdName specified in this file is used for a token name is converted to all uppercase

Version 1.22

April 2010

33

DEC File Format Specification

DEC

characters and the . dot separating the token space GUID c name and the PCDs c name is replace with an underscore character. For example: gMyTSGuidCname.myPcdName will be converted to a imocpde version of: GMYTSGUIDCNAME_MYPCDNAME when used as a token in the Unicode file.

Restrictions
It is NOT permissible to list a pcd entry under common and under a specific architecture. It is permissible to specify Pcd entries under all architectures except common if different default values may be required for different architectures. It is permissible to specify multiple architectures for like UsageType items in the same section header. For example:
[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64]

It is permissible to mix PatchPcd, FixedPcd, Pcd and PcdEx UsageType elements within an architecture section. For example:
[PcdsPatchableInModule.IA32, PcdsFixedAtBuild.IA32]

The PcdsFeatureFlag UsageType may not be mixed with any other UsageType elements in the section header. The following example is NOT VALID:
[PcdsFeatureFlag.IA32, PcdsFixedAtBuild.IA32]

Refer to the PI 1.2 Specification for more information.

34

April 2010

Version 1.22

DEC

DEC File Format Specification

Example
######################################################################### # # PCD Declarations section - list of all PCDs Declared by this package # Only this package should be providing the # declaration, other packages should not. # ######################################################################### [PcdsFeatureFlag.common] gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable | FALSE | BOOLEAN | 0x0000000d gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable | FALSE | BOOLEAN | 0x0000000e [PcdsFixedAtBuild.common] gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF|UINT8|0x00000008 gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x0f|UINT8|0x00000005 gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength | 1000000 | UINT32 | 0x00000002 gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength | 1000000 | UINT32 | 0x00000003 gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength | 1000000 | UINT32 | 0x00000001 gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask | 0 | UINT8 | 0x00000009 gEfiMdePkgTokenSpaceGuid.PcdPostCodePropertyMask|0|UINT8|0x0000000b gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask | 0x06 | UINT8 | 0x00000007 gEfiMdePkgTokenSpaceGuid.PcdSpinLockTimeout|10000000|UINT32|0x00000004 [FixedPcd.common, PcdsPatchableInModule.common] gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel | 0x80000000 | UINT32 | 0x00000006 gEfiMdePkgTokenSpaceGuid.PcdFSBClock|200000000|UINT32|0x0000000c gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress | 0xE0000000 | UINT64 | 0x0000000a [FixedPcd.IPF] gEfiMdePkgTokenSpaceGuid.PcdIoBlockBaseAddressForIpf | 0x0ffffc00000 | UINT64 | 0x0000000c

3.11 [UserExtensions] Section


Summary
Defines the optional EDK II DEC file UserExtensions tag. The build tools must have an a priori knowledge of how to process any items in this section. Tools provided on TianoCore.org ignore this section. This is an optional section.

Version 1.22

April 2010

35

DEC File Format Specification

DEC

Prototype
<UserExtensions> ::= "[userextensions" <UserId> <IdString> "]" <EOL> [<statements>] "." <Word> "." <QuotedString> {"'" <String> "'"} {""" <String> """>} Content is build tool chain specific.

<UserId> <IdString> <QuotedString> <statements>

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

Example
[UserExtensions.MyVendorName."MySpecialFiles"] Any content supported module types.

36

April 2010

Version 1.22

DEC

Appendix A DEC Examples


Note: The "\" line continuation character is used here for clarity, but is not permitted in actual DSC files. Continued lines are
indented to match the indentation of the beginning of the line.

A.1 EDK II MdeModulePkg Example


## @file # Mde Module Package Reference Implementations # # This module provides headers and libraries that conform to EFI/PI Industry # standards. # # Copyright (c) 2007, Intel Corporation. # # All rights reserved. # This program and the accompanying materials are licensed and made available # under the terms and conditions of the BSD License which accompanies this # distribution. The full text of the license may be found at # http://opensource.org/licenses/bsd-license.php # # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. # ##

[Defines] DEC_SPECIFICATION PACKAGE_NAME PACKAGE_GUID PACKAGE_VERSION [Includes.common] Include [Guids.common]

= = = =

0x00010015 MdeModulePkg BA0D78D6-2CAF-414b-BD4D-B6762A894288 0.1

gPcdDataBaseHobGuid = \ { 0xEA296D92, 0x0B69, 0x423C, { 0x8C, gEfiMdeModulePkgTokenSpaceGuid = \ { 0xA1AFF049, 0xFDEB, 0x442a, { 0xB3, gPcdPeiCallbackFnTableHobGuid = \ { 0xC625F4B2, 0xEA09, 0x4675, { 0x82, gEfiSystemNvDataFvGuid = \ { 0xFFF12B8D, 0x7696, 0x4C8B, { 0xA9, gEfiSystemNvDataHobGuid = \ { 0xD6E5092D, 0xC7B2, 0x4872, { 0xAF, gEfiDiskInfoUsbInterfaceGuid = \

0x28, 0x33, 0xB4, 0xE0, 0xA9, 0x12, 0x68 }} 0x20, 0x13, 0xAB, 0x4C, 0xB7, 0x2B, 0xBC }} 0xD7, 0xBA, 0x36, 0x82, 0x15, 0x7A, 0x14 }} 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50 }} 0x66, 0xFD, 0xC0, 0xE6, 0xF9, 0x5E, 0x78 }}

Version 1.22

April 2010

37

DEC

{ 0xCB871572, 0xC11A, 0x47B5, { 0xB4, 0x92, gEfiDiskInfoScsiInterfaceGuid = \ { 0x08F74BAA, 0xEA36, 0x41D9, { 0x95, 0x21, gEfiDiskInfoIdeInterfaceGuid = \ { 0x5E948FE3, 0x26D3, 0x42B5, { 0xAF, 0x17, gEfiAlternateFvBlockGuid = \ { 0xF496922D, 0x172F, 0x4BBC, { 0xA1, 0xEB, gEfiConsoleOutDeviceGuid = \ { 0xD3B36F2C, 0xD551, 0x11D4, { 0x9A, 0x46, gEfiConsoleInDeviceGuid = \ { 0xD3B36F2B, 0xD551, 0x11D4, { 0x9A, 0x46, gEfiHotPlugDeviceGuid = \ { 0x220AC432, 0x1D43, 0x49E5, { 0xA7, 0x4F, gEfiPrimaryConsoleOutDeviceGuid = \ { 0x62BDF38A, 0xE3D5, 0x492C, { 0x95, 0x0C, gEfiPrimaryConsoleInDeviceGuid = \ { 0xE451DCBE, 0x96A1, 0x4729, { 0xA5, 0xCF, gEfiPrimaryStandardErrorDeviceGuid = \ { 0x5A68191B, 0x9B97, 0x4752, { 0x99, 0x46, gEfiDefaultBmpLogoGuid = \ { 0x7BB28B99, 0x61BB, 0x11D5, { 0x9A, gEfiBootStateGuid = \ { 0x60B5E939, 0x0FCF, 0x4227, { 0xBA, gEfiMemoryTypeInformationGuid = \ { 0x4C19049F, 0x4137, 0x4DD3, { 0x9C, gEfiCapsuleVendorGuid = \ { 0x711C703F, 0xC285, 0x4B10, { 0xA3, gPeiPerformanceHobGuid = \ { 0xEC4DF5AF, 0x4395, 0x4CC9, { 0x94, gEfiGenericPlatformVariableGuid = \ { 0x59d1c24f, 0x50f1, 0x401a, { 0xb1, gEfiShellFileGuid { 0xC57AD6B7, 0x0515, 0x40A8, gEfiFlashMapHobGuid { 0xB091E7D2, 0x05A0, 0x4198, gEfiStandardErrorDeviceGuid { 0xD3B36F2D, 0xD551, 0x11D4, gEfiPeiCorePrivateGuid { 0xd641a0f5, 0xcb7c, 0x4846, = \ { 0x9D, = \ { 0x94, = \ { 0x9A, = \ { 0xa3,

0x67, 0x5E, 0xAF, 0xA7, 0x77, 0x27 }} 0x21, 0xA7, 0x0F, 0x87, 0x80, 0xBC }} 0x61, 0x02, 0x87, 0x18, 0x8D, 0xEC }} 0x0E, 0xEB, 0x94, 0x9C, 0x34, 0x86 }} 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }} 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }} 0x4C, 0x9D, 0xA6, 0x7A, 0xD2, 0x3B }} 0x23, 0xA7, 0xF6, 0x6E, 0x67, 0x2E }} 0x6B, 0x9C, 0x2C, 0xFF, 0x47, 0xFD }} 0xE3, 0x6A, 0x5D, 0xA9, 0x42, 0xB1 }}

0x5D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }} 0x83, 0x6B, 0xBE, 0xD4, 0x5B, 0xC0, 0xE3 }} 0x10, 0x8B, 0x97, 0xA8, 0x3F, 0xFD, 0xFA }} 0xB0, 0x36, 0xEC, 0xBD, 0x3C, 0x8B, 0xE2 }} 0xDE, 0x77, 0x50, 0x6D, 0x12, 0xC7, 0xB8 }} 0x01, 0xf3, 0x3e, 0x0d, 0xae, 0xd4, 0x43 }}

0x21, 0x55, 0x16, 0x52, 0x85, 0x4E, 0x37 }} 0xF0, 0x74, 0xB7, 0xB8, 0xC5, 0x54, 0x59 }} 0x46, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }} 0x80, 0x1d, 0x01, 0xb4, 0xd9, 0xe3, 0xb9 }}

gEfiPeiPeCoffLoaderGuid = \ { 0xD8117CFF, 0x94A6, 0x11D4, { 0x9A, 0x3A, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D }} [Protocols.common] gEfiCapsuleArchProtocolGuid = \ { 0x5053697E, 0x2EBC, 0x4819, { 0x90, 0xD9, 0x05, 0x80, 0xDE, 0xEE, 0x57, 0x54 }} gEfiLoadPeImageProtocolGuid =\ { 0x5CB5C776, 0x60D5, 0x45EE, { 0x88, 0x3C, 0x45, 0x27, 0x08, 0xCD, 0x74, 0x3F }} gEfiPrintProtocolGuid = \ { 0xDF2D868E, 0x32FC, 0x4CF0, { 0x8E, 0x6B, 0xFF, 0xD9, 0x5D, 0x13, 0x43, 0xD0 }} gEfiGenericMemTestProtocolGuid = \ { 0x309DE7F1, 0x7F5E, 0x4ACE, { 0xB4, 0x9C, 0x53, 0x1B, 0xE5, 0xAA, 0x95, 0xEF }}

38

April 2010

Version 1.22

DEC

gEfiDiskInfoProtocolGuid = \ { 0xD432A67F, 0x14DC, 0x484B, { 0xB3, 0xBB, 0x3F, 0x02, 0x91, 0x84, 0x93, 0x27 }} gEfiFvbExtensionProtocolGuid = \ { 0x53A4C71B, 0xB581, 0x4170, { 0x91, 0xB3, 0x8D, 0xB8, 0x7A, 0x4B, 0x5C, 0x46 }} gEfiFaultTolerantWriteLiteProtocolGuid = \ { 0x3F557189, 0x8DAE, 0x45AE, { 0xA0, 0xB3, 0x2B, 0x99, 0xCA, 0x7A, 0xA7, 0xA0 }} gEfiConsoleControlProtocolGuid = \ { 0xF42F7782, 0x012E, 0x4C12, { 0x99, 0x56, 0x49, 0xF9, 0x43, 0x04, 0xF7, 0x21 }} gEfiOEMBadgingProtocolGuid = \ { 0x170E13C0, 0xBF1B, 0x4218, { 0x87, 0x1D, 0x2A, 0xBD, 0xC6, 0xF8, 0x87, 0xBC }} gEfiUsbAtapiProtocolGuid = \ { 0x2B2F68DA, 0x0CD2, 0x44CF, { 0x8E, 0x8B, 0xBB, 0xA2, 0x0B, 0x1B, 0x5B, 0x75 }} gPerformanceProtocolGuid = \ { 0x76B6BDFA, 0x2ACD, 0x4462, { 0x9E, 0x3F, 0xCB, 0x58, 0xC9, 0x69, 0xD9, 0x37 }} gEfiCrc32GuidedSectionExtractionProtocolGuid = \ { 0xFC1BCDB0, 0x7D31, 0x49aa, {0x93, 0x6A, 0xA4, 0x60, 0x0D, 0x9D, 0xD0, 0x83 } } gEfiFirmwareVolumeDispatchProtocolGuid = \ { 0x7AA35A69, 0x506C, 0x444F, { 0xA7, 0xAF, 0x69, 0x4B, 0xF5, 0x6F, 0x71, 0xC8 }} gEfiTianoDecompressProtocolGuid = \ { 0xE84CF29C, 0x191F, 0x4EAE, { 0x96, 0xE1, 0xF4, 0x6A, 0xEC, 0xEA, 0xEA, 0x0B }} gEfiCustomizedDecompressProtocolGuid = \ { 0x9A44198E, 0xA4A2, 0x44E6, { 0x8A, 0x1F, 0x39, 0xBE, 0xFD, 0xAC, 0x89, 0x6F }} gEfiNicIp4ConfigProtocolGuid = \ {0xdca3d4d, 0x12da, 0x4728, { 0xbf, 0x7e, 0x86, 0xce, 0xb9, 0x28, 0xd0, 0x67 }} gEfiNicIp4ConfigVariableGuid = \ {0xd8944553, 0xc4dd, 0x41f4, { 0x9b, 0x30, 0xe1, 0x39, 0x7c, 0xfb, 0x26, 0x7b }} gEfiTcpProtocolGuid = \ { 0x02b3d5f2, 0xac28, 0x11d3, { 0x9a, 0x2d, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d }} gEfiPxeDhcp4CallbackProtocolGuid = \ { 0xc1544c01, 0x92a4, 0x4198, {0x8a, 0x84, 0x77, 0x85, 0x83, 0xc2, 0x36, 0x21 } } gEfiPxeDhcp4ProtocolGuid = \ { 0x03c4e624, 0xac28, 0x11d3, {0x9a, 0x2d, 0x00, 0x90, 0x29, 0x3f, 0xc1, 0x4d } } [Ppis.common] gPeiBaseMemoryTestPpiGuid = \ { 0xB6EC423C, 0x21D2, 0x490D, { 0x85, 0xC6, 0xDD, 0x58, 0x64, 0xEA, 0xA6, 0x74 }} ##gPeiFlashMapPpiGuid will be removed in future gPeiFlashMapPpiGuid = \ { 0xf34c2fa0, 0xde88, 0x4270, {0x84, 0x14, 0x96, 0x12, 0x22, 0xf4, 0x52, 0x1c } } [PcdsFeatureFlag.common] gEfiMdeModulePkgTokenSpaceGuid.PcdSupportUpdateCapsuleRest | FALSE|BOOLEAN|0x0001001d gEfiMdeModulePkgTokenSpaceGuid.PcdPeiPcdDatabaseTraverseEnabled | TRUE|BOOLEAN|0x00010020 gEfiMdeModulePkgTokenSpaceGuid.PcdDxePcdDatabaseTraverseEnabled | TRUE|BOOLEAN|0x00010021 gEfiMdeModulePkgTokenSpaceGuid.PcdPeiPcdDatabaseSetEnabled | TRUE|BOOLEAN|0x00010030 gEfiMdeModulePkgTokenSpaceGuid.PcdPeiPcdDatabaseGetSizeEnabled | TRUE|BOOLEAN|0x00010031 gEfiMdeModulePkgTokenSpaceGuid.PcdPeiPcdDatabaseCallbackOnSetEnabled | TRUE|BOOLEAN|0x00010032 gEfiMdeModulePkgTokenSpaceGuid.PcdPeiPcdDatabaseExEnabled | TRUE|BOOLEAN|0x00010033 gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSupportEfiDecompress | TRUE|BOOLEAN|0x00010034 gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSupportTianoDecompress | TRUE|BOOLEAN|0x00010035 gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSupportCustomDecompress | TRUE|BOOLEAN|0x00010036

Version 1.22

April 2010

39

DEC

gEfiMdeModulePkgTokenSpaceGuid.PcdDevicePathSupportDevicePathToText | FALSE|BOOLEAN|0x00010037 gEfiMdeModulePkgTokenSpaceGuid.PcdDevicePathSupportDevicePathFromText | FALSE|BOOLEAN|0x00010038 gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplBuildShareCodeHobs | FALSE|BOOLEAN|0x0001003c gEfiMdeModulePkgTokenSpaceGuid.PcdNtEmulatorEnable|FALSE|BOOLEAN|0x0001003e [PcdsFixedAtBuild.common] gEfiMdeModulePkgTokenSpaceGuid.PcdMaxPeiPcdCallBackNumberPerPcdEntry | 0x08|UINT32|0x0001000f gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0|UINT32|0x00010010 gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizePopulateCapsule | 0x0|UINT32|0x0001001e gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule | 0x0|UINT32|0x0001001f gEfiMdeModulePkgTokenSpaceGuid.PcdMaxPeiPerformanceLogEntries | 28|UINT8|0x0001002f gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0 | UINT32|0x30000001 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0 | UINT32|0x30000002 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0 | UINT32|0x30000013 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0 | UINT32|0x30000014 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0 | UINT32|0x30000010 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0 | UINT32|0x30000011 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueMouseInterfaceError | 0x01020005|UINT32|0x30001000 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueMouseEnable|0x01020004 | UINT32|0x30001001 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueMouseDisable|0x01020002 | UINT32|0x3001002 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueKeyboardEnable|0x01010004 | UINT32|0x3001003 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueKeyboardDisable|0x01010002 | UINT32|0x3001004 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueKeyboardPresenceDetect | 0x01010003|UINT32|0x30001005 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueKeyboardReset|0x01010001 | UINT32|0x30001006 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueKeyboardClearBuffer | 0x01011000|UINT32|0x30001007 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueKeyboardSelfTest | 0x01011001|UINT32|0x30001008 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueKeyboardInterfaceError | 0x01010005|UINT32|0x30001009 gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueKeyboardInputError | 0x01010007|UINT32|0x3000100a gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueMouseInputError|0x01020007 | UINT32|0x30001000b gEfiMdePkgTokenSpaceGuid.PcdStatusCodeValueMouseReset|0x01020001|UINT32 | 0x30001000c [PcdsDynamic.common] gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0 | UINT32|0x30000001 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0|UINT32 | 0x30000002 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0 | UINT32|0x30000013 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize | 0x0|UINT32|0x30000014 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase | 0x0|UINT32|0x30000010 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize | 0x0|UINT32|0x30000011 [PcdsPatchableInModule.common] gEfiMdeModulePkgTokenSpaceGuid.PcdMaxPeiPerformanceLogEntries | 28|UINT8|0x0001002f gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase | 0x0|UINT32|0x30000001 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize | 0x0|UINT32|0x30000002 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase | 0x0|UINT32|0x30000013 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize | 0x0|UINT32|0x30000014 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase | 0x0|UINT32|0x30000010 gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize | 0x0|UINT32|0x30000011

[PcdsFeatureFlag.IA32] gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode | TRUE | BOOLEAN | 0x0001003b

40

April 2010

Version 1.22

DEC

A.2 EDK II Nt32Pkg Example


## @file # EFI/PI Reference Module Package for All Architectures # # This DEC file is used for Package Level build. # # Copyright (c) 2007, Intel Corporation # # All rights reserved. This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD # License which accompanies this distribution. The full text of the license # may be found at # http://opensource.org/licenses/bsd-license.php # # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. # ## ################################################################################ # # Defines Section - statements that will be processed to create a Makefile. # ################################################################################ [Defines] DEC_SPECIFICATION PACKAGE_NAME PACKAGE_GUID PACKAGE_VERSION

= = = =

0x00010015 Nt32Pkg 0fb2aa2d-10d5-40a5-a9dc-060c12a4a3f3 0.1

################################################################################ # # Include Section - list of Include Paths that are provided by this package. # Comments are used for Keywords and Module Types. # # Supported Module Types: # SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER # DXE_SAL_DRIVER UEFI_DRIVER # ################################################################################ [Includes.common] Include # Root include for the package

################################################################################ # # Library Class Header section - list of Library Class header files that are # provided by this package. # ################################################################################ [LibraryClasses.common] WinNtLib|Include/Library/WinNtLib.h EdkGenericBdsLib|Include/Library/EdkGenericBdsLib.h

Version 1.22

April 2010

41

DEC

################################################################################ # # Global Guid Definition section - list of Global Guid C Name Data Structures # that are provided by this package. # ################################################################################ [Guids.common] gEfiWinNtPassThroughGuid = \ { 0xCC664EB8, 0x3C24, 0x4086, { 0xB6, 0xF6, 0x34, 0xE8, 0x56, 0xBC, 0xE3, 0x6E gEfiWinNtConsoleGuid = \ { 0xBA73672C, 0xA5D3, 0x11D4, { 0xBD, 0x00, 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtUgaGuid = \ { 0xAB248E99, 0xABE1, 0x11D4, { 0xBD, 0x0D, 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtGopGuid = \ { 0x4e11e955, 0xccca, 0x11d4, { 0xbd, 0x0d, 0x00, 0x80, 0xc7, 0x3c, 0x88, 0x81 gEfiWinNtSerialPortGuid = \ { 0x0C95A93D, 0xA006, 0x11D4, { 0xBC, 0xFA, 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtFileSystemGuid = \ { 0x0C95A935, 0xA006, 0x11D4, { 0xBC, 0xFA, 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtPhysicalDisksGuid = \ { 0x0C95A92F, 0xA006, 0x11D4, { 0xBC, 0xFA, 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiWinNtVirtualDisksGuid = \ { 0x0C95A928, 0xA006, 0x11D4, { 0xBC, 0xFA, 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 gEfiNt32PkgTokenSpaceGuid = \ { 0x0D79A645, 0x1D91, 0x40a6, { 0xA8, 0x1F, 0x61, 0xE6, 0x98, 0x2B, 0x32, 0xB4

}} }} }} }} }} }} }} }} }}

################################################################################ # # Global Protocols Definition section - list of Global Protocols C Name Data # Structures that are provided by this package. # ################################################################################ [Protocols.common] gWinNtBusDriverGuid = \ { 0x0419f582, 0x0625, 0x4531, { 0x8a, 0x33, 0x85, 0xa9, 0x96, 0x5c, 0x95, 0xbc }} gEfiWinNtThunkProtocolGuid = \ { 0x58C518B1, 0x76F3, 0x11D4, { 0xBC, 0xEA, 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 }} gEfiWinNtIoProtocolGuid = \ { 0x96EB4AD6, 0xA32A, 0x11D4, { 0xBC, 0xFD, 0x00, 0x80, 0xC7, 0x3C, 0x88, 0x81 }} ################################################################################ # # Global Ppis Definition section - list of Global Ppis C Name Data Structures # that are provided by this package. # ################################################################################ [Ppis.common] gPeiNtThunkPpiGuid = \ { 0x98c281e5, 0xf906, 0x43dd, { 0xa9, 0x2b, 0xb0, 0x03, 0xbf, 0x27, 0x65, 0xda }} gPeiNtAutoScanPpiGuid = \ { 0x0dce384d, 0x007c, 0x4ba5, { 0x94, 0xbd, 0x0f, 0x6e, 0xb6, 0x4d, 0x2a, 0xa9 }} gNtPeiLoadFilePpiGuid = \

42

April 2010

Version 1.22

DEC

{ 0xfd0c65eb, 0x0405, 0x4cd2, { 0x8a, 0xee, 0xf4, 0x0, 0xef, 0x13, 0xba, 0xc2 }} gNtFwhPpiGuid = \ { 0x4e76928f, 0x50ad, 0x4334, {0xb0, 0x6b, 0xa8, 0x42, 0x13, 0x10, 0x8a, 0x57 }} ############################################################################### # # PCD Declarations section - list of all PCDs Declared by this Package # Only this package should be providing the # declaration, other packages should not. # ############################################################################### [PcdsFixedAtBuild.common] gEfiNt32PkgTokenSpaceGuid.PcdWinNtBootMode|1|UINT32|0x00001006 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFirmwareVolume | L"..\\Fv\\Fv_Recovery.fd"|VOID*|0x00001009 gEfiNt32PkgTokenSpaceGuid.PcdWinNtMemorySizeForSecMain | L"64!64"|VOID*|0x0000100c gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageEventLogBase | 0x0|UINT32|0x0000100e gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageEventLogSize | 0x0|UINT32|0x0000100f gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashFvRecoveryBase|0x0|UINT32|0x00001010 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashFvRecoverySize|0x0|UINT32|0x00001011 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFirmwareFdSize|0x0|UINT32|0x00001012 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFirmwareBlockSize|0|UINT32|0x00001013 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageVariableBase | 0x0|UINT32|0x00001014 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageFtwSpareBase | 0x0|UINT32|0x00001015 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageFtwWorkingBase | 0x0|UINT32|0x00001016 [PcdsDynamic.common] gEfiNt32PkgTokenSpaceGuid.PcdWinNtPhysicalDisk | L"E:RW;245760;512"|VOID*|0x00001000 gEfiNt32PkgTokenSpaceGuid.PcdWinNtVirtualDisk | L"FW;40960;512"|VOID*|0x00001001 gEfiNt32PkgTokenSpaceGuid.PcdWinNtSerialPort | L"COM1!COM2"|VOID*|0x00001002 gEfiNt32PkgTokenSpaceGuid.PcdWinNtUga | L"UGA Window 1!UGA Window 2"| VOID* | 0x00001003 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFileSystem |\ L".!..\\..\\..\\..\\EdkShellBinPkg\\bin\\ia32\\Apps" |VOID*|0x00001004 gEfiNt32PkgTokenSpaceGuid.PcdWinNtMemorySize|L"64!64"|VOID*|0x00001005 gEfiNt32PkgTokenSpaceGuid.PcdWinNtCpuModel | L"Intel(R) Processor Model" | VOID*|0x00001007 gEfiNt32PkgTokenSpaceGuid.PcdWinNtCpuSpeed|L"3000"|VOID*|0x00001008 gEfiNt32PkgTokenSpaceGuid.PcdWinNtConsole | L"Bus Driver Console Window" | VOID*|0x0000100a gEfiNt32PkgTokenSpaceGuid.PcdWinNtGop | L"UGA Window 1!UGA Window 2" | VOID*|0x0000100d [PcdsPatchableInModule.common] gEfiNt32PkgTokenSpaceGuid.PcdWinNtBootMode|1|UINT32|0x00001006 gEfiNt32PkgTokenSpaceGuid.PcdWinNtFirmwareVolume | L"..\\Fv\\Fv_Recovery.fd"|VOID*|0x00001009 gEfiNt32PkgTokenSpaceGuid.PcdWinNtMemorySizeForSecMain | L"64!64"|VOID*|0x0000100c

Version 1.22

April 2010

43

DEC

44

April 2010

Version 1.22

DEC

Appendix B HII String Files


This chapter describes the restrictions and extensions for using the UEFI HII String files for storing prompt and help text for elements of the DEC file.

B.1 Use of HII String File Data


The TokenName references that are made in the DEC file can be resolved by retrieving the data from the package.UNI file, specified in the [defines] section. The format of the file follows the format specified in the UEFI specification. The TokenName in the String file must use all uppercase characters (and optional underscore characters.) A TokenName reference which is associated with a PCD values prompt will have a _PROMPT as a suffix. A TokenName reference which is associated with a PCD values help will have a _HELP as a suffix. A TokenName reference which is associated with a PCD will have a STR_ as a prefix.

Version 1.22

April 2010

45

DEC

46

April 2010

Version 1.22

DEC

Appendix C Module Types


Table 2. EDK II Module Types
MODULE_TYPE Supported Architecture Types Any Description

BASE

Modules or Libraries can be ported to any execution environment. This module type is intended to be used 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. This module type is used by PEI Core implementations that are compliant with the PI 1.2 Specification. This module type is used by PEIMs that are compliant with PI 1.2. This module type is used by DXE Core implementations that are compliant with the PI 1.2 Specification. This module type is used by DXE Drivers that are compliant with the PI 1.2 Specification. This module type is used by DXE Drivers that are compliant to the PI 1.2 Specification. These modules execute in both boot services and runtime services environments. 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() has been called. This module type is only available for IPF processor types. This module type is used by DXE Drivers that are loaded into SMRAM. This is the SMM core. This module type is used by UEFI Drivers that are compliant with the EFI 1.10 and UEFI 2.0 specifications. These modules provide services in the boot services execution environment. UEFI Drivers that return EFI_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 and EFI 2.0 specifications. UEFI Applications are always unloaded when they exit.

SEC

Any

PEI_CORE PEIM DXE_CORE

Any Any Any

DXE_DRIVER DXE_RUNTIME_DRIVER

Any Any

DXE_SAL_DRIVER

IPF

DXE_SMM_DRIVER SMM_CORE UEFI_DRIVER

IA32, X64 Any Any

UEFI_APPLICATION

Any

Version 1.22

April 2010

47

DEC

48

April 2010

Version 1.22

You might also like