* [Patch] Document: Update DSC spec to remove EDK related contents
@ 2019-03-05 3:48 Feng, Bob C
2019-03-05 15:24 ` Carsey, Jaben
2019-03-06 8:31 ` Gao, Liming
0 siblings, 2 replies; 3+ messages in thread
From: Feng, Bob C @ 2019-03-05 3:48 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 related contents inf Dsc 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 | 14 +--
...=> 210_[components]_section_processing.md} | 27 +-----
...ion.md => 211_[userextensions]_section.md} | 4 +-
...212_[defaultstores]_section_processing.md} | 4 +-
.../22_build_description_file_format.md | 50 ++--------
.../23_[defines]_section_processing.md | 12 +--
2_dsc_overview/24_[buildoptions]_section.md | 72 ++------------
.../26_[libraries]_section_processing.md | 69 --------------
...26_[libraryclasses]_section_processing.md} | 4 +-
...essing.md => 27_pcd_section_processing.md} | 34 +++----
...{29_pcd_sections.md => 28_pcd_sections.md} | 26 ++---
...210_pcd_database.md => 29_pcd_database.md} | 4 +-
...ctions.md => 310_[components]_sections.md} | 62 +-----------
...ns.md => 311_[userextensions]_sections.md} | 4 +-
...tion.md => 312_[defaultstores]_section.md} | 4 +-
3_edk_ii_dsc_file_format/32_general_rules.md | 13 +--
.../33_platform_dsc_definition.md | 17 +---
.../35_[defines]_section.md | 12 +--
.../36_[buildoptions]_sections.md | 19 ++--
.../38_[libraries]_sections.md | 94 -------------------
...ons.md => 38_[libraryclasses]_sections.md} | 4 +-
...310_pcd_sections.md => 39_pcd_sections.md} | 14 +--
22 files changed, 101 insertions(+), 462 deletions(-)
rename 2_dsc_overview/{211_[components]_section_processing.md => 210_[components]_section_processing.md} (84%)
rename 2_dsc_overview/{212_[userextensions]_section.md => 211_[userextensions]_section.md} (93%)
rename 2_dsc_overview/{213_[defaultstores]_section_processing.md => 212_[defaultstores]_section_processing.md} (93%)
delete mode 100644 2_dsc_overview/26_[libraries]_section_processing.md
rename 2_dsc_overview/{27_[libraryclasses]_section_processing.md => 26_[libraryclasses]_section_processing.md} (96%)
rename 2_dsc_overview/{28_pcd_section_processing.md => 27_pcd_section_processing.md} (94%)
rename 2_dsc_overview/{29_pcd_sections.md => 28_pcd_sections.md} (93%)
rename 2_dsc_overview/{210_pcd_database.md => 29_pcd_database.md} (96%)
rename 3_edk_ii_dsc_file_format/{311_[components]_sections.md => 310_[components]_sections.md} (81%)
rename 3_edk_ii_dsc_file_format/{312_[userextensions]_sections.md => 311_[userextensions]_sections.md} (94%)
rename 3_edk_ii_dsc_file_format/{313_[defaultstores]_section.md => 312_[defaultstores]_section.md} (93%)
delete mode 100644 3_edk_ii_dsc_file_format/38_[libraries]_sections.md
rename 3_edk_ii_dsc_file_format/{39_[libraryclasses]_sections.md => 38_[libraryclasses]_sections.md} (95%)
rename 3_edk_ii_dsc_file_format/{310_pcd_sections.md => 39_pcd_sections.md} (97%)
diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
index d9006df..ff2b517 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:
@@ -48,14 +48,11 @@ specifications.
This design has the following goals.
**Compatible**
The EDK II DSC format does not support EDK DSC format, nor can EDK tools be
-used to parse the EDK II DSC format files. The EDK II DSC Format must maintain
-backward compatibility for supporting existing EDK INF file formats. This means
-that the changes made to this specification do not require changes for standard
-INF files.
+used to parse the EDK II DSC format files.
**Simplified platform build and configuration**
One goal of this format is to simplify the build setup and configuration for a
given platform. It was also designed to simplify the process of adding EDK II
@@ -67,11 +64,11 @@ builds.
###### Table 1 EDK Build Infrastructure Support Matrix
| | EDK DSC | EDK II DSC | EDK FDF | EDK II FDF | EDK INF | EDK II INF |
| ------------------ |:---------:|:------------:|:---------:|:------------:|:---------:|:------------:|
| EDK Build Tools | YES | NO | YES | NO | YES | NO |
-| EDK II Build Tools | NO | YES | NO | YES | YES | YES |
+| EDK II Build Tools | NO | YES | NO | YES | NO | YES |
**********
**Note:** This document is intended for persons doing EFI development and
support for different platforms. It is most likely only of interest in the
event that there is a problem with a build, or if a developer needs to perform
@@ -90,9 +87,6 @@ contain information on the EFI format for FFS or FV file creation. The
Makefiles will support third party compilation tools - Microsoft, Intel and GCC
tool chains - and at least one EDK II tool, GenFw. The GenFw tool is used to
manipulate the files emitted from the compilation tools.
The EDK II build provides UEFI and PI (Unified EFI, Inc.)
-specification-compliant images. Use of the tools in the EDK Compatibility
-package can be used for creating earlier versions of EFI 1.10 and/or UEFI 2.0
-compliant components. To be clear, EDK II tools do not have the limitation of
-ECP tools, which can only do EFI 1.10 and UEFI 2.0 images.
+specification-compliant images.
diff --git a/2_dsc_overview/211_[components]_section_processing.md b/2_dsc_overview/210_[components]_section_processing.md
similarity index 84%
rename from 2_dsc_overview/211_[components]_section_processing.md
rename to 2_dsc_overview/210_[components]_section_processing.md
index 140f09c..c1948e8 100644
--- a/2_dsc_overview/211_[components]_section_processing.md
+++ b/2_dsc_overview/210_[components]_section_processing.md
@@ -1,9 +1,9 @@
<!--- @file
2.11 [Components] Section Processing
- 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:
@@ -27,31 +27,24 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 2.11 [Components] Section Processing
+## 2.10 [Components] Section Processing
-One or more `[Components]` sections contain lists of EDK components and EDK II
-Modules. The format for specifying the INF file for EDK II modules incorporates
-new scoping capabilities.
+One or more `[Components]` sections contain lists of EDK II Modules. The format
+for specifying the INF file for EDK II modules incorporates new scoping capabilities.
This section uses one or more of the following section definitions:
* `[Components]`
* `[Components.IA32]`
* `[Components.X64]`
* `[Components.EBC]`
* `[Components.common]`
-EDK components are specified using a fully qualified path to the EDK INF file.
-
-`$(EDK_SOURCE)/Path/and/Filename.inf`
-
-Because EDK II modules have different requirements than EDK I components,
-specifying the INF filename in the extended DSC file may require more than just
-the INF filename and options. A scoping structure, that binds library class
+A scoping structure, that binds library class
(with an optional override instance,) PCD settings (also overriding the values
specified in the `[PcdsPatchableInModule]` or `[PcdsFixedAtBuild]` sections)
and build options for an EDK II module may be required. This scoping structure,
containing sub-elements, is enclosed within curly braces: "{}". The opening
curly brace, "{", must appear at the end of the inf filename line, before any
@@ -79,20 +72,10 @@ Path/and/Filename.inf {
There are four valid, optional sub-elements for EDK II modules. These
sub-element are enclosed within angle brackets: `<Defines>, <LibraryClasses>`,
`<Pcds*>` and `<BuildOptions>`.
-For EDK component INF files, an optional sub-element of
-`<SOURCE_OVERRIDE_PATH>` has been defined. If this element is specified, files
-listed in the directory are used instead of the "same-named" files in the
-component's directory. If an EDK component directory lists files, A.c, B.c and
-C.h, and the directory specified in this sub-element contains the file B.c,
-then the component will be built using files from the component directory: A.c
-and C.h, and the file B.c from the override directory. Any other files listed
-in the override directory will NOT be included in the build (no new or
-additional files are permitted).
-
An INF file line may also have one argument, EXEC = Filename, that specifies
an executable file that takes the INF filename as a parameter. The Filename
must be executable, and must take the INF filename. No other arguments are
permitted to the Filename.
diff --git a/2_dsc_overview/212_[userextensions]_section.md b/2_dsc_overview/211_[userextensions]_section.md
similarity index 93%
rename from 2_dsc_overview/212_[userextensions]_section.md
rename to 2_dsc_overview/211_[userextensions]_section.md
index c176d86..4708e7e 100644
--- a/2_dsc_overview/212_[userextensions]_section.md
+++ b/2_dsc_overview/211_[userextensions]_section.md
@@ -1,9 +1,9 @@
<!--- @file
2.12 [UserExtensions] Section
- 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:
@@ -27,11 +27,11 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 2.12 [UserExtensions] Section
+## 2.11 [UserExtensions] Section
Users may develop custom tools that use the `[UserExtensions]` sections.The EDK
II `[UserExtensions]` sections allow for extending the DSC file with custom
processing of component images. The format for a user extension section
specifier is:
diff --git a/2_dsc_overview/213_[defaultstores]_section_processing.md b/2_dsc_overview/212_[defaultstores]_section_processing.md
similarity index 93%
rename from 2_dsc_overview/213_[defaultstores]_section_processing.md
rename to 2_dsc_overview/212_[defaultstores]_section_processing.md
index 88a7ad2..be83759 100644
--- a/2_dsc_overview/213_[defaultstores]_section_processing.md
+++ b/2_dsc_overview/212_[defaultstores]_section_processing.md
@@ -1,9 +1,9 @@
<!--- @file
2.13 [DefaultStores] Section Processing
- 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:
@@ -27,11 +27,11 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 2.13 [DefaultStores] Section Processing
+## 2.12 [DefaultStores] Section Processing
The contents of this section are used to define DefaultStores names. Default
store is UEFI HII concept. It is used to define HII default setting for the
different store, such as standard default, manufacturing default. Platform
can define the supported default store for DynamicHii/DynamicExHii PCD in this
diff --git a/2_dsc_overview/22_build_description_file_format.md b/2_dsc_overview/22_build_description_file_format.md
index 31e23f4..10dc428 100644
--- a/2_dsc_overview/22_build_description_file_format.md
+++ b/2_dsc_overview/22_build_description_file_format.md
@@ -1,9 +1,9 @@
<!--- @file
2.2 Build Description File Format
- 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:
@@ -229,19 +229,18 @@ definition, contain complete sections, or combination of both. And 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 the paths listed in the system environment
-variables `$(WORKSPACE)`, `$(EFI_SOURCE)`, `$(EDK_SOURCE)`, and
-`$(ECP_SOURCE)`. If the file is still not found, the parsing tools must
-terminate with an error.
+variable `$(WORKSPACE)`. If the file is still not found, the parsing tools
+must terminate with an error.
Macros, defined in this 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.
+for macros. The system environment variable `$(WORKSPACE)`, may also be used;
+only these system environment variables are permitted to start the path of the
+included file.
Statements in `!include` files must not break the integrity of the DSC 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.
@@ -395,14 +394,10 @@ reference build (Nt32Pkg/Nt32Pkg.dsc), macros set on a command line override
any macro value defined in the DSC (or FDF) file.
MACROs may also be used as values in PCD statements. See _Section 3.10_ for
more information on PCD statements.
-In order to support EDK components and libraries, the word `DEFINE` is replaced
-with `EDK_GLOBAL`. The `EDK_GLOBAL` macros are considered global during the
-processing of the DSC, FDF and EDK INF files.
-
Macros that appear within double quotation marks in build options sections are
not expanded. It is assumed that they will be expanded by the OS or external
scripting tools.
Global variables that may be used in EDK II DSC and FDF meta-data files are
@@ -427,13 +422,10 @@ be altered.
###### Table 3 Using System Environment Variable
| Macro Style Used in Meta-Data Files | Matches Windows Environment Variable | Matches Linux & OS/X Environment Variable |
| ----------------------------------- | ------------------------------------ | ----------------------------------------- |
| $(WORKSPACE) | %WORKSPACE% | $WORKSPACE |
-| $(EFI_SOURCE) | %EFI_SOURCE% | $EFI_SOURCE |
-| $(EDK_SOURCE) | %EDK_SOURCE% | $EDK_SOURCE |
-| $(ECP_SOURCE) | %ECP_SOURCE% | $ECP_SOURCE |
| $(EDK_TOOLS_PATH) | %EDK_TOOLS_PATH% | $EDK_TOOLS_PATH |
The system environment variables, PACKAGES_PATH and EDK_TOOLS_BIN, are not
permitted in EDK II meta-data files.
@@ -479,22 +471,11 @@ follow the same rules as architectural modifiers.
# Can use $(MDE) from the common section
PalLib|$(MDE)/UefiPalLib/UefiPalLib.inf
TimerLib|$(MDE)/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
```
-### 2.2.7 EDK_GLOBAL
-
-The `EDK_GLOBAL` statements defined in the DSC file can be used during the
-processing of the DSC, FDF and EDK INF files. The definition of the
-`EDK_GLOBAL` name must only be done in the DSC `[Defines]` section. These
-special macros can be used in path statements, DSC file `[BuildOptions]` and
-FDF file `[Rule]` sections. These statements are used to replace the
-environment variables that were defined for the EDK build tools. They must
-never be used in a conditional directive statement in the DSC and FDF files,
-nor can they be used by EDK II INF files.
-
-### 2.2.8 Conditional Directive Statements (!if...)
+### 2.2.7 Conditional Directive Statements (!if...)
Conditional directive statements are used by the build tools preprocessor
function to include or exclude statements in the DSC file. A limited number of
statements are supported, and nesting of conditionals is also supported.
Statements are prefixed by the exclamation "!" character. Conditional
@@ -642,11 +623,11 @@ The following are examples of conditional directives.
!else
# The strings do not match exactly
!endif
```
-### 2.2.9 !error Statement
+### 2.2.8 !error Statement
The `!error` statement may appear within any section of EDK II DSC file. The
argument of this statement is an error message, it causes build tool to stop
at the location where the statement is encountered and error message following
the `!error` statement is output as a message. The keyword `!error` is not
@@ -658,11 +639,11 @@ The following example show the valid usage of the `!error` statement.
!if $(FEATURE_ENABLE) == TRUE
!error "unsupported feature!"
!endif
```
-### 2.2.10 Expressions
+### 2.2.9 Expressions
Expressions can be used in conditional directive comparison statements and in
value fields for Macros and PCDs in the DSC and FDF files.
Refer to the EDK II Expression Syntax Specification for additional information.
@@ -723,11 +704,11 @@ names specified on the command line or come from the `Conf/target.txt` file.
For logical expressions, any non-zero value must be considered `TRUE`.
Invalid expressions must cause a build break with an appropriate error message.
-### 2.2.11 Section Handling
+### 2.2.10 Section Handling
The DSC file parsing routines must process the sections so that common
architecture sections are logically merged with the architecturally specific
sections. The architectural sections need to be processed so that they are
logically after the common section. It is recommended that EDK II developers
@@ -750,24 +731,13 @@ on the "==" replace or "=" append assignment character sequence.
```ini
[BuildOptions.Common]
MSFT:*_*_*_CC_FLAGS = /nologo
-[BuildOptions.Common.EDK]
- MSFT:*_*_*_CC_FLAGS = /Od
-
[BuildOptions.IA32]
MSFT:*_*_IA32_CC_FLAGS = /D EFI32
```
For IA32 architecture builds of an EDK II INF file would logically be:
`MSFT:*_*_IA32_CC_FLAGS = /nologo /D EFI32`
-For non-IA32 architecture EDK INF files, tool parsing would logically be:
-
-`MSFT:*_*_*_CC_FLAGS = /nologo /Od`
-
-For IA32 architecture builds of an EDK INF file, tool parsing would logically
-be:
-
-`MSFT:*_*_IA32_CC_FLAGS = /nologo /D EFI32 /Od`
diff --git a/2_dsc_overview/23_[defines]_section_processing.md b/2_dsc_overview/23_[defines]_section_processing.md
index 428196b..ad0702b 100644
--- a/2_dsc_overview/23_[defines]_section_processing.md
+++ b/2_dsc_overview/23_[defines]_section_processing.md
@@ -1,9 +1,9 @@
<!--- @file
2.3 [Defines] Section Processing
- 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:
@@ -80,14 +80,10 @@ define the MACRO name during the processing of this file, files included by the
**Warning:** The DEFINE MACRO = Value statements in other sections are local to
the section, and override the global definition for entries in the section that
follow the macro definition: `DEFINE MACRO = Value.`
**********
-The `EDK_GLOBAL MACRO = Value` definitions in this section globally define the
-MACRO name when parsing the DSC, files included by the !include statement, FDF
-and EDK INF files.
-
The EDK II tools will locate the FDF file specified in the `FLASH_DEFINITION`
entry in the same directory as the DSC file. When the PCD_VAR_CHECK_GENERATION
entry is present and set to TRUE, tools will generate a binary file for
DynamicHii and DynamicExHii PCD variable checking.
@@ -112,11 +108,10 @@ item is required.
| `BUILD_NUMBER` | Optional | Up to four digit numbers | Set this value in the generated Makefile. |
| `FIX_LOAD_TOP_MEMORY_ADDRESS` | Optional | Address | The top memory address - the starting location in memory for all drivers, application loading. When it is not set, or set to 0, the load fixed address feature will be disabled. When it is set to 0xFFFFFFFFFFFFFFFF, enable the feature as fixed offset to TOLM. When it is set to the positive address, enable the feature as fixed address. |
| `TIME_STAMP_FILE` | Optional | Filename | The timestamp file contains a timestamp that will be used to set the creation timestamp on all created files. If this file is specified, it will be used to adjust the timestamp of created files, if it does not exist at the start of a build, the file will be created, using the current date and time. |
| | | | If this variable is not specified, the time and date of the start of the build are used by the EDK II tools that modify the time/date portion of a PE32/PE32+/Coff header. This file's path is either relative to the directory containing the DSC file or a `WORKSPACE`[^1] relative path followed by the file name. |
| `DEFINE` | Optional | MACRO = PATH or Value | A name that is assigned to either a path or a value. This statement can be used to make the DSC file more readable, as in: `DEFINE MDE = MdePkg/Library` Then, later, `$(MDE)/BaseLib/ BaseLib.inf` |
-| `EDK_GLOBAL` | Optional | MACRO = PATH or Value | Similar to the DEFINE statement, macros defined using this keyword are only valid when processing EDK ibraries and components. These values are ignored during processing of EDK II modules. |
| `RFC_LANGUAGES` | Optional | RFC4646 Language code list | A semi-colon ";" separated list of RFC4646 Language codes (EDK II Modules) used during the generation of only a set, rather than all, UNICODE languages during the StrGather AutoGen phase. The list must be encapsulated in double quotes. |
| `ISO_LANGUAGES` | Optional | ISO-639-2 Language code list | A non-separated list of three character ISO 639-2 Language codes (EDK Components) used during the generation of only a set, rather than all, UNICODE languages during the StrGather AutoGen phase. The list must be encapsulated in double quotes. |
| `VPD_TOOL_GUID` | Optional | Registry Format GUID | When this element is present, the build process will be interrupted during the AutoGen stage in order to call an external program, named by GUID that must also be defined in the Conf/tools_def.txt file using a tool code name of VPDTOOL. Refer to the EDK II Build specification for additional information. |
| `PCD_INFO_GENERATION` | Optional | TRUE or FALSE | If present, and set to TRUE, this flag will generate PCD information in the Pcd Database. |
| `PCD_VAR_CHECK_GENERATION` | Optional | TRUE or FALSE | If present and set to TRUE, this flag will generate the variable validation table binary file in the build output FV floder. If not present ro set to FALSE, then the binary file will not be generated. |
@@ -128,9 +123,8 @@ WORKSPACE system environment variable and the PACKAGES_PATH system environment
variable.
**********
**Note:** EDK II Modules can have unicode string files that contain RFC4646
language codes. EDK II modules cannot have unicode string files that contain
-ISO-629-2 language codes. USI-629-2 language codes are only valid for EDK
-components. The format of the statement is specific to processing RFC4646
-language code lists.
+ISO-629-2 language codes. The format of the statement is specific to processing
+RFC4646 language code lists.
**********
diff --git a/2_dsc_overview/24_[buildoptions]_section.md b/2_dsc_overview/24_[buildoptions]_section.md
index 7d3d2d1..375866c 100644
--- a/2_dsc_overview/24_[buildoptions]_section.md
+++ b/2_dsc_overview/24_[buildoptions]_section.md
@@ -1,9 +1,9 @@
<!--- @file
2.4 [BuildOptions] Section
- 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:
@@ -33,11 +33,11 @@
Content in the `[BuildOptions]` section is used to define module specific tool
chain flags rather than use the default flags for a module. These flags are
appended to any standard flags that are defined by the build process. They can
be applied for any modules or those modules on the specific ARCH or those
-modules with the specific module style (EDK or EDKII). In order to replace the
+modules with the specific EDKII module style. In order to replace the
standard flags that are defined by the build process, an alternate assignment
operator is used; "==" is used for replacement, while "=" is used to append
the flag lines. In addition to flags, other tool attributes may have the item
either appended or replaced.
@@ -94,93 +94,35 @@ that the lines show use of the "\" line continuation character.
```
The following examples show how `[BuildOptions]` sections can be merged, as
well as how the content in those sections can be merged.
-For specific flag values, common to both EDK and EDKII options, it is
-appropriate to use a `DEFINE` statement in the `[Defines]` section; for
+It is appropriate to use a `DEFINE` statement in the `[Defines]` section; for
example 1:
`DEFINE MSFT_COMMON_DEBUG_FLAGS = /Od`
Then the macro, $(MSFT_COMMON_DEBUG_FLAGS) can be used in statements in any of
the `[BuildOptions.*]` sections, as in:
```ini
-[BuildOptions.Common.EDK]
+[BuildOptions.X64]
MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c $(MSFT_COMMON_DEBUG_FLAGS)
-[BuildOptions.Common.EDKII]
+[BuildOptions.IA32]
MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c $(MSFT_COMMON_DEBUG_FLAGS)
```
It is also permissible to have a `[BuildOptions.<arch>]` section that can be
shared be used for different statements that are not duplicate content from
-either the `[BuildOptions.<arch>.EDK]` or `[BuildOptions.<arch>.EDKII]`
-sections. For example 2:
+the `[BuildOptions.<arch>.EDKII]` sections. For example:
```ini
[BuildOptions.Common]
MSFT:*_*_*_ASL_OUTFLAGS = /Fo=
-[BuildOptions.Common.EDK]
- MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c /D UNICODE
-
-[BuildOptions.IA32.EDK]
- MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy
-
[BuildOptions.Common.EDKII]
MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c /D UNICODE
[BuildOptions.IA32.EDKII]
MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy
-```
-
-It is also permissible to have a `[BuildOptions.<arch>]` section that can be
-shared be used prior to appending statement content from either the
-`[BuildOptions.<arch>.EDK]` or `[BuildOptions.<arch>.EDKII]` sections as in the
-following example:
-
-```ini
-[BuildOptions.IA32]
- MSFT:DEBUG_*_IA32_CC_FLAGS = /nologo /W4 /WX /Gy /c /D UNICODE
-
-[BuildOptions.IA32.EDKII]
- MSFT:DEBUG_*_IA32_CC_FLAGS = /FI$(DEST_DIR_DEBUG)/AutoGen.h
-
-[BuildOptions.IA32.EDK]
- MSFT:DEBUG_*_IA32_CC_FLAGS = /D EFI32
-```
-
-When processing EDK II C files, the `CC_FLAGS` would be:
-
-`/nologo /W4 /WX /Gy /c /D UNICODE /FI$(DEST_DIR_DEBUG)/AutoGen.h`
-
-While processing of EDK C files, the CC_FLAGS would be:
-
-`/nologo /W4 /WX /Gy /c /D UNICODE /D EFI32`
-
-It is also permissible to combine [BuildOptions.common] with
-`[BuildOptions.<arch>]` sections that are not "common", as in the following
-example:
-
-```ini
-[BuildOptions.Common]
- MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c
-
-[BuildOptions.IA32]
- MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy /D UNICODE
-
-[BuildOptions.IA32.EDKII]
- MSFT:DEBUG_*_IA32_CC_FLAGS = /FI$(DEST_DIR_DEBUG)/AutoGen.h
-
-[BuildOptions.IA32.EDK]
- MSFT:DEBUG_*_IA32_CC_FLAGS = /D EFI32
-```
-
-In the previous example, the `CC_FLAGS` for IA32 EDK II modules would equal:
-
-`/nologo /x /W4 /WX /Gy /D UNICODE /FI$(DEST_DIR_DEBUG)/AutoGen.h`
-
-The CC_FLAGS for IA EDK modules would equal:
-
-`/nologo /c /W4 /WX /Gy /D UNICODE /D EFI32`
+```
\ No newline at end of file
diff --git a/2_dsc_overview/26_[libraries]_section_processing.md b/2_dsc_overview/26_[libraries]_section_processing.md
deleted file mode 100644
index 82cda47..0000000
--- a/2_dsc_overview/26_[libraries]_section_processing.md
+++ /dev/null
@@ -1,69 +0,0 @@
-<!--- @file
- 2.6 [Libraries] Section Processing
-
- 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.6 [Libraries] Section Processing
-
-This section specifies all the EDK INF files that must be processed to build
-the libraries used to build the individual EDK components. This will include
-all the libraries called out in the individual component INF files. A sample
-section is listed below. Each line from the libraries section specifies a
-library component's INF file (relative to `$(EDK_SOURCE)`, or absolute path).
-
-This section is required for any EDK II DSC file that specifies one or more EDK
-components. If only EDK II Modules are used, this section must not be
-specified. If the section is specified, and only EDK II Modules are found, the
-build and parsing tools will ignore this section. A warning message will be
-emitted by the parsing tool if and only the parsing tool is executed in a
-verbose mode.
-
-The `!include` statements may be used within the `[Libraries]` section.
-
-The file specified after the `!include` statement can only contain a list of
-EDK Library INF files (with the path to the file). If the line starts with a
-word, rather than a variable like `$(EDK_SOURCE)` the path is assumed to be
-relative to `$(EDK_SOURCE)`. Again, only EDK Library INF files are permitted in
-the file specified in the `!include` statement.
-
-This section will typically use one of the following section definitions:
-
-```ini
-[Libraries.common]
-[Libraries.IA32]
-[Libraries.X64]
-[Libraries.EBC]
-```
-
-The formats for entries in this section is:
-
-```
-$(EDK_SOURCE)/Path/to/LibraryName.inf
-$(CUSTOM_DECOMPRESS_LIB_INF)
-```
diff --git a/2_dsc_overview/27_[libraryclasses]_section_processing.md b/2_dsc_overview/26_[libraryclasses]_section_processing.md
similarity index 96%
rename from 2_dsc_overview/27_[libraryclasses]_section_processing.md
rename to 2_dsc_overview/26_[libraryclasses]_section_processing.md
index 50bda93..0f87ceb 100644
--- a/2_dsc_overview/27_[libraryclasses]_section_processing.md
+++ b/2_dsc_overview/26_[libraryclasses]_section_processing.md
@@ -1,9 +1,9 @@
<!--- @file
2.7 [LibraryClasses] Section Processing
- 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:
@@ -27,11 +27,11 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 2.7 [LibraryClasses] Section Processing
+## 2.6 [LibraryClasses] Section Processing
The `[LibraryClasses]` section is used to provide a mapping between the library
class names used by an EDK II module and the Library Instances that are
selected by the platform integrator. Library Classes allow modules to be coded
for a library class, and then allow platform integrator then chooses a Library
diff --git a/2_dsc_overview/28_pcd_section_processing.md b/2_dsc_overview/27_pcd_section_processing.md
similarity index 94%
rename from 2_dsc_overview/28_pcd_section_processing.md
rename to 2_dsc_overview/27_pcd_section_processing.md
index a5d56b3..d2a409f 100644
--- a/2_dsc_overview/28_pcd_section_processing.md
+++ b/2_dsc_overview/27_pcd_section_processing.md
@@ -1,9 +1,9 @@
<!--- @file
2.8 PCD Section Processing
- 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:
@@ -27,22 +27,22 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 2.8 PCD Section Processing
+## 2.7 PCD Section Processing
This section is for specifying global (or default) PCD values as well as the
access method each PCD will use for modules in the platform.
-### 2.8.1 PCD Access Methods
+### 2.7.1 PCD Access Methods
There are five defined PCD access methods. The five access methods are:
`FeatureFlag`, `FixedAtBuild`, `PatchableInModule`, `Dynamic` and `DynamicEx`
PCDs.
-#### 2.8.1.1 FeatureFlag and Dynamic PCD Types
+#### 2.7.1.1 FeatureFlag and Dynamic PCD Types
The two recommended access methods that are commonly used in modules are
`FeatureFlag` and the generic `Dynamic method`. The `Dynamic` form is used for
configuration when the PCD value is produced and consumed by drivers during
execution, the value may be user configurable from setup or the value is
@@ -50,11 +50,11 @@ produced by the platform in a specified area. It is associated with modules
that are released in source code. The dynamic form is the most flexible method,
as platform integrators may chose a to use a different access method for a
given platform without modifying the module's INF file or the code for the
module.
-#### 2.8.1.2 DynamicEx, FixedAtBuild and PatchableInModule PCD Access Methods
+#### 2.7.1.2 DynamicEx, FixedAtBuild and PatchableInModule PCD Access Methods
Similar in function, the `DynamicEx` access method can be used with modules
that are released as binary. The `FixedAtBuild` and `PatchableInModule` PCDs
are static and only the `PatchableInModule` PCD can have the value changed in a
binary prior to including the module in a firmware image.
@@ -82,11 +82,11 @@ The content in these sections is used for generating the `AutoGen.c` and
[Pcds(PcdType).IA32]
[Pcds(PcdType).X64]
[Pcds(PcdType).EBC]
```
-### 2.8.2 PCD Access Method Categories
+### 2.7.2 PCD Access Method Categories
Of the five access methods of PCDs that have been defined, they fall into one
of three categories:
* `FeatureFlag` - always has a Boolean value.
@@ -129,42 +129,42 @@ different datum type based on the architecture. For example, a PCD that is used
for address manipulation may have a datum type of `UINT32` for IA32 and
`UINT64` for X64 and EBC architectures. This will be declared in the EDK II
Package Declaration (DEC) File.
**********
-### 2.8.3 PCD Section Usage
+### 2.7.3 PCD Section Usage
PCD sections are optional unless the EDK II modules specified in the
`[Components]` section use PCDs.
The PCD sections are used to define the access method for a PCD. Since each
module is built once for a given architecture, the PCD can be listed under
different PCD access methods provided they are listed under different
architectures.
-#### 2.8.3.1 Access Methods
+#### 2.7.3.1 Access Methods
However, once a PCD access method is selected for a given architecture, the PCD
can only use that access method.
#### Example
A PCD that will use the `FixedAtBuild` access method for IA32 cannot use the
`PatchableInModule` access method for individual modules built for the IA32
architecture.
-#### 2.8.3.2 Different Access Methods
+#### 2.7.3.2 Different Access Methods
It is permissible to have a PCD use different access methods for different
architectures.
#### Example
A PCD that will use the FixedAtBuild access method for IA32 can use the
Patchable in Module access method for X64.
-#### 2.8.3.3 Item Access Methods
+#### 2.7.3.3 Item Access Methods
Multiple item access methods, `PcdsFeatureFlag`, `PcdsFixedAtBuild`,
`PcdsPatchableInModule`, `PcdsDynamic` and `PcdsDynamicEx` are not allowed to
be specified within a single [] section tag.
@@ -187,11 +187,11 @@ be specified within a single [] section tag.
[PcdsDynamicDefault.IA32]
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
```
-#### 2.8.3.4 Mixing PCD Dynamic item storage methods
+#### 2.7.3.4 Mixing PCD Dynamic item storage methods
It is not permissible to mix different PCD Dynamic item storage methods within
a single section, as the format for the PCD entries in PcdsDynamicDefault,
PcdsDynamicVpd, PcdsDynamicHii, and PcdsDynamicExDefault, PcdsDynamicExVpd and
PcdsDynamicExHii sections are different.
@@ -212,11 +212,11 @@ PcdsDynamicExHii sections are different.
[PcdsDynamicExVpd.IA32]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|*|0
```
-#### 2.8.3.5 Multiple Architectural Section Tags
+#### 2.7.3.5 Multiple Architectural Section Tags
It is permissible to specify multiple architectural section tags for the same
PCD item type in a single section.
#### Example
@@ -232,11 +232,11 @@ PCD item type in a single section.
[PcdsDynamicDefault.IA32, PcdsDynamicDefault.X64]
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
```
-#### 2.8.3.6 Dynamic and DynamicEx PCD Storage Methods
+#### 2.7.3.6 Dynamic and DynamicEx PCD Storage Methods
The PCDs that use Dynamic and DynamicEx access methods can have their values
stored in one of three different methods, Default, VPD or HII. A PCD using one
of these access methods can use one storage method. It is not permissible to
have a PCD try to store the data in the Default database and a VPD region at
@@ -273,11 +273,11 @@ TokenSpaceGuid.PcdCname|<HiiString>|<VariableGuid>|<VariableOffset>|<Value>|<Att
**********
**Note:** Some of the above fields are optional; refer to "PCD Sections" in the
next chapter for the exact syntax.
**********
-#### 2.8.3.7 Unique PCDs
+#### 2.7.3.7 Unique PCDs
Unique PCDs are identified using the format to identify the named PCD:
`TokenSpaceGuidCName.PcdCName`
@@ -304,11 +304,11 @@ be used - `PcdsFixedAtBuild` for modules with wellknown values for a PCD,
then either `PcdsPatchableInModule` or `PcdsDynamicEx` - the first
being for testing a module, the second giving the ability for doing individual
driver performance tuning "on-the-fly".
**********
-#### 2.8.3.8 Precedence
+#### 2.7.3.8 Precedence
Tools must assume that the first method found for a PCD in the PCDs sections
will used for all instances of a PCD. Tools must not allow for different
modules using a PCD differently, using the `<Pcds*>` statements under the INF
file definitions in the `[Components]` section.
@@ -375,11 +375,11 @@ listed more than one time within a section. List a PCD in one of the other
access methods is allowed, provided a single access method must be used for all
instances of the PCD. If PCD field value is listed, it will override PCD value
even if PCD value is after PCD field value.
**********
-#### 2.8.3.9 Library Instances
+#### 2.7.3.9 Library Instances
Library Instances that use PCDs that the module is linked with must use the
same PCD setting as the module using the Library Instance. So if a module uses
a PCD as `PcdsFixedAtBuild`, then all library instances that use that PCD must
also use the PCD as `PcdsFixedAtBuild` with the same value.
@@ -393,11 +393,11 @@ The expression is a C-style expression using C relational, equality and logical
numeric and bitwise operators or numeric and bitwise operators that evaluate to
a value that matches the PCD's Datum Type (specified in the DEC package
declaration file.) Precedence and associativity follow C standards. Using PCDs
in expressions is also permitted.
-#### 2.8.3.10 Maximum Size of a VOID* PCD
+#### 2.7.3.10 Maximum Size of a VOID* PCD
If the maximum size of a VOID* PCD is not specified in the DSC file, then the
maximum size will be calculated based on the largest size of the following:
* the string or array in the --pcd option
diff --git a/2_dsc_overview/29_pcd_sections.md b/2_dsc_overview/28_pcd_sections.md
similarity index 93%
rename from 2_dsc_overview/29_pcd_sections.md
rename to 2_dsc_overview/28_pcd_sections.md
index d84d2f4..0b0b6d3 100644
--- a/2_dsc_overview/29_pcd_sections.md
+++ b/2_dsc_overview/28_pcd_sections.md
@@ -1,9 +1,9 @@
<!--- @file
2.9 PCD 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:
@@ -27,13 +27,13 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 2.9 PCD Sections
+## 2.8 PCD Sections
-### 2.9.1 [PcdsFeatureFlag] section
+### 2.8.1 [PcdsFeatureFlag] section
The required content for the FeatureFlag PCD is the PCD Token Space Guid C
name, the PCD's C name (these two entries are separated by the period
character), and a Boolean value of either TRUE, FALSE, 1 or 0. The PCD name
and value entries are separated by the pipe "|" character.
@@ -69,19 +69,19 @@ Format of an entry in this section is:
```ini
[PcdsFeatureFlag.common]
gEfiMdeModulePkgTokenSpaceGuid.PcdDxePcdDatabaseTraverseEnabled|1
```
-### 2.9.2 [PcdsFixedAtBuild] and [PcdsPatchableInModule] sections
+### 2.8.2 [PcdsFixedAtBuild] and [PcdsPatchableInModule] sections
The section modifier, `SkuIdentifier`, can be used by the build tools to create
images for one specific SKU. Unlike the `PcdsDynamic` and `PcdsDynamicEx`
entries, no access methods are allowed for having different values during
runtime for different SKUs. Do not use the `SkuIdentifier` when building all
SKUs.
-#### 2.9.2.1 PcdsFixedAtBuild
+#### 2.8.2.1 PcdsFixedAtBuild
The `FixedAtBuild` PCD access method cannot be used in a Binary Module.
The required content for the `FixedAtBuild` PCD are the PCD Token Space Guid
C name, the PCD's C name (these two entries are separated by the period
@@ -125,11 +125,11 @@ Format for Boolean and numeric entries in this section is:
gEfiMdePkgTokenSpaceGuid.PcdFSBClock|200000000
gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
gEfiEdkNt32PkgTokenSpaceGuid.PcdWinNtPhysicalDisk|L"E:RW;245760;512"|VOID*|32
```
-#### 2.9.2.2 PcdsPatchableInModule
+#### 2.8.2.2 PcdsPatchableInModule
The `PatchableInModule` PCD access method can be used with modules that are
distributed in binary form. The PCD's value can be patched by tools that know
the offset of the PCD into the binary file.
@@ -163,11 +163,11 @@ Format of an entry in this section is:
```ini
[PcdsPatchableInModule.common]
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000000|UINT32|4
```
-### 2.9.3 [PcdsDynamic*] and [PcdsDynamicEx*] sections
+### 2.8.3 [PcdsDynamic*] and [PcdsDynamicEx*] sections
PCDs listed in these sections cannot be used in conditional directive
statements.
The Dynamic PCD access method cannot be used for modules that are distributed
@@ -185,11 +185,11 @@ binary image supports multiple SKUs. The SKU selection based on things like a
hardware jumper, or some other method that is outside the scope of this
document.
For using the standard PCD Get/Set PPI or Protocol.
-#### 2.9.3.1 PcdsDynamicDefault
+#### 2.8.3.1 PcdsDynamicDefault
The Dynamic Default PCD access method will generate a volatile variable that
can be accessed at runtime using PCD a Get PPI or Protocol.
```ini
@@ -213,11 +213,11 @@ The format for a VOID* PCD entry in this section is:
[PcdsDynamicDefault]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0
```
-#### 2.9.3.2 PcdsDynamicHII
+#### 2.8.3.2 PcdsDynamicHII
The Dynamic Hii PCD access method will generate HII data content that can be
accessed at runtime.
For using the HII for PCD data, the section name is as follows:
@@ -259,11 +259,11 @@ described in the following table.
[PcdsDynamicHii.common.DEFAULT]
gEfiMdeModulePkgTokenSpaceGuid.PcdValidRange|L"PcdValidRange"|gEfiGlobalVariableGuid|0x07|0|BS,RT,NV
```
-#### 2.9.3.3 PcdsDynamicVpd
+#### 2.8.3.3 PcdsDynamicVpd
The Dynamic Vpd PCD access method will generate macros that allow the data
content (stored in read-only memory) to be accessed at runtime. Note that the
PCD drivers may use a copy of the VPD data to allow runtime changes to these
variables.
@@ -296,11 +296,11 @@ The format for VOID* datum type content in this section is:
gNoSuchTokenSpaceGuid.PcdOemBootOptionName | 0x22D4 | 100 | " " # VOID*
gNoSuchTokenSpaceGuid.PcdOemBootOptionPath | 0x2338 | 100 | " " # VOID*
gNoSuchTokenSpaceGuid.PcdEnableFastBoot | 0x239C | 1 | FALSE # BOOLEAN
```
-#### 2.9.3.4 PcdsDynamicExDefault
+#### 2.8.3.4 PcdsDynamicExDefault
The DynamicEx access method of PCD is recommended for modules that are
distributed in binary form.
Entries for `DynamicEx` are identical to the `Dynamic` entries. The `DynamicEx`
@@ -327,11 +327,11 @@ The format for a VOID* PCD entry in this section is:
[PcdsDynamicExDefault.common.DEFAULT]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0
```
-#### 2.9.3.5 PcdsDynamicEx Hii
+#### 2.8.3.5 PcdsDynamicEx Hii
For using the HII for PCD data, the section name is as follows:
`[PcdsDynamicExHii.$(arch).$(SKUID_IDENTIFIER)]`
@@ -357,11 +357,11 @@ described in Table 9 HII Attributes.
[PcdsDynamicExHii.common.DEFAULT]
gEfiMdeModulePkgTokenSpaceGuid.PcdValidRange|L"PcdValidRange"|gEfiGlobalVariableGuid|0x07|0|BS,RT,NV
```
-#### 2.9.3.6 PcdsDynamicExVpd
+#### 2.8.3.6 PcdsDynamicExVpd
For using the VPD for PCD data, the section name is:
`[PcdsDynamicExVpd.$(arch).$(SKUID_IDENTIFIER)]`
diff --git a/2_dsc_overview/210_pcd_database.md b/2_dsc_overview/29_pcd_database.md
similarity index 96%
rename from 2_dsc_overview/210_pcd_database.md
rename to 2_dsc_overview/29_pcd_database.md
index 2e4380c..ab3fda5 100644
--- a/2_dsc_overview/210_pcd_database.md
+++ b/2_dsc_overview/29_pcd_database.md
@@ -1,9 +1,9 @@
<!--- @file
2.10 PCD Database
- 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:
@@ -27,11 +27,11 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 2.10 PCD Database
+## 2.9 PCD Database
Dynamic and DynamicEx PCDs can be modified during the boot/setup stages. In
order to support modifications, a PEIM and a DXE driver use databases of these
PCDs so that changes can persist across reboots. These databases are generated
prior to the final image assembly. The following rules determine when the build
diff --git a/3_edk_ii_dsc_file_format/311_[components]_sections.md b/3_edk_ii_dsc_file_format/310_[components]_sections.md
similarity index 81%
rename from 3_edk_ii_dsc_file_format/311_[components]_sections.md
rename to 3_edk_ii_dsc_file_format/310_[components]_sections.md
index b8e2875..abca3e9 100644
--- a/3_edk_ii_dsc_file_format/311_[components]_sections.md
+++ b/3_edk_ii_dsc_file_format/310_[components]_sections.md
@@ -1,9 +1,9 @@
<!--- @file
3.11 [Components] 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:
@@ -27,11 +27,11 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 3.11 [Components] Sections
+## 3.10 [Components] Sections
The `[Components]` sections are required.
#### Summary
@@ -42,12 +42,11 @@ files.
The `!include` statement is permitted in `[Components]` sections. however this
method is NOT recommended.
All EDK II file paths must be specified relative to a directory containing EDK
II Packages (as specified by the WORKSPACE or a directory listed in
-PACKAGES_PATH system environment variable). EDK INF component and library files
-may use `$(EDK_SOURCE)` or `$(EFI_SOURCE)` global environment variables. If the
+PACKAGES_PATH system environment variable). If the
environment variable is not specified, the INF file path is assumed to be
relative to the `WORKSPACE`.
The following is an example of specifying a `WORKSPACE` (MdeModulePkg is in the
directory pointed to by the WORKSPACE environment variable) relative Path:
@@ -55,11 +54,11 @@ directory pointed to by the WORKSPACE environment variable) relative Path:
`MdeModulePkg/Universal/Disk/DiskIo/Dxe`
The following is an example of specifying an Indirect Path:
```ini
-DEFINE FOUNDATION_LIB = $(EDK_SOURCE)/Foundation/Library
+DEFINE FOUNDATION_LIB = $(WORKSPACE)/Foundation/Library
$(FOUNDATION_LIB)/EdkIIGlueLib/EntryPoints
```
The permitted `DEFINE` statement must be a variable name assigned to a path.
@@ -91,13 +90,10 @@ value, while the `<PcdsFixedAtBuild>` section of an INF use a different value.
The FeatureFlag PCD and the two dynamic forms of PCDs are common to a platform,
with the dynamic form PCD values stored in a "runtime database", read-only
memory location or an HII data store. Therefore, having different values is
prohibited for these access methods.
-EDK components may have the scoped sub-element, `<SOURCE_OVERRIDE_PATH>` that
-is used to virtually replace files in the component's directory.
-
The format for items listed in the sub-elements is the identical format for
content under the section.
Within the context of an EDK II module sub-element, the `<LibraryClasses>`
entries must appear before `<Pcds*>` entries; the `<LibraryClasses>` entries
@@ -128,20 +124,16 @@ modules in a binary image (the FDF file describes that ordering).
<attribs> ::= <attrs> ["," <TS> "Components" <attrs>]*
<attrs> ::= "." <arch>
<ModuleStatements> ::= {<MacroDefinition>}
{<IncludeStatement>} {<TS> <InfFiles>}
<InfFiles> ::= <InfFilename> [<MTS> <Options>] <EOL>
-<Options> ::= {<Exec>} {<Edk2Struct>} {<EdkStruct>}
+<Options> ::= {<Exec>} {<Edk2Struct>}
<InfFilename> ::= <PATH> <Word> ".inf"
<Exec> ::= "EXEC" <Eq> <ExecFilename>
<ExecFilename> ::= <PATH> <Word> ["." <ExecExtension>]
<ExecExtension> ::= <Word> # An OS recognisable extension that will #
automatically be run.
-<EdkStruct> ::= "{" <EOL>
- <TS> "<SOURCE_OVERRIDE_PATH>" <EOL>
- <TS> <PATH>
- <TS> "}" <EOL>
<Edk2Struct> ::= "{" <EOL>
[<TS> <DefSec>]
[<TS> <LibraryClasses>]
[<TS> <PcdsFeatureFlag>]
[<TS> <PcdsFixed>]
@@ -267,49 +259,5 @@ individual modules.
**_ClassName_**
A Library Class Keyword defined in DEC files. The Keyword must also be present
in the defines section `LIBRARY_CLASS` entry of the INF file
-
-#### Example Using EDK components in an EDK II DSC build
-
-```
-[Components]
-DEFINE EDK=$(EDK_SOURCE)/Edk
-DEFINE MDE=MdePkg/Library
-DEFINE STATUS_CODE=$(MDE)/PeiDxeDebugLibReportStatusCode
-
-$(EDK)/Foundation/Core/Pei/PeiMain.inf
-DEFINE NT32 = $(EDK)/Sample/Platform
-$(NT32)/Generic/MonoStatusCode/Pei/Nt32/MonoStatusCode.inf
-$(NT32)/Nt32/Pei/BootMode/BootMode.inf
-$(NT32)/Nt32/Pei/FlashMap/FlashMap.inf
-MdeModulePkg/Core/Dxe/DxeMain.inf
-...
-MdeModulePkg/Universal/Debugger/Debugport/Dxe/DebugPort.inf
-MdeModulePkg/Cpu/DebugSupport/Dxe/DebugSupport.inf
-...
-
-DEFINE MDEMODUNI = MdeModulePkg/Universal
-$(MDEMODUNI)/DataHub/DataHubStdErr/Dxe/DataHubStdErr.inf
-MdeModulePkg/Universal/Disk/DiskIo/Dxe/DiskIo.inf {
- <LibraryClasses>
- DebugLib|$(STATUS_CODE)/PeiDxeDebugLibReportStatusCode.inf
- BaseMemoryLib|$(MDE)/DxeMemoryLib/DxeMemoryLib.inf
- MemoryAllocationLib|$(MDE)/DxeMemoryAllocationLib/DxeMemoryAllocationLib.inf
- <PcdsFeatureFlag>
- PcdDriverDiagnosticsDisable|gEfiMdePkgTokenSpaceGuid|FALSE
-}
-MdeModulePkg/Universal/Ebc/Dxe/Ebc.inf
-$(MDEMODUNI)/GenericMemoryTest/Dxe/NullMemoryTest.inf
-$(MDEMODUNI)/StatusCode/Pei/PeiStatusCode.inf {
- <BuildOptions>
- MSFT:RELEASE_MYTOOLS_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
- DEBUG_MYTOOLS_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
- DEBUG_WINDDK3790x1830_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
- RELEASE_WINDDK3790x1830_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
- DEBUG_VS2003_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
- RELEASE_VS2003_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
-}
-MdeModulePkg/Logo/Logo.inf
-...
-```
diff --git a/3_edk_ii_dsc_file_format/312_[userextensions]_sections.md b/3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
similarity index 94%
rename from 3_edk_ii_dsc_file_format/312_[userextensions]_sections.md
rename to 3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
index 6020c5c..504fa9f 100644
--- a/3_edk_ii_dsc_file_format/312_[userextensions]_sections.md
+++ b/3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
@@ -1,9 +1,9 @@
<!--- @file
3.12 [UserExtensions] 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:
@@ -27,11 +27,11 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 3.12 [UserExtensions] Sections
+## 3.11 [UserExtensions] Sections
The `[UserExtensions]` sections are optional.
#### Summary
diff --git a/3_edk_ii_dsc_file_format/313_[defaultstores]_section.md b/3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
similarity index 93%
rename from 3_edk_ii_dsc_file_format/313_[defaultstores]_section.md
rename to 3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
index 23dec7d..dfa7fa8 100644
--- a/3_edk_ii_dsc_file_format/313_[defaultstores]_section.md
+++ b/3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
@@ -1,9 +1,9 @@
<!--- @file
3.13 [DefaultStores] Section
- 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:
@@ -27,11 +27,11 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 3.13 [DefaultStores] Section
+## 3.12 [DefaultStores] Section
The `[DefaultStores]` section is optional in all EDK II DSC files.
#### Summary
diff --git a/3_edk_ii_dsc_file_format/32_general_rules.md b/3_edk_ii_dsc_file_format/32_general_rules.md
index e040abc..d0cdb9b 100644
--- a/3_edk_ii_dsc_file_format/32_general_rules.md
+++ b/3_edk_ii_dsc_file_format/32_general_rules.md
@@ -1,9 +1,9 @@
<!--- @file
3.2 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:
@@ -118,16 +118,5 @@ is unknown.
Unless otherwise noted, all file names and paths are relative EDK II Packages
(subdirectories in directories pointed to by WORKSPACE or PACKAGES_PATH system
environment variables). A directory name that starts with a word is assumed by
the build tools to be an EDK II Package directory name.
-
-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_dsc_file_format/33_platform_dsc_definition.md b/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
index 07f10d6..0679ff0 100644
--- a/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
+++ b/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
@@ -1,9 +1,9 @@
<!--- @file
3.3 Platform DSC 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:
@@ -45,24 +45,21 @@ PatchableInModule or DynamicEx PCDs.
specified in the `[Defines]` section or SET statements.
**********
The `[Defines]` section must appear before any other sections (except the
header comment blocks). The remaining sections may appear in any order, however
-the EBNF, below, shows the recommended order. (The `[Libraries]` section is
-required if building EDK libraries and components in the context of an EDK II
-platform.)
+the EBNF, below, shows the recommended order.
#### Summary
The EDK II Platform Description (DSC) file has the following format (using the
EBNF).
```c
<EDK_II_DSC> ::= [<Header>]
<Defines>
[<SkuIds>]
- <Libraries>*
<LibraryClasses>*
<Pcds>*
<Components>+
<BuildOptions>*
<UserExtensions>*
@@ -377,12 +374,11 @@ Highest Priority
3. Macros defined in the DSC file's `[Defines]` section
Lowest Priority
Macros defined in the `[Defines]` section are considered global during the
-processing of the FDF file and the DSC file. `EDK_GLOBAL` macros are considered
-global during the processing of DSC, FDF and EDK INF files.
+processing of the FDF file and the DSC file.
Macros are not allowed to redefine the reserved words specified in this file.
For example, it is not permitted to `DEFINE DEFINE = FOOBAR`, then use `FOOBAR`
as a the reserved word.
@@ -406,13 +402,12 @@ may report the error on the line that uses the macro, `$(MACRO)`, rather than
where the macro was defined.
#### Prototype
```c
-<MacroDefinition> ::= {<NormalMacro>} {<EdkMacro>}
+<MacroDefinition> ::= {<NormalMacro>}
<NormalMacro> ::= <TS> "DEFINE" <MTS> <MACRO> <Eq> [<Value>] <EOL>
-<EdkMacro> ::= <TS> "EDK_GLOBAL" <MTS> <MACRO> <Eq> [<Value>] <EOL>
<Value> ::= {<Number>} {<BoolType>} {<GUID>}
{<CString>} {<UnicodeString>} {<CArray>}
{<PATH>} {<Expression>} {<CFlags>}
{<RelativePath>} {<Filename>}
```
@@ -449,11 +444,10 @@ defined in this file may be used in the Flash FDF file.
```
DEFINE GEN_SKU = MyPlatformPkg/GenPei
DEFINE SKU1 = MyPlatformPkg/Sku1/Pei
DEFINE HACK = DEBUG
-EDK_GLOBAL EFI_ACPI_TABLE_STORAGE_GUID = 7E374E25-8E01-4FEE-87F2390C23C606CD
```
### 3.3.3 Conditional Directive Blocks
Use of conditional directive blocks is optional.
@@ -697,12 +691,11 @@ in the DSC file. The included file's content must match the content of the
section that the `!include` statement resides, or it may contain completely new
sections. If the included file starts with a section header, then the section
being processed in the Platform DSC file is considered to have been terminated.
If the `<Filename>` contains "$" characters, then macros defined in the DSC
-file and the system environment variables, `$(WORKSPACE)`, `$(EDK_SOURCE)`,
-`$(EFI_SOURCE)`, and `$(ECP_SOURCE)` are substituted into `<Filename>`.
+file and the system environment variable `$(WORKSPACE)` are substituted into `<Filename>`.
The tools look for `<Filename>` relative to the directory the DSC file resides.
If the file is not found, and a directory separator is in `<Filename>`, the
tools attempt to find the file in a WORKSPACE (or a directory listed in the
PACKAGES_PATH) relative path. If the file cannot be found, the build system
diff --git a/3_edk_ii_dsc_file_format/35_[defines]_section.md b/3_edk_ii_dsc_file_format/35_[defines]_section.md
index 7337415..ea2077d 100644
--- a/3_edk_ii_dsc_file_format/35_[defines]_section.md
+++ b/3_edk_ii_dsc_file_format/35_[defines]_section.md
@@ -1,9 +1,9 @@
<!--- @file
3.5 [Defines] Section
- 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:
@@ -179,19 +179,10 @@ specifying the three language codes in this statement will limit the final
output of string parsing tools to strings for these three languages. Tools must
use a "Get Best Language" function when filtering the content. The
`RFC_LANGUAGES` statement must be used when processing EDK II Modules. Space
characters are not permitted within the list.
-**_ISO 639-2 Language Code_**
-
-One or more three character language codes, formatted per ISO 639-2, with no
-separator character (for example: "engfraspa".) This list can be used to filter
-the output of tools that generate unicode strings. Tools must use a "Get Best
-Language" function when filtering the content. The `ISO_LANGUAGES` statement
-must be used when processing EDK Components. Space characters are not permitted
-within the list.
-
**_BuildNumber_**
This value, if present, will be used during the creation of
`EFI_SECTION_VERSION` sections. Values in this file override any values set in
the INF files. If not present, the EDK II build tools must use a value of `0`.
@@ -225,8 +216,7 @@ compiling them into a machine language program.
OUTPUT_DIRECTORY = Build/Nt32
SUPPORTED_ARCHITECTURES = IA32
BUILD_TARGETS = DEBUG|RELEASE
RFC_LANGUAGES = "en-us;
zh-hans;fr-fr"
- ISO_LANGUAGES = "engchnfra"
SKUID_IDENTIFIER = SkuTwo|DEFAULT
```
diff --git a/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md b/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
index 71d778d..5f0a95c 100644
--- a/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
+++ b/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
@@ -1,9 +1,9 @@
<!--- @file
3.6 [BuildOptions] 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:
@@ -49,16 +49,15 @@ expectation is that other tools will be responsible for expanding the macro.
This section is used to replace flags or append flags to the end of the tool
code flags defined in the `tools_def.txt` file. The `Family` tag can be used
for elements that are shared between different architectures, and different
tool chain tag names.
-The `[BuildOptions]` section modifier, CodeBase, (value of EDK or EDKII,
-default is EDKII) allows for platform integrators to override default build
+The `[BuildOptions]` section modifier, CodeBase, (value is EDKII) allows for
+platform integrators to override default build
options set in the `tools_def.txt` file scoped according to the type of INF
file being processed. EDK II INF files all contain an `INF_VERSION` element in
-their `[Defines]` section, while EDK libraries and components do not have the
-element. The `[BuildOptions]` section of an INF file override both the
+their `[Defines]` section. The `[BuildOptions]` section of an INF file override both the
`tools_def.txt` options and the options set in the `[BuildOptions]` section. In
order to override options set in the INF file, the options must be overridden
using the INF scoped `<BuildOptions>` tag after an INF file specified in the
`[Components]` section.
@@ -167,27 +166,27 @@ The result would logically be: `*_*_*_TEST_FLAGS = /a /b`
```
The result for EDK II modules would be: `*_*_*_TEST_FLAGS = /a /b /c`
```ini
-[BuildOptions.common.EDK]
- # Entries are for EDK components and libraries
+[BuildOptions.common.EDKII]
+ # Entries are for EDK II components and libraries
*_*_*_TEST_FLAGS = /d
```
-The result for EDK components and libraries would be: `*_*_*_TEST_FLAGS = /a /b /d`
+The result for EDKII components and libraries would be: `*_*_*_TEST_FLAGS = /a /b /d`
```ini
[BuildOptions.IA32]
# Architectural options for IA32
*_*_*_TEST_FLAGS = /e
```
The logical result is: `*_*_IA32_TEST_FLAGS = /a /b /c /e`
```ini
-[BuildOptions.X64.EDK]
+[BuildOptions.X64.EDKII]
# Architectural options for X64
*_*_*_TEST_FLAGS = /f
DEBUG_*_*_TEST_FLAGS = /g
RELEASE_*_*_TEST_FLAGS = /h
```
@@ -220,11 +219,11 @@ The logical result is:
#### Prototype
```c
<BuildOptions> ::= "[BuildOptions" [<attribs>] "]" <EOL> <Statements>*
<attribs> ::= "." <arch> [<CodeBase> ["." <ModuleType>]]
-<CodeBase> ::= "." {"Common"} {"EDK"} {"EDKII"}
+<CodeBase> ::= "." {"Common"} {"EDKII"}
<Statements> ::= {<MacroDefinition>} {<IncludeStatement>}
{<TS> <BStatement>}
<BStatement> ::= {<ToolFlag>} {<ToolPath>} {<ToolCmd>} {<Other>}
<ToolFlag> ::= [<Family> ":"] <FlagSpec> <Equal> <Flags> <EOL>
<ToolPath> ::= [<Family> ":"] <PathSpec> <Equal> <PATH> <EOL>
diff --git a/3_edk_ii_dsc_file_format/38_[libraries]_sections.md b/3_edk_ii_dsc_file_format/38_[libraries]_sections.md
deleted file mode 100644
index 23c441c..0000000
--- a/3_edk_ii_dsc_file_format/38_[libraries]_sections.md
+++ /dev/null
@@ -1,94 +0,0 @@
-<!--- @file
- 3.8 [Libraries] 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.
-
--->
-
-## 3.8 [Libraries] Sections
-
-The section `[Libraries]` sections are optional in EDK II DSC files, although
-if any EDK component is specified in the `[Components]` section, then the EDK
-II DSC file must contain this section. EDK components can not use EDK II
-Library Instances.
-
-#### Summary
-
-Defines the `[Libraries]` section tag which lists the libraries that are linked
-against
-
-EDK I components. Entries may appear in any order. Entries for EDK are a list
-of INF files, with a path that is relative to the `$(EFI_SOURCE)`,
-`$(EDK_SOURCE)` or `$(ECP_SOURCE)` directories (or a MACRO definition).
-
-One or more `!include` statements may be used within the libraries sections. If
-used, the file included must be a list of INF files and their paths relative to
-the `$(EFI_SOURCE)`, `$(EDK_SOURCE)` or `$(ECP_SOURCE)` directories.
-
-#### Prototype
-
-```c
-<Libraries> ::= "[Libraries" [<attribs>] "]" <EOL> <LibStatements>*
-<LibStatements> ::= {<MacroDefinition>} {<IncludeStatement>}
- {<Statement>}
-<attribs> ::= "." <arch> [", Libraries." <arch>]*
-<Statement> ::= <TS> <PathAndFilename> <EOL>
-<PathAndFilename> ::= <LPATH> <Word> ".inf"
-<LPATH> ::= [{"$(EDK_SOURCE)"} {<MACROVAL>} "/"] <Path>*
-<Path> ::= <Word> "/"
-```
-
-#### Parameters
-
-**_arch_**
-
-The arch attribute must be specified in the `Conf/tools_def.txt` file for the
-tool chain used to build the platform in order to be valid.
-
-**_Path_**
-
-If only the `<Path>` element is specified, the path is `WORKSPACE` relative.
-
-#### Example
-
-```ini
-[Libraries]
- Foundation/Efi/Guid/EfiGuidLib.inf
- Foundation/Framework/Guid/EdkFrameworkGuidLib.inf
- Foundation/Guid/EdkGuidLib.inf
- Foundation/Library/EfiCommonLib/EfiCommonLib.inf
- Foundation/Cpu/Pentium/CpuIA32Lib/CpuIA32Lib.inf
- Foundation/Cpu/Itanium/CpuIA64Lib/CpuIA64Lib.inf
- Foundation/Library/CustomizedDecompress/CustomizedDecompress.inf
-
-[Libraries.IA32]
- DEFINE PLATFORM_DIR = $(EDK_SOURCE)/Platform
- $(PLATFORM_DIR)/IntelEpg/Guid/IntelEpgGuidLib.inf
- $(PLATFORM_DIR)/IntelEpg/Ppi/IntelEpgPpiLib.inf
- $(PLATFORM_DIR)/Generic/Guid/GenericGuidLib.inf
- $(PLATFORM_DIR)/Generic/Lib/Port80MappingLib/PlatformPort80.inf
-```
diff --git a/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md b/3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
similarity index 95%
rename from 3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
rename to 3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
index 9ac3878..cc9f96e 100644
--- a/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
+++ b/3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
@@ -1,9 +1,9 @@
<!--- @file
3.9 [LibraryClasses] 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:
@@ -27,11 +27,11 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 3.9 [LibraryClasses] Sections
+## 3.8 [LibraryClasses] Sections
The `[LibraryClasses]` sections are optional if no library classes are defined
for any of the components, or if only EDK modules are used.
#### Summary
diff --git a/3_edk_ii_dsc_file_format/310_pcd_sections.md b/3_edk_ii_dsc_file_format/39_pcd_sections.md
similarity index 97%
rename from 3_edk_ii_dsc_file_format/310_pcd_sections.md
rename to 3_edk_ii_dsc_file_format/39_pcd_sections.md
index f982d60..96e4f0e 100644
--- a/3_edk_ii_dsc_file_format/310_pcd_sections.md
+++ b/3_edk_ii_dsc_file_format/39_pcd_sections.md
@@ -1,9 +1,9 @@
<!--- @file
3.10 PCD 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:
@@ -27,11 +27,11 @@
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
-## 3.10 PCD Sections
+## 3.9 PCD Sections
The PCD sections are optional.
PCD Values listed in the DSC file must be absolute values, macro names or
expressions which may include other PCD names and/or macro names that have been
@@ -111,11 +111,11 @@ PCDs with a C strucutre type is also a VOID* PCD. Its value can be specified lik
normal VOID* PCD, and also be specified by its structure field.
Refer to the _EDK II Build Specification_ for the description of the PCD
processing rules.
-### 3.10.1 [PcdsFeatureFlag] Sections
+### 3.9.1 [PcdsFeatureFlag] Sections
These are optional sections for EDK II DSC Files.
#### Summary
@@ -192,11 +192,11 @@ section tag can only be used as a conditional modifier.
`SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
must break, stating that this platform requires separate builds for individual
`SkuId`s.
**********
-### 3.10.2 [PcdsFixedAtBuild] Section
+### 3.9.2 [PcdsFixedAtBuild] Section
These are optional sections for EDK II DSC Files.
#### Summary
@@ -298,11 +298,11 @@ must be used.
`SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
must break, stating that this platform requires separate builds for individual
`SkuId`s.
**********
-### 3.10.3 [PcdsPatchableInModule] Sections
+### 3.9.3 [PcdsPatchableInModule] Sections
These are optional sections.
#### Summary
@@ -403,11 +403,11 @@ must be used.
`SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
must break, stating that this platform requires separate builds for individual
`SkuId`s.
**********
-### 3.10.4 [PcdsDynamic] Sections
+### 3.9.4 [PcdsDynamic] Sections
These are optional sections.
#### Summary
@@ -632,11 +632,11 @@ the _UEFI Specification_ for a description of these attributes.
[PcdsDynamicHii.IA32, PcdsDynamicHii.X64.Sku1.Standard]
gEfiMyModulePkgTokenSpaceGuid.PcdChassisIntrution|L"TestVariable"|gSysConfigGuid|0x83|0x0
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|10 # Variable: L"Timeout"
```
-### 3.10.5 [PcdsDynamicEx] Sections
+### 3.9.5 [PcdsDynamicEx] Sections
These are optional sections.
#### Summary
--
2.20.1.windows.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [Patch] Document: Update DSC spec to remove EDK related contents
2019-03-05 3:48 [Patch] Document: Update DSC spec to remove EDK related contents Feng, Bob C
@ 2019-03-05 15:24 ` Carsey, Jaben
2019-03-06 8:31 ` Gao, Liming
1 sibling, 0 replies; 3+ messages in thread
From: Carsey, Jaben @ 2019-03-05 15:24 UTC (permalink / raw)
To: Feng, Bob C, edk2-devel@lists.01.org; +Cc: Gao, Liming
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
It's a lot of changes. It looks good to me.
> -----Original Message-----
> From: Feng, Bob C
> Sent: Monday, March 04, 2019 7:49 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] Document: Update DSC spec to remove EDK related
> contents
> Importance: High
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
>
> Remove EDK related contents inf Dsc 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 | 14 +--
> ...=> 210_[components]_section_processing.md} | 27 +-----
> ...ion.md => 211_[userextensions]_section.md} | 4 +-
> ...212_[defaultstores]_section_processing.md} | 4 +-
> .../22_build_description_file_format.md | 50 ++--------
> .../23_[defines]_section_processing.md | 12 +--
> 2_dsc_overview/24_[buildoptions]_section.md | 72 ++------------
> .../26_[libraries]_section_processing.md | 69 --------------
> ...26_[libraryclasses]_section_processing.md} | 4 +-
> ...essing.md => 27_pcd_section_processing.md} | 34 +++----
> ...{29_pcd_sections.md => 28_pcd_sections.md} | 26 ++---
> ...210_pcd_database.md => 29_pcd_database.md} | 4 +-
> ...ctions.md => 310_[components]_sections.md} | 62 +-----------
> ...ns.md => 311_[userextensions]_sections.md} | 4 +-
> ...tion.md => 312_[defaultstores]_section.md} | 4 +-
> 3_edk_ii_dsc_file_format/32_general_rules.md | 13 +--
> .../33_platform_dsc_definition.md | 17 +---
> .../35_[defines]_section.md | 12 +--
> .../36_[buildoptions]_sections.md | 19 ++--
> .../38_[libraries]_sections.md | 94 -------------------
> ...ons.md => 38_[libraryclasses]_sections.md} | 4 +-
> ...310_pcd_sections.md => 39_pcd_sections.md} | 14 +--
> 22 files changed, 101 insertions(+), 462 deletions(-)
> rename 2_dsc_overview/{211_[components]_section_processing.md =>
> 210_[components]_section_processing.md} (84%)
> rename 2_dsc_overview/{212_[userextensions]_section.md =>
> 211_[userextensions]_section.md} (93%)
> rename 2_dsc_overview/{213_[defaultstores]_section_processing.md =>
> 212_[defaultstores]_section_processing.md} (93%)
> delete mode 100644 2_dsc_overview/26_[libraries]_section_processing.md
> rename 2_dsc_overview/{27_[libraryclasses]_section_processing.md =>
> 26_[libraryclasses]_section_processing.md} (96%)
> rename 2_dsc_overview/{28_pcd_section_processing.md =>
> 27_pcd_section_processing.md} (94%)
> rename 2_dsc_overview/{29_pcd_sections.md => 28_pcd_sections.md}
> (93%)
> rename 2_dsc_overview/{210_pcd_database.md => 29_pcd_database.md}
> (96%)
> rename 3_edk_ii_dsc_file_format/{311_[components]_sections.md =>
> 310_[components]_sections.md} (81%)
> rename 3_edk_ii_dsc_file_format/{312_[userextensions]_sections.md =>
> 311_[userextensions]_sections.md} (94%)
> rename 3_edk_ii_dsc_file_format/{313_[defaultstores]_section.md =>
> 312_[defaultstores]_section.md} (93%)
> delete mode 100644 3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> rename 3_edk_ii_dsc_file_format/{39_[libraryclasses]_sections.md =>
> 38_[libraryclasses]_sections.md} (95%)
> rename 3_edk_ii_dsc_file_format/{310_pcd_sections.md =>
> 39_pcd_sections.md} (97%)
>
> diff --git a/1_introduction/11_overview.md
> b/1_introduction/11_overview.md
> index d9006df..ff2b517 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:
>
> @@ -48,14 +48,11 @@ specifications.
> This design has the following goals.
>
> **Compatible**
>
> The EDK II DSC format does not support EDK DSC format, nor can EDK tools
> be
> -used to parse the EDK II DSC format files. The EDK II DSC Format must
> maintain
> -backward compatibility for supporting existing EDK INF file formats. This
> means
> -that the changes made to this specification do not require changes for
> standard
> -INF files.
> +used to parse the EDK II DSC format files.
>
> **Simplified platform build and configuration**
>
> One goal of this format is to simplify the build setup and configuration for a
> given platform. It was also designed to simplify the process of adding EDK II
> @@ -67,11 +64,11 @@ builds.
> ###### Table 1 EDK Build Infrastructure Support Matrix
>
> | | EDK DSC | EDK II DSC | EDK FDF | EDK II FDF | EDK INF |
> EDK II INF |
> | ------------------ |:---------:|:------------:|:---------:|:------------:|:---------:|:----
> --------:|
> | EDK Build Tools | YES | NO | YES | NO | YES | NO |
> -| EDK II Build Tools | NO | YES | NO | YES | YES | YES
> |
> +| EDK II Build Tools | NO | YES | NO | YES | NO | YES
> |
>
> **********
> **Note:** This document is intended for persons doing EFI development
> and
> support for different platforms. It is most likely only of interest in the
> event that there is a problem with a build, or if a developer needs to
> perform
> @@ -90,9 +87,6 @@ contain information on the EFI format for FFS or FV file
> creation. The
> Makefiles will support third party compilation tools - Microsoft, Intel and
> GCC
> tool chains - and at least one EDK II tool, GenFw. The GenFw tool is used to
> manipulate the files emitted from the compilation tools.
>
> The EDK II build provides UEFI and PI (Unified EFI, Inc.)
> -specification-compliant images. Use of the tools in the EDK Compatibility
> -package can be used for creating earlier versions of EFI 1.10 and/or UEFI 2.0
> -compliant components. To be clear, EDK II tools do not have the limitation of
> -ECP tools, which can only do EFI 1.10 and UEFI 2.0 images.
> +specification-compliant images.
> diff --git a/2_dsc_overview/211_[components]_section_processing.md
> b/2_dsc_overview/210_[components]_section_processing.md
> similarity index 84%
> rename from 2_dsc_overview/211_[components]_section_processing.md
> rename to 2_dsc_overview/210_[components]_section_processing.md
> index 140f09c..c1948e8 100644
> --- a/2_dsc_overview/211_[components]_section_processing.md
> +++ b/2_dsc_overview/210_[components]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.11 [Components] Section Processing
>
> - 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:
>
> @@ -27,31 +27,24 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.11 [Components] Section Processing
> +## 2.10 [Components] Section Processing
>
> -One or more `[Components]` sections contain lists of EDK components and
> EDK II
> -Modules. The format for specifying the INF file for EDK II modules
> incorporates
> -new scoping capabilities.
> +One or more `[Components]` sections contain lists of EDK II Modules. The
> format
> +for specifying the INF file for EDK II modules incorporates new scoping
> capabilities.
>
> This section uses one or more of the following section definitions:
>
> * `[Components]`
> * `[Components.IA32]`
> * `[Components.X64]`
> * `[Components.EBC]`
> * `[Components.common]`
>
> -EDK components are specified using a fully qualified path to the EDK INF file.
> -
> -`$(EDK_SOURCE)/Path/and/Filename.inf`
> -
> -Because EDK II modules have different requirements than EDK I
> components,
> -specifying the INF filename in the extended DSC file may require more than
> just
> -the INF filename and options. A scoping structure, that binds library class
> +A scoping structure, that binds library class
> (with an optional override instance,) PCD settings (also overriding the values
> specified in the `[PcdsPatchableInModule]` or `[PcdsFixedAtBuild]` sections)
> and build options for an EDK II module may be required. This scoping
> structure,
> containing sub-elements, is enclosed within curly braces: "{}". The opening
> curly brace, "{", must appear at the end of the inf filename line, before any
> @@ -79,20 +72,10 @@ Path/and/Filename.inf {
>
> There are four valid, optional sub-elements for EDK II modules. These
> sub-element are enclosed within angle brackets: `<Defines>,
> <LibraryClasses>`,
> `<Pcds*>` and `<BuildOptions>`.
>
> -For EDK component INF files, an optional sub-element of
> -`<SOURCE_OVERRIDE_PATH>` has been defined. If this element is specified,
> files
> -listed in the directory are used instead of the "same-named" files in the
> -component's directory. If an EDK component directory lists files, A.c, B.c and
> -C.h, and the directory specified in this sub-element contains the file B.c,
> -then the component will be built using files from the component directory:
> A.c
> -and C.h, and the file B.c from the override directory. Any other files listed
> -in the override directory will NOT be included in the build (no new or
> -additional files are permitted).
> -
> An INF file line may also have one argument, EXEC = Filename, that specifies
> an executable file that takes the INF filename as a parameter. The Filename
> must be executable, and must take the INF filename. No other arguments
> are
> permitted to the Filename.
>
> diff --git a/2_dsc_overview/212_[userextensions]_section.md
> b/2_dsc_overview/211_[userextensions]_section.md
> similarity index 93%
> rename from 2_dsc_overview/212_[userextensions]_section.md
> rename to 2_dsc_overview/211_[userextensions]_section.md
> index c176d86..4708e7e 100644
> --- a/2_dsc_overview/212_[userextensions]_section.md
> +++ b/2_dsc_overview/211_[userextensions]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.12 [UserExtensions] Section
>
> - 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.12 [UserExtensions] Section
> +## 2.11 [UserExtensions] Section
>
> Users may develop custom tools that use the `[UserExtensions]`
> sections.The EDK
> II `[UserExtensions]` sections allow for extending the DSC file with custom
> processing of component images. The format for a user extension section
> specifier is:
> diff --git a/2_dsc_overview/213_[defaultstores]_section_processing.md
> b/2_dsc_overview/212_[defaultstores]_section_processing.md
> similarity index 93%
> rename from 2_dsc_overview/213_[defaultstores]_section_processing.md
> rename to 2_dsc_overview/212_[defaultstores]_section_processing.md
> index 88a7ad2..be83759 100644
> --- a/2_dsc_overview/213_[defaultstores]_section_processing.md
> +++ b/2_dsc_overview/212_[defaultstores]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.13 [DefaultStores] Section Processing
>
> - 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.13 [DefaultStores] Section Processing
> +## 2.12 [DefaultStores] Section Processing
>
> The contents of this section are used to define DefaultStores names. Default
> store is UEFI HII concept. It is used to define HII default setting for the
> different store, such as standard default, manufacturing default. Platform
> can define the supported default store for DynamicHii/DynamicExHii PCD in
> this
> diff --git a/2_dsc_overview/22_build_description_file_format.md
> b/2_dsc_overview/22_build_description_file_format.md
> index 31e23f4..10dc428 100644
> --- a/2_dsc_overview/22_build_description_file_format.md
> +++ b/2_dsc_overview/22_build_description_file_format.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.2 Build Description File Format
>
> - 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:
>
> @@ -229,19 +229,18 @@ definition, contain complete sections, or
> combination of both. And 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 the paths listed in the system environment
> -variables `$(WORKSPACE)`, `$(EFI_SOURCE)`, `$(EDK_SOURCE)`, and
> -`$(ECP_SOURCE)`. If the file is still not found, the parsing tools must
> -terminate with an error.
> +variable `$(WORKSPACE)`. If the file is still not found, the parsing tools
> +must terminate with an error.
>
> Macros, defined in this 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.
> +for macros. The system environment variable `$(WORKSPACE)`, may also be
> used;
> +only these system environment variables are permitted to start the path of
> the
> +included file.
>
> Statements in `!include` files must not break the integrity of the DSC 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.
> @@ -395,14 +394,10 @@ reference build (Nt32Pkg/Nt32Pkg.dsc), macros set
> on a command line override
> any macro value defined in the DSC (or FDF) file.
>
> MACROs may also be used as values in PCD statements. See _Section 3.10_
> for
> more information on PCD statements.
>
> -In order to support EDK components and libraries, the word `DEFINE` is
> replaced
> -with `EDK_GLOBAL`. The `EDK_GLOBAL` macros are considered global during
> the
> -processing of the DSC, FDF and EDK INF files.
> -
> Macros that appear within double quotation marks in build options sections
> are
> not expanded. It is assumed that they will be expanded by the OS or
> external
> scripting tools.
>
> Global variables that may be used in EDK II DSC and FDF meta-data files are
> @@ -427,13 +422,10 @@ be altered.
> ###### Table 3 Using System Environment Variable
>
> | Macro Style Used in Meta-Data Files | Matches Windows Environment
> Variable | Matches Linux & OS/X Environment Variable |
> | ----------------------------------- | ------------------------------------ | ---------------
> -------------------------- |
> | $(WORKSPACE) | %WORKSPACE% | $WORKSPACE
> |
> -| $(EFI_SOURCE) | %EFI_SOURCE% | $EFI_SOURCE
> |
> -| $(EDK_SOURCE) | %EDK_SOURCE% |
> $EDK_SOURCE |
> -| $(ECP_SOURCE) | %ECP_SOURCE% | $ECP_SOURCE
> |
> | $(EDK_TOOLS_PATH) | %EDK_TOOLS_PATH% |
> $EDK_TOOLS_PATH |
>
> The system environment variables, PACKAGES_PATH and EDK_TOOLS_BIN,
> are not
> permitted in EDK II meta-data files.
>
> @@ -479,22 +471,11 @@ follow the same rules as architectural modifiers.
> # Can use $(MDE) from the common section
> PalLib|$(MDE)/UefiPalLib/UefiPalLib.inf
>
> TimerLib|$(MDE)/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
> ```
>
> -### 2.2.7 EDK_GLOBAL
> -
> -The `EDK_GLOBAL` statements defined in the DSC file can be used during
> the
> -processing of the DSC, FDF and EDK INF files. The definition of the
> -`EDK_GLOBAL` name must only be done in the DSC `[Defines]` section.
> These
> -special macros can be used in path statements, DSC file `[BuildOptions]` and
> -FDF file `[Rule]` sections. These statements are used to replace the
> -environment variables that were defined for the EDK build tools. They must
> -never be used in a conditional directive statement in the DSC and FDF files,
> -nor can they be used by EDK II INF files.
> -
> -### 2.2.8 Conditional Directive Statements (!if...)
> +### 2.2.7 Conditional Directive Statements (!if...)
>
> Conditional directive statements are used by the build tools preprocessor
> function to include or exclude statements in the DSC file. A limited number
> of
> statements are supported, and nesting of conditionals is also supported.
> Statements are prefixed by the exclamation "!" character. Conditional
> @@ -642,11 +623,11 @@ The following are examples of conditional
> directives.
> !else
> # The strings do not match exactly
> !endif
> ```
>
> -### 2.2.9 !error Statement
> +### 2.2.8 !error Statement
>
> The `!error` statement may appear within any section of EDK II DSC file. The
> argument of this statement is an error message, it causes build tool to stop
> at the location where the statement is encountered and error message
> following
> the `!error` statement is output as a message. The keyword `!error` is not
> @@ -658,11 +639,11 @@ The following example show the valid usage of the
> `!error` statement.
> !if $(FEATURE_ENABLE) == TRUE
> !error "unsupported feature!"
> !endif
> ```
>
> -### 2.2.10 Expressions
> +### 2.2.9 Expressions
>
> Expressions can be used in conditional directive comparison statements and
> in
> value fields for Macros and PCDs in the DSC and FDF files.
>
> Refer to the EDK II Expression Syntax Specification for additional
> information.
> @@ -723,11 +704,11 @@ names specified on the command line or come
> from the `Conf/target.txt` file.
>
> For logical expressions, any non-zero value must be considered `TRUE`.
>
> Invalid expressions must cause a build break with an appropriate error
> message.
>
> -### 2.2.11 Section Handling
> +### 2.2.10 Section Handling
>
> The DSC file parsing routines must process the sections so that common
> architecture sections are logically merged with the architecturally specific
> sections. The architectural sections need to be processed so that they are
> logically after the common section. It is recommended that EDK II
> developers
> @@ -750,24 +731,13 @@ on the "==" replace or "=" append assignment
> character sequence.
>
> ```ini
> [BuildOptions.Common]
> MSFT:*_*_*_CC_FLAGS = /nologo
>
> -[BuildOptions.Common.EDK]
> - MSFT:*_*_*_CC_FLAGS = /Od
> -
> [BuildOptions.IA32]
> MSFT:*_*_IA32_CC_FLAGS = /D EFI32
> ```
>
> For IA32 architecture builds of an EDK II INF file would logically be:
>
> `MSFT:*_*_IA32_CC_FLAGS = /nologo /D EFI32`
>
> -For non-IA32 architecture EDK INF files, tool parsing would logically be:
> -
> -`MSFT:*_*_*_CC_FLAGS = /nologo /Od`
> -
> -For IA32 architecture builds of an EDK INF file, tool parsing would logically
> -be:
> -
> -`MSFT:*_*_IA32_CC_FLAGS = /nologo /D EFI32 /Od`
> diff --git a/2_dsc_overview/23_[defines]_section_processing.md
> b/2_dsc_overview/23_[defines]_section_processing.md
> index 428196b..ad0702b 100644
> --- a/2_dsc_overview/23_[defines]_section_processing.md
> +++ b/2_dsc_overview/23_[defines]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.3 [Defines] Section Processing
>
> - 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:
>
> @@ -80,14 +80,10 @@ define the MACRO name during the processing of this
> file, files included by the
> **Warning:** The DEFINE MACRO = Value statements in other sections are
> local to
> the section, and override the global definition for entries in the section that
> follow the macro definition: `DEFINE MACRO = Value.`
> **********
>
> -The `EDK_GLOBAL MACRO = Value` definitions in this section globally define
> the
> -MACRO name when parsing the DSC, files included by the !include
> statement, FDF
> -and EDK INF files.
> -
> The EDK II tools will locate the FDF file specified in the `FLASH_DEFINITION`
> entry in the same directory as the DSC file. When the
> PCD_VAR_CHECK_GENERATION
> entry is present and set to TRUE, tools will generate a binary file for
> DynamicHii and DynamicExHii PCD variable checking.
>
> @@ -112,11 +108,10 @@ item is required.
> | `BUILD_NUMBER` | Optional | Up to four digit numbers | Set
> this value in the generated Makefile.
> |
> | `FIX_LOAD_TOP_MEMORY_ADDRESS` | Optional | Address |
> The top memory address - the starting location in memory for all drivers,
> application loading. When it is not set, or set to 0, the load fixed address
> feature will be disabled. When it is set to 0xFFFFFFFFFFFFFFFF, enable the
> feature as fixed offset to TOLM. When it is set to the positive address,
> enable the feature as fixed address. |
> | `TIME_STAMP_FILE` | Optional | Filename | The
> timestamp file contains a timestamp that will be used to set the creation
> timestamp on all created files. If this file is specified, it will be used to adjust
> the timestamp of created files, if it does not exist at the start of a build, the
> file will be created, using the current date and time.
> |
> | | | | If this variable is not specified,
> the time and date of the start of the build are used by the EDK II tools that
> modify the time/date portion of a PE32/PE32+/Coff header. This file's path is
> either relative to the directory containing the DSC file or a `WORKSPACE`[^1]
> relative path followed by the file name.
> |
> | `DEFINE` | Optional | MACRO = PATH or Value | A name
> that is assigned to either a path or a value. This statement can be used to
> make the DSC file more readable, as in: `DEFINE MDE = MdePkg/Library`
> Then, later, `$(MDE)/BaseLib/ BaseLib.inf`
> |
> -| `EDK_GLOBAL` | Optional | MACRO = PATH or Value |
> Similar to the DEFINE statement, macros defined using this keyword are only
> valid when processing EDK ibraries and components. These values are
> ignored during processing of EDK II modules.
> |
> | `RFC_LANGUAGES` | Optional | RFC4646 Language code list | A
> semi-colon ";" separated list of RFC4646 Language codes (EDK II Modules)
> used during the generation of only a set, rather than all, UNICODE languages
> during the StrGather AutoGen phase. The list must be encapsulated in
> double quotes.
> |
> | `ISO_LANGUAGES` | Optional | ISO-639-2 Language code list | A
> non-separated list of three character ISO 639-2 Language codes (EDK
> Components) used during the generation of only a set, rather than all,
> UNICODE languages during the StrGather AutoGen phase. The list must be
> encapsulated in double quotes.
> |
> | `VPD_TOOL_GUID` | Optional | Registry Format GUID |
> When this element is present, the build process will be interrupted during
> the AutoGen stage in order to call an external program, named by GUID that
> must also be defined in the Conf/tools_def.txt file using a tool code name of
> VPDTOOL. Refer to the EDK II Build specification for additional information.
> |
> | `PCD_INFO_GENERATION` | Optional | TRUE or FALSE | If
> present, and set to TRUE, this flag will generate PCD information in the Pcd
> Database.
> |
> | `PCD_VAR_CHECK_GENERATION` | Optional | TRUE or FALSE |
> If present and set to TRUE, this flag will generate the variable validation table
> binary file in the build output FV floder. If not present ro set to FALSE, then
> the binary file will not be generated.
> |
> @@ -128,9 +123,8 @@ WORKSPACE system environment variable and the
> PACKAGES_PATH system environment
> variable.
>
> **********
> **Note:** EDK II Modules can have unicode string files that contain RFC4646
> language codes. EDK II modules cannot have unicode string files that contain
> -ISO-629-2 language codes. USI-629-2 language codes are only valid for EDK
> -components. The format of the statement is specific to processing RFC4646
> -language code lists.
> +ISO-629-2 language codes. The format of the statement is specific to
> processing
> +RFC4646 language code lists.
> **********
> diff --git a/2_dsc_overview/24_[buildoptions]_section.md
> b/2_dsc_overview/24_[buildoptions]_section.md
> index 7d3d2d1..375866c 100644
> --- a/2_dsc_overview/24_[buildoptions]_section.md
> +++ b/2_dsc_overview/24_[buildoptions]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.4 [BuildOptions] Section
>
> - 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:
>
> @@ -33,11 +33,11 @@
>
> Content in the `[BuildOptions]` section is used to define module specific tool
> chain flags rather than use the default flags for a module. These flags are
> appended to any standard flags that are defined by the build process. They
> can
> be applied for any modules or those modules on the specific ARCH or those
> -modules with the specific module style (EDK or EDKII). In order to replace
> the
> +modules with the specific EDKII module style. In order to replace the
> standard flags that are defined by the build process, an alternate assignment
> operator is used; "==" is used for replacement, while "=" is used to append
> the flag lines. In addition to flags, other tool attributes may have the item
> either appended or replaced.
>
> @@ -94,93 +94,35 @@ that the lines show use of the "\" line continuation
> character.
> ```
>
> The following examples show how `[BuildOptions]` sections can be merged,
> as
> well as how the content in those sections can be merged.
>
> -For specific flag values, common to both EDK and EDKII options, it is
> -appropriate to use a `DEFINE` statement in the `[Defines]` section; for
> +It is appropriate to use a `DEFINE` statement in the `[Defines]` section; for
> example 1:
>
> `DEFINE MSFT_COMMON_DEBUG_FLAGS = /Od`
>
> Then the macro, $(MSFT_COMMON_DEBUG_FLAGS) can be used in
> statements in any of
> the `[BuildOptions.*]` sections, as in:
>
> ```ini
> -[BuildOptions.Common.EDK]
> +[BuildOptions.X64]
> MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c
> $(MSFT_COMMON_DEBUG_FLAGS)
>
> -[BuildOptions.Common.EDKII]
> +[BuildOptions.IA32]
> MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c
> $(MSFT_COMMON_DEBUG_FLAGS)
> ```
>
> It is also permissible to have a `[BuildOptions.<arch>]` section that can be
> shared be used for different statements that are not duplicate content from
> -either the `[BuildOptions.<arch>.EDK]` or `[BuildOptions.<arch>.EDKII]`
> -sections. For example 2:
> +the `[BuildOptions.<arch>.EDKII]` sections. For example:
>
> ```ini
> [BuildOptions.Common]
> MSFT:*_*_*_ASL_OUTFLAGS = /Fo=
>
> -[BuildOptions.Common.EDK]
> - MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c /D UNICODE
> -
> -[BuildOptions.IA32.EDK]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy
> -
> [BuildOptions.Common.EDKII]
> MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c /D UNICODE
>
> [BuildOptions.IA32.EDKII]
> MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy
> -```
> -
> -It is also permissible to have a `[BuildOptions.<arch>]` section that can be
> -shared be used prior to appending statement content from either the
> -`[BuildOptions.<arch>.EDK]` or `[BuildOptions.<arch>.EDKII]` sections as in
> the
> -following example:
> -
> -```ini
> -[BuildOptions.IA32]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /nologo /W4 /WX /Gy /c /D UNICODE
> -
> -[BuildOptions.IA32.EDKII]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /FI$(DEST_DIR_DEBUG)/AutoGen.h
> -
> -[BuildOptions.IA32.EDK]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /D EFI32
> -```
> -
> -When processing EDK II C files, the `CC_FLAGS` would be:
> -
> -`/nologo /W4 /WX /Gy /c /D UNICODE /FI$(DEST_DIR_DEBUG)/AutoGen.h`
> -
> -While processing of EDK C files, the CC_FLAGS would be:
> -
> -`/nologo /W4 /WX /Gy /c /D UNICODE /D EFI32`
> -
> -It is also permissible to combine [BuildOptions.common] with
> -`[BuildOptions.<arch>]` sections that are not "common", as in the following
> -example:
> -
> -```ini
> -[BuildOptions.Common]
> - MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c
> -
> -[BuildOptions.IA32]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy /D UNICODE
> -
> -[BuildOptions.IA32.EDKII]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /FI$(DEST_DIR_DEBUG)/AutoGen.h
> -
> -[BuildOptions.IA32.EDK]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /D EFI32
> -```
> -
> -In the previous example, the `CC_FLAGS` for IA32 EDK II modules would
> equal:
> -
> -`/nologo /x /W4 /WX /Gy /D UNICODE /FI$(DEST_DIR_DEBUG)/AutoGen.h`
> -
> -The CC_FLAGS for IA EDK modules would equal:
> -
> -`/nologo /c /W4 /WX /Gy /D UNICODE /D EFI32`
> +```
> \ No newline at end of file
> diff --git a/2_dsc_overview/26_[libraries]_section_processing.md
> b/2_dsc_overview/26_[libraries]_section_processing.md
> deleted file mode 100644
> index 82cda47..0000000
> --- a/2_dsc_overview/26_[libraries]_section_processing.md
> +++ /dev/null
> @@ -1,69 +0,0 @@
> -<!--- @file
> - 2.6 [Libraries] Section Processing
> -
> - 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.6 [Libraries] Section Processing
> -
> -This section specifies all the EDK INF files that must be processed to build
> -the libraries used to build the individual EDK components. This will include
> -all the libraries called out in the individual component INF files. A sample
> -section is listed below. Each line from the libraries section specifies a
> -library component's INF file (relative to `$(EDK_SOURCE)`, or absolute path).
> -
> -This section is required for any EDK II DSC file that specifies one or more EDK
> -components. If only EDK II Modules are used, this section must not be
> -specified. If the section is specified, and only EDK II Modules are found, the
> -build and parsing tools will ignore this section. A warning message will be
> -emitted by the parsing tool if and only the parsing tool is executed in a
> -verbose mode.
> -
> -The `!include` statements may be used within the `[Libraries]` section.
> -
> -The file specified after the `!include` statement can only contain a list of
> -EDK Library INF files (with the path to the file). If the line starts with a
> -word, rather than a variable like `$(EDK_SOURCE)` the path is assumed to be
> -relative to `$(EDK_SOURCE)`. Again, only EDK Library INF files are permitted
> in
> -the file specified in the `!include` statement.
> -
> -This section will typically use one of the following section definitions:
> -
> -```ini
> -[Libraries.common]
> -[Libraries.IA32]
> -[Libraries.X64]
> -[Libraries.EBC]
> -```
> -
> -The formats for entries in this section is:
> -
> -```
> -$(EDK_SOURCE)/Path/to/LibraryName.inf
> -$(CUSTOM_DECOMPRESS_LIB_INF)
> -```
> diff --git a/2_dsc_overview/27_[libraryclasses]_section_processing.md
> b/2_dsc_overview/26_[libraryclasses]_section_processing.md
> similarity index 96%
> rename from 2_dsc_overview/27_[libraryclasses]_section_processing.md
> rename to 2_dsc_overview/26_[libraryclasses]_section_processing.md
> index 50bda93..0f87ceb 100644
> --- a/2_dsc_overview/27_[libraryclasses]_section_processing.md
> +++ b/2_dsc_overview/26_[libraryclasses]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.7 [LibraryClasses] Section Processing
>
> - 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.7 [LibraryClasses] Section Processing
> +## 2.6 [LibraryClasses] Section Processing
>
> The `[LibraryClasses]` section is used to provide a mapping between the
> library
> class names used by an EDK II module and the Library Instances that are
> selected by the platform integrator. Library Classes allow modules to be
> coded
> for a library class, and then allow platform integrator then chooses a Library
> diff --git a/2_dsc_overview/28_pcd_section_processing.md
> b/2_dsc_overview/27_pcd_section_processing.md
> similarity index 94%
> rename from 2_dsc_overview/28_pcd_section_processing.md
> rename to 2_dsc_overview/27_pcd_section_processing.md
> index a5d56b3..d2a409f 100644
> --- a/2_dsc_overview/28_pcd_section_processing.md
> +++ b/2_dsc_overview/27_pcd_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.8 PCD Section Processing
>
> - 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:
>
> @@ -27,22 +27,22 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.8 PCD Section Processing
> +## 2.7 PCD Section Processing
>
> This section is for specifying global (or default) PCD values as well as the
> access method each PCD will use for modules in the platform.
>
> -### 2.8.1 PCD Access Methods
> +### 2.7.1 PCD Access Methods
>
> There are five defined PCD access methods. The five access methods are:
> `FeatureFlag`, `FixedAtBuild`, `PatchableInModule`, `Dynamic` and
> `DynamicEx`
> PCDs.
>
> -#### 2.8.1.1 FeatureFlag and Dynamic PCD Types
> +#### 2.7.1.1 FeatureFlag and Dynamic PCD Types
>
> The two recommended access methods that are commonly used in modules
> are
> `FeatureFlag` and the generic `Dynamic method`. The `Dynamic` form is used
> for
> configuration when the PCD value is produced and consumed by drivers
> during
> execution, the value may be user configurable from setup or the value is
> @@ -50,11 +50,11 @@ produced by the platform in a specified area. It is
> associated with modules
> that are released in source code. The dynamic form is the most flexible
> method,
> as platform integrators may chose a to use a different access method for a
> given platform without modifying the module's INF file or the code for the
> module.
>
> -#### 2.8.1.2 DynamicEx, FixedAtBuild and PatchableInModule PCD Access
> Methods
> +#### 2.7.1.2 DynamicEx, FixedAtBuild and PatchableInModule PCD Access
> Methods
>
> Similar in function, the `DynamicEx` access method can be used with
> modules
> that are released as binary. The `FixedAtBuild` and `PatchableInModule`
> PCDs
> are static and only the `PatchableInModule` PCD can have the value changed
> in a
> binary prior to including the module in a firmware image.
> @@ -82,11 +82,11 @@ The content in these sections is used for generating
> the `AutoGen.c` and
> [Pcds(PcdType).IA32]
> [Pcds(PcdType).X64]
> [Pcds(PcdType).EBC]
> ```
>
> -### 2.8.2 PCD Access Method Categories
> +### 2.7.2 PCD Access Method Categories
>
> Of the five access methods of PCDs that have been defined, they fall into
> one
> of three categories:
>
> * `FeatureFlag` - always has a Boolean value.
> @@ -129,42 +129,42 @@ different datum type based on the architecture.
> For example, a PCD that is used
> for address manipulation may have a datum type of `UINT32` for IA32 and
> `UINT64` for X64 and EBC architectures. This will be declared in the EDK II
> Package Declaration (DEC) File.
> **********
>
> -### 2.8.3 PCD Section Usage
> +### 2.7.3 PCD Section Usage
>
> PCD sections are optional unless the EDK II modules specified in the
> `[Components]` section use PCDs.
>
> The PCD sections are used to define the access method for a PCD. Since each
> module is built once for a given architecture, the PCD can be listed under
> different PCD access methods provided they are listed under different
> architectures.
>
> -#### 2.8.3.1 Access Methods
> +#### 2.7.3.1 Access Methods
>
> However, once a PCD access method is selected for a given architecture, the
> PCD
> can only use that access method.
>
> #### Example
>
> A PCD that will use the `FixedAtBuild` access method for IA32 cannot use the
> `PatchableInModule` access method for individual modules built for the IA32
> architecture.
>
> -#### 2.8.3.2 Different Access Methods
> +#### 2.7.3.2 Different Access Methods
>
> It is permissible to have a PCD use different access methods for different
> architectures.
>
> #### Example
>
> A PCD that will use the FixedAtBuild access method for IA32 can use the
> Patchable in Module access method for X64.
>
> -#### 2.8.3.3 Item Access Methods
> +#### 2.7.3.3 Item Access Methods
>
> Multiple item access methods, `PcdsFeatureFlag`, `PcdsFixedAtBuild`,
> `PcdsPatchableInModule`, `PcdsDynamic` and `PcdsDynamicEx` are not
> allowed to
> be specified within a single [] section tag.
>
> @@ -187,11 +187,11 @@ be specified within a single [] section tag.
> [PcdsDynamicDefault.IA32]
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> ```
>
> -#### 2.8.3.4 Mixing PCD Dynamic item storage methods
> +#### 2.7.3.4 Mixing PCD Dynamic item storage methods
>
> It is not permissible to mix different PCD Dynamic item storage methods
> within
> a single section, as the format for the PCD entries in PcdsDynamicDefault,
> PcdsDynamicVpd, PcdsDynamicHii, and PcdsDynamicExDefault,
> PcdsDynamicExVpd and
> PcdsDynamicExHii sections are different.
> @@ -212,11 +212,11 @@ PcdsDynamicExHii sections are different.
>
> [PcdsDynamicExVpd.IA32]
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|*|0
> ```
>
> -#### 2.8.3.5 Multiple Architectural Section Tags
> +#### 2.7.3.5 Multiple Architectural Section Tags
>
> It is permissible to specify multiple architectural section tags for the same
> PCD item type in a single section.
>
> #### Example
> @@ -232,11 +232,11 @@ PCD item type in a single section.
> [PcdsDynamicDefault.IA32, PcdsDynamicDefault.X64]
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> ```
>
> -#### 2.8.3.6 Dynamic and DynamicEx PCD Storage Methods
> +#### 2.7.3.6 Dynamic and DynamicEx PCD Storage Methods
>
> The PCDs that use Dynamic and DynamicEx access methods can have their
> values
> stored in one of three different methods, Default, VPD or HII. A PCD using
> one
> of these access methods can use one storage method. It is not permissible
> to
> have a PCD try to store the data in the Default database and a VPD region at
> @@ -273,11 +273,11 @@
> TokenSpaceGuid.PcdCname|<HiiString>|<VariableGuid>|<VariableOffset>|
> <Value>|<Att
> **********
> **Note:** Some of the above fields are optional; refer to "PCD Sections" in
> the
> next chapter for the exact syntax.
> **********
>
> -#### 2.8.3.7 Unique PCDs
> +#### 2.7.3.7 Unique PCDs
>
> Unique PCDs are identified using the format to identify the named PCD:
>
> `TokenSpaceGuidCName.PcdCName`
>
> @@ -304,11 +304,11 @@ be used - `PcdsFixedAtBuild` for modules with
> wellknown values for a PCD,
> then either `PcdsPatchableInModule` or `PcdsDynamicEx` - the first
> being for testing a module, the second giving the ability for doing individual
> driver performance tuning "on-the-fly".
> **********
>
> -#### 2.8.3.8 Precedence
> +#### 2.7.3.8 Precedence
>
> Tools must assume that the first method found for a PCD in the PCDs
> sections
> will used for all instances of a PCD. Tools must not allow for different
> modules using a PCD differently, using the `<Pcds*>` statements under the
> INF
> file definitions in the `[Components]` section.
> @@ -375,11 +375,11 @@ listed more than one time within a section. List a
> PCD in one of the other
> access methods is allowed, provided a single access method must be used
> for all
> instances of the PCD. If PCD field value is listed, it will override PCD value
> even if PCD value is after PCD field value.
> **********
>
> -#### 2.8.3.9 Library Instances
> +#### 2.7.3.9 Library Instances
>
> Library Instances that use PCDs that the module is linked with must use the
> same PCD setting as the module using the Library Instance. So if a module
> uses
> a PCD as `PcdsFixedAtBuild`, then all library instances that use that PCD must
> also use the PCD as `PcdsFixedAtBuild` with the same value.
> @@ -393,11 +393,11 @@ The expression is a C-style expression using C
> relational, equality and logical
> numeric and bitwise operators or numeric and bitwise operators that
> evaluate to
> a value that matches the PCD's Datum Type (specified in the DEC package
> declaration file.) Precedence and associativity follow C standards. Using PCDs
> in expressions is also permitted.
>
> -#### 2.8.3.10 Maximum Size of a VOID* PCD
> +#### 2.7.3.10 Maximum Size of a VOID* PCD
>
> If the maximum size of a VOID* PCD is not specified in the DSC file, then the
> maximum size will be calculated based on the largest size of the following:
>
> * the string or array in the --pcd option
> diff --git a/2_dsc_overview/29_pcd_sections.md
> b/2_dsc_overview/28_pcd_sections.md
> similarity index 93%
> rename from 2_dsc_overview/29_pcd_sections.md
> rename to 2_dsc_overview/28_pcd_sections.md
> index d84d2f4..0b0b6d3 100644
> --- a/2_dsc_overview/29_pcd_sections.md
> +++ b/2_dsc_overview/28_pcd_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.9 PCD 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:
>
> @@ -27,13 +27,13 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.9 PCD Sections
> +## 2.8 PCD Sections
>
> -### 2.9.1 [PcdsFeatureFlag] section
> +### 2.8.1 [PcdsFeatureFlag] section
>
> The required content for the FeatureFlag PCD is the PCD Token Space Guid C
> name, the PCD's C name (these two entries are separated by the period
> character), and a Boolean value of either TRUE, FALSE, 1 or 0. The PCD name
> and value entries are separated by the pipe "|" character.
> @@ -69,19 +69,19 @@ Format of an entry in this section is:
> ```ini
> [PcdsFeatureFlag.common]
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxePcdDatabaseTraverseEnabled|1
> ```
>
> -### 2.9.2 [PcdsFixedAtBuild] and [PcdsPatchableInModule] sections
> +### 2.8.2 [PcdsFixedAtBuild] and [PcdsPatchableInModule] sections
>
> The section modifier, `SkuIdentifier`, can be used by the build tools to create
> images for one specific SKU. Unlike the `PcdsDynamic` and `PcdsDynamicEx`
> entries, no access methods are allowed for having different values during
> runtime for different SKUs. Do not use the `SkuIdentifier` when building all
> SKUs.
>
> -#### 2.9.2.1 PcdsFixedAtBuild
> +#### 2.8.2.1 PcdsFixedAtBuild
>
> The `FixedAtBuild` PCD access method cannot be used in a Binary Module.
>
> The required content for the `FixedAtBuild` PCD are the PCD Token Space
> Guid
> C name, the PCD's C name (these two entries are separated by the period
> @@ -125,11 +125,11 @@ Format for Boolean and numeric entries in this
> section is:
> gEfiMdePkgTokenSpaceGuid.PcdFSBClock|200000000
> gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
>
> gEfiEdkNt32PkgTokenSpaceGuid.PcdWinNtPhysicalDisk|L"E:RW;245760;512"
> |VOID*|32
> ```
>
> -#### 2.9.2.2 PcdsPatchableInModule
> +#### 2.8.2.2 PcdsPatchableInModule
>
> The `PatchableInModule` PCD access method can be used with modules that
> are
> distributed in binary form. The PCD's value can be patched by tools that
> know
> the offset of the PCD into the binary file.
>
> @@ -163,11 +163,11 @@ Format of an entry in this section is:
> ```ini
> [PcdsPatchableInModule.common]
>
> gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000000|UINT32|
> 4
> ```
>
> -### 2.9.3 [PcdsDynamic*] and [PcdsDynamicEx*] sections
> +### 2.8.3 [PcdsDynamic*] and [PcdsDynamicEx*] sections
>
> PCDs listed in these sections cannot be used in conditional directive
> statements.
>
> The Dynamic PCD access method cannot be used for modules that are
> distributed
> @@ -185,11 +185,11 @@ binary image supports multiple SKUs. The SKU
> selection based on things like a
> hardware jumper, or some other method that is outside the scope of this
> document.
>
> For using the standard PCD Get/Set PPI or Protocol.
>
> -#### 2.9.3.1 PcdsDynamicDefault
> +#### 2.8.3.1 PcdsDynamicDefault
>
> The Dynamic Default PCD access method will generate a volatile variable that
> can be accessed at runtime using PCD a Get PPI or Protocol.
>
> ```ini
> @@ -213,11 +213,11 @@ The format for a VOID* PCD entry in this section is:
> [PcdsDynamicDefault]
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0
> ```
>
> -#### 2.9.3.2 PcdsDynamicHII
> +#### 2.8.3.2 PcdsDynamicHII
>
> The Dynamic Hii PCD access method will generate HII data content that can
> be
> accessed at runtime.
>
> For using the HII for PCD data, the section name is as follows:
> @@ -259,11 +259,11 @@ described in the following table.
>
> [PcdsDynamicHii.common.DEFAULT]
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdValidRange|L"PcdValidRange"|gEfi
> GlobalVariableGuid|0x07|0|BS,RT,NV
> ```
>
> -#### 2.9.3.3 PcdsDynamicVpd
> +#### 2.8.3.3 PcdsDynamicVpd
>
> The Dynamic Vpd PCD access method will generate macros that allow the
> data
> content (stored in read-only memory) to be accessed at runtime. Note that
> the
> PCD drivers may use a copy of the VPD data to allow runtime changes to
> these
> variables.
> @@ -296,11 +296,11 @@ The format for VOID* datum type content in this
> section is:
> gNoSuchTokenSpaceGuid.PcdOemBootOptionName | 0x22D4 | 100 | " " #
> VOID*
> gNoSuchTokenSpaceGuid.PcdOemBootOptionPath | 0x2338 | 100 | " " #
> VOID*
> gNoSuchTokenSpaceGuid.PcdEnableFastBoot | 0x239C | 1 | FALSE #
> BOOLEAN
> ```
>
> -#### 2.9.3.4 PcdsDynamicExDefault
> +#### 2.8.3.4 PcdsDynamicExDefault
>
> The DynamicEx access method of PCD is recommended for modules that are
> distributed in binary form.
>
> Entries for `DynamicEx` are identical to the `Dynamic` entries. The
> `DynamicEx`
> @@ -327,11 +327,11 @@ The format for a VOID* PCD entry in this section is:
> [PcdsDynamicExDefault.common.DEFAULT]
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0
> ```
>
> -#### 2.9.3.5 PcdsDynamicEx Hii
> +#### 2.8.3.5 PcdsDynamicEx Hii
>
> For using the HII for PCD data, the section name is as follows:
>
> `[PcdsDynamicExHii.$(arch).$(SKUID_IDENTIFIER)]`
>
> @@ -357,11 +357,11 @@ described in Table 9 HII Attributes.
>
> [PcdsDynamicExHii.common.DEFAULT]
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdValidRange|L"PcdValidRange"|gEfi
> GlobalVariableGuid|0x07|0|BS,RT,NV
> ```
>
> -#### 2.9.3.6 PcdsDynamicExVpd
> +#### 2.8.3.6 PcdsDynamicExVpd
>
> For using the VPD for PCD data, the section name is:
>
> `[PcdsDynamicExVpd.$(arch).$(SKUID_IDENTIFIER)]`
>
> diff --git a/2_dsc_overview/210_pcd_database.md
> b/2_dsc_overview/29_pcd_database.md
> similarity index 96%
> rename from 2_dsc_overview/210_pcd_database.md
> rename to 2_dsc_overview/29_pcd_database.md
> index 2e4380c..ab3fda5 100644
> --- a/2_dsc_overview/210_pcd_database.md
> +++ b/2_dsc_overview/29_pcd_database.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.10 PCD Database
>
> - 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.10 PCD Database
> +## 2.9 PCD Database
>
> Dynamic and DynamicEx PCDs can be modified during the boot/setup stages.
> In
> order to support modifications, a PEIM and a DXE driver use databases of
> these
> PCDs so that changes can persist across reboots. These databases are
> generated
> prior to the final image assembly. The following rules determine when the
> build
> diff --git a/3_edk_ii_dsc_file_format/311_[components]_sections.md
> b/3_edk_ii_dsc_file_format/310_[components]_sections.md
> similarity index 81%
> rename from 3_edk_ii_dsc_file_format/311_[components]_sections.md
> rename to 3_edk_ii_dsc_file_format/310_[components]_sections.md
> index b8e2875..abca3e9 100644
> --- a/3_edk_ii_dsc_file_format/311_[components]_sections.md
> +++ b/3_edk_ii_dsc_file_format/310_[components]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.11 [Components] 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.11 [Components] Sections
> +## 3.10 [Components] Sections
>
> The `[Components]` sections are required.
>
> #### Summary
>
> @@ -42,12 +42,11 @@ files.
> The `!include` statement is permitted in `[Components]` sections. however
> this
> method is NOT recommended.
>
> All EDK II file paths must be specified relative to a directory containing EDK
> II Packages (as specified by the WORKSPACE or a directory listed in
> -PACKAGES_PATH system environment variable). EDK INF component and
> library files
> -may use `$(EDK_SOURCE)` or `$(EFI_SOURCE)` global environment variables.
> If the
> +PACKAGES_PATH system environment variable). If the
> environment variable is not specified, the INF file path is assumed to be
> relative to the `WORKSPACE`.
>
> The following is an example of specifying a `WORKSPACE` (MdeModulePkg is
> in the
> directory pointed to by the WORKSPACE environment variable) relative
> Path:
> @@ -55,11 +54,11 @@ directory pointed to by the WORKSPACE environment
> variable) relative Path:
> `MdeModulePkg/Universal/Disk/DiskIo/Dxe`
>
> The following is an example of specifying an Indirect Path:
>
> ```ini
> -DEFINE FOUNDATION_LIB = $(EDK_SOURCE)/Foundation/Library
> +DEFINE FOUNDATION_LIB = $(WORKSPACE)/Foundation/Library
> $(FOUNDATION_LIB)/EdkIIGlueLib/EntryPoints
> ```
>
> The permitted `DEFINE` statement must be a variable name assigned to a
> path.
>
> @@ -91,13 +90,10 @@ value, while the `<PcdsFixedAtBuild>` section of an
> INF use a different value.
> The FeatureFlag PCD and the two dynamic forms of PCDs are common to a
> platform,
> with the dynamic form PCD values stored in a "runtime database", read-only
> memory location or an HII data store. Therefore, having different values is
> prohibited for these access methods.
>
> -EDK components may have the scoped sub-element,
> `<SOURCE_OVERRIDE_PATH>` that
> -is used to virtually replace files in the component's directory.
> -
> The format for items listed in the sub-elements is the identical format for
> content under the section.
>
> Within the context of an EDK II module sub-element, the `<LibraryClasses>`
> entries must appear before `<Pcds*>` entries; the `<LibraryClasses>` entries
> @@ -128,20 +124,16 @@ modules in a binary image (the FDF file describes
> that ordering).
> <attribs> ::= <attrs> ["," <TS> "Components" <attrs>]*
> <attrs> ::= "." <arch>
> <ModuleStatements> ::= {<MacroDefinition>}
> {<IncludeStatement>} {<TS> <InfFiles>}
> <InfFiles> ::= <InfFilename> [<MTS> <Options>] <EOL>
> -<Options> ::= {<Exec>} {<Edk2Struct>} {<EdkStruct>}
> +<Options> ::= {<Exec>} {<Edk2Struct>}
> <InfFilename> ::= <PATH> <Word> ".inf"
> <Exec> ::= "EXEC" <Eq> <ExecFilename>
> <ExecFilename> ::= <PATH> <Word> ["." <ExecExtension>]
> <ExecExtension> ::= <Word> # An OS recognisable extension that will #
> automatically be run.
> -<EdkStruct> ::= "{" <EOL>
> - <TS> "<SOURCE_OVERRIDE_PATH>" <EOL>
> - <TS> <PATH>
> - <TS> "}" <EOL>
> <Edk2Struct> ::= "{" <EOL>
> [<TS> <DefSec>]
> [<TS> <LibraryClasses>]
> [<TS> <PcdsFeatureFlag>]
> [<TS> <PcdsFixed>]
> @@ -267,49 +259,5 @@ individual modules.
>
> **_ClassName_**
>
> A Library Class Keyword defined in DEC files. The Keyword must also be
> present
> in the defines section `LIBRARY_CLASS` entry of the INF file
> -
> -#### Example Using EDK components in an EDK II DSC build
> -
> -```
> -[Components]
> -DEFINE EDK=$(EDK_SOURCE)/Edk
> -DEFINE MDE=MdePkg/Library
> -DEFINE STATUS_CODE=$(MDE)/PeiDxeDebugLibReportStatusCode
> -
> -$(EDK)/Foundation/Core/Pei/PeiMain.inf
> -DEFINE NT32 = $(EDK)/Sample/Platform
> -$(NT32)/Generic/MonoStatusCode/Pei/Nt32/MonoStatusCode.inf
> -$(NT32)/Nt32/Pei/BootMode/BootMode.inf
> -$(NT32)/Nt32/Pei/FlashMap/FlashMap.inf
> -MdeModulePkg/Core/Dxe/DxeMain.inf
> -...
> -MdeModulePkg/Universal/Debugger/Debugport/Dxe/DebugPort.inf
> -MdeModulePkg/Cpu/DebugSupport/Dxe/DebugSupport.inf
> -...
> -
> -DEFINE MDEMODUNI = MdeModulePkg/Universal
> -$(MDEMODUNI)/DataHub/DataHubStdErr/Dxe/DataHubStdErr.inf
> -MdeModulePkg/Universal/Disk/DiskIo/Dxe/DiskIo.inf {
> - <LibraryClasses>
> - DebugLib|$(STATUS_CODE)/PeiDxeDebugLibReportStatusCode.inf
> - BaseMemoryLib|$(MDE)/DxeMemoryLib/DxeMemoryLib.inf
> -
> MemoryAllocationLib|$(MDE)/DxeMemoryAllocationLib/DxeMemoryAllocati
> onLib.inf
> - <PcdsFeatureFlag>
> - PcdDriverDiagnosticsDisable|gEfiMdePkgTokenSpaceGuid|FALSE
> -}
> -MdeModulePkg/Universal/Ebc/Dxe/Ebc.inf
> -$(MDEMODUNI)/GenericMemoryTest/Dxe/NullMemoryTest.inf
> -$(MDEMODUNI)/StatusCode/Pei/PeiStatusCode.inf {
> - <BuildOptions>
> - MSFT:RELEASE_MYTOOLS_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib
> Gdi32.lib User32.lib Winmm.lib
> - DEBUG_MYTOOLS_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib
> Gdi32.lib User32.lib Winmm.lib
> - DEBUG_WINDDK3790x1830_IA32_DLINK_FLAGS = Kernel32.lib
> MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
> - RELEASE_WINDDK3790x1830_IA32_DLINK_FLAGS = Kernel32.lib
> MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
> - DEBUG_VS2003_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib
> User32.lib Winmm.lib
> - RELEASE_VS2003_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib
> Gdi32.lib User32.lib Winmm.lib
> -}
> -MdeModulePkg/Logo/Logo.inf
> -...
> -```
> diff --git a/3_edk_ii_dsc_file_format/312_[userextensions]_sections.md
> b/3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
> similarity index 94%
> rename from 3_edk_ii_dsc_file_format/312_[userextensions]_sections.md
> rename to 3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
> index 6020c5c..504fa9f 100644
> --- a/3_edk_ii_dsc_file_format/312_[userextensions]_sections.md
> +++ b/3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.12 [UserExtensions] 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.12 [UserExtensions] Sections
> +## 3.11 [UserExtensions] Sections
>
> The `[UserExtensions]` sections are optional.
>
> #### Summary
>
> diff --git a/3_edk_ii_dsc_file_format/313_[defaultstores]_section.md
> b/3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
> similarity index 93%
> rename from 3_edk_ii_dsc_file_format/313_[defaultstores]_section.md
> rename to 3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
> index 23dec7d..dfa7fa8 100644
> --- a/3_edk_ii_dsc_file_format/313_[defaultstores]_section.md
> +++ b/3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.13 [DefaultStores] Section
>
> - 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.13 [DefaultStores] Section
> +## 3.12 [DefaultStores] Section
>
> The `[DefaultStores]` section is optional in all EDK II DSC files.
>
> #### Summary
>
> diff --git a/3_edk_ii_dsc_file_format/32_general_rules.md
> b/3_edk_ii_dsc_file_format/32_general_rules.md
> index e040abc..d0cdb9b 100644
> --- a/3_edk_ii_dsc_file_format/32_general_rules.md
> +++ b/3_edk_ii_dsc_file_format/32_general_rules.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.2 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:
>
> @@ -118,16 +118,5 @@ is unknown.
>
> Unless otherwise noted, all file names and paths are relative EDK II Packages
> (subdirectories in directories pointed to by WORKSPACE or PACKAGES_PATH
> system
> environment variables). A directory name that starts with a word is assumed
> by
> the build tools to be an EDK II Package directory name.
> -
> -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_dsc_file_format/33_platform_dsc_definition.md
> b/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
> index 07f10d6..0679ff0 100644
> --- a/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
> +++ b/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.3 Platform DSC 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:
>
> @@ -45,24 +45,21 @@ PatchableInModule or DynamicEx PCDs.
> specified in the `[Defines]` section or SET statements.
> **********
>
> The `[Defines]` section must appear before any other sections (except the
> header comment blocks). The remaining sections may appear in any order,
> however
> -the EBNF, below, shows the recommended order. (The `[Libraries]` section
> is
> -required if building EDK libraries and components in the context of an EDK II
> -platform.)
> +the EBNF, below, shows the recommended order.
>
> #### Summary
>
> The EDK II Platform Description (DSC) file has the following format (using the
> EBNF).
>
> ```c
> <EDK_II_DSC> ::= [<Header>]
> <Defines>
> [<SkuIds>]
> - <Libraries>*
> <LibraryClasses>*
> <Pcds>*
> <Components>+
> <BuildOptions>*
> <UserExtensions>*
> @@ -377,12 +374,11 @@ Highest Priority
> 3. Macros defined in the DSC file's `[Defines]` section
>
> Lowest Priority
>
> Macros defined in the `[Defines]` section are considered global during the
> -processing of the FDF file and the DSC file. `EDK_GLOBAL` macros are
> considered
> -global during the processing of DSC, FDF and EDK INF files.
> +processing of the FDF file and the DSC file.
>
> Macros are not allowed to redefine the reserved words specified in this file.
> For example, it is not permitted to `DEFINE DEFINE = FOOBAR`, then use
> `FOOBAR`
> as a the reserved word.
>
> @@ -406,13 +402,12 @@ may report the error on the line that uses the
> macro, `$(MACRO)`, rather than
> where the macro was defined.
>
> #### Prototype
>
> ```c
> -<MacroDefinition> ::= {<NormalMacro>} {<EdkMacro>}
> +<MacroDefinition> ::= {<NormalMacro>}
> <NormalMacro> ::= <TS> "DEFINE" <MTS> <MACRO> <Eq> [<Value>]
> <EOL>
> -<EdkMacro> ::= <TS> "EDK_GLOBAL" <MTS> <MACRO> <Eq> [<Value>]
> <EOL>
> <Value> ::= {<Number>} {<BoolType>} {<GUID>}
> {<CString>} {<UnicodeString>} {<CArray>}
> {<PATH>} {<Expression>} {<CFlags>}
> {<RelativePath>} {<Filename>}
> ```
> @@ -449,11 +444,10 @@ defined in this file may be used in the Flash FDF file.
>
> ```
> DEFINE GEN_SKU = MyPlatformPkg/GenPei
> DEFINE SKU1 = MyPlatformPkg/Sku1/Pei
> DEFINE HACK = DEBUG
> -EDK_GLOBAL EFI_ACPI_TABLE_STORAGE_GUID = 7E374E25-8E01-4FEE-
> 87F2390C23C606CD
> ```
>
> ### 3.3.3 Conditional Directive Blocks
>
> Use of conditional directive blocks is optional.
> @@ -697,12 +691,11 @@ in the DSC file. The included file's content must
> match the content of the
> section that the `!include` statement resides, or it may contain completely
> new
> sections. If the included file starts with a section header, then the section
> being processed in the Platform DSC file is considered to have been
> terminated.
>
> If the `<Filename>` contains "$" characters, then macros defined in the DSC
> -file and the system environment variables, `$(WORKSPACE)`,
> `$(EDK_SOURCE)`,
> -`$(EFI_SOURCE)`, and `$(ECP_SOURCE)` are substituted into `<Filename>`.
> +file and the system environment variable `$(WORKSPACE)` are substituted
> into `<Filename>`.
>
> The tools look for `<Filename>` relative to the directory the DSC file resides.
> If the file is not found, and a directory separator is in `<Filename>`, the
> tools attempt to find the file in a WORKSPACE (or a directory listed in the
> PACKAGES_PATH) relative path. If the file cannot be found, the build system
> diff --git a/3_edk_ii_dsc_file_format/35_[defines]_section.md
> b/3_edk_ii_dsc_file_format/35_[defines]_section.md
> index 7337415..ea2077d 100644
> --- a/3_edk_ii_dsc_file_format/35_[defines]_section.md
> +++ b/3_edk_ii_dsc_file_format/35_[defines]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.5 [Defines] Section
>
> - 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:
>
> @@ -179,19 +179,10 @@ specifying the three language codes in this
> statement will limit the final
> output of string parsing tools to strings for these three languages. Tools must
> use a "Get Best Language" function when filtering the content. The
> `RFC_LANGUAGES` statement must be used when processing EDK II
> Modules. Space
> characters are not permitted within the list.
>
> -**_ISO 639-2 Language Code_**
> -
> -One or more three character language codes, formatted per ISO 639-2, with
> no
> -separator character (for example: "engfraspa".) This list can be used to filter
> -the output of tools that generate unicode strings. Tools must use a "Get
> Best
> -Language" function when filtering the content. The `ISO_LANGUAGES`
> statement
> -must be used when processing EDK Components. Space characters are not
> permitted
> -within the list.
> -
> **_BuildNumber_**
>
> This value, if present, will be used during the creation of
> `EFI_SECTION_VERSION` sections. Values in this file override any values set
> in
> the INF files. If not present, the EDK II build tools must use a value of `0`.
> @@ -225,8 +216,7 @@ compiling them into a machine language program.
> OUTPUT_DIRECTORY = Build/Nt32
> SUPPORTED_ARCHITECTURES = IA32
> BUILD_TARGETS = DEBUG|RELEASE
> RFC_LANGUAGES = "en-us;
> zh-hans;fr-fr"
> - ISO_LANGUAGES = "engchnfra"
> SKUID_IDENTIFIER = SkuTwo|DEFAULT
> ```
> diff --git a/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> b/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> index 71d778d..5f0a95c 100644
> --- a/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> +++ b/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.6 [BuildOptions] 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:
>
> @@ -49,16 +49,15 @@ expectation is that other tools will be responsible for
> expanding the macro.
> This section is used to replace flags or append flags to the end of the tool
> code flags defined in the `tools_def.txt` file. The `Family` tag can be used
> for elements that are shared between different architectures, and different
> tool chain tag names.
>
> -The `[BuildOptions]` section modifier, CodeBase, (value of EDK or EDKII,
> -default is EDKII) allows for platform integrators to override default build
> +The `[BuildOptions]` section modifier, CodeBase, (value is EDKII) allows for
> +platform integrators to override default build
> options set in the `tools_def.txt` file scoped according to the type of INF
> file being processed. EDK II INF files all contain an `INF_VERSION` element in
> -their `[Defines]` section, while EDK libraries and components do not have
> the
> -element. The `[BuildOptions]` section of an INF file override both the
> +their `[Defines]` section. The `[BuildOptions]` section of an INF file override
> both the
> `tools_def.txt` options and the options set in the `[BuildOptions]` section. In
> order to override options set in the INF file, the options must be overridden
> using the INF scoped `<BuildOptions>` tag after an INF file specified in the
> `[Components]` section.
>
> @@ -167,27 +166,27 @@ The result would logically be: `*_*_*_TEST_FLAGS
> = /a /b`
> ```
>
> The result for EDK II modules would be: `*_*_*_TEST_FLAGS = /a /b /c`
>
> ```ini
> -[BuildOptions.common.EDK]
> - # Entries are for EDK components and libraries
> +[BuildOptions.common.EDKII]
> + # Entries are for EDK II components and libraries
> *_*_*_TEST_FLAGS = /d
> ```
>
> -The result for EDK components and libraries would be: `*_*_*_TEST_FLAGS
> = /a /b /d`
> +The result for EDKII components and libraries would be:
> `*_*_*_TEST_FLAGS = /a /b /d`
>
> ```ini
> [BuildOptions.IA32]
> # Architectural options for IA32
> *_*_*_TEST_FLAGS = /e
> ```
>
> The logical result is: `*_*_IA32_TEST_FLAGS = /a /b /c /e`
>
> ```ini
> -[BuildOptions.X64.EDK]
> +[BuildOptions.X64.EDKII]
> # Architectural options for X64
> *_*_*_TEST_FLAGS = /f
> DEBUG_*_*_TEST_FLAGS = /g
> RELEASE_*_*_TEST_FLAGS = /h
> ```
> @@ -220,11 +219,11 @@ The logical result is:
> #### Prototype
>
> ```c
> <BuildOptions> ::= "[BuildOptions" [<attribs>] "]" <EOL> <Statements>*
> <attribs> ::= "." <arch> [<CodeBase> ["." <ModuleType>]]
> -<CodeBase> ::= "." {"Common"} {"EDK"} {"EDKII"}
> +<CodeBase> ::= "." {"Common"} {"EDKII"}
> <Statements> ::= {<MacroDefinition>} {<IncludeStatement>}
> {<TS> <BStatement>}
> <BStatement> ::= {<ToolFlag>} {<ToolPath>} {<ToolCmd>} {<Other>}
> <ToolFlag> ::= [<Family> ":"] <FlagSpec> <Equal> <Flags> <EOL>
> <ToolPath> ::= [<Family> ":"] <PathSpec> <Equal> <PATH> <EOL>
> diff --git a/3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> b/3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> deleted file mode 100644
> index 23c441c..0000000
> --- a/3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> +++ /dev/null
> @@ -1,94 +0,0 @@
> -<!--- @file
> - 3.8 [Libraries] 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.
> -
> --->
> -
> -## 3.8 [Libraries] Sections
> -
> -The section `[Libraries]` sections are optional in EDK II DSC files, although
> -if any EDK component is specified in the `[Components]` section, then the
> EDK
> -II DSC file must contain this section. EDK components can not use EDK II
> -Library Instances.
> -
> -#### Summary
> -
> -Defines the `[Libraries]` section tag which lists the libraries that are linked
> -against
> -
> -EDK I components. Entries may appear in any order. Entries for EDK are a list
> -of INF files, with a path that is relative to the `$(EFI_SOURCE)`,
> -`$(EDK_SOURCE)` or `$(ECP_SOURCE)` directories (or a MACRO definition).
> -
> -One or more `!include` statements may be used within the libraries sections.
> If
> -used, the file included must be a list of INF files and their paths relative to
> -the `$(EFI_SOURCE)`, `$(EDK_SOURCE)` or `$(ECP_SOURCE)` directories.
> -
> -#### Prototype
> -
> -```c
> -<Libraries> ::= "[Libraries" [<attribs>] "]" <EOL> <LibStatements>*
> -<LibStatements> ::= {<MacroDefinition>} {<IncludeStatement>}
> - {<Statement>}
> -<attribs> ::= "." <arch> [", Libraries." <arch>]*
> -<Statement> ::= <TS> <PathAndFilename> <EOL>
> -<PathAndFilename> ::= <LPATH> <Word> ".inf"
> -<LPATH> ::= [{"$(EDK_SOURCE)"} {<MACROVAL>} "/"] <Path>*
> -<Path> ::= <Word> "/"
> -```
> -
> -#### Parameters
> -
> -**_arch_**
> -
> -The arch attribute must be specified in the `Conf/tools_def.txt` file for the
> -tool chain used to build the platform in order to be valid.
> -
> -**_Path_**
> -
> -If only the `<Path>` element is specified, the path is `WORKSPACE` relative.
> -
> -#### Example
> -
> -```ini
> -[Libraries]
> - Foundation/Efi/Guid/EfiGuidLib.inf
> - Foundation/Framework/Guid/EdkFrameworkGuidLib.inf
> - Foundation/Guid/EdkGuidLib.inf
> - Foundation/Library/EfiCommonLib/EfiCommonLib.inf
> - Foundation/Cpu/Pentium/CpuIA32Lib/CpuIA32Lib.inf
> - Foundation/Cpu/Itanium/CpuIA64Lib/CpuIA64Lib.inf
> - Foundation/Library/CustomizedDecompress/CustomizedDecompress.inf
> -
> -[Libraries.IA32]
> - DEFINE PLATFORM_DIR = $(EDK_SOURCE)/Platform
> - $(PLATFORM_DIR)/IntelEpg/Guid/IntelEpgGuidLib.inf
> - $(PLATFORM_DIR)/IntelEpg/Ppi/IntelEpgPpiLib.inf
> - $(PLATFORM_DIR)/Generic/Guid/GenericGuidLib.inf
> - $(PLATFORM_DIR)/Generic/Lib/Port80MappingLib/PlatformPort80.inf
> -```
> diff --git a/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> b/3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
> similarity index 95%
> rename from 3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> rename to 3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
> index 9ac3878..cc9f96e 100644
> --- a/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> +++ b/3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.9 [LibraryClasses] 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.9 [LibraryClasses] Sections
> +## 3.8 [LibraryClasses] Sections
>
> The `[LibraryClasses]` sections are optional if no library classes are defined
> for any of the components, or if only EDK modules are used.
>
> #### Summary
> diff --git a/3_edk_ii_dsc_file_format/310_pcd_sections.md
> b/3_edk_ii_dsc_file_format/39_pcd_sections.md
> similarity index 97%
> rename from 3_edk_ii_dsc_file_format/310_pcd_sections.md
> rename to 3_edk_ii_dsc_file_format/39_pcd_sections.md
> index f982d60..96e4f0e 100644
> --- a/3_edk_ii_dsc_file_format/310_pcd_sections.md
> +++ b/3_edk_ii_dsc_file_format/39_pcd_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.10 PCD 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
> DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.10 PCD Sections
> +## 3.9 PCD Sections
>
> The PCD sections are optional.
>
> PCD Values listed in the DSC file must be absolute values, macro names or
> expressions which may include other PCD names and/or macro names that
> have been
> @@ -111,11 +111,11 @@ PCDs with a C strucutre type is also a VOID* PCD. Its
> value can be specified lik
> normal VOID* PCD, and also be specified by its structure field.
>
> Refer to the _EDK II Build Specification_ for the description of the PCD
> processing rules.
>
> -### 3.10.1 [PcdsFeatureFlag] Sections
> +### 3.9.1 [PcdsFeatureFlag] Sections
>
> These are optional sections for EDK II DSC Files.
>
> #### Summary
>
> @@ -192,11 +192,11 @@ section tag can only be used as a conditional
> modifier.
> `SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
> must break, stating that this platform requires separate builds for individual
> `SkuId`s.
> **********
>
> -### 3.10.2 [PcdsFixedAtBuild] Section
> +### 3.9.2 [PcdsFixedAtBuild] Section
>
> These are optional sections for EDK II DSC Files.
>
> #### Summary
>
> @@ -298,11 +298,11 @@ must be used.
> `SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
> must break, stating that this platform requires separate builds for individual
> `SkuId`s.
> **********
>
> -### 3.10.3 [PcdsPatchableInModule] Sections
> +### 3.9.3 [PcdsPatchableInModule] Sections
>
> These are optional sections.
>
> #### Summary
>
> @@ -403,11 +403,11 @@ must be used.
> `SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
> must break, stating that this platform requires separate builds for individual
> `SkuId`s.
> **********
>
> -### 3.10.4 [PcdsDynamic] Sections
> +### 3.9.4 [PcdsDynamic] Sections
>
> These are optional sections.
>
> #### Summary
>
> @@ -632,11 +632,11 @@ the _UEFI Specification_ for a description of these
> attributes.
> [PcdsDynamicHii.IA32, PcdsDynamicHii.X64.Sku1.Standard]
>
> gEfiMyModulePkgTokenSpaceGuid.PcdChassisIntrution|L"TestVariable"|gSy
> sConfigGuid|0x83|0x0
>
> gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L
> "Timeout"|gEfiGlobalVariableGuid|0x0|10 # Variable: L"Timeout"
> ```
>
> -### 3.10.5 [PcdsDynamicEx] Sections
> +### 3.9.5 [PcdsDynamicEx] Sections
>
> These are optional sections.
>
> #### Summary
>
> --
> 2.20.1.windows.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Patch] Document: Update DSC spec to remove EDK related contents
2019-03-05 3:48 [Patch] Document: Update DSC spec to remove EDK related contents Feng, Bob C
2019-03-05 15:24 ` Carsey, Jaben
@ 2019-03-06 8:31 ` Gao, Liming
1 sibling, 0 replies; 3+ messages in thread
From: Gao, Liming @ 2019-03-06 8:31 UTC (permalink / raw)
To: Feng, Bob C, edk2-devel@lists.01.org; +Cc: Carsey, Jaben
1. 2.12 [UserExtensions] Section and ## 2.11 [UserExtensions] Section are inconsistent. There are the similar issue in this patch. Please check them to make sure they are same.
2. Update commit message for EDK and IPF both.
> -----Original Message-----
> From: Feng, Bob C
> Sent: Monday, March 4, 2019 7:49 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] Document: Update DSC spec to remove EDK related contents
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1453
>
> Remove EDK related contents inf Dsc 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 | 14 +--
> ...=> 210_[components]_section_processing.md} | 27 +-----
> ...ion.md => 211_[userextensions]_section.md} | 4 +-
> ...212_[defaultstores]_section_processing.md} | 4 +-
> .../22_build_description_file_format.md | 50 ++--------
> .../23_[defines]_section_processing.md | 12 +--
> 2_dsc_overview/24_[buildoptions]_section.md | 72 ++------------
> .../26_[libraries]_section_processing.md | 69 --------------
> ...26_[libraryclasses]_section_processing.md} | 4 +-
> ...essing.md => 27_pcd_section_processing.md} | 34 +++----
> ...{29_pcd_sections.md => 28_pcd_sections.md} | 26 ++---
> ...210_pcd_database.md => 29_pcd_database.md} | 4 +-
> ...ctions.md => 310_[components]_sections.md} | 62 +-----------
> ...ns.md => 311_[userextensions]_sections.md} | 4 +-
> ...tion.md => 312_[defaultstores]_section.md} | 4 +-
> 3_edk_ii_dsc_file_format/32_general_rules.md | 13 +--
> .../33_platform_dsc_definition.md | 17 +---
> .../35_[defines]_section.md | 12 +--
> .../36_[buildoptions]_sections.md | 19 ++--
> .../38_[libraries]_sections.md | 94 -------------------
> ...ons.md => 38_[libraryclasses]_sections.md} | 4 +-
> ...310_pcd_sections.md => 39_pcd_sections.md} | 14 +--
> 22 files changed, 101 insertions(+), 462 deletions(-)
> rename 2_dsc_overview/{211_[components]_section_processing.md => 210_[components]_section_processing.md} (84%)
> rename 2_dsc_overview/{212_[userextensions]_section.md => 211_[userextensions]_section.md} (93%)
> rename 2_dsc_overview/{213_[defaultstores]_section_processing.md => 212_[defaultstores]_section_processing.md} (93%)
> delete mode 100644 2_dsc_overview/26_[libraries]_section_processing.md
> rename 2_dsc_overview/{27_[libraryclasses]_section_processing.md => 26_[libraryclasses]_section_processing.md} (96%)
> rename 2_dsc_overview/{28_pcd_section_processing.md => 27_pcd_section_processing.md} (94%)
> rename 2_dsc_overview/{29_pcd_sections.md => 28_pcd_sections.md} (93%)
> rename 2_dsc_overview/{210_pcd_database.md => 29_pcd_database.md} (96%)
> rename 3_edk_ii_dsc_file_format/{311_[components]_sections.md => 310_[components]_sections.md} (81%)
> rename 3_edk_ii_dsc_file_format/{312_[userextensions]_sections.md => 311_[userextensions]_sections.md} (94%)
> rename 3_edk_ii_dsc_file_format/{313_[defaultstores]_section.md => 312_[defaultstores]_section.md} (93%)
> delete mode 100644 3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> rename 3_edk_ii_dsc_file_format/{39_[libraryclasses]_sections.md => 38_[libraryclasses]_sections.md} (95%)
> rename 3_edk_ii_dsc_file_format/{310_pcd_sections.md => 39_pcd_sections.md} (97%)
>
> diff --git a/1_introduction/11_overview.md b/1_introduction/11_overview.md
> index d9006df..ff2b517 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:
>
> @@ -48,14 +48,11 @@ specifications.
> This design has the following goals.
>
> **Compatible**
>
> The EDK II DSC format does not support EDK DSC format, nor can EDK tools be
> -used to parse the EDK II DSC format files. The EDK II DSC Format must maintain
> -backward compatibility for supporting existing EDK INF file formats. This means
> -that the changes made to this specification do not require changes for standard
> -INF files.
> +used to parse the EDK II DSC format files.
>
> **Simplified platform build and configuration**
>
> One goal of this format is to simplify the build setup and configuration for a
> given platform. It was also designed to simplify the process of adding EDK II
> @@ -67,11 +64,11 @@ builds.
> ###### Table 1 EDK Build Infrastructure Support Matrix
>
> | | EDK DSC | EDK II DSC | EDK FDF | EDK II FDF | EDK INF | EDK II INF |
> | ------------------ |:---------:|:------------:|:---------:|:------------:|:---------:|:------------:|
> | EDK Build Tools | YES | NO | YES | NO | YES | NO |
> -| EDK II Build Tools | NO | YES | NO | YES | YES | YES |
> +| EDK II Build Tools | NO | YES | NO | YES | NO | YES |
>
> **********
> **Note:** This document is intended for persons doing EFI development and
> support for different platforms. It is most likely only of interest in the
> event that there is a problem with a build, or if a developer needs to perform
> @@ -90,9 +87,6 @@ contain information on the EFI format for FFS or FV file creation. The
> Makefiles will support third party compilation tools - Microsoft, Intel and GCC
> tool chains - and at least one EDK II tool, GenFw. The GenFw tool is used to
> manipulate the files emitted from the compilation tools.
>
> The EDK II build provides UEFI and PI (Unified EFI, Inc.)
> -specification-compliant images. Use of the tools in the EDK Compatibility
> -package can be used for creating earlier versions of EFI 1.10 and/or UEFI 2.0
> -compliant components. To be clear, EDK II tools do not have the limitation of
> -ECP tools, which can only do EFI 1.10 and UEFI 2.0 images.
> +specification-compliant images.
> diff --git a/2_dsc_overview/211_[components]_section_processing.md b/2_dsc_overview/210_[components]_section_processing.md
> similarity index 84%
> rename from 2_dsc_overview/211_[components]_section_processing.md
> rename to 2_dsc_overview/210_[components]_section_processing.md
> index 140f09c..c1948e8 100644
> --- a/2_dsc_overview/211_[components]_section_processing.md
> +++ b/2_dsc_overview/210_[components]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.11 [Components] Section Processing
>
> - 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:
>
> @@ -27,31 +27,24 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.11 [Components] Section Processing
> +## 2.10 [Components] Section Processing
>
> -One or more `[Components]` sections contain lists of EDK components and EDK II
> -Modules. The format for specifying the INF file for EDK II modules incorporates
> -new scoping capabilities.
> +One or more `[Components]` sections contain lists of EDK II Modules. The format
> +for specifying the INF file for EDK II modules incorporates new scoping capabilities.
>
> This section uses one or more of the following section definitions:
>
> * `[Components]`
> * `[Components.IA32]`
> * `[Components.X64]`
> * `[Components.EBC]`
> * `[Components.common]`
>
> -EDK components are specified using a fully qualified path to the EDK INF file.
> -
> -`$(EDK_SOURCE)/Path/and/Filename.inf`
> -
> -Because EDK II modules have different requirements than EDK I components,
> -specifying the INF filename in the extended DSC file may require more than just
> -the INF filename and options. A scoping structure, that binds library class
> +A scoping structure, that binds library class
> (with an optional override instance,) PCD settings (also overriding the values
> specified in the `[PcdsPatchableInModule]` or `[PcdsFixedAtBuild]` sections)
> and build options for an EDK II module may be required. This scoping structure,
> containing sub-elements, is enclosed within curly braces: "{}". The opening
> curly brace, "{", must appear at the end of the inf filename line, before any
> @@ -79,20 +72,10 @@ Path/and/Filename.inf {
>
> There are four valid, optional sub-elements for EDK II modules. These
> sub-element are enclosed within angle brackets: `<Defines>, <LibraryClasses>`,
> `<Pcds*>` and `<BuildOptions>`.
>
> -For EDK component INF files, an optional sub-element of
> -`<SOURCE_OVERRIDE_PATH>` has been defined. If this element is specified, files
> -listed in the directory are used instead of the "same-named" files in the
> -component's directory. If an EDK component directory lists files, A.c, B.c and
> -C.h, and the directory specified in this sub-element contains the file B.c,
> -then the component will be built using files from the component directory: A.c
> -and C.h, and the file B.c from the override directory. Any other files listed
> -in the override directory will NOT be included in the build (no new or
> -additional files are permitted).
> -
> An INF file line may also have one argument, EXEC = Filename, that specifies
> an executable file that takes the INF filename as a parameter. The Filename
> must be executable, and must take the INF filename. No other arguments are
> permitted to the Filename.
>
> diff --git a/2_dsc_overview/212_[userextensions]_section.md b/2_dsc_overview/211_[userextensions]_section.md
> similarity index 93%
> rename from 2_dsc_overview/212_[userextensions]_section.md
> rename to 2_dsc_overview/211_[userextensions]_section.md
> index c176d86..4708e7e 100644
> --- a/2_dsc_overview/212_[userextensions]_section.md
> +++ b/2_dsc_overview/211_[userextensions]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.12 [UserExtensions] Section
>
> - 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.12 [UserExtensions] Section
> +## 2.11 [UserExtensions] Section
>
> Users may develop custom tools that use the `[UserExtensions]` sections.The EDK
> II `[UserExtensions]` sections allow for extending the DSC file with custom
> processing of component images. The format for a user extension section
> specifier is:
> diff --git a/2_dsc_overview/213_[defaultstores]_section_processing.md b/2_dsc_overview/212_[defaultstores]_section_processing.md
> similarity index 93%
> rename from 2_dsc_overview/213_[defaultstores]_section_processing.md
> rename to 2_dsc_overview/212_[defaultstores]_section_processing.md
> index 88a7ad2..be83759 100644
> --- a/2_dsc_overview/213_[defaultstores]_section_processing.md
> +++ b/2_dsc_overview/212_[defaultstores]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.13 [DefaultStores] Section Processing
>
> - 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.13 [DefaultStores] Section Processing
> +## 2.12 [DefaultStores] Section Processing
>
> The contents of this section are used to define DefaultStores names. Default
> store is UEFI HII concept. It is used to define HII default setting for the
> different store, such as standard default, manufacturing default. Platform
> can define the supported default store for DynamicHii/DynamicExHii PCD in this
> diff --git a/2_dsc_overview/22_build_description_file_format.md b/2_dsc_overview/22_build_description_file_format.md
> index 31e23f4..10dc428 100644
> --- a/2_dsc_overview/22_build_description_file_format.md
> +++ b/2_dsc_overview/22_build_description_file_format.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.2 Build Description File Format
>
> - 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:
>
> @@ -229,19 +229,18 @@ definition, contain complete sections, or combination of both. And 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 the paths listed in the system environment
> -variables `$(WORKSPACE)`, `$(EFI_SOURCE)`, `$(EDK_SOURCE)`, and
> -`$(ECP_SOURCE)`. If the file is still not found, the parsing tools must
> -terminate with an error.
> +variable `$(WORKSPACE)`. If the file is still not found, the parsing tools
> +must terminate with an error.
>
> Macros, defined in this 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.
> +for macros. The system environment variable `$(WORKSPACE)`, may also be used;
> +only these system environment variables are permitted to start the path of the
> +included file.
>
> Statements in `!include` files must not break the integrity of the DSC 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.
> @@ -395,14 +394,10 @@ reference build (Nt32Pkg/Nt32Pkg.dsc), macros set on a command line override
> any macro value defined in the DSC (or FDF) file.
>
> MACROs may also be used as values in PCD statements. See _Section 3.10_ for
> more information on PCD statements.
>
> -In order to support EDK components and libraries, the word `DEFINE` is replaced
> -with `EDK_GLOBAL`. The `EDK_GLOBAL` macros are considered global during the
> -processing of the DSC, FDF and EDK INF files.
> -
> Macros that appear within double quotation marks in build options sections are
> not expanded. It is assumed that they will be expanded by the OS or external
> scripting tools.
>
> Global variables that may be used in EDK II DSC and FDF meta-data files are
> @@ -427,13 +422,10 @@ be altered.
> ###### Table 3 Using System Environment Variable
>
> | Macro Style Used in Meta-Data Files | Matches Windows Environment Variable | Matches Linux & OS/X Environment Variable |
> | ----------------------------------- | ------------------------------------ | ----------------------------------------- |
> | $(WORKSPACE) | %WORKSPACE% | $WORKSPACE
> |
> -| $(EFI_SOURCE) | %EFI_SOURCE% | $EFI_SOURCE
> |
> -| $(EDK_SOURCE) | %EDK_SOURCE% | $EDK_SOURCE
> |
> -| $(ECP_SOURCE) | %ECP_SOURCE% | $ECP_SOURCE
> |
> | $(EDK_TOOLS_PATH) | %EDK_TOOLS_PATH% | $EDK_TOOLS_PATH
> |
>
> The system environment variables, PACKAGES_PATH and EDK_TOOLS_BIN, are not
> permitted in EDK II meta-data files.
>
> @@ -479,22 +471,11 @@ follow the same rules as architectural modifiers.
> # Can use $(MDE) from the common section
> PalLib|$(MDE)/UefiPalLib/UefiPalLib.inf
> TimerLib|$(MDE)/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
> ```
>
> -### 2.2.7 EDK_GLOBAL
> -
> -The `EDK_GLOBAL` statements defined in the DSC file can be used during the
> -processing of the DSC, FDF and EDK INF files. The definition of the
> -`EDK_GLOBAL` name must only be done in the DSC `[Defines]` section. These
> -special macros can be used in path statements, DSC file `[BuildOptions]` and
> -FDF file `[Rule]` sections. These statements are used to replace the
> -environment variables that were defined for the EDK build tools. They must
> -never be used in a conditional directive statement in the DSC and FDF files,
> -nor can they be used by EDK II INF files.
> -
> -### 2.2.8 Conditional Directive Statements (!if...)
> +### 2.2.7 Conditional Directive Statements (!if...)
>
> Conditional directive statements are used by the build tools preprocessor
> function to include or exclude statements in the DSC file. A limited number of
> statements are supported, and nesting of conditionals is also supported.
> Statements are prefixed by the exclamation "!" character. Conditional
> @@ -642,11 +623,11 @@ The following are examples of conditional directives.
> !else
> # The strings do not match exactly
> !endif
> ```
>
> -### 2.2.9 !error Statement
> +### 2.2.8 !error Statement
>
> The `!error` statement may appear within any section of EDK II DSC file. The
> argument of this statement is an error message, it causes build tool to stop
> at the location where the statement is encountered and error message following
> the `!error` statement is output as a message. The keyword `!error` is not
> @@ -658,11 +639,11 @@ The following example show the valid usage of the `!error` statement.
> !if $(FEATURE_ENABLE) == TRUE
> !error "unsupported feature!"
> !endif
> ```
>
> -### 2.2.10 Expressions
> +### 2.2.9 Expressions
>
> Expressions can be used in conditional directive comparison statements and in
> value fields for Macros and PCDs in the DSC and FDF files.
>
> Refer to the EDK II Expression Syntax Specification for additional information.
> @@ -723,11 +704,11 @@ names specified on the command line or come from the `Conf/target.txt` file.
>
> For logical expressions, any non-zero value must be considered `TRUE`.
>
> Invalid expressions must cause a build break with an appropriate error message.
>
> -### 2.2.11 Section Handling
> +### 2.2.10 Section Handling
>
> The DSC file parsing routines must process the sections so that common
> architecture sections are logically merged with the architecturally specific
> sections. The architectural sections need to be processed so that they are
> logically after the common section. It is recommended that EDK II developers
> @@ -750,24 +731,13 @@ on the "==" replace or "=" append assignment character sequence.
>
> ```ini
> [BuildOptions.Common]
> MSFT:*_*_*_CC_FLAGS = /nologo
>
> -[BuildOptions.Common.EDK]
> - MSFT:*_*_*_CC_FLAGS = /Od
> -
> [BuildOptions.IA32]
> MSFT:*_*_IA32_CC_FLAGS = /D EFI32
> ```
>
> For IA32 architecture builds of an EDK II INF file would logically be:
>
> `MSFT:*_*_IA32_CC_FLAGS = /nologo /D EFI32`
>
> -For non-IA32 architecture EDK INF files, tool parsing would logically be:
> -
> -`MSFT:*_*_*_CC_FLAGS = /nologo /Od`
> -
> -For IA32 architecture builds of an EDK INF file, tool parsing would logically
> -be:
> -
> -`MSFT:*_*_IA32_CC_FLAGS = /nologo /D EFI32 /Od`
> diff --git a/2_dsc_overview/23_[defines]_section_processing.md b/2_dsc_overview/23_[defines]_section_processing.md
> index 428196b..ad0702b 100644
> --- a/2_dsc_overview/23_[defines]_section_processing.md
> +++ b/2_dsc_overview/23_[defines]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.3 [Defines] Section Processing
>
> - 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:
>
> @@ -80,14 +80,10 @@ define the MACRO name during the processing of this file, files included by the
> **Warning:** The DEFINE MACRO = Value statements in other sections are local to
> the section, and override the global definition for entries in the section that
> follow the macro definition: `DEFINE MACRO = Value.`
> **********
>
> -The `EDK_GLOBAL MACRO = Value` definitions in this section globally define the
> -MACRO name when parsing the DSC, files included by the !include statement, FDF
> -and EDK INF files.
> -
> The EDK II tools will locate the FDF file specified in the `FLASH_DEFINITION`
> entry in the same directory as the DSC file. When the PCD_VAR_CHECK_GENERATION
> entry is present and set to TRUE, tools will generate a binary file for
> DynamicHii and DynamicExHii PCD variable checking.
>
> @@ -112,11 +108,10 @@ item is required.
> | `BUILD_NUMBER` | Optional | Up to four digit numbers | Set this value in the generated Makefile.
> |
> | `FIX_LOAD_TOP_MEMORY_ADDRESS` | Optional | Address | The top memory address - the starting
> location in memory for all drivers, application loading. When it is not set, or set to 0, the load fixed address feature will be disabled. When
> it is set to 0xFFFFFFFFFFFFFFFF, enable the feature as fixed offset to TOLM. When it is set to the positive address, enable the feature as
> fixed address. |
> | `TIME_STAMP_FILE` | Optional | Filename | The timestamp file contains a timestamp
> that will be used to set the creation timestamp on all created files. If this file is specified, it will be used to adjust the timestamp of created
> files, if it does not exist at the start of a build, the file will be created, using the current date and time.
> |
> | | | | If this variable is not specified, the time
> and date of the start of the build are used by the EDK II tools that modify the time/date portion of a PE32/PE32+/Coff header. This file's
> path is either relative to the directory containing the DSC file or a `WORKSPACE`[^1] relative path followed by the file name.
> |
> | `DEFINE` | Optional | MACRO = PATH or Value | A name that is assigned to either a path or a
> value. This statement can be used to make the DSC file more readable, as in: `DEFINE MDE = MdePkg/Library` Then, later,
> `$(MDE)/BaseLib/ BaseLib.inf`
> |
> -| `EDK_GLOBAL` | Optional | MACRO = PATH or Value | Similar to the DEFINE statement, macros
> defined using this keyword are only valid when processing EDK ibraries and components. These values are ignored during processing of
> EDK II modules.
> |
> | `RFC_LANGUAGES` | Optional | RFC4646 Language code list | A semi-colon ";" separated list of RFC4646
> Language codes (EDK II Modules) used during the generation of only a set, rather than all, UNICODE languages during the StrGather
> AutoGen phase. The list must be encapsulated in double quotes.
> |
> | `ISO_LANGUAGES` | Optional | ISO-639-2 Language code list | A non-separated list of three character ISO
> 639-2 Language codes (EDK Components) used during the generation of only a set, rather than all, UNICODE languages during the
> StrGather AutoGen phase. The list must be encapsulated in double quotes.
> |
> | `VPD_TOOL_GUID` | Optional | Registry Format GUID | When this element is present, the build
> process will be interrupted during the AutoGen stage in order to call an external program, named by GUID that must also be defined in the
> Conf/tools_def.txt file using a tool code name of VPDTOOL. Refer to the EDK II Build specification for additional information.
> |
> | `PCD_INFO_GENERATION` | Optional | TRUE or FALSE | If present, and set to TRUE, this flag will
> generate PCD information in the Pcd Database.
> |
> | `PCD_VAR_CHECK_GENERATION` | Optional | TRUE or FALSE | If present and set to TRUE, this flag will
> generate the variable validation table binary file in the build output FV floder. If not present ro set to FALSE, then the binary file will not be
> generated.
> |
> @@ -128,9 +123,8 @@ WORKSPACE system environment variable and the PACKAGES_PATH system environment
> variable.
>
> **********
> **Note:** EDK II Modules can have unicode string files that contain RFC4646
> language codes. EDK II modules cannot have unicode string files that contain
> -ISO-629-2 language codes. USI-629-2 language codes are only valid for EDK
> -components. The format of the statement is specific to processing RFC4646
> -language code lists.
> +ISO-629-2 language codes. The format of the statement is specific to processing
> +RFC4646 language code lists.
> **********
> diff --git a/2_dsc_overview/24_[buildoptions]_section.md b/2_dsc_overview/24_[buildoptions]_section.md
> index 7d3d2d1..375866c 100644
> --- a/2_dsc_overview/24_[buildoptions]_section.md
> +++ b/2_dsc_overview/24_[buildoptions]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.4 [BuildOptions] Section
>
> - 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:
>
> @@ -33,11 +33,11 @@
>
> Content in the `[BuildOptions]` section is used to define module specific tool
> chain flags rather than use the default flags for a module. These flags are
> appended to any standard flags that are defined by the build process. They can
> be applied for any modules or those modules on the specific ARCH or those
> -modules with the specific module style (EDK or EDKII). In order to replace the
> +modules with the specific EDKII module style. In order to replace the
> standard flags that are defined by the build process, an alternate assignment
> operator is used; "==" is used for replacement, while "=" is used to append
> the flag lines. In addition to flags, other tool attributes may have the item
> either appended or replaced.
>
> @@ -94,93 +94,35 @@ that the lines show use of the "\" line continuation character.
> ```
>
> The following examples show how `[BuildOptions]` sections can be merged, as
> well as how the content in those sections can be merged.
>
> -For specific flag values, common to both EDK and EDKII options, it is
> -appropriate to use a `DEFINE` statement in the `[Defines]` section; for
> +It is appropriate to use a `DEFINE` statement in the `[Defines]` section; for
> example 1:
>
> `DEFINE MSFT_COMMON_DEBUG_FLAGS = /Od`
>
> Then the macro, $(MSFT_COMMON_DEBUG_FLAGS) can be used in statements in any of
> the `[BuildOptions.*]` sections, as in:
>
> ```ini
> -[BuildOptions.Common.EDK]
> +[BuildOptions.X64]
> MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c $(MSFT_COMMON_DEBUG_FLAGS)
>
> -[BuildOptions.Common.EDKII]
> +[BuildOptions.IA32]
> MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c $(MSFT_COMMON_DEBUG_FLAGS)
> ```
>
> It is also permissible to have a `[BuildOptions.<arch>]` section that can be
> shared be used for different statements that are not duplicate content from
> -either the `[BuildOptions.<arch>.EDK]` or `[BuildOptions.<arch>.EDKII]`
> -sections. For example 2:
> +the `[BuildOptions.<arch>.EDKII]` sections. For example:
>
> ```ini
> [BuildOptions.Common]
> MSFT:*_*_*_ASL_OUTFLAGS = /Fo=
>
> -[BuildOptions.Common.EDK]
> - MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c /D UNICODE
> -
> -[BuildOptions.IA32.EDK]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy
> -
> [BuildOptions.Common.EDKII]
> MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c /D UNICODE
>
> [BuildOptions.IA32.EDKII]
> MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy
> -```
> -
> -It is also permissible to have a `[BuildOptions.<arch>]` section that can be
> -shared be used prior to appending statement content from either the
> -`[BuildOptions.<arch>.EDK]` or `[BuildOptions.<arch>.EDKII]` sections as in the
> -following example:
> -
> -```ini
> -[BuildOptions.IA32]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /nologo /W4 /WX /Gy /c /D UNICODE
> -
> -[BuildOptions.IA32.EDKII]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /FI$(DEST_DIR_DEBUG)/AutoGen.h
> -
> -[BuildOptions.IA32.EDK]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /D EFI32
> -```
> -
> -When processing EDK II C files, the `CC_FLAGS` would be:
> -
> -`/nologo /W4 /WX /Gy /c /D UNICODE /FI$(DEST_DIR_DEBUG)/AutoGen.h`
> -
> -While processing of EDK C files, the CC_FLAGS would be:
> -
> -`/nologo /W4 /WX /Gy /c /D UNICODE /D EFI32`
> -
> -It is also permissible to combine [BuildOptions.common] with
> -`[BuildOptions.<arch>]` sections that are not "common", as in the following
> -example:
> -
> -```ini
> -[BuildOptions.Common]
> - MSFT:DEBUG_*_*_CC_FLAGS = /nologo /c
> -
> -[BuildOptions.IA32]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /W4 /WX /Gy /D UNICODE
> -
> -[BuildOptions.IA32.EDKII]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /FI$(DEST_DIR_DEBUG)/AutoGen.h
> -
> -[BuildOptions.IA32.EDK]
> - MSFT:DEBUG_*_IA32_CC_FLAGS = /D EFI32
> -```
> -
> -In the previous example, the `CC_FLAGS` for IA32 EDK II modules would equal:
> -
> -`/nologo /x /W4 /WX /Gy /D UNICODE /FI$(DEST_DIR_DEBUG)/AutoGen.h`
> -
> -The CC_FLAGS for IA EDK modules would equal:
> -
> -`/nologo /c /W4 /WX /Gy /D UNICODE /D EFI32`
> +```
> \ No newline at end of file
> diff --git a/2_dsc_overview/26_[libraries]_section_processing.md b/2_dsc_overview/26_[libraries]_section_processing.md
> deleted file mode 100644
> index 82cda47..0000000
> --- a/2_dsc_overview/26_[libraries]_section_processing.md
> +++ /dev/null
> @@ -1,69 +0,0 @@
> -<!--- @file
> - 2.6 [Libraries] Section Processing
> -
> - 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.6 [Libraries] Section Processing
> -
> -This section specifies all the EDK INF files that must be processed to build
> -the libraries used to build the individual EDK components. This will include
> -all the libraries called out in the individual component INF files. A sample
> -section is listed below. Each line from the libraries section specifies a
> -library component's INF file (relative to `$(EDK_SOURCE)`, or absolute path).
> -
> -This section is required for any EDK II DSC file that specifies one or more EDK
> -components. If only EDK II Modules are used, this section must not be
> -specified. If the section is specified, and only EDK II Modules are found, the
> -build and parsing tools will ignore this section. A warning message will be
> -emitted by the parsing tool if and only the parsing tool is executed in a
> -verbose mode.
> -
> -The `!include` statements may be used within the `[Libraries]` section.
> -
> -The file specified after the `!include` statement can only contain a list of
> -EDK Library INF files (with the path to the file). If the line starts with a
> -word, rather than a variable like `$(EDK_SOURCE)` the path is assumed to be
> -relative to `$(EDK_SOURCE)`. Again, only EDK Library INF files are permitted in
> -the file specified in the `!include` statement.
> -
> -This section will typically use one of the following section definitions:
> -
> -```ini
> -[Libraries.common]
> -[Libraries.IA32]
> -[Libraries.X64]
> -[Libraries.EBC]
> -```
> -
> -The formats for entries in this section is:
> -
> -```
> -$(EDK_SOURCE)/Path/to/LibraryName.inf
> -$(CUSTOM_DECOMPRESS_LIB_INF)
> -```
> diff --git a/2_dsc_overview/27_[libraryclasses]_section_processing.md b/2_dsc_overview/26_[libraryclasses]_section_processing.md
> similarity index 96%
> rename from 2_dsc_overview/27_[libraryclasses]_section_processing.md
> rename to 2_dsc_overview/26_[libraryclasses]_section_processing.md
> index 50bda93..0f87ceb 100644
> --- a/2_dsc_overview/27_[libraryclasses]_section_processing.md
> +++ b/2_dsc_overview/26_[libraryclasses]_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.7 [LibraryClasses] Section Processing
>
> - 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.7 [LibraryClasses] Section Processing
> +## 2.6 [LibraryClasses] Section Processing
>
> The `[LibraryClasses]` section is used to provide a mapping between the library
> class names used by an EDK II module and the Library Instances that are
> selected by the platform integrator. Library Classes allow modules to be coded
> for a library class, and then allow platform integrator then chooses a Library
> diff --git a/2_dsc_overview/28_pcd_section_processing.md b/2_dsc_overview/27_pcd_section_processing.md
> similarity index 94%
> rename from 2_dsc_overview/28_pcd_section_processing.md
> rename to 2_dsc_overview/27_pcd_section_processing.md
> index a5d56b3..d2a409f 100644
> --- a/2_dsc_overview/28_pcd_section_processing.md
> +++ b/2_dsc_overview/27_pcd_section_processing.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.8 PCD Section Processing
>
> - 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:
>
> @@ -27,22 +27,22 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.8 PCD Section Processing
> +## 2.7 PCD Section Processing
>
> This section is for specifying global (or default) PCD values as well as the
> access method each PCD will use for modules in the platform.
>
> -### 2.8.1 PCD Access Methods
> +### 2.7.1 PCD Access Methods
>
> There are five defined PCD access methods. The five access methods are:
> `FeatureFlag`, `FixedAtBuild`, `PatchableInModule`, `Dynamic` and `DynamicEx`
> PCDs.
>
> -#### 2.8.1.1 FeatureFlag and Dynamic PCD Types
> +#### 2.7.1.1 FeatureFlag and Dynamic PCD Types
>
> The two recommended access methods that are commonly used in modules are
> `FeatureFlag` and the generic `Dynamic method`. The `Dynamic` form is used for
> configuration when the PCD value is produced and consumed by drivers during
> execution, the value may be user configurable from setup or the value is
> @@ -50,11 +50,11 @@ produced by the platform in a specified area. It is associated with modules
> that are released in source code. The dynamic form is the most flexible method,
> as platform integrators may chose a to use a different access method for a
> given platform without modifying the module's INF file or the code for the
> module.
>
> -#### 2.8.1.2 DynamicEx, FixedAtBuild and PatchableInModule PCD Access Methods
> +#### 2.7.1.2 DynamicEx, FixedAtBuild and PatchableInModule PCD Access Methods
>
> Similar in function, the `DynamicEx` access method can be used with modules
> that are released as binary. The `FixedAtBuild` and `PatchableInModule` PCDs
> are static and only the `PatchableInModule` PCD can have the value changed in a
> binary prior to including the module in a firmware image.
> @@ -82,11 +82,11 @@ The content in these sections is used for generating the `AutoGen.c` and
> [Pcds(PcdType).IA32]
> [Pcds(PcdType).X64]
> [Pcds(PcdType).EBC]
> ```
>
> -### 2.8.2 PCD Access Method Categories
> +### 2.7.2 PCD Access Method Categories
>
> Of the five access methods of PCDs that have been defined, they fall into one
> of three categories:
>
> * `FeatureFlag` - always has a Boolean value.
> @@ -129,42 +129,42 @@ different datum type based on the architecture. For example, a PCD that is used
> for address manipulation may have a datum type of `UINT32` for IA32 and
> `UINT64` for X64 and EBC architectures. This will be declared in the EDK II
> Package Declaration (DEC) File.
> **********
>
> -### 2.8.3 PCD Section Usage
> +### 2.7.3 PCD Section Usage
>
> PCD sections are optional unless the EDK II modules specified in the
> `[Components]` section use PCDs.
>
> The PCD sections are used to define the access method for a PCD. Since each
> module is built once for a given architecture, the PCD can be listed under
> different PCD access methods provided they are listed under different
> architectures.
>
> -#### 2.8.3.1 Access Methods
> +#### 2.7.3.1 Access Methods
>
> However, once a PCD access method is selected for a given architecture, the PCD
> can only use that access method.
>
> #### Example
>
> A PCD that will use the `FixedAtBuild` access method for IA32 cannot use the
> `PatchableInModule` access method for individual modules built for the IA32
> architecture.
>
> -#### 2.8.3.2 Different Access Methods
> +#### 2.7.3.2 Different Access Methods
>
> It is permissible to have a PCD use different access methods for different
> architectures.
>
> #### Example
>
> A PCD that will use the FixedAtBuild access method for IA32 can use the
> Patchable in Module access method for X64.
>
> -#### 2.8.3.3 Item Access Methods
> +#### 2.7.3.3 Item Access Methods
>
> Multiple item access methods, `PcdsFeatureFlag`, `PcdsFixedAtBuild`,
> `PcdsPatchableInModule`, `PcdsDynamic` and `PcdsDynamicEx` are not allowed to
> be specified within a single [] section tag.
>
> @@ -187,11 +187,11 @@ be specified within a single [] section tag.
> [PcdsDynamicDefault.IA32]
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> ```
>
> -#### 2.8.3.4 Mixing PCD Dynamic item storage methods
> +#### 2.7.3.4 Mixing PCD Dynamic item storage methods
>
> It is not permissible to mix different PCD Dynamic item storage methods within
> a single section, as the format for the PCD entries in PcdsDynamicDefault,
> PcdsDynamicVpd, PcdsDynamicHii, and PcdsDynamicExDefault, PcdsDynamicExVpd and
> PcdsDynamicExHii sections are different.
> @@ -212,11 +212,11 @@ PcdsDynamicExHii sections are different.
>
> [PcdsDynamicExVpd.IA32]
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|*|0
> ```
>
> -#### 2.8.3.5 Multiple Architectural Section Tags
> +#### 2.7.3.5 Multiple Architectural Section Tags
>
> It is permissible to specify multiple architectural section tags for the same
> PCD item type in a single section.
>
> #### Example
> @@ -232,11 +232,11 @@ PCD item type in a single section.
> [PcdsDynamicDefault.IA32, PcdsDynamicDefault.X64]
> gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
> ```
>
> -#### 2.8.3.6 Dynamic and DynamicEx PCD Storage Methods
> +#### 2.7.3.6 Dynamic and DynamicEx PCD Storage Methods
>
> The PCDs that use Dynamic and DynamicEx access methods can have their values
> stored in one of three different methods, Default, VPD or HII. A PCD using one
> of these access methods can use one storage method. It is not permissible to
> have a PCD try to store the data in the Default database and a VPD region at
> @@ -273,11 +273,11 @@ TokenSpaceGuid.PcdCname|<HiiString>|<VariableGuid>|<VariableOffset>|<Value>|<Att
> **********
> **Note:** Some of the above fields are optional; refer to "PCD Sections" in the
> next chapter for the exact syntax.
> **********
>
> -#### 2.8.3.7 Unique PCDs
> +#### 2.7.3.7 Unique PCDs
>
> Unique PCDs are identified using the format to identify the named PCD:
>
> `TokenSpaceGuidCName.PcdCName`
>
> @@ -304,11 +304,11 @@ be used - `PcdsFixedAtBuild` for modules with wellknown values for a PCD,
> then either `PcdsPatchableInModule` or `PcdsDynamicEx` - the first
> being for testing a module, the second giving the ability for doing individual
> driver performance tuning "on-the-fly".
> **********
>
> -#### 2.8.3.8 Precedence
> +#### 2.7.3.8 Precedence
>
> Tools must assume that the first method found for a PCD in the PCDs sections
> will used for all instances of a PCD. Tools must not allow for different
> modules using a PCD differently, using the `<Pcds*>` statements under the INF
> file definitions in the `[Components]` section.
> @@ -375,11 +375,11 @@ listed more than one time within a section. List a PCD in one of the other
> access methods is allowed, provided a single access method must be used for all
> instances of the PCD. If PCD field value is listed, it will override PCD value
> even if PCD value is after PCD field value.
> **********
>
> -#### 2.8.3.9 Library Instances
> +#### 2.7.3.9 Library Instances
>
> Library Instances that use PCDs that the module is linked with must use the
> same PCD setting as the module using the Library Instance. So if a module uses
> a PCD as `PcdsFixedAtBuild`, then all library instances that use that PCD must
> also use the PCD as `PcdsFixedAtBuild` with the same value.
> @@ -393,11 +393,11 @@ The expression is a C-style expression using C relational, equality and logical
> numeric and bitwise operators or numeric and bitwise operators that evaluate to
> a value that matches the PCD's Datum Type (specified in the DEC package
> declaration file.) Precedence and associativity follow C standards. Using PCDs
> in expressions is also permitted.
>
> -#### 2.8.3.10 Maximum Size of a VOID* PCD
> +#### 2.7.3.10 Maximum Size of a VOID* PCD
>
> If the maximum size of a VOID* PCD is not specified in the DSC file, then the
> maximum size will be calculated based on the largest size of the following:
>
> * the string or array in the --pcd option
> diff --git a/2_dsc_overview/29_pcd_sections.md b/2_dsc_overview/28_pcd_sections.md
> similarity index 93%
> rename from 2_dsc_overview/29_pcd_sections.md
> rename to 2_dsc_overview/28_pcd_sections.md
> index d84d2f4..0b0b6d3 100644
> --- a/2_dsc_overview/29_pcd_sections.md
> +++ b/2_dsc_overview/28_pcd_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.9 PCD 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:
>
> @@ -27,13 +27,13 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.9 PCD Sections
> +## 2.8 PCD Sections
>
> -### 2.9.1 [PcdsFeatureFlag] section
> +### 2.8.1 [PcdsFeatureFlag] section
>
> The required content for the FeatureFlag PCD is the PCD Token Space Guid C
> name, the PCD's C name (these two entries are separated by the period
> character), and a Boolean value of either TRUE, FALSE, 1 or 0. The PCD name
> and value entries are separated by the pipe "|" character.
> @@ -69,19 +69,19 @@ Format of an entry in this section is:
> ```ini
> [PcdsFeatureFlag.common]
> gEfiMdeModulePkgTokenSpaceGuid.PcdDxePcdDatabaseTraverseEnabled|1
> ```
>
> -### 2.9.2 [PcdsFixedAtBuild] and [PcdsPatchableInModule] sections
> +### 2.8.2 [PcdsFixedAtBuild] and [PcdsPatchableInModule] sections
>
> The section modifier, `SkuIdentifier`, can be used by the build tools to create
> images for one specific SKU. Unlike the `PcdsDynamic` and `PcdsDynamicEx`
> entries, no access methods are allowed for having different values during
> runtime for different SKUs. Do not use the `SkuIdentifier` when building all
> SKUs.
>
> -#### 2.9.2.1 PcdsFixedAtBuild
> +#### 2.8.2.1 PcdsFixedAtBuild
>
> The `FixedAtBuild` PCD access method cannot be used in a Binary Module.
>
> The required content for the `FixedAtBuild` PCD are the PCD Token Space Guid
> C name, the PCD's C name (these two entries are separated by the period
> @@ -125,11 +125,11 @@ Format for Boolean and numeric entries in this section is:
> gEfiMdePkgTokenSpaceGuid.PcdFSBClock|200000000
> gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
> gEfiEdkNt32PkgTokenSpaceGuid.PcdWinNtPhysicalDisk|L"E:RW;245760;512"|VOID*|32
> ```
>
> -#### 2.9.2.2 PcdsPatchableInModule
> +#### 2.8.2.2 PcdsPatchableInModule
>
> The `PatchableInModule` PCD access method can be used with modules that are
> distributed in binary form. The PCD's value can be patched by tools that know
> the offset of the PCD into the binary file.
>
> @@ -163,11 +163,11 @@ Format of an entry in this section is:
> ```ini
> [PcdsPatchableInModule.common]
> gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000000|UINT32|4
> ```
>
> -### 2.9.3 [PcdsDynamic*] and [PcdsDynamicEx*] sections
> +### 2.8.3 [PcdsDynamic*] and [PcdsDynamicEx*] sections
>
> PCDs listed in these sections cannot be used in conditional directive
> statements.
>
> The Dynamic PCD access method cannot be used for modules that are distributed
> @@ -185,11 +185,11 @@ binary image supports multiple SKUs. The SKU selection based on things like a
> hardware jumper, or some other method that is outside the scope of this
> document.
>
> For using the standard PCD Get/Set PPI or Protocol.
>
> -#### 2.9.3.1 PcdsDynamicDefault
> +#### 2.8.3.1 PcdsDynamicDefault
>
> The Dynamic Default PCD access method will generate a volatile variable that
> can be accessed at runtime using PCD a Get PPI or Protocol.
>
> ```ini
> @@ -213,11 +213,11 @@ The format for a VOID* PCD entry in this section is:
> [PcdsDynamicDefault]
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0
> ```
>
> -#### 2.9.3.2 PcdsDynamicHII
> +#### 2.8.3.2 PcdsDynamicHII
>
> The Dynamic Hii PCD access method will generate HII data content that can be
> accessed at runtime.
>
> For using the HII for PCD data, the section name is as follows:
> @@ -259,11 +259,11 @@ described in the following table.
>
> [PcdsDynamicHii.common.DEFAULT]
> gEfiMdeModulePkgTokenSpaceGuid.PcdValidRange|L"PcdValidRange"|gEfiGlobalVariableGuid|0x07|0|BS,RT,NV
> ```
>
> -#### 2.9.3.3 PcdsDynamicVpd
> +#### 2.8.3.3 PcdsDynamicVpd
>
> The Dynamic Vpd PCD access method will generate macros that allow the data
> content (stored in read-only memory) to be accessed at runtime. Note that the
> PCD drivers may use a copy of the VPD data to allow runtime changes to these
> variables.
> @@ -296,11 +296,11 @@ The format for VOID* datum type content in this section is:
> gNoSuchTokenSpaceGuid.PcdOemBootOptionName | 0x22D4 | 100 | " " # VOID*
> gNoSuchTokenSpaceGuid.PcdOemBootOptionPath | 0x2338 | 100 | " " # VOID*
> gNoSuchTokenSpaceGuid.PcdEnableFastBoot | 0x239C | 1 | FALSE # BOOLEAN
> ```
>
> -#### 2.9.3.4 PcdsDynamicExDefault
> +#### 2.8.3.4 PcdsDynamicExDefault
>
> The DynamicEx access method of PCD is recommended for modules that are
> distributed in binary form.
>
> Entries for `DynamicEx` are identical to the `Dynamic` entries. The `DynamicEx`
> @@ -327,11 +327,11 @@ The format for a VOID* PCD entry in this section is:
> [PcdsDynamicExDefault.common.DEFAULT]
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0
> ```
>
> -#### 2.9.3.5 PcdsDynamicEx Hii
> +#### 2.8.3.5 PcdsDynamicEx Hii
>
> For using the HII for PCD data, the section name is as follows:
>
> `[PcdsDynamicExHii.$(arch).$(SKUID_IDENTIFIER)]`
>
> @@ -357,11 +357,11 @@ described in Table 9 HII Attributes.
>
> [PcdsDynamicExHii.common.DEFAULT]
> gEfiMdeModulePkgTokenSpaceGuid.PcdValidRange|L"PcdValidRange"|gEfiGlobalVariableGuid|0x07|0|BS,RT,NV
> ```
>
> -#### 2.9.3.6 PcdsDynamicExVpd
> +#### 2.8.3.6 PcdsDynamicExVpd
>
> For using the VPD for PCD data, the section name is:
>
> `[PcdsDynamicExVpd.$(arch).$(SKUID_IDENTIFIER)]`
>
> diff --git a/2_dsc_overview/210_pcd_database.md b/2_dsc_overview/29_pcd_database.md
> similarity index 96%
> rename from 2_dsc_overview/210_pcd_database.md
> rename to 2_dsc_overview/29_pcd_database.md
> index 2e4380c..ab3fda5 100644
> --- a/2_dsc_overview/210_pcd_database.md
> +++ b/2_dsc_overview/29_pcd_database.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 2.10 PCD Database
>
> - 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 2.10 PCD Database
> +## 2.9 PCD Database
>
> Dynamic and DynamicEx PCDs can be modified during the boot/setup stages. In
> order to support modifications, a PEIM and a DXE driver use databases of these
> PCDs so that changes can persist across reboots. These databases are generated
> prior to the final image assembly. The following rules determine when the build
> diff --git a/3_edk_ii_dsc_file_format/311_[components]_sections.md b/3_edk_ii_dsc_file_format/310_[components]_sections.md
> similarity index 81%
> rename from 3_edk_ii_dsc_file_format/311_[components]_sections.md
> rename to 3_edk_ii_dsc_file_format/310_[components]_sections.md
> index b8e2875..abca3e9 100644
> --- a/3_edk_ii_dsc_file_format/311_[components]_sections.md
> +++ b/3_edk_ii_dsc_file_format/310_[components]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.11 [Components] 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.11 [Components] Sections
> +## 3.10 [Components] Sections
>
> The `[Components]` sections are required.
>
> #### Summary
>
> @@ -42,12 +42,11 @@ files.
> The `!include` statement is permitted in `[Components]` sections. however this
> method is NOT recommended.
>
> All EDK II file paths must be specified relative to a directory containing EDK
> II Packages (as specified by the WORKSPACE or a directory listed in
> -PACKAGES_PATH system environment variable). EDK INF component and library files
> -may use `$(EDK_SOURCE)` or `$(EFI_SOURCE)` global environment variables. If the
> +PACKAGES_PATH system environment variable). If the
> environment variable is not specified, the INF file path is assumed to be
> relative to the `WORKSPACE`.
>
> The following is an example of specifying a `WORKSPACE` (MdeModulePkg is in the
> directory pointed to by the WORKSPACE environment variable) relative Path:
> @@ -55,11 +54,11 @@ directory pointed to by the WORKSPACE environment variable) relative Path:
> `MdeModulePkg/Universal/Disk/DiskIo/Dxe`
>
> The following is an example of specifying an Indirect Path:
>
> ```ini
> -DEFINE FOUNDATION_LIB = $(EDK_SOURCE)/Foundation/Library
> +DEFINE FOUNDATION_LIB = $(WORKSPACE)/Foundation/Library
> $(FOUNDATION_LIB)/EdkIIGlueLib/EntryPoints
> ```
>
> The permitted `DEFINE` statement must be a variable name assigned to a path.
>
> @@ -91,13 +90,10 @@ value, while the `<PcdsFixedAtBuild>` section of an INF use a different value.
> The FeatureFlag PCD and the two dynamic forms of PCDs are common to a platform,
> with the dynamic form PCD values stored in a "runtime database", read-only
> memory location or an HII data store. Therefore, having different values is
> prohibited for these access methods.
>
> -EDK components may have the scoped sub-element, `<SOURCE_OVERRIDE_PATH>` that
> -is used to virtually replace files in the component's directory.
> -
> The format for items listed in the sub-elements is the identical format for
> content under the section.
>
> Within the context of an EDK II module sub-element, the `<LibraryClasses>`
> entries must appear before `<Pcds*>` entries; the `<LibraryClasses>` entries
> @@ -128,20 +124,16 @@ modules in a binary image (the FDF file describes that ordering).
> <attribs> ::= <attrs> ["," <TS> "Components" <attrs>]*
> <attrs> ::= "." <arch>
> <ModuleStatements> ::= {<MacroDefinition>}
> {<IncludeStatement>} {<TS> <InfFiles>}
> <InfFiles> ::= <InfFilename> [<MTS> <Options>] <EOL>
> -<Options> ::= {<Exec>} {<Edk2Struct>} {<EdkStruct>}
> +<Options> ::= {<Exec>} {<Edk2Struct>}
> <InfFilename> ::= <PATH> <Word> ".inf"
> <Exec> ::= "EXEC" <Eq> <ExecFilename>
> <ExecFilename> ::= <PATH> <Word> ["." <ExecExtension>]
> <ExecExtension> ::= <Word> # An OS recognisable extension that will #
> automatically be run.
> -<EdkStruct> ::= "{" <EOL>
> - <TS> "<SOURCE_OVERRIDE_PATH>" <EOL>
> - <TS> <PATH>
> - <TS> "}" <EOL>
> <Edk2Struct> ::= "{" <EOL>
> [<TS> <DefSec>]
> [<TS> <LibraryClasses>]
> [<TS> <PcdsFeatureFlag>]
> [<TS> <PcdsFixed>]
> @@ -267,49 +259,5 @@ individual modules.
>
> **_ClassName_**
>
> A Library Class Keyword defined in DEC files. The Keyword must also be present
> in the defines section `LIBRARY_CLASS` entry of the INF file
> -
> -#### Example Using EDK components in an EDK II DSC build
> -
> -```
> -[Components]
> -DEFINE EDK=$(EDK_SOURCE)/Edk
> -DEFINE MDE=MdePkg/Library
> -DEFINE STATUS_CODE=$(MDE)/PeiDxeDebugLibReportStatusCode
> -
> -$(EDK)/Foundation/Core/Pei/PeiMain.inf
> -DEFINE NT32 = $(EDK)/Sample/Platform
> -$(NT32)/Generic/MonoStatusCode/Pei/Nt32/MonoStatusCode.inf
> -$(NT32)/Nt32/Pei/BootMode/BootMode.inf
> -$(NT32)/Nt32/Pei/FlashMap/FlashMap.inf
> -MdeModulePkg/Core/Dxe/DxeMain.inf
> -...
> -MdeModulePkg/Universal/Debugger/Debugport/Dxe/DebugPort.inf
> -MdeModulePkg/Cpu/DebugSupport/Dxe/DebugSupport.inf
> -...
> -
> -DEFINE MDEMODUNI = MdeModulePkg/Universal
> -$(MDEMODUNI)/DataHub/DataHubStdErr/Dxe/DataHubStdErr.inf
> -MdeModulePkg/Universal/Disk/DiskIo/Dxe/DiskIo.inf {
> - <LibraryClasses>
> - DebugLib|$(STATUS_CODE)/PeiDxeDebugLibReportStatusCode.inf
> - BaseMemoryLib|$(MDE)/DxeMemoryLib/DxeMemoryLib.inf
> - MemoryAllocationLib|$(MDE)/DxeMemoryAllocationLib/DxeMemoryAllocationLib.inf
> - <PcdsFeatureFlag>
> - PcdDriverDiagnosticsDisable|gEfiMdePkgTokenSpaceGuid|FALSE
> -}
> -MdeModulePkg/Universal/Ebc/Dxe/Ebc.inf
> -$(MDEMODUNI)/GenericMemoryTest/Dxe/NullMemoryTest.inf
> -$(MDEMODUNI)/StatusCode/Pei/PeiStatusCode.inf {
> - <BuildOptions>
> - MSFT:RELEASE_MYTOOLS_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
> - DEBUG_MYTOOLS_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
> - DEBUG_WINDDK3790x1830_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
> - RELEASE_WINDDK3790x1830_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
> - DEBUG_VS2003_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
> - RELEASE_VS2003_IA32_DLINK_FLAGS = Kernel32.lib MSVCRTD.lib Gdi32.lib User32.lib Winmm.lib
> -}
> -MdeModulePkg/Logo/Logo.inf
> -...
> -```
> diff --git a/3_edk_ii_dsc_file_format/312_[userextensions]_sections.md b/3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
> similarity index 94%
> rename from 3_edk_ii_dsc_file_format/312_[userextensions]_sections.md
> rename to 3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
> index 6020c5c..504fa9f 100644
> --- a/3_edk_ii_dsc_file_format/312_[userextensions]_sections.md
> +++ b/3_edk_ii_dsc_file_format/311_[userextensions]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.12 [UserExtensions] 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.12 [UserExtensions] Sections
> +## 3.11 [UserExtensions] Sections
>
> The `[UserExtensions]` sections are optional.
>
> #### Summary
>
> diff --git a/3_edk_ii_dsc_file_format/313_[defaultstores]_section.md b/3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
> similarity index 93%
> rename from 3_edk_ii_dsc_file_format/313_[defaultstores]_section.md
> rename to 3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
> index 23dec7d..dfa7fa8 100644
> --- a/3_edk_ii_dsc_file_format/313_[defaultstores]_section.md
> +++ b/3_edk_ii_dsc_file_format/312_[defaultstores]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.13 [DefaultStores] Section
>
> - 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.13 [DefaultStores] Section
> +## 3.12 [DefaultStores] Section
>
> The `[DefaultStores]` section is optional in all EDK II DSC files.
>
> #### Summary
>
> diff --git a/3_edk_ii_dsc_file_format/32_general_rules.md b/3_edk_ii_dsc_file_format/32_general_rules.md
> index e040abc..d0cdb9b 100644
> --- a/3_edk_ii_dsc_file_format/32_general_rules.md
> +++ b/3_edk_ii_dsc_file_format/32_general_rules.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.2 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:
>
> @@ -118,16 +118,5 @@ is unknown.
>
> Unless otherwise noted, all file names and paths are relative EDK II Packages
> (subdirectories in directories pointed to by WORKSPACE or PACKAGES_PATH system
> environment variables). A directory name that starts with a word is assumed by
> the build tools to be an EDK II Package directory name.
> -
> -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_dsc_file_format/33_platform_dsc_definition.md b/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
> index 07f10d6..0679ff0 100644
> --- a/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
> +++ b/3_edk_ii_dsc_file_format/33_platform_dsc_definition.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.3 Platform DSC 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:
>
> @@ -45,24 +45,21 @@ PatchableInModule or DynamicEx PCDs.
> specified in the `[Defines]` section or SET statements.
> **********
>
> The `[Defines]` section must appear before any other sections (except the
> header comment blocks). The remaining sections may appear in any order, however
> -the EBNF, below, shows the recommended order. (The `[Libraries]` section is
> -required if building EDK libraries and components in the context of an EDK II
> -platform.)
> +the EBNF, below, shows the recommended order.
>
> #### Summary
>
> The EDK II Platform Description (DSC) file has the following format (using the
> EBNF).
>
> ```c
> <EDK_II_DSC> ::= [<Header>]
> <Defines>
> [<SkuIds>]
> - <Libraries>*
> <LibraryClasses>*
> <Pcds>*
> <Components>+
> <BuildOptions>*
> <UserExtensions>*
> @@ -377,12 +374,11 @@ Highest Priority
> 3. Macros defined in the DSC file's `[Defines]` section
>
> Lowest Priority
>
> Macros defined in the `[Defines]` section are considered global during the
> -processing of the FDF file and the DSC file. `EDK_GLOBAL` macros are considered
> -global during the processing of DSC, FDF and EDK INF files.
> +processing of the FDF file and the DSC file.
>
> Macros are not allowed to redefine the reserved words specified in this file.
> For example, it is not permitted to `DEFINE DEFINE = FOOBAR`, then use `FOOBAR`
> as a the reserved word.
>
> @@ -406,13 +402,12 @@ may report the error on the line that uses the macro, `$(MACRO)`, rather than
> where the macro was defined.
>
> #### Prototype
>
> ```c
> -<MacroDefinition> ::= {<NormalMacro>} {<EdkMacro>}
> +<MacroDefinition> ::= {<NormalMacro>}
> <NormalMacro> ::= <TS> "DEFINE" <MTS> <MACRO> <Eq> [<Value>] <EOL>
> -<EdkMacro> ::= <TS> "EDK_GLOBAL" <MTS> <MACRO> <Eq> [<Value>] <EOL>
> <Value> ::= {<Number>} {<BoolType>} {<GUID>}
> {<CString>} {<UnicodeString>} {<CArray>}
> {<PATH>} {<Expression>} {<CFlags>}
> {<RelativePath>} {<Filename>}
> ```
> @@ -449,11 +444,10 @@ defined in this file may be used in the Flash FDF file.
>
> ```
> DEFINE GEN_SKU = MyPlatformPkg/GenPei
> DEFINE SKU1 = MyPlatformPkg/Sku1/Pei
> DEFINE HACK = DEBUG
> -EDK_GLOBAL EFI_ACPI_TABLE_STORAGE_GUID = 7E374E25-8E01-4FEE-87F2390C23C606CD
> ```
>
> ### 3.3.3 Conditional Directive Blocks
>
> Use of conditional directive blocks is optional.
> @@ -697,12 +691,11 @@ in the DSC file. The included file's content must match the content of the
> section that the `!include` statement resides, or it may contain completely new
> sections. If the included file starts with a section header, then the section
> being processed in the Platform DSC file is considered to have been terminated.
>
> If the `<Filename>` contains "$" characters, then macros defined in the DSC
> -file and the system environment variables, `$(WORKSPACE)`, `$(EDK_SOURCE)`,
> -`$(EFI_SOURCE)`, and `$(ECP_SOURCE)` are substituted into `<Filename>`.
> +file and the system environment variable `$(WORKSPACE)` are substituted into `<Filename>`.
>
> The tools look for `<Filename>` relative to the directory the DSC file resides.
> If the file is not found, and a directory separator is in `<Filename>`, the
> tools attempt to find the file in a WORKSPACE (or a directory listed in the
> PACKAGES_PATH) relative path. If the file cannot be found, the build system
> diff --git a/3_edk_ii_dsc_file_format/35_[defines]_section.md b/3_edk_ii_dsc_file_format/35_[defines]_section.md
> index 7337415..ea2077d 100644
> --- a/3_edk_ii_dsc_file_format/35_[defines]_section.md
> +++ b/3_edk_ii_dsc_file_format/35_[defines]_section.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.5 [Defines] Section
>
> - 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:
>
> @@ -179,19 +179,10 @@ specifying the three language codes in this statement will limit the final
> output of string parsing tools to strings for these three languages. Tools must
> use a "Get Best Language" function when filtering the content. The
> `RFC_LANGUAGES` statement must be used when processing EDK II Modules. Space
> characters are not permitted within the list.
>
> -**_ISO 639-2 Language Code_**
> -
> -One or more three character language codes, formatted per ISO 639-2, with no
> -separator character (for example: "engfraspa".) This list can be used to filter
> -the output of tools that generate unicode strings. Tools must use a "Get Best
> -Language" function when filtering the content. The `ISO_LANGUAGES` statement
> -must be used when processing EDK Components. Space characters are not permitted
> -within the list.
> -
> **_BuildNumber_**
>
> This value, if present, will be used during the creation of
> `EFI_SECTION_VERSION` sections. Values in this file override any values set in
> the INF files. If not present, the EDK II build tools must use a value of `0`.
> @@ -225,8 +216,7 @@ compiling them into a machine language program.
> OUTPUT_DIRECTORY = Build/Nt32
> SUPPORTED_ARCHITECTURES = IA32
> BUILD_TARGETS = DEBUG|RELEASE
> RFC_LANGUAGES = "en-us;
> zh-hans;fr-fr"
> - ISO_LANGUAGES = "engchnfra"
> SKUID_IDENTIFIER = SkuTwo|DEFAULT
> ```
> diff --git a/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md b/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> index 71d778d..5f0a95c 100644
> --- a/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> +++ b/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.6 [BuildOptions] 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:
>
> @@ -49,16 +49,15 @@ expectation is that other tools will be responsible for expanding the macro.
> This section is used to replace flags or append flags to the end of the tool
> code flags defined in the `tools_def.txt` file. The `Family` tag can be used
> for elements that are shared between different architectures, and different
> tool chain tag names.
>
> -The `[BuildOptions]` section modifier, CodeBase, (value of EDK or EDKII,
> -default is EDKII) allows for platform integrators to override default build
> +The `[BuildOptions]` section modifier, CodeBase, (value is EDKII) allows for
> +platform integrators to override default build
> options set in the `tools_def.txt` file scoped according to the type of INF
> file being processed. EDK II INF files all contain an `INF_VERSION` element in
> -their `[Defines]` section, while EDK libraries and components do not have the
> -element. The `[BuildOptions]` section of an INF file override both the
> +their `[Defines]` section. The `[BuildOptions]` section of an INF file override both the
> `tools_def.txt` options and the options set in the `[BuildOptions]` section. In
> order to override options set in the INF file, the options must be overridden
> using the INF scoped `<BuildOptions>` tag after an INF file specified in the
> `[Components]` section.
>
> @@ -167,27 +166,27 @@ The result would logically be: `*_*_*_TEST_FLAGS = /a /b`
> ```
>
> The result for EDK II modules would be: `*_*_*_TEST_FLAGS = /a /b /c`
>
> ```ini
> -[BuildOptions.common.EDK]
> - # Entries are for EDK components and libraries
> +[BuildOptions.common.EDKII]
> + # Entries are for EDK II components and libraries
> *_*_*_TEST_FLAGS = /d
> ```
>
> -The result for EDK components and libraries would be: `*_*_*_TEST_FLAGS = /a /b /d`
> +The result for EDKII components and libraries would be: `*_*_*_TEST_FLAGS = /a /b /d`
>
> ```ini
> [BuildOptions.IA32]
> # Architectural options for IA32
> *_*_*_TEST_FLAGS = /e
> ```
>
> The logical result is: `*_*_IA32_TEST_FLAGS = /a /b /c /e`
>
> ```ini
> -[BuildOptions.X64.EDK]
> +[BuildOptions.X64.EDKII]
> # Architectural options for X64
> *_*_*_TEST_FLAGS = /f
> DEBUG_*_*_TEST_FLAGS = /g
> RELEASE_*_*_TEST_FLAGS = /h
> ```
> @@ -220,11 +219,11 @@ The logical result is:
> #### Prototype
>
> ```c
> <BuildOptions> ::= "[BuildOptions" [<attribs>] "]" <EOL> <Statements>*
> <attribs> ::= "." <arch> [<CodeBase> ["." <ModuleType>]]
> -<CodeBase> ::= "." {"Common"} {"EDK"} {"EDKII"}
> +<CodeBase> ::= "." {"Common"} {"EDKII"}
> <Statements> ::= {<MacroDefinition>} {<IncludeStatement>}
> {<TS> <BStatement>}
> <BStatement> ::= {<ToolFlag>} {<ToolPath>} {<ToolCmd>} {<Other>}
> <ToolFlag> ::= [<Family> ":"] <FlagSpec> <Equal> <Flags> <EOL>
> <ToolPath> ::= [<Family> ":"] <PathSpec> <Equal> <PATH> <EOL>
> diff --git a/3_edk_ii_dsc_file_format/38_[libraries]_sections.md b/3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> deleted file mode 100644
> index 23c441c..0000000
> --- a/3_edk_ii_dsc_file_format/38_[libraries]_sections.md
> +++ /dev/null
> @@ -1,94 +0,0 @@
> -<!--- @file
> - 3.8 [Libraries] 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.
> -
> --->
> -
> -## 3.8 [Libraries] Sections
> -
> -The section `[Libraries]` sections are optional in EDK II DSC files, although
> -if any EDK component is specified in the `[Components]` section, then the EDK
> -II DSC file must contain this section. EDK components can not use EDK II
> -Library Instances.
> -
> -#### Summary
> -
> -Defines the `[Libraries]` section tag which lists the libraries that are linked
> -against
> -
> -EDK I components. Entries may appear in any order. Entries for EDK are a list
> -of INF files, with a path that is relative to the `$(EFI_SOURCE)`,
> -`$(EDK_SOURCE)` or `$(ECP_SOURCE)` directories (or a MACRO definition).
> -
> -One or more `!include` statements may be used within the libraries sections. If
> -used, the file included must be a list of INF files and their paths relative to
> -the `$(EFI_SOURCE)`, `$(EDK_SOURCE)` or `$(ECP_SOURCE)` directories.
> -
> -#### Prototype
> -
> -```c
> -<Libraries> ::= "[Libraries" [<attribs>] "]" <EOL> <LibStatements>*
> -<LibStatements> ::= {<MacroDefinition>} {<IncludeStatement>}
> - {<Statement>}
> -<attribs> ::= "." <arch> [", Libraries." <arch>]*
> -<Statement> ::= <TS> <PathAndFilename> <EOL>
> -<PathAndFilename> ::= <LPATH> <Word> ".inf"
> -<LPATH> ::= [{"$(EDK_SOURCE)"} {<MACROVAL>} "/"] <Path>*
> -<Path> ::= <Word> "/"
> -```
> -
> -#### Parameters
> -
> -**_arch_**
> -
> -The arch attribute must be specified in the `Conf/tools_def.txt` file for the
> -tool chain used to build the platform in order to be valid.
> -
> -**_Path_**
> -
> -If only the `<Path>` element is specified, the path is `WORKSPACE` relative.
> -
> -#### Example
> -
> -```ini
> -[Libraries]
> - Foundation/Efi/Guid/EfiGuidLib.inf
> - Foundation/Framework/Guid/EdkFrameworkGuidLib.inf
> - Foundation/Guid/EdkGuidLib.inf
> - Foundation/Library/EfiCommonLib/EfiCommonLib.inf
> - Foundation/Cpu/Pentium/CpuIA32Lib/CpuIA32Lib.inf
> - Foundation/Cpu/Itanium/CpuIA64Lib/CpuIA64Lib.inf
> - Foundation/Library/CustomizedDecompress/CustomizedDecompress.inf
> -
> -[Libraries.IA32]
> - DEFINE PLATFORM_DIR = $(EDK_SOURCE)/Platform
> - $(PLATFORM_DIR)/IntelEpg/Guid/IntelEpgGuidLib.inf
> - $(PLATFORM_DIR)/IntelEpg/Ppi/IntelEpgPpiLib.inf
> - $(PLATFORM_DIR)/Generic/Guid/GenericGuidLib.inf
> - $(PLATFORM_DIR)/Generic/Lib/Port80MappingLib/PlatformPort80.inf
> -```
> diff --git a/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md b/3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
> similarity index 95%
> rename from 3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> rename to 3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
> index 9ac3878..cc9f96e 100644
> --- a/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> +++ b/3_edk_ii_dsc_file_format/38_[libraryclasses]_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.9 [LibraryClasses] 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.9 [LibraryClasses] Sections
> +## 3.8 [LibraryClasses] Sections
>
> The `[LibraryClasses]` sections are optional if no library classes are defined
> for any of the components, or if only EDK modules are used.
>
> #### Summary
> diff --git a/3_edk_ii_dsc_file_format/310_pcd_sections.md b/3_edk_ii_dsc_file_format/39_pcd_sections.md
> similarity index 97%
> rename from 3_edk_ii_dsc_file_format/310_pcd_sections.md
> rename to 3_edk_ii_dsc_file_format/39_pcd_sections.md
> index f982d60..96e4f0e 100644
> --- a/3_edk_ii_dsc_file_format/310_pcd_sections.md
> +++ b/3_edk_ii_dsc_file_format/39_pcd_sections.md
> @@ -1,9 +1,9 @@
> <!--- @file
> 3.10 PCD 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:
>
> @@ -27,11 +27,11 @@
> OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
> -->
>
> -## 3.10 PCD Sections
> +## 3.9 PCD Sections
>
> The PCD sections are optional.
>
> PCD Values listed in the DSC file must be absolute values, macro names or
> expressions which may include other PCD names and/or macro names that have been
> @@ -111,11 +111,11 @@ PCDs with a C strucutre type is also a VOID* PCD. Its value can be specified lik
> normal VOID* PCD, and also be specified by its structure field.
>
> Refer to the _EDK II Build Specification_ for the description of the PCD
> processing rules.
>
> -### 3.10.1 [PcdsFeatureFlag] Sections
> +### 3.9.1 [PcdsFeatureFlag] Sections
>
> These are optional sections for EDK II DSC Files.
>
> #### Summary
>
> @@ -192,11 +192,11 @@ section tag can only be used as a conditional modifier.
> `SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
> must break, stating that this platform requires separate builds for individual
> `SkuId`s.
> **********
>
> -### 3.10.2 [PcdsFixedAtBuild] Section
> +### 3.9.2 [PcdsFixedAtBuild] Section
>
> These are optional sections for EDK II DSC Files.
>
> #### Summary
>
> @@ -298,11 +298,11 @@ must be used.
> `SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
> must break, stating that this platform requires separate builds for individual
> `SkuId`s.
> **********
>
> -### 3.10.3 [PcdsPatchableInModule] Sections
> +### 3.9.3 [PcdsPatchableInModule] Sections
>
> These are optional sections.
>
> #### Summary
>
> @@ -403,11 +403,11 @@ must be used.
> `SKUID_IDENTIFER` element exists in the `[Defines]` section, the build
> must break, stating that this platform requires separate builds for individual
> `SkuId`s.
> **********
>
> -### 3.10.4 [PcdsDynamic] Sections
> +### 3.9.4 [PcdsDynamic] Sections
>
> These are optional sections.
>
> #### Summary
>
> @@ -632,11 +632,11 @@ the _UEFI Specification_ for a description of these attributes.
> [PcdsDynamicHii.IA32, PcdsDynamicHii.X64.Sku1.Standard]
> gEfiMyModulePkgTokenSpaceGuid.PcdChassisIntrution|L"TestVariable"|gSysConfigGuid|0x83|0x0
> gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|10 # Variable:
> L"Timeout"
> ```
>
> -### 3.10.5 [PcdsDynamicEx] Sections
> +### 3.9.5 [PcdsDynamicEx] Sections
>
> These are optional sections.
>
> #### Summary
>
> --
> 2.20.1.windows.1
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-03-06 8:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-05 3:48 [Patch] Document: Update DSC spec to remove EDK related contents Feng, Bob C
2019-03-05 15:24 ` Carsey, Jaben
2019-03-06 8:31 ` Gao, Liming
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox