Bob: There is one typo in commit message. Remove EDK and IPF related contents inf Fdf spec ==> Remove EDK and IPF related contents from Fdf spec.
With this change, Reviewed-by: Liming Gao <liming....@intel.com> >-----Original Message----- >From: Feng, Bob C >Sent: Wednesday, March 06, 2019 5:53 PM >To: edk2-devel@lists.01.org >Cc: Feng, Bob C <bob.c.f...@intel.com>; Gao, Liming ><liming....@intel.com>; Carsey, Jaben <jaben.car...@intel.com> >Subject: [Patch 1/1] Document: Update FDF spec to remove EDK and IPF >related contents > >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
