1. Update commit message 2. + 2.8 [Rule] Sections, and +## 2.7 [Rule] Sections. They are not consistent. 3. +[Rule.Common.ACPITABLE] Here ACPITABLE is EDK type. Please change it to [Rule.Common.USER_DEFINED.ACPITABLE]
> -----Original Message----- > From: Feng, Bob C > Sent: Monday, March 4, 2019 7:00 AM > To: [email protected] > Cc: Feng, Bob C <[email protected]>; Gao, Liming <[email protected]>; > Carsey, Jaben <[email protected]> > Subject: [Patch] Document: Update FDF spec to remove EDK related contents > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453 > > Remove EDK related contents inf Fdf spec. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Bob Feng <[email protected]> > Cc: Liming Gao <[email protected]> > Cc: Jaben Carsey <[email protected]> > --- > 1_introduction/11_overview.md | 22 +- > 1_introduction/12_terms.md | 8 +- > 1_introduction/README.md | 9 +- > .../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 +- > ...ule]_sections.md => 27_[rule]_sections.md} | 232 +++++++++--------- > 2_fdf_design_discussion/27_[vtf]_sections.md | 82 ------- > ...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 --------------- > ...ection.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 +---- > appendix_a_nt32pkg_flash_description_file.md | 4 +- > 15 files changed, 317 insertions(+), 717 deletions(-) > rename 2_fdf_design_discussion/{28_[rule]_sections.md => > 27_[rule]_sections.md} (96%) > 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%) > > 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 96% > rename from 2_fdf_design_discussion/28_[rule]_sections.md > rename to 2_fdf_design_discussion/27_[rule]_sections.md > index 27b8873..80733e3 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.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/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.18.0.windows.1 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
