[edk2] [PATCH v2 0/2] Avoid reading undefined contents in PrintLib

[Hao Wu]

V2 changes:
Refines the code logic to replace the 'if else' statments with the '? :'
operator.

V1 history:
This series add logic to avoid reading content beyond a ASCII format
string.

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Michael Kinney 

Hao Wu (2):
  MdePkg/BasePrintLib: Avoid reading content beyond the format string
  MdeModulePkg/PrintLib: Avoid reading content beyond the format string

 MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c | 22 
++--
 MdePkg/Library/BasePrintLib/PrintLibInternal.c| 16 +++---
 2 files changed, 19 insertions(+), 19 deletions(-)

-- 
2.12.0.windows.1

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

[edk2] [PATCH v2 2/2] MdeModulePkg/PrintLib: Avoid reading content beyond the format string

[Hao Wu]

https://bugzilla.tianocore.org/show_bug.cgi?id=567

In functions DxePrintLibPrint2ProtocolVaListToBaseList() and
InternalPrintLibSPrintMarker(), when processing ASCII format strings, if
the format string walker pointer 'Format' is pointing at the end of the
format string (i.e. '\0'), the following expression:
*(Format + 1)
will read an undefined value.

Though this value won't affect the functionality, since it will be masked
by variable 'FormatMask':
(*(Format + 1) << 8)) & FormatMask
(FormatMask is 0xff for ASCII format string)

This commit adds additional logic to avoid reading undefined content.

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c | 22 
++--
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c 
b/MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c
index 9f702c4fef..b58db8e011 100644
--- a/MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c
+++ b/MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c
@@ -130,7 +130,7 @@ DxePrintLibPrint2ProtocolVaListToBaseList (
   //
   // Get the first character from the format string
   //
-  FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & FormatMask;
+  FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) ? 0 : 
(*(Format + 1) << 8))) & FormatMask;
 
   while (FormatCharacter != 0) {
 if (FormatCharacter == '%') {
@@ -148,7 +148,7 @@ DxePrintLibPrint2ProtocolVaListToBaseList (
 //
 // Get the next character from the format string
 //
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & 
FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) 
? 0 : (*(Format + 1) << 8))) & FormatMask;
 
 switch (FormatCharacter) {
 case '.': 
@@ -239,7 +239,7 @@ DxePrintLibPrint2ProtocolVaListToBaseList (
 //
 // Get the next character from the format string
 //
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) ? 0 
: (*(Format + 1) << 8))) & FormatMask;
   }
   return TRUE;
 }
@@ -1596,7 +1596,7 @@ InternalPrintLibSPrintMarker (
   //
   // Get the first character from the format string
   //
-  FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & FormatMask;
+  FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) ? 0 : 
(*(Format + 1) << 8))) & FormatMask;
 
   //
   // Loop until the end of the format string is reached or the output buffer 
is full
@@ -1628,7 +1628,7 @@ InternalPrintLibSPrintMarker (
   //
   for (Done = FALSE; !Done; ) {
 Format += BytesPerFormatCharacter;
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & 
FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) 
? 0 : (*(Format + 1) << 8))) & FormatMask;
 switch (FormatCharacter) {
 case '.': 
   Flags |= PRECISION; 
@@ -1681,7 +1681,7 @@ InternalPrintLibSPrintMarker (
   for (Count = 0; ((FormatCharacter >= '0') &&  (FormatCharacter <= 
'9')); ){
 Count = (Count * 10) + FormatCharacter - '0';
 Format += BytesPerFormatCharacter;
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & 
FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 
1) ? 0 : (*(Format + 1) << 8))) & FormatMask;
   }
   Format -= BytesPerFormatCharacter;
   if ((Flags & PRECISION) == 0) {
@@ -1960,7 +1960,7 @@ InternalPrintLibSPrintMarker (
 
   case '\r':
 Format += BytesPerFormatCharacter;
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & 
FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) 
? 0 : (*(Format + 1) << 8))) & FormatMask;
 if (FormatCharacter == '\n') {
   //
   // Translate '\r\n' to '\r\n'
@@ -1981,7 +1981,7 @@ InternalPrintLibSPrintMarker (
 //
 ArgumentString = "\r\n";
 Format += BytesPerFormatCharacter;
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & 
FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) 
? 0 : (*(Format + 1) << 8))) & FormatMask;
 if (FormatCharacter != '\r') {
   Format   -= BytesPerFormatCharacter;
 }
@@ -2000,7 +2000,7 @@ InternalPrintLibSPrintMarker (
  
 case '\r':
   Format += BytesPerFormatCharacter;
-  FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & FormatMask;
+  FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) ? 
0 : (*(Format + 1) << 8))) & FormatMask;
   if (FormatCharacter == '\n') {
 //
 // Tran

[edk2] [PATCH v2 1/2] MdePkg/BasePrintLib: Avoid reading content beyond the format string

[Hao Wu]

https://bugzilla.tianocore.org/show_bug.cgi?id=567

In function BasePrintLibSPrintMarker(), when processing ASCII format
strings, if the format string walker pointer 'Format' is pointing at the
end of the format string (i.e. '\0'), the following expression:
*(Format + 1)
will read an undefined value.

Though this value won't affect the functionality, since it will be masked
by variable 'FormatMask':
(*(Format + 1) << 8)) & FormatMask
(FormatMask is 0xff for ASCII format string)

This commit adds additional logic to avoid reading undefined content.

Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdePkg/Library/BasePrintLib/PrintLibInternal.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/MdePkg/Library/BasePrintLib/PrintLibInternal.c 
b/MdePkg/Library/BasePrintLib/PrintLibInternal.c
index 9b15a07ac0..cec5b3bc99 100644
--- a/MdePkg/Library/BasePrintLib/PrintLibInternal.c
+++ b/MdePkg/Library/BasePrintLib/PrintLibInternal.c
@@ -653,7 +653,7 @@ BasePrintLibSPrintMarker (
   //
   // Get the first character from the format string
   //
-  FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & FormatMask;
+  FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) ? 0 : 
(*(Format + 1) << 8))) & FormatMask;
 
   //
   // Loop until the end of the format string is reached or the output buffer 
is full
@@ -685,7 +685,7 @@ BasePrintLibSPrintMarker (
   //
   for (Done = FALSE; !Done; ) {
 Format += BytesPerFormatCharacter;
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & 
FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) 
? 0 : (*(Format + 1) << 8))) & FormatMask;
 switch (FormatCharacter) {
 case '.': 
   Flags |= PRECISION; 
@@ -738,7 +738,7 @@ BasePrintLibSPrintMarker (
   for (Count = 0; ((FormatCharacter >= '0') &&  (FormatCharacter <= 
'9')); ){
 Count = (Count * 10) + FormatCharacter - '0';
 Format += BytesPerFormatCharacter;
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & 
FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 
1) ? 0 : (*(Format + 1) << 8))) & FormatMask;
   }
   Format -= BytesPerFormatCharacter;
   if ((Flags & PRECISION) == 0) {
@@ -1017,7 +1017,7 @@ BasePrintLibSPrintMarker (
 
   case '\r':
 Format += BytesPerFormatCharacter;
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & 
FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) 
? 0 : (*(Format + 1) << 8))) & FormatMask;
 if (FormatCharacter == '\n') {
   //
   // Translate '\r\n' to '\r\n'
@@ -1038,7 +1038,7 @@ BasePrintLibSPrintMarker (
 //
 ArgumentString = "\r\n";
 Format += BytesPerFormatCharacter;
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & 
FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) 
? 0 : (*(Format + 1) << 8))) & FormatMask;
 if (FormatCharacter != '\r') {
   Format   -= BytesPerFormatCharacter;
 }
@@ -1057,7 +1057,7 @@ BasePrintLibSPrintMarker (
  
 case '\r':
   Format += BytesPerFormatCharacter;
-  FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & FormatMask;
+  FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) ? 
0 : (*(Format + 1) << 8))) & FormatMask;
   if (FormatCharacter == '\n') {
 //
 // Translate '\r\n' to '\r\n'
@@ -1078,7 +1078,7 @@ BasePrintLibSPrintMarker (
   //
   ArgumentString = "\r\n";
   Format += BytesPerFormatCharacter;
-  FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & FormatMask;
+  FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) ? 
0 : (*(Format + 1) << 8))) & FormatMask;
   if (FormatCharacter != '\r') {
 Format   -= BytesPerFormatCharacter;
   }
@@ -1206,7 +1206,7 @@ BasePrintLibSPrintMarker (
 //
 // Get the next character from the format string
 //
-FormatCharacter = ((*Format & 0xff) | (*(Format + 1) << 8)) & FormatMask;
+FormatCharacter = ((*Format & 0xff) | ((BytesPerFormatCharacter == 1) ? 0 
: (*(Format + 1) << 8))) & FormatMask;
   }
 
   if ((Flags & COUNT_ONLY_NO_PRINT) != 0) {
-- 
2.12.0.windows.1

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

Re: [edk2] [edk2-DscSpecification PATCH v2] Update Precedence of PCD Values

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong

-Original Message-
From: Kinney, Michael D 
Sent: Wednesday, May 31, 2017 2:00 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-DscSpecification PATCH v2] Update Precedence of PCD Values

https://bugzilla.tianocore.org/show_bug.cgi?id=519

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_dsc_overview/28_pcd_section_processing.md | 56 ++---
 README.md   |  1 +
 2 files changed, 29 insertions(+), 28 deletions(-)

diff --git a/2_dsc_overview/28_pcd_section_processing.md 
b/2_dsc_overview/28_pcd_section_processing.md
index 0969b41..1adde81 100644
--- a/2_dsc_overview/28_pcd_section_processing.md
+++ b/2_dsc_overview/28_pcd_section_processing.md
@@ -320,45 +320,45 @@ string plus 1 byte for the null terminator, for L"string" 
entries to be the  length of the UCS-2 character string plus 2 bytes for the 
null terminator and  the exact length of a byte array.
 
-Precedence for determining PCD values (high to low, last in position) is as
-follows:
+The values that are assigned to individual PCDs required by a build may 
+come from different locations and different meta-data files. The 
+following provides the precedence (high to low) to assign a value to a PCD.
 
-* A PCD value defined by a MACRO, ("MacroName" in this example), and the Macro
-  is defined on the command-line using -D MacroName=Value
+* Command-line, `--pcd` flags (left most has higher priority)
 
-* A PCD value defined in the FDF file SET statements
+* DSC file, FeatureFlag, PatchableInModule or FixedAtBuild PCD value 
+defined
+  in the `[Components]` INF scoping `` section statements
 
-* A PCD value defined positionally in the FDF file
+* FDF file, grammar describing automatic assignment of PCD values
 
-* A FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined in the
-  `[Components]` INF scoping section
+* FDF file, SET statements within a section
 
-* A FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined in a PCD
-  access method section with an architectural modifier (the access method for a
-  PCD in a section with an architectural modifier takes precedence over any
-  other access method)
+* FDF file, SET statement in the [Defines] section
 
-In this example, modules built for IA32 architecture, the PCD will use 
-PatchableInModule access, while modules built for all other architectures, the 
-PCD will use the FixedAtBuild access method:
+* DSC file, a PCD value defined in a PCD access method section with an
+  architectural modifier.
 
-```ini
-[PcdsFixedAtBuild.common]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
-  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
+  In this example, modules built for IA32 architecture, the PCD will 
+ use  PatchableInModule access, while modules built for all other 
+ architectures, the  PCD will use the FixedAtBuild access method:
 
-[PcdsPatchableInModule.IA32]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
-  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
-```
+  ```ini
+  [PcdsFixedAtBuild.common]
+gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|F
+ ALSE
+
+  [PcdsPatchableInModule.IA32]
+gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|F
+ ALSE
+  ```
 
-* A PCD value defined in a PCD access method (item type) section for common
-  architectures
+* DSC file, A PCD value defined in a PCD access method (item type) 
+global
+  `[Pcd*]` section for common architectures.
 
-* A PCD value defined in an INF (provided all INF files have defined the same
-  value)
+* INF file, PCD sections, Default Values (provided all INF files have 
+defined
+  the same value)
 
-* A PCD default value defined in the DEC file that declares the PCD.
+* DEC file, PCD sections, Default Values
 
 **
 **Note:** Dynamic or DynamicEx PCD sections with architectural modifiers is 
