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.f...@intel.com>; Gao, Liming <liming....@intel.com>; 
> Carsey, Jaben <jaben.car...@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.f...@intel.com>
> Cc: Liming Gao <liming....@intel.com>
> Cc: Jaben Carsey <jaben.car...@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

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to