BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
Remove EDK and IPF related contents inf Fdf spec.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.f...@intel.com>
Cc: Liming Gao <liming....@intel.com>
Cc: Jaben Carsey <jaben.car...@intel.com>
---
1_introduction/11_overview.md
| 22 +++-------------------
1_introduction/12_terms.md
| 8 +-------
1_introduction/README.md
| 9 ++-------
2_fdf_design_discussion/22_flash_description_file_format.md
| 34 ++++++++++++----------------------
2_fdf_design_discussion/24_[fd]_sections.md
| 9 ++-------
2_fdf_design_discussion/25_[fv]_sections.md
| 9 +++------
2_fdf_design_discussion/{28_[rule]_sections.md => 27_[rule]_sections.md}
| 232
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------------------------------------------------------------------------
2_fdf_design_discussion/27_[vtf]_sections.md
| 82
----------------------------------------------------------------------------------
2_fdf_design_discussion/{29_[optionrom]_sections.md =>
28_[optionrom]_sections.md} | 112
++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------------
2_fdf_design_discussion/README.md
| 2 --
3_edk_ii_fdf_file_format/310_[vtf]_section.md
| 203
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3_edk_ii_fdf_file_format/{311_pci_optionrom_section.md =>
310_pci_optionrom_section.md} | 228
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------------------------------------------------------------------
3_edk_ii_fdf_file_format/31_general_rules.md
| 13 +------------
3_edk_ii_fdf_file_format/32_fdf_definition.md
| 67
+++++--------------------------------------------------------------
README.md
| 1 +
SUMMARY.md
| 8 +++-----
appendix_a_nt32pkg_flash_description_file.md
| 4 ++--
17 files changed, 321 insertions(+), 722 deletions(-)
diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
index 6db8a26..d7dbb20 100644
--- a/1_introduction/11_overview.md
+++ b/1_introduction/11_overview.md
@@ -1,9 +1,9 @@
<!--- @file
1.1 Overview
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
Redistribution and use in source (original document form) and 'compiled'
forms (converted to PDF, epub, HTML and other formats) with or without
modification, are permitted provided that the following conditions are met:
@@ -47,26 +47,10 @@ that comply with the UEFI specifications listed above.
The FDF file describes the content and layout of binary images that are either
a boot image or PCI Option ROMs.
This document describes the format of EDK II FDF files that are required for
-building binary images for an EDK II platform. The goals are:
-
-* **Compatibility** - No compatibility with EDK FDF files exists in format
- or tools.
+building binary images for an EDK II platform. The goal is
* **Simplified platform build and configuration** - The FDF files simplify the
- process of adding EDK components and EDK II modules to a firmware volume on
- any given platform.
-
-The EDK build tools are provided as part of the EdkCompatibilityPkg which is
-included in EDK II.
-
-Table 1 shows the FDF compatibility between platform, module and component
-builds.
-
-###### Table 1 EDK Build Infrastructure Support Matrix
+ process of adding EDK II modules to a firmware volume on any given platform.
-| | EDK FDF | EDK II FDF | EDK DSC | EDK II DSC |
-| ------------------ |:-------:|:----------:|:-------:|:----------:|
-| EDK Build Tools | YES | NO | YES | NO |
-| EDK II Build Tools | NO | YES | NO | YES |
diff --git a/1_introduction/12_terms.md b/1_introduction/12_terms.md
index abb857b..c3d238b 100644
--- a/1_introduction/12_terms.md
+++ b/1_introduction/12_terms.md
@@ -1,9 +1,9 @@
<!--- @file
1.2 Terms
- Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
Redistribution and use in source (original document form) and 'compiled'
forms (converted to PDF, epub, HTML and other formats) with or without
modification, are permitted provided that the following conditions are met:
@@ -108,16 +108,10 @@ the Intel(R) Platform Innovation Framework for EFI
Specifications developed in
**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 and EDK II
-platforms.
-
**EFI**
Generic term that refers to one of the versions of the EFI specification: EFI
1.02, EFI 1.10or any of the UEFI specifications.
diff --git a/1_introduction/README.md b/1_introduction/README.md
index e67e88a..c0725ec 100644
--- a/1_introduction/README.md
+++ b/1_introduction/README.md
@@ -1,9 +1,9 @@
<!--- @file
1 Introduction
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
Redistribution and use in source (original document form) and 'compiled'
forms (converted to PDF, epub, HTML and other formats) with or without
modification, are permitted provided that the following conditions are met:
@@ -38,11 +38,6 @@ II modules within the EDK II build infrastructure.
The EDK II Build Infrastructure supports generation of current Unified EFI,
Inc. (UEFI 2.5 and PI 1.4) compliant binary images.
The FDF file is used to describe the content and layout of binary images.
Binary images described in this file may be any combination of boot images,
-capsule images or PCI Options ROMs.
-
-**********
-**Note:** EDK II FDF file formats have no similarity to EDK FDF file formats.
-New utilities and functionality have been provided to process these files.
-**********
+capsule images or PCI Options ROMs.
\ No newline at end of file
diff --git a/2_fdf_design_discussion/22_flash_description_file_format.md
b/2_fdf_design_discussion/22_flash_description_file_format.md
index 3ea818f..336122c 100644
--- a/2_fdf_design_discussion/22_flash_description_file_format.md
+++ b/2_fdf_design_discussion/22_flash_description_file_format.md
@@ -1,9 +1,9 @@
<!--- @file
2.2 Flash Description File Format
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
Redistribution and use in source (original document form) and 'compiled'
forms (converted to PDF, epub, HTML and other formats) with or without
modification, are permitted provided that the following conditions are met:
@@ -37,14 +37,12 @@ must already exist in order for the build tools to create
the final images.
Some content, such as PCD definitions, may be used during the creation of
binary files.
### 2.2.1 Section Entries
-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
+To simplify parsing, the EDK II meta-data files use the INI format.
+EDK II formats differ from the defacto format
in that the semicolon ";" character cannot be used to indicate a comment.
Leading and trailing space/tab characters must be ignored.
It is recommended that duplicate section names be merged by tools.
@@ -78,11 +76,11 @@ Duplicate sections (two sections with identical section
tags) will be merged by
tools, with the second section appended to the first.
The EDK II Reference build system will ignore [UserExtensions] sections in the
FDF file.
-The `[Rules]` and `[VTF]` sections allow the use of architectural modifiers,
+The `[Rules]` section allows the use of architectural modifiers,
however the content must specific to an individual architecture or common to
all architectures.
Therefore, the architectural sections take priority over common section
content. The cannot be combined with a 'common' architecture.
@@ -157,12 +155,12 @@ all directory and file names are case sensitive.
* Directory Names must only contain alphanumeric characters, underscore or dash
characters and it is recommended that they 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
+ use a name with only the first character capitalized. Ia32, X64 and Ebc
+ are valid architectural directory names. IA32 and EBC are not acceptable
directory names, and may cause build breaks. From a build tools perspective,
an IA32 directory name is not equivalent to Ia32 or ia32 An architecture used
in a directory name must be listed in a section that uses the architecture
modifier. If a common section contains filenames that have directories with
architecture modifiers, the file will be processed for all architectures, not
@@ -177,14 +175,14 @@ use of space characters in the directory name.
The EDK II Coding Style specification covers naming conventions for use within
C Code files, and as well as specifying the rules for directory and file names.
This section is meant to highlight those rules as they apply to the content of
the FDF files.
-Architecture keywords (`IA32`, `IPF`, `X64` and `EBC`) are used by build tools
+Architecture keywords (`IA32`, `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
+directory names with architectural names (Ia32, 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.
For clarity, this specification will use all upper case letters when describing
@@ -215,20 +213,18 @@ contain complete sections, or combination of both. The
keyword `!include`
is case-insensitive.
The argument of this statement is a filename. The file is relative to the
directory that contains this DSC file, and if not found the tool must attempt
to find the file relative to paths listed in the system environment variables,
-`$(WORKSPACE)`, `$(PACKAGES_PATH)`, `$(EFI_SOURCE)`, `$(EDK_SOURCE)`, and
-`$(ECP_SOURCE)`. If the file is not found after testing for the possible
-combinations, the parsing tools must terminate with an error.
+`$(WORKSPACE)`, and `$(PACKAGES_PATH)`. If the file is not found after testing
+for the possible combinations, the parsing tools must terminate with an error.
Macros, defined in this FDF file or in the DSC file, are permitted in the
path or file name of the !include statement, as these files are included prior
to processing the file for macros. The system environment variables,
-`$(WORKSPACE)`, `$(EDK_SOURCE)`, `$(EFI_SOURCE)`, and `$(ECP_SOURCE)` may also
-be used; only these system environment variables are permitted to start the
-path of the included file.
+`$(WORKSPACE)` may also be used; only that system environment variables are
+permitted to start the path of the included file.
Statements in !include files must not break the integrity of the FDF file, the
included file is read in by tools in the exact position of the file, and is
functionally equivalent of copying the contents of the included file and
inserting (paste) the content into the DSC file.
@@ -379,15 +375,12 @@ that may be used in EDK II DSC and FDF files are in the
next table.
| Exact Notation | Derivation
|
| --------------------- |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
| `$(WORKSPACE)` | System Environment Variable.
|
| `PACKAGES_PATH` | System Environment Variable that cannot be used in
EDK II meta-data Files. The build system will automatically detect if this
variable is present and use directories listed in this variable as if they were
listed in $(WORKSPACE) |
-| `$(EDK_SOURCE)` | System Environment Variable.
|
-| `$(EFI_SOURCE)` | System Environment Variable.
|
| `$(EDK_TOOLS_PATH)` | System Environment Variable
|
| `EDK_TOOLS_BIN` | System Environment Variable that cannot be used in
EDK II meta-data Files.
|
-| `$(ECP_SOURCE)` | System Environment Variable
|
| `$(OUTPUT_DIRECTORY)` | Tool parsing from either the DSC file or via a
command line option. This is typically the Build/Platform name directory
created by the build system in the EDK II WORKSPACE
|
| `$(BUILD_NUMBER)` | Tool parsing from either an EDK INF file or the EDK
II DSC file's `BUILD_NUMBER` statement. The EDK II DSC file's `BUILD_NUMBER`
takes precedence over an EDK INF file's
|
| | `BUILD_NUMBER` if and only if the EDK II DSC
specifies a
|
| | `BUILD_NUMBER`.
|
| | Future implementation may allow for setting the
|
@@ -408,14 +401,11 @@ must not be altered.
###### Table 3 Using System Environment Variable
| Macro Style Used in Meta-Data files | Windows Environment Variable | Linux &
OS/X Environment Variable |
| ------------------- | ------------------ | ----------------- |
| `$(WORKSPACE)` | `%WORKSPACE%` | `$WORKSPACE` |
-| `$(EFI_SOURCE)` | `%EFI_SOURCE%` | `$EFI_SOURCE` |
-| `$(EDK_SOURCE)` | `%EDK_SOURCE%` | `$EDK_SOURCE` |
| `$(EDK_TOOLS_PATH)` | `%EDK_TOOLS_PATH%` | `$EDK_TOOLS_PATH` |
-| `$(ECP_SOURCE)` | `%ECP_SOURCE%` | `$ECP_SOURCE` |
The system environment variables, `PACKAGES_PATH` and `EDK_TOOLS_BIN`, are not
permitted in EDK II meta-data files.
Macros defined in the FDF file are local to the FDF file. They are also
diff --git a/2_fdf_design_discussion/24_[fd]_sections.md
b/2_fdf_design_discussion/24_[fd]_sections.md
index 67e478e..fc0fb14 100644
--- a/2_fdf_design_discussion/24_[fd]_sections.md
+++ b/2_fdf_design_discussion/24_[fd]_sections.md
@@ -1,9 +1,9 @@
<!--- @file
2.4 [FD] Sections
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
Redistribution and use in source (original document form) and 'compiled'
forms (converted to PDF, epub, HTML and other formats) with or without
modification, are permitted provided that the following conditions are met:
@@ -227,15 +227,10 @@ region starting at the "Offset", of length "Size" must
not be touched (unless
the region will be used for VPD data). This type of region is typically used
for
event logs that are persistent between system resets, and modified via some
other mechanism (and Each FD region has a `UiName` modifier, then the output
image files uses the `UiName` modifier for the file name.
-**********
-**Note:** Although sub-regions existed in EDK FDF files, EDK II FDF does not
-use the concept of subregions.
-**********
-
#### 2.4.4.1 FV RegionType
The `FV RegionType` is a pointer to either one of the unique FV names that are
defined in the `[FV]` section. Both of these are files that contains a binary
FV
as defined by the PI 1.0 specification. The format for the `FV RegionType` is
@@ -329,11 +324,11 @@ gEfiTokenSpaceGuid.PcdCapsuleOffset |
gEfiTokenSpaceGuid.PcdCapsuleSize
CAPSULE = MyCapsule
```
#### 2.4.4.5 INF Region Type
-The INF statements point to EDK component and EDK II module INF files. Parsing
+The INF statements point to EDK II module INF files. Parsing
tools will scan the INF file to determine the type of component or module. The
component or module type is used to reference the standard rules defined
elsewhere in the FDF file.
The format for INF statements is:
diff --git a/2_fdf_design_discussion/25_[fv]_sections.md
b/2_fdf_design_discussion/25_[fv]_sections.md
index 4d3566d..e7bdba0 100644
--- a/2_fdf_design_discussion/25_[fv]_sections.md
+++ b/2_fdf_design_discussion/25_[fv]_sections.md
@@ -1,9 +1,9 @@
<!--- @file
2.5 [FV] Sections
- Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
Redistribution and use in source (original document form) and 'compiled'
forms (converted to PDF, epub, HTML and other formats) with or without
modification, are permitted provided that the following conditions are met:
@@ -93,11 +93,10 @@ used for identifying other items or values that will be
used in later statements
`DEFINE MACRO = VALUE`
The following are examples of the `DEFINE` statement.
```
-DEFINE EDKMOD = $(WORKSPACE)/EdkModulePkg/
DEFINE MDE_MOD_TSPG = gEfiMdeModulePkgTokenSpaceGuid
DEFINE NV_STOR_VAR_SIZE = PcdFlashNvStorageVariableSize
DEFINE FV_HDR_SIZE = 0x48
DEFINE VAR_STORE_SIZE = $(MDE_MOD_TSPG).$(NV_STOR_VAR_SIZE) - $(FV_HDR_SIZE)
```
@@ -194,11 +193,11 @@ image, named Dxe, there will be at least five FFS files,
the `APRIORI` file,
listing the GUID names of `a.inf`, `c.inf` and `b.inf`, which will be
dispatched in this order. Once complete, the `d.inf` module will be dispatched.
### 2.5.5 INF Statements
-The INF statements point to EDK component and EDK II module INF files. Parsing
+The INF statements point to EDK II module INF files. Parsing
tools will scan the INF file to determine the type of component or module. The
component or module type is used to reference the standard rules defined
elsewhere in the FDF file.
The format for INF statements is:
@@ -468,13 +467,11 @@ The following keywords are used for valid `LEAF_SECTION`
types.
* `SUBTYPE_GUID` -- A GUID value with content defined by the GUID to be used
with
the section type of `EFI_SECTION_FREEFORM_SUBTYPE_GUID`.
The argument, `build #`, is only valid for `VERSION` leaf section. The number
may be specified in the platform description (DSC) file's `[Defines]` section,
-`BUILD_NUMBER` element. EDK INF files may specify a `BUILD_NUMBER` in the
-defines section. However, this value is only used if the EDK II DSC file does
-not contain a `BUILD_NUMBER` statement.
+`BUILD_NUMBER` element.
The **_Filename_** is only optional for `VERSION` and `UI`.
A Unicode string is only valid for `VERSION` or `UI` if the Filename is not
present, and is of the form `L"string"`.
diff --git a/2_fdf_design_discussion/28_[rule]_sections.md
b/2_fdf_design_discussion/27_[rule]_sections.md
similarity index 95%
rename from 2_fdf_design_discussion/28_[rule]_sections.md
rename to 2_fdf_design_discussion/27_[rule]_sections.md
index 27b8873..4c7e5a1 100644
--- a/2_fdf_design_discussion/28_[rule]_sections.md
+++ b/2_fdf_design_discussion/27_[rule]_sections.md
@@ -1,116 +1,116 @@
-<!--- @file
- 2.8 [Rule] Sections
-
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
-
- Redistribution and use in source (original document form) and 'compiled'
- forms (converted to PDF, epub, HTML and other formats) with or without
- modification, are permitted provided that the following conditions are met:
-
- 1) Redistributions of source code (original document form) must retain the
- above copyright notice, this list of conditions and the following
- disclaimer as the first lines of this file unmodified.
-
- 2) Redistributions in compiled form (transformed to other DTDs, converted to
- PDF, epub, HTML and other formats) must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in the
- documentation and/or other materials provided with the distribution.
-
- THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS
OR
- IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
- EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
- SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
- OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
- WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
- OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
- ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
--->
-
-## 2.8 [Rule] Sections
-
-The optional `[Rule]` sections in the FDF file are used for combining binary
-images, not for compiling code. Rules are use with the `[FV]` section's module
-INF type to define how an FFS file is created for a given INF file. The EDK II
-Build Specification defines the default rules that are implicitly used for
-creating FFS files. The implicit rules follow the _PI Specification_ and
-_UEFI Specification_.
-
-The `[Rule]` section of the FDF file is used to define custom rules, which may
-be applied to a given INF file listed in an `[FV]` section. This section is
-also used to define rules for module types that permit the user to define the
-content of the FFS file - when an FFS type is not specified by either PI or
-UEFI specifications.
-
-The Rules can have multiple modifiers as shown below.
-
-`[Rule.ARCH.MODULE_TYPE.TEMPLATE_NAME]`
-
-If no `TEMPLATE_NAME` is given then the match is based on `ARCH` and
-`MODULE_TYPE` modifiers. `BINARY` is a reserved `TEMPLATE_NAME` as a default
rule
-name for binary modules. The `TEMPLATE_NAME` must be unique to the `ARCH` and
-`MODULE_TYPE`. It is permissible to use the same `TEMPLATE_NAME` for two or
-more `[Rule]` sections if the `ARCH` or the `MODULE_TYPE` listed are different
-for each of the sections.
-
-A `[Rule]` section is terminated by another section header or the end of file.
-
-The content of the `[Rule]` section is based on the `FILE` and section grammar
-of the FV section. The difference is the `FILE` referenced in the `[RULE]` is a
-`MACRO`. The section grammar is extended to include an optional argument,
-`Optional`. The `Optional` argument is used to say a section is optional. That
-is to say, if it does not exist, then it is O.K.
-
-**********
-**Note:** The `!include` statement is valid for any part of the `[Rule]`
-section, including an entire `[Rule]` section.
-**********
-
-The generic form of the entries for leaf sections is:
-
-`<SectionType> <FileType> [Options] [{<Filename>} {<Extension>}]`
-
-When processing the FDF file, the following rules apply (in order):
-
-1. If `<SectionType>` not defined or not a legal name, then error
-2. If `<FileType>` not defined or not a legal name, then error
-3. If `[FilePath/FileName]`, then:
- Add one section to FFS with a section type of `<SectionType>`
-4. Else:
- Find all files defined by the INF file whose file type is `<FileType>` and
- add each one to the FFS with a section type of `<SectionType>` in
- alphabetical order.
- Add files defined in `[Sources]` followed by files defined in `[Binaries]`
-
-5. If > 1 `UI` section in final FFS, then error
-6. If > 1 `VER` section in final FFS, then error
-7. If > 1 `PEI_DEPEX` section in final FFS, then error
-8. If > 1 `DXE_DEPEX` section in final FFS, then error
-9. If > 1 `SMM_DEPEX` section in final FFS, then error
-
-If a rule specifies a file type, instead of specifying specific file names, the
-files that match the extension must be processed in alphabetical order.
-
-#### Example
-
-```ini
-[Rule.Common.ACPITABLE]
- FILE FREEFORM = $(NAMED_GUID) {
- RAW ACPI Optional |.acpi
- RAW ASL Optional |.aml
- }
-```
-
-Tools must add the processed .acpi files alphabetically, followed by the .aml
-files which must also be added alphabetically.
-
-The file would contain:
-
-`<SOF>a1.acpi, a2.acpi, b1.acpi, b2.acpi, a.aml, b.aml<EOF>`
-
-where, start of file is `<SOF>` and end of file is `<EOF>`
-
-Refer to the _EDK II INF File Specification_ for a description of the
-`FileType` for binary files.
+<!--- @file
+ 2.8 [Rule] Sections
+
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS
OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## 2.7 [Rule] Sections
+
+The optional `[Rule]` sections in the FDF file are used for combining binary
+images, not for compiling code. Rules are use with the `[FV]` section's module
+INF type to define how an FFS file is created for a given INF file. The EDK II
+Build Specification defines the default rules that are implicitly used for
+creating FFS files. The implicit rules follow the _PI Specification_ and
+_UEFI Specification_.
+
+The `[Rule]` section of the FDF file is used to define custom rules, which may
+be applied to a given INF file listed in an `[FV]` section. This section is
+also used to define rules for module types that permit the user to define the
+content of the FFS file - when an FFS type is not specified by either PI or
+UEFI specifications.
+
+The Rules can have multiple modifiers as shown below.
+
+`[Rule.ARCH.MODULE_TYPE.TEMPLATE_NAME]`
+
+If no `TEMPLATE_NAME` is given then the match is based on `ARCH` and
+`MODULE_TYPE` modifiers. `BINARY` is a reserved `TEMPLATE_NAME` as a default
rule
+name for binary modules. The `TEMPLATE_NAME` must be unique to the `ARCH` and
+`MODULE_TYPE`. It is permissible to use the same `TEMPLATE_NAME` for two or
+more `[Rule]` sections if the `ARCH` or the `MODULE_TYPE` listed are different
+for each of the sections.
+
+A `[Rule]` section is terminated by another section header or the end of file.
+
+The content of the `[Rule]` section is based on the `FILE` and section grammar
+of the FV section. The difference is the `FILE` referenced in the `[RULE]` is a
+`MACRO`. The section grammar is extended to include an optional argument,
+`Optional`. The `Optional` argument is used to say a section is optional. That
+is to say, if it does not exist, then it is O.K.
+
+**********
+**Note:** The `!include` statement is valid for any part of the `[Rule]`
+section, including an entire `[Rule]` section.
+**********
+
+The generic form of the entries for leaf sections is:
+
+`<SectionType> <FileType> [Options] [{<Filename>} {<Extension>}]`
+
+When processing the FDF file, the following rules apply (in order):
+
+1. If `<SectionType>` not defined or not a legal name, then error
+2. If `<FileType>` not defined or not a legal name, then error
+3. If `[FilePath/FileName]`, then:
+ Add one section to FFS with a section type of `<SectionType>`
+4. Else:
+ Find all files defined by the INF file whose file type is `<FileType>` and
+ add each one to the FFS with a section type of `<SectionType>` in
+ alphabetical order.
+ Add files defined in `[Sources]` followed by files defined in `[Binaries]`
+
+5. If > 1 `UI` section in final FFS, then error
+6. If > 1 `VER` section in final FFS, then error
+7. If > 1 `PEI_DEPEX` section in final FFS, then error
+8. If > 1 `DXE_DEPEX` section in final FFS, then error
+9. If > 1 `SMM_DEPEX` section in final FFS, then error
+
+If a rule specifies a file type, instead of specifying specific file names, the
+files that match the extension must be processed in alphabetical order.
+
+#### Example
+
+```ini
+[Rule.Common.USER_DEFINED.ACPITABLE]
+ FILE FREEFORM = $(NAMED_GUID) {
+ RAW ACPI Optional |.acpi
+ RAW ASL Optional |.aml
+ }
+```
+
+Tools must add the processed .acpi files alphabetically, followed by the .aml
+files which must also be added alphabetically.
+
+The file would contain:
+
+`<SOF>a1.acpi, a2.acpi, b1.acpi, b2.acpi, a.aml, b.aml<EOF>`
+
+where, start of file is `<SOF>` and end of file is `<EOF>`
+
+Refer to the _EDK II INF File Specification_ for a description of the
+`FileType` for binary files.
diff --git a/2_fdf_design_discussion/27_[vtf]_sections.md
b/2_fdf_design_discussion/27_[vtf]_sections.md
deleted file mode 100644
index 5ef35a9..0000000
--- a/2_fdf_design_discussion/27_[vtf]_sections.md
+++ /dev/null
@@ -1,82 +0,0 @@
-<!--- @file
- 2.7 [VTF] Sections
-
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
-
- Redistribution and use in source (original document form) and 'compiled'
- forms (converted to PDF, epub, HTML and other formats) with or without
- modification, are permitted provided that the following conditions are met:
-
- 1) Redistributions of source code (original document form) must retain the
- above copyright notice, this list of conditions and the following
- disclaimer as the first lines of this file unmodified.
-
- 2) Redistributions in compiled form (transformed to other DTDs, converted to
- PDF, epub, HTML and other formats) must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in the
- documentation and/or other materials provided with the distribution.
-
- THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS
OR
- IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
- EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
- SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
- OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
- WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
- OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
- ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
--->
-
-## 2.7 [VTF] Sections
-
-The optional `[VTF]` sections specify information regarding the IPF Boot Strap
-File (BSF) or the IA32 Volume Top File (VTF). Both the `ARCH` and the `UiName`
-modifier fields are required. The `[VTF]` section terminates with either the
-start of another section, or the end of the file.
-
-The `[VTF]` section modifier usage is shown below.
-
-`[VTF.ARCH.UiName]`
-
-Underneath the `[VTF]` section are specific statements defining information
-about the VTF file. EDK Bsf.inf files use two different sections, an
`[OPTIONS]`
-section and a `[COMPONENTS]` section. For EDK II, the grammar of the `[VTF]`
-section statements defines these sections, rather than having separate
-sub-sections within the `[VTF]` section.
-
-The format for statements within the section is illustrated below.
-
-`STATEMENT_NAME = Value`
-
-The component version number (`COMP_VER`) values are binary coded decimal
-(1 byte for the major number and 1 byte for the minor number). As a result, the
-maximum value is "99.99".
-
-### 2.7.1 Options Statement
-
-One and only one options statement, "IA32_RST_BIN", is permitted within any
-one `[VTF]` section. This value is a path and name of `IA32_BIOS` reset vector
-binary (16 byte) file. If needed, this binary can be put into the VTF file.
-
-### 2.7.2 Component Statements
-
-Within the section, a components sub-section starts with the "COMP_NAME"
-statement, and terminates with either the start of another sub-section, major
-section or the end of the file. Certain values for component statements are
-enumerated values or values that are within a given, specification defined,
-range.
-
-Each of the component sections is used to complete a data structure, using the
-following sequence.
-
-```c
-Name = Region,
- Type,
- Version,
- Checksum Flag,
- Path of Binary File,
- Path of the Symbol File,
- Preferred Size;
-```
diff --git a/2_fdf_design_discussion/29_[optionrom]_sections.md
b/2_fdf_design_discussion/28_[optionrom]_sections.md
similarity index 94%
rename from 2_fdf_design_discussion/29_[optionrom]_sections.md
rename to 2_fdf_design_discussion/28_[optionrom]_sections.md
index 1f7af01..d5e782b 100644
--- a/2_fdf_design_discussion/29_[optionrom]_sections.md
+++ b/2_fdf_design_discussion/28_[optionrom]_sections.md
@@ -1,56 +1,56 @@
-<!--- @file
- 2.9 [OptionRom] Sections
-
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
-
- Redistribution and use in source (original document form) and 'compiled'
- forms (converted to PDF, epub, HTML and other formats) with or without
- modification, are permitted provided that the following conditions are met:
-
- 1) Redistributions of source code (original document form) must retain the
- above copyright notice, this list of conditions and the following
- disclaimer as the first lines of this file unmodified.
-
- 2) Redistributions in compiled form (transformed to other DTDs, converted to
- PDF, epub, HTML and other formats) must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in the
- documentation and/or other materials provided with the distribution.
-
- THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS
OR
- IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
- EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
- SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
- OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
- WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
- OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
- ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
--->
-
-## 2.9 [OptionRom] Sections
-
-The EDK II `[OptionRom]` sections allow for extending the FDF for processing of
-standalone legacy PCI Option ROM images or stand-alone UEFI PCI Option ROM
-images. A required modifier, DriverName, will specify where in the build's FV
-directory, the OptionROM file will be placed.
-
-If the user is only creating PCI Option ROM images, then the `[FV]` and `[FD]`
-sections are not required. If an FD and FV sections exist, then the tools will
-create the FD image as well as the Option ROM image. If they are not in the FDF
-file, then they will only generate the Option ROM image.
-
-Each `[OptionRom]` section terminates with either the start of another section,
-or the end of the file. The `[OptionRom]` section header usage is shown below.
-
-`[OptionRom.ROMName]`
-
-If more than architecture (for example, IA32 and EBC) for the driver is to be
-bundled in an option rom file, then more than one INF entry (specified by the
-USE option) can be used to include the other architecture.
-
-Having different sections for the same option rom driver for different
-architectures is not permitted.
-
-This is an optional section for platform images.
+<!--- @file
+ 2.9 [OptionRom] Sections
+
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS
OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## 2.8 [OptionRom] Sections
+
+The EDK II `[OptionRom]` sections allow for extending the FDF for processing of
+standalone legacy PCI Option ROM images or stand-alone UEFI PCI Option ROM
+images. A required modifier, DriverName, will specify where in the build's FV
+directory, the OptionROM file will be placed.
+
+If the user is only creating PCI Option ROM images, then the `[FV]` and `[FD]`
+sections are not required. If an FD and FV sections exist, then the tools will
+create the FD image as well as the Option ROM image. If they are not in the FDF
+file, then they will only generate the Option ROM image.
+
+Each `[OptionRom]` section terminates with either the start of another section,
+or the end of the file. The `[OptionRom]` section header usage is shown below.
+
+`[OptionRom.ROMName]`
+
+If more than architecture (for example, IA32 and EBC) for the driver is to be
+bundled in an option rom file, then more than one INF entry (specified by the
+USE option) can be used to include the other architecture.
+
+Having different sections for the same option rom driver for different
+architectures is not permitted.
+
+This is an optional section for platform images.
diff --git a/2_fdf_design_discussion/README.md
b/2_fdf_design_discussion/README.md
index 7d87e43..58398bd 100644
--- a/2_fdf_design_discussion/README.md
+++ b/2_fdf_design_discussion/README.md
@@ -45,12 +45,10 @@ The flash description file is normally in the same
directory as the platform
description (DSC) file.
The remainder of this document uses "FDF" instead of "Flash Description File."
The EDK II Build generates UEFI and PI specification compliant binary images.
-The tools provided in the EDK and the EdkCompatibilityPkg module support
-earlier versions of the specifications.
This revision of the specification adds support for multiple binary files in
an FV FILE RAW statement. FDF files that use this feature must use the new
`FDF_SPECIFICATION = 0x0001001C` in the `[Defines]` section. Older FDF files
do not need to update the `FDF_SPECIFICATION` value.
diff --git a/3_edk_ii_fdf_file_format/310_[vtf]_section.md
b/3_edk_ii_fdf_file_format/310_[vtf]_section.md
deleted file mode 100644
index 0c29d37..0000000
--- a/3_edk_ii_fdf_file_format/310_[vtf]_section.md
+++ /dev/null
@@ -1,203 +0,0 @@
-<!--- @file
- 3.10 [VTF] Section
-
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
-
- Redistribution and use in source (original document form) and 'compiled'
- forms (converted to PDF, epub, HTML and other formats) with or without
- modification, are permitted provided that the following conditions are met:
-
- 1) Redistributions of source code (original document form) must retain the
- above copyright notice, this list of conditions and the following
- disclaimer as the first lines of this file unmodified.
-
- 2) Redistributions in compiled form (transformed to other DTDs, converted to
- PDF, epub, HTML and other formats) must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in the
- documentation and/or other materials provided with the distribution.
-
- THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS
OR
- IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
- EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
- SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
- OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
- WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
- OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
- ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
--->
-
-## 3.10 [VTF] Section
-
-This describes the optional `[VTF]` section tag found in FDF files.
-
-#### Summary
-
-If VTF files will be created, they will be created in the
-`$(OUTPUT_DIRECTORY)/$(TARGET)_$(TAGNAME)/FV` directory using the values from
-the individual instance of the build tools. (Build tools get these values after
-parsing DSC, INF, `target.txt`, `tools_def.txt` files and command line
options.)
-
-The following sequence describes each component:
-
-```
-Name = Region,
- Type,
- Version,
- CheckSum_Flag,
- Path_of_Binary_File,
- Path_of_SYM_File,
- Preferred_Size;
-```
-
-Where,
-
-**_Name:_**
-
-Name of the component
-
-**_Region:_**
-
-Location in the firmware. Valid locations are:
-
-```
-PH - Protected Block region, merged towards the higher address
-PL - Protected Block region, merged towards the lower address
-H - Flashable region, merged towards the higher address
-L - Flashable region, merged towards the lower address
-F - First VTF File
-N - Not in VTF File
-S - Second VTF File
-```
-
-**_Type:_**
-
-Component Type. Predefined values are:
-
-```
-0x00 : FIT Header entry
-0x01 : PAL_B
-0x02 - 0x0E : Reserved
-0x0F : PAL_A
-0x10 - 0x7E : OEM-defined
-0x7F : Unused
-```
-
-**_Version:_**
-
-Component Version number (XX.YY)
-
-```
-- major version number (decimal number, range of 0 to 99)
-- minor version number (decimal number, range of 0 to 99)
-```
-
-**_Checksum_Flag:_**
-
-Checksum Flag (equivalent to CV bit)
-
-```
-0 - Checksum Byte always equals 0, CV=0
-1 - calculate Checksum Byte, CV=1
-```
-
-**_Checksum:_**
-
-Byte sum of component + Checksum Byte = modulus 0x100
-
-**_Path_of_Binary_File:_**
-
-Path of the Binary file of the component
-
-**_Path_of_SYM_File:_**
-
-Path of the .SYM symbol file of the component
-
-**_Preferred_Size:_**
-
-User preferred component size, overrides actual component file size. Valid is
-equal or greater than the actual file size.
-
-#### Prototype
-
-```c
-<VTF> ::= "[VTF" <Modifiers> "]" <EOL>
- [<OptionStatement>]
- <ComponentStatements>*
-<Modifiers> ::= "." <arch> "." <UiName> [<ArchList>]
-<ArchList> ::= "," <Arch>
-<Arch> ::= {"IA32"} {"X64"} {"IPF"}
-<UiName> ::= <Word>
-<OptionStatement> ::= <TS> "IA32_RST_BIN" <Eq> <Filename> <EOL>
-<ComponentStatements> ::= <TS> "COMP_NAME" <Eq> <WORD> <EOL>
- <TS> "COMP_LOC" <Eq> <Location> <EOL>
- <TS> "COMP_TYPE" <Eq> <CompType> <EOL>
- <TS> "COMP_VER" <Eq> <Version> <EOL>
- <TS> "COMP_CS" <Eq> {"1"} {"0"} <EOL>
- <TS> "COMP_BIN" <Eq> <BinFile> <EOL>
- <TS> "COMP_SYM" <Eq> <SymFile> <EOL> <TS> "COMP_SIZE"
- <Eq> <Size> <EOL>
-<Location> ::= {<FvUiName>} {"NONE"} {"None"} {"none"} [<FS>
- <Region>]
-<Region> ::= {"F"} {"N"} {"S"} {"H"} {"L"} {"PH"} {"PL"}
-<CompType> ::= {"FIT"} {"PAL_B"} {"PAL_A"} {"OEM"} {<Byte>}
-<Byte> ::= "0x" <HexDigit>? <HexDigit>
-<Version> ::= {"-"} {<Major> "." <Minor>} {<BcdHex>}
-<Major> ::= [(0-9)](0-9)
-<Minor> ::= [(0-9)](0-9)
-<BcdHex> ::= "0x" <Major> (0-9) (0-9)
-<BinFile> ::= {"-"} {[<PATH>] <Filename>}
-<SymFile> ::= {"-"} {[<PATH>] <Filename>}
-<Size> ::= {"-"} {<Integer>} {<HexNumber>}
-```
-
-#### Restrictions
-
-**_FName_**
-
-All file specified paths are relative to the WORKSPACE directory (or a
directory
-
-listed in the PACKAGES_PATH). In some cases, the tools will search well known
-paths for some files, for example, for FD filenames, the output will typically
-be located in the $(OUTPUT_DIRECTORY)/$(TARGET)_$(TAGNAME)/FV directory.
-
-#### Parameters
-
-**_<BinFile> - Filename_**
-
-If a filename is given, the file must have an extension for a binary type file,
-such as ".bin" or ".BIN". Filenames are case sensitive, so the correct case
-must be used for all filenames.
-
-**_<SymFile> - Filename_**
-
-If a filename is given, the file must have an extension for a symbol type file,
-such as ".sym" or ".SYM". Filenames are case sensitive, so the correct case
-must be used for all filenames.
-
-#### Example
-
-```
-[VTF.IPF.MyBsf]
-IA32_RST_BIN = IA32_RST.BIN
-
-COMP_NAME = PAL_A # Component Name
-COMP_LOC = FvRecovery | F # In the first VTF file
-COMP_TYPE = 0xF # Component Type (PAL_A=0x0F, defined in SAL Spec.)
-COMP_VER = 7.01 # Version will come from header of PAL_A binary
-COMP_CS = 1 # Checksum_Validity (CV bit)
-COMP_BIN = PAL_A_GEN.BIN # Path of binary
-COMP_SYM = PAL_A_GEN.SYM # Path of SYM symbol
-COMP_SIZE = - # Preferred component size in bytes
-
-COMP_NAME = PAL_B # Component Name
-COMP_LOC = F # In the first VTF file
-COMP_TYPE = 0x01 # Component Type (PAL_A=0x0F, defined in SAL Spec.)
-COMP_VER = - # Version will come from header of PAL_A binary
-COMP_CS = 1 # Checksum_Validity (CV bit)
-COMP_BIN = PAL_B.BIN # Path of binary
-COMP_SYM = PAL_B.Sym # Path of SYM symbol
-COMP_SIZE = - # Preferred component size in bytes
-```
diff --git a/3_edk_ii_fdf_file_format/311_pci_optionrom_section.md
b/3_edk_ii_fdf_file_format/310_pci_optionrom_section.md
similarity index 93%
rename from 3_edk_ii_fdf_file_format/311_pci_optionrom_section.md
rename to 3_edk_ii_fdf_file_format/310_pci_optionrom_section.md
index 8267fbb..4bc2fad 100644
--- a/3_edk_ii_fdf_file_format/311_pci_optionrom_section.md
+++ b/3_edk_ii_fdf_file_format/310_pci_optionrom_section.md
@@ -1,114 +1,114 @@
-<!--- @file
- 3.11 PCI OptionRom Section
-
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
-
- Redistribution and use in source (original document form) and 'compiled'
- forms (converted to PDF, epub, HTML and other formats) with or without
- modification, are permitted provided that the following conditions are met:
-
- 1) Redistributions of source code (original document form) must retain the
- above copyright notice, this list of conditions and the following
- disclaimer as the first lines of this file unmodified.
-
- 2) Redistributions in compiled form (transformed to other DTDs, converted to
- PDF, epub, HTML and other formats) must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in the
- documentation and/or other materials provided with the distribution.
-
- THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS
OR
- IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
- EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
- SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
- OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
- WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
- OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
- ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
--->
-
-## 3.11 PCI OptionRom Section
-
-This is an optional section.
-
-#### Summary
-
-This section is used to specify the content of a PCI Option ROM container. A
-PCI Option ROM image may contain zero or more PCI ROM image files - binary
-only, and zero or more UEFI driver images, specified by either binary or INF
-files, that are to be packaged into a single Option ROM image. Additionally,
-support for a single EFI driver with both native (IA32, X64, IPF, etc). and EBC
-images in the same PCI Option ROM container is provided.
-
-Conditional statements may be used anywhere within this section.
-
-#### Prototype
-
-```c
-<OptionRom> ::= "[OptionRom" "." <DriverName> "]" <EOL> <Components>*
-<DriverName> ::= (a-zA-Z)(a-zA-Z0-9)*
-<Components> ::= {<InfComponent>} {<Binary>}
-<InfComponent> ::= <TS> "INF" <MTS> <UseArch> <InfFile>
- [<Overrides>] <EOL>
-<UseArch> ::= "USE" <Eq> <TargetArch> <MTS>
-<TargetArch> ::= <arch>
-<InfFile> ::= [<PATH>] <Word> ".inf"
-<Overrides> ::= <MTS> "{" <EOL>
- [<TS> "PCI_VENDOR_ID" <Eq> <UINT16> <EOL>]
- [<TS> "PCI_CLASS_CODE" <Eq> <UINT8> <EOL>]
- [<TS> "PCI_DEVICE_ID" <Eq> <UINT16> [<MTS> <UINT16>]* <EOL>]
- [<TS> "PCI_REVISION" <Eq> <UINT8> <EOL>]
- [<TS> "PCI_COMPRESS" <Eq> <TrueFalse> <EOL>]
- <TS> "}" <EOL>
-<Binary> ::= {<EfiBinary>} {<OtherBinary>}
-<EfiBinary> ::= <TS> "FILE" <MTS> "EFI" <EfiFileName>
- [<Overrides>] <EOL>
-<EfiFileName> ::= <MTS> [<PATH>] <Word> {".efi"} {".EFI"} {".Efi"}
-<OtherBinary> ::= <TS> "FILE" <MTS> "BIN" <Filename> <EOL>
-```
-
-#### Restrictions
-
-**_TargetArch_**
-
-Only specific architectures are permitted - use of "common" or the wildcard
-character is prohibited.
-
-**_Paths_**
-
-For BINARY ONLY content (`UEFI_DRIVER` and `UEFI_APPLICATION` .efi files) the
-file names specified in `<EfiFileName>` of this section must be relative to the
-directory identified by the `WORKSPACE` system environment variable (or
-relative to a directory listed in the PACKAGES_PATH system environment
-variable). In some cases, the tools will search well known paths for some
-files, for example, for FD filenames, the output will typically be located in
-the `$(OUTPUT_DIRECTORY)/ $(TARGET)_$(TAGNAME)/FV` directory.
-
-#### Related Definitions
-
-**_DriverName_**
-
-Specifies the name of the created PCI Option ROM image that will be placed in
-the build's FV directory.
-
-**_USE_**
-
-Specifies the architecture to use to create a PCI Option ROM.
-
-**_Filename_**
-
-Filenames must match the actual case of the file; three variations are shown
-for the .efi extension in the ENBF above.
-
-#### Example
-
-```c
-[OptionRom.AtapiPassThru]
- INF USE = IA32 OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf {
- PCI_REVISION = 0x0020
- PCI_DEVICE_ID = 0x0A03 0x0B03
- }
- INF USE = EBC OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf
-```
+<!--- @file
+ 3.11 PCI OptionRom Section
+
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
+
+ Redistribution and use in source (original document form) and 'compiled'
+ forms (converted to PDF, epub, HTML and other formats) with or without
+ modification, are permitted provided that the following conditions are met:
+
+ 1) Redistributions of source code (original document form) must retain the
+ above copyright notice, this list of conditions and the following
+ disclaimer as the first lines of this file unmodified.
+
+ 2) Redistributions in compiled form (transformed to other DTDs, converted to
+ PDF, epub, HTML and other formats) must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+ THIS DOCUMENTATION IS PROVIDED BY TIANOCORE PROJECT "AS IS" AND ANY EXPRESS
OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ EVENT SHALL TIANOCORE PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
+ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+-->
+
+## 3.10 PCI OptionRom Section
+
+This is an optional section.
+
+#### Summary
+
+This section is used to specify the content of a PCI Option ROM container. A
+PCI Option ROM image may contain zero or more PCI ROM image files - binary
+only, and zero or more UEFI driver images, specified by either binary or INF
+files, that are to be packaged into a single Option ROM image. Additionally,
+support for a single EFI driver with both native (IA32, X64, etc). and EBC
+images in the same PCI Option ROM container is provided.
+
+Conditional statements may be used anywhere within this section.
+
+#### Prototype
+
+```c
+<OptionRom> ::= "[OptionRom" "." <DriverName> "]" <EOL> <Components>*
+<DriverName> ::= (a-zA-Z)(a-zA-Z0-9)*
+<Components> ::= {<InfComponent>} {<Binary>}
+<InfComponent> ::= <TS> "INF" <MTS> <UseArch> <InfFile>
+ [<Overrides>] <EOL>
+<UseArch> ::= "USE" <Eq> <TargetArch> <MTS>
+<TargetArch> ::= <arch>
+<InfFile> ::= [<PATH>] <Word> ".inf"
+<Overrides> ::= <MTS> "{" <EOL>
+ [<TS> "PCI_VENDOR_ID" <Eq> <UINT16> <EOL>]
+ [<TS> "PCI_CLASS_CODE" <Eq> <UINT8> <EOL>]
+ [<TS> "PCI_DEVICE_ID" <Eq> <UINT16> [<MTS> <UINT16>]* <EOL>]
+ [<TS> "PCI_REVISION" <Eq> <UINT8> <EOL>]
+ [<TS> "PCI_COMPRESS" <Eq> <TrueFalse> <EOL>]
+ <TS> "}" <EOL>
+<Binary> ::= {<EfiBinary>} {<OtherBinary>}
+<EfiBinary> ::= <TS> "FILE" <MTS> "EFI" <EfiFileName>
+ [<Overrides>] <EOL>
+<EfiFileName> ::= <MTS> [<PATH>] <Word> {".efi"} {".EFI"} {".Efi"}
+<OtherBinary> ::= <TS> "FILE" <MTS> "BIN" <Filename> <EOL>
+```
+
+#### Restrictions
+
+**_TargetArch_**
+
+Only specific architectures are permitted - use of "common" or the wildcard
+character is prohibited.
+
+**_Paths_**
+
+For BINARY ONLY content (`UEFI_DRIVER` and `UEFI_APPLICATION` .efi files) the
+file names specified in `<EfiFileName>` of this section must be relative to the
+directory identified by the `WORKSPACE` system environment variable (or
+relative to a directory listed in the PACKAGES_PATH system environment
+variable). In some cases, the tools will search well known paths for some
+files, for example, for FD filenames, the output will typically be located in
+the `$(OUTPUT_DIRECTORY)/ $(TARGET)_$(TAGNAME)/FV` directory.
+
+#### Related Definitions
+
+**_DriverName_**
+
+Specifies the name of the created PCI Option ROM image that will be placed in
+the build's FV directory.
+
+**_USE_**
+
+Specifies the architecture to use to create a PCI Option ROM.
+
+**_Filename_**
+
+Filenames must match the actual case of the file; three variations are shown
+for the .efi extension in the ENBF above.
+
+#### Example
+
+```c
+[OptionRom.AtapiPassThru]
+ INF USE = IA32 OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf {
+ PCI_REVISION = 0x0020
+ PCI_DEVICE_ID = 0x0A03 0x0B03
+ }
+ INF USE = EBC OptionRomPkg/AtapiPassThruDxe/AtapiPassThruDxe.inf
+```
diff --git a/3_edk_ii_fdf_file_format/31_general_rules.md
b/3_edk_ii_fdf_file_format/31_general_rules.md
index 0f9b187..59e171a 100644
--- a/3_edk_ii_fdf_file_format/31_general_rules.md
+++ b/3_edk_ii_fdf_file_format/31_general_rules.md
@@ -1,9 +1,9 @@
<!--- @file
3.1 General Rules
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
Redistribution and use in source (original document form) and 'compiled'
forms (converted to PDF, epub, HTML and other formats) with or without
modification, are permitted provided that the following conditions are met:
@@ -119,16 +119,5 @@ environment variable, `WORKSPACE`(or relative to a
directory listed in the
a word is assumed by the build tools to be located in the `WORKSPACE` directory
(or a directory listed in the `PACKAGES_PATH` system environment variable).
Search paths for locating the files are `WORKSPACE` then the ordered list
(left to right) of directories listed in the optional `PACKAGES_PATH`
environment variable.
-
-Each module may have one or more INF files that can be used by tools to
-generate images. Specifically, the EDK Compatibility Package may contain two
-INF files for any module that contains 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 INF 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.
diff --git a/3_edk_ii_fdf_file_format/32_fdf_definition.md
b/3_edk_ii_fdf_file_format/32_fdf_definition.md
index db098cf..0cc5f4d 100644
--- a/3_edk_ii_fdf_file_format/32_fdf_definition.md
+++ b/3_edk_ii_fdf_file_format/32_fdf_definition.md
@@ -1,9 +1,9 @@
<!--- @file
3.2 FDF Definition
- Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
Redistribution and use in source (original document form) and 'compiled'
forms (converted to PDF, epub, HTML and other formats) with or without
modification, are permitted provided that the following conditions are met:
@@ -48,11 +48,10 @@ EBNF).
[<Defines>]
<FD>*
<FV>*
<Capsule>*
<FmpPayload>*
- <VTF>*
<Rules>*
<OptionRom>*
<UserExtensions>*
```
@@ -216,16 +215,16 @@ The following are common definitions used by multiple
section types.
<MembershipExpression> ::= {<TargetExpress>} {<ArchExpress>} {<ToolExpress>}
<NotOp> ::= <UnaryOperator> <MTS>
<InOp> ::= <MTS> [<NotOp>] {"IN"} {"in"} <MTS>
<TargetExress> ::= (A-Z) (A-Z0-9)* <InOp> "$(TARGET)"
<ArchExpress> ::= <DblQuote> <Arch> <DblQuote> <InOp> "$(ARCH)"
-<Arch> ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {<OA>}
+<Arch> ::= {"IA32"} {"X64"} {"EBC"} {<OA>}
<ToolExpress> ::= (A-Z) (a-zA-Z0-9)* <InOp> "$(TOOL_CHAIN_TAG)"
<Boolean> ::= {<BoolType>} {<Expression>}
<EOL> ::= <TS> 0x0D 0x0A
<OA> ::= (a-zA-Z)(a-zA-Z0-9)*
-<arch> ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {<OA>}
+<arch> ::= {"IA32"} {"X64"} {"EBC"} {<OA>}
{"common"}
<FvAlignmentValues> ::= {"1"} {"2"} {"4"} {"8"} {"16"} {"32"}
{"64"} {"128"}{"256"} {"512"} {"1K"} {"2K"}
{"4K"} {"8K"} {"16K"} {"32K"} {"64K"}
{"128K"} {"256K"} {"512K"} {"1M"} {"2M"} {"4M"}
@@ -281,11 +280,11 @@ 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
+EDK II meta-data file, _Conf/tools_def.txt_. Only `IA32`, `X64` and
`EBC` are routinely validated.
**_FileSep_**
FileSep refers to either the back slash "\" or forward slash "/" characters
@@ -575,65 +574,10 @@ zero or one are invalid. Precedence and associativity
follow C standards. Along
with absolute values, macro names and PCDs may be used within an expression.
For both macro names and PCDs, the element must be previously defined before it
can be used. A new operator, "in" is also permitted for testing membership of
an item in a list of one or more items.
-#### Example
-
-```ini
-!if $(MyPlatformTspGuid.IPF_VERSION_1) && NOT
$(MyPlatformTspGuid.IPF_VERSION_2)
- [VTF.IPF.MyBsf]
- !ifdef IA32RESET
- # IPF_VERSION is 1 and IA32RESET defined
- IA32_RST_BIN = IA32_RST.BIN
- !endif
- COMP_NAME = PAL_A
- COMP_LOC = MyVtfVF | F
- COMP_TYPE = 0xF
- COMP_VER = 7.01
- COMP_CS = 1
- !if ($(PROCESSOR_NAME) == "M1")
- COMP_BIN = M1PalCode/PAL_A_M1.BIN
- COMP_SYM = M1PalCode/PAL_A_M1.SYM
- !elseif ($(PROCESSOR_NAME) == "M2")
- COMP_BIN = M2PalCode/PAL_A_M2.BIN
- COMP_SYM = M2PalCode/PAL_A_M2.SYM
- !else
- COMP_BIN = GenPal/PAL_A_GEN.bin
- COMP_SYM = GenPal/PAL_A_GEN.sym
- !endif
- COMP_SIZE = -
-!elseif $(MyPlatformTspGuid.IPF_VERSION_2)
- [VTF.IPF.MyBsf]
- !ifdef IA32RESET
- IA32_RST_BIN = IA32_RST.BIN
- !endif
- COMP_NAME = PAL_A
- COMP_LOC = MyVtfFv | F
- COMP_TYPE = 0xF
- COMP_VER = 7.01
- COMP_CS = 1
- COMP_BIN = GenPal/PAL_A_GEN.bin
- COMP_SYM = GenPal/PAL_A_GEN.sym
- COMP_SIZE = -
- COMP_NAME = PAL_B
- COMP_LOC = MyVtfFv | S
- COMP_TYPE = 0x01
- COMP_VER = -
- COMP_CS = 1
- COMP_BIN = GenPal/PAL_B_GEN.bin
- COMP_SYM = GenPal/PAL_B_GEN.sym
- COMP_SIZE = -
-!else
- [VTF.X64.MyVtf]
- IA32_RST_BIN = IA32_RST.BIN
-!endif
-!ifndef MY_MACRO
-DEFINE MY_MACRO
-!endif
-```
-
### 3.2.4 !include Statements
Use of this statement is optional.
#### Summary
@@ -647,12 +591,11 @@ of the section that the `!include` statement resides, or
it may contain
completely new sections of the same section type. If the included file contains
new sections, then the section being processed in the Platform FDF file is
considered to have been terminated.
If the `<Filename>` contains "$" characters, then macros defined in the DSC
-file, FDF file, and the system environment variables, `$(WORKSPACE)`,
-`$(EDK_SOURCE)`, `$(EFI_SOURCE)`, and `$(ECP_SOURCE)` are substituted into
+file, FDF file, and the system environment variables, `$(WORKSPACE)`, is
substituted into
`<Filename>`.
The tools look for `<Filename>` relative to the directory the FDF file resides.
If the file is not found, and the directory containing this FDF file is not the
same directory as the directory containing the DSC file, the tools must attempt
diff --git a/README.md b/README.md
index 7c7face..1b287aa 100644
--- a/README.md
+++ b/README.md
@@ -215,5 +215,6 @@ Copyright (c) 2006-2017, Intel Corporation. All rights
reserved.
| | clean up the <NamedGuidOrPcd> and <NamedGuid> usage in spec
| |
| | document WEAK_ALIGNMENT attribute
| |
| | support varstore template generation with a [FV] section
| |
| | [#1110](https://bugzilla.tianocore.org/show_bug.cgi?id=1110)
Extend exclamation statement's keyword to case-insensitive
| |
| | [#551] (https://bugzilla.tianocore.org/show_bug.cgi?id=551) Add
PI1.5 standalone SMM support in FDF file
| |
+| 1.29 | [#1453](https://bugzilla.tianocore.org/show_bug.cgi?id=1453)
Update FDF spec to remove EDK related contents
| Mar 2019 |
\ No newline at end of file
diff --git a/SUMMARY.md b/SUMMARY.md
index c9ff1f1..ba5ce9a 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -43,25 +43,23 @@
* [2.2 Flash Description File
Format](2_fdf_design_discussion/22_flash_description_file_format.md#22-flash-description-file-format)
* [2.3 [Defines]
Section](2_fdf_design_discussion/23_[defines]_section.md#23-defines-section)
* [2.4 [FD]
Sections](2_fdf_design_discussion/24_[fd]_sections.md#24-fd-sections)
* [2.5 [FV]
Sections](2_fdf_design_discussion/25_[fv]_sections.md#25-fv-sections)
* [2.6 [Capsule]
Sections](2_fdf_design_discussion/26_[capsule]_sections.md#26-capsule-sections)
- * [2.7 [VTF]
Sections](2_fdf_design_discussion/27_[vtf]_sections.md#27-vtf-sections)
- * [2.8 [Rule]
Sections](2_fdf_design_discussion/28_[rule]_sections.md#28-rule-sections)
- * [2.9 [OptionRom]
Sections](2_fdf_design_discussion/29_[optionrom]_sections.md#29-optionrom-sections)
+ * [2.7 [Rule]
Sections](2_fdf_design_discussion/27_[rule]_sections.md#27-rule-sections)
+ * [2.8 [OptionRom]
Sections](2_fdf_design_discussion/28_[optionrom]_sections.md#28-optionrom-sections)
* [3 EDK II FDF File
Format](3_edk_ii_fdf_file_format/README.md#3-edk-ii-fdf-file-format)
* [3.1 General
Rules](3_edk_ii_fdf_file_format/31_general_rules.md#31-general-rules)
* [3.2 FDF
Definition](3_edk_ii_fdf_file_format/32_fdf_definition.md#32-fdf-definition)
* [3.3 Header
Section](3_edk_ii_fdf_file_format/33_header_section.md#33-header-section)
* [3.4 [Defines]
Section](3_edk_ii_fdf_file_format/34_[defines]_section.md#34-defines-section)
* [3.5 [FD]
Sections](3_edk_ii_fdf_file_format/35_[fd]_sections.md#35-fd-sections)
* [3.6 [FV]
Sections](3_edk_ii_fdf_file_format/36_[fv]_sections.md#36-fv-sections)
* [3.7 [Capsule]
Sections](3_edk_ii_fdf_file_format/37_[capsule]_sections.md#37-capsule-sections)
* [3.8 [FmpPayload]
Sections](3_edk_ii_fdf_file_format/38_[fmppayload]_sections.md#38-fmppayload-sections)
* [3.9 [Rule]
Sections](3_edk_ii_fdf_file_format/39_[rule]_sections.md#39-rule-sections)
- * [3.10 [VTF]
Section](3_edk_ii_fdf_file_format/310_[vtf]_section.md#310-vtf-section)
- * [3.11 PCI OptionRom
Section](3_edk_ii_fdf_file_format/311_pci_optionrom_section.md#311-pci-optionrom-section)
+ * [3.10 PCI OptionRom
Section](3_edk_ii_fdf_file_format/310_pci_optionrom_section.md#310-pci-optionrom-section)
* [Appendix A Nt32Pkg Flash Description
File](appendix_a_nt32pkg_flash_description_file.md#appendix-a-nt32pkg-flash-description-file)
* [Appendix B Common Error
Messages](appendix_b_common_error_messages.md#appendix-b-common-error-messages)
* [B.1 [FD] Syntax
Errors:](appendix_b_common_error_messages.md#b1-fd-syntax-errors)
* [B.2 [FV] Syntax
Errors:](appendix_b_common_error_messages.md#b2-fv-syntax-errors)
* [B.3 [CAPSULE] Syntax
Errors:](appendix_b_common_error_messages.md#b3-capsule-syntax-errors)
diff --git a/appendix_a_nt32pkg_flash_description_file.md
b/appendix_a_nt32pkg_flash_description_file.md
index 89be76c..b43a507 100644
--- a/appendix_a_nt32pkg_flash_description_file.md
+++ b/appendix_a_nt32pkg_flash_description_file.md
@@ -1,9 +1,9 @@
<!--- @file
Appendix A Nt32Pkg Flash Description File
- Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
+ Copyright (c) 2006-2019, Intel Corporation. All rights reserved.<BR>
Redistribution and use in source (original document form) and 'compiled'
forms (converted to PDF, epub, HTML and other formats) with or without
modification, are permitted provided that the following conditions are met:
@@ -188,11 +188,11 @@ READ_LOCK_CAP = TRUE
READ_LOCK_STATUS = TRUE
FvNameGuid = 6D99E806-3D38-42c2-A095-5F4300BFD7DC
########################################################################
#
-# The INF statements point to EDK component and EDK II module INF files,
+# The INF statements point to EDK II module INF files,
# which will be placed into this FV image.
# Parsing tools will scan the INF file to determine the type of component
# or module.
# The component or module type is used to reference the standard rules
# defined elsewhere in the FDF file.
--
2.20.1.windows.1
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
