Re: [Patch] DSC Spec: Correct expression operator, update some typo and remove IPF

["Gao, Liming" <liming.gao@intel.com>]

Reviewed-by: Liming Gao <liming.gao@intel.com>

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Yonghong Zhu
> Sent: Wednesday, August 22, 2018 12:15 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Shaw, Kevin W <kevin.w.shaw@intel.com>; Gao, Liming <liming.gao@intel.com>
> Subject: [edk2] [Patch] DSC Spec: Correct expression operator, update some typo and remove IPF
> 
> 1. Update the Table 5 about the expression operator
> 2. Update some typo and remove some not used items
> 3. Remove IPF
> 
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Michael Kinney <michael.d.kinney@intel.com>
> Cc: Kevin W Shaw <kevin.w.shaw@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
> ---
>  .../211_[components]_section_processing.md         |  3 +-
>  2_dsc_overview/22_build_description_file_format.md | 32 +++++++++--------
>  2_dsc_overview/24_[buildoptions]_section.md        |  2 +-
>  .../26_[libraries]_section_processing.md           |  1 -
>  .../27_[libraryclasses]_section_processing.md      |  1 -
>  2_dsc_overview/28_pcd_section_processing.md        | 13 ++++---
>  2_dsc_overview/29_pcd_sections.md                  | 10 +++---
>  3_edk_ii_dsc_file_format/310_pcd_sections.md       | 42 ++++++++++++++--------
>  .../311_[components]_sections.md                   |  2 +-
>  .../33_platform_dsc_definition.md                  | 39 +++++++-------------
>  .../36_[buildoptions]_sections.md                  |  4 +--
>  .../39_[libraryclasses]_sections.md                |  2 +-
>  README.md                                          |  2 +-
>  13 files changed, 76 insertions(+), 77 deletions(-)
> 
> diff --git a/2_dsc_overview/211_[components]_section_processing.md b/2_dsc_overview/211_[components]_section_processing.md
> index 0adffd5..140f09c 100644
> --- a/2_dsc_overview/211_[components]_section_processing.md
> +++ b/2_dsc_overview/211_[components]_section_processing.md
> @@ -1,9 +1,9 @@
>  <!--- @file
>    2.11 [Components] Section Processing
> 
> -  Copyright (c) 2006-2017, Intel Corporation. All rights reserved.<BR>
> +  Copyright (c) 2006-2018, Intel Corporation. All rights reserved.<BR>
> 
>    Redistribution and use in source (original document form) and 'compiled'
>    forms (converted to PDF, epub, HTML and other formats) with or without
>    modification, are permitted provided that the following conditions are met:
> 
> @@ -38,11 +38,10 @@ new scoping capabilities.
>  This section uses one or more of the following section definitions:
> 
>  * `[Components]`
>  * `[Components.IA32]`
>  * `[Components.X64]`
> -* `[Components.IPF]`
>  * `[Components.EBC]`
>  * `[Components.common]`
> 
>  EDK components are specified using a fully qualified path to the EDK INF file.
> 
> diff --git a/2_dsc_overview/22_build_description_file_format.md b/2_dsc_overview/22_build_description_file_format.md
> index 1ce890f..9bf46a6 100644
> --- a/2_dsc_overview/22_build_description_file_format.md
> +++ b/2_dsc_overview/22_build_description_file_format.md
> @@ -56,11 +56,11 @@ This description file consists of sections delineated by section tags enclosed
>  within square `[]` brackets. Section tag entries are case-insensitive. The
>  different sections and their usage are described below. The text of a given
>  section can be used for multiple section names by separating the section names
>  with a comma. For example:
> 
> -`[LibraryClasses.X64, LibraryClasses.ipf]`
> +`[LibraryClasses.X64, LibraryClasses.EBC]`
> 
>  The content below each section heading is processed by the parsing utilities in
>  the order that they occur in the file. The precedence for processing these
>  architecture section tags is from right to left, with sections defining an
>  architecture having a higher precedence than a section which uses common (or no
> @@ -181,14 +181,14 @@ case sensitive because of multiple environment support.
>    underscore characters and start with an alpha character. A single period
>    character is permitted in the name provided that alphanumeric characters
>    appear before and after the period character (as in: _MdePkg.1_).
> 
>  * Additionally, all EDK II directories that are architecturally dependent must
> -  use a name with only the first character capitalized. _Ia32_, _Ipf_, _X64_
> -  and _Ebc_ are valid architectural directory names. IA32, IPF and EBC are not
> -  acceptable directory names, and may cause build breaks. From a build tools
> -  perspective, IA32 is not equivalent to Ia32 or ia32.
> +  use a name with only the first character capitalized. _Ia32_, _X64_ and _Ebc_
> +  are valid architectural directory names. IA32, X64 and EBC are not acceptable
> +  directory names, and may cause build breaks. From a build tools perspective,
> +  IA32 is not equivalent to Ia32 or ia32.
> 
>  The build tools must be able to process the tool definitions file:
>  `tools_def.txt` (describing the location and flags for compiler and user
>  defined tools), which may contain space characters in paths on Windows* systems.
> 
> @@ -200,14 +200,14 @@ places that permit the use of space characters in a directory path.
>  The EDK II Coding Style specification covers naming conventions for use within
>  C Code files, and as well as specifying the rules for directory and file names.
>  This section is meant to highlight those rules as they apply to the content of
>  the INF files.
> 
> -Architecture keywords (`IA32`, `IPF`, `X64` and `EBC`) are used by build tools
> +Architecture keywords (`IA32`, `X64` and `EBC`) are used by build tools
>  and in metadata files for describing alternate threads for processing of files.
>  These keywords must not be used for describing directory paths. Additionally,
> -directory names with architectural names (_Ia32_, _Ipf_, _X64_ and _Ebc_) do
> +directory names with architectural names (_Ia32_, _X64_ and _Ebc_) do
>  not automatically cause the build tools or meta-data files to follow these
>  alternate paths. Directories and Architectural Keywords are similar in name
>  only.
> 
>  All directory paths within EDK II INF files must use the "/" forward slash
> @@ -471,11 +471,11 @@ follow the same rules as architectural modifiers.
>  [LibraryClasses.X64.PEIM]
>    # Can use $(MDE) and $(PERF)
>    DEFINE MDEMEM = $(MDE)/PeiMemoryAllocationLib
>    MemoryAllocationLib|$(MDEMEM)/PeiMemoryAllocationLib.inf
> 
> -[LibraryClasses.IPF]
> +[LibraryClasses.EBC]
>    # Cannot use $(PERF) or $(MDEMEM)
>    # Can use $(MDE) from the common section
>    PalLib|$(MDE)/UefiPalLib/UefiPalLib.inf
>    TimerLib|$(MDE)/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
>  ```
> @@ -674,20 +674,24 @@ be tested as a string.
> 
>  ###### Table 5 Operator Precedence and Supported Operands
> 
>  | Operator                                     | Use with Data Types   | Notes
> | Priority |
>  | -------------------------------------------- | --------------------- |
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> -------------------------------------------- | -------- |
> -| `or`, `OR`, <code>&#124;&#124;</code>        | Number, Boolean       |
> | Lowest   |
> +| `? :`                                        | All                   | conditional operator
> | Lowest   |
> +| `or`, `OR`, <code>&#124;&#124;</code>        | Number, Boolean       |
> |          |
> +| `XOR`, `xor`                                 | Number, Boolean       |
> |          |
>  | `and`, `AND`, `&&`                           | Number, Boolean       |
> |          |
>  | <code>&#124;</code>                          | Number, Boolean       | Bitwise OR
> |          |
> -| `^`, `xor`, `XOR`                            | Number, Boolean       | Exclusive OR
> |          |
> +| `^`                                          | Number, Boolean       | Bitwise XOR
> |          |
>  | `&`                                          | Number, Boolean       | Bitwise AND
> |          |
>  | `==`, `!=`, `EQ`, `NE`, `IN`                 | All types             | The IN operator can only be used to test a quoted unary
> literal string for membership in a list.
> |          |
> -|                                              |                       | Space characters must be used before and
> after the letter operators Strings compared to boolean or numeric values using "==" or "EQ" will always return FALSE, while using the
> "!=" or "NE" operators will always return TRUE |          |
> -| `<=`, `>=`, `<`, `>`, `LE`, `GE`, `LT`, `GT` | All                   | Space characters must be used before and after the letter
> operators.
> |          |
> -| `+`, `-`                                     | Number, Boolean       | Cannot be used with strings - the system does not
> automatically do concatenation. Tools should report a warning message if these operators are used with both a boolean and number
> value                                      |          |
> -| `!`, `not`, `NOT`                            | Number, Boolean       |
> | Highest  |
> +|                                              |                       | Strings compared to boolean or numeric
> values using "==" or "EQ" will always return FALSE, while using the "!=" or "NE" operators will always return TRUE
> |          |
> +| `<=`, `>=`, `<`, `>`, `LE`, `GE`, `LT`, `GT` | All                   |
> |          |
> +| `<<`, `>>`                                   | Number, Boolean       |
> |          |
> +| `+`, `-`                                     | Number, Boolean       | Cannot be used with strings - the system does not
> automatically do concatenation.
> |          |
> +| `*`, `/`, `%`,                               | Number, Boolean       | Cannot be used with strings.
> |          |
> +| `!`, `not`, `NOT`, `~`                       | Number, Boolean       |
> | Highest  |
> 
>  The "IN" operator can only be used to test a literal string against elements
>  in the following global variables:
> 
>  **_$(FAMILY)_**
> diff --git a/2_dsc_overview/24_[buildoptions]_section.md b/2_dsc_overview/24_[buildoptions]_section.md
> index 1d33180..7d3d2d1 100644
> --- a/2_dsc_overview/24_[buildoptions]_section.md
> +++ b/2_dsc_overview/24_[buildoptions]_section.md
> @@ -60,11 +60,11 @@ Valid content is within this section is limited to the following description.
>  |             |          |          | By not specifying the FAMILY, the tools assume the flags are applicable to all families.
> |
>  | `TARGET`    | YES      | Yes = *  | `Conf/tools_def.txt` file defines two values:
> |
>  |             |          |          | DEBUG and RELEASE. Developers may define additional targets.
> |
>  | `TAGNAME`   | YES      | Yes = *  | `Conf/tools_def.txt` file defines several different tag names - these are defined by
> developers; the default tag name, MYTOOLS, is provided in the template for tools_def.txt and set in the `Conf/target.txt` file. |
>  | `ARCH`      | YES      | Yes = *  | `Conf/tools_def.txt` defines six architectures:
> |
> -|             |          |          | ARM, AARCH64, IA32, X64, IPF and EBC. This tag must use all capital letters for the tag.
> Additional Architectures, such as PPC may be added as support becomes available.
> |
> +|             |          |          | ARM, AARCH64, IA32, X64 and EBC. This tag must use all capital letters for the tag.
> Additional Architectures, such as PPC may be added as support becomes available.
> |
>  | `TOOLCODE`  | YES      | NO       | The tool code must be one of the defined tool codes in the `Conf/tools_def.txt` file. The
> flags defined in this section are appended to flags defined in the `tools_def.txt` file for individual tools.              |
>  |             |          |          | EXCEPTION: If the INF MODULE_TYPE, defined in the `[Defines]` section is
> `USER_DEFINED`, then the flags listed in this section are the only flags used for the
> |
>  |             |          |          | TOOLCODE command specified in Conf/tools_def.txt`.
> |
>  | `ATTRIBUTE` | YES      | NO       | The attribute must be specific to the tool code and must be a valid attribute handled by the
> build system. For the reference build, a valid rule must be included in the _build_rule.txt_.                           |
> 
> diff --git a/2_dsc_overview/26_[libraries]_section_processing.md b/2_dsc_overview/26_[libraries]_section_processing.md
> index 8a01025..82cda47 100644
> --- a/2_dsc_overview/26_[libraries]_section_processing.md
> +++ b/2_dsc_overview/26_[libraries]_section_processing.md
> @@ -56,11 +56,10 @@ This section will typically use one of the following section definitions:
> 
>  ```ini
>  [Libraries.common]
>  [Libraries.IA32]
>  [Libraries.X64]
> -[Libraries.IPF]
>  [Libraries.EBC]
>  ```
> 
>  The formats for entries in this section is:
> 
> diff --git a/2_dsc_overview/27_[libraryclasses]_section_processing.md b/2_dsc_overview/27_[libraryclasses]_section_processing.md
> index 14ac9c8..50bda93 100644
> --- a/2_dsc_overview/27_[libraryclasses]_section_processing.md
> +++ b/2_dsc_overview/27_[libraryclasses]_section_processing.md
> @@ -51,11 +51,10 @@ The following is the generic format for the specifying a section
> 
>  ```ini
>  [LibraryClasses]
>  [LibraryClasses.IA32]
>  [LibraryClasses.X64]
> -[LibraryClasses.IPF]
>  [LibraryClasses.EBC]
>  [LibraryClasses.common]
>  ```
> 
>  Format for entries in this section is as follows:
> diff --git a/2_dsc_overview/28_pcd_section_processing.md b/2_dsc_overview/28_pcd_section_processing.md
> index 4c5d952..a5d56b3 100644
> --- a/2_dsc_overview/28_pcd_section_processing.md
> +++ b/2_dsc_overview/28_pcd_section_processing.md
> @@ -41,11 +41,11 @@ There are five defined PCD access methods. The five access methods are:
>  PCDs.
> 
>  #### 2.8.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
> +`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
>  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
> @@ -79,11 +79,10 @@ The content in these sections is used for generating the `AutoGen.c` and
>  ```ini
>  [Pcds(PcdType)]
>  [Pcds(PcdType).common]
>  [Pcds(PcdType).IA32]
>  [Pcds(PcdType).X64]
> -[Pcds(PcdType).IPF]
>  [Pcds(PcdType).EBC]
>  ```
> 
>  ### 2.8.2 PCD Access Method Categories
> 
> @@ -126,11 +125,11 @@ for all other PCD data types.
> 
>  **********
>  **Warning:** A `FixedAtBuild` or `PatchableInModule` PCD may have a
>  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 IPF architectures. This will be declared in the EDK II
> +`UINT64` for X64 and EBC architectures. This will be declared in the EDK II
>  Package Declaration (DEC) File.
>  **********
> 
>  ### 2.8.3 PCD Section Usage
> 
> @@ -178,11 +177,11 @@ be specified within a single [] section tag.
>  #### Correct example
> 
>  ```ini
>  [PcdsFixedAtBuild.IA32]
>    gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FAL  SE
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
> 
>  [PcdsPatchableInModule.IA32]
>    gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000000
> 
>  [PcdsDynamicDefault.IA32]
> @@ -386,11 +385,11 @@ a PCD as `PcdsFixedAtBuild`, then all library instances that use that PCD must
>  also use the PCD as `PcdsFixedAtBuild` with the same value.
> 
>  Build Tools must detect missing PCD entries (PCD specified in an INF file, but
>  not in the DSC file) and search the DEC files in the EDK II Packages
>  (sub‐directories in directories pointed to by WORKSPACE or PACKAGES_PATH system
> -environment variables), in order to use the default value from the DEC file.PCD
> +environment variables), in order to use the default value from the DEC file. PCD
>  Values may be absolute (a number, string, etc.) a MACRO name or an expression.
>  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
> @@ -399,10 +398,14 @@ in expressions is also permitted.
>  #### 2.8.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
> +
> +* the string or array in the FDF file
> +
>  * the string or array in the DSC file
> 
>  * the string or array in the INF file
> 
>  * the string or array in the DEC file
> diff --git a/2_dsc_overview/29_pcd_sections.md b/2_dsc_overview/29_pcd_sections.md
> index b33026c..791125f 100644
> --- a/2_dsc_overview/29_pcd_sections.md
> +++ b/2_dsc_overview/29_pcd_sections.md
> @@ -33,11 +33,11 @@
> 
>  ### 2.9.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
> +character), and a Boolean value of either TRUE, FALSE, 1 or 0. The PCD name
>  and value entries are separated by the pipe "|" character.
> 
>  FeatureFlag PCDs can be used in conditional directive statements within the DSC
>  and FDF files. These PCDs may also be used to select execution paths in some
>  code routines. The build tools will generate a const variable for each
> @@ -55,11 +55,10 @@ omitted in these examples:
>  ```ini
>  [PcdsFeatureFlag]
>  [PcdsFeatureFlag.common]
>  [PcdsFeatureFlag.IA32]
>  [PcdsFeatureFlag.X64]
> -[PcdsFeatureFlag.IPF]
>  [PcdsFeatureFlag.EBC]
>  ```
> 
>  Format of an entry in this section is:
> 
> @@ -105,11 +104,10 @@ The following are typical examples of the `[PcdsFixedAtBuild]` section tag (the
>  ```ini
>  [PcdsFixedAtBuild]
>  [PcdsFixedAtBuild.common]
>  [PcdsFixedAtBuild.IA32]
>  [PcdsFixedAtBuild.X64]
> -[PcdsFixedAtBuild.IPF]
>  [PcdsFixedAtBuild.EBC]
>  [PcdsFixedAtBuild.$(arch).$(SkuIdentifier)]
>  ```
> 
>  Format of a point (VOID*) entry in this section is:
> @@ -150,11 +148,10 @@ The following are typical examples of the `[PcdsPatchableInModule]` section tag
> 
>  ```ini
>  [PcdsPatchableInModule]
>  [PcdsPatchableInModule.IA32]
>  [PcdsPatchableInModule.X64]
> -[PcdsPatchableInModule.IPF]
>  [PcdsPatchableInModule.EBC]
>  [PcdsPatchableInModule.$(arch).$(SkuIdentifier)]
>  ```
> 
>  Format of an entry in this section is:
> @@ -256,11 +253,12 @@ described in the following table.
> 
>  #### Examples
> 
>  ```ini
>  [PcdsDynamicHii.common.Sku_Two]
> -  NoSuchTokenSpaceGuid.PcdPreAllocatedMem| 0x0053 0x0065 0x0074 0x0075 0x0070|gSysconfigGuid|0x000000A9|0x3
> +  NoSuchTokenSpaceGuid.PcdPreAllocatedMem|L"TestVariable"|gSysconfigGuid|0x000000A9|0x3
> +
>  [PcdsDynamicHii.common.DEFAULT]
>    gEfiMdeModulePkgTokenSpaceGuid.PcdValidRange|L"PcdValidRange"|gEfiGlobalVariableGuid|0x07|0|BS,RT,NV
>  ```
> 
>  #### 2.9.3.3 PcdsDynamicVpd
> @@ -353,11 +351,11 @@ described in Table 9 HII Attributes.
> 
>  #### Examples
> 
>  ```ini
>  [PcdsDynamicExHii.IA32.Sku_Two]
> -  gNoSuchTokenSpaceGuid.PcdPreAllocatedMem|0x0053 0x0065 0x0074 0x0075 0x0070|gSysconfigGuid|0x000000A9|0x11
> +  gNoSuchTokenSpaceGuid.PcdPreAllocatedMem|L"TestVariable"|gSysconfigGuid|0x000000A9|0x11
> 
>  [PcdsDynamicExHii.common.DEFAULT]
>    gEfiMdeModulePkgTokenSpaceGuid.PcdValidRange|L"PcdValidRange"|gEfiGlobalVariableGuid|0x07|0|BS,RT,NV
>  ```
> 
> diff --git a/3_edk_ii_dsc_file_format/310_pcd_sections.md b/3_edk_ii_dsc_file_format/310_pcd_sections.md
> index 741a620..f9f1359 100644
> --- a/3_edk_ii_dsc_file_format/310_pcd_sections.md
> +++ b/3_edk_ii_dsc_file_format/310_pcd_sections.md
> @@ -131,11 +131,12 @@ the pipe character, "|". PCDs listed in this section must not be listed in
>  file.
> 
>  #### Prototype
> 
>  ```c
> -<Pcds>         ::= "[PcdsFeatureFlag" [<attribs>] "]" <EOL> <FFStatments>*
> +<Pcds>         ::= "[PcdsFeatureFlag" [<attribs>] "]" <EOL>
> +                   <FFStatments>*
>  <FFStatements> ::= {<MacroDefinition>} {<IncludeStatement>} {<PcdEntry>}
>  <attribs>      ::= <attrs> ["," <TS> "PcdsFeatureFlag" <attrs>]*
>  <attrs>        ::= "." <arch> ["." <SkuIds>]
>  <SkuIdS>       ::= <Keyword> [<FS> <Keyword>]*
>  <Keyword>      ::= <CName>
> @@ -217,11 +218,12 @@ fields that are separated by the pipe character, "|".
>                      <FabStatements>*
>  <attribs>       ::= <attrs> ["," <TS> "PcdsFixedAtBuild" <attrs>]*
>  <attrs>         ::= "." <arch> ["." <SkuIds>]
>  <SkuIdS>        ::= <Keyword> [<FS> <Keyword>]*
>  <Keyword>       ::= <CName>
> -<FabStatements> ::= {<MacroDefinition>} {<IncludeStatement>} {<PcdEntry>} {<PcdFieldEntry>}
> +<FabStatements> ::= {<MacroDefinition>} {<IncludeStatement>} {<PcdEntry>}
> +                    {<PcdFieldEntry>}
>  <PcdEntry>      ::= <TS> <PcdName> [<FS> <PcdValue>] <EOL>
>  <PcdValue>      ::= if (pcddatumtype == "BOOLEAN"):
>                        {<BoolType>} {<Expression>}
>                      elif (pcddatumtype == "UINT8"):
>                        {<NumValUint8>} {<Expression>}
> @@ -265,11 +267,12 @@ value is not listed in the INF file, then the default value from the DEC file
>  must be used.
> 
>  #### Example
> 
>  ```ini
> -[PcdsFixedAtBuild.IA32] gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength
> +[PcdsFixedAtBuild.IA32]
> +  gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength
>    gEfiEdkNt32PkgTokenSpaceGuid.PcdWinNtMemorySizeForSecMain|L"64!64"|VOID*|0x10
> 
>  [PcdsFixedAtBuild.ARM]
>    gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|32
>    gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|0
> @@ -324,11 +327,12 @@ of the DSC file.
>  <attribs>       ::= <attrs> ["," <TS> "PcdsPatchableInModule"
>                      <attrs>]*
>  <attrs>         ::= "." <arch> ["." <SkuIds>]
>  <SkuIdS>        ::= <Keyword> [<FS> <Keyword>]*
>  <Keyword>       ::= <CName>
> -<PimStatements> ::= {<MacroDefinition>} {<IncludeStatement>} {<PcdEntry>} {<PcdFieldEntry>}
> +<PimStatements> ::= {<MacroDefinition>} {<IncludeStatement>} {<PcdEntry>}
> +                    {<PcdFieldEntry>}
>  <PcdEntry>      ::= <TS> <PcdName> [<FS> <PcdValue>] <EOL>
>  <PcdValue>      ::= if (pcddatumtype == "BOOLEAN"):
>                        {<BoolType>} {<Expression>}
>                      elif (pcddatumtype == "UINT8"):
>                        {<NumValUint8>} {<Expression>}
> @@ -413,16 +417,16 @@ the datum type specified in the DEC file that declares this PCD. If a PCD's
>  datum type is `VOID`* the `MaximumDatumSize` field is required. Specifying
>  different `<DataStore>` values(`Default`, `HII`, or `VPD`) in one section
>  header is not permitted. It is permissible to specify different Architectures
>  using an identical `<DataStore>` value. The following line is permissible:
> 
> -`[PcdsDynamicDefault.X64.Default, PcdsDynamicDefault.IPF.Default]`
> +`[PcdsDynamicDefault.X64.Default, PcdsDynamicDefault.EBC.Default]`
> 
>  The following line is incorrect, and must cause a build break during parsing of
>  the file:
> 
> -`[PcdsDynamicDefault.X64.Default, PcdsDynamicVpd.IPF.Default]`
> +`[PcdsDynamicDefault.X64.Default, PcdsDynamicVpd.EBC.Default]`
> 
>  The `!include` statement is permitted in `[PcdsDynamic]` sections, although not
>  recommended.
> 
>  The `Offset`, `MaximumDatumSize` and Value fields are optional for the VPD PCD
> @@ -452,15 +456,17 @@ sections of the DSC file.
>                       {<TS> <MinEntry>} {<TS> <PcdFieldEntry>}
>  <PddAttribs>     ::= <attrs> ["," <TS> "PcdsDynamicDefault" <attrs>]*
>  <PcdsVpd>        ::= "[PcdsDynamicVpd" [<PdvAttribs>] "]" <EOL>
>                       <PdvEntries>*
>  <PdvAttribs>     ::= <attrs> [ "," <TS> "PcdsDynamicVpd" <attrs>]*
> -<PdvEntries>     ::= {<MacroDefinition>} {<IncludeStatement>} {<TS> <VpdEntry>} {<TS> <PcdFieldEntry>}
> +<PdvEntries>     ::= {<MacroDefinition>} {<IncludeStatement>} {<TS> <VpdEntry>}
> +                     {<TS> <PcdFieldEntry>}
>  <PcdsHii>        ::= "[PcdsDynamicHii" [<PdhAttribs>] "]" <EOL>
>                       <PcdHiiEntries>*
>  <PdhAttribs>     ::= <phattrs> ["," <TS> "PcdsDynamicHii <phattrs>]* <PdvEntries>*
> -<PcdHiiEntries>  ::= {<MacroDefinition>} {<IncludeStatement>} {<TS> <HiiEntry>} {<TS> <PcdFieldEntry>}
> +<PcdHiiEntries>  ::= {<MacroDefinition>} {<IncludeStatement>} {<TS> <HiiEntry>}
> +                     {<TS> <PcdFieldEntry>}
>  <attrs>          ::= "." <arch> ["." <SkuIds>]
>  <phattrs>        ::= "." <arch> ["." <SkuIds>]["." <DefaultStore>]
>  <SkuIdS>         ::= <Keyword> [<FS> <Keyword>]*
>  <DefaultStore>   ::= <Keyword>
>  <Keyword>        ::= <CName>
> @@ -570,10 +576,11 @@ DefaultStore in its parent SKU, then inherit other DefaultStore in the same SKU.
>  DefaultStore with the big default store ID will inherit the setting from one with
>  the small default store ID. If there are more than one small default store ID,
>  it will use the biggest one to be inherit. Here is the example. Four PcdsDynamicHii
>  sections are defined.
> 
> +```ini
>  # Four PcdsDynamicHii section
>  [PcdsDynamicHii.common.Default.Standard]
>  [PcdsDynamicHii.common.Default.Manufacturing]
>  [PcdsDynamicHii.common.Sku1.Standard]
>  [PcdsDynamicHii.common.Sku1.Manufacturing]
> @@ -589,10 +596,11 @@ sections are defined.
>  # SKU1 Manufacturing setting based on four sections
>  [PcdsDynamicHii.common.Default.Standard]
>  [PcdsDynamicHii.common.Default.Manufacturing]
>  [PcdsDynamicHii.common.Sku1.Standard]
>  [PcdsDynamicHii.common.Sku1.Manufacturing]
> +```
> 
>  **_PcdValues_**
> 
>  PCD values are optional for `[PcdsDynamicDefault]` sections. The PCD values for
>  PCDs listed in `[PcdsDynamicVpd]` and `[PcdsDynamicHii]` sections are also
> @@ -607,11 +615,11 @@ the _UEFI Specification_ for a description of these attributes.
> 
>  #### Examples
> 
>  ```ini
>  [PcdsDynamicDefault.IA32.Default]
> -  gEfiEdkNt32PkgTokenSpaceGuid.PcdWinNtMemorySizeForSecMain|"L64!64"|10
> +  gEfiEdkNt32PkgTokenSpaceGuid.PcdWinNtMemorySizeForSecMain|"L64!64"|VOID*|10
>    gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel |0x0         # UINT16
>    gPcAtChipsetPkgTokenSpaceGuid.PcdIsaAcpiPs2MouseEnable   |0           # BOOLEAN
> 
>  [PcdsDynamicVpd.common.Sku_Two|SkuSeven]
>    gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress |0x0001ffff|0x1  # UINT32
> @@ -620,11 +628,11 @@ the _UEFI Specification_ for a description of these attributes.
>    gNoSuchTokenSpaceGuid.PcdOemBootOptionName|0x22D4|100|" "             # VOID*
>    gNoSuchTokenSpaceGuid.PcdOemBootOptionPath|0x2338|100|" "             # VOID*
>    gNoSuchTokenSpaceGuid.PcdEnableFastBoot   |0x239C|1  |FALSE           # BOOLEAN
> 
>  [PcdsDynamicHii.IA32, PcdsDynamicHii.X64.Sku1.Standard]
> -  gEfiMyModulePkgTokenSpaceGuid.PcdChassisIntrution|0x0053 0x0065 0x0074 0x0075 0x0070|gSysConfigGuid|0x83|0x0
> +  gEfiMyModulePkgTokenSpaceGuid.PcdChassisIntrution|L"TestVariable"|gSysConfigGuid|0x83|0x0
>    gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0|10  # Variable:
> L"Timeout"
>  ```
> 
>  ### 3.10.5 [PcdsDynamicEx] Sections
> 
> @@ -638,16 +646,16 @@ the datum type specified in the DEC file that declares this PCD. If a PCD's
>  datum type is `VOID`* the `MaximumDatumSize` field is required. Specifying
>  different `<DataStore>` values(`Default`, `HII`, or `VPD`) in one section header
>  is not permitted. It is permissible to specify different Architectures using an
>  identical `<DataStore>` value. The following line is permissible:
> 
> -`[PcdsDynamicExDefault.X64.Default, PcdsDynamicExDefault.IPF.Default]`
> +`[PcdsDynamicExDefault.X64.Default, PcdsDynamicExDefault.EBC.Default]`
> 
>  The following line is incorrect, and must cause a build break during parsing of
>  the file:
> 
> -`[PcdsDynamicExDefault.X64.DEFAULT, PcdsDynamicExVpd.IPF.DEFAULT]`
> +`[PcdsDynamicExDefault.X64.DEFAULT, PcdsDynamicExVpd.EBC.DEFAULT]`
> 
>  The `!include` statement is permitted in `[PcdsDynamicEx]` sections, although
>  not recommended.
> 
>  The `PcdsDynamicEx` entry is a formatted string with three to six fields,
> @@ -659,22 +667,24 @@ sections of the DSC file.
> 
>  ```c
>  <Pcds>           ::= {<PcdsExDefault>} {<PcdsExVpd>} {<PcdsExHii>}
>  <PcdsExDefault>  ::= "[PcdsDynamicExDefault" [<PddAttribs>] "]" <EOL>
>                       <PddEntries>*
> -<PddEntries>     ::= {<MacroDefinition>} {<IncludeStatement>} {<TS> <MinEntry>} {<TS> <PcdFieldEntry>}
> +<PddEntries>     ::= {<MacroDefinition>} {<IncludeStatement>} {<TS> <MinEntry>}
> +                     {<TS> <PcdFieldEntry>}
>  <PddAttribs>     ::= <attrs> ["," <TS> "PcdsDynamicExDefault" <attrs>]*
>  <PcdsExVpd>      ::= "[PcdsDynamicExVpd" [<PdvAttribs>] "]" <EOL>
>                       <PdvEntries>*
>  <PdvAttribs>     ::= <attrs> [ "," <TS> "PcdsDynamicExVpd" <attrs>]*
>  <PdvEntries>     ::= {<MacroDefinition>} {<IncludeStatement>}
>                       {<TS> <VpdEntry>} {<TS> <PcdFieldEntry>}
>  <PcdsExHii>      ::= "[PcdsDynamicExHii" [<PdhAttribs>] "]" <EOL>
>                       <PcdHiiEntries>*
>  <PdhAttribs>     ::= <phattrs> ["," <TS> "PcdsDynamicExHii <phattrs>]*
>                       <PdvEntries>*
> -<PcdHiiEntries>  ::= {<MacroDefinition>} {<IncludeStatement>} {<TS> <HiiEntry>} {<TS> <PcdFieldEntry>}
> +<PcdHiiEntries>  ::= {<MacroDefinition>} {<IncludeStatement>} {<TS> <HiiEntry>}
> +                     {<TS> <PcdFieldEntry>}
>  <attrs>          ::= "." <arch> ["." <SkuIds>]
>  <phattrs>        ::= "." <arch> ["." <SkuIds>]["." <DefaultStore>]
>  <SkuIdS>         ::= <Keyword> [<FS> <Keyword>]*
>  <DefaultStore>   ::= <Keyword>
>  <Keyword>        ::= <CName>
> @@ -784,10 +794,11 @@ DefaultStore in its parent SKU, then inherit other DefaultStore in the same SKU.
>  DefaultStore with the big default store ID will inherit the setting from one with
>  the small default store ID. If there are more than one small default store ID,
>  it will use the biggest one to be inherit. Here is the example. Four PcdsDynamicExHii
>  sections are defined.
> 
> +```ini
>  # Four PcdsDynamicExHii section
>  [PcdsDynamicExHii.common.Default.Standard]
>  [PcdsDynamicExHii.common.Default.Manufacturing]
>  [PcdsDynamicExHii.common.Sku1.Standard]
>  [PcdsDynamicExHii.common.Sku1.Manufacturing]
> @@ -803,10 +814,11 @@ sections are defined.
>  # SKU1 Manufacturing setting based on four sections
>  [PcdsDynamicExHii.common.Default.Standard]
>  [PcdsDynamicExHii.common.Default.Manufacturing]
>  [PcdsDynamicExHii.common.Sku1.Standard]
>  [PcdsDynamicExHii.common.Sku1.Manufacturing]
> +```
> 
>  **_PcdValues_**
> 
>  PCD values are optional for `[PcdsDynamicExDefault]` sections. The PCD values
>  for PCDs listed in `[PcdsDynamicExVpd]` and `[PcdsDynamicExHii]` sections are
> @@ -834,8 +846,8 @@ the _UEFI Specification_ for a description of these attributes.
>    gNoSuchTokenSpaceGuid.PcdOemBootOptionName|0x22D4|100|" "              # VOID*
>    gNoSuchTokenSpaceGuid.PcdOemBootOptionPath|0x2338|100|" "              # VOID*
>    gNoSuchTokenSpaceGuid.PcdEnableFastBoot   |0x239C|FALSE                # BOOLEAN
> 
>  [PcdsDynamicExHii.IA32, PcdsDynamicExHii.X64.Sku1.Standard]
> -  gEfiMyModulePkgTokenSpaceGuid.PcdChassisIntrution|0x0053 0x0065 0x0074 0x0075 0x0070|gSysConfigGuid|0x83|0x0
> +  gEfiMyModulePkgTokenSpaceGuid.PcdChassisIntrution|L"TestVariable"|gSysConfigGuid|0x83|0x0
>    gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut|L"Timeout"|gEfiGlobalVariableGuid|0x0  # Variable:
> L"Timeout"
>  ```
> diff --git a/3_edk_ii_dsc_file_format/311_[components]_sections.md b/3_edk_ii_dsc_file_format/311_[components]_sections.md
> index 7e24bac..b8e2875 100644
> --- a/3_edk_ii_dsc_file_format/311_[components]_sections.md
> +++ b/3_edk_ii_dsc_file_format/311_[components]_sections.md
> @@ -202,11 +202,11 @@ modules in a binary image (the FDF file describes that ordering).
>  <Other>            ::= [<Family> ":"] <OtherSpec>
>  <OtherSpec>        ::= <ToolSpec> "_" <Attribute> <Equal> <String>
>  <Equal>            ::= {<AppendEq>} {<ReplaceEq>}
>  <AppendEq>         ::= <Eq>
>  <ReplaceEq>        ::= <TS> "==" <TS>
> -<Tarch>            ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {*} {<OA>}
> +<Tarch>            ::= {"IA32"} {"X64"} {"EBC"} {*} {<OA>}
>  <OA>               ::= (A-Z) (A-Z0-9)*
>  <Family>           ::= _Family_
>  <Attribute>        ::= _Attribute_
>  <Target>           ::= _Target_
>  <TagName>          ::= _TagName_
> 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 d99e20b..3bbcd9d 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
> @@ -109,11 +109,11 @@ The following are common definitions used by multiple section types.
>                             {[<RelativePath> <FileSep>] <File>}
>                             {<MACROVAL>}
>  <Chars>                ::= (a-zA-Z0-9_)
>  <Digit>                ::= (0-9)
>  <NonDigit>             ::= (a-zA-Z_)
> -<Identifier>           ::= [<NonDigit> <Chars>]*
> +<Identifier>           ::= <NonDigit> <Chars>*
>  <CName>                ::= <Identifier> # A valid C variable name.
>  <AsciiChars>           ::= (0x21 - 0x7E)
>  <CChars>               ::= [{0x21} {(0x23 - 0x26)} {(0x28 - 0x5B)}
>                             {(0x5D - 0x7E)} {<EscapeSequence>}]*
>  <DblQuote>             ::= 0x22
> @@ -196,11 +196,13 @@ The following are common definitions used by multiple section types.
>  <PcdName>              ::= <TokenSpaceGuidCName> "." <PcdCName>
>  <PcdCName>             ::= <CName>
>  <TokenSpaceGuidCName>  ::= <CName>
>  <Field>                ::= <CName>
>  <PcdFieldEntry>        ::= <PcdFieldName> <FS> <PcdFieldValue> <EOL>
> -<PcdFieldValue>        ::= {<BoolType>} {<NumValUint8>} {<NumValUint16>} {<NumValUint32>} {<NumValUint64>} {<StringVal>}
> {<MACROVAL>} {<Expression>}
> +<PcdFieldValue>        ::= {<BoolType>} {<NumValUint8>} {<NumValUint16>}
> +                           {<NumValUint32>} {<NumValUint64>} {<StringVal>}
> +                           {<MACROVAL>} {<Expression>}
>  <PCDVAL>               ::= "PCD(" <PcdName> ")"
>  <UINT8>                ::= {"0x"} {"0X"} (\x0 - \xFF)
>  <UINT16>               ::= {"0x"} {"0X"} (\x0 - \xFFFF)
>  <UINT32>               ::= {"0x"} {"0X"} (\x0 - \xFFFFFFFF)
>  <UINT64>               ::= {"0x"} {"0X"} (\x0 - \xFFFFFFFFFFFFFFFF)
> @@ -262,31 +264,14 @@ The following are common definitions used by multiple section types.
>                             {"DXE_CORE"} {"DXE_DRIVER"} {"SMM_CORE"}
>                             {"DXE_RUNTIME_DRIVER"} {"DXE_SAL_DRIVER"}
>                             {"DXE_SMM_DRIVER"} {"UEFI_DRIVER"}
>                             {"UEFI_APPLICATION"} {"USER_DEFINED"}
>  <ModuleTypeList>       ::= <ModuleType> [" " <ModuleType>]*
> -<IdentifierName>       ::= <TS> {<MACROVAL>} {<PcdName>} <TS>
> -<MembershipExpression> ::= {<TargetExpress>} {<ArchExpress>}
> -                           {<ToolExpress>}
> -<NotOp>                ::= {"NOT"} {"not"} <MTS>
> -<InOp>                 ::= <MTS> [<NotOp>] {"IN"} {"in"} <MTS>
> -<TargetExress>         ::= (A-Z) (A-Z0-9)* <InOp> "$(TARGET)"
> -<ArchExpress>          ::= <DblQuote> <Arch> <DblQuote> <InOp>
> -                           "$(ARCH)"
> -<Arch>                 ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {<OA>}
> -<ToolExpress>          ::= (A-Z) (a-zA-Z0-9)* <InOp> "$(TOOL_CHAIN_TAG)"
>  <Boolean>              ::= {<BoolType>} {<Expression>}
>  <EOL>                  ::= <TS> 0x0A 0x0D
>  <OA>                   ::= (a-zA-Z)(a-zA-Z0-9)*
> -<arch>                 ::= {"IA32"} {"X64"} {"IPF"} {"EBC"} {<OA>}
> -                           {"common"}
> -<Edk2ModuleType>       ::= {"BASE"} {"SEC"} {"PEI_CORE"} {"PEIM"}
> -                           {"DXE_CORE"} {"DXE_DRIVER"}
> -                           {"DXE_SAL_DRIVER"}
> -                           {"DXE_RUNTIME_DRIVER"}
> -                           {"SMM_CORE"} {"DXE_SMM_DRIVER"}
> -                           {"UEFI_DRIVER"} {"UEFI_APPLICATION"}
> +<arch>                 ::= {"IA32"} {"X64"} {"EBC"} {<OA>} {"COMMON"}
>  ```
> 
>  **********
>  **Note:** When using CString, UnicodeString or byte array format as
>  UINT8/UINT16/UINT32/UINT64 values, please make sure they fit in the
> @@ -340,11 +325,11 @@ must not be expanded by parsing tools.
> 
>  **_OA_**
> 
>  Other Architecture - One or more user defined target architectures, such as ARM
>  or PPC. The architectures listed here must have a corresponding entry in the
> -EDK II meta-data file, `Conf/tools_def.txt`. Only `IA32`, `X64`, `IPF` and
> +EDK II meta-data file, `Conf/tools_def.txt`. Only `IA32`, `X64`, `COMMON` and
>  `EBC` are routinely validated.
> 
>  **_FileSep_**
> 
>  FileSep refers to either the back slash "\" or forward slash "/" characters
> @@ -632,14 +617,14 @@ chain tag names.
>  Refer to the EDK II Expression Syntax Specification for additional information.
> 
>  #### Example
> 
>  ```ini
> -!if $(IPF_VERSION) == 1
> -  [VTF.IPF.MyBsf]
> +!if $(EBC_VERSION) == 1
> +  [VTF.EBC.MyBsf]
>      !ifdef IA32RESET
> -      # IPF_VERSION is 1 and IA32RESET defined
> +      # EBC_VERSION is 1 and IA32RESET defined
>        IA32_RST_BIN           = IA32_RST.BIN
>      !endif
>      COMP_NAME              = PAL_A
>      COMP_LOC               = F
>      COMP_TYPE              = 0xF
> @@ -654,14 +639,14 @@ Refer to the EDK II Expression Syntax Specification for additional information.
>      !else
>        COMP_BIN               = GenPal/PAL_A_GEN.bin
>        COMP_SYM               = GenPal/PAL_A_GEN.sym
>      !endif
>      COMP_SIZE              = -
> -!elseif $(IPF_VERSION) == 2
> -  [VTF.IPF.MyBsf]
> +!elseif $(EBC_VERSION) == 2
> +  [VTF.EBC.MyBsf]
>      !ifdef IA32RESET
> -      # IPF_VERSION is 2 and IA32RESET defined
> +      # EBC_VERSION is 2 and IA32RESET defined
>        IA32_RST_BIN = IA32_RST.BIN
>      !endif
>      COMP_NAME    = PAL_A
>      COMP_LOC     = F
>      COMP_TYPE    = 0xF
> 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 8935474..71d778d 100644
> --- a/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> +++ b/3_edk_ii_dsc_file_format/36_[buildoptions]_sections.md
> @@ -68,11 +68,11 @@ earlier.
>  Build options priority (appended from lowest to highest and/or highest
>  replacement) is:
> 
>  * Highest, DSC file's component scoped `<BuildOptions>` for individual INF
>    files.
> -* `[BuildOptions.$(arch).CodeBase.Edk2ModuleType]`
> +* `[BuildOptions.$(arch).CodeBase.ModuleType]`
>  * `[BuildOptions.$(arch).CodeBase]`
>  * `[BuildOptions.common.CodeBase]`
>  * `[BuildOptions.$(arch)]`
>  * `[BuildOptions.common]`
>  * `[BuildOptions]`
> @@ -219,11 +219,11 @@ The logical result is:
> 
>  #### Prototype
> 
>  ```c
>  <BuildOptions> ::= "[BuildOptions" [<attribs>] "]" <EOL> <Statements>*
> -<attribs>      ::= "." <arch> [<CodeBase> ["." <Edk2ModuleType>]]
> +<attribs>      ::= "." <arch> [<CodeBase> ["." <ModuleType>]]
>  <CodeBase>     ::= "." {"Common"} {"EDK"} {"EDKII"}
>  <Statements>   ::= {<MacroDefinition>} {<IncludeStatement>}
>                     {<TS> <BStatement>}
>  <BStatement>   ::= {<ToolFlag>} {<ToolPath>} {<ToolCmd>} {<Other>}
>  <ToolFlag>     ::= [<Family> ":"] <FlagSpec> <Equal> <Flags> <EOL>
> diff --git a/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md b/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> index d431275..9ac3878 100644
> --- a/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> +++ b/3_edk_ii_dsc_file_format/39_[libraryclasses]_sections.md
> @@ -75,11 +75,11 @@ When parsing the DSC file, the precedence rules must be followed.
>  #### Prototype
> 
>  ```c
>  <LibraryClasses>   ::= "[LibraryClasses" [<attribs>] "]" <EOL> <LcStatements>*
>  <attribs>          ::= <attrs> ["," "LibraryClasses" <attrs>]*
> -<attrs>            ::= "." <arch> ["." <Edk2ModuleType>]
> +<attrs>            ::= "." <arch> ["." <ModuleType>]
>  <LcStatements>     ::= {<MacroDefinition>} {<IncludeStatment>}
>                         {<TS> <LcEntry>}
>  <LcEntry>          ::= <LibraryClassName> <FS> <LibraryInstance> <EOL>
>  <LibraryClassName> ::= (A-Z)(a-zA-Z0-9)*
>  <LibraryInstance>  ::= <InfFileName> <EOL>
> diff --git a/README.md b/README.md
> index 54d50cb..5672273 100644
> --- a/README.md
> +++ b/README.md
> @@ -164,11 +164,11 @@ Copyright (c) 2006-2017, Intel Corporation. All rights reserved.
>  | Errata A   | Update link to the EDK II Specifications, fixed the name of the Multi-String .UNI File Format Specification
> |                |
>  | 1.25       | Updates:
> | June 2015      |
>  |            | Updated support for UEFI 2.5 and PI 1.4
> |                |
>  |            | Added clarification regarding the use of .. and . in path names in section 2
> |                |
>  |            | In section 2.8.3.7, added clarification regarding allocation of memory based on calculation of maximum size for
> VOID* PCD entries when the maximum size is not specified in the DSC file
> |                |
> -|            | In section 3.6 added optional `<Edk2ModuleType>` element to the section header in order to support UEFI 2.5
> Runtime Drivers that must be 4K page aligned
> |                |
> +|            | In section 3.6 added optional `<ModuleType>` element to the section header in order to support UEFI 2.5 Runtime
> Drivers that must be 4K page aligned
> |                |
>  |            | Also in 3.6, updated the priority of [BuildOptions] to match current implementation that follows the Build
> Specification
> |                |
>  |            | In sections 2.3 and 3.5, added new [Defines] boolean entry PCD_VAR_CHECK_GENERATION
> |                |
>  |            | In sections 2.9.3.2, 2.9.3.5, 3.10.4 and 3.10.5 added HII Attribute entry.
> |                |
>  |            | Since the above changes are new features, update the minor revision of the DSC_SPECIFICATION to 0x00010019,
> older DSC files that do not use the new features do not need to modify the DSC_SPECIFICATION values
> |                |
>  |            | Added clarification on when the DSC_SPECIFICATION value must be updated to 0x00010019
> |                |
> --
> 2.6.1.windows.1