not diff --git a/README.md b/README.md index eb6966f..5e2c17a 100644
--- a/README.md
+++ b/README.md
@@ -181,3 +181,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || [#484](https://bugzilla.tianocore.org/show_bug.cgi?id=484) DSC 
spec: support Prebuild and Postbuild in the [Defines] section   

  ||
 || [#353](https://bugzilla.tianocore.org/show_bug.cgi?id=353) 
Build spec: Allow nested includes in DSC and FDF files  
   

Re: [edk2] [edk2-DscSpecification PATCH] Update Precedence of PCD Values

[Kinney, Michael D]

Yonghong,

Thanks for the feedback.  I have sent V2 with these corrections.

Mike

-Original Message-
From: Zhu, Yonghong 
Sent: Tuesday, May 30, 2017 6:41 PM
To: Kinney, Michael D ; edk2-devel@lists.01.org
Cc: Gao, Liming ; Shaw, Kevin W ; 
Zhu, Yonghong 
Subject: RE: [edk2-DscSpecification PATCH] Update Precedence of PCD Values

Hi Mike,

1. Is this 'p' typo error is sentence "DSC file, p FeatureFlag, 
PatchableInModule or FixedAtBuild PCD value"?
2. How about remove the "FeatureFlag, PatchableInModule or FixedAtBuild" from 
below sentence since current Dynamic/DynamicEx also can have the specific arch 
info.
"DSC file, a FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined 
in a PCD access method section with an architectural modifier"

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Sunday, May 28, 2017 3:35 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-DscSpecification PATCH] Update Precedence of PCD Values

https://bugzilla.tianocore.org/show_bug.cgi?id=519

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_dsc_overview/28_pcd_section_processing.md | 56 ++---
 README.md   |  5 +--
 2 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/2_dsc_overview/28_pcd_section_processing.md 
b/2_dsc_overview/28_pcd_section_processing.md
index 60e7de7..3736cde 100644
--- a/2_dsc_overview/28_pcd_section_processing.md
+++ b/2_dsc_overview/28_pcd_section_processing.md
@@ -312,45 +312,45 @@ string plus 1 byte for the null terminator, for L"string" 
entries to be the  length of the UCS-2 character string plus 2 bytes for the 
null terminator and  the exact length of a byte array.
 
-Precedence for determining PCD values (high to low, last in position) is as
-follows:
+The values that are assigned to individual PCDs required by a build may 
+come from different locations and different meta-data files. The 
+following provides the precedence (high to low) to assign a value to a PCD.
 
-* A PCD value defined by a MACRO, ("MacroName" in this example), and the Macro
-  is defined on the command-line using -D MacroName=Value
+* Command-line, `--pcd` flags (left most has higher priority)
 
-* A PCD value defined in the FDF file SET statements
+* DSC file, p FeatureFlag, PatchableInModule or FixedAtBuild PCD value 
+defined
+  in the `[Components]` INF scoping `` section statements
 
-* A PCD value defined positionally in the FDF file
+* FDF file, grammar describing automatic assignment of PCD values
 
-* A FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined in the
-  `[Components]` INF scoping section
+* FDF file, SET statements within a section
 
-* A FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined in a PCD
-  access method section with an architectural modifier (the access method for a
-  PCD in a section with an architectural modifier takes precedence over any
-  other access method)
+* FDF file, SET statement in the [Defines] section
 
-In this example, modules built for IA32 architecture, the PCD will use 
-PatchableInModule access, while modules built for all other architectures, the 
-PCD will use the FixedAtBuild access method:
+* DSC file, a FeatureFlag, PatchableInModule or FixedAtBuild PCD value 
+defined
+  in a PCD access method section with an architectural modifier.
 
-```ini
-[PcdsFixedAtBuild.common]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
-  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
+  In this example, modules built for IA32 architecture, the PCD will 
+ use  PatchableInModule access, while modules built for all other 
+ architectures, the  PCD will use the FixedAtBuild access method:
 
-[PcdsPatchableInModule.IA32]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
-  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
-```
+  ```ini
+  [PcdsFixedAtBuild.common]
+gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|F
+ ALSE
+
+  [PcdsPatchableInModule.IA32]
+gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|F
+ ALSE
+  ```
 
-* A PCD value defined in a PCD access method (item type) section for common
-  architectures
+* DSC file, A PCD value defined in a PCD access method (item type) 
+global
+  `[Pcd*]` section for common architectures.
 
-* A PCD value defined in an INF (provided all INF files have defined the same
-  value)
+* INF file, PCD sections, Default Values (provided all INF files have 
+defined
+  the same value)
 
-* A PCD default value defined in the DEC file that declares the PCD.
+* DEC file, PCD sections, Default Values
 
 **
 **Note

[edk2] [edk2-DscSpecification PATCH v2] Update Precedence of PCD Values

[Michael Kinney]

https://bugzilla.tianocore.org/show_bug.cgi?id=519

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_dsc_overview/28_pcd_section_processing.md | 56 ++---
 README.md   |  1 +
 2 files changed, 29 insertions(+), 28 deletions(-)

diff --git a/2_dsc_overview/28_pcd_section_processing.md 
b/2_dsc_overview/28_pcd_section_processing.md
index 0969b41..1adde81 100644
--- a/2_dsc_overview/28_pcd_section_processing.md
+++ b/2_dsc_overview/28_pcd_section_processing.md
@@ -320,45 +320,45 @@ string plus 1 byte for the null terminator, for L"string" 
entries to be the
 length of the UCS-2 character string plus 2 bytes for the null terminator and
 the exact length of a byte array.
 
-Precedence for determining PCD values (high to low, last in position) is as
-follows:
+The values that are assigned to individual PCDs required by a build may come
+from different locations and different meta-data files. The following provides
+the precedence (high to low) to assign a value to a PCD.
 
-* A PCD value defined by a MACRO, ("MacroName" in this example), and the Macro
-  is defined on the command-line using -D MacroName=Value
+* Command-line, `--pcd` flags (left most has higher priority)
 
-* A PCD value defined in the FDF file SET statements
+* DSC file, FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined
+  in the `[Components]` INF scoping `` section statements
 
-* A PCD value defined positionally in the FDF file
+* FDF file, grammar describing automatic assignment of PCD values
 
-* A FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined in the
-  `[Components]` INF scoping section
+* FDF file, SET statements within a section
 
-* A FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined in a PCD
-  access method section with an architectural modifier (the access method for a
-  PCD in a section with an architectural modifier takes precedence over any
-  other access method)
+* FDF file, SET statement in the [Defines] section
 
-In this example, modules built for IA32 architecture, the PCD will use
-PatchableInModule access, while modules built for all other architectures, the
-PCD will use the FixedAtBuild access method:
+* DSC file, a PCD value defined in a PCD access method section with an
+  architectural modifier.
 
-```ini
-[PcdsFixedAtBuild.common]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
-  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
+  In this example, modules built for IA32 architecture, the PCD will use
+  PatchableInModule access, while modules built for all other architectures, 
the
+  PCD will use the FixedAtBuild access method:
 
-[PcdsPatchableInModule.IA32]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
-  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
-```
+  ```ini
+  [PcdsFixedAtBuild.common]
+gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
+gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
+
+  [PcdsPatchableInModule.IA32]
+gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
+gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
+  ```
 
-* A PCD value defined in a PCD access method (item type) section for common
-  architectures
+* DSC file, A PCD value defined in a PCD access method (item type) global
+  `[Pcd*]` section for common architectures.
 
-* A PCD value defined in an INF (provided all INF files have defined the same
-  value)
+* INF file, PCD sections, Default Values (provided all INF files have defined
+  the same value)
 
-* A PCD default value defined in the DEC file that declares the PCD.
+* DEC file, PCD sections, Default Values
 
 **
 **Note:** Dynamic or DynamicEx PCD sections with architectural modifiers is not
diff --git a/README.md b/README.md
index eb6966f..5e2c17a 100644
--- a/README.md
+++ b/README.md
@@ -181,3 +181,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || [#484](https://bugzilla.tianocore.org/show_bug.cgi?id=484) DSC 
spec: support Prebuild and Postbuild in the [Defines] section   

  ||
 || [#353](https://bugzilla.tianocore.org/show_bug.cgi?id=353) 
Build spec: Allow nested includes in DSC and FDF files  

  | 
   |
 || [#521](https://bugzilla.tianocore.org/show_bug.cgi?id=521) DSC 
spec: add clarification for mixed PCD usage in the DSC spec 

[edk2] [edk2-DscSpecification PATCH v2] Update Precedence of PCD Values

[Michael Kinney]

New in V2
==
* Remove extra 'p' character typo
* Clarify that arch specific PCD values can be used for all PCD access methods

https://bugzilla.tianocore.org/show_bug.cgi?id=519

GitHub branch for review:

* 
https://github.com/mdkinney/edk2-DscSpecification/tree/r_Bugzilla_519_UpdatePrecedenceOfPcdValues_V2

GitHub word diff view of the patches in this series:

* [1/1] 
https://github.com/mdkinney/edk2-DscSpecification/commit/eb78621d3a98dac73e0b248b38787e675966eb81?w=1

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  Update Precedence of PCD Values

 2_dsc_overview/28_pcd_section_processing.md | 56 ++---
 README.md   |  1 +
 2 files changed, 29 insertions(+), 28 deletions(-)

-- 
2.6.3.windows.1

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

Re: [edk2] [PATCH] Maintainers.txt: Update maintainers for DuetPkg & Nt32Pkg

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

Thanks/Ray

> -Original Message-
> From: Wu, Hao A
> Sent: Wednesday, May 31, 2017 9:55 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ni, Ruiyu 
> Subject: [PATCH] Maintainers.txt: Update maintainers for DuetPkg &
> Nt32Pkg
> 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  Maintainers.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt index f412b65691..39b5b67857
> 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -90,6 +90,7 @@ M: Ting Ye   DuetPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg
>  M: Ruiyu Ni 
> +M: Hao Wu 
> 
>  EdkCompatibilityPkg
>  W:
> https://github.com/tianocore/tianocore.github.io/wiki/EdkCompatibilityPkg
> @@ -168,6 +169,7 @@ M: Jiaxin Wu   Nt32Pkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/Nt32Pkg
>  M: Ruiyu Ni 
> +M: Hao Wu 
> 
>  Omap35xxPkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/Omap35xxPkg
> --
> 2.12.0.windows.1

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

[edk2] [edk2-staging/BaseToolsOpt]: Add new branch BaseToolsOpt

[Gao, Liming]

Hi All,
  I would like to add new branch BaseToolsOpt in edk2-staging for BaseTools 
build performance optimization. Here is its Readme.MD. Please help review.

Readme.MD:
This branch is used to optimize BaseTools build performance. It bases on edk2 
repo UDK2017 branch.

The branch owner:
Gao, Liming 
Zhu, Yonghong 

## Feature Introduction
BaseTools supports more and more features. They will take more build time. To 
reduce build overhead, some points have been 
identified to be optimized. POC code will be added in this branch for 
evaluation.
1) Enable the multiple thread in GenFds phase.
2) Support to merge multiple drivers into one. It should save the link time. 
But, it doesn't save much in the multiple build. 
   Besides, this feature can save the image size when the image is not 
compressed, such as PEI images.
3) Reduce the extra copy actions in build process.
4) Analyze cProfile data and enhance the parser logic. 
https://bugzilla.tianocore.org/show_bug.cgi?id=42

## Timeline
Target for 2017 Q3

### NOTES
Most changes in this branch are BaseTools. To apply them, user needs to run 
BaseTools 
from sources. In Linux, BaseTools run from source. In Windows, BaseTools can 
run from source. And, Reconfig option is also 
required to apply new config settings in BaseTools\Conf. The step is like below:
1. enter into edk2
2. set PYTHON_HOME=C:\Python27
3. type edksetup.bat --nt32 Reconfig
4. nmake -f BaseTools\Makefile
5. type build command to build platform.

Thanks
Liming
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2-staging/StructurePcd]: Add new branch StructurePcd

[Gao, Liming]

Hi All,
  Some RFC have been sent on Structure PCD feature. I would like to add new 
branch StructurePcd in edk2-staging and add POC code to show structure PCD idea 
and usage. Here is its Readme.MD. Please help review.

Readme.MD:
This branch is used to enable Structure PCD feature.

The branch owner:
Gao, Liming 
Zhu, Yonghong 
Zeng, Star 
Feng, Bob C 
Bi, Dandan 

## Feature Introduction
Structure PCD is to support the same C structure/Enum/Macro definition in PCD 
and VFR, and specify the value for individual 
fields in a VOID* PCD in DEC/DSC/FDF/CL. It includes the group of the sub 
features. 
https://bugzilla.tianocore.org/show_bug.cgi?id=541 [BaseTools] Extended PCD 
Value Syntax to support the flexible value formats
https://bugzilla.tianocore.org/show_bug.cgi?id=542 [BaseTools] Structure PCD 
value assignment in DEC/DSC
https://bugzilla.tianocore.org/show_bug.cgi?id=543 [BaseTools] Extended SKU 
Support - Inheritance
https://bugzilla.tianocore.org/show_bug.cgi?id=544 [BaseTools] PCD: Extended 
SKU support 2 - sub SKU
https://bugzilla.tianocore.org/show_bug.cgi?id=545 [BaseTools] Support Bit 
fields used as EFI VarStore/Buffer VarStore in VFR
https://bugzilla.tianocore.org/show_bug.cgi?id=546 [PCD] Pcd Database size 
optimization for multi-SKU

## Timeline
Target for 2017

### NOTES
This branch bases on edk2 repo UDK2017 branch.

Thanks
Liming
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Xhci: Fill the 'interval' field for ISO endpoint context

[Wu, Hao A]

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, May 31, 2017 11:27 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Wu, Hao A; Baranee; Zeng, Star
> Subject: RE: [edk2] [PATCH] MdeModulePkg/Xhci: Fill the 'interval' field for 
> ISO
> endpoint context
> 
> Reviewed-by: Star Zeng 
> 
> BTW: Could you add the reference to the bugzilla link in the commit log?

Yes, I will modify the commit message to include the info.

Best Regards,
Hao Wu

> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao
> Wu
> Sent: Wednesday, May 31, 2017 9:48 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Baranee ; Zeng,
> Star 
> Subject: [edk2] [PATCH] MdeModulePkg/Xhci: Fill the 'interval' field for ISO
> endpoint context
> 
> The commit fills the 'Interval' field of the Endpoint Context data for 
> isochronous
> endpoints. It will resolve the error when a Configure Endpoint Command is sent
> to an isochronous endpoint.
> 
> Cc: Star Zeng 
> Cc: Baranee 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 30
> +-
> MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c | 30
> +-
>  2 files changed, 58 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> index 4bec76a85f..58a2f984a9 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
> @@ -2,7 +2,7 @@
> 
>XHCI transfer scheduling routines.
> 
> -Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials  are licensed and made
> available under the terms and conditions of the BSD License  which
> accompanies this distribution.  The full text of the license may be found at 
> @@
> -2661,6 +2661,20 @@ XhcInitializeEndpointContext (
>InputContext->EP[Dci-1].EPType = ED_ISOCH_OUT;
>  }
>  //
> +// Get the bInterval from descriptor and init the the interval field 
> of
> endpoint context.
> +// Refer to XHCI 1.1 spec section 6.2.3.6.
> +//
> +if (DeviceSpeed == EFI_USB_SPEED_FULL) {
> +  Interval = EpDesc->Interval;
> +  ASSERT (Interval >= 1 && Interval <= 16);
> +  InputContext->EP[Dci-1].Interval = Interval + 2;
> +} else if ((DeviceSpeed == EFI_USB_SPEED_HIGH) || (DeviceSpeed ==
> EFI_USB_SPEED_SUPER)) {
> +  Interval = EpDesc->Interval;
> +  ASSERT (Interval >= 1 && Interval <= 16);
> +  InputContext->EP[Dci-1].Interval = Interval - 1;
> +}
> +
> +//
>  // Do not support isochronous transfer now.
>  //
>  DEBUG ((EFI_D_INFO, "XhcInitializeEndpointContext: Unsupport ISO EP
> found, Transfer ring is not allocated.\n")); @@ -2829,6 +2843,20 @@
> XhcInitializeEndpointContext64 (
>InputContext->EP[Dci-1].EPType = ED_ISOCH_OUT;
>  }
>  //
> +// Get the bInterval from descriptor and init the the interval field 
> of
> endpoint context.
> +// Refer to XHCI 1.1 spec section 6.2.3.6.
> +//
> +if (DeviceSpeed == EFI_USB_SPEED_FULL) {
> +  Interval = EpDesc->Interval;
> +  ASSERT (Interval >= 1 && Interval <= 16);
> +  InputContext->EP[Dci-1].Interval = Interval + 2;
> +} else if ((DeviceSpeed == EFI_USB_SPEED_HIGH) || (DeviceSpeed ==
> EFI_USB_SPEED_SUPER)) {
> +  Interval = EpDesc->Interval;
> +  ASSERT (Interval >= 1 && Interval <= 16);
> +  InputContext->EP[Dci-1].Interval = Interval - 1;
> +}
> +
> +//
>  // Do not support isochronous transfer now.
>  //
>  DEBUG ((EFI_D_INFO, "XhcInitializeEndpointContext64: Unsupport ISO EP
> found, Transfer ring is not allocated.\n")); diff --git
> a/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c
> b/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c
> index 7a63dabd8c..3dd2b89097 100644
> --- a/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c
> +++ b/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c
> @@ -2,7 +2,7 @@
>  PEIM to produce gPeiUsb2HostControllerPpiGuid based on
> gPeiUsbControllerPpiGuid  which is used to enable recovery function from USB
> Drivers.
> 
> -Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> 
>  This program and the accompanying materials  are licensed and made
> available under the terms and conditions @@ -1750,6 +1750,20 @@
> XhcPeiSetConfigCmd (
>  InputContext->EP[Dci-1].EPType = ED_ISOCH_OUT;
>}
>//
> +  // Get the bInterval from descriptor and init the the interval 
> field of
> endpoint context.
> +  // Refer to XHCI 1.1 spec se

Re: [edk2] Unmount and mount a mass storage from shell

[GN Keshava]

Hi Jaben,

Thanks a lot for your input.

As I have mentioned in previous mail, I'm facing an issue now, that, If I
reconnect my client device, the mass storage is not able to mount again
automatically.
Here is few more details. Expecting some help on this :

I connect the the client device to UEFI host. I get the mass storage
successfully. (device is listed as Mass storage in devices command)
The client device also has serial CDC functionality (It is Linux CDC
gadget, which will enumerate as both Mass storage (FAT32) and CDC serial
com port).
To use serial port, I have developed a custom serial driver. I use VID PID
of the device in this custom driver to bind the driver to the device. I
load this driver, and I get serial port (It is listed in sermode command)
Now I refresh the mapping using map -r. Still I get the mass storage of
device, and I'm able to access it correctly.
Now I disconnect the client from host (UEFI) by unplugging the device.
When I connect the device again, I'm not able to get Mass storage if i run
map -r. But serial port will start to work fine again.

If I run devices command, it is not shown as mass storage. but as linux
gadget.
Now if I use disconnect command, and followed by connect command to this
device with mass storage driver, I'm able to mount the mass storage and use
it.
The issue is present if I load my serial driver, which uses device's VID
PID. If I unload this driver and do the unplug-plug, I'm able to get mass
storage automatically..

What could be the issue? Is there any way to solve this?

(sorry for long post, it's difficult to explain otherwise)

Thanks again.
Regards,
Keshava

On Tue, 30 May 2017 at 20:56 Carsey, Jaben  wrote:

> I think that you will always need to inform the UEFI Shell of the change.
> It is not designed to automatically do detection of added/removed/changed
> devices.
>
>
>
> I think that your solution to use the code from mount makes the most sense.
>
>
>
> -Jaben
>
>
>
> *From:* GN Keshava [mailto:keshava...@gmail.com]
> *Sent:* Thursday, May 25, 2017 11:02 PM
> *To:* Carsey, Jaben ; edk2-devel@lists.01.org
> *Subject:* Re: [edk2] Unmount and mount a mass storage from shell
> *Importance:* High
>
>
>
> Hi Jaben, Thanks a lot for input. My necessity for unmount-mount is that,
> the USB client is a Linux storage gadget, which needs to be remounted to
> get the updated/new files created by Linux. Anyhow, now I'm doing this
> programmatically by copying mount command code from older shell. :)
>
>
>
> One more issue is that, after Linux updates some file (on client side,
> Linux will mount the same partition, save some file, and then umount the
> partition. Then if i remount the partition on Host side, when host is
> windows, i will get updated files) I will manually remove and connect the
> cable (MS device), UEFI is not able to detect the MS itself. (This issue
> observed, regardless of remount. This issue is not there on windows 10
> host).
>
> Can you give some pointers on this?
>
>
>
> Thanks a lot, Jaben.
>
>
>
> Regards,
>
> Keshava
>
>
>
> On Thu, 25 May 2017 at 21:26 Carsey, Jaben  wrote:
>
> You can "disconnect" the driver
> You can do "map -d" to delete a mapping
>
> I am unsure what your goals are for mount/unmount
>
> -Jaben
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > GN Keshava
> > Sent: Wednesday, May 24, 2017 10:59 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] Unmount and mount a mass storage from shell
> > Importance: High
> >
> > How can I unmount and mount a mass storage fs from UEFI shell?
> >
> > In older EFI shells, I can do with "mount" command. But it just does
> > "mapping" in newer shell. It doesn't actually remounting the device.
> >
> > Please help.
> >
> > thanks
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Xhci: Fill the 'interval' field for ISO endpoint context

[Zeng, Star]

Reviewed-by: Star Zeng 

BTW: Could you add the reference to the bugzilla link in the commit log?


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao Wu
Sent: Wednesday, May 31, 2017 9:48 AM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Baranee ; Zeng, Star 

Subject: [edk2] [PATCH] MdeModulePkg/Xhci: Fill the 'interval' field for ISO 
endpoint context

The commit fills the 'Interval' field of the Endpoint Context data for 
isochronous endpoints. It will resolve the error when a Configure Endpoint 
Command is sent to an isochronous endpoint.

Cc: Star Zeng 
Cc: Baranee 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 30 +-  
MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c | 30 +-
 2 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
index 4bec76a85f..58a2f984a9 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
@@ -2,7 +2,7 @@
 
   XHCI transfer scheduling routines.
 
-Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions of the BSD License  which accompanies this 
distribution.  The full text of the license may be found at @@ -2661,6 +2661,20 
@@ XhcInitializeEndpointContext (
   InputContext->EP[Dci-1].EPType = ED_ISOCH_OUT;
 }
 //
+// Get the bInterval from descriptor and init the the interval field 
of endpoint context.
+// Refer to XHCI 1.1 spec section 6.2.3.6.
+//
+if (DeviceSpeed == EFI_USB_SPEED_FULL) {
+  Interval = EpDesc->Interval;
+  ASSERT (Interval >= 1 && Interval <= 16);
+  InputContext->EP[Dci-1].Interval = Interval + 2;
+} else if ((DeviceSpeed == EFI_USB_SPEED_HIGH) || (DeviceSpeed == 
EFI_USB_SPEED_SUPER)) {
+  Interval = EpDesc->Interval;
+  ASSERT (Interval >= 1 && Interval <= 16);
+  InputContext->EP[Dci-1].Interval = Interval - 1;
+}
+
+//
 // Do not support isochronous transfer now.
 //
 DEBUG ((EFI_D_INFO, "XhcInitializeEndpointContext: Unsupport ISO EP 
found, Transfer ring is not allocated.\n")); @@ -2829,6 +2843,20 @@ 
XhcInitializeEndpointContext64 (
   InputContext->EP[Dci-1].EPType = ED_ISOCH_OUT;
 }
 //
+// Get the bInterval from descriptor and init the the interval field 
of endpoint context.
+// Refer to XHCI 1.1 spec section 6.2.3.6.
+//
+if (DeviceSpeed == EFI_USB_SPEED_FULL) {
+  Interval = EpDesc->Interval;
+  ASSERT (Interval >= 1 && Interval <= 16);
+  InputContext->EP[Dci-1].Interval = Interval + 2;
+} else if ((DeviceSpeed == EFI_USB_SPEED_HIGH) || (DeviceSpeed == 
EFI_USB_SPEED_SUPER)) {
+  Interval = EpDesc->Interval;
+  ASSERT (Interval >= 1 && Interval <= 16);
+  InputContext->EP[Dci-1].Interval = Interval - 1;
+}
+
+//
 // Do not support isochronous transfer now.
 //
 DEBUG ((EFI_D_INFO, "XhcInitializeEndpointContext64: Unsupport ISO EP 
found, Transfer ring is not allocated.\n")); diff --git 
a/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c 
b/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c
index 7a63dabd8c..3dd2b89097 100644
--- a/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c
@@ -2,7 +2,7 @@
 PEIM to produce gPeiUsb2HostControllerPpiGuid based on 
gPeiUsbControllerPpiGuid  which is used to enable recovery function from USB 
Drivers.
 
-Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials  are licensed and made available 
under the terms and conditions @@ -1750,6 +1750,20 @@ XhcPeiSetConfigCmd (
 InputContext->EP[Dci-1].EPType = ED_ISOCH_OUT;
   }
   //
+  // Get the bInterval from descriptor and init the the interval field 
of endpoint context.
+  // Refer to XHCI 1.1 spec section 6.2.3.6.
+  //
+  if (DeviceSpeed == EFI_USB_SPEED_FULL) {
+Interval = EpDesc->Interval;
+ASSERT (Interval >= 1 && Interval <= 16);
+InputContext->EP[Dci-1].Interval = Interval + 2;
+  } else if ((DeviceSpeed == EFI_USB_SPEED_HIGH) || (DeviceSpeed == 
EFI_USB_SPEED_SUPER)) {
+Interval = EpDesc->Interval;
+ASSERT (Interval >= 1 && Interval <= 16);
+InputContext->EP[Dci-1].Interval = Interval - 1;
+  }
+
+  //
   // Do not support isochronous transfe

[edk2] [PATCH] MdeModulePkg/Xhci: Remove TRB when canceling Async Int Transfer

[Ruiyu Ni]

Some USB devices don't report data periodically through Int
Transfer. They report data only when be asked. If the TRB
is not removed from the XHCI HW, when next time HOST asks
data again, the data is reported but consumed by the previous
TRB, which results the HOST thinks data never comes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao A Wu 
Cc: Star Zeng 
---
 MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
index 4bec76a85f..058e8f36ba 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
@@ -2,7 +2,7 @@
 
   XHCI transfer scheduling routines.
 
-Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -1319,6 +1319,7 @@ XhciDelAsyncIntTransfer (
   LIST_ENTRY  *Next;
   URB *Urb;
   EFI_USB_DATA_DIRECTION  Direction;
+  EFI_STATUS  Status;
 
   Direction = ((EpNum & 0x80) != 0) ? EfiUsbDataIn : EfiUsbDataOut;
   EpNum&= 0x0F;
@@ -1330,6 +1331,15 @@ XhciDelAsyncIntTransfer (
 if ((Urb->Ep.BusAddr == BusAddr) &&
 (Urb->Ep.EpAddr == EpNum) &&
 (Urb->Ep.Direction == Direction)) {
+  //
+  // Device doesn't finish the IntTransfer until real data comes
+  // So the TRB should be removed as well.
+  //
+  Status = XhcDequeueTrbFromEndpoint (Xhc, Urb);
+  if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, "XhciDelAsyncIntTransfer: 
XhcDequeueTrbFromEndpoint failed\n"));
+  }
+
   RemoveEntryList (&Urb->UrbList);
   FreePool (Urb->Data);
   XhcFreeUrb (Xhc, Urb);
@@ -1354,9 +1364,20 @@ XhciDelAllAsyncIntTransfers (
   LIST_ENTRY  *Entry;
   LIST_ENTRY  *Next;
   URB *Urb;
+  EFI_STATUS  Status;
 
   EFI_LIST_FOR_EACH_SAFE (Entry, Next, &Xhc->AsyncIntTransfers) {
 Urb = EFI_LIST_CONTAINER (Entry, URB, UrbList);
+
+  //
+  // Device doesn't finish the IntTransfer until real data comes
+  // So the TRB should be removed as well.
+  //
+Status = XhcDequeueTrbFromEndpoint (Xhc, Urb);
+if (EFI_ERROR (Status)) {
+  DEBUG ((EFI_D_ERROR, "XhciDelAllAsyncIntTransfers: 
XhcDequeueTrbFromEndpoint failed\n"));
+}
+
 RemoveEntryList (&Urb->UrbList);
 FreePool (Urb->Data);
 XhcFreeUrb (Xhc, Urb);
-- 
2.12.2.windows.2

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

Re: [edk2] [edk2-BuildSpecification PATCH] Update Precedence of PCD Values

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Saturday, May 27, 2017 11:44 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-BuildSpecification PATCH] Update Precedence of PCD Values

https://bugzilla.tianocore.org/show_bug.cgi?id=518

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 8_pre-build_autogen_stage/82_auto-generation_process.md | 7 +--
 README.md   | 3 ++-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/8_pre-build_autogen_stage/82_auto-generation_process.md 
b/8_pre-build_autogen_stage/82_auto-generation_process.md
index 5c2022b..7bca366 100644
--- a/8_pre-build_autogen_stage/82_auto-generation_process.md
+++ b/8_pre-build_autogen_stage/82_auto-generation_process.md
@@ -856,10 +856,10 @@ from different locations and different meta-data files. 
The following provides  the precedence (high to low) to assign a value to a PCD.
 
 * Command-line, `--pcd` flags (left most has higher priority)
-* FDF file, SET statements within a section
+* DSC file, Component INF `` section statements
 * FDF file, grammar describing automatic assignment of PCD values
+* FDF file, SET statements within a section
 * FDF file, SET statement in the [Defines] section
-* DSC file, Component INF `` section statements
 * DSC file, global [Pcd*] sections
 * INF file, PCD sections, Default Values
 * DEC file, PCD sections, Default Values @@ -1083,6 +1083,9 @@ II module:
 
   - Command-line, `--pcd` flags (left most has higher priority)
   - The DSC file's component INF scoping `` sections
+  - FDF file, grammar describing automatic assignment of PCD values
+  - FDF file, SET statements within a section
+  - FDF file, SET statement in the [Defines] section
   - The DSC file's `[Pcd*.arch.skuid]` sections
   - The DSC file's `[Pcd*.common.skuid]` sections
   - The DSC file's `[Pcd*.arch]` sections diff --git a/README.md b/README.md 
index 16fcc4a..43022c7 100644
--- a/README.md
+++ b/README.md
@@ -200,7 +200,7 @@ Copyright (c) 2008-2017, Intel Corporation. All rights 
reserved.
 || Remove Unicode file storage requirement; refer to the 
Multi-String UNI File Format Specification instead. 


  |   |
 || Clarify BUILDRULEORDER  



|   |
 || Add support for INF statement in an FD region.  



|   |
-| 1.27   | Convert to Gitbook  



| April 2017|
+| 1.27   | Convert to Gitbook  



| May 2017  |
 || [#471](https://bugzilla.tianocore.org/show_bug.cgi?id=471) 
Build spec: only copy the "TianoCore" Userextension section into "As Built" INF 


 |   |
 || [#472](https://bugzilla.tianocore.org/show_bug.cgi?id=472) 
[Build Spec] Extend macro usage in the !include statements for DSC/FDF files


   

Re: [edk2] [Qemu-devel] [PATCH v3 1/4] ACPI: Add APEI GHES Table Generation support

[gengdongjiu]

Laszlo,
   very sorry for that, it was my mistake that missing your name.
when I reply mail, I copy the "CC" list to the mail reply list, but forget to 
copy the "To" list.
I will check your comments in detailed later and reply you. thanks again.



On 2017/5/30 0:03, Laszlo Ersek wrote:
> Hi,
> 
> did you remove me from the To: / Cc: list intentionally, or was that an
> oversight? I caught your message in my list folders only by luck.
> 
> Some followup below:
> 
> On 05/29/17 17:27, gengdongjiu wrote:
> 
>>> (46) What is "physical_addr" good for? Below I can only see an 
>>> assignment to it, in ghes_update_guest(). Where is the field read?
> 
>> this "physical_addr" address is the physical error address in the
>> CPER. such as the physical address that happen hwpoison, this address
>> is delivered by the KVM and QEMU transfer this address to physical.
> I understand that in the ghes_update_guest() function, you accept a
> parameter called "physical_address", and you pass it on to
> ghes_generate_cper_record(). That makes sense, yes.
> 
> However, you also assign the same value to "ges.physical_addr". And that
> structure field is never read. So my point is that the
> "GhesErrorState.physical_addr" field is superfluous and should be removed.
> 
> I checked the other three patches in the series and they don't seem to
> read that structure member either. Correct me if I'm wrong.
> 
>>> (55) What happens if you run out of the preallocated memory?
> 
>> if it run out of the preallocated memory. it will overwrite other 
>> error source. every block's size is fixed. so it does not easy
>> dynamically extend the size if it is overflow. Anyway I will add a
>> error report if it happens overwrite.
> I understand (and agree) that dynamic allocation is not possible here.
> 
> But that doesn't justify overwriting the error status data block that
> belongs to a different data source. (Worse, if this happens with the
> last error status data block, for error source 10, you could overwrite
> memory that belongs to the OS.)
> 
> If an error status data block becomes full, then we should either wrap
> back to the start of the same data block, or else stop forwarding errors
> for that error source.
> 
> Does the ACPI spec say anything about this? I.e., about the case when
> the system runs out of the memory that was reserved for recording
> hardware errors?
> 
> +
> +mem_err = (struct cper_sec_mem_err *) (gdata + 1);
> +
> +/* In order to simplify simulation, hardcode the CPER section to 
> memory
> + * section.
> + */
> +mem_err->validation_bits |= CPER_MEM_VALID_ERROR_TYPE;
> +mem_err->error_type = 3;
>>>
>>> (58) Is this supposed to stand for "Multi-bit ECC" (from "N.2.5 Memory 
>>> Error Section" in UEFI 2.6)? Should we have a macro for that?
> 
>> Yes, it is. What do you mean a macro?
> 
> A #define for the integer value 3.
> 
>> For all the errors that happen in the guest OS, in order to simulate
>> easy, I abstract all the error section to memory section, even though
>> the error section is processor or other section.
> Why is that a valid thing to do? (I'm not doubting it is valid, I'm just
> asking.) Will that not confuse the ACPI subsystem of the guest OS?
> 
>> I do not know whether do you have some suggestion for that.
> Well I would have thought (without any expertise on the subject) that
> hardware errors from the host side should be mapped to the guest more or
> less "type correct". IOW, it looks strange that, say, a CPU error is
> reported as a memory error. But this is just an uneducated guess.
> 
> +mem_err->validation_bits |= CPER_MEM_VALID_CARD | 
> CPER_MEM_VALID_MODULE |
> +CPER_MEM_VALID_BANK | CPER_MEM_VALID_ROW |
> +CPER_MEM_VALID_COLUMN | CPER_MEM_VALID_BIT_POSITION;
> +mem_err->card = 1;
> +mem_err->module = 2;
> +mem_err->bank = 3;
> +mem_err->row = 1;
> +mem_err->column = 2;
> +mem_err->bit_pos = 5;
>>>
>>> (60) I have no idea where these values come from.
> 
>> For all the errors that happen in the guest OS, in order to simulate
>> easy, I abstract all the error section to memory section, and hard
>> code the memory section error value as above.
> Sure, but why is that safe? Will the guest OS not want to do something
> about these error details? If we are feeding the guest OS invalid error
> details, will that not lead to confusion?
> 
>>> (64) What does "reqr" stand for?
>> It stand for the request size.
> Can you please call it "req_size" or something similar? The English
> expression
> 
>   request size
> 
> contains only one "r" letter, so it's hard to understand where the
> second "r" in "reqr" comes from.
> 
> Thanks,
> Laszlo
> 
> .
> 

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

[edk2] [PATCH] Maintainers.txt: Update maintainers for DuetPkg & Nt32Pkg

[Hao Wu]

Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 Maintainers.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index f412b65691..39b5b67857 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -90,6 +90,7 @@ M: Ting Ye 
 DuetPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg
 M: Ruiyu Ni 
+M: Hao Wu 
 
 EdkCompatibilityPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/EdkCompatibilityPkg
@@ -168,6 +169,7 @@ M: Jiaxin Wu 
 Nt32Pkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/Nt32Pkg
 M: Ruiyu Ni 
+M: Hao Wu 
 
 Omap35xxPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/Omap35xxPkg
-- 
2.12.0.windows.1

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

Re: [edk2] [edk2-InfSpecification PATCH] Clarify that PCD values may come from the build command line

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Saturday, May 27, 2017 9:35 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-InfSpecification PATCH] Clarify that PCD values may come from 
the build command line

GitHub branch for review:

* 
https://github.com/mdkinney/edk2-InfSpecification/tree/Bugzilla_522_AddPcdValueFromCommandLine

GitHub word diff view of the patches in this series:

* [1/1] 
https://github.com/mdkinney/edk2-InfSpecification/commit/a7412993bd49ded0cc7069913bc5008d782a3597?w=1

https://bugzilla.tianocore.org/show_bug.cgi?id=522

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  Clarify that PCD values may come from the build command line

 2_inf_overview/214_pcd_sections.md | 7 ---
 README.md  | 3 ++-
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.6.3.windows.1

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

Re: [edk2] [edk2-BuildSpecification PATCH] Clarify that values of unused PCD are not evaluated

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Saturday, May 27, 2017 11:09 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-BuildSpecification PATCH] Clarify that values of unused PCD are 
not evaluated

https://bugzilla.tianocore.org/show_bug.cgi?id=481

GitHub branch for review:

* 
https://github.com/mdkinney/edk2-BuildSpecification/tree/Bugzilla_481_NoValueCheckOnUnreferrencedPcd

GitHub word diff view of the patches in this series:

* [1/1] 
https://github.com/mdkinney/edk2-BuildSpecification/commit/b6e588b374a707311d8fc6088daf458fbc02a3ca?w=1

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  Clarify that values of unused PCD are not evaluated

 13_build_reports/134_platform_summary.md | 5 +
 README.md| 1 +
 2 files changed, 6 insertions(+)

-- 
2.6.3.windows.1

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

Re: [edk2] [edk2-InfSpecification PATCH] Add LIB to supported file types in [Binaries] section

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Saturday, May 27, 2017 8:49 AM
To: edk2-devel@lists.01.org
Cc: Laszlo Ersek ; Gao, Liming ; Zhu, 
Yonghong ; Shaw, Kevin W 
Subject: [edk2-InfSpecification PATCH] Add LIB to supported file types in 
[Binaries] section

https://bugzilla.tianocore.org/show_bug.cgi?id=463

Cc: Laszlo Ersek 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_inf_overview/27_[binaries]_section.md| 7 ++-
 3_edk_ii_inf_file_format/315_[binaries]_section.md | 2 +-
 README.md  | 3 ++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/2_inf_overview/27_[binaries]_section.md 
b/2_inf_overview/27_[binaries]_section.md
index f117340..993b836 100644
--- a/2_inf_overview/27_[binaries]_section.md
+++ b/2_inf_overview/27_[binaries]_section.md
@@ -74,7 +74,7 @@ The formats for entries in this section are:
 ```
 FileType|Relative/path/and/filename.ext|DEBUG|GCC|UNIXGCC|TRUE
 FileType|Filename.ext|*|GCC
-FIleType|Relative/path/and/filename.ext|RELEASE
+FileType|Relative/path/and/filename.ext|RELEASE
 FileType|Filename.ext|RELEASE
 FileType|Filename.ext
 ```
@@ -170,6 +170,11 @@ This binary is an `EFI_SECTION_COMPATIBILTY16 leaf` 
section.
 
 This binary is an `EFI_SECTION_FIRMWARE_VOLUME_IMAGE` leaf section.
 
+**_LIB_**
+
+This binary is a pre-built library instance that provides the library 
+class defined in the `LIBRARY_CLASS` statement in the `[Defines]` section.
+
 **
 **Note:** The section names listed above refer to leaf section type values  
rather than the name of the data structure.
diff --git a/3_edk_ii_inf_file_format/315_[binaries]_section.md 
b/3_edk_ii_inf_file_format/315_[binaries]_section.md
index 7a03547..d6d57f2 100644
--- a/3_edk_ii_inf_file_format/315_[binaries]_section.md
+++ b/3_edk_ii_inf_file_format/315_[binaries]_section.md
@@ -110,7 +110,7 @@ included in any one `[Binaries]` section.
::= {"ACPI"} {"ASL"} {"PE32"} {"PIC"} {"FV"}
  {"PEI_DEPEX"} {"DXE_DEPEX"} {"SMM_DEPEX"}
  {"TE"} {"BIN"} {"RAW"} {"COMPAT16"}
- {"DISPOSABLE"}
+ {"DISPOSABLE"} {"LIB"}
 ```
 
  Parameters
diff --git a/README.md b/README.md
index 57e05d2..e2ffcb9 100644
--- a/README.md
+++ b/README.md
@@ -192,4 +192,5 @@ Copyright (c) 2007-2017, Intel Corporation. All rights 
reserved.
 || Updated other sections to specify how the build system will 
evaluate the Feature Flag Expression

|   |
 || Prohibit using #include statements in UNI files specified in 
the MODULE_UNI_FILE entry   

   |   |
 | 1.25   | Revised WORKSPACE wording for updated build system that can 
handle packages located outside of the WORKSPACE directory tree (refer to the 
TianoCore.org/EDKII website for additional instructions on setting up a 
development environment). | January 
2016  |
-| 1.26   | Convert to GitBooks 


| March 2017|
+| 1.26   | Convert to GitBooks 


| May 2017  |
+|| [#463](https://bugzilla.tianocore.org/show_bug.cgi?id=463) INF 
spec: document the LIB file type under the [Binaries] Section   

 |   |
--
2.6.3.windows.1

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

Re: [edk2] [edk2-BuildSpecification PATCH] Add BrotliCompress and Pkcs7Sign GUIDed tools

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Saturday, May 27, 2017 12:04 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-BuildSpecification PATCH] Add BrotliCompress and Pkcs7Sign 
GUIDed tools

https://bugzilla.tianocore.org/show_bug.cgi?id=517

GitHub branch for review:

* 
https://github.com/mdkinney/edk2-BuildSpecification/tree/Bugzilla_517_GuidedToolsBrotliPkcs7Sign

GitHub word diff view of the patches in this series:

* [1/1] 
https://github.com/mdkinney/edk2-BuildSpecification/commit/f030b1e840b253afeca87d6aa30f93828398f2ae?w=1

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 

Michael Kinney (1):
  Add BrotliCompress and Pkcs7Sign GUIDed tools

 5_meta-data_file_specifications/52_tools_def_txt.md | 12 
 README.md   |  3 ++-
 2 files changed, 14 insertions(+), 1 deletion(-)

-- 
2.6.3.windows.1

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

[edk2] [PATCH] MdeModulePkg/Xhci: Fill the 'interval' field for ISO endpoint context

[Hao Wu]

The commit fills the 'Interval' field of the Endpoint Context data for
isochronous endpoints. It will resolve the error when a Configure
Endpoint Command is sent to an isochronous endpoint.

Cc: Star Zeng 
Cc: Baranee 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 30 +-
 MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c | 30 +-
 2 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
index 4bec76a85f..58a2f984a9 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
@@ -2,7 +2,7 @@
 
   XHCI transfer scheduling routines.
 
-Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -2661,6 +2661,20 @@ XhcInitializeEndpointContext (
   InputContext->EP[Dci-1].EPType = ED_ISOCH_OUT;
 }
 //
+// Get the bInterval from descriptor and init the the interval field 
of endpoint context.
+// Refer to XHCI 1.1 spec section 6.2.3.6.
+//
+if (DeviceSpeed == EFI_USB_SPEED_FULL) {
+  Interval = EpDesc->Interval;
+  ASSERT (Interval >= 1 && Interval <= 16);
+  InputContext->EP[Dci-1].Interval = Interval + 2;
+} else if ((DeviceSpeed == EFI_USB_SPEED_HIGH) || (DeviceSpeed == 
EFI_USB_SPEED_SUPER)) {
+  Interval = EpDesc->Interval;
+  ASSERT (Interval >= 1 && Interval <= 16);
+  InputContext->EP[Dci-1].Interval = Interval - 1;
+}
+
+//
 // Do not support isochronous transfer now.
 //
 DEBUG ((EFI_D_INFO, "XhcInitializeEndpointContext: Unsupport ISO EP 
found, Transfer ring is not allocated.\n"));
@@ -2829,6 +2843,20 @@ XhcInitializeEndpointContext64 (
   InputContext->EP[Dci-1].EPType = ED_ISOCH_OUT;
 }
 //
+// Get the bInterval from descriptor and init the the interval field 
of endpoint context.
+// Refer to XHCI 1.1 spec section 6.2.3.6.
+//
+if (DeviceSpeed == EFI_USB_SPEED_FULL) {
+  Interval = EpDesc->Interval;
+  ASSERT (Interval >= 1 && Interval <= 16);
+  InputContext->EP[Dci-1].Interval = Interval + 2;
+} else if ((DeviceSpeed == EFI_USB_SPEED_HIGH) || (DeviceSpeed == 
EFI_USB_SPEED_SUPER)) {
+  Interval = EpDesc->Interval;
+  ASSERT (Interval >= 1 && Interval <= 16);
+  InputContext->EP[Dci-1].Interval = Interval - 1;
+}
+
+//
 // Do not support isochronous transfer now.
 //
 DEBUG ((EFI_D_INFO, "XhcInitializeEndpointContext64: Unsupport ISO EP 
found, Transfer ring is not allocated.\n"));
diff --git a/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c 
b/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c
index 7a63dabd8c..3dd2b89097 100644
--- a/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c
@@ -2,7 +2,7 @@
 PEIM to produce gPeiUsb2HostControllerPpiGuid based on gPeiUsbControllerPpiGuid
 which is used to enable recovery function from USB Drivers.
 
-Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -1750,6 +1750,20 @@ XhcPeiSetConfigCmd (
 InputContext->EP[Dci-1].EPType = ED_ISOCH_OUT;
   }
   //
+  // Get the bInterval from descriptor and init the the interval field 
of endpoint context.
+  // Refer to XHCI 1.1 spec section 6.2.3.6.
+  //
+  if (DeviceSpeed == EFI_USB_SPEED_FULL) {
+Interval = EpDesc->Interval;
+ASSERT (Interval >= 1 && Interval <= 16);
+InputContext->EP[Dci-1].Interval = Interval + 2;
+  } else if ((DeviceSpeed == EFI_USB_SPEED_HIGH) || (DeviceSpeed == 
EFI_USB_SPEED_SUPER)) {
+Interval = EpDesc->Interval;
+ASSERT (Interval >= 1 && Interval <= 16);
+InputContext->EP[Dci-1].Interval = Interval - 1;
+  }
+
+  //
   // Do not support isochronous transfer now.
   //
   DEBUG ((EFI_D_INFO, "XhcPeiSetConfigCmd: Unsupport ISO EP found, 
Transfer ring is not allocated.\n"));
@@ -1953,6 +1967,20 @@ XhcPeiSetConfigCmd64 (
 InputContext->EP[Dci-1].EPType = ED_ISOCH_OUT;
   }
   //
+  // Get the bInterval from descriptor and init the the interval field 
of endpoint context.
+  // Refer to XHCI 1.1 spec section 6.2.3.6.
+  

Re: [edk2] [edk2-DscSpecification PATCH] Allow mixed PCD access methods

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Sunday, May 28, 2017 4:03 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-DscSpecification PATCH] Allow mixed PCD access methods

https://bugzilla.tianocore.org/show_bug.cgi?id=521

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_dsc_overview/28_pcd_section_processing.md  | 12 ++--  
3_edk_ii_dsc_file_format/310_pcd_sections.md | 15 +++
 README.md|  5 +++--
 3 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/2_dsc_overview/28_pcd_section_processing.md 
b/2_dsc_overview/28_pcd_section_processing.md
index 60e7de7..0969b41 100644
--- a/2_dsc_overview/28_pcd_section_processing.md
+++ b/2_dsc_overview/28_pcd_section_processing.md
@@ -103,10 +103,18 @@ of three categories:
 **Note:** For the dynamic types of PCDs, using an `$(Arch)` extension other  
than `common` in the section header is not valid.
 **
-**Warning:** A PCD can only use one type for all modules. It is not 
permissible -to list a PCD in a PcdsFixedAtBuild section and also list it in a
+**Warning:** A PCD can only use one type for all source modules. It is 
+not permissible to list a PCD in a PcdsFixedAtBuild section and also 
+list it in a
 PcdsPatchableInModule section.
 **
+**Note:** Binary modules included in a platform build are permitted to 
+use the PatchableInModule or DynamicEx access methods (the Binary 
+module must specify which of these two methods were used to create the 
+binary module) regardless of the method used for a given PCD in modules 
+built from source. The build supports binary modules that use the same 
+or different PCD access method than the source modules or other binary 
+modules. The build parser must break with an error if a PCD is listed as 
FixedAtBuild or Dynamic (not DynamicEx) in the Binary INF.
+**
 
 Datum Types for PCD values are either Boolean (`BOOLEAN` - 1 byte), numeric  
(`UINT8` - 1 byte, `UINT16` - 2 bytes, `UINT32` - 4 bytes or `UINT64` - 8 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 bf20cc5..c061e5b 100644
--- a/3_edk_ii_dsc_file_format/310_pcd_sections.md
+++ b/3_edk_ii_dsc_file_format/310_pcd_sections.md
@@ -75,10 +75,17 @@ value specified in the INF file or the default value listed 
in the DEC file  (for modules that do not list a preferred value). This same 
rule applies to  `FeatureFlag` PCDs.
 
-If the INF values differ (or are not listed) and the access methods are 
-different, then the build must break. A PCD can only use a single method of 
-access for the platform and all modules in the platform that use the PCD must 
-use the same access method.
+If the Source INF values differ (or are not listed) and the access 
+methods are different, then the build must break. All source modules in 
+a platform must use the same PCD same access method.
+
+Binary modules included in a platform build are permitted to use the 
+PatchableInModule or DynamicEx access methods (the Binary module must 
+specify which of these two methods were used to create the binary 
+module) regardless of the method used for a given PCD in modules built 
+from source. The build supports binary modules that use the same or 
+different PCD access method than the source modules or other binary 
+modules. The build parser must break with an error if a PCD is listed as 
FixedAtBuild or Dynamic (not DynamicEx) in the Binary INF.
 
 If no value is entered in the DSC file, and no INF files provide a preferred  
value, then the DEC file's default value must be used.
diff --git a/README.md b/README.md
index 1d1f99c..eb6966f 100644
--- a/README.md
+++ b/README.md
@@ -176,7 +176,8 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || Update the DSC_SPECIFICATION version to 0x0001001A  


 ||
 || Revised WORKSPACE wording for updated build system that can 
handle packages located outside of the WORKSPACE directory tree (refer to the 
TianoCore.org/ EDKII website for additional instructions on setting up a 
development environment). | 
   |
 || Added new system environment variables used by the build 
system. 

|   
 |
-| 1.27   | Con

Re: [edk2] [edk2-DscSpecification PATCH] Update Precedence of PCD Values

[Zhu, Yonghong]

Hi Mike,

1. Is this 'p' typo error is sentence "DSC file, p FeatureFlag, 
PatchableInModule or FixedAtBuild PCD value"?
2. How about remove the "FeatureFlag, PatchableInModule or FixedAtBuild" from 
below sentence since current Dynamic/DynamicEx also can have the specific arch 
info.
"DSC file, a FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined 
in a PCD access method section with an architectural modifier"

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Sunday, May 28, 2017 3:35 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-DscSpecification PATCH] Update Precedence of PCD Values

https://bugzilla.tianocore.org/show_bug.cgi?id=519

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_dsc_overview/28_pcd_section_processing.md | 56 ++---
 README.md   |  5 +--
 2 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/2_dsc_overview/28_pcd_section_processing.md 
b/2_dsc_overview/28_pcd_section_processing.md
index 60e7de7..3736cde 100644
--- a/2_dsc_overview/28_pcd_section_processing.md
+++ b/2_dsc_overview/28_pcd_section_processing.md
@@ -312,45 +312,45 @@ string plus 1 byte for the null terminator, for L"string" 
entries to be the  length of the UCS-2 character string plus 2 bytes for the 
null terminator and  the exact length of a byte array.
 
-Precedence for determining PCD values (high to low, last in position) is as
-follows:
+The values that are assigned to individual PCDs required by a build may 
+come from different locations and different meta-data files. The 
+following provides the precedence (high to low) to assign a value to a PCD.
 
-* A PCD value defined by a MACRO, ("MacroName" in this example), and the Macro
-  is defined on the command-line using -D MacroName=Value
+* Command-line, `--pcd` flags (left most has higher priority)
 
-* A PCD value defined in the FDF file SET statements
+* DSC file, p FeatureFlag, PatchableInModule or FixedAtBuild PCD value 
+defined
+  in the `[Components]` INF scoping `` section statements
 
-* A PCD value defined positionally in the FDF file
+* FDF file, grammar describing automatic assignment of PCD values
 
-* A FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined in the
-  `[Components]` INF scoping section
+* FDF file, SET statements within a section
 
-* A FeatureFlag, PatchableInModule or FixedAtBuild PCD value defined in a PCD
-  access method section with an architectural modifier (the access method for a
-  PCD in a section with an architectural modifier takes precedence over any
-  other access method)
+* FDF file, SET statement in the [Defines] section
 
-In this example, modules built for IA32 architecture, the PCD will use 
-PatchableInModule access, while modules built for all other architectures, the 
-PCD will use the FixedAtBuild access method:
+* DSC file, a FeatureFlag, PatchableInModule or FixedAtBuild PCD value 
+defined
+  in a PCD access method section with an architectural modifier.
 
-```ini
-[PcdsFixedAtBuild.common]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
-  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
+  In this example, modules built for IA32 architecture, the PCD will 
+ use  PatchableInModule access, while modules built for all other 
+ architectures, the  PCD will use the FixedAtBuild access method:
 
-[PcdsPatchableInModule.IA32]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
-  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
-```
+  ```ini
+  [PcdsFixedAtBuild.common]
+gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|F
+ ALSE
+
+  [PcdsPatchableInModule.IA32]
+gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
+
+ gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|F
+ ALSE
+  ```
 
-* A PCD value defined in a PCD access method (item type) section for common
-  architectures
+* DSC file, A PCD value defined in a PCD access method (item type) 
+global
+  `[Pcd*]` section for common architectures.
 
-* A PCD value defined in an INF (provided all INF files have defined the same
-  value)
+* INF file, PCD sections, Default Values (provided all INF files have 
+defined
+  the same value)
 
-* A PCD default value defined in the DEC file that declares the PCD.
+* DEC file, PCD sections, Default Values
 
 **
 **Note:** Dynamic or DynamicEx PCD sections with architectural modifiers is 
not diff --git a/README.md b/README.md index 1d1f99c..3bec3b3 100644
--- a/README.md
+++ b/README.md
@@ -176,7 +176,8 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || Update the DSC_SPECIFICATION version to 0x0001001A  
  

Re: [edk2] [edk2-FdfSpecification PATCH] Update Precedence of PCD Values

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Kinney, Michael D 
Sent: Sunday, May 28, 2017 2:10 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong ; 
Shaw, Kevin W 
Subject: [edk2-FdfSpecification PATCH] Update Precedence of PCD Values

https://bugzilla.tianocore.org/show_bug.cgi?id=520

Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Kinney 
---
 2_fdf_design_discussion/21_processing_overview.md | 26 +++
 README.md |  3 ++-
 2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/2_fdf_design_discussion/21_processing_overview.md 
b/2_fdf_design_discussion/21_processing_overview.md
index ddef010..7a045dd 100644
--- a/2_fdf_design_discussion/21_processing_overview.md
+++ b/2_fdf_design_discussion/21_processing_overview.md
@@ -105,13 +105,31 @@ warning message on the PCD defined in the DSC file. 
Default values from DEC  files are not permitted in the EDK II build system for 
PCDs specified in the  FDF file.
 
-PCD values set in this file override PCD settings in other EDK II meta-data 
-files. Note that PCDs settings are positional within the FDF file.
-
-Additionally, the PCDs used in the FDF file must be specified as:
+The PCDs used in the FDF file must be specified as:
 
 `PcdTokenSpaceGuidCName.PcdCName`
 
+### 2.1.2 Precedence of PCD Values
+
+The values that are assigned to individual PCDs required by a build may 
+come from different locations and different meta-data files. The 
+following provides the precedence (high to low) to assign a value to a PCD.
+
+* Command-line, `--pcd` flags (left most has higher priority)
+* DSC file, Component INF `` section statements
+* FDF file, grammar describing automatic assignment of PCD values
+* FDF file, SET statements within a section
+* FDF file, SET statement in the [Defines] section
+* DSC file, global [Pcd*] sections
+* INF file, PCD sections, Default Values
+* DEC file, PCD sections, Default Values
+
+In addition to the above precedence rules, PCDs set in sections with 
+architectural modifiers take precedence over PCD sections that are 
+common to all architectures.
+
+If a PCD is listed in the same section multiple times, the last one is used.
+
  PCD RULES
 
 There are no PCD sections defined for the FDF file. PCD values are assigned in 
diff --git a/README.md b/README.md index 131246d..bad0930 100644
--- a/README.md
+++ b/README.md
@@ -194,7 +194,7 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || PACKAGES_PATH and EDK_TOOLS_BIN, used by the build system.  

   |   |
 || Allow INF statements in FD regions. 

   |   |
 || Clarified [UserExtensions] content in chapter 2 (to match 
implementation) 
 |   |
-| 1.28   | Convert to GitBooks 

   | April 2017|
+| 1.28   | Convert to GitBooks 

   | May 2017  |
 || [#426](https://bugzilla.tianocore.org/show_bug.cgi?id=426) 
IMAGE_TYPE_ID must be provided with value, FDF should mark it as required 
section   |   |
 || [#373](https://bugzilla.tianocore.org/show_bug.cgi?id=373) 
Conditional statement examples incorrect
|   |
 || [#461](https://bugzilla.tianocore.org/show_bug.cgi?id=461) FDF 
Spec: add a super script number for the
|   |
@@ -206,3 +206,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 || [#142](https://bugzilla.tianocore.org/show_bug.cgi?id=142) 
Update EDK II FDF Specification to allow sections in any order  
|   |
 || [#478](https://bugzilla.tianocore.org/show_bug.cgi?id=478) FDF 
spec: extend the  to support  and  
|   |
 || [#353](https://bugzilla.tianocore.org/show_bug.cgi?id=353) 
Build spec: Allow nested includes in DSC and FDF files  
|   |
+|| [#520](https://bugzilla.tianocore.org/show_bug

Re: [edk2] Localization help need: national symbols are not displayed on BIOS screen after adding a new language

[Kinney, Michael D]

Nikolay,

I suspect you do not have the glyphs to support the Unicode characters
you are attempting to display.

The default HII Font Package is produced by the module:

  MdeModulePkg\Universal\Console\GraphicsConsoleDxe

The file LaffStd.c contains the glyphs required for some Unicode
characters.

You can either extend that file or produce the additional glyphs you
require from a different module that produces an additional HII Font
Package.

Best regards,

Mike

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Nikolay 
Bodunov
Sent: Tuesday, May 30, 2017 5:04 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Localization help need: national symbols are not displayed on 
BIOS screen after adding a new language

Hello

I added 3 new languages in MdeModulePks/Application/UiApp example from EDK2
and I got a problem with strings output. Using Nt32Pkg emulator with Win 7.

My problem is: when I add Russian language, I also add new string on that
language to existing token, but I can't see that string shown on screen.
Specifically, I can see English part of the string only.
I mean, if I write the first half of the string on English and the second
half on Russian, I can see only English half of the string on BIOS screen.
Here are my problem on the screenshot:
https://yadi.sk/i/mgh_-dBH3JbYtp
I didn't added corresponding Russian strings to any other tokens, so
displaying "!" instead for them is ok. If I switch back to English or
French, correct strings are shown again.

What I did:
1. Added new languages in MdePkg.dec:
  gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultPlatform
LangCodes|"en;fr;en-US;fr-FR;ru;de;zh-cn"|VOID*|0x001e

2. Opened UNI file in Notepad++ and added new languages, after English and
French:
#langdef   en-US "English"
#langdef   fr-FR "Francais"
#langdef   en"Standard English"
#langdef   fr"Standard Francais"
#langdef   ru"Russian"
//#langdef   ru-RU "Russian"
#langdef   de"German"
#langdef   zh-cn "Chinese (PRC)"

3. Switched (in Windows 7) on Russian codepage and added new string for
"ru" locale that token "STR_LANGUAGE_SELECT"
https://yadi.sk/i/quf2Gd003JbZez

I also located my string in .efi output file in HEX to investigate what
could be wrong, but I see exactly what I expected: codepage 04 and symbol
codes which conforms corresponding Russian symbols in UCS-2: 2004 4304 4104
4104 3A04 3804 3904 (and English symbols, too):
https://yadi.sk/i/QIEqcqKg3JbaiL

>From the other side, I got support for German locale in that way, having
typical German symbols in string attached ot that token.

Any suggestions, what I did wrong or what I should do else? I suppose there
should be some "magical" function call that adds more than one locale, but
I don't know what it is.
Maybe default font just does not support Russian locale? Which font should
I use instead and where I can read about it? Text search in EDK2 source
tree does't find string "ru-RU"

I cannot diagnose it in programming way: when I add non-existing locale
"xz" to MdePkg.dec, I have no error during compilation and I can see this
pseudo-locale in PlatformLangCodes variable then.

With best regards,
Nikolay Bodunov
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Localization help need: national symbols are not displayed on BIOS screen after adding a new language

[Nikolay Bodunov]

Hello

I added 3 new languages in MdeModulePks/Application/UiApp example from EDK2
and I got a problem with strings output. Using Nt32Pkg emulator with Win 7.

My problem is: when I add Russian language, I also add new string on that
language to existing token, but I can't see that string shown on screen.
Specifically, I can see English part of the string only.
I mean, if I write the first half of the string on English and the second
half on Russian, I can see only English half of the string on BIOS screen.
Here are my problem on the screenshot:
https://yadi.sk/i/mgh_-dBH3JbYtp
I didn't added corresponding Russian strings to any other tokens, so
displaying "!" instead for them is ok. If I switch back to English or
French, correct strings are shown again.

What I did:
1. Added new languages in MdePkg.dec:
  gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultPlatform
LangCodes|"en;fr;en-US;fr-FR;ru;de;zh-cn"|VOID*|0x001e

2. Opened UNI file in Notepad++ and added new languages, after English and
French:
#langdef   en-US "English"
#langdef   fr-FR "Francais"
#langdef   en"Standard English"
#langdef   fr"Standard Francais"
#langdef   ru"Russian"
//#langdef   ru-RU "Russian"
#langdef   de"German"
#langdef   zh-cn "Chinese (PRC)"

3. Switched (in Windows 7) on Russian codepage and added new string for
"ru" locale that token "STR_LANGUAGE_SELECT"
https://yadi.sk/i/quf2Gd003JbZez

I also located my string in .efi output file in HEX to investigate what
could be wrong, but I see exactly what I expected: codepage 04 and symbol
codes which conforms corresponding Russian symbols in UCS-2: 2004 4304 4104
4104 3A04 3804 3904 (and English symbols, too):
https://yadi.sk/i/QIEqcqKg3JbaiL

>From the other side, I got support for German locale in that way, having
typical German symbols in string attached ot that token.

Any suggestions, what I did wrong or what I should do else? I suppose there
should be some "magical" function call that adds more than one locale, but
I don't know what it is.
Maybe default font just does not support Russian locale? Which font should
I use instead and where I can read about it? Text search in EDK2 source
tree does't find string "ru-RU"

I cannot diagnose it in programming way: when I add non-existing locale
"xz" to MdePkg.dec, I have no error during compilation and I can see this
pseudo-locale in PlatformLangCodes variable then.

With best regards,
Nikolay Bodunov
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Vladimir Olovyannikov]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: May-30-17 1:17 PM
> To: Vladimir Olovyannikov; edk2-devel@lists.01.org
> Cc: Ard Biesheuvel
> Subject: Re: [edk2] Using a generic PciHostBridgeDxe driver for a
> multi-PCIe-
> domain platform
>
> On 05/30/17 21:04, Vladimir Olovyannikov wrote:
>
> > So basically my PciHostBridgeLib should treat hostbridges as
> > rootbridges with different segments in this case?
>
> In my opinion, yes.
>
> I would actually put it as
>
>   treat the set of sole root bridges on all the host bridges as multiple
>   root bridges on a single host bridge, just with different segment
>   numbers
>
> The separate segment numbers should be mapped to the separate ECAM
> windows in your PciSegmentLib instance, in my opinion.
OK, got it. Thanks a lot for your help!
>
> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Laszlo Ersek]

On 05/30/17 21:04, Vladimir Olovyannikov wrote:

> So basically my PciHostBridgeLib should treat hostbridges as
> rootbridges with different segments in this case?

In my opinion, yes.

I would actually put it as

  treat the set of sole root bridges on all the host bridges as multiple
  root bridges on a single host bridge, just with different segment
  numbers

The separate segment numbers should be mapped to the separate ECAM
windows in your PciSegmentLib instance, in my opinion.

Thanks,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Vladimir Olovyannikov]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: May-30-17 11:50 AM
> To: Vladimir Olovyannikov; edk2-devel@lists.01.org
> Cc: Ard Biesheuvel
> Subject: Re: [edk2] Using a generic PciHostBridgeDxe driver for a
> multi-PCIe-
> domain platform
>
> On 05/30/17 20:32, Laszlo Ersek wrote:
> > On 05/30/17 18:23, Vladimir Olovyannikov wrote:
> >> Hi,
> >>
> >> I've started PCIe stack implementation design for an armv8 aarch64
> >> platform.
> >> The platform's PCIe represents several host bridges, and each
> >> hostbridge has one rootbridge.
> >> They do not share any resources between each other.
> >> Looking into the PciHostBridgeDxe implementation I can see that it
> >> supports only one hostbridge, and there is a comment:
> >> // Most systems in the world including complex servers have only one
> >> Host Bridge.
> >>
> >> So in my case should I create my own PciHostBridgeDxe driver
> >> supporting multiple hostbridges and do not use the Industry standard
> driver?
> >> I am very new to it, and will appreciate any help or idea.
> >
> > I think you can use PciHostBridgeDxe on this platform:
> >
> > - Implement a PciHostBridgeLib instance (see
> > ) that returns
> > PCI_ROOT_BRIDGE objects with different Segment fields, from
> > PciHostBridgeGetRootBridges().
> >
> > - Implement a PciSegmentLib instance (see
> > ) that routes the config space
> > addresses, encoded by the PCI_SEGMENT_LIB_ADDRESS() macro,
> according
> > to your platform.
> >
> > PciHostBridgeDxe and PciBusDxe should "just work" atop. To my
> > understanding, PciBusDxe delegates all config space accesses to
> > PciHostBridgeDxe, via EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL. And
> > PciHostBridgeDxe delegates all config space accesses to the platform's
> > PciSegmentLib.
>
> A small addition. Assuming the general case, i.e. when you have a
> different
> number of root bridges on each of several host bridges, you still have to
> number all those root bridges incrementally, in a curious, flat address
> space.
> And that address space is the PcieRoot(N) device path node that is
> supposed
> to start the "DevicePath" member of each PCI_ROOT_BRIDGE object that
> you return from PciHostBridgeGetRootBridges().
>
> You can read about the PcieRoot() devpath node in the UEFI 2.6 spec.
> Basically, you have
>
> ACPI_HID_DEVICE_PATH.Header = ;
> ACPI_HID_DEVICE_PATH.HID = EFI_PNP_ID (0x0a08);
> ACPI_HID_DEVICE_PATH.UID = ;
>
> The UID values used in these devpath nodes should preferably match the
> UID values of the corresponding PCI Express Root Bridge objects
> (=PNP0A08) that you expose in your ACPI tables (DSDT and/or SSDT).
Thanks for explanation Laszlo,
In my case every hostbridge has exactly one rootbridge. I will follow your
advice and will create
SegmentPciLib and platform's PciHostBridgeLib.
So basically my PciHostBridgeLib should treat hostbridges as rootbridges
with different segments in this case?
>
> Thanks
> Laszlo

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Laszlo Ersek]

On 05/30/17 20:32, Laszlo Ersek wrote:
> On 05/30/17 18:23, Vladimir Olovyannikov wrote:
>> Hi,
>>
>> I've started PCIe stack implementation design for an armv8 aarch64
>> platform.
>> The platform's PCIe represents several host bridges, and each hostbridge
>> has one rootbridge.
>> They do not share any resources between each other.
>> Looking into the PciHostBridgeDxe implementation I can see that it
>> supports only one hostbridge, and there is a comment:
>> // Most systems in the world including complex servers have only one Host
>> Bridge.
>>
>> So in my case should I create my own PciHostBridgeDxe driver supporting
>> multiple hostbridges and do not use the Industry standard driver?
>> I am very new to it, and will appreciate any help or idea.
> 
> I think you can use PciHostBridgeDxe on this platform:
> 
> - Implement a PciHostBridgeLib instance (see
> ) that returns
> PCI_ROOT_BRIDGE objects with different Segment fields, from
> PciHostBridgeGetRootBridges().
> 
> - Implement a PciSegmentLib instance (see
> ) that routes the config space
> addresses, encoded by the PCI_SEGMENT_LIB_ADDRESS() macro, according to
> your platform.
> 
> PciHostBridgeDxe and PciBusDxe should "just work" atop. To my
> understanding, PciBusDxe delegates all config space accesses to
> PciHostBridgeDxe, via EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL. And
> PciHostBridgeDxe delegates all config space accesses to the platform's
> PciSegmentLib.

A small addition. Assuming the general case, i.e. when you have a
different number of root bridges on each of several host bridges, you
still have to number all those root bridges incrementally, in a curious,
flat address space. And that address space is the PcieRoot(N) device
path node that is supposed to start the "DevicePath" member of each
PCI_ROOT_BRIDGE object that you return from PciHostBridgeGetRootBridges().

You can read about the PcieRoot() devpath node in the UEFI 2.6 spec.
Basically, you have

ACPI_HID_DEVICE_PATH.Header = ;
ACPI_HID_DEVICE_PATH.HID = EFI_PNP_ID (0x0a08);
ACPI_HID_DEVICE_PATH.UID = ;

The UID values used in these devpath nodes should preferably match the
UID values of the corresponding PCI Express Root Bridge objects
(=PNP0A08) that you expose in your ACPI tables (DSDT and/or SSDT).

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Laszlo Ersek]

On 05/30/17 18:23, Vladimir Olovyannikov wrote:
> Hi,
> 
> I've started PCIe stack implementation design for an armv8 aarch64
> platform.
> The platform's PCIe represents several host bridges, and each hostbridge
> has one rootbridge.
> They do not share any resources between each other.
> Looking into the PciHostBridgeDxe implementation I can see that it
> supports only one hostbridge, and there is a comment:
> // Most systems in the world including complex servers have only one Host
> Bridge.
> 
> So in my case should I create my own PciHostBridgeDxe driver supporting
> multiple hostbridges and do not use the Industry standard driver?
> I am very new to it, and will appreciate any help or idea.

I think you can use PciHostBridgeDxe on this platform:

- Implement a PciHostBridgeLib instance (see
) that returns
PCI_ROOT_BRIDGE objects with different Segment fields, from
PciHostBridgeGetRootBridges().

- Implement a PciSegmentLib instance (see
) that routes the config space
addresses, encoded by the PCI_SEGMENT_LIB_ADDRESS() macro, according to
your platform.

PciHostBridgeDxe and PciBusDxe should "just work" atop. To my
understanding, PciBusDxe delegates all config space accesses to
PciHostBridgeDxe, via EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL. And
PciHostBridgeDxe delegates all config space accesses to the platform's
PciSegmentLib.

Thanks,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Vladimir Olovyannikov]

> -Original Message-
> From: Bill Paul [mailto:wp...@windriver.com]
> Sent: May-30-17 10:34 AM
> To: edk2-de...@ml01.01.org
> Cc: Vladimir Olovyannikov; Ard Biesheuvel; edk2-de...@ml01.01.org
> Subject: Re: [edk2] Using a generic PciHostBridgeDxe driver for a
multi-PCIe-
> domain platform
>
> Of all the gin joints in all the towns in all the world, Vladimir
Olovyannikov had
> to walk into mine at 09:49:16 on Tuesday 30 May 2017 and say:
>
> > > -Original Message-
> > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > > Sent: May-30-17 9:35 AM
> > > To: Vladimir Olovyannikov
> > > Cc: edk2-devel@lists.01.org
> > > Subject: Re: Using a generic PciHostBridgeDxe driver for a
> > > multi-PCIe-domain platform
> > >
> > > On 30 May 2017 at 16:23, Vladimir Olovyannikov
> > >
> > >  wrote:
> > > > Hi,
> > > >
> > > > I've started PCIe stack implementation design for an armv8 aarch64
> > > > platform.
> > > > The platform's PCIe represents several host bridges, and each
> > > > hostbridge has one rootbridge.
> > > > They do not share any resources between each other.
> > > > Looking into the PciHostBridgeDxe implementation I can see that it
> > > > supports only one hostbridge, and there is a comment:
> > > > // Most systems in the world including complex servers have only
> > > > one Host Bridge.
> > > >
> > > > So in my case should I create my own PciHostBridgeDxe driver
> > > > supporting multiple hostbridges and do not use the Industry
> > > > standard
> > >
> > > driver?
> > >
> > > > I am very new to it, and will appreciate any help or idea.
> > >
> > > As far as I can tell, PciHostBridgeLib allows you to return an
> > > arbitrary number of PCI host bridges, each with their own segment
> > > number. I haven't tried it myself, but it is worth a try whether
> > > returning an array of all host bridges on your platform works as
> > > expected.
> >
> > Thank you Ard,
> > Right, but PciHostBridgeDxe seems to work with one hostbridge.
> > I am confused that
> >
> > // Make sure all root bridges share the same ResourceAssigned value
> >
> > The rootbridges are independent on the platform, and should not share
> > anything. Or am I missing anything?
> > Anyway, I will try to return multiple hostbridges in the
PciHostBridgeLib.
>
> This may be an Intel-ism.
>
> Note that for PCIe, I typically refer to "host bridges" as root
complexes.
>
> On PowerPC SoCs that I've worked with (e.g. Freescale/NXP MPC8548,
> P2020, P4080, T4240) there are often several root complexes. A typical
board
> design may have several PCIe slots where each slot is connected to one
root
> complex in the SoC. Each root complex is therefore the parent of a
separate
> "segment"
> which has its own unique bus/dev/func space. Each root complex has its
own
> bank of registers to control it, including a separate set of
configuration space
> access registers. This means you can have multiple PCIe trees each with
its
> own bus0/dev0/func0 root. There can therefore be several devices with
the
> same bus/dev/func tuple, but which reside on separate segments.
>
> The ARMv8 board you're working with is probably set up the same way.
I've
> only worked with ARM Cortex-A boards and those have all had just one
PCIe
> root complex, but it stands to reason those that have multiple root
> complexes would follow the same pattern as the PPC devices.
>
> Intel systems can (and often do) also have multiple PCIe root complexes,
> however for the sake of backwards compatibility, they all end up sharing
the
> same configuration space access registers (0xCF8/0xCFC or memory mapped
> extended config space) and share a single unified bus/dev/func tree.
I see. Thanks for comprehensive explanation.
In my case root complexes do not share (there is no need for backward
compatibility).
So the question is - can I use PciRootBridgeDxe from MdeModulePkg, which
operates with "rootbridges" and one rootcomplex(?),
or I need to look into the way of creating my own for the platform (say
the way Juno driver was designed initially before switching to the generic
one)?
>
> Note that the tree is not always contiguous. For example, I've seen one
Intel
> board where there was a special PCIe device on bus 128. In the ACPI
tables,
> there were two PCI "segments" described, the second of which
> corresponded to bus 128. There was no switch or bridge to connect bus
128
> to the tree rooted at bus0/dev0/func0, so it would not be possible to
> automatically discover it by just walking the bus0/dev0/func0 tree and
all its
> branches: you needed to use the ACPI hint to know it was there.
>
> I have also seen cases like this with pre-PCIe systems. For example,
I've seen
> a Dell server that had both 32-bit and 64-bit PCI buses, where the
64-bit bus
> was at bus 1, but was not directly bridged to bus 0 (the 32-bit bus).
There was
> a reason for this: 64-bit PCIe buses are usually clocked at 66MHz, but
will fall
> back to 33MHz if you connect a 32-bit PCI device to them (this is

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Bill Paul]

Of all the gin joints in all the towns in all the world, Vladimir Olovyannikov 
had to walk into mine at 09:49:16 on Tuesday 30 May 2017 and say:

> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: May-30-17 9:35 AM
> > To: Vladimir Olovyannikov
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: Using a generic PciHostBridgeDxe driver for a
> > multi-PCIe-domain
> > platform
> > 
> > On 30 May 2017 at 16:23, Vladimir Olovyannikov
> > 
> >  wrote:
> > > Hi,
> > > 
> > > I've started PCIe stack implementation design for an armv8 aarch64
> > > platform.
> > > The platform's PCIe represents several host bridges, and each
> > > hostbridge has one rootbridge.
> > > They do not share any resources between each other.
> > > Looking into the PciHostBridgeDxe implementation I can see that it
> > > supports only one hostbridge, and there is a comment:
> > > // Most systems in the world including complex servers have only one
> > > Host Bridge.
> > > 
> > > So in my case should I create my own PciHostBridgeDxe driver
> > > supporting multiple hostbridges and do not use the Industry standard
> > 
> > driver?
> > 
> > > I am very new to it, and will appreciate any help or idea.
> > 
> > As far as I can tell, PciHostBridgeLib allows you to return an arbitrary
> > number
> > of PCI host bridges, each with their own segment number. I haven't tried
> > it
> > myself, but it is worth a try whether returning an array of all host
> > bridges on
> > your platform works as expected.
> 
> Thank you Ard,
> Right, but PciHostBridgeDxe seems to work with one hostbridge.
> I am confused that
> 
> // Make sure all root bridges share the same ResourceAssigned value
> 
> The rootbridges are independent on the platform, and should not share
> anything. Or am I missing anything?
> Anyway, I will try to return multiple hostbridges in the PciHostBridgeLib.

This may be an Intel-ism.

Note that for PCIe, I typically refer to "host bridges" as root complexes.

On PowerPC SoCs that I've worked with (e.g. Freescale/NXP MPC8548, P2020, 
P4080, T4240) there are often several root complexes. A typical board design 
may have several PCIe slots where each slot is connected to one root complex 
in the SoC. Each root complex is therefore the parent of a separate "segment" 
which has its own unique bus/dev/func space. Each root complex has its own 
bank of registers to control it, including a separate set of configuration 
space access registers. This means you can have multiple PCIe trees each with 
its own bus0/dev0/func0 root. There can therefore be several devices with the 
same bus/dev/func tuple, but which reside on separate segments.

The ARMv8 board you're working with is probably set up the same way. I've only 
worked with ARM Cortex-A boards and those have all had just one PCIe root 
complex, but it stands to reason those that have multiple root complexes would 
follow the same pattern as the PPC devices.

Intel systems can (and often do) also have multiple PCIe root complexes, 
however for the sake of backwards compatibility, they all end up sharing the 
same configuration space access registers (0xCF8/0xCFC or memory mapped 
extended config space) and share a single unified bus/dev/func tree.

Note that the tree is not always contiguous. For example, I've seen one Intel 
board where there was a special PCIe device on bus 128. In the ACPI tables, 
there were two PCI "segments" described, the second of which corresponded to 
bus 128. There was no switch or bridge to connect bus 128 to the tree rooted 
at bus0/dev0/func0, so it would not be possible to automatically discover it 
by just walking the bus0/dev0/func0 tree and all its branches: you needed to 
use the ACPI hint to know it was there.

I have also seen cases like this with pre-PCIe systems. For example, I've seen 
a Dell server that had both 32-bit and 64-bit PCI buses, where the 64-bit bus 
was at bus 1, but was not directly bridged to bus 0 (the 32-bit bus). There 
was a reason for this: 64-bit PCIe buses are usually clocked at 66MHz, but 
will fall back to 33MHz if you connect a 32-bit PCI device to them (this is 
supported for backward compatibility). Reducing the bus clock reduces 
performance, so to avoid that it's necessary to keep the 32-bit and 64-bit 
buses separate and thus give each one its own host bridge. As with the 
previous example, all the devices shared the same bus/dev/func space, but the 
only way to learn about the other segment was to probe the ACPI tables.

It sounds as if the UEFI PCI host bridge code may be biased towards the Intel 
PCI behavior, though I'm not sure to what extent.

So the comment that you found that says:

// Most systems in the world including complex servers have only one Host
Bridge.

Should probably be amended: it should probably say "Most Intel systems" and 
even those systems probably do have more than one host bridge (root complex), 
it's just that it doesn't look like it.

-Bill
 
> Th

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Vladimir Olovyannikov]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: May-30-17 9:35 AM
> To: Vladimir Olovyannikov
> Cc: edk2-devel@lists.01.org
> Subject: Re: Using a generic PciHostBridgeDxe driver for a
> multi-PCIe-domain
> platform
>
> On 30 May 2017 at 16:23, Vladimir Olovyannikov
>  wrote:
> > Hi,
> >
> > I've started PCIe stack implementation design for an armv8 aarch64
> > platform.
> > The platform's PCIe represents several host bridges, and each
> > hostbridge has one rootbridge.
> > They do not share any resources between each other.
> > Looking into the PciHostBridgeDxe implementation I can see that it
> > supports only one hostbridge, and there is a comment:
> > // Most systems in the world including complex servers have only one
> > Host Bridge.
> >
> > So in my case should I create my own PciHostBridgeDxe driver
> > supporting multiple hostbridges and do not use the Industry standard
> driver?
> > I am very new to it, and will appreciate any help or idea.
> >
>
> As far as I can tell, PciHostBridgeLib allows you to return an arbitrary
> number
> of PCI host bridges, each with their own segment number. I haven't tried
> it
> myself, but it is worth a try whether returning an array of all host
> bridges on
> your platform works as expected.

Thank you Ard,
Right, but PciHostBridgeDxe seems to work with one hostbridge.
I am confused that

// Make sure all root bridges share the same ResourceAssigned value

The rootbridges are independent on the platform, and should not share
anything. Or am I missing anything?
Anyway, I will try to return multiple hostbridges in the PciHostBridgeLib.

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Ard Biesheuvel]

On 30 May 2017 at 16:23, Vladimir Olovyannikov
 wrote:
> Hi,
>
> I've started PCIe stack implementation design for an armv8 aarch64
> platform.
> The platform's PCIe represents several host bridges, and each hostbridge
> has one rootbridge.
> They do not share any resources between each other.
> Looking into the PciHostBridgeDxe implementation I can see that it
> supports only one hostbridge, and there is a comment:
> // Most systems in the world including complex servers have only one Host
> Bridge.
>
> So in my case should I create my own PciHostBridgeDxe driver supporting
> multiple hostbridges and do not use the Industry standard driver?
> I am very new to it, and will appreciate any help or idea.
>

As far as I can tell, PciHostBridgeLib allows you to return an
arbitrary number of PCI host bridges, each with their own segment
number. I haven't tried it myself, but it is worth a try whether
returning an array of all host bridges on your platform works as
expected.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform

[Vladimir Olovyannikov]

Hi,

I've started PCIe stack implementation design for an armv8 aarch64
platform.
The platform's PCIe represents several host bridges, and each hostbridge
has one rootbridge.
They do not share any resources between each other.
Looking into the PciHostBridgeDxe implementation I can see that it
supports only one hostbridge, and there is a comment:
// Most systems in the world including complex servers have only one Host
Bridge.

So in my case should I create my own PciHostBridgeDxe driver supporting
multiple hostbridges and do not use the Industry standard driver?
I am very new to it, and will appreciate any help or idea.

Thank you,
Vladimir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Unmount and mount a mass storage from shell

[Carsey, Jaben]

I think that you will always need to inform the UEFI Shell of the change.  It 
is not designed to automatically do detection of added/removed/changed devices.

I think that your solution to use the code from mount makes the most sense.

-Jaben

From: GN Keshava [mailto:keshava...@gmail.com]
Sent: Thursday, May 25, 2017 11:02 PM
To: Carsey, Jaben ; edk2-devel@lists.01.org
Subject: Re: [edk2] Unmount and mount a mass storage from shell
Importance: High

Hi Jaben, Thanks a lot for input. My necessity for unmount-mount is that, the 
USB client is a Linux storage gadget, which needs to be remounted to get the 
updated/new files created by Linux. Anyhow, now I'm doing this programmatically 
by copying mount command code from older shell. :)

One more issue is that, after Linux updates some file (on client side, Linux 
will mount the same partition, save some file, and then umount the partition. 
Then if i remount the partition on Host side, when host is windows, i will get 
updated files) I will manually remove and connect the cable (MS device), UEFI 
is not able to detect the MS itself. (This issue observed, regardless of 
remount. This issue is not there on windows 10 host).
Can you give some pointers on this?

Thanks a lot, Jaben.

Regards,
Keshava

On Thu, 25 May 2017 at 21:26 Carsey, Jaben 
mailto:jaben.car...@intel.com>> wrote:
You can "disconnect" the driver
You can do "map -d" to delete a mapping

I am unsure what your goals are for mount/unmount

-Jaben

> -Original Message-
> From: edk2-devel 
> [mailto:edk2-devel-boun...@lists.01.org]
>  On Behalf Of
> GN Keshava
> Sent: Wednesday, May 24, 2017 10:59 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Unmount and mount a mass storage from shell
> Importance: High
>
> How can I unmount and mount a mass storage fs from UEFI shell?
>
> In older EFI shells, I can do with "mount" command. But it just does
> "mapping" in newer shell. It doesn't actually remounting the device.
>
> Please help.
>
> thanks
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Copy bus scanning workaround from ARM Juno PCIe driver.

[Ard Biesheuvel]

On 29 May 2017 at 16:14, Scott Telford  wrote:
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: 26 May 2017 18:38
>> To: Leif Lindholm 
>> Cc: Scott Telford ; edk2-devel@lists.01.org > de...@ml01.01.org>; Tian, Feng ; Zeng, Star
>> 
>> Subject: Re: [edk2] [PATCH] Copy bus scanning workaround from ARM Juno
>> PCIe driver.
>
>> I'd still like to understand why this issue does not occur under
>> Linux, or if it does occur, if we need an ECAM quirk for Juno to work
>> around it.
>>
>> Could you give an example of which hardware combination triggers this
>> issue?
>
> I don't have access to a Juno board here, so can't reproduce the original 
> problem. It would certainly be interesting to know if the current Juno 
> platform code using the generic PCIe driver suffers from the same problem or 
> not.
>
> The platform I've been working with only exists within a Cadence emulation 
> environment. I've seen the problem when testing an ASMedia ASM1182e bridge 
> and an Intel I210 Ethernet card so it's probably not specific to certain PCIe 
> bridges/devices.
>
> The original Juno PCIe driver (including the workaround) was committed by 
> Olivier Martin at ARM, but I'm not sure if he's still there?
>

He used to maintain the ARM bits in Tianocore/EDK2 but he left ARM two
years ago.

> I'm working on moving the workaround into the PciExpressLib layer.
>

Yes, that is best for now.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel