* [Patch V2 0/1] Document: Update FDF spec to remove EDK and IPF related contents
@ 2019-03-06 9:53 Feng, Bob C
2019-03-06 9:53 ` [Patch 1/1] " Feng, Bob C
0 siblings, 1 reply; 3+ messages in thread
From: Feng, Bob C @ 2019-03-06 9:53 UTC (permalink / raw)
To: edk2-devel
V2:
Update the table of content and update history.
Update commit message and fixed a bug.
Feng, Bob C (1):
Document: Update FDF spec to remove EDK and IPF related contents
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(-)
rename 2_fdf_design_discussion/{28_[rule]_sections.md => 27_[rule]_sections.md} (95%)
delete mode 100644 2_fdf_design_discussion/27_[vtf]_sections.md
rename 2_fdf_design_discussion/{29_[optionrom]_sections.md => 28_[optionrom]_sections.md} (94%)
delete mode 100644 3_edk_ii_fdf_file_format/310_[vtf]_section.md
rename 3_edk_ii_fdf_file_format/{311_pci_optionrom_section.md => 310_pci_optionrom_section.md} (93%)
--
2.20.1.windows.1
^ permalink raw reply [flat|nested] 3+ messages in thread* [Patch 1/1] Document: Update FDF spec to remove EDK and IPF related contents 2019-03-06 9:53 [Patch V2 0/1] Document: Update FDF spec to remove EDK and IPF related contents Feng, Bob C @ 2019-03-06 9:53 ` Feng, Bob C 2019-03-19 7:40 ` Gao, Liming 0 siblings, 1 reply; 3+ messages in thread From: Feng, Bob C @ 2019-03-06 9:53 UTC (permalink / raw) To: edk2-devel; +Cc: Bob Feng, Liming Gao, Jaben Carsey 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.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jaben Carsey <jaben.carsey@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 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [Patch 1/1] Document: Update FDF spec to remove EDK and IPF related contents 2019-03-06 9:53 ` [Patch 1/1] " Feng, Bob C @ 2019-03-19 7:40 ` Gao, Liming 0 siblings, 0 replies; 3+ messages in thread From: Gao, Liming @ 2019-03-19 7:40 UTC (permalink / raw) To: Feng, Bob C, edk2-devel@lists.01.org; +Cc: Carsey, Jaben 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.gao@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.feng@intel.com>; Gao, Liming ><liming.gao@intel.com>; Carsey, Jaben <jaben.carsey@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.feng@intel.com> >Cc: Liming Gao <liming.gao@intel.com> >Cc: Jaben Carsey <jaben.carsey@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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-03-19 7:40 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-03-06 9:53 [Patch V2 0/1] Document: Update FDF spec to remove EDK and IPF related contents Feng, Bob C 2019-03-06 9:53 ` [Patch 1/1] " Feng, Bob C 2019-03-19 7:40 ` Gao, Liming
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox