Re: [edk2-devel] [Patch V3] EmulatorPkg: don't display the cpu current speed

[Zhiguang Liu]

Thanks for the comments.
I will change the commit message in the next version.
But I don't think this is a issue worth making a major change.
Given that the change is consistent with NT32, will you agree with this change?

Best Regards,
Zhiguang Liu

>-Original Message-
>From: Justen, Jordan L
>Sent: Tuesday, June 11, 2019 3:56 PM
>To: Liu, Zhiguang ; devel@edk2.groups.io
>Cc: Andrew Fish ; Ni, Ray 
>Subject: Re: [Patch V3] EmulatorPkg: don't display the cpu current speed
>
>On 2019-06-11 00:32:27, Zhiguang Liu wrote:
>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1686
>>
>> V3: I hope that changing the status of the mCpuSmbiosType4
>> wouldn't affect other features except showing CPU speed.
>> The value is zero in NT32Pkg.
>>
>> Cc: Jordan Justen 
>> Cc: Andrew Fish 
>> Cc: Ray Ni 
>> Signed-off-by: Zhiguang Liu 
>> ---
>>  EmulatorPkg/CpuRuntimeDxe/Cpu.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/EmulatorPkg/CpuRuntimeDxe/Cpu.c
>> b/EmulatorPkg/CpuRuntimeDxe/Cpu.c index 00e93016af..a5e19b4181
>100644
>> --- a/EmulatorPkg/CpuRuntimeDxe/Cpu.c
>> +++ b/EmulatorPkg/CpuRuntimeDxe/Cpu.c
>> @@ -104,7 +104,7 @@ SMBIOS_TABLE_TYPE4 mCpuSmbiosType4 = {
>>0,  // ExternalClock;
>>0,  // MaxSpeed;
>>0,  // CurrentSpeed;
>> -  0x41,   // Status;
>> +  0,  // Status;
>
>It looks like bit 6 means the process is populated, and bits[2:0]==1 means the
>CPU is enabled.
>
>So, it looks like this change will make SMBIOS indicate the the processor
>socket is not populated, and bit2[2:0]==0 means that the CPU status is
>unknown.
>
>I think the commit message for this patch should have been:
>
>===
>
>EmulatorPkg: Change SMBIOS processor to unpopulated
>
>This change updates the SMBIOS processor information to indicate that the
>processor is not populated, and that it's status is unknown.
>
>With this change the processor speed will not be shown in setup.
>
>Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1686
>
>===
>
>But, I'm not sure I agree we should make this change to fix this bug.
>I'm not particularly concerned with this bug, but I wonder if perhaps the
>MdeModulePkg should just suppress the item if the speed is 0.
>
>Or, alternately, perhaps we can investigate some methods to attempt to
>determine the processor speed. I guess for all OS's, it might be difficult, but
>we probably could support finding the processor speed under the most
>common environments.
>
>-Jordan

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42256): https://edk2.groups.io/g/devel/message/42256
Mute This Topic: https://groups.io/mt/32013654/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH] Platform/Socionext/DeveloperBox: add SMBIOS type 17 table

[Masahisa Kojima]

Hi Ard,

On Tue, 11 Jun 2019 at 22:01, Ard Biesheuvel  wrote:
>
> On Tue, 11 Jun 2019 at 14:18, Masahisa Kojima
>  wrote:
> >
> > This adds the SMBIOS type 17 table support for Developerbox platform.
> > The SPDs on a I2C bus is only accessible by the SCP, so SCP-firmware
> > stores SPDs in non-secure SRAM.
> >
> > This commit also reduces the uefi stack size to allocate space
> > for SPDs. It requires 2KB, 512bytes * 4 DIMMs.
> >
> > Signed-off-by: Masahisa Kojima 
>
> So this patch depends on SCP fw changes that are not yet available,
> right? That is not a problem, but I will hold off on merging it until
> we have a new SCP firmware build in the tree.

Yes, this patch depends on SCP firmware changes.
It is better to wait SCP fw available, thank you.

> Some comments below.

I will fix all comments.

> > ---
> >  .../Socionext/DeveloperBox/DeveloperBox.dsc   |   3 +
> >  .../DeveloperBox/DeveloperBox.dsc.inc |   2 +-
> >  .../SmbiosPlatformDxe/SmbiosPlatformDxe.c | 494 +-
> >  .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf   |   2 +
> >  Silicon/Socionext/SynQuacer/SynQuacer.dec |   3 +
> >  5 files changed, 381 insertions(+), 123 deletions(-)
> >
> > diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> > b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> > index 97fb8c410c..f247370694 100644
> > --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> > +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> > @@ -147,6 +147,9 @@
> >
> >gSynQuacerTokenSpaceGuid.PcdDramInfoBase|0x2E00FFC0
> >
> > +  # SCP-firmware stored SPD DDR4 data in non-secure SRAM
> > +  gSynQuacerTokenSpaceGuid.PcdSmbiosStoredSpdDDR4Address|0x2E00F000
> > +
>
> Please drop 'Smbios' from this PCD name - we may want to use the SPD
> data in a different way in the future.
>
> >#
> ># 96boards mezzanine support
> >#
> > diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc 
> > b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
> > index a10e48ca07..abb113e858 100644
> > --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
> > +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
> > @@ -137,7 +137,7 @@
> >
> ># non-secure SRAM
> >gArmPlatformTokenSpaceGuid.PcdCPUCoresStackBase|0x2E00
> > -  gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0xFFC0
> > +  gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0xF000
> >
> >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24
> >
> > diff --git 
> > a/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
> > b/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> > index 6227b77877..da0fd2e6a5 100644
> > --- a/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> > +++ b/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> > @@ -10,17 +10,48 @@
> >  **/
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >
> >  STATIC EFI_SMBIOS_PROTOCOL   *mSmbios;
> >
> > +#define SPD4_MEM_BUS_WIDTH_8BIT(0x00)
> > +#define SPD4_MEM_BUS_WIDTH_16BIT   (BIT0)
> > +#define SPD4_MEM_BUS_WIDTH_32BIT   (BIT1)
> > +#define SPD4_MEM_BUS_WIDTH_64BIT   (BIT0 | BIT1)
> > +
> > +#define SPD4_MEM_DEV_WIDTH_4BIT(0x00)
> > +#define SPD4_MEM_DEV_WIDTH_8BIT(BIT0)
> > +#define SPD4_MEM_DEV_WIDTH_16BIT   (BIT1)
> > +#define SPD4_MEM_DEV_WIDTH_32BIT   (BIT0 | BIT1)
> > +
> > +#define SPD4_MEM_MODULE_TYPE_RDIMM0x01
> > +#define SPD4_MEM_MODULE_TYPE_UDIMM0x02
> > +#define SPD4_MEM_MODULE_TYPE_SODIMM   0x03
> > +
> > +#define TYPE17_DEVICE_LOCATOR_LEN (8 + 1)
> > +#define TYPE17_BANK_LOCATOR_LEN   (20 + 1)
> > +#define TYPE17_MANUFACTURER_NAME_LEN  (30 + 1)
> > +#define TYPE17_SERIAL_NUMBER_LEN  (16 + 1)
> > +#define TYPE17_ASSETTAG_LEN   (16 + 1)
> > +#define TYPE17_MODULE_PART_NUMBER_LEN (20 + 1)
> > +
> > +#define TYPE17_STRINGS_MAX_LEN(TYPE17_DEVICE_LOCATOR_LEN + \
> > +   TYPE17_BANK_LOCATOR_LEN + \
> > +   TYPE17_MANUFACTURER_NAME_LEN + \
> > +   TYPE17_SERIAL_NUMBER_LEN + \
> > +   TYPE17_ASSETTAG_LEN + \
> > +   TYPE17_MODULE_PART_NUMBER_LEN + \
> > +   1/* null SMBIOS_TABLE_STRING 
> > terminator */ )
> > +
> >  //
> >  // Type definition and contents of the default SMBIOS table.
> >  // This table covers only the minimum structures required by
> > @@ -69,7 +100,7 @@ typedef struct {
> >
> >  typedef struct {
> >SMBIOS_TABLE_TYPE17 Base;
> > -  CHAR8   Strings[];
> > +  CHAR8   Strings[TYPE17_STRINGS_MAX_LEN];
> >  } ARM_TYPE17;
> >
> >  typedef struct {
> > @@ -94,6 +125,69 @@ enum {
> >SMBIOS_HANDLE_MEMORY,
> >  };
> >
> > +struct 

[edk2-devel] [PATCH] MdeModulePkg/PeiMain: Substantial change for PeiAllocatePool

[Gao, Zhichao]

From: Bret Barkelew 

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

The original logic is ASSERT if fail to create HOB. But
that doesn't make sense for release version. So it is required
to set the Buffer to null to indicate the failure.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 MdeModulePkg/Core/Pei/Memory/MemoryServices.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Core/Pei/Memory/MemoryServices.c 
b/MdeModulePkg/Core/Pei/Memory/MemoryServices.c
index 42f79ab076..37b0cfa3cf 100644
--- a/MdeModulePkg/Core/Pei/Memory/MemoryServices.c
+++ b/MdeModulePkg/Core/Pei/Memory/MemoryServices.c
@@ -802,7 +802,12 @@ PeiAllocatePool (
  (VOID **)
  );
   ASSERT_EFI_ERROR (Status);
-  *Buffer = Hob+1;
+
+  if (EFI_ERROR (Status)) {
+*Buffer = NULL;
+  } else {
+*Buffer = Hob+1;
+  }
 
   return Status;
 }
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42253): https://edk2.groups.io/g/devel/message/42253
Mute This Topic: https://groups.io/mt/32038027/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/3] Common OBB verification feature

[Yao, Jiewen]

Thanks Jian. Some comment below:

0) Please add what unit test has been done.

1) Can we use UINT64 for Base and Length?
typedef struct _HASHED_FV_INFO {
  UINT32  Base;
  UINT32  Length;
  UINT64  Flag;
} HASHED_FV_INFO;

2) Can we remove the hard code HASHED_FV_MAX_NUMBER and use more flexible way?
#define HASHED_FV_MAX_NUMBER  10
struct _EDKII_PEI_FIRMWARE_VOLUME_INFO_STORED_HASH_FV_PPI {
  UINTN   FvNumber;
  HASHED_FV_INFO  FvInfo[HASHED_FV_MAX_NUMBER];
  UINTN   HashNumber;
  FV_HASH_INFOHashInfo[1];
};

3) can we use better way to organize the table? It is weird to have so many 
zero. Why not just use TPM_ALG_xxx as the first field and search?
STATIC CONST HASH_ALG_INFO mHashAlgInfo[] = {
  {0, NULL, NULL, NULL, NULL},//  TPM_ALG_ERROR
  {0, NULL, NULL, NULL, NULL},// 0001 TPM_ALG_FIRST
  {0, NULL, NULL, NULL, NULL},// 0002
  {0, NULL, NULL, NULL, NULL},// 0003
  {0, NULL, NULL, NULL, NULL},// 0004 TPM_ALG_SHA1
  {0, NULL, NULL, NULL, NULL},// 0005
  {0, NULL, NULL, NULL, NULL},// 0006 TPM_ALG_AES
  {0, NULL, NULL, NULL, NULL},// 0007
  {0, NULL, NULL, NULL, NULL},// 0008 TPM_ALG_KEYEDHASH
  {0, NULL, NULL, NULL, NULL},// 0009
  {0, NULL, NULL, NULL, NULL},// 000A
  {SHA256_DIGEST_SIZE, Sha256Init, Sha256Update, Sha256Final, Sha256HashAll}, 
// 000B TPM_ALG_SHA256
  {SHA384_DIGEST_SIZE, Sha384Init, Sha384Update, Sha384Final, Sha384HashAll}, 
// 000C TPM_ALG_SHA384
  {SHA512_DIGEST_SIZE, Sha512Init, Sha512Update, Sha512Final, Sha512HashAll}, 
// 000D TPM_ALG_SHA512
  {0, NULL, NULL, NULL, NULL},// 000E
  {0, NULL, NULL, NULL, NULL},// 000F
  {0, NULL, NULL, NULL, NULL},// 0010 TPM_ALG_NULL
//{0, NULL, NULL, NULL, NULL},// 0011
//{0, NULL, NULL, NULL, NULL},// 0012 TPM_ALG_SM3_256
};

4) Why not just add one bit say: skip in S3 ? Why need such complexity?
#define HASHED_FV_FLAG_SKIP_BOOT_MODE(Mode)   LShiftU64 (0x100, (Mode))
#define FV_HASH_FLAG_BOOT_MODE(Mode)  LShiftU64 (1, (Mode))

I am not sure how that works. Is boot mode bit start from BIT0 or BIT8 ? I am 
confused.

if ((StoredHashFvPpi->HashInfo[HashIndex].HashFlag
 & FV_HASH_FLAG_BOOT_MODE (BootMode)) != 0) {
  HashInfo = >HashInfo[HashIndex];
  break;
}

5) Why the producer want skip both verified boot and measured boot? Is that 
legal or illegal? If it is illegal, I prefer use ASSER() to tell people.
if ((FvInfo[FvIndex].Flag & HASHED_FV_FLAG_VERIFIED_BOOT) == 0 &&
(FvInfo[FvIndex].Flag & HASHED_FV_FLAG_MEASURED_BOOT) == 0) {
  continue;
}

6) I recommend to add one debug message to tell people this is skipped.
//
// Skip any FV not meant for current boot mode.
//
if ((FvInfo[FvIndex].Flag & HASHED_FV_FLAG_SKIP_BOOT_MODE (BootMode)) != 0) 
{
  continue;
}

7) Would you please clarify why and when a platform need report multiple 
StartedHashFv ?
  do {
Status = PeiServicesLocatePpi (
   ,
   Instance,
   NULL,
   (VOID**)
   );
if (!EFI_ERROR(Status) && StoredHashFvPpi != NULL && 
StoredHashFvPpi->FvNumber > 0) {

It will be better, if you can those description in StoredHashFvPpi.h file

8) Same code above, would you please clarify if it is legal or illegal that 
StoredHashFvPpi->FvNumber == 0 ?
If it is illegal, I prefer use ASSERT()

Thank you
Yao Jiewen


> -Original Message-
> From: Wang, Jian J
> Sent: Tuesday, June 11, 2019 2:36 AM
> To: devel@edk2.groups.io
> Cc: Zhang, Chao B ; Yao, Jiewen
> ; Hernandez Beltran, Jorge
> ; Han, Harry 
> Subject: [PATCH v2 0/3] Common OBB verification feature
> 
> >V2: fix parameter description error found by ECC
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1617
> 
> Cc: Chao Zhang 
> Cc: Jiewen Yao 
> Cc: "Hernandez Beltran, Jorge" 
> Cc: Harry Han 
> 
> Jian J Wang (3):
>   SecurityPkg: add definitions for OBB verification
>   SecurityPkg/FvReportPei: implement a common FV verifier and reporter
>   SecurityPkg: add FvReportPei.inf in dsc for build validation
> 
>  SecurityPkg/FvReportPei/FvReportPei.c | 418
> ++
>  SecurityPkg/FvReportPei/FvReportPei.h | 121 +
>  SecurityPkg/FvReportPei/FvReportPei.inf   |  57 +++
>  SecurityPkg/FvReportPei/FvReportPei.uni   |  14 +
>  .../FvReportPei/FvReportPeiPeiExtra.uni   |  12 +
>  .../Ppi/FirmwareVolumeInfoStoredHashFv.h  |  61 +++
>  SecurityPkg/SecurityPkg.dec   |   9 +
>  SecurityPkg/SecurityPkg.dsc   |   5 +
>  8 files changed, 697 insertions(+)
>  create mode 100644 

Re: [edk2-devel] [PATCH 1/2] Platform/Intel: Update Kabylake build steps.

[Nate DeSimone]

It's good that we have the Python 2.x dependency documented for 
KabyLakeOpenBoardPkg now, but we really need to migrate it to Python 3.x since 
security updates for Python 2.x will be ending soon.

Reviewed-by: Nate DeSimone 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Chiu, Chasel
Sent: Tuesday, June 11, 2019 8:29 PM
To: devel@edk2.groups.io
Cc: Kubacki, Michael A ; Desimone, Nathaniel L 
; Gao, Liming 
Subject: [edk2-devel] [PATCH 1/2] Platform/Intel: Update Kabylake build steps.

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

KabylakeOpenBoardPkg no longer supported batch file build, it only supports 
build_bios.py.
ReadMe.md should be updated and batch files should be removed.

Test: both API mode and Dispatch mode can build
  successfully by build_bios.py

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/Readme.md | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/Platform/Intel/Readme.md b/Platform/Intel/Readme.md index 
443fb409b3..cc0151066e 100644
--- a/Platform/Intel/Readme.md
+++ b/Platform/Intel/Readme.md
@@ -101,7 +101,7 @@ return back to the minimum platform caller.
   * ``git clone https://github.com/tianocore/edk2-non-osi.git -b 
devel-MinPlatform``
 
 * FSP repository
-  * ``git clone https://github.com/IntelFsp/FSP.git -b Kabylake``
+  * ``git clone https://github.com/IntelFsp/FSP.git``
 
 ### Build
 
@@ -132,7 +132,8 @@ return back to the minimum platform caller.
   | --capsule | capsule build enabled   |
   | --silent  | silent build enabled|
   | --performance | performance build enabled   |
-  | --fsp | fsp build enabled   |
+  | --fsp | fsp wrapper build enabled   |
+  | --fspapi  | API mode fsp wrapper build enabled  |
   | |
 
 * For more information on build options @@ -140,6 +141,8 @@ return back to the 
minimum platform caller.
 
 * Note
   * Python 2.7.16 and Python 3.7.3 compatible
+  * Some dependency Python scripts might only support 2.x or 3.x, if that 
happened use
+"py -2" or "py -3" to launch build_bios.py
   * This python build script has been tested on Windows 10 and Ubuntu 16.04.5 
LTS
   * See [cross-platform limitations](#Known-limitations)
 
@@ -186,12 +189,7 @@ return back to the minimum platform caller.
   
 
 **Building with the batch scripts**
-For KabylakeOpenBoardPkg
-1. Open command window, go to the workspace directory, e.g. c:\Kabylake.
-2. Type "cd edk2-platforms\Platform\Intel\KabylakeOpenBoardPkg\KabylakeRvp3".
-3. Type "GitEdk2MinKabylake.bat" to setup GIT environment.
-4. Type "prep" and make prebuild finish for debug build, "prep r" for release 
build.
-5. Type "bld" to build Kaby Lake reference platform UEFI firmware image.
+KabylakeOpenBoardPkg does not support batch scripts, please use build_bios.py.
 
 For PurleyOpenBoardPkg
 1. Open command window, go to the workspace directory, e.g. c:\Purley.
--
2.13.3.windows.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42250): https://edk2.groups.io/g/devel/message/42250
Mute This Topic: https://groups.io/mt/32037607/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/2] KabylakeOpenBoardPkg: Update Kabylake build steps.

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

-Original Message-
From: Chiu, Chasel 
Sent: Tuesday, June 11, 2019 8:29 PM
To: devel@edk2.groups.io
Cc: Kubacki, Michael A ; Desimone, Nathaniel L 
; Gao, Liming 
Subject: [PATCH 2/2] KabylakeOpenBoardPkg: Update Kabylake build steps.

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

Remove build batch files because they are obsolete.
Use build_bios.py from now.

Test: both API mode and Dispatch mode can build
  successfully by build_bios.py

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/GitEdk2MinKabylake.bat |  79 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/bld.bat| 159 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/cln.bat|  48 

 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/postbuild.bat  |  39 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/prebuild.bat   | 215 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/prep.bat   |  79 
---
 6 files changed, 619 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/GitEdk2MinKabylake.bat 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/GitEdk2MinKabylake.bat
deleted file mode 100644
index 3bb13df80a..00
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/GitEdk2MinKabylake.bat
+++ /dev/null
@@ -1,79 +0,0 @@
-@REM @file
-@REM
-@REM Copyright (c) 2017, Intel Corporation. All rights reserved. -@REM 
SPDX-License-Identifier: BSD-2-Clause-Patent -@REM
-
-@echo off
-
-pushd ..\..\..\..\..\
-
-@REM Set WORKSPACE environment.
-set WORKSPACE=%cd%
-echo.
-echo Set WORKSPACE as: %WORKSPACE%
-echo.
-
-@REM Check whether Git has been installed and been added to system path.
-git --help >nul 2>nul
-if %ERRORLEVEL% NEQ 0 (
-  echo.
-  echo The 'git' command is not recognized.
-  echo Please make sure that Git is installed and has been added to system 
path.
-  echo.
-  goto :EOF
-)
-
-@REM Create the Conf directory under WORKSPACE -if not exist %WORKSPACE%\Conf (
-  mkdir Conf
-)
-
-@REM Set other environments.
-@REM Basic Rule:
-@REM   Platform override Silicon override Core
-@REM   Source override Binary
-
-set 
PACKAGES_PATH=%WORKSPACE%\edk2-platforms\Platform\Intel;%WORKSPACE%\edk2-platforms\Silicon\Intel;%WORKSPACE%\edk2-non-osi\Silicon\Intel;%WORKSPACE%\FSP;%WORKSPACE%\edk2;%WORKSPACE%
-set EDK_TOOLS_BIN=%WORKSPACE%\edk2-BaseTools-win32
-
-@if not defined PYTHON_HOME (
-  @if exist C:\Python27 (
-set PYTHON_HOME=C:\Python27
-  )
-)
-
-set EDK_SETUP_OPTION=
-@rem if python is installed, disable the binary base tools.
-if defined PYTHON_HOME (
-  set EDK_TOOLS_BIN=
-  set EDK_SETUP_OPTION=--nt32
-)
-pushd %WORKSPACE%\edk2
-call edksetup.bat %EDK_SETUP_OPTION%
-popd
-pushd %WORKSPACE%
-@rem if python is installed, nmake BaseTools source and enable BaseTools 
source build -@if defined PYTHON_HOME (
-  nmake -f %BASE_TOOLS_PATH%\Makefile
-)
-popd
-
-set openssl_path=%WORKSPACE%
-
-popd
-
-goto :EOF
-
-:Help
-echo.
-echo Usage:
-echo GitEdk2.bat [-w Workspace_Directory] (optional) [-b Branch_Name] 
(optional) -echo.
-echo -wA absolute/relative path to be the workspace.
-echo   Default value is the current directory.
-echo.
-echo -bThe branch name of the repository. Currently, only master, udk2015,
-echo   trunk (same as master) and bp13 (same as udk2015) are supported.
-echo   Default value is master.
-echo.
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/bld.bat 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/bld.bat
deleted file mode 100644
index 449660b75d..00
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/bld.bat
+++ /dev/null
@@ -1,159 +0,0 @@
-@REM @file
-@REM
-@REM Copyright (c) 2017, Intel Corporation. All rights reserved. -@REM 
SPDX-License-Identifier: BSD-2-Clause-Patent -@REM
-
-:: Useage: bld [/s] [/f  ] [/r]
-::
-:: For a given build command, 3 options may be passed into this batch file via 
command prompt:
-:: 1) /s = Redirects all output to a file called EDK2.log(Prep.log must be 
existed), which will be located at the root.
-:: 2) /f = Defines the passing in of a single override to a feature PCD that 
is used in the platform
-::DSC file.  If this parameter is used, it is to be followed immediately 
after by both the feature
-::pcd name 

Re: [edk2-devel] ExtScsiPassThru support for Logical SCSI devices

[Ravi Kumar Siadri]

Hi,

Can someone help me in clarifying my queries ??

Thanks,
Ravi Kumar

On Mon, Jun 10, 2019 at 3:55 PM Ravi Kumar Siadri <
siadriravikumaru...@gmail.com> wrote:

> Hi all,
>
> I have couple of queries regarding the
> *EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL* attribute support in
> *EFI_EXT_SCSI_PASS_THRU_PROTOCOL*.
>
> *1. *
> *The Attributes field of the EFI_EXT_SCSI_PASS_THRU_PROTOCOL interface
> tells if the interface is for physical SCSI devices or logical SCSI
> devices. Drivers for non-RAID SCSI controllers will set both the
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL, and the
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bits.*
>
> If the Drivers is for non-RAID SCSI controllers why to set the
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bit. Will there be any case that
> non-RAID SCSI controllers have Logical devices connected to it ??
>
> *2. *
> *Drivers for RAID controllers that allow access to the physical devices
> and logical devices will produce two EFI_EXT_SCSI_PASS_THRU_PROTOCOL
> interfaces:  *
> *One with the just the EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL bit set
> and another with just the EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bit
> set. One interface can be used to access the physical devices attached to
> the RAID controller, and the other can be used to access the logical
> devices attached to the RAID controller for its current configuration.*
>
> Any background why EFI_EXT_SCSI_PASS_THRU_PROTOCOL needed 2 instances ?
> why can't we install attributes EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL
> and EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL on same Instance ??
> How User locates the Instance with
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bit set and Instance with
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL bit set. ??
>
> Thanks,
> Ravi Kumar
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42249): https://edk2.groups.io/g/devel/message/42249
Mute This Topic: https://groups.io/mt/32007447/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] BaseTools: Cannot store library cache of different arch together

[Steven Shi]

Sorry, the CopyFileOnChange() will ensure only once IO store/restore writing 
for each library. The extra IO read is ok.


Thanks

Steven Shi
Intel\SSG\FID\Firmware Infrastructure

From: Shi, Steven
Sent: Wednesday, June 12, 2019 11:24 AM
To: Rodriguez, Christian ; devel@edk2.groups.io
Cc: Gao, Liming ; Feng, Bob C 
Subject: RE: [PATCH] BaseTools: Cannot store library cache of different arch 
together


Hi Christian,

For the extra IO accesses for duplicated library, I plan to introduce the 
CopyFileOnChange() function to solve it. Below is the CopyFileOnChange() BZ, 
and I haven't sent its patch yet. The CopyFileOnChange() will ensure only once 
IO store/restore access for each library. To avoid duplicated library access is 
critical not only for the performance, but also for the writing data race in 
multi-threads.





Basetool need CopyFileOnChange function to avoid cache file writing race in 
multi-thread build

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





Thanks



Steven Shi

Intel\SSG\FID\Firmware Infrastructure



> -Original Message-

> From: Rodriguez, Christian

> Sent: Tuesday, June 11, 2019 11:41 PM

> To: Shi, Steven mailto:steven@intel.com>>; 
> devel@edk2.groups.io

> Cc: Gao, Liming mailto:liming@intel.com>>; Feng, 
> Bob C mailto:bob.c.f...@intel.com>>

> Subject: RE: [PATCH] BaseTools: Cannot store library cache of different arch

> together

>

> The change looks good overall, but I'm concerned about the performance if

> there are multiple of the same library used by different modules. In this case

> the library will be copied once per arch per module. I'm not sure if it would

> make a giant impact, but just something to think about because you would be

> doing extra IO accesses for each duplicate library autogen.

>

> Possible suggestion:

> Is it possible to change the hash to include the arch? Or you can store a

> unique tuple pair like (lib.arch, lib) in the set to reduce the libraries 
> being

> copied to a unique subset.

>

> Thanks,

> Christian

>

> >-Original Message-

> >From: Shi, Steven

> >Sent: Monday, June 10, 2019 10:53 PM

> >To: devel@edk2.groups.io

> >Cc: Gao, Liming mailto:liming@intel.com>>; Feng, 
> >Bob C

> >mailto:bob.c.f...@intel.com>>; Rodriguez, Christian

> >mailto:christian.rodrig...@intel.com>>

> >Subject: [PATCH] BaseTools: Cannot store library cache of different arch

> >together

> >

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

> >

> >Build cache cannot store cache for the same library modules in different arch

> >together. E.g. Both the below IA32 and X64 arch BaseLib caches should exist

> >after build Ovmf3264, but now only the one in X64 arch exist.

> >The reason is the current Basetool use a set() to same all library AutoGen

> >objects, but the different arch lib AutoGen objects have same __hash_ value

> >which comes from the lib MetaFile(The path of module file):

> >def __hash__(self):

> >return hash(self.MetaFile)

> >

> >So the different arch lib AutoGen objects are duplicated one to the set() and

> >only one can exist. This is why the Basetool can only store one arch cache 
> >for

> >library.

> >This patch avoid to use the set() as the container to save the library and

> >module objects because the objects might have same __hash__ value.

> >

> >Cc: Liming Gao mailto:liming@intel.com>>

> >Cc: Bob Feng mailto:bob.c.f...@intel.com>>

> >Cc: Christian Rodriguez 
> >mailto:christian.rodrig...@intel.com>>

> >Signed-off-by: Steven Shi mailto:steven@intel.com>>

> >---

> > BaseTools/Source/Python/build/build.py | 13 +++--

> > 1 file changed, 3 insertions(+), 10 deletions(-)

> >

> >diff --git a/BaseTools/Source/Python/build/build.py

> >b/BaseTools/Source/Python/build/build.py

> >index 0855d4561c..f7a79cbbab 100644

> >--- a/BaseTools/Source/Python/build/build.py

> >+++ b/BaseTools/Source/Python/build/build.py

> >@@ -2203,21 +2203,14 @@ class Build():

> > RemoveDirectory(os.path.dirname(GlobalData.gDatabasePath), True)

> >

> > def CreateAsBuiltInf(self):

> >-all_lib_set = set()

> >-all_mod_set = set()

> > for Module in self.BuildModules:

> > Module.CreateAsBuiltInf()

> >-all_mod_set.add(Module)

> >+for lib in Module.LibraryAutoGenList:

> >+lib.CreateAsBuiltInf(True)

> > for Module in self.HashSkipModules:

> > Module.CreateAsBuiltInf(True)

> >-all_mod_set.add(Module)

> >-for Module in all_mod_set:

> > for lib in Module.LibraryAutoGenList:

> >-all_lib_set.add(lib)

> >-for lib in all_lib_set:

> >-lib.CreateAsBuiltInf(True)

> >-all_lib_set.clear()

> >-all_mod_set.clear()

> >+lib.CreateAsBuiltInf(True)

> > self.BuildModules = []

> > 

[edk2-devel] [PATCH 1/2] Platform/Intel: Update Kabylake build steps.

[Chiu, Chasel]

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

KabylakeOpenBoardPkg no longer supported batch file
build, it only supports build_bios.py.
ReadMe.md should be updated and batch files should
be removed.

Test: both API mode and Dispatch mode can build
  successfully by build_bios.py

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/Readme.md | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/Platform/Intel/Readme.md b/Platform/Intel/Readme.md
index 443fb409b3..cc0151066e 100644
--- a/Platform/Intel/Readme.md
+++ b/Platform/Intel/Readme.md
@@ -101,7 +101,7 @@ return back to the minimum platform caller.
   * ``git clone https://github.com/tianocore/edk2-non-osi.git -b 
devel-MinPlatform``
 
 * FSP repository
-  * ``git clone https://github.com/IntelFsp/FSP.git -b Kabylake``
+  * ``git clone https://github.com/IntelFsp/FSP.git``
 
 ### Build
 
@@ -132,7 +132,8 @@ return back to the minimum platform caller.
   | --capsule | capsule build enabled   |
   | --silent  | silent build enabled|
   | --performance | performance build enabled   |
-  | --fsp | fsp build enabled   |
+  | --fsp | fsp wrapper build enabled   |
+  | --fspapi  | API mode fsp wrapper build enabled  |
   | |
 
 * For more information on build options
@@ -140,6 +141,8 @@ return back to the minimum platform caller.
 
 * Note
   * Python 2.7.16 and Python 3.7.3 compatible
+  * Some dependency Python scripts might only support 2.x or 3.x, if that 
happened use
+"py -2" or "py -3" to launch build_bios.py
   * This python build script has been tested on Windows 10 and Ubuntu 16.04.5 
LTS
   * See [cross-platform limitations](#Known-limitations)
 
@@ -186,12 +189,7 @@ return back to the minimum platform caller.
   
 
 **Building with the batch scripts**
-For KabylakeOpenBoardPkg
-1. Open command window, go to the workspace directory, e.g. c:\Kabylake.
-2. Type "cd edk2-platforms\Platform\Intel\KabylakeOpenBoardPkg\KabylakeRvp3".
-3. Type "GitEdk2MinKabylake.bat" to setup GIT environment.
-4. Type "prep" and make prebuild finish for debug build, "prep r" for release 
build.
-5. Type "bld" to build Kaby Lake reference platform UEFI firmware image.
+KabylakeOpenBoardPkg does not support batch scripts, please use build_bios.py.
 
 For PurleyOpenBoardPkg
 1. Open command window, go to the workspace directory, e.g. c:\Purley.
-- 
2.13.3.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42246): https://edk2.groups.io/g/devel/message/42246
Mute This Topic: https://groups.io/mt/32037607/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 0/2] Update Kabylake build steps.

[Chiu, Chasel]

KabylakeOpenBoardPkg no longer supported batch file
build, it only supports build_bios.py.
ReadMe.md should be updated and batch files should
be removed.

Test: both API mode and Dispatch mode can build
  successfully by build_bios.py

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Chasel Chiu 

Chasel Chiu (2):
  Platform/Intel: Update Kabylake build steps.
  KabylakeOpenBoardPkg: Update Kabylake build steps.

 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/GitEdk2MinKabylake.bat |  79 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/bld.bat| 159 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/cln.bat|  48 

 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/postbuild.bat  |  39 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/prebuild.bat   | 215 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/prep.bat   |  79 
---
 Platform/Intel/Readme.md|  14 
++
 7 files changed, 6 insertions(+), 627 deletions(-)
 delete mode 100644 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/GitEdk2MinKabylake.bat
 delete mode 100644 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/bld.bat
 delete mode 100644 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/cln.bat
 delete mode 100644 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/postbuild.bat
 delete mode 100644 
Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/prebuild.bat
 delete mode 100644 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/prep.bat

-- 
2.13.3.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42245): https://edk2.groups.io/g/devel/message/42245
Mute This Topic: https://groups.io/mt/32037606/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 2/2] KabylakeOpenBoardPkg: Update Kabylake build steps.

[Chiu, Chasel]

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

Remove build batch files because they are obsolete.
Use build_bios.py from now.

Test: both API mode and Dispatch mode can build
  successfully by build_bios.py

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/GitEdk2MinKabylake.bat |  79 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/bld.bat| 159 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/cln.bat|  48 

 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/postbuild.bat  |  39 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/prebuild.bat   | 215 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/prep.bat   |  79 
---
 6 files changed, 619 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/GitEdk2MinKabylake.bat 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/GitEdk2MinKabylake.bat
deleted file mode 100644
index 3bb13df80a..00
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/GitEdk2MinKabylake.bat
+++ /dev/null
@@ -1,79 +0,0 @@
-@REM @file
-@REM
-@REM Copyright (c) 2017, Intel Corporation. All rights reserved.
-@REM SPDX-License-Identifier: BSD-2-Clause-Patent
-@REM
-
-@echo off
-
-pushd ..\..\..\..\..\
-
-@REM Set WORKSPACE environment.
-set WORKSPACE=%cd%
-echo.
-echo Set WORKSPACE as: %WORKSPACE%
-echo.
-
-@REM Check whether Git has been installed and been added to system path.
-git --help >nul 2>nul
-if %ERRORLEVEL% NEQ 0 (
-  echo.
-  echo The 'git' command is not recognized.
-  echo Please make sure that Git is installed and has been added to system 
path.
-  echo.
-  goto :EOF
-)
-
-@REM Create the Conf directory under WORKSPACE
-if not exist %WORKSPACE%\Conf (
-  mkdir Conf
-)
-
-@REM Set other environments.
-@REM Basic Rule:
-@REM   Platform override Silicon override Core
-@REM   Source override Binary
-
-set 
PACKAGES_PATH=%WORKSPACE%\edk2-platforms\Platform\Intel;%WORKSPACE%\edk2-platforms\Silicon\Intel;%WORKSPACE%\edk2-non-osi\Silicon\Intel;%WORKSPACE%\FSP;%WORKSPACE%\edk2;%WORKSPACE%
-set EDK_TOOLS_BIN=%WORKSPACE%\edk2-BaseTools-win32
-
-@if not defined PYTHON_HOME (
-  @if exist C:\Python27 (
-set PYTHON_HOME=C:\Python27
-  )
-)
-
-set EDK_SETUP_OPTION=
-@rem if python is installed, disable the binary base tools.
-if defined PYTHON_HOME (
-  set EDK_TOOLS_BIN=
-  set EDK_SETUP_OPTION=--nt32
-)
-pushd %WORKSPACE%\edk2
-call edksetup.bat %EDK_SETUP_OPTION%
-popd
-pushd %WORKSPACE%
-@rem if python is installed, nmake BaseTools source and enable BaseTools 
source build
-@if defined PYTHON_HOME (
-  nmake -f %BASE_TOOLS_PATH%\Makefile
-)
-popd
-
-set openssl_path=%WORKSPACE%
-
-popd
-
-goto :EOF
-
-:Help
-echo.
-echo Usage:
-echo GitEdk2.bat [-w Workspace_Directory] (optional) [-b Branch_Name] 
(optional)
-echo.
-echo -wA absolute/relative path to be the workspace.
-echo   Default value is the current directory.
-echo.
-echo -bThe branch name of the repository. Currently, only master, udk2015,
-echo   trunk (same as master) and bp13 (same as udk2015) are supported.
-echo   Default value is master.
-echo.
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/bld.bat 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/bld.bat
deleted file mode 100644
index 449660b75d..00
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/bld.bat
+++ /dev/null
@@ -1,159 +0,0 @@
-@REM @file
-@REM
-@REM Copyright (c) 2017, Intel Corporation. All rights reserved.
-@REM SPDX-License-Identifier: BSD-2-Clause-Patent
-@REM
-
-:: Useage: bld [/s] [/f  ] [/r]
-::
-:: For a given build command, 3 options may be passed into this batch file via 
command prompt:
-:: 1) /s = Redirects all output to a file called EDK2.log(Prep.log must be 
existed), which will be located at the root.
-:: 2) /f = Defines the passing in of a single override to a feature PCD that 
is used in the platform
-::DSC file.  If this parameter is used, it is to be followed immediately 
after by both the feature
-::pcd name and value. FeaturePcd is the full PCD name, like 
gMinPlatformPkgTokenSpaceGuid.PcdOptimizeCompilerEnable
-:: 3) /r = Useful for faster rebuilds when no changes have been made to .inf 
files. Passes -u to
-::build.exe to skip the generation of makefiles.
-:: 4) rom = 

Re: [edk2-devel] [PATCH] BaseTools: Cannot store library cache of different arch together

[Steven Shi]

Hi Christian,

For the extra IO accesses for duplicated library, I plan to introduce the 
CopyFileOnChange() function to solve it. Below is the CopyFileOnChange() BZ, 
and I haven't sent its patch yet. The CopyFileOnChange() will ensure only once 
IO store/restore access for each library. To avoid duplicated library access is 
critical not only for the performance, but also for the writing data race in 
multi-threads.





Basetool need CopyFileOnChange function to avoid cache file writing race in 
multi-thread build

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





Thanks



Steven Shi

Intel\SSG\FID\Firmware Infrastructure



> -Original Message-

> From: Rodriguez, Christian

> Sent: Tuesday, June 11, 2019 11:41 PM

> To: Shi, Steven ; devel@edk2.groups.io

> Cc: Gao, Liming ; Feng, Bob C 

> Subject: RE: [PATCH] BaseTools: Cannot store library cache of different arch

> together

>

> The change looks good overall, but I'm concerned about the performance if

> there are multiple of the same library used by different modules. In this case

> the library will be copied once per arch per module. I'm not sure if it would

> make a giant impact, but just something to think about because you would be

> doing extra IO accesses for each duplicate library autogen.

>

> Possible suggestion:

> Is it possible to change the hash to include the arch? Or you can store a

> unique tuple pair like (lib.arch, lib) in the set to reduce the libraries 
> being

> copied to a unique subset.

>

> Thanks,

> Christian

>

> >-Original Message-

> >From: Shi, Steven

> >Sent: Monday, June 10, 2019 10:53 PM

> >To: devel@edk2.groups.io

> >Cc: Gao, Liming mailto:liming@intel.com>>; Feng, 
> >Bob C

> >mailto:bob.c.f...@intel.com>>; Rodriguez, Christian

> >mailto:christian.rodrig...@intel.com>>

> >Subject: [PATCH] BaseTools: Cannot store library cache of different arch

> >together

> >

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

> >

> >Build cache cannot store cache for the same library modules in different arch

> >together. E.g. Both the below IA32 and X64 arch BaseLib caches should exist

> >after build Ovmf3264, but now only the one in X64 arch exist.

> >The reason is the current Basetool use a set() to same all library AutoGen

> >objects, but the different arch lib AutoGen objects have same __hash_ value

> >which comes from the lib MetaFile(The path of module file):

> >def __hash__(self):

> >return hash(self.MetaFile)

> >

> >So the different arch lib AutoGen objects are duplicated one to the set() and

> >only one can exist. This is why the Basetool can only store one arch cache 
> >for

> >library.

> >This patch avoid to use the set() as the container to save the library and

> >module objects because the objects might have same __hash__ value.

> >

> >Cc: Liming Gao mailto:liming@intel.com>>

> >Cc: Bob Feng mailto:bob.c.f...@intel.com>>

> >Cc: Christian Rodriguez 
> >mailto:christian.rodrig...@intel.com>>

> >Signed-off-by: Steven Shi mailto:steven@intel.com>>

> >---

> > BaseTools/Source/Python/build/build.py | 13 +++--

> > 1 file changed, 3 insertions(+), 10 deletions(-)

> >

> >diff --git a/BaseTools/Source/Python/build/build.py

> >b/BaseTools/Source/Python/build/build.py

> >index 0855d4561c..f7a79cbbab 100644

> >--- a/BaseTools/Source/Python/build/build.py

> >+++ b/BaseTools/Source/Python/build/build.py

> >@@ -2203,21 +2203,14 @@ class Build():

> > RemoveDirectory(os.path.dirname(GlobalData.gDatabasePath), True)

> >

> > def CreateAsBuiltInf(self):

> >-all_lib_set = set()

> >-all_mod_set = set()

> > for Module in self.BuildModules:

> > Module.CreateAsBuiltInf()

> >-all_mod_set.add(Module)

> >+for lib in Module.LibraryAutoGenList:

> >+lib.CreateAsBuiltInf(True)

> > for Module in self.HashSkipModules:

> > Module.CreateAsBuiltInf(True)

> >-all_mod_set.add(Module)

> >-for Module in all_mod_set:

> > for lib in Module.LibraryAutoGenList:

> >-all_lib_set.add(lib)

> >-for lib in all_lib_set:

> >-lib.CreateAsBuiltInf(True)

> >-all_lib_set.clear()

> >-all_mod_set.clear()

> >+lib.CreateAsBuiltInf(True)

> > self.BuildModules = []

> > self.HashSkipModules = []

> > ## Do some clean-up works when error occurred

> >--

> >2.17.1.windows.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42244): https://edk2.groups.io/g/devel/message/42244
Mute This Topic: https://groups.io/mt/32013233/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] SourceLevelDebugPkg: Add lacking instances for build only

[Gao, Zhichao]

From: Bret Barkelew 

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

Add the lacking instance to the [Components] of dsc file
for build only.

Cc: Hao A Wu 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Cc: Leif Lindholm 
Signed-off-by: Zhichao gao 
---
 SourceLevelDebugPkg/SourceLevelDebugPkg.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc 
b/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
index 8be6781296..a1a1b81d03 100644
--- a/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
+++ b/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
@@ -93,6 +93,8 @@
 
###
 
 [Components.common]
+  
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunicationLibUsb3Dxe.inf
+  
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunicationLibUsb3Pei.inf
   
SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommunicationLibSerialPort.inf
   
SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommunicationLibUsb.inf
   
SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42241): https://edk2.groups.io/g/devel/message/42241
Mute This Topic: https://groups.io/mt/32037313/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] MdeModulePkg: Add lacking instances for build only

[Gao, Zhichao]

From: Bret Barkelew 

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

Add the lacking instances to the [Components] of dsc file
for build only.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 MdeModulePkg/MdeModulePkg.dsc | 16 
 1 file changed, 16 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 995fd805e1..f32adc3839 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -204,6 +204,22 @@
   MdeModulePkg/Application/DumpDynPcd/DumpDynPcd.inf
   MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.inf
 
+  MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
+  MdeModulePkg/Logo/Logo.inf
+  MdeModulePkg/Logo/LogoDxe.inf
+  MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
+  
MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
+  MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
+  MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+  MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
+  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
+  MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
+  MdeModulePkg/Library/PciHostBridgeLibNull/PciHostBridgeLibNull.inf
+  
MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
+  MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
+  MdeModulePkg/Library/BaseHobLibNull/BaseHobLibNull.inf
+  
MdeModulePkg/Library/BaseMemoryAllocationLibNull/BaseMemoryAllocationLibNull.inf
+
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
   MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
   MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42243): https://edk2.groups.io/g/devel/message/42243
Mute This Topic: https://groups.io/mt/32037315/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] SecurityPkg: Add lacking instances for build only

[Gao, Zhichao]

From: Bret Barkelew 

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

Add the lacking instance to the [Components] of dsc file
for build only.

Cc: Chao Zhang 
Cc: Jiewen Yao 
Cc: Jian Wang 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Cc: Leif Lindholm 
Signed-off-by: Zhichao gao 
---
 SecurityPkg/SecurityPkg.dsc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc
index a2ee0528f0..ed0da7563d 100644
--- a/SecurityPkg/SecurityPkg.dsc
+++ b/SecurityPkg/SecurityPkg.dsc
@@ -199,6 +199,12 @@
   SecurityPkg/Library/FmpAuthenticationLibPkcs7/FmpAuthenticationLibPkcs7.inf
   
SecurityPkg/Library/FmpAuthenticationLibRsa2048Sha256/FmpAuthenticationLibRsa2048Sha256.inf
 
+  SecurityPkg/Library/DxeDeferImageLoadLib/DxeDeferImageLoadLib.inf
+  SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
+  SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
+  SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
+  SecurityPkg/Library/TcgPpVendorLibNull/TcgPpVendorLibNull.inf
+
 [Components.IA32, Components.X64, Components.ARM, Components.AARCH64]
   SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
 
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42242): https://edk2.groups.io/g/devel/message/42242
Mute This Topic: https://groups.io/mt/32037314/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] CryptoPkg: Add lacking instances for build only

[Gao, Zhichao]

From: Bret Barkelew 

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

Add the lacking instance to [Componnets] of dsc file
for build only.

Cc: Jian Wang 
Cc: Ting Ye 
Cc: Liming Gao 
Cc: Sean Brogan 
Cc: Michael Turner 
Cc: Bret Barkelew 
Signed-off-by: Zhichao Gao 
---
 CryptoPkg/CryptoPkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/CryptoPkg/CryptoPkg.dsc b/CryptoPkg/CryptoPkg.dsc
index 9dfa349f6d..c90e76c721 100644
--- a/CryptoPkg/CryptoPkg.dsc
+++ b/CryptoPkg/CryptoPkg.dsc
@@ -116,6 +116,7 @@
   CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
   CryptoPkg/Library/TlsLib/TlsLib.inf
   CryptoPkg/Library/OpensslLib/OpensslLib.inf
+  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
 
 [Components.IA32, Components.X64]
   CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42240): https://edk2.groups.io/g/devel/message/42240
Mute This Topic: https://groups.io/mt/32037312/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Wu, Hao A]

> -Original Message-
> From: Ni, Ray
> Sent: Wednesday, June 12, 2019 10:04 AM
> To: Wu, Hao A; David Woodhouse; Justen, Jordan L; devel@edk2.groups.io
> Cc: Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> dependency
> 
> Hao,
> Will the CSM duplication cause any code change that may impact CSM
> functionality?

Hello Ray,

I think there should be no functional impact for the duplication.
There is no change to the .C/.H files.

Best Regards,
Hao Wu

> If no, how about firstly duplicate them first?
> 
> David,
> Will this approach work for you?
> 
> Thanks,
> Ray
> 
> > -Original Message-
> > From: Wu, Hao A 
> > Sent: Wednesday, June 12, 2019 9:19 AM
> > To: David Woodhouse ; Justen, Jordan L
> > ; devel@edk2.groups.io
> > Cc: Ni, Ray ; Laszlo Ersek ; Ard
> > Biesheuvel ; Phillips, D Scott
> > 
> > Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > dependency
> >
> > > -Original Message-
> > > From: Wu, Hao A
> > > Sent: Tuesday, June 11, 2019 4:06 PM
> > > To: 'David Woodhouse'; Justen, Jordan L; devel@edk2.groups.io
> > > Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > > Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > > dependency
> > >
> > > > -Original Message-
> > > > From: David Woodhouse [mailto:dw...@infradead.org]
> > > > Sent: Tuesday, June 11, 2019 4:01 PM
> > > > To: Wu, Hao A; Justen, Jordan L; devel@edk2.groups.io
> > > > Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > > > Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > > > dependency
> > > >
> > > > On Tue, 2019-06-11 at 07:49 +, Wu, Hao A wrote:
> > > > > Hello all,
> > > > >
> > > > > For the series:
> > > > > [PATCH v2 00/10] Duplicate required CSM components for OVMF
> > > > > https://edk2.groups.io/g/devel/message/41385
> > > > >
> > > > > I sent it out on May 27th, and did not receive a confirmation from
> > > > > David for about 2 weeks. I think maybe the CSM support on OVMF is
> > > > > no longer cared, and thus I sent another series today to drop such
> > support:
> > > > > [PATCH v1 0/2] OVMF: Drop CSM support
> > > > > https://edk2.groups.io/g/devel/message/42142
> > > > >
> > > > > Please help to provide some feedbacks/confirmation on what should
> > > > > I do
> > > > for
> > > > > the next step. (This task actually blocks our proposal to remove
> > > > > IntelFramework[Module]Pkg from edk2.)
> > > >
> > > >
> > > > Apologies for the delay. It wasn't clear that the first series was
> > > > actually tested by booting with a CSM, and I was reluctant to ack it
> > > > without knowing that it didn't cause a regression.
> > >
> > > Agree, I understand that.
> > >
> > > >
> > > > This is, of course, complicated by the fact that I can't actually
> > > > get a CSM boot to complete at the moment. But it gets a long way
> > > > into the boot process before something goes wrong, so confirmation
> > > > that it still gets at least that far with your 'Duplicate required CSM
> > components'
> > > > series would be good.
> > > >
> > > > Is there a git tree I can pull from? I seem to recall that last time
> > > > I spent serious time working on OVMF, life was horribly complicated
> > > > by CRLF line endings, and it was extremely painful to just apply
> > > > patches from email... is that still the case?
> > >
> > > Yes, you can get the first series at:
> > > https://github.com/hwu25/edk2/commits/ovmf_csm_v2
> >
> > Hello David,
> >
> > May I know how long will it take for your verification and acknowledging
> the
> > series that duplicate the required CSM modules under OvmfPkg?
> >
> > Thanks in advance.
> >
> > Best Regards,
> > Hao Wu
> >
> > >
> > > Best Regards,
> > > Hao Wu
> > >
> > > >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42239): https://edk2.groups.io/g/devel/message/42239
Mute This Topic: https://groups.io/mt/32011839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Ni, Ray]

Hao,
Will the CSM duplication cause any code change that may impact CSM 
functionality?
If no, how about firstly duplicate them first?

David,
Will this approach work for you?

Thanks,
Ray

> -Original Message-
> From: Wu, Hao A 
> Sent: Wednesday, June 12, 2019 9:19 AM
> To: David Woodhouse ; Justen, Jordan L
> ; devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek ; Ard
> Biesheuvel ; Phillips, D Scott
> 
> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> dependency
> 
> > -Original Message-
> > From: Wu, Hao A
> > Sent: Tuesday, June 11, 2019 4:06 PM
> > To: 'David Woodhouse'; Justen, Jordan L; devel@edk2.groups.io
> > Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > dependency
> >
> > > -Original Message-
> > > From: David Woodhouse [mailto:dw...@infradead.org]
> > > Sent: Tuesday, June 11, 2019 4:01 PM
> > > To: Wu, Hao A; Justen, Jordan L; devel@edk2.groups.io
> > > Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > > Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > > dependency
> > >
> > > On Tue, 2019-06-11 at 07:49 +, Wu, Hao A wrote:
> > > > Hello all,
> > > >
> > > > For the series:
> > > > [PATCH v2 00/10] Duplicate required CSM components for OVMF
> > > > https://edk2.groups.io/g/devel/message/41385
> > > >
> > > > I sent it out on May 27th, and did not receive a confirmation from
> > > > David for about 2 weeks. I think maybe the CSM support on OVMF is
> > > > no longer cared, and thus I sent another series today to drop such
> support:
> > > > [PATCH v1 0/2] OVMF: Drop CSM support
> > > > https://edk2.groups.io/g/devel/message/42142
> > > >
> > > > Please help to provide some feedbacks/confirmation on what should
> > > > I do
> > > for
> > > > the next step. (This task actually blocks our proposal to remove
> > > > IntelFramework[Module]Pkg from edk2.)
> > >
> > >
> > > Apologies for the delay. It wasn't clear that the first series was
> > > actually tested by booting with a CSM, and I was reluctant to ack it
> > > without knowing that it didn't cause a regression.
> >
> > Agree, I understand that.
> >
> > >
> > > This is, of course, complicated by the fact that I can't actually
> > > get a CSM boot to complete at the moment. But it gets a long way
> > > into the boot process before something goes wrong, so confirmation
> > > that it still gets at least that far with your 'Duplicate required CSM
> components'
> > > series would be good.
> > >
> > > Is there a git tree I can pull from? I seem to recall that last time
> > > I spent serious time working on OVMF, life was horribly complicated
> > > by CRLF line endings, and it was extremely painful to just apply
> > > patches from email... is that still the case?
> >
> > Yes, you can get the first series at:
> > https://github.com/hwu25/edk2/commits/ovmf_csm_v2
> 
> Hello David,
> 
> May I know how long will it take for your verification and acknowledging the
> series that duplicate the required CSM modules under OvmfPkg?
> 
> Thanks in advance.
> 
> Best Regards,
> Hao Wu
> 
> >
> > Best Regards,
> > Hao Wu
> >
> > >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42238): https://edk2.groups.io/g/devel/message/42238
Mute This Topic: https://groups.io/mt/32011839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Wu, Hao A]

> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, June 11, 2019 4:06 PM
> To: 'David Woodhouse'; Justen, Jordan L; devel@edk2.groups.io
> Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> Subject: RE: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> dependency
> 
> > -Original Message-
> > From: David Woodhouse [mailto:dw...@infradead.org]
> > Sent: Tuesday, June 11, 2019 4:01 PM
> > To: Wu, Hao A; Justen, Jordan L; devel@edk2.groups.io
> > Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> > Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> > dependency
> >
> > On Tue, 2019-06-11 at 07:49 +, Wu, Hao A wrote:
> > > Hello all,
> > >
> > > For the series:
> > > [PATCH v2 00/10] Duplicate required CSM components for OVMF
> > > https://edk2.groups.io/g/devel/message/41385
> > >
> > > I sent it out on May 27th, and did not receive a confirmation from David
> > > for about 2 weeks. I think maybe the CSM support on OVMF is no longer
> > > cared, and thus I sent another series today to drop such support:
> > > [PATCH v1 0/2] OVMF: Drop CSM support
> > > https://edk2.groups.io/g/devel/message/42142
> > >
> > > Please help to provide some feedbacks/confirmation on what should I do
> > for
> > > the next step. (This task actually blocks our proposal to remove
> > > IntelFramework[Module]Pkg from edk2.)
> >
> >
> > Apologies for the delay. It wasn't clear that the first series was
> > actually tested by booting with a CSM, and I was reluctant to ack it
> > without knowing that it didn't cause a regression.
> 
> Agree, I understand that.
> 
> >
> > This is, of course, complicated by the fact that I can't actually get a
> > CSM boot to complete at the moment. But it gets a long way into the
> > boot process before something goes wrong, so confirmation that it still
> > gets at least that far with your 'Duplicate required CSM components'
> > series would be good.
> >
> > Is there a git tree I can pull from? I seem to recall that last time I
> > spent serious time working on OVMF, life was horribly complicated by
> > CRLF line endings, and it was extremely painful to just apply patches
> > from email... is that still the case?
> 
> Yes, you can get the first series at:
> https://github.com/hwu25/edk2/commits/ovmf_csm_v2

Hello David,

May I know how long will it take for your verification and acknowledging
the series that duplicate the required CSM modules under OvmfPkg?

Thanks in advance.

Best Regards,
Hao Wu

> 
> Best Regards,
> Hao Wu
> 
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42237): https://edk2.groups.io/g/devel/message/42237
Mute This Topic: https://groups.io/mt/32011839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] SecurityPkg/HddPassword: Add a PCD to skip Hdd password prompt

[Dong, Eric]

Hi Maggie,

Reviewed-by: Eric Dong 

And pushed: 9e2416ae2e1d26c6e6daa58353de519745bb322d

Thanks,
Eric

> -Original Message-
> From: Chu, Maggie
> Sent: Monday, June 10, 2019 6:19 PM
> To: devel@edk2.groups.io
> Cc: Zhang, Chao B ; Yao, Jiewen
> ; Dong, Eric 
> Subject: [PATCH] SecurityPkg/HddPassword: Add a PCD to skip Hdd
> password prompt
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1876
> Add a PCD for skipping Hdd password prompt.
> If device is in the locked status while attempting to skip password prompt,
> device will keep locked and system continue to boot.
> If device is in the unlocked status while attempting to skip password prompt,
> system will be forced shutdown.
> 
> Signed-off-by: Maggie Chu 
> Cc: Chao Zhang 
> Cc: Jiewen Yao 
> Cc: Eric Dong 
> ---
>  SecurityPkg/HddPassword/HddPasswordDxe.c   | 16 
>  SecurityPkg/HddPassword/HddPasswordDxe.inf |  4 
>  SecurityPkg/SecurityPkg.dec|  6 ++
>  3 files changed, 26 insertions(+)
> 
> diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.c
> b/SecurityPkg/HddPassword/HddPasswordDxe.c
> index 253af9f78f..b0d795b659 100644
> --- a/SecurityPkg/HddPassword/HddPasswordDxe.c
> +++ b/SecurityPkg/HddPassword/HddPasswordDxe.c
> @@ -1345,6 +1345,22 @@ HddPasswordRequestPassword (
>//
>if ((ConfigFormEntry->IfrData.SecurityStatus.Supported) &&
>(ConfigFormEntry->IfrData.SecurityStatus.Enabled)) {
> +
> + //
> + // Add PcdSkipHddPasswordPrompt to determin whether to skip
> password prompt.
> + // Due to board design, device may not power off during system warm
> boot, which result in
> + // security status remain unlocked status, hence we add device security
> status check here.
> + //
> + // If device is in the locked status, device keeps locked and system
> continues booting.
> + // If device is in the unlocked status, system is forced shutdown for
> security concern.
> + //
> + if (PcdGetBool (PcdSkipHddPasswordPrompt)) {
> +   if (ConfigFormEntry->IfrData.SecurityStatus.Locked) {
> + return;
> +   } else {
> + gRT->ResetSystem (EfiResetShutdown, EFI_SUCCESS, 0, NULL);
> +   }
> +}
>  //
>  // As soon as the HDD password is in enabled state, we pop up a window
> to unlock hdd
>  // no matter it's really in locked or unlocked state.
> diff --git a/SecurityPkg/HddPassword/HddPasswordDxe.inf
> b/SecurityPkg/HddPassword/HddPasswordDxe.inf
> index f7550079ed..06e8755ffc 100644
> --- a/SecurityPkg/HddPassword/HddPasswordDxe.inf
> +++ b/SecurityPkg/HddPassword/HddPasswordDxe.inf
> @@ -34,6 +34,7 @@
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
>CryptoPkg/CryptoPkg.dec
> +  SecurityPkg/SecurityPkg.dec
> 
>  [LibraryClasses]
>BaseLib
> @@ -64,6 +65,9 @@
>gEfiPciIoProtocolGuid ## CONSUMES
>gEdkiiVariableLockProtocolGuid## CONSUMES
> 
> +[Pcd]
> +  gEfiSecurityPkgTokenSpaceGuid.PcdSkipHddPasswordPrompt  ##
> CONSUMES
> +
>  [Depex]
>gEfiVariableWriteArchProtocolGuid
> 
> diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec index
> 3314f1854b..82929fe38e 100644
> --- a/SecurityPkg/SecurityPkg.dec
> +++ b/SecurityPkg/SecurityPkg.dec
> @@ -428,6 +428,12 @@
># @Prompt Skip Opal DXE driver unlock device flow.
> 
> gEfiSecurityPkgTokenSpaceGuid.PcdSkipOpalDxeUnlock|FALSE|BOOLEAN|0
> x00010020
> 
> +  ## Indicates if Hdd Password driver skip password prompt.
> +  #   TRUE  - Skip password prompt.
> +  #   FALSE - Does not skip password prompt.
> +  # @Prompt Skip Hdd Password prompt.
> +
> +
> gEfiSecurityPkgTokenSpaceGuid.PcdSkipHddPasswordPrompt|FALSE|BOOLE
> AN|0
> + x00010021
> +
>  [PcdsDynamic, PcdsDynamicEx]
> 
>## This PCD indicates Hash mask for TPM 2.0. Bit definition strictly 
> follows
> TCG Algorithm Registry.
> --
> 2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42236): https://edk2.groups.io/g/devel/message/42236
Mute This Topic: https://groups.io/mt/32002537/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] BaseTools: add centralized location for git config files

[Bob Feng]

OK. I will add the header when I do push.

Reviewed-by: Bob Feng 

-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
Sent: Tuesday, June 11, 2019 5:35 PM
To: Feng, Bob C 
Cc: devel@edk2.groups.io; Gao, Liming ; Zhu, Yonghong 
; Andrew Fish ; Laszlo Ersek 
; Kinney, Michael D 
Subject: Re: [PATCH 1/2] BaseTools: add centralized location for git config 
files

Right, I tend to think of configuration files as not-really-copyrightable.

Would you like me to send a v2, or would you be OK with me adding # # Copyright 
(c) 2019, Linaro Ltd. All rights reserved.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent # to both files and pushing the 
series?

Regards

Leif

On Tue, Jun 11, 2019 at 05:25:58AM +, Feng, Bob C wrote:
> Hi Leif,
> 
> These 2 new file have no license header, need to add?
> 
> Thanks,
> Bob
> 
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, June 10, 2019 7:54 PM
> To: devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming 
> ; Zhu, Yonghong ; Andrew 
> Fish ; Laszlo Ersek ; Kinney, 
> Michael D 
> Subject: [PATCH 1/2] BaseTools: add centralized location for git 
> config files
> 
> Before adding the git environment initialization script, add the following 
> files that will be pointed to after running said script:
> 
> - BaseTools/Conf/diff.order
> - BaseTools/Conf/gitattributes
> 
> Signed-off-by: Leif Lindholm 
> Reviewed-by: Laszlo Ersek 
> ---
>  BaseTools/Conf/diff.order|  8 
>  BaseTools/Conf/gitattributes | 14 ++
>  2 files changed, 22 insertions(+)
>  create mode 100644 BaseTools/Conf/diff.order  create mode 100644 
> BaseTools/Conf/gitattributes
> 
> diff --git a/BaseTools/Conf/diff.order b/BaseTools/Conf/diff.order new 
> file mode 100644 index 00..1d578ac28c
> --- /dev/null
> +++ b/BaseTools/Conf/diff.order
> @@ -0,0 +1,8 @@
> +*.dec
> +*.dsc.inc
> +*.dsc
> +*.fdf
> +*.inf
> +*.h
> +*.vfr
> +*.c
> diff --git a/BaseTools/Conf/gitattributes 
> b/BaseTools/Conf/gitattributes new file mode 100644 index 
> 00..a8f923fd8a
> --- /dev/null
> +++ b/BaseTools/Conf/gitattributes
> @@ -0,0 +1,14 @@
> +*.efi -diff
> +*.EFI -diff
> +*.bin -diff
> +*.BIN -diff
> +*.raw -diff
> +*.RAW -diff
> +*.bmp -diff
> +*.BMP -diff
> +*.dec diff=ini
> +*.dsc diff=ini
> +*.dsc.inc diff=ini
> +*.fdf diff=ini
> +*.fdf.inc diff=ini
> +*.inf diff=ini
> --
> 2.11.0
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42235): https://edk2.groups.io/g/devel/message/42235
Mute This Topic: https://groups.io/mt/32003228/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform patch 3/4] KabylakeOpenBoardPkg: Update FDF to use the generic Microcode FFS rule

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

-Original Message-
From: Gao, Liming 
Sent: Monday, June 10, 2019 10:04 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L 

Subject: [edk2-platform patch 3/4] KabylakeOpenBoardPkg: Update FDF to use the 
generic Microcode FFS rule

Signed-off-by: Liming Gao 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
---
 Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf 
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf
index 0cff53e308..0f95ee7942 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.fdf
@@ -203,9 +203,7 @@ READ_STATUS= FALSE
 READ_LOCK_CAP  = TRUE
 READ_LOCK_STATUS   = TRUE
 
-FILE RAW = 197DB236-F856-4924-90F8-CDF12FB875F3 {
-  $(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/X64/MicrocodeUpdates.bin
-}
+INF RuleOverride = MICROCODE 
$(PLATFORM_SI_BIN_PACKAGE)/Microcode/MicrocodeUpdates.inf
 
 [FV.FvPreMemory]
 BlockSize  = $(FLASH_BLOCK_SIZE)
-- 
2.13.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42234): https://edk2.groups.io/g/devel/message/42234
Mute This Topic: https://groups.io/mt/32013037/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform patch 1/4] MinPlatformPkg: Add generic MICROCODE FFS Rules

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

-Original Message-
From: Gao, Liming 
Sent: Monday, June 10, 2019 10:04 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Desimone, Nathaniel L 

Subject: [edk2-platform patch 1/4] MinPlatformPkg: Add generic MICROCODE FFS 
Rules

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

Signed-off-by: Liming Gao 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
---
 Platform/Intel/MinPlatformPkg/Include/Fdf/RuleInclude.fdf | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Platform/Intel/MinPlatformPkg/Include/Fdf/RuleInclude.fdf 
b/Platform/Intel/MinPlatformPkg/Include/Fdf/RuleInclude.fdf
index a1a8964b91..85e6f773df 100644
--- a/Platform/Intel/MinPlatformPkg/Include/Fdf/RuleInclude.fdf
+++ b/Platform/Intel/MinPlatformPkg/Include/Fdf/RuleInclude.fdf
@@ -227,6 +227,11 @@
 VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
 
+[Rule.Common.USER_DEFINED.MICROCODE]
+  FILE RAW = 197DB236-F856-4924-90F8-CDF12FB875F3 {
+$(INF_OUTPUT)/$(MODULE_NAME).bin
+  }
+
 [Rule.Common.PEIM.BIN_FV]
   FILE FV_IMAGE = $(NAMED_GUID) {
 FV_IMAGE FV  |.fv
-- 
2.13.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42232): https://edk2.groups.io/g/devel/message/42232
Mute This Topic: https://groups.io/mt/32013035/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform patch 2/4] ClevoOpenBoardPkg: Update FDF to use generic Microcode FFS rule

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Liming Gao
Sent: Monday, June 10, 2019 10:04 PM
To: devel@edk2.groups.io
Cc: Sinha, Ankit ; Desimone, Nathaniel L 

Subject: [edk2-devel] [edk2-platform patch 2/4] ClevoOpenBoardPkg: Update FDF 
to use generic Microcode FFS rule

Signed-off-by: Liming Gao 
Cc: Ankit Sinha 
Cc: Nate DeSimone 
---
 Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.fdf | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.fdf 
b/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.fdf
index 67aebbd547..b16bf0fe4e 100644
--- a/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.fdf
+++ b/Platform/Intel/ClevoOpenBoardPkg/N1xxWU/OpenBoardPkg.fdf
@@ -207,9 +207,7 @@ READ_STATUS= FALSE
 READ_LOCK_CAP  = TRUE
 READ_LOCK_STATUS   = TRUE
 
-FILE RAW = 197DB236-F856-4924-90F8-CDF12FB875F3 {
-  $(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/X64/MicrocodeUpdates.bin
-}
+INF RuleOverride = MICROCODE 
$(PLATFORM_SI_BIN_PACKAGE)/Microcode/MicrocodeUpdates.inf
 
 [FV.FvPreMemory]
 BlockSize  = $(FLASH_BLOCK_SIZE)
-- 
2.13.0.windows.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42233): https://edk2.groups.io/g/devel/message/42233
Mute This Topic: https://groups.io/mt/32013036/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop IntelFramework[Module]Pkg dependency

[Wu, Hao A]

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, June 11, 2019 5:39 PM
> To: devel@edk2.groups.io; Wu, Hao A
> Cc: 'Ard Biesheuvel'; ming.hu...@linaro.org; Ni, Ray
> Subject: Re: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop
> IntelFramework[Module]Pkg dependency
> 
> On Tue, Jun 11, 2019 at 06:19:50AM +, Wu, Hao A wrote:
> > Can I go ahead to push this series?
> > Or should I wait someone for additional review?
> 
> Go for it.
> My ACK applies to the series.

Thanks.
Series pushed via commits 453c792abb..f87b5c8a6b.

Best Regards,
Hao Wu

> 
> Best Regards,
> 
> Leif
> 
> > Best Regards,
> > Hao Wu
> >
> > >
> > > On Mon, Jun 10, 2019 at 05:13:42AM +, Wu, Hao A wrote:
> > > > Hello Ard and Leif,
> > > >
> > > > I saw Ming Huang  validated the patch (OS boot):
> > > > Hisilicon/D0x: Use StatusCode Router & Handler in MdeModulePkg
> > > >
> > > > https://edk2.groups.io/g/devel/message/41419
> > > > (Thanks a lot for the validation effort.)
> > > >
> > > > Do you have remaining concerns for review this series?
> > > > Thanks in advance.
> > > >
> > > > Best Regards,
> > > > Hao Wu
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Wu, Hao A
> > > > > Sent: Monday, May 27, 2019 10:43 AM
> > > > > To: devel@edk2.groups.io; Ard Biesheuvel; Leif Lindholm
> > > > > Cc: Kinney, Michael D; Andrew Fish; Laszlo Ersek; Ni, Ray;
> > > > > guoh...@huawei.com
> > > > > Subject: RE: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop
> > > > > IntelFramework[Module]Pkg dependency
> > > > >
> > > > > Hello Ard and Leif,
> > > > >
> > > > > Do you have comments on this series?
> > > > >
> > > > > Also, for the below patch to Hisilicon platforms:
> > > > > [PATCH v2 06/18] Hisilicon/D0x: Use StatusCode Router & Handler in
> > > > > MdeModulePkg
> > > > >
> > > > > it is suggested to be verified on actual hardware:
> > > > > https://edk2.groups.io/g/devel/topic/31614327#41188
> > > > >
> > > > > However, it seems that there is no accessible hardware for such
> > > verification
> > > > > at this moment. Do you think it is fine to push this change anyway?
> > > > >
> > > > > (Also CCed the stewards here for comments.)
> > > > >
> > > > > Best Regards,
> > > > > Hao Wu
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
> Behalf
> > > Of
> > > > > > Wu, Hao A
> > > > > > Sent: Monday, May 20, 2019 4:41 PM
> > > > > > To: devel@edk2.groups.io
> > > > > > Cc: Wu, Hao A; Ard Biesheuvel; Leif Lindholm; Kinney, Michael D
> > > > > > Subject: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop
> > > > > > IntelFramework[Module]Pkg dependency
> > > > > >
> > > > > > The series is also available at:
> > > > > > https://github.com/hwu25/edk2-
> > > > > > platforms/commits/drop_intelframework_v2
> > > > > >
> > > > > > V2 changes:
> > > > > > A. For platforms BeagleBoard, CelloBoard and Overdrive1000Board,
> > > update
> > > > > >their DSC file to consume the null ReportStatusCodeLib in MdePkg.
> > > The
> > > > > >change is done since these platforms do not have a StatusCode
> > > Router
> > > > > >module;
> > > > > > B. Add the change for platform RaspberryPi/RPi3 to drop its
> > > dependency
> > > > > on
> > > > > >the framework packages;
> > > > > > C. Update the commit log message for patch
> > > > > >'Silicon/Hisilicon: Use ReportStatusCodeLib (DXE) in
> MdeModulePkg'
> > > > > >to better reflect the commit impact.
> > > > > >
> > > > > >
> > > > > > This series will drop the IntelFramework[Module]Pkg dependency
> for
> > > > > > platforms within the edk2-platforms repo.
> > > > > > packages.
> > > > > >
> > > > > > Tests done for the series:
> > > > > > Platforms build verified with GCC5 toolchain:
> > > > > > * Platform/AMD/OverdriveBoard
> > > > > > * Platform/ARM/JunoPkg
> > > > > > * Platform/ARM/SgiPkg
> > > > > > * Platform/ARM/VExpressPkg
> > > > > > * Platform/BeagleBoard
> > > > > > * Platform/Hisilicon/D0x
> > > > > > * Platform/Hisilicon/HiKey
> > > > > > * Platform/Hisilicon/HiKey960
> > > > > > * Platform/LeMaker/CelloBoard
> > > > > > * Platform/Marvell/Armada70x0Db (only AARCH64)
> > > > > > * Platform/Marvell/Armada80x0Db (only AARCH64)
> > > > > > * Platform/RaspberryPi/RPi3
> > > > > > * Platform/Socionext/DeveloperBox
> > > > > > * Platform/Socionext/SynQuacerEvalBoard (only AARCH64)
> > > > > > * Platform/SoftIron/Overdrive1000Board
> > > > > > * Platform/SolidRun/Armada80x0McBin (only AARCH64)
> > > > > >
> > > > > > Platforms originally cannot be built via GCC5 toolchain (thus, not
> > > > > > verified):
> > > > > > * Platform/Comcast/RDKQemu (ARM, AARCH64)
> > > > > > * Platform/Marvell/Armada70x0Db (ARM)
> > > > > > * Platform/Marvell/Armada80x0Db (ARM)
> > > > > > * Platform/Socionext/SynQuacerEvalBoard (ARM, AARCH64)
> > > > > > * Platform/SolidRun/Armada80x0McBin (ARM)
> > > > > >
> > > > > > Cc: Ard Biesheuvel 
> > > > > 

[edk2-devel] [PATCH 1/2] [staging/EdkRepo]: Add EdkRepo - The Multi-Repo Tool

[Nate DeSimone]

Signed-off-by: Nate DeSimone 
Cc: Andrew Fish 
Cc: Laszlo Ersek 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
---
 Maintainers.txt | 50 ++
 README.md   | 32 
 2 files changed, 82 insertions(+)
 create mode 100644 Maintainers.txt
 create mode 100644 README.md

diff --git a/Maintainers.txt b/Maintainers.txt
new file mode 100644
index 00..7fce863cce
--- /dev/null
+++ b/Maintainers.txt
@@ -0,0 +1,50 @@
+EDK II Maintainers
+==
+
+This file provides information about the primary maintainers for
+EdkRepo.
+
+In general, you should not privately email the maintainer. You should
+email the edk2-devel list, but you can also Cc the maintainer.
+
+Descriptions of section entries:
+
+  L: Mailing list that is relevant to this area (default is edk2-devel)
+ Patches and questions should be sent to the email list.
+  M: Cc address for patches and questions (ie, the package maintainer)
+  R: Package Reviewer: Cc address for patches and questions. Reviewers help
+ maintainers review code, but don't have push access. A designated Package
+ Reviewer is reasonably familiar with the Package (or some modules
+ thereof), and/or provides testing or regression testing for the Package
+ (or some modules thereof), in certain platforms and environments.
+  W: Web-page with status/info
+  T: SCM tree type and location.  Type is one of: git, svn.
+  S: Status, one of the following:
+ Supported:  Someone is actually paid to look after this.
+ Maintained: Someone actually looks after it.
+ Odd Fixes:  It has a maintainer but they don't have time to do
+ much other than throw the odd patch in. See below.
+ Orphan: No current maintainer [but maybe you could take the
+ role as you write your new code].
+ Obsolete:   Old code. Something tagged obsolete generally means
+ it has been replaced by a better system and you
+ should be using that.
+
+EDK II
+--
+W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
+L: https://edk2.groups.io/g/devel/
+T: git - https://github.com/tianocore/edk2-staging.git
+
+Responsible Disclosure, Reporting Security Issues
+-
+W: https://github.com/tianocore/tianocore.github.io/wiki/Security
+
+EDK II Packages:
+
+
+EdkRepo
+W: https://github.com/tianocore/edk2-staging/tree/EdkRepo
+M: Nate DeSimone 
+M: Ashley DeSimone 
+R: Puja Pandya 
diff --git a/README.md b/README.md
new file mode 100644
index 00..2a6c2fc003
--- /dev/null
+++ b/README.md
@@ -0,0 +1,32 @@
+This branch is for integrating the EdkRepo tool in to EDK2
+
+# Introduction
+
+EdkRepo is the multi-repository tool for EDK II firmware development. EdkRepo 
is built on top of git. It is intended to automate common developer workflows 
for projects that use more than one git repository. For example many of the new 
projects in the edk2-platforms repository require the user to clone several git 
repositories. EdkRepo makes it easier to set up and upstream changes for these 
projects. EdkRepo does not replace git, rather it provides higher level 
extensions that make it easier to work with git. EdkRepo is written in Python 
and is compatible with Python 3.5 or later.
+
+# Timeline
+| Time | Event |
+|::|:-:|
+| WW 24 2019 | Initial commit of EdkRepo |
+|...|...|
+
+# Branch Owners
+- Ashley DeSimone 
+- Nate DeSimone 
+
+# Integration
+EdkRepo could live in several places:
+1. edk2-platforms
+2. edk2-pytool-library
+3. The edk2-toolenv repository proposed by Sean (assuming approval of Sean’s 
RFC)
+4. A new, separate repository created for EdkRepo
+
+This is a topic that requires community discussion to decide what the final 
location should be.
+
+# Known Issues
+| Issue | Status |
+|:-:|:--:|
+|...|...|
+
+# Related Links
+- https://edk2.groups.io/g/devel/message/42227
+- https://github.com/tianocore/edk2-platforms
-- 
2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42229): https://edk2.groups.io/g/devel/message/42229
Mute This Topic: https://groups.io/mt/32035973/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 2/2] [staging/EdkRepo-Manifest]: Add EdkRepo manifest XML

[Nate DeSimone]

Signed-off-by: Nate DeSimone 
Cc: Andrew Fish 
Cc: Laszlo Ersek 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
---
 Maintainers.txt | 50 ++
 README.md   | 32 
 2 files changed, 82 insertions(+)
 create mode 100644 Maintainers.txt
 create mode 100644 README.md

diff --git a/Maintainers.txt b/Maintainers.txt
new file mode 100644
index 00..de4817f6ee
--- /dev/null
+++ b/Maintainers.txt
@@ -0,0 +1,50 @@
+EDK II Maintainers
+==
+
+This file provides information about the primary maintainers for
+EdkRepo.
+
+In general, you should not privately email the maintainer. You should
+email the edk2-devel list, but you can also Cc the maintainer.
+
+Descriptions of section entries:
+
+  L: Mailing list that is relevant to this area (default is edk2-devel)
+ Patches and questions should be sent to the email list.
+  M: Cc address for patches and questions (ie, the package maintainer)
+  R: Package Reviewer: Cc address for patches and questions. Reviewers help
+ maintainers review code, but don't have push access. A designated Package
+ Reviewer is reasonably familiar with the Package (or some modules
+ thereof), and/or provides testing or regression testing for the Package
+ (or some modules thereof), in certain platforms and environments.
+  W: Web-page with status/info
+  T: SCM tree type and location.  Type is one of: git, svn.
+  S: Status, one of the following:
+ Supported:  Someone is actually paid to look after this.
+ Maintained: Someone actually looks after it.
+ Odd Fixes:  It has a maintainer but they don't have time to do
+ much other than throw the odd patch in. See below.
+ Orphan: No current maintainer [but maybe you could take the
+ role as you write your new code].
+ Obsolete:   Old code. Something tagged obsolete generally means
+ it has been replaced by a better system and you
+ should be using that.
+
+EDK II
+--
+W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
+L: https://edk2.groups.io/g/devel/
+T: git - https://github.com/tianocore/edk2-staging.git
+
+Responsible Disclosure, Reporting Security Issues
+-
+W: https://github.com/tianocore/tianocore.github.io/wiki/Security
+
+EDK II Packages:
+
+
+EdkRepo Manifest
+W: https://github.com/tianocore/edk2-staging/tree/EdkRepo-Manifest
+M: Nate DeSimone 
+M: Ashley DeSimone 
+R: Puja Pandya 
diff --git a/README.md b/README.md
new file mode 100644
index 00..2145696afb
--- /dev/null
+++ b/README.md
@@ -0,0 +1,32 @@
+This branch is for integrating the EdkRepo tool manifest XML in to EDK2
+
+# Introduction
+
+EdkRepo is the multi-repository tool for EDK II firmware development. This 
branch contains an initial set of example manifest files which can be used to 
try EdkRepo.
+
+# Timeline
+| Time | Event |
+|::|:-:|
+| WW 24 2019 | Initial commit of EdkRepo manifest XML files. |
+|...|...|
+
+# Branch Owners
+- Ashley DeSimone 
+- Nate DeSimone 
+
+# Integration
+EdkRepo could live in several places:
+1. edk2-platforms
+2. edk2-pytool-library
+3. The edk2-toolenv repository proposed by Sean (assuming approval of Sean’s 
RFC)
+4. A new, separate repository created for EdkRepo
+
+This is a topic that requires community discussion to decide what the final 
location should be.
+
+# Known Issues
+| Issue | Status |
+|:-:|:--:|
+|...|...|
+
+# Related Links
+- https://github.com/tianocore/edk2-staging/tree/EdkRepo
-- 
2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42230): https://edk2.groups.io/g/devel/message/42230
Mute This Topic: https://groups.io/mt/32035974/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 0/2] EdkRepo - The Multi-Repository Tool for EDK II

[Nate DeSimone]

This patch series is raised to add the EdkRepo and EdkRepo-Manifest branches
to the Edk2-Staging repository. These branches are added to host EdkRepo,
the multi-repository tool for EDK II firmware development to TianoCore.

For more details on EdkRepo, please see my RFC.

Nate DeSimone (2):
  Add EdkRepo - The Multi-Repo Tool
  Add EdkRepo manifest XML

-- 
2.16.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42228): https://edk2.groups.io/g/devel/message/42228
Mute This Topic: https://groups.io/mt/32035972/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC] EdkRepo - The Multi-Repository Tool for EDK II

[Nate DeSimone]

Hi All,

This RFC is raised to add EdkRepo, the multi-repository tool for EDK II 
firmware development to TianoCore.

EdkRepo is built on top of git. It is intended to automate common developer 
workflows for projects that use more than one git repository. For example many 
of the new projects in the edk2-platforms repository require the user to clone 
several git repositories. EdkRepo makes it easier to set up and upstream 
changes for these projects. EdkRepo does not replace git, rather it provides 
higher level extensions that make it easier to work with git. EdkRepo uses 
"manifest XML" files to describe the git repositories and EDK II packages that 
a project uses. EdkRepo is aware of the DSC file format and is able to combine 
this XML with metadata from DSC files to create a development experience 
tailored specifically for EDK II firmware development. EdkRepo is written in 
Python and is compatible with Python 3.5 or later.

EdkRepo has been internally developed at Intel for 2.5 years. EdkRepo was 
originally created to support our own product development. With the recent 
release of MinPlatformPkg, the number of complete open source UEFI firmware 
implementations available at TianoCore has been growing rapidly. We see that 
many of the development workflows we encounter for our product work now apply 
more broadly to the TianoCore community. Accordingly, we would like to open 
EdkRepo to community.

We see this process going through several phases. First, we provide an initial 
commit of EdkRepo via edk2-staging. We envision two branches being added to 
edk2-staging:

1. EdkRepo - Contains the source code for the EdkRepo tool.
2. EdkRepo-Manifest - Contains an initial set of example manifest files which 
can be used to try EdkRepo

I will send out patches to create these two branches shortly.

After these branches are created, we will send a series of commits to populate 
the first open source version of EdkRepo. At this point the community can take 
a look and provide feedback. There are several options for where the final 
location where this tool might live:

1. edk2-platforms
2. edk2-pytool-library
3. The edk2-toolenv repository proposed by Sean (assuming approval of Sean's 
RFC)
4. A new, separate repository created for EdkRepo

In addition, we recommend that a new TianoCore owned repository be created to 
host the manifest XML content.

The initial proposed maintainer list for EdkRepo is:

M: Nate DeSimone 
M: Ashley DeSimone 
R: Puja Pandya 

I believe a community discussion is needed to make a decision on the exact 
final location. Once consensus is reached, we can retire the edk2-staging 
version of EdkRepo. As always, feedback on this proposal is welcome and 
appreciated.

With Best Regards,
Nate

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42227): https://edk2.groups.io/g/devel/message/42227
Mute This Topic: https://groups.io/mt/32035894/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] ShellPkg/UefiShellBcfgCommandLib: Fix '-opt' option

[Jonathan Watt]

Since I haven't contributed before I'm not sure what the timeline for these
things generally is. It's been a month though. Can the patch be pushed now?

Regards,
Jonathan

On 08/05/2019 01:08, Tim Lewis wrote:
> Yes, I would support it. Tim
> 
> -Original Message-
> From: Carsey, Jaben  
> Sent: Tuesday, May 7, 2019 5:00 PM
> To: Jonathan Watt ; devel@edk2.groups.io; 
> tim.le...@insyde.com; Gao, Zhichao ; Ni, Ray 
> 
> Cc: Bi, Dandan 
> Subject: RE: [edk2-devel] [PATCH v1 1/1] ShellPkg/UefiShellBcfgCommandLib: 
> Fix '-opt' option
> 
> Tim,
> 
> Does this mean you would support such an errata? I would like to get the spec 
> to a place where the behavior is at least nailed down one way or the other...
> 
> -Jaben
> 
>> -Original Message-
>> From: Jonathan Watt [mailto:jw...@jwatt.org]
>> Sent: Tuesday, May 7, 2019 2:08 PM
>> To: devel@edk2.groups.io; tim.le...@insyde.com; Carsey, Jaben 
>> ; Gao, Zhichao ; Ni, 
>> Ray 
>> Cc: Bi, Dandan 
>> Subject: Re: [edk2-devel] [PATCH v1 1/1] ShellPkg/UefiShellBcfgCommandLib:
>> Fix '-opt' option
>> Importance: High
>>
>> No apologies necessary! Raising compatibility concerns is very valid. 
>> As I said, I just wanted to provide some other considerations I saw to 
>> weigh in the decision.
>>
>> All the best,
>> Jonathan
>>
>> On 07/05/2019 22:02, Tim Lewis wrote:
>>> Jonathan --
>>>
>>> My apologies. I jumped because we've been bitten by shell "clarifications"
>> in the past.
>>>
>>> As you've probably read in the other thread, it turns out that I 
>>> (we) actually
>> did agree with your interpretation of the spec in our alternate 
>> implementation and have been using it that way for 2+ years. And it 
>> didn't cause us grief with our other product which does use an EDK2-derived 
>> shell.
>>>
>>> Best regards,
>>> Tim
>>>
>>> -Original Message-
>>> From: devel@edk2.groups.io  On Behalf Of 
>>> Jonathan Watt
>>> Sent: Tuesday, May 7, 2019 1:51 PM
>>> To: Tim Lewis ; 'Carsey, Jaben'
>>> ; devel@edk2.groups.io; 'Gao, Zhichao'
>>> ; 'Ni, Ray' 
>>> Cc: 'Bi, Dandan' 
>>> Subject: Re: [edk2-devel] [PATCH v1 1/1]
>>> ShellPkg/UefiShellBcfgCommandLib: Fix '-opt' option
>>>
>>> Hi Tim,
>>>
>>> For context, I'm just some random guy who tripped over this issue on 
>>> his
>> home workstation and thought he'd try and remove the footgun to save 
>> anyone else the same pain. I was specifically replying to the 
>> unconditional statement "It will break existing scripts." (not made by 
>> you) to provide what I hope was some qualification and balance to the 
>> face value of that statement, and to suggest some other things that 
>> should be considered. As far as deciding what the best resolution is, I'm 
>> not qualified for that.
>>>
>>> I am curious about one thing though. The sentence you wrote that 
>>> ends
>> with "that are implemented to the specification" sounds like you're 
>> saying making the proposed change would violate the specification. 
>> That does not seem to be the case from my reading, and my reading 
>> would be that it would actually make it do what most people would 
>> expect from reading the specification.
>>>
>>> Specifically, the usage block for bcfg in the specification says:
>>>
>>>   Usage:
>>> bcfg driver|boot [dump [-v]]
>>> bcfg driver|boot [add # file "desc"] [addp # file “desc”]
>>>  [addh # handle “desc”]
>>> bcfg driver|boot [rm #]
>>> bcfg driver|boot [mv # #]
>>> bcfg driver|boot [mod # “desc”] | [modf # file] | [modp # file] |
>>>  [modh # handle]
>>> bcfg driver|boot [-opt # [[filename]|[”data”]] |
>>>  [KeyData *]]
>>>
>>> It seems natural to assume from that that the "#" for all options is 
>>> the
>> "same thing" and would be handled the same way.
>>>
>>> The comment for the -opt option does not indicate otherwise:
>>>
>>>   -opt
>>> Modify the optional data associated with a driver or boot option.
>>> Followed either by the filename of the file which contains the
>>> binary data to be associated with the driver or boot option
>>> optional data, or else the quote-delimited data that will be
>>> associated with the driver or boot option optional data.
>>>
>>> In fact the use of the term "driver or boot option" for -opt and the 
>>> other
>> options indicates that it is the same thing as for the other options 
>> (which explicitly say that the "#" is a hexadecimal number), even if 
>> "#" isn't described explicitly in this case.
>>>
>>> I'm glad to hear there are other implementations, because given the
>> disagreement over what the spec intends, it would be useful to compare 
>> them and consider converging.
>>>
>>> Anyway, that's probably enough from me. :)
>>>
>>> Jonathan
>>>
>>> On 07/05/2019 21:04, Tim Lewis wrote:
 Jonathan --

 The bcfg command pre-dates the UEFI shell specification. I know of 
 at
>> least two non-EDK2 implementations, including one maintained by my 
>> company, that 

Re: [edk2-devel] UEFI SCT Build Broken

[Ashish Singhal]

Supreeth,

It is broken against both edk2 tip as well as latest edk2 tag edk2-stable201903.

I have filed a bugzilla 
bug for the same.

Thanks
Ashish

From: Supreeth Venkatesh 
Sent: Tuesday, June 11, 2019 1:36 PM
To: Ashish Singhal; Eric Jin; devel@edk2.groups.io
Subject: RE: UEFI SCT Build Broken


Ashish,



We are working towards fixing the issue for the next SCT tag corresponding to 
edk2 tag.

Can you please let us know whether you are referring to edk2 tip or which edk2 
tag (edk2-stable201903)?



If possible, could you log a bug entry in bugzillafor edk2-test/SCT component?



Thanks,

Supreeth



From: Ashish Singhal 
Sent: Tuesday, June 11, 2019 12:18 PM
To: Supreeth Venkatesh ; Eric Jin 
; devel@edk2.groups.io
Subject: UEFI SCT Build Broken



Hello Eric/Supreeth,



With the latest edk2 tag, UEFI SCT tip build is broken. Seems like it needs 
Guid/SalSystemTable.h header file which is not in edk2 tree any more. Is a fix 
for this already being looked at?



Thanks

Ashish



This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42225): https://edk2.groups.io/g/devel/message/42225
Mute This Topic: https://groups.io/mt/32030281/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] UEFI SCT Build Broken

[Supreeth Venkatesh]

Ashish,

We are working towards fixing the issue for the next SCT tag corresponding to 
edk2 tag.
Can you please let us know whether you are referring to edk2 tip or which edk2 
tag (edk2-stable201903)?

If possible, could you log a bug entry in bugzillafor edk2-test/SCT component?

Thanks,
Supreeth

From: Ashish Singhal 
Sent: Tuesday, June 11, 2019 12:18 PM
To: Supreeth Venkatesh ; Eric Jin 
; devel@edk2.groups.io
Subject: UEFI SCT Build Broken

Hello Eric/Supreeth,

With the latest edk2 tag, UEFI SCT tip build is broken. Seems like it needs 
Guid/SalSystemTable.h header file which is not in edk2 tree any more. Is a fix 
for this already being looked at?

Thanks
Ashish

This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42224): https://edk2.groups.io/g/devel/message/42224
Mute This Topic: https://groups.io/mt/32030281/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] RFC for Edk2-ToolEnv

[Purma, Kondal R]

Hi Sean ,

Sorry I replied to wrong subject and it's about ToolEnv.

It's great that all python files must pass flake8 Python Style. I remember 
flake8 does not show errors for undefined member variables or instances . 

I feel this is one of most common use cases of code failures, due to typing 
errors and won't be visible unless  test that use case.

Are we planning to use any flake8 plug-ins to cover this or is it good idea to 
use Pylint (only to cover features not covered by falke8)on top of flake8.

Thanks,
Kondal.

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Michael D 
Kinney
Sent: Thursday, May 23, 2019 10:14 AM
To: devel@edk2.groups.io; sean.bro...@microsoft.com; Kinney, Michael D 

Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv

Hi Sean,

Thanks for the clarification that this PIP module has more than just build and 
CI.  And over time, it may add more features to help developers maintain their 
code and platforms.  How about

  edk2-tool-extensions

And we perhaps remove plural from the library repo

  edk2-tool-library

Do you think that python needs to be in the repo name so it is obvious these 
are python components.  Or is the top level Readme.md sufficient to make this 
obvious.  Perhaps:

  edk2-pytool-extensions
  edk2-pytool-library

Mike


> -Original Message-
> From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On Behalf Of Sean via Groups.Io
> Sent: Wednesday, May 22, 2019 11:46 PM
> To: Kinney, Michael D ; 
> devel@edk2.groups.io
> Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv
> 
> Yes the plan would be to support both CI and local builds.  There is 
> actually more features related to support platform builds so I think 
> it would be better to keep ci out of the name.  The reason why 
> Tool-Env was suggested is the modules can be used to run anything 
> within the python environment not just builds.
> We have a git submodule update tool, external dependency management 
> tool (package mgmt/binary files), platform build tool, and CI build 
> tool.
> 
> Look at https://github.com/microsoft/mu_pip_environment
> and https://github.com/microsoft/mu_pip_build to get an idea of the 
> content proposed.
> 
> Thanks
> Sean
> 
> 
> 
> -Original Message-
> From: Kinney, Michael D 
> Sent: Wednesday, May 22, 2019 7:39 PM
> To: devel@edk2.groups.io; rebe...@bluestop.org; Sean Brogan 
> 
> Subject: RE: [edk2-devel] RFC for Edk2-ToolEnv
> 
> Hi Sean,
> 
> Does the PIP module here support both local platform builds and CI 
> builds?
> 
> I am looking at the name of the repo and trying to align with the 
> edk2-tools-library repo name so it is obvious the two repos are 
> related.  Maybe focus on the CI part for the name and we reuse the CI 
> features to simplify local builds.
> 
>   edk2-tools-ci
> 
> Finalizing the name is the only open I am aware of.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On Behalf Of
> > rebe...@bluestop.org
> > Sent: Tuesday, May 14, 2019 4:34 PM
> > To: Sean ; devel@edk2.groups.io
> > Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv
> >
> > On 2019-05-14 17:23, sean.brogan via groups.io wrote:
> > > Take a look at the proposed content and how it is
> > used.  We even have
> > > examples of calling from DevOps and i don't think
> > Jenkins would be any
> > > different.  I don't think we are trying to
> duplicate CI
> > > functionality.  We are providing the "last mile" so
> > that those CI
> > > engines can run EDK specific tests and
> tools.  Standard
> > CI engines
> > > have no concept of packages, DSC, FDF, INFs,
> firmware,
> > etc.
> >
> >
> > Okay, that's great. Of course we do also have lots of
> code running on
> > the CI server at work, not the client, that does
> things like packaging
> > etc., and this proposal will include server-side code
> too.
> >
> > Also, I don't think there is anything that'll be as
> nicely integrated
> > as this, so I'm happy with it.
> >
> >
> > --
> > Rebecca Cran
> >
> >
> >
> 
> 
> 





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42223): https://edk2.groups.io/g/devel/message/42223
Mute This Topic: https://groups.io/mt/31614611/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] RFC for Edk2-Library

[Purma, Kondal R]

Hi Sean ,

Its great that all python files must pass flake8 Python Style. I remember 
flake8 does not show errors for undefined member variables or instances . 

I feel this is one of most common use cases of code failures, due to typing 
errors and won't be visible unless  test that use case.

Are we planning to use any flake8 plug-ins to cover this or is it good idea to 
use Pylint (only to cover features not covered by falke8)on top of flake8.

Thanks,
Kondal.

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Michael D 
Kinney
Sent: Wednesday, May 22, 2019 7:32 PM
To: Laszlo Ersek ; devel@edk2.groups.io; 
sean.bro...@microsoft.com; Kinney, Michael D 
Subject: Re: [edk2-devel] RFC for Edk2-Library

Hi Sean,

Can you send an RFC V2 that makes the following changes:

1) Add use of python virtual environments
2) Update Repository name: edk2-tools-library
3) Provide a summary of the APIs/Services that this PIP module 
   provides and the APIs/Services from the edk2 repo that this
   PIP module depends on.
4) Contribution process.  Add recommendation that PRs be focused
   on changes that make sense to be squashed.  Submit a different
   PR for a different feature/issue.  Break up a complex PR into
   multiple PRs.
5) Remove the following bullet:

   "* Potentially move content from basetools/source/python/common/*"

   We can discuss this concept after TianoCore platforms are
   successfully using these new features and the overlap between
   the edk2 repo and edk2-tools-library repo is clearly understood.

A follow on task should evaluate GitHub PR options for submitting and 
preserving a patch series.

Thanks,

Mike


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, May 13, 2019 1:29 PM
> To: Kinney, Michael D ; 
> devel@edk2.groups.io; sean.bro...@microsoft.com
> Subject: Re: [edk2-devel] RFC for Edk2-Library
> 
> On 05/13/19 20:20, Kinney, Michael D wrote:
> > Laszlo,
> >
> > On Windows build systems, we have to install OpenSSL
> command line
> > utilities.  For all host systems, the OpenSSL command
> line
> > utilities need to be in the system path.  My point is
> that this
> > is similar to other dependencies like iASL and NASM.
> 
> OK. I think I must have misunderstood you at some point.
> Sorry about that.
> 
> > For the patch discussion, I did not mean to confuse
> things.  From
> > one perspective, there are two types of patch
> submissions.  Single
> > commit (no series) and multiple commits (patch series).
> The squash
> > merge of a PR works just fine for the single commit (no
> series) type.
> > There may be feedback/comments that require code
> changes and once the
> > PR is accepted, the history in the repository shows a
> single commit.
> > As the PR evolves, commits are made on the PR to
> address each piece
> > of feedback.  Squashing all of these together at the
> time the PR is
> > accepted is the correct action and matches what we do
> the for email
> > based review process.  The final result for both PR and
> email is a
> > single commit with a cleaned up commit message.
> 
> OK.
> 
> > You may consider the single commit (no series) type
> more rare than the
> > multiple commit (patch series) type.  However, there
> may be cases where
> > a multiple commit (patch series) was used where the
> changes could have
> > been submitted as a set of single commit (no series)
> changes.
> 
> OK.
> 
> Thanks
> Laszlo
> 
> >
> > Best regards,
> >
> > Mike
> >
> >> -Original Message-
> >> From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io]
> >> On Behalf Of Laszlo Ersek
> >> Sent: Monday, May 13, 2019 3:46 AM
> >> To: Kinney, Michael D ; 
> >> devel@edk2.groups.io; sean.bro...@microsoft.com
> >> Subject: Re: [edk2-devel] RFC for Edk2-Library
> >>
> >> On 05/10/19 02:01, Kinney, Michael D wrote:
> >>> Laszlo,
> >>>
> >>> 1) We also use OpenSSL command line tool to locally
> >> sign
> >>>capsules and recovery images for local testing.
> So
> >> both
> >>>tool dependency and source dependency apply to the
> >> OpenSSL
> >>>content.
> >>
> >> I haven't used the tools yet that you refer to, so I'm unsure how 
> >> exactly they invoke the "openssl" utility. If they
> just
> >> rely on the PATH
> >> environment variable, then what they invoke comes from the 
> >> system-wide openssl package.
> >>
> >>>
> >>> 2) If a dev submits a PR, and there are many review
> >> comments
> >>>that require code changes, then those code changes
> >> are
> >>>added to that PR until all feedback is addressed.
> >>
> >> I don't understand how. Let's say the pull request
> refers
> >> to a branch
> >> with three commits, and the majority of the review comments request 
> >> updates for patch #2 (i.e., in the middle). How can
> the
> >> submitter "add
> >> changes to the PR"? It is patch #2 that needs to be reworked, which 
> >> will require rebases, and so the hash of the HEAD commit of the 
> >> 

Re: [edk2-devel] [PATCH v1 0/2] OVMF: Drop CSM support

[Laszlo Ersek]

On 06/11/19 08:47, Ard Biesheuvel wrote:
> On Tue, 11 Jun 2019 at 03:30, Hao A Wu  wrote:
>>
>> The series is also available at:
>> https://github.com/hwu25/edk2/tree/ovmf_drop_csm
>>
>> The series will drop the CSM support in OvmfPkg and delete the unused
>> modules.
>>
>> Cc: David Woodhouse 
>> Cc: Ray Ni 
>> Cc: Jordan Justen 
>> Cc: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>>
>> Hao A Wu (2):
>>   OvmfPkg: Remove 'CSM_ENABLE' flag & CSM modules in DSC/FDF files
>>   OvmfPkg/Csm: Remove the components under this folder
>>
> 
> For the series
> 
> Acked-by: Ard Biesheuvel 
> 
> but I will let Laszlo have the final word.

Thanks -- from the discussion under

  [edk2-devel] [PATCH v2 0/6]
  Ovmf: Drop IntelFramework[Module]Pkg dependency

it seems that we're back to the previous group of patch sets, namely:

  [edk2-devel] [PATCH v2 00/10]
  Duplicate required CSM components for OVMF
  (BZ#1811)

  [edk2-devel] [PATCH v1 0/6]
  Ovmf: Drop IntelFramework[Module]Pkg dependency
  (BZ#1843)

  [edk2-devel] [RFC][PATCH v1 0/3]
  Remove IntelFramework[Module]Pkg
  (BZ#1605)

  [edk2-devel] [RFC][PATCH v1 0/1]
  PcAtChipsetPkg: Remove framework modules
  (BZ#1844)

in this dependency order.

(Please see also my earlier message at
<5bb0b7dc-a16e-3ff9-af6e-3c87c6e3744c@redhat.com">http://mid.mail-archive.com/5bb0b7dc-a16e-3ff9-af6e-3c87c6e3744c@redhat.com>.)

Thanks,
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42221): https://edk2.groups.io/g/devel/message/42221
Mute This Topic: https://groups.io/mt/32011732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] UEFI SCT Build Broken

[Ashish Singhal]

Hello Eric/Supreeth,

With the latest edk2 tag, UEFI SCT tip build is broken. Seems like it needs 
Guid/SalSystemTable.h header file which is not in edk2 tree any more. Is a fix 
for this already being looked at?

Thanks
Ashish

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42220): https://edk2.groups.io/g/devel/message/42220
Mute This Topic: https://groups.io/mt/32030281/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH for-next] MdeModulePkg/PciBusDxe: catch unimplemented extended config space reads

[Laszlo Ersek]

On 06/04/19 23:44, Laszlo Ersek wrote:
> When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may
> find that the extended config space is not (fully) implemented. In
> LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as
> 0x_ at a given config space offset, after which the loop gets
> stuck spinning on offset 0xFFC (the read at offset 0xFFC returns
> 0x_ most likely as well).
> 
> Another scenario (not related to virtualization) for triggering the above
> is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the
> topology -- intervenes between a PCI Express Root Port and a PCI Express
> Endpoint. The Conventional PCI bus limits the accessible config space of
> the PCI Express Endpoint, even though the endpoint advertizes the PCI
> Express capability. Here's a diagram, courtesy of Alex Williamson:
> 
>   [PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
>   ->|  |<- Conventional PCI bus
> 
> Catch reads of 0x_ in LocatePciExpressCapabilityRegBlock(), and
> break out of the scan with a warning message. The function will return
> EFI_NOT_FOUND.
> 
> Cc: Alex Williamson 
> Cc: Hao A Wu 
> Cc: Jian J Wang 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> Repo:   https://github.com/lersek/edk2.git
> Branch: pcibus_no_ext_conf
> 
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> index 214aeecdd40a..6283d602207c 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> @@ -236,6 +236,19 @@ LocatePciExpressCapabilityRegBlock (
>break;
>  }
>  
> +if (CapabilityEntry == MAX_UINT32) {
> +  DEBUG ((
> +DEBUG_WARN,
> +"%a: [%02x|%02x|%02x] failed to access config space at offset 
> 0x%x\n",
> +__FUNCTION__,
> +PciIoDevice->BusNumber,
> +PciIoDevice->DeviceNumber,
> +PciIoDevice->FunctionNumber,
> +CapabilityPtr
> +));
> +  break;
> +}
> +
>  CapabilityID = (UINT16) CapabilityEntry;
>  
>  if (CapabilityID == CapId) {
> 

Thank you everyone, patch pushed as commit e5b4d825afc4.

Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42219): https://edk2.groups.io/g/devel/message/42219
Mute This Topic: https://groups.io/mt/31931246/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-announce] TianoCore Community Meeting Minutes

[Stephano Cetola]

On 6/11/2019 8:13 AM, Rebecca Cran wrote:



I should clarify that I don't mind hosting the doxygen docs: there seems
to be a move to have this sort of thing hosted on well-known cloud
services though, which is why I raised it.


Sure, that makes sense. We appreciate you taking the time to host the 
docs yourself. It's my hope that we can get the docs up on something 
like docs.tianocore.org, but we'll see how feasible that is. :)




I'm not sure gitbooks is the ideal solution, given that we'd likely lose
the current flexible search capability (e.g. see
https://code.bluestop.org/edk2/docs/doxygensearch.png), and possibly the
ability to cross-link the source code too?


I think Mike's hope (and please correct me if I'm wrong here Mike), is 
that we automate this process, and be sure that the doxygen docs work in 
concert with our current documentation setup.


What "in concert" looks like is probably up for debate. We want to be 
sure that people who are searching for documentation find both our 
current docs as well as the doxygen docs.


Cheers,
Stephano

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42218): https://edk2.groups.io/g/devel/message/42218
Mute This Topic: https://groups.io/mt/32017009/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[David Woodhouse]

On Tue, 2019-06-11 at 00:35 -0700, Jordan Justen wrote:
> I see that https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> mentions that there is "missing of reviewer/maintainer of the CSM
> modules in OvmfPkg", so it will be dropped. Yet, I thought David
> agreed to maintain that support as recently as May 20:
> 
> https://edk2.groups.io/g/devel/message/41049
> 
> Maybe he changed his mind about it?

No, I'm happy to do it. Just been fairly busy recently.

There appears to be nothing actually on fire this week. I may actually
get to spend some quality time making sure it works again.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42214): https://edk2.groups.io/g/devel/message/42214
Mute This Topic: https://groups.io/mt/32011839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



smime.p7s
Description: S/MIME cryptographic signature

[edk2-devel] [edk2-platforms PATCH] Platform/Socionext/DeveloperBox: add SMBIOS type 17 table

[Masahisa Kojima]

This adds the SMBIOS type 17 table support for Developerbox platform.
The SPDs on a I2C bus is only accessible by the SCP, so SCP-firmware
stores SPDs in non-secure SRAM.

This commit also reduces the uefi stack size to allocate space
for SPDs. It requires 2KB, 512bytes * 4 DIMMs.

Signed-off-by: Masahisa Kojima 
---
 .../Socionext/DeveloperBox/DeveloperBox.dsc   |   3 +
 .../DeveloperBox/DeveloperBox.dsc.inc |   2 +-
 .../SmbiosPlatformDxe/SmbiosPlatformDxe.c | 494 +-
 .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf   |   2 +
 Silicon/Socionext/SynQuacer/SynQuacer.dec |   3 +
 5 files changed, 381 insertions(+), 123 deletions(-)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 97fb8c410c..f247370694 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -147,6 +147,9 @@
 
   gSynQuacerTokenSpaceGuid.PcdDramInfoBase|0x2E00FFC0
 
+  # SCP-firmware stored SPD DDR4 data in non-secure SRAM
+  gSynQuacerTokenSpaceGuid.PcdSmbiosStoredSpdDDR4Address|0x2E00F000
+
   #
   # 96boards mezzanine support
   #
diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
index a10e48ca07..abb113e858 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
@@ -137,7 +137,7 @@
 
   # non-secure SRAM
   gArmPlatformTokenSpaceGuid.PcdCPUCoresStackBase|0x2E00
-  gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0xFFC0
+  gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0xF000
 
   gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24
 
diff --git 
a/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
b/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c
index 6227b77877..da0fd2e6a5 100644
--- a/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c
+++ b/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c
@@ -10,17 +10,48 @@
 **/
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 STATIC EFI_SMBIOS_PROTOCOL   *mSmbios;
 
+#define SPD4_MEM_BUS_WIDTH_8BIT(0x00)
+#define SPD4_MEM_BUS_WIDTH_16BIT   (BIT0)
+#define SPD4_MEM_BUS_WIDTH_32BIT   (BIT1)
+#define SPD4_MEM_BUS_WIDTH_64BIT   (BIT0 | BIT1)
+
+#define SPD4_MEM_DEV_WIDTH_4BIT(0x00)
+#define SPD4_MEM_DEV_WIDTH_8BIT(BIT0)
+#define SPD4_MEM_DEV_WIDTH_16BIT   (BIT1)
+#define SPD4_MEM_DEV_WIDTH_32BIT   (BIT0 | BIT1)
+
+#define SPD4_MEM_MODULE_TYPE_RDIMM0x01
+#define SPD4_MEM_MODULE_TYPE_UDIMM0x02
+#define SPD4_MEM_MODULE_TYPE_SODIMM   0x03
+
+#define TYPE17_DEVICE_LOCATOR_LEN (8 + 1)
+#define TYPE17_BANK_LOCATOR_LEN   (20 + 1)
+#define TYPE17_MANUFACTURER_NAME_LEN  (30 + 1)
+#define TYPE17_SERIAL_NUMBER_LEN  (16 + 1)
+#define TYPE17_ASSETTAG_LEN   (16 + 1)
+#define TYPE17_MODULE_PART_NUMBER_LEN (20 + 1)
+
+#define TYPE17_STRINGS_MAX_LEN(TYPE17_DEVICE_LOCATOR_LEN + \
+   TYPE17_BANK_LOCATOR_LEN + \
+   TYPE17_MANUFACTURER_NAME_LEN + \
+   TYPE17_SERIAL_NUMBER_LEN + \
+   TYPE17_ASSETTAG_LEN + \
+   TYPE17_MODULE_PART_NUMBER_LEN + \
+   1/* null SMBIOS_TABLE_STRING terminator 
*/ )
+
 //
 // Type definition and contents of the default SMBIOS table.
 // This table covers only the minimum structures required by
@@ -69,7 +100,7 @@ typedef struct {
 
 typedef struct {
   SMBIOS_TABLE_TYPE17 Base;
-  CHAR8   Strings[];
+  CHAR8   Strings[TYPE17_STRINGS_MAX_LEN];
 } ARM_TYPE17;
 
 typedef struct {
@@ -94,6 +125,69 @@ enum {
   SMBIOS_HANDLE_MEMORY,
 };
 
+struct JEP106_MANUFACTURER_TABLE {
+  UINT16 ManufacturerId;
+  CHAR8  ManufacturerName[TYPE17_MANUFACTURER_NAME_LEN];
+};
+
+STATIC CONST struct JEP106_MANUFACTURER_TABLE Manufacturer[] = {
+  {0x0010, "NEC\0"},
+  {0x002C, "Micron Technology\0"},
+  {0x003D, "Tektronix\0"},
+  {0x0097, "Texas Instruments\0"},
+  {0x00AD, "SK Hynix\0"},
+  {0x00B3, "IDT\0"},
+  {0x00C1, "Infineon\0"},
+  {0x00CE, "Samsung\0"},
+  {0x00DA, "Winbond Electronic\0"},
+  {0x014F, "Transcend Information\0"},
+  {0x0194, "Smart Modular\0"},
+  {0x0198, "Kingston\0"},
+  {0x02C8, "Agilent Technologies\0"},
+  {0x02FE, "Elpida\0"},
+  {0x030B, "Nanya Technology\0"},
+  {0x0443, "Ramaxel Technology\0"},
+  {0x04B3, "Inphi Corporation\0"},
+  {0x04C8, "Powerchip Semiconductor\0"},
+  {0x0551, "Qimonda\0"},
+  {0x0557, "AENEON\0"},
+  {0x059B, "Crucial Technology\0"},
+  {0x, "Unknown\0"}
+};
+
+enum SPD4_SDRAM_CAPACITY {
+  SPD4_SDRAM_CAPACITY_256MBIT = 0,
+  SPD4_SDRAM_CAPACITY_512MBIT,
+  SPD4_SDRAM_CAPACITY_1GBIT,
+  

Re: [edk2-devel] [edk2-platform patch 4/4] PurleyOpenBoardPkg: Update FDF to use the generic Microcode FFS rules

[Zhou, Bowen]

reviewed-by: Xiaohu Zhou 

-Original Message-
From: Gao, Liming 
Sent: Tuesday, June 11, 2019 1:04 PM
To: devel@edk2.groups.io
Cc: Lu, Shifei A ; Zhou, Bowen 
Subject: [edk2-platform patch 4/4] PurleyOpenBoardPkg: Update FDF to use the 
generic Microcode FFS rules

Signed-off-by: Liming Gao 
Cc: Shifei A Lu 
Cc: Xiaohu Zhou 
---
 Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.fdf | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.fdf 
b/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.fdf
index e7523da74e..182e197344 100644
--- a/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.fdf
+++ b/Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.fdf
@@ -194,9 +194,7 @@ READ_STATUS= TRUE
 READ_LOCK_CAP  = TRUE
 READ_LOCK_STATUS   = TRUE
 
-FILE RAW = 197DB236-F856-4924-90F8-CDF12FB875F3 {
-  $(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/X64/Microcode.bin
-}
+INF RuleOverride = MICROCODE $(SILICON_BIN_PKG)/Microcode/Microcode.inf
 
 [FV.FvPreMemory]
 FvAlignment= 16
-- 
2.13.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42213): https://edk2.groups.io/g/devel/message/42213
Mute This Topic: https://groups.io/mt/32013038/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[David Woodhouse]

On Tue, 2019-06-11 at 07:49 +, Wu, Hao A wrote:
> Hello all,
> 
> For the series:
> [PATCH v2 00/10] Duplicate required CSM components for OVMF
> https://edk2.groups.io/g/devel/message/41385
> 
> I sent it out on May 27th, and did not receive a confirmation from David
> for about 2 weeks. I think maybe the CSM support on OVMF is no longer
> cared, and thus I sent another series today to drop such support: 
> [PATCH v1 0/2] OVMF: Drop CSM support
> https://edk2.groups.io/g/devel/message/42142
> 
> Please help to provide some feedbacks/confirmation on what should I do for
> the next step. (This task actually blocks our proposal to remove
> IntelFramework[Module]Pkg from edk2.)


Apologies for the delay. It wasn't clear that the first series was
actually tested by booting with a CSM, and I was reluctant to ack it
without knowing that it didn't cause a regression.

This is, of course, complicated by the fact that I can't actually get a
CSM boot to complete at the moment. But it gets a long way into the
boot process before something goes wrong, so confirmation that it still
gets at least that far with your 'Duplicate required CSM components'
series would be good.

Is there a git tree I can pull from? I seem to recall that last time I
spent serious time working on OVMF, life was horribly complicated by
CRLF line endings, and it was extremely painful to just apply patches
from email... is that still the case?



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42215): https://edk2.groups.io/g/devel/message/42215
Mute This Topic: https://groups.io/mt/32011839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



smime.p7s
Description: S/MIME cryptographic signature

Re: [edk2-devel] edk2-docs hosted on legacy gitbook site - is migration to new version planned?

[Laszlo Ersek]

Hi,

On 06/11/19 16:29, Rebecca Cran wrote:
> I noticed the edk2-docs are hosted on the *legacy* gitbook.com site, at
> https://legacy.gitbook.com/@edk2-docs .
> 
> Are there any plans to migrate to the new version
> (https://docs.gitbook.com/getting-started/migrating-from-the-previous-version)?

if I click the "HTML" links in the Wiki article at:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Specifications

for example the "HTML" link for the Build Spec, I land at:

https://edk2-docs.gitbooks.io/edk-ii-build-specification/content/v/release/1.28/

This is the "new version" of gitbook, right?


I certainly have the link  in my
browser history as well, but I'm not sure where it is still referenced
from... Ah wait, after grepping a local clone of the edk2 wiki, the
following article does have a reference:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Documents

under caption "EDK II Documents on GitBook". I guess that link should be
updated, but I'm not sure what to. FWIW, if I just enter
, it redirects to
 :/

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42212): https://edk2.groups.io/g/devel/message/42212
Mute This Topic: https://groups.io/mt/32016430/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC] Fine-grained review ownership for MdeModulePkg

[Laszlo Ersek]

On 06/11/19 11:51, Leif Lindholm wrote:
> Hi Wu Hao,
> 
> I am working on a proposal (and proof-of-concept) machine readable
> Maintainers.txt format, and a GetMaintainer.py script, based on the
> format used by QEMU.
> 
> One of the key features of that format is the F: tag, which specifes a
> filesytem path (with wildcard support).

This is great news! QEMU's pathnames are very flexible.

> 
> While this is just an RFC in progress (to be sent out later in week),
> if you could take that into account, and figure out which paths
> correspond to which areas of responsibility, that would make a test
> run of the script much easier.
> 
> For my part, I would suggest adding (not just for MdeModulePkg)
> F: */ARM/*
> F: */AARCH64/*
> as maintained by myself and Ard.

* Under ArmVirtPkg, we distinguish "Xen modules":

R: Julien Grall 
   (Xen modules)

I hope that Ard can come up with a set of patterns for these modules. :)

* Under OvmfPkg, we distinguish:

R: Anthony Perard 
   (Xen modules)
R: Julien Grall 
   (Xen modules)

and

R: Marc-André Lureau 
   (TPM2 modules)
R: Stefan Berger 
   (TPM2 modules)

For "Xen modules", I'd suggest:

F: OvmfPkg/AcpiPlatformDxe/Xen.c
F: OvmfPkg/Include/Guid/Xen*.h
F: OvmfPkg/Include/IndustryStandard/Xen/
F: OvmfPkg/Include/Library/Xen*.h
F: OvmfPkg/Include/Protocol/Xen*.h
F: OvmfPkg/Library/PciHostBridgeLib/XenSupport.c
F: OvmfPkg/Library/XenConsoleSerialPortLib/
F: OvmfPkg/Library/XenHypercallLib/
F: OvmfPkg/Library/XenIoMmioLib
F: OvmfPkg/PlatformPei/Xen.*
F: OvmfPkg/SmbiosPlatformDxe/*Xen.c
F: OvmfPkg/XenBusDxe/
F: OvmfPkg/XenIoPciDxe/
F: OvmfPkg/XenPvBlkDxe/

For "TPM2 modules":

F: OvmfPkg/Include/IndustryStandard/QemuTpm.h
F: OvmfPkg/Library/Tcg2PhysicalPresenceLib*/
F: OvmfPkg/Tcg/

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42210): https://edk2.groups.io/g/devel/message/42210
Mute This Topic: https://groups.io/mt/32001926/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V2] EmulatorPkg: don't diaplay the cpu current speed

[Laszlo Ersek]

On 06/10/19 09:16, Ni, Ray wrote:
> Hao,
> Can you please list the detailed sub-directories/modules/libraries for each 
> major feature, including those that are not covered by the major features? 
> This avoid misunderstanding and is also needed by the Maintainers.txt.

I agree. Every module INF file needs an assigned maintainer that can be
determined mechanically.

Currently, there are 224 INF files under MdeModulePkg. We need to
provide a list that covers each one of these INF files by pathname.
Wildcards are fine to use of course.

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42208): https://edk2.groups.io/g/devel/message/42208
Mute This Topic: https://groups.io/mt/31907735/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-announce] TianoCore Community Meeting Minutes

[rebecca]

[replying to devel@]

On 2019-06-10 12:47, Stephano Cetola wrote:
>
> Documentation
> -
> Rebecca is hosting the Doxygen docs from packages on her server, and
> it is probably better if we use a cloud service to host these, or
> better yet, our current gitbooks system. However, there is a small
> issue with the way Doxygen changes folder structures between builds.
> Since we would be checking this into git (see:
> gitbook/TianoCore-Docs), it would cause a lot of git history
> thrashing. Mike has found ways around this, however we want to be sure
> that searching (particularly across packages) would be possible before
> we go down this road. 


I should clarify that I don't mind hosting the doxygen docs: there seems
to be a move to have this sort of thing hosted on well-known cloud
services though, which is why I raised it.

I'm not sure gitbooks is the ideal solution, given that we'd likely lose
the current flexible search capability (e.g. see
https://code.bluestop.org/edk2/docs/doxygensearch.png), and possibly the
ability to cross-link the source code too?

I had a look at the directory structure my doxygen configuration is
generating, and it doesn't have any sub-directories at all: all 27,783
files (229 MB) for the github master docs are in the top-level directory.


-- 
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42207): https://edk2.groups.io/g/devel/message/42207
Mute This Topic: https://groups.io/mt/32017009/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/README: Update the network build flags

[Laszlo Ersek]

On 06/10/19 08:55, Gary Lin wrote:
> The following network build flags changed due to the inclusion of
> NetworkPkg/Network.fdf.inc.
> 
>   HTTP_BOOT_ENABLE -> NETWORK_HTTP_BOOT_ENABLE
>   TLS_ENABLE -> NETWORK_TLS_ENABLE
> 
> This commit also adds NETWORK_ALLOW_HTTP_CONNECTIONS to reflect the
> change in OvmfPkg/OvmfPkg*.dsc.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1884
> Signed-off-by: Gary Lin 
> ---
>  OvmfPkg/README | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/OvmfPkg/README b/OvmfPkg/README
> index c014d07bfbdb..3dd28474ead4 100644
> --- a/OvmfPkg/README
> +++ b/OvmfPkg/README
> @@ -260,9 +260,14 @@ HTTPS Boot is an alternative solution to PXE. It 
> replaces the tftp server
>  with a HTTPS server so the firmware can download the images through a trusted
>  and encrypted connection.
>  
> -* To enable HTTPS Boot, you have to build OVMF with -D HTTP_BOOT_ENABLE and
> -  -D TLS_ENABLE. The former brings in the HTTP stack from NetworkPkg while
> -  the latter enables TLS support in both NetworkPkg and CryptoPkg.
> +* To enable HTTPS Boot, you have to build OVMF with -D 
> NETWORK_HTTP_BOOT_ENABLE
> +  and -D NETWORK_TLS_ENABLE. The former brings in the HTTP stack from
> +  NetworkPkg while the latter enables TLS support in both NetworkPkg and
> +  CryptoPkg.
> +
> +  If you want to exclude the unsecured HTTP connection completely, OVMF has 
> to
> +  be built with -D NETWORK_ALLOW_HTTP_CONNECTIONS=FALSE so that only the 
> HTTPS
> +  connections will be accepted.
>  
>  * By default, there is no trusted certificate. The user has to import the
>certificates either manually with "Tls Auth Configuration" utility in the
> 

Reviewed-by: Laszlo Ersek 

Pushed as commit 1631bb26ae99.

Thank you!
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42206): https://edk2.groups.io/g/devel/message/42206
Mute This Topic: https://groups.io/mt/32001627/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Upcoming Event: TianoCore Design / Bug Triage - EMEA - Wed, 06/12/2019 8:00am-9:00am #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Design / Bug Triage - EMEA

*When:* Wednesday, 12 June 2019, 8:00am to 9:00am, (GMT-07:00) America/Los 
Angeles

*Where:* https://zoom.us/j/695893389

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=488583 )

*Organizer:* Stephano Cetola stephano.cet...@linux.intel.com ( 
stephano.cet...@linux.intel.com?subject=Re:%20Event:%20TianoCore%20Design%20%2F%20Bug%20Triage%20-%20EMEA
 )

*Description:*

Join Zoom Meeting

https://zoom.us/j/695893389

One tap mobile

+17207072699,,695893389# US

+16465588656,,695893389# US (New York)

Dial by your location

+1 720 707 2699 US

+1 646 558 8656 US (New York)

Meeting ID: 695 893 389

Find your local number: https://zoom.us/u/abOtdJckxL

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42205): https://edk2.groups.io/g/devel/message/42205
Mute This Topic: https://groups.io/mt/32016828/21656
Mute #cal-reminder: https://groups.io/mk?hashtag=cal-reminder=3846945
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] edk2-docs hosted on legacy gitbook site - is migration to new version planned?

[rebecca]

I noticed the edk2-docs are hosted on the *legacy* gitbook.com site, at
https://legacy.gitbook.com/@edk2-docs .

Are there any plans to migrate to the new version
(https://docs.gitbook.com/getting-started/migrating-from-the-previous-version)?


-- 

Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42204): https://edk2.groups.io/g/devel/message/42204
Mute This Topic: https://groups.io/mt/32016430/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH] Platform/Socionext/DeveloperBox: add SMBIOS type 17 table

[Ard Biesheuvel]

On Tue, 11 Jun 2019 at 14:18, Masahisa Kojima
 wrote:
>
> This adds the SMBIOS type 17 table support for Developerbox platform.
> The SPDs on a I2C bus is only accessible by the SCP, so SCP-firmware
> stores SPDs in non-secure SRAM.
>
> This commit also reduces the uefi stack size to allocate space
> for SPDs. It requires 2KB, 512bytes * 4 DIMMs.
>
> Signed-off-by: Masahisa Kojima 

So this patch depends on SCP fw changes that are not yet available,
right? That is not a problem, but I will hold off on merging it until
we have a new SCP firmware build in the tree.

Some comments below.

> ---
>  .../Socionext/DeveloperBox/DeveloperBox.dsc   |   3 +
>  .../DeveloperBox/DeveloperBox.dsc.inc |   2 +-
>  .../SmbiosPlatformDxe/SmbiosPlatformDxe.c | 494 +-
>  .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf   |   2 +
>  Silicon/Socionext/SynQuacer/SynQuacer.dec |   3 +
>  5 files changed, 381 insertions(+), 123 deletions(-)
>
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> index 97fb8c410c..f247370694 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
> @@ -147,6 +147,9 @@
>
>gSynQuacerTokenSpaceGuid.PcdDramInfoBase|0x2E00FFC0
>
> +  # SCP-firmware stored SPD DDR4 data in non-secure SRAM
> +  gSynQuacerTokenSpaceGuid.PcdSmbiosStoredSpdDDR4Address|0x2E00F000
> +

Please drop 'Smbios' from this PCD name - we may want to use the SPD
data in a different way in the future.

>#
># 96boards mezzanine support
>#
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
> index a10e48ca07..abb113e858 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
> @@ -137,7 +137,7 @@
>
># non-secure SRAM
>gArmPlatformTokenSpaceGuid.PcdCPUCoresStackBase|0x2E00
> -  gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0xFFC0
> +  gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0xF000
>
>gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|24
>
> diff --git 
> a/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
> b/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> index 6227b77877..da0fd2e6a5 100644
> --- a/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> +++ b/Platform/Socionext/DeveloperBox/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> @@ -10,17 +10,48 @@
>  **/
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
>  STATIC EFI_SMBIOS_PROTOCOL   *mSmbios;
>
> +#define SPD4_MEM_BUS_WIDTH_8BIT(0x00)
> +#define SPD4_MEM_BUS_WIDTH_16BIT   (BIT0)
> +#define SPD4_MEM_BUS_WIDTH_32BIT   (BIT1)
> +#define SPD4_MEM_BUS_WIDTH_64BIT   (BIT0 | BIT1)
> +
> +#define SPD4_MEM_DEV_WIDTH_4BIT(0x00)
> +#define SPD4_MEM_DEV_WIDTH_8BIT(BIT0)
> +#define SPD4_MEM_DEV_WIDTH_16BIT   (BIT1)
> +#define SPD4_MEM_DEV_WIDTH_32BIT   (BIT0 | BIT1)
> +
> +#define SPD4_MEM_MODULE_TYPE_RDIMM0x01
> +#define SPD4_MEM_MODULE_TYPE_UDIMM0x02
> +#define SPD4_MEM_MODULE_TYPE_SODIMM   0x03
> +
> +#define TYPE17_DEVICE_LOCATOR_LEN (8 + 1)
> +#define TYPE17_BANK_LOCATOR_LEN   (20 + 1)
> +#define TYPE17_MANUFACTURER_NAME_LEN  (30 + 1)
> +#define TYPE17_SERIAL_NUMBER_LEN  (16 + 1)
> +#define TYPE17_ASSETTAG_LEN   (16 + 1)
> +#define TYPE17_MODULE_PART_NUMBER_LEN (20 + 1)
> +
> +#define TYPE17_STRINGS_MAX_LEN(TYPE17_DEVICE_LOCATOR_LEN + \
> +   TYPE17_BANK_LOCATOR_LEN + \
> +   TYPE17_MANUFACTURER_NAME_LEN + \
> +   TYPE17_SERIAL_NUMBER_LEN + \
> +   TYPE17_ASSETTAG_LEN + \
> +   TYPE17_MODULE_PART_NUMBER_LEN + \
> +   1/* null SMBIOS_TABLE_STRING 
> terminator */ )
> +
>  //
>  // Type definition and contents of the default SMBIOS table.
>  // This table covers only the minimum structures required by
> @@ -69,7 +100,7 @@ typedef struct {
>
>  typedef struct {
>SMBIOS_TABLE_TYPE17 Base;
> -  CHAR8   Strings[];
> +  CHAR8   Strings[TYPE17_STRINGS_MAX_LEN];
>  } ARM_TYPE17;
>
>  typedef struct {
> @@ -94,6 +125,69 @@ enum {
>SMBIOS_HANDLE_MEMORY,
>  };
>
> +struct JEP106_MANUFACTURER_TABLE {
> +  UINT16 ManufacturerId;
> +  CHAR8  ManufacturerName[TYPE17_MANUFACTURER_NAME_LEN];
> +};
> +
> +STATIC CONST struct JEP106_MANUFACTURER_TABLE Manufacturer[] = {
> +  {0x0010, "NEC\0"},
> +  {0x002C, "Micron Technology\0"},
> +  {0x003D, "Tektronix\0"},
> +  {0x0097, "Texas Instruments\0"},
> +  {0x00AD, "SK Hynix\0"},
> +  {0x00B3, "IDT\0"},
> +  {0x00C1, "Infineon\0"},
> +  {0x00CE, "Samsung\0"},
> +  

Re: [edk2-devel] [PATCH v1 1/1] DynamicTablesPkg: GTDT updates for ACPI 6.3

[Sami Mujawar]

Pushed as 77db115601fb..e8015f2facff

-Original Message-
From: Sami Mujawar 
Sent: 11 June 2019 09:55 AM
To: devel@edk2.groups.io
Cc: nd 
Subject: RE: [PATCH v1 1/1] DynamicTablesPkg: GTDT updates for ACPI 6.3

Reviewed-by: Sami Mujawar 

-Original Message-
From: PierreGondois  
Sent: 06 June 2019 10:21 AM
To: devel@edk2.groups.io
Cc: Sami Mujawar ; Alexei Fedorov 
; Matteo Carlini ; Stephanie 
Hughes-Fitt ; Pierre Gondois 
; nd 
Subject: [PATCH v1 1/1] DynamicTablesPkg: GTDT updates for ACPI 6.3

From: Pierre Gondois 

The ACPI 6.3 specification adds support for describing
ARMv8.1 EL2 virtual timers. Update GTDTGenerator to extend this support.

Signed-off-by: Pierre Gondois 
---

The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/381_dynamicTables_gtdt_acpi6_3_update_v1

Notes:
v1:
- Add support for describing ARMv8.1 EL2 virtual timers and update
  GTDTGenerator to extend this support. [Pierre]

 DynamicTablesPkg/Include/ArmNameSpaceObjects.h   |  6 ++
 DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c | 69 
+++-
 2 files changed, 44 insertions(+), 31 deletions(-)

diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 
bf70dc76cea044b9a8e8eb529d2ddbf892bafd58..0b00c8669729138e910d1fa09870f12dbc2a02a6
 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -290,6 +290,12 @@ typedef struct CmArmGenericTimerInfo {
 
   /// The non-secure PL2 timer flags
   UINT32  NonSecurePL2TimerFlags;
+
+  /// GSIV for the virtual EL2 timer
+  UINT32 VirtualPL2TimerGSIV;
+
+  /// Flags for the virtual EL2 timer
+  UINT32 VirtualPL2TimerFlags;
 } CM_ARM_GENERIC_TIMER_INFO;
 
 /** A structure that describes the
diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
index 
8d9ddcf9244b9f8b795edf7a53dd8a071bb121bc..adc91c073efcac8e06997658b20096ae0b7d7b86
 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
+++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
@@ -5,7 +5,7 @@
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
   @par Reference(s):
-  - ACPI 6.2 Specification - Errata A, September 2017
+  - ACPI 6.3 Specification - January 2019
 
 **/
 
@@ -77,7 +77,7 @@ GET_OBJECT_LIST (
   Protocol Interface.
   @param [in]  Gtdt   Pointer to the GTDT Table.
   @param [in]  PlatformTimerCount Platform timer count.
-
+  @param [in]  AcpiTableRevision  Acpi Revision targeted by the platform.
   @retval EFI_SUCCESS   Success.
   @retval EFI_INVALID_PARAMETER A parameter is invalid.
   @retval EFI_NOT_FOUND The required object was not found.
@@ -90,8 +90,9 @@ EFI_STATUS
 EFIAPI
 AddGenericTimerInfo (
   IN  CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL * CONST 
CfgMgrProtocol,
-  INEFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE * CONST Gtdt,
-  IN  CONST UINT32   
PlatformTimerCount
+  INEFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE * CONST Gtdt,
+  IN  CONST UINT32   
PlatformTimerCount,
+  IN  CONST UINT32   
AcpiTableRevision
 )
 {
   EFI_STATUS   Status;
@@ -131,9 +132,14 @@ AddGenericTimerInfo (
 GenericTimerInfo->CounterReadBaseAddress;
   Gtdt->PlatformTimerCount = PlatformTimerCount;
   Gtdt->PlatformTimerOffset = (PlatformTimerCount == 0) ? 0 :
-sizeof (EFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE);
+sizeof (EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE);
 
-  return EFI_SUCCESS;
+  if (AcpiTableRevision > 
EFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE_REVISION) {
+Gtdt->VirtualPL2TimerGSIV = GenericTimerInfo->VirtualPL2TimerGSIV;
+Gtdt->VirtualPL2TimerFlags = 
+ GenericTimerInfo->VirtualPL2TimerFlags;
+  }
+
+  return Status;
 }
 
 /** Add the SBSA Generic Watchdog Timers to the GTDT table.
@@ -147,26 +153,26 @@ AddGenericTimerInfo (  STATIC  VOID  
AddGenericWatchdogList (
-  IN EFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE  * CONST Gtdt,
+  IN EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE  * CONST Gtdt,
   IN CONST UINT32  WatchdogOffset,
   IN CONST CM_ARM_GENERIC_WATCHDOG_INFO*   WatchdogInfoList,
   IN   UINT32  WatchdogCount
   )
 {
-  EFI_ACPI_6_2_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE  * Watchdog;
+  EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE  * Watchdog;
 
   ASSERT (Gtdt != NULL);
   ASSERT (WatchdogInfoList != NULL);
 
-  Watchdog = (EFI_ACPI_6_2_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE *)
+  Watchdog = (EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE *)
  ((UINT8*)Gtdt + WatchdogOffset);
 
   while 

Re: [edk2-devel] [PATCH edk2-platforms 5/5] Platform/RDKQemu: stop using deprecated string conversion routines

[Ard Biesheuvel]

On Mon, 10 Jun 2019 at 21:01, Leif Lindholm  wrote:
>
> On Mon, Jun 10, 2019 at 08:55:03PM +0200, Ard Biesheuvel wrote:
> > On Mon, 10 Jun 2019 at 20:06, Leif Lindholm  
> > wrote:
> > >
> > > On Mon, Jun 10, 2019 at 04:20:06PM +0200, Ard Biesheuvel wrote:
> > > > Stop using deprecated string conversion routines so we can stop
> > > > un'#define'ing the DISABLE_NEW_DEPRECATED_INTERFACES macro in this code.
> > > >
> > > > Signed-off-by: Ard Biesheuvel 
> > > > ---
> > > >  Platform/Comcast/Library/RdkBootManagerLib/DiskIo.c  | 12 +++--
> > > >  Platform/Comcast/Library/RdkBootManagerLib/RdkFile.c | 28 
> > > > +++-
> > > >  Platform/Comcast/RDKQemu/RDKQemu.dsc |  3 ---
> > > >  3 files changed, 26 insertions(+), 17 deletions(-)
> > > >
> > > > diff --git a/Platform/Comcast/Library/RdkBootManagerLib/DiskIo.c 
> > > > b/Platform/Comcast/Library/RdkBootManagerLib/DiskIo.c
> > > > index ed893bd5af6a..df16c326cc57 100644
> > > > --- a/Platform/Comcast/Library/RdkBootManagerLib/DiskIo.c
> > > > +++ b/Platform/Comcast/Library/RdkBootManagerLib/DiskIo.c
> > > > @@ -90,6 +90,7 @@ ListBlockIos (
> > > >UINTN NumHandles;
> > > >UINT16*DeviceFullPath;
> > > >DISKIO_PARTITION_LIST *Entry;
> > > > +  RETURN_STATUS RetStatus;
> > > >
> > > >InitializeListHead ();
> > > >
> > > > @@ -146,11 +147,13 @@ ListBlockIos (
> > > >
> > > >// Copy handle and partition name
> > > >Entry->PartitionHandle = AllHandles[LoopIndex];
> > > > -  StrnCpy (
> > > > +  RetStatus = StrnCpyS (
> > > >  Entry->PartitionName,
> > > > +PARTITION_NAME_MAX_LENGTH,
> > > >  PartitionName,
> > > >  PARTITION_NAME_MAX_LENGTH
> > > >);
> > > > +  ASSERT_RETURN_ERROR (RetStatus);
> > >
> > > Would we not want to return an error here, for non-DEBUG builds?
> > >
> >
> > Actually, I think I should just change the last arg to
> > PARTITION_NAME_MAX_LENGTH - 1, in which case no input length based
> > error is ever returned.
>
> Thats works for me.
> With that, and the below style fixes:
> Reviewed-by: Leif Lindholm 
>


Thanks

Series pushed as  cf5d0a48c1d9..9f814bbee5d5

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42200): https://edk2.groups.io/g/devel/message/42200
Mute This Topic: https://groups.io/mt/32004766/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC] Fine-grained review ownership for MdeModulePkg

[Leif Lindholm]

Hi Wu Hao,

I am working on a proposal (and proof-of-concept) machine readable
Maintainers.txt format, and a GetMaintainer.py script, based on the
format used by QEMU.

One of the key features of that format is the F: tag, which specifes a
filesytem path (with wildcard support).

While this is just an RFC in progress (to be sent out later in week),
if you could take that into account, and figure out which paths
correspond to which areas of responsibility, that would make a test
run of the script much easier.

For my part, I would suggest adding (not just for MdeModulePkg)
F: */ARM/*
F: */AARCH64/*
as maintained by myself and Ard.

Best Regards,

Leif

On Mon, Jun 10, 2019 at 08:06:23AM +, Wu, Hao A wrote:
> Hello all,
> 
> Driven by the issue raised and discussions with thread:
> https://edk2.groups.io/g/devel/topic/31907735#42076
> 
> This RFC proposal is raised to work out a fine-grained review ownership
> for MdeModulePkg.
> 
> The goal is to update the 'MdeModulePkg' section in file Maintainers.txt
> to resemble the format like the 'OvmfPkg' section. Several reviewers will
> be listed to take the ownership to review patches for a specific feature
> in the package.
> 
> In order to get the list of reviewers, a 2-step process will be adopted:
> 1. Work out a list that contains major features in MdeModulePkg.
> 2. Call for owners for every item in the list.
> 
> For 1, a coarse feature list is:
> Acpi
> Bds
> Capsule
> Compress
> Console
> Core (PeiCore, DxeCore, PiSmmCore, etc. Mainly content in MdeModulePkg/Core/ 
> folder)
> Device (peripheral & storage)
> Disk
> EBC
> HII
> MemoryManagement (include memory test, memory allocation, memory profile, 
> etc.)
> PCD
> PCI bus
> Reset
> S3 (including LockBox)
> SMBIOS
> SMM
> Status Code
> UI
> Variable
> Misc (all the components that do not fit in the above items)
> 
> Once we think the granularity of the above list is fine and there is no
> significant feature missing, I will update such list to include the
> modules that belong to a specific feature. So adjustments can be done to
> work out the final feature list.
> 
> The proposal here is far from mature, so any feedback/suggestion will be
> appreciated.
> 
> 
> Best Regards,
> Hao Wu
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42198): https://edk2.groups.io/g/devel/message/42198
Mute This Topic: https://groups.io/mt/32001926/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop IntelFramework[Module]Pkg dependency

[Leif Lindholm]

On Tue, Jun 11, 2019 at 06:19:50AM +, Wu, Hao A wrote:
> Can I go ahead to push this series?
> Or should I wait someone for additional review?

Go for it.
My ACK applies to the series.

Best Regards,

Leif

> Best Regards,
> Hao Wu
> 
> > 
> > On Mon, Jun 10, 2019 at 05:13:42AM +, Wu, Hao A wrote:
> > > Hello Ard and Leif,
> > >
> > > I saw Ming Huang  validated the patch (OS boot):
> > > Hisilicon/D0x: Use StatusCode Router & Handler in MdeModulePkg
> > >
> > > https://edk2.groups.io/g/devel/message/41419
> > > (Thanks a lot for the validation effort.)
> > >
> > > Do you have remaining concerns for review this series?
> > > Thanks in advance.
> > >
> > > Best Regards,
> > > Hao Wu
> > >
> > >
> > > > -Original Message-
> > > > From: Wu, Hao A
> > > > Sent: Monday, May 27, 2019 10:43 AM
> > > > To: devel@edk2.groups.io; Ard Biesheuvel; Leif Lindholm
> > > > Cc: Kinney, Michael D; Andrew Fish; Laszlo Ersek; Ni, Ray;
> > > > guoh...@huawei.com
> > > > Subject: RE: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop
> > > > IntelFramework[Module]Pkg dependency
> > > >
> > > > Hello Ard and Leif,
> > > >
> > > > Do you have comments on this series?
> > > >
> > > > Also, for the below patch to Hisilicon platforms:
> > > > [PATCH v2 06/18] Hisilicon/D0x: Use StatusCode Router & Handler in
> > > > MdeModulePkg
> > > >
> > > > it is suggested to be verified on actual hardware:
> > > > https://edk2.groups.io/g/devel/topic/31614327#41188
> > > >
> > > > However, it seems that there is no accessible hardware for such
> > verification
> > > > at this moment. Do you think it is fine to push this change anyway?
> > > >
> > > > (Also CCed the stewards here for comments.)
> > > >
> > > > Best Regards,
> > > > Hao Wu
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf
> > Of
> > > > > Wu, Hao A
> > > > > Sent: Monday, May 20, 2019 4:41 PM
> > > > > To: devel@edk2.groups.io
> > > > > Cc: Wu, Hao A; Ard Biesheuvel; Leif Lindholm; Kinney, Michael D
> > > > > Subject: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop
> > > > > IntelFramework[Module]Pkg dependency
> > > > >
> > > > > The series is also available at:
> > > > > https://github.com/hwu25/edk2-
> > > > > platforms/commits/drop_intelframework_v2
> > > > >
> > > > > V2 changes:
> > > > > A. For platforms BeagleBoard, CelloBoard and Overdrive1000Board,
> > update
> > > > >their DSC file to consume the null ReportStatusCodeLib in MdePkg.
> > The
> > > > >change is done since these platforms do not have a StatusCode
> > Router
> > > > >module;
> > > > > B. Add the change for platform RaspberryPi/RPi3 to drop its
> > dependency
> > > > on
> > > > >the framework packages;
> > > > > C. Update the commit log message for patch
> > > > >'Silicon/Hisilicon: Use ReportStatusCodeLib (DXE) in MdeModulePkg'
> > > > >to better reflect the commit impact.
> > > > >
> > > > >
> > > > > This series will drop the IntelFramework[Module]Pkg dependency for
> > > > > platforms within the edk2-platforms repo.
> > > > > packages.
> > > > >
> > > > > Tests done for the series:
> > > > > Platforms build verified with GCC5 toolchain:
> > > > > * Platform/AMD/OverdriveBoard
> > > > > * Platform/ARM/JunoPkg
> > > > > * Platform/ARM/SgiPkg
> > > > > * Platform/ARM/VExpressPkg
> > > > > * Platform/BeagleBoard
> > > > > * Platform/Hisilicon/D0x
> > > > > * Platform/Hisilicon/HiKey
> > > > > * Platform/Hisilicon/HiKey960
> > > > > * Platform/LeMaker/CelloBoard
> > > > > * Platform/Marvell/Armada70x0Db (only AARCH64)
> > > > > * Platform/Marvell/Armada80x0Db (only AARCH64)
> > > > > * Platform/RaspberryPi/RPi3
> > > > > * Platform/Socionext/DeveloperBox
> > > > > * Platform/Socionext/SynQuacerEvalBoard (only AARCH64)
> > > > > * Platform/SoftIron/Overdrive1000Board
> > > > > * Platform/SolidRun/Armada80x0McBin (only AARCH64)
> > > > >
> > > > > Platforms originally cannot be built via GCC5 toolchain (thus, not
> > > > > verified):
> > > > > * Platform/Comcast/RDKQemu (ARM, AARCH64)
> > > > > * Platform/Marvell/Armada70x0Db (ARM)
> > > > > * Platform/Marvell/Armada80x0Db (ARM)
> > > > > * Platform/Socionext/SynQuacerEvalBoard (ARM, AARCH64)
> > > > > * Platform/SolidRun/Armada80x0McBin (ARM)
> > > > >
> > > > > Cc: Ard Biesheuvel 
> > > > > Cc: Leif Lindholm 
> > > > > Cc: Michael D Kinney 
> > > > >
> > > > > Hao A Wu (18):
> > > > >   Platform/AMD: Use Lzma decompress lib in MdeModulePkg
> > > > >   Platform/BeagleBoard: Use ReportStatusCodeLib null instance
> > > > >   Platform/BeagleBoard: Drop the consume of PcdShellFile
> > > > >   Hisilicon/D0x: Use Lzma decompress lib in MdeModulePkg
> > > > >   Hisilicon/D0x: Drop the consume of GenericBdsLib & PlatformBdsLib
> > > > >   Hisilicon/D0x: Use StatusCode Router & Handler in MdeModulePkg
> > > > >   Hisilicon/D06: Drop the consume of PcdShellFile
> > > > >   Silicon/Hisilicon: Use Lzma decompress lib in MdeModulePkg
> > > > >   

Re: [edk2-devel] [PATCH 1/2] BaseTools: add centralized location for git config files

[Leif Lindholm]

Right, I tend to think of configuration files as
not-really-copyrightable.

Would you like me to send a v2, or would you be OK with me adding
#
# Copyright (c) 2019, Linaro Ltd. All rights reserved.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
to both files and pushing the series?

Regards

Leif

On Tue, Jun 11, 2019 at 05:25:58AM +, Feng, Bob C wrote:
> Hi Leif,
> 
> These 2 new file have no license header, need to add?
> 
> Thanks,
> Bob
> 
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
> Sent: Monday, June 10, 2019 7:54 PM
> To: devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming ; 
> Zhu, Yonghong ; Andrew Fish ; Laszlo 
> Ersek ; Kinney, Michael D 
> Subject: [PATCH 1/2] BaseTools: add centralized location for git config files
> 
> Before adding the git environment initialization script, add the following 
> files that will be pointed to after running said script:
> 
> - BaseTools/Conf/diff.order
> - BaseTools/Conf/gitattributes
> 
> Signed-off-by: Leif Lindholm 
> Reviewed-by: Laszlo Ersek 
> ---
>  BaseTools/Conf/diff.order|  8 
>  BaseTools/Conf/gitattributes | 14 ++
>  2 files changed, 22 insertions(+)
>  create mode 100644 BaseTools/Conf/diff.order  create mode 100644 
> BaseTools/Conf/gitattributes
> 
> diff --git a/BaseTools/Conf/diff.order b/BaseTools/Conf/diff.order new file 
> mode 100644 index 00..1d578ac28c
> --- /dev/null
> +++ b/BaseTools/Conf/diff.order
> @@ -0,0 +1,8 @@
> +*.dec
> +*.dsc.inc
> +*.dsc
> +*.fdf
> +*.inf
> +*.h
> +*.vfr
> +*.c
> diff --git a/BaseTools/Conf/gitattributes b/BaseTools/Conf/gitattributes new 
> file mode 100644 index 00..a8f923fd8a
> --- /dev/null
> +++ b/BaseTools/Conf/gitattributes
> @@ -0,0 +1,14 @@
> +*.efi -diff
> +*.EFI -diff
> +*.bin -diff
> +*.BIN -diff
> +*.raw -diff
> +*.RAW -diff
> +*.bmp -diff
> +*.BMP -diff
> +*.dec diff=ini
> +*.dsc diff=ini
> +*.dsc.inc diff=ini
> +*.fdf diff=ini
> +*.fdf.inc diff=ini
> +*.inf diff=ini
> --
> 2.11.0
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42196): https://edk2.groups.io/g/devel/message/42196
Mute This Topic: https://groups.io/mt/32003228/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 6/7] EmbeddedPkg: Fix DwEmmc SendCommand polling

[Loh, Tien Hock]

> -Original Message-
> From: Leif Lindholm 
> Sent: Tuesday, June 11, 2019 5:09 PM
> To: Loh, Tien Hock 
> Cc: 'Haojian Zhuang' ; 'devel@edk2.groups.io'
> ; 'thlo...@gmail.com' ; 'Ard
> Biesheuvel' 
> Subject: Re: [PATCH v2 6/7] EmbeddedPkg: Fix DwEmmc SendCommand
> polling
> 
> On Tue, Jun 11, 2019 at 02:40:51AM +, Loh, Tien Hock wrote:
> > Leif,
> >
> > Since Haojian have a newer driver model that uses the
> > NonDiscoverableDeviceDxe, I believe we should be moving to use the new
> > driver.
> >
> > I'll try to test out the patches submitted by Haojian in the mean time.
> > Can you help review the patch? Thanks!
> 
> I can have another look at the patch, but I would really appreciate if you
> could also review it please?
> 
> My problem is that I really don't have much understanding of SD/MMC
> protocols.

Sure. I'll test it out on the SoCFPGA platform first. It is quite a long patch, 
so I might take a bit of time to review.
Thanks Leif!

> 
> /
> Leif
> 
> > > -Original Message-
> > > From: Loh, Tien Hock
> > > Sent: Thursday, May 30, 2019 3:56 PM
> > > To: Haojian Zhuang ; Leif Lindholm
> > > 
> > > Cc: devel@edk2.groups.io; thlo...@gmail.com; Ard Biesheuvel
> > > 
> > > Subject: RE: [PATCH v2 6/7] EmbeddedPkg: Fix DwEmmc SendCommand
> > > polling
> > >
> > > > -Original Message-
> > > > From: Haojian Zhuang 
> > > > Sent: Thursday, May 30, 2019 3:06 PM
> > > > To: Leif Lindholm 
> > > > Cc: Loh, Tien Hock ;
> > > > devel@edk2.groups.io; thlo...@gmail.com; Ard Biesheuvel
> > > > 
> > > > Subject: Re: [PATCH v2 6/7] EmbeddedPkg: Fix DwEmmc SendCommand
> > > > polling
> > > >
> > > > On Tue, May 28, 2019 at 07:04:09PM +0100, Leif Lindholm wrote:
> > > > > +Haojian,
> > > > >
> > > > > Haojian - since you are the original author, can you comment on
> > > > > the delays? Are these silicon bug workarounds (so we need to add
> > > > > a Pcd), or does these changes work on your platforms too?
> > > >
> > > > I'm not in the loop, so I missed the patch series.
> > > >
> > > > The patch series can't work on my platform for the eMMC. Although
> > > > a variable is created to identify whether it's a SD or eMMC
> > > > device, it doesn't identify the eMMC device by the right way. So
> > > > the eMMC device isn't initialized successfully on my platform.
> > > >
> > > > 1. Since MMC framework could identify whether it's eMMC device or
> > > > SD device, we need to make device driver gets this kind of
> > > > information from the MMC framework. And we need to support
> > > > multiple eMMC/SD instances in MMC framework.
> > >
> > > Yeah my bad I didn't read through the SD/MMC specs on that. Now I
> > > check the specs and you're right, the information should be read
> > > from MMC framework.
> > >
> > > >
> > > > 2. I sent a patch series to support both eMMC device and SD device
> before.
> > > > https://edk2.groups.io/g/devel/message/28572
> > > > &&
> > > > https://edk2.groups.io/g/devel/message/28615
> > > > Maybe it's missed. Could you help to review that patch series?
> >
> > Leif, can you help review the patch series? Since Haojian have moved the
> driver to NonDiscoverableDeviceDxe, I think that would be a more
> appropriate driver to be used going forward. Thanks!
> >
> > >
> > > >
> > > > Best Regards
> > > > Haojian
> > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Leif
> > > > >
> > > > > On Mon, May 27, 2019 at 05:30:27PM +0800,
> > > > > tien.hock@intel.com
> > > > wrote:
> > > > > > From: "Tien Hock, Loh" 
> > > > > >
> > > > > > Change SendCommand polling mode to remove unnecessary delay,
> > > > > > and check for transfer done only when block data is to be
> read/write.
> > > > > > This would also increase performance slightly.
> > > > > >
> > > > > > Signed-off-by: "Tien Hock, Loh" 
> > > > > > Cc: Leif Lindholm 
> > > > > > Cc: Ard Biesheuvel 
> > > > > > ---
> > > > > >  EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c | 43
> > > > +++-
> > > > > >  1 file changed, 33 insertions(+), 10 deletions(-)
> > > > > >
> > > > > > diff --git a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
> > > > > > b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
> > > > > > index c6c8e04917..b57833458f 100644
> > > > > > --- a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
> > > > > > +++ b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
> > > > > > @@ -286,16 +286,13 @@ SendCommand (
> > > > > >  DWEMMC_INT_RCRC | DWEMMC_INT_RE;
> > > > > >ErrMask |= DWEMMC_INT_DCRC | DWEMMC_INT_DRT |
> > > > DWEMMC_INT_SBE;
> > > > > >do {
> > > > > > -MicroSecondDelay(500);
> > > > > >  Data = MmioRead32 (DWEMMC_RINTSTS);
> > > > > > -
> > > > > > -if (Data & ErrMask) {
> > > > > > -  return EFI_DEVICE_ERROR;
> > > > > > -}
> > > > > > -if (Data & DWEMMC_INT_DTO) { // Transfer Done
> > > > > > -  break;
> > > > > > -}
> > > > > >} while (!(Data & DWEMMC_INT_CMD_DONE));
> > > > > > +
> > > > > > +  if (Data & ErrMask) {
> > > > > > +return 

Re: [edk2-devel] [PATCH v2 6/7] EmbeddedPkg: Fix DwEmmc SendCommand polling

[Leif Lindholm]

On Tue, Jun 11, 2019 at 02:40:51AM +, Loh, Tien Hock wrote:
> Leif,
> 
> Since Haojian have a newer driver model that uses the
> NonDiscoverableDeviceDxe, I believe we should be moving to use the
> new driver.
>
> I'll try to test out the patches submitted by Haojian in the mean time. 
> Can you help review the patch? Thanks!

I can have another look at the patch, but I would really appreciate if
you could also review it please?

My problem is that I really don't have much understanding of SD/MMC
protocols.

/
Leif

> > -Original Message-
> > From: Loh, Tien Hock
> > Sent: Thursday, May 30, 2019 3:56 PM
> > To: Haojian Zhuang ; Leif Lindholm
> > 
> > Cc: devel@edk2.groups.io; thlo...@gmail.com; Ard Biesheuvel
> > 
> > Subject: RE: [PATCH v2 6/7] EmbeddedPkg: Fix DwEmmc SendCommand
> > polling
> > 
> > > -Original Message-
> > > From: Haojian Zhuang 
> > > Sent: Thursday, May 30, 2019 3:06 PM
> > > To: Leif Lindholm 
> > > Cc: Loh, Tien Hock ; devel@edk2.groups.io;
> > > thlo...@gmail.com; Ard Biesheuvel 
> > > Subject: Re: [PATCH v2 6/7] EmbeddedPkg: Fix DwEmmc SendCommand
> > > polling
> > >
> > > On Tue, May 28, 2019 at 07:04:09PM +0100, Leif Lindholm wrote:
> > > > +Haojian,
> > > >
> > > > Haojian - since you are the original author, can you comment on the
> > > > delays? Are these silicon bug workarounds (so we need to add a Pcd),
> > > > or does these changes work on your platforms too?
> > >
> > > I'm not in the loop, so I missed the patch series.
> > >
> > > The patch series can't work on my platform for the eMMC. Although a
> > > variable is created to identify whether it's a SD or eMMC device, it
> > > doesn't identify the eMMC device by the right way. So the eMMC device
> > > isn't initialized successfully on my platform.
> > >
> > > 1. Since MMC framework could identify whether it's eMMC device or SD
> > > device, we need to make device driver gets this kind of information
> > > from the MMC framework. And we need to support multiple eMMC/SD
> > > instances in MMC framework.
> > 
> > Yeah my bad I didn't read through the SD/MMC specs on that. Now I check
> > the specs and you're right, the information should be read from MMC
> > framework.
> > 
> > >
> > > 2. I sent a patch series to support both eMMC device and SD device before.
> > > https://edk2.groups.io/g/devel/message/28572
> > > &&
> > > https://edk2.groups.io/g/devel/message/28615
> > > Maybe it's missed. Could you help to review that patch series?
> 
> Leif, can you help review the patch series? Since Haojian have moved the 
> driver to NonDiscoverableDeviceDxe, I think that would be a more appropriate 
> driver to be used going forward. Thanks!
> 
> > 
> > >
> > > Best Regards
> > > Haojian
> > >
> > > >
> > > > Regards,
> > > >
> > > > Leif
> > > >
> > > > On Mon, May 27, 2019 at 05:30:27PM +0800, tien.hock@intel.com
> > > wrote:
> > > > > From: "Tien Hock, Loh" 
> > > > >
> > > > > Change SendCommand polling mode to remove unnecessary delay, and
> > > > > check for transfer done only when block data is to be read/write.
> > > > > This would also increase performance slightly.
> > > > >
> > > > > Signed-off-by: "Tien Hock, Loh" 
> > > > > Cc: Leif Lindholm 
> > > > > Cc: Ard Biesheuvel 
> > > > > ---
> > > > >  EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c | 43
> > > +++-
> > > > >  1 file changed, 33 insertions(+), 10 deletions(-)
> > > > >
> > > > > diff --git a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
> > > > > b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
> > > > > index c6c8e04917..b57833458f 100644
> > > > > --- a/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
> > > > > +++ b/EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c
> > > > > @@ -286,16 +286,13 @@ SendCommand (
> > > > >  DWEMMC_INT_RCRC | DWEMMC_INT_RE;
> > > > >ErrMask |= DWEMMC_INT_DCRC | DWEMMC_INT_DRT |
> > > DWEMMC_INT_SBE;
> > > > >do {
> > > > > -MicroSecondDelay(500);
> > > > >  Data = MmioRead32 (DWEMMC_RINTSTS);
> > > > > -
> > > > > -if (Data & ErrMask) {
> > > > > -  return EFI_DEVICE_ERROR;
> > > > > -}
> > > > > -if (Data & DWEMMC_INT_DTO) { // Transfer Done
> > > > > -  break;
> > > > > -}
> > > > >} while (!(Data & DWEMMC_INT_CMD_DONE));
> > > > > +
> > > > > +  if (Data & ErrMask) {
> > > > > +return EFI_DEVICE_ERROR;
> > > > > +  }
> > > > > +
> > > > >return EFI_SUCCESS;
> > > > >  }
> > > > >
> > > > > @@ -550,8 +547,9 @@ DwEmmcReadBlockData (
> > > > >)
> > > > >  {
> > > > >EFI_STATUS  Status;
> > > > > -  UINT32  DescPages, CountPerPage, Count;
> > > > > +  UINT32  DescPages, CountPerPage, Count, ErrMask;
> > > > >EFI_TPL Tpl;
> > > > > +  UINTN Rintsts = 0;
> > > > >
> > > > >Tpl = gBS->RaiseTPL (TPL_NOTIFY);
> > > > >
> > > > > @@ -574,6 +572,18 @@ DwEmmcReadBlockData (
> > > > >  DEBUG ((DEBUG_ERROR, "Failed to read data,
> > > mDwEmmcCommand:%x, mDwEmmcArgument:%x, Status:%r\n",
> > mDwEmmcCommand,
> > > 

Re: [edk2-devel] [PATCH v1 1/1] DynamicTablesPkg: GTDT updates for ACPI 6.3

[Sami Mujawar]

Reviewed-by: Sami Mujawar 

-Original Message-
From: PierreGondois  
Sent: 06 June 2019 10:21 AM
To: devel@edk2.groups.io
Cc: Sami Mujawar ; Alexei Fedorov 
; Matteo Carlini ; Stephanie 
Hughes-Fitt ; Pierre Gondois 
; nd 
Subject: [PATCH v1 1/1] DynamicTablesPkg: GTDT updates for ACPI 6.3

From: Pierre Gondois 

The ACPI 6.3 specification adds support for describing
ARMv8.1 EL2 virtual timers. Update GTDTGenerator to extend this support.

Signed-off-by: Pierre Gondois 
---

The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/381_dynamicTables_gtdt_acpi6_3_update_v1

Notes:
v1:
- Add support for describing ARMv8.1 EL2 virtual timers and update
  GTDTGenerator to extend this support. [Pierre]

 DynamicTablesPkg/Include/ArmNameSpaceObjects.h   |  6 ++
 DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c | 69 
+++-
 2 files changed, 44 insertions(+), 31 deletions(-)

diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 
bf70dc76cea044b9a8e8eb529d2ddbf892bafd58..0b00c8669729138e910d1fa09870f12dbc2a02a6
 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -290,6 +290,12 @@ typedef struct CmArmGenericTimerInfo {
 
   /// The non-secure PL2 timer flags
   UINT32  NonSecurePL2TimerFlags;
+
+  /// GSIV for the virtual EL2 timer
+  UINT32 VirtualPL2TimerGSIV;
+
+  /// Flags for the virtual EL2 timer
+  UINT32 VirtualPL2TimerFlags;
 } CM_ARM_GENERIC_TIMER_INFO;
 
 /** A structure that describes the
diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
index 
8d9ddcf9244b9f8b795edf7a53dd8a071bb121bc..adc91c073efcac8e06997658b20096ae0b7d7b86
 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
+++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
@@ -5,7 +5,7 @@
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
   @par Reference(s):
-  - ACPI 6.2 Specification - Errata A, September 2017
+  - ACPI 6.3 Specification - January 2019
 
 **/
 
@@ -77,7 +77,7 @@ GET_OBJECT_LIST (
   Protocol Interface.
   @param [in]  Gtdt   Pointer to the GTDT Table.
   @param [in]  PlatformTimerCount Platform timer count.
-
+  @param [in]  AcpiTableRevision  Acpi Revision targeted by the platform.
   @retval EFI_SUCCESS   Success.
   @retval EFI_INVALID_PARAMETER A parameter is invalid.
   @retval EFI_NOT_FOUND The required object was not found.
@@ -90,8 +90,9 @@ EFI_STATUS
 EFIAPI
 AddGenericTimerInfo (
   IN  CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL * CONST 
CfgMgrProtocol,
-  INEFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE * CONST Gtdt,
-  IN  CONST UINT32   
PlatformTimerCount
+  INEFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE * CONST Gtdt,
+  IN  CONST UINT32   
PlatformTimerCount,
+  IN  CONST UINT32   
AcpiTableRevision
 )
 {
   EFI_STATUS   Status;
@@ -131,9 +132,14 @@ AddGenericTimerInfo (
 GenericTimerInfo->CounterReadBaseAddress;
   Gtdt->PlatformTimerCount = PlatformTimerCount;
   Gtdt->PlatformTimerOffset = (PlatformTimerCount == 0) ? 0 :
-sizeof (EFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE);
+sizeof (EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE);
 
-  return EFI_SUCCESS;
+  if (AcpiTableRevision > 
EFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE_REVISION) {
+Gtdt->VirtualPL2TimerGSIV = GenericTimerInfo->VirtualPL2TimerGSIV;
+Gtdt->VirtualPL2TimerFlags = 
+ GenericTimerInfo->VirtualPL2TimerFlags;
+  }
+
+  return Status;
 }
 
 /** Add the SBSA Generic Watchdog Timers to the GTDT table.
@@ -147,26 +153,26 @@ AddGenericTimerInfo (  STATIC  VOID  
AddGenericWatchdogList (
-  IN EFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE  * CONST Gtdt,
+  IN EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE  * CONST Gtdt,
   IN CONST UINT32  WatchdogOffset,
   IN CONST CM_ARM_GENERIC_WATCHDOG_INFO*   WatchdogInfoList,
   IN   UINT32  WatchdogCount
   )
 {
-  EFI_ACPI_6_2_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE  * Watchdog;
+  EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE  * Watchdog;
 
   ASSERT (Gtdt != NULL);
   ASSERT (WatchdogInfoList != NULL);
 
-  Watchdog = (EFI_ACPI_6_2_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE *)
+  Watchdog = (EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE *)
  ((UINT8*)Gtdt + WatchdogOffset);
 
   while (WatchdogCount-- != 0) {
 // Add watchdog entry
 DEBUG ((DEBUG_INFO, "GTDT: Watchdog = 0x%p\n", Watchdog));
-Watchdog->Type = EFI_ACPI_6_2_GTDT_SBSA_GENERIC_WATCHDOG;
+Watchdog->Type = 

Re: [edk2-devel] [PATCH for-next] MdeModulePkg/PciBusDxe: catch unimplemented extended config space reads

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Wu, Hao A 
> Sent: Monday, June 10, 2019 3:04 PM
> To: devel@edk2.groups.io; ler...@redhat.com; Ni, Ray 
> Cc: Alex Williamson ; Wang, Jian J
> ; Ard Biesheuvel ; Zeng,
> Star 
> Subject: RE: [edk2-devel] [PATCH for-next] MdeModulePkg/PciBusDxe:
> catch unimplemented extended config space reads
> 
> Hello Ray,
> 
> Do you have comments on this patch?
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Laszlo Ersek
> > Sent: Wednesday, June 05, 2019 6:15 PM
> > To: Ard Biesheuvel; edk2-devel-groups-io
> > Cc: Alex Williamson; Wu, Hao A; Wang, Jian J; Ni, Ray; Zeng, Star
> > Subject: Re: [edk2-devel] [PATCH for-next] MdeModulePkg/PciBusDxe:
> > catch unimplemented extended config space reads
> >
> > On 06/05/19 11:25, Ard Biesheuvel wrote:
> > > On Tue, 4 Jun 2019 at 23:44, Laszlo Ersek  wrote:
> > >>
> > >> When assigning a physical PCIe device to a QEMU/KVM guest,
> > >> PciBusDxe
> > may
> > >> find that the extended config space is not (fully) implemented. In
> > >> LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read
> > >> as 0x_ at a given config space offset, after which the loop
> > >> gets stuck spinning on offset 0xFFC (the read at offset 0xFFC
> > >> returns 0x_ most likely as well).
> > >>
> > >> Another scenario (not related to virtualization) for triggering the
> > >> above is when a Conventional PCI bus -- exposed by a PCIe-to-PCI
> > >> bridge in the topology -- intervenes between a PCI Express Root
> > >> Port and a PCI Express Endpoint. The Conventional PCI bus limits
> > >> the accessible config space of the PCI Express Endpoint, even
> > >> though the endpoint advertizes the PCI Express capability. Here's a
> diagram, courtesy of Alex Williamson:
> > >>
> > >>   [PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
> > >>   ->|  |<- Conventional PCI bus
> > >>
> > >> Catch reads of 0x_ in LocatePciExpressCapabilityRegBlock(),
> > >> and break out of the scan with a warning message. The function will
> > >> return EFI_NOT_FOUND.
> > >>
> > >> Cc: Alex Williamson 
> > >> Cc: Hao A Wu 
> > >> Cc: Jian J Wang 
> > >> Cc: Ray Ni 
> > >> Cc: Star Zeng 
> > >> Signed-off-by: Laszlo Ersek 
> > >> ---
> > >>
> > >> Notes:
> > >> Repo:   https://github.com/lersek/edk2.git
> > >> Branch: pcibus_no_ext_conf
> > >>
> > >>  MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c | 13
> > +
> > >>  1 file changed, 13 insertions(+)
> > >>
> > >> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> > b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> > >> index 214aeecdd40a..6283d602207c 100644
> > >> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> > >> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
> > >> @@ -236,6 +236,19 @@ LocatePciExpressCapabilityRegBlock (
> > >>break;
> > >>  }
> > >>
> > >> +if (CapabilityEntry == MAX_UINT32) {
> > >
> > > Should we check here that the offset > 0x100 ? Otherwise, this
> > > affects more than just the extended config space.
> >
> > A separate function exists for locating caps in the conventional
> > config space (LocateCapabilityRegBlock()).
> >
> > Whereas the function being patched --
> > LocatePciExpressCapabilityRegBlock() -- is supposed to start with a
> > capability offset into the extended config space, passed in by the
> > caller via *Offset, or else at 0x100 if *Offset is 0.
> >
> > And, my understanding is that an extended cap shall never chain to a
> > conventional cap. The spec says,
> >
> > Next Capability Offset - This field contains the offset to the next
> > PCI Express Capability structure or 000h if no other items exist in
> > the linked list of Capabilities.
> >
> > For Extended Capabilities implemented in Configuration Space, this
> > offset is relative to the beginning of PCI compatible Configuration
> > Space and thus must always be either 000h (for terminating list of
> > Capabilities) or greater than 0FFh.
> >
> > The bottom 2 bits of this offset are Reserved and must be
> > implemented as 00b although software must mask them to allow for
> > future uses of these bits.
> >
> > Additionally, the capability header is different for conventional
> > capabilities: EFI_PCI_CAPABILITY_HDR -- 2 bytes -- vs.
> > PCI_EXPRESS_EXTENDED_CAPABILITIES_HEADER -- 4 bytes. So if this loop
> > ever crossed over into normal config space, it would break horribly,
> > regardless of this patch.
> >
> > A more general question would be how much we should armor such
> > functions
> > -- i.e., capability list scanning -- with sanity checks.
> >
> > My answer to that was authoring PciCapLib, which detects loops in cap
> > lists, oversized capability reads/writes, an absent extended config
> > space in spite of a present express capability; maybe more. Basically
> > everything I could think of and/or had 

Re: [edk2-devel] [PATCH v1 0/2] DynamicTablesPkg: Fix line endings and disable deprecated APIs

[Alexei Fedorov]

Reviewed-by: Alexei Fedorov alexei.fedo...@arm.com

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42191): https://edk2.groups.io/g/devel/message/42191
Mute This Topic: https://groups.io/mt/30918515/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform patch 0/2] Import IntelSiliconPkg from edk2 repo master

[Chaganty, Rangasai V]

Reviewed-by: Sai Chaganty  

-Original Message-
From: Gao, Liming 
Sent: Monday, June 10, 2019 8:36 AM
To: devel@edk2.groups.io
Cc: Kinney, Michael D ; Ni, Ray ; 
Chaganty, Rangasai V 
Subject: [edk2-platform patch 0/2] Import IntelSiliconPkg from edk2 repo master

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1890
IntelSiliconPkg is moved into Silicon/Intel directory.

Cc: Michael D Kinney 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Signed-off-by: Liming Gao 

Liming Gao (2):
  Silicon/Intel: Import IntelSiliconPkg from edk2 repo master
  Maintainers.txt: Add Maintainers for new added IntelSiliconPkg

 .../MicrocodeFlashAccessLibNull.c  |   36 +
 .../Capsule/MicrocodeUpdateDxe/MicrocodeFmp.c  |  979 +++
 .../Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c   | 1326 
 .../Feature/VTd/IntelVTdDxe/BmDma.c|  538 
 .../Feature/VTd/IntelVTdDxe/DmaProtection.c|  683 ++
 .../Feature/VTd/IntelVTdDxe/DmarAcpiTable.c|  890 +
 .../Feature/VTd/IntelVTdDxe/IntelVTdDxe.c  |  400 ++
 .../Feature/VTd/IntelVTdDxe/PciInfo.c  |  373 ++
 .../Feature/VTd/IntelVTdDxe/TranslationTable.c | 1026 +++
 .../Feature/VTd/IntelVTdDxe/TranslationTableEx.c   |  152 +++
 .../Feature/VTd/IntelVTdDxe/VtdReg.c   |  561 +
 .../Feature/VTd/IntelVTdPmrPei/DmarTable.c |  578 +
 .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c   |  420 +++
 .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c|  810 
 .../Feature/VTd/IntelVTdPmrPei/VtdReg.c|  287 +
 .../PlatformVTdInfoSamplePei.c |  361 ++
 .../PlatformVTdSampleDxe/PlatformVTdSampleDxe.c|  407 ++
 .../DxeSmbiosDataHobLib/DxeSmbiosDataHobLib.c  |   81 ++
 Maintainers.txt|4 +
 .../MicrocodeFlashAccessLibNull.inf|   34 +
 .../MicrocodeFlashAccessLibNull.uni|   16 +
 .../MicrocodeCapsulePdb/MicrocodeCapsulePdb.dsc|   27 +
 .../MicrocodeCapsulePdb/MicrocodeCapsulePdb.fdf|   26 +
 .../Feature/Capsule/MicrocodeCapsulePdb/Readme.md  |   20 +
 .../MicrocodeCapsuleTxt/Microcode/Microcode.inf|   21 +
 .../MicrocodeCapsuleTxt/MicrocodeCapsuleTxt.dsc|   33 +
 .../MicrocodeCapsuleTxt/MicrocodeCapsuleTxt.fdf|   26 +
 .../Feature/Capsule/MicrocodeCapsuleTxt/Readme.md  |   33 +
 .../Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.h   |  499 
 .../MicrocodeUpdateDxe/MicrocodeUpdateDxe.inf  |   67 +
 .../MicrocodeUpdateDxe/MicrocodeUpdateDxe.uni  |   15 +
 .../MicrocodeUpdateDxe/MicrocodeUpdateDxeExtra.uni |   14 +
 .../Feature/VTd/IntelVTdDxe/DmaProtection.h|  632 ++
 .../Feature/VTd/IntelVTdDxe/IntelVTdDxe.inf|   83 ++
 .../Feature/VTd/IntelVTdDxe/IntelVTdDxe.uni|   14 +
 .../Feature/VTd/IntelVTdDxe/IntelVTdDxeExtra.uni   |   14 +
 .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.h|  159 +++
 .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf  |   60 +
 .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.uni  |   14 +
 .../VTd/IntelVTdPmrPei/IntelVTdPmrPeiExtra.uni |   14 +
 .../PlatformVTdInfoSamplePei.inf   |   48 +
 .../PlatformVTdInfoSamplePei.uni   |   14 +
 .../PlatformVTdInfoSamplePeiExtra.uni  |   14 +
 .../PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf  |   56 +
 .../PlatformVTdSampleDxe/PlatformVTdSampleDxe.uni  |   14 +
 .../PlatformVTdSampleDxeExtra.uni  |   14 +
 .../IntelSiliconPkg/Include/Guid/MicrocodeFmp.h|   15 +
 .../IndustryStandard/FirmwareInterfaceTable.h  |   69 +
 .../Include/IndustryStandard/FirmwareVersionInfo.h |   54 +
 .../Include/IndustryStandard/IgdOpRegion.h |  149 +++
 .../IntelSiliconPkg/Include/IndustryStandard/Vtd.h |  355 ++
 .../Include/Library/MicrocodeFlashAccessLib.h  |   33 +
 .../Intel/IntelSiliconPkg/Include/Ppi/VtdInfo.h|   37 +
 .../Include/Protocol/PlatformVtdPolicy.h   |  143 +++
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec  |   80 ++
 Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc  |   86 ++
 .../DxeSmbiosDataHobLib/DxeSmbiosDataHobLib.inf|   38 +
 57 files changed, 12952 insertions(+)
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/Capsule/Library/MicrocodeFlashAccessLibNull/MicrocodeFlashAccessLibNull.c
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeFmp.c
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/BmDma.c
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmarAcpiTable.c
 create mode 100644 
Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/IntelVTdDxe.c
 create 

Re: [edk2-devel] [PATCH v1 1/1] DynamicTablesPkg: GTDT updates for ACPI 6.3

[Alexei Fedorov]

Reviewed-by: Alexei Fedorov 


Alexei


From: PierreGondois 
Sent: 06 June 2019 10:20
To: devel@edk2.groups.io
Cc: Sami Mujawar; Alexei Fedorov; Matteo Carlini; Stephanie Hughes-Fitt; Pierre 
Gondois; nd
Subject: [PATCH v1 1/1] DynamicTablesPkg: GTDT updates for ACPI 6.3

From: Pierre Gondois 

The ACPI 6.3 specification adds support for describing
ARMv8.1 EL2 virtual timers. Update GTDTGenerator
to extend this support.

Signed-off-by: Pierre Gondois 
---

The changes can be seen at: 
https://github.com/PierreARM/edk2/tree/381_dynamicTables_gtdt_acpi6_3_update_v1

Notes:
v1:
- Add support for describing ARMv8.1 EL2 virtual timers and update
  GTDTGenerator to extend this support. [Pierre]

 DynamicTablesPkg/Include/ArmNameSpaceObjects.h   |  6 ++
 DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c | 69 
+++-
 2 files changed, 44 insertions(+), 31 deletions(-)

diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 
bf70dc76cea044b9a8e8eb529d2ddbf892bafd58..0b00c8669729138e910d1fa09870f12dbc2a02a6
 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -290,6 +290,12 @@ typedef struct CmArmGenericTimerInfo {

   /// The non-secure PL2 timer flags
   UINT32  NonSecurePL2TimerFlags;
+
+  /// GSIV for the virtual EL2 timer
+  UINT32 VirtualPL2TimerGSIV;
+
+  /// Flags for the virtual EL2 timer
+  UINT32 VirtualPL2TimerFlags;
 } CM_ARM_GENERIC_TIMER_INFO;

 /** A structure that describes the
diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
index 
8d9ddcf9244b9f8b795edf7a53dd8a071bb121bc..adc91c073efcac8e06997658b20096ae0b7d7b86
 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
+++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
@@ -5,7 +5,7 @@
   SPDX-License-Identifier: BSD-2-Clause-Patent

   @par Reference(s):
-  - ACPI 6.2 Specification - Errata A, September 2017
+  - ACPI 6.3 Specification - January 2019

 **/

@@ -77,7 +77,7 @@ GET_OBJECT_LIST (
   Protocol Interface.
   @param [in]  Gtdt   Pointer to the GTDT Table.
   @param [in]  PlatformTimerCount Platform timer count.
-
+  @param [in]  AcpiTableRevision  Acpi Revision targeted by the platform.
   @retval EFI_SUCCESS   Success.
   @retval EFI_INVALID_PARAMETER A parameter is invalid.
   @retval EFI_NOT_FOUND The required object was not found.
@@ -90,8 +90,9 @@ EFI_STATUS
 EFIAPI
 AddGenericTimerInfo (
   IN  CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL * CONST 
CfgMgrProtocol,
-  INEFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE * CONST Gtdt,
-  IN  CONST UINT32   
PlatformTimerCount
+  INEFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE * CONST Gtdt,
+  IN  CONST UINT32   
PlatformTimerCount,
+  IN  CONST UINT32   
AcpiTableRevision
 )
 {
   EFI_STATUS   Status;
@@ -131,9 +132,14 @@ AddGenericTimerInfo (
 GenericTimerInfo->CounterReadBaseAddress;
   Gtdt->PlatformTimerCount = PlatformTimerCount;
   Gtdt->PlatformTimerOffset = (PlatformTimerCount == 0) ? 0 :
-sizeof (EFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE);
+sizeof (EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE);

-  return EFI_SUCCESS;
+  if (AcpiTableRevision > 
EFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE_REVISION) {
+Gtdt->VirtualPL2TimerGSIV = GenericTimerInfo->VirtualPL2TimerGSIV;
+Gtdt->VirtualPL2TimerFlags = GenericTimerInfo->VirtualPL2TimerFlags;
+  }
+
+  return Status;
 }

 /** Add the SBSA Generic Watchdog Timers to the GTDT table.
@@ -147,26 +153,26 @@ AddGenericTimerInfo (
 STATIC
 VOID
 AddGenericWatchdogList (
-  IN EFI_ACPI_6_2_GENERIC_TIMER_DESCRIPTION_TABLE  * CONST Gtdt,
+  IN EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE  * CONST Gtdt,
   IN CONST UINT32  WatchdogOffset,
   IN CONST CM_ARM_GENERIC_WATCHDOG_INFO*   WatchdogInfoList,
   IN   UINT32  WatchdogCount
   )
 {
-  EFI_ACPI_6_2_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE  * Watchdog;
+  EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE  * Watchdog;

   ASSERT (Gtdt != NULL);
   ASSERT (WatchdogInfoList != NULL);

-  Watchdog = (EFI_ACPI_6_2_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE *)
+  Watchdog = (EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE *)
  ((UINT8*)Gtdt + WatchdogOffset);

   while (WatchdogCount-- != 0) {
 // Add watchdog entry
 DEBUG ((DEBUG_INFO, "GTDT: Watchdog = 0x%p\n", Watchdog));
-Watchdog->Type = EFI_ACPI_6_2_GTDT_SBSA_GENERIC_WATCHDOG;
+Watchdog->Type = EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG;
 

Re: [edk2-devel] [edk2-platform patch 0/2] Import IntelSiliconPkg from edk2 repo master

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Gao, Liming 
> Sent: Monday, June 10, 2019 11:36 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Ni, Ray
> ; Chaganty, Rangasai V 
> Subject: [edk2-platform patch 0/2] Import IntelSiliconPkg from edk2 repo
> master
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1890
> IntelSiliconPkg is moved into Silicon/Intel directory.
> 
> Cc: Michael D Kinney 
> Cc: Ray Ni 
> Cc: Rangasai V Chaganty 
> Signed-off-by: Liming Gao 
> 
> Liming Gao (2):
>   Silicon/Intel: Import IntelSiliconPkg from edk2 repo master
>   Maintainers.txt: Add Maintainers for new added IntelSiliconPkg
> 
>  .../MicrocodeFlashAccessLibNull.c  |   36 +
>  .../Capsule/MicrocodeUpdateDxe/MicrocodeFmp.c  |  979
> +++
>  .../Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c   | 1326
> 
>  .../Feature/VTd/IntelVTdDxe/BmDma.c|  538 
>  .../Feature/VTd/IntelVTdDxe/DmaProtection.c|  683 ++
>  .../Feature/VTd/IntelVTdDxe/DmarAcpiTable.c|  890 +
>  .../Feature/VTd/IntelVTdDxe/IntelVTdDxe.c  |  400 ++
>  .../Feature/VTd/IntelVTdDxe/PciInfo.c  |  373 ++
>  .../Feature/VTd/IntelVTdDxe/TranslationTable.c | 1026
> +++
>  .../Feature/VTd/IntelVTdDxe/TranslationTableEx.c   |  152 +++
>  .../Feature/VTd/IntelVTdDxe/VtdReg.c   |  561 +
>  .../Feature/VTd/IntelVTdPmrPei/DmarTable.c |  578 +
>  .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmr.c   |  420 +++
>  .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.c|  810 
>  .../Feature/VTd/IntelVTdPmrPei/VtdReg.c|  287 +
>  .../PlatformVTdInfoSamplePei.c |  361 ++
>  .../PlatformVTdSampleDxe/PlatformVTdSampleDxe.c|  407 ++
>  .../DxeSmbiosDataHobLib/DxeSmbiosDataHobLib.c  |   81 ++
>  Maintainers.txt|4 +
>  .../MicrocodeFlashAccessLibNull.inf|   34 +
>  .../MicrocodeFlashAccessLibNull.uni|   16 +
>  .../MicrocodeCapsulePdb/MicrocodeCapsulePdb.dsc|   27 +
>  .../MicrocodeCapsulePdb/MicrocodeCapsulePdb.fdf|   26 +
>  .../Feature/Capsule/MicrocodeCapsulePdb/Readme.md  |   20 +
>  .../MicrocodeCapsuleTxt/Microcode/Microcode.inf|   21 +
>  .../MicrocodeCapsuleTxt/MicrocodeCapsuleTxt.dsc|   33 +
>  .../MicrocodeCapsuleTxt/MicrocodeCapsuleTxt.fdf|   26 +
>  .../Feature/Capsule/MicrocodeCapsuleTxt/Readme.md  |   33 +
>  .../Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.h   |  499 
>  .../MicrocodeUpdateDxe/MicrocodeUpdateDxe.inf  |   67 +
>  .../MicrocodeUpdateDxe/MicrocodeUpdateDxe.uni  |   15 +
>  .../MicrocodeUpdateDxe/MicrocodeUpdateDxeExtra.uni |   14 +
>  .../Feature/VTd/IntelVTdDxe/DmaProtection.h|  632 ++
>  .../Feature/VTd/IntelVTdDxe/IntelVTdDxe.inf|   83 ++
>  .../Feature/VTd/IntelVTdDxe/IntelVTdDxe.uni|   14 +
>  .../Feature/VTd/IntelVTdDxe/IntelVTdDxeExtra.uni   |   14 +
>  .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.h|  159 +++
>  .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf  |   60 +
>  .../Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.uni  |   14 +
>  .../VTd/IntelVTdPmrPei/IntelVTdPmrPeiExtra.uni |   14 +
>  .../PlatformVTdInfoSamplePei.inf   |   48 +
>  .../PlatformVTdInfoSamplePei.uni   |   14 +
>  .../PlatformVTdInfoSamplePeiExtra.uni  |   14 +
>  .../PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf  |   56 +
>  .../PlatformVTdSampleDxe/PlatformVTdSampleDxe.uni  |   14 +
>  .../PlatformVTdSampleDxeExtra.uni  |   14 +
>  .../IntelSiliconPkg/Include/Guid/MicrocodeFmp.h|   15 +
>  .../IndustryStandard/FirmwareInterfaceTable.h  |   69 +
>  .../Include/IndustryStandard/FirmwareVersionInfo.h |   54 +
>  .../Include/IndustryStandard/IgdOpRegion.h |  149 +++
>  .../IntelSiliconPkg/Include/IndustryStandard/Vtd.h |  355 ++
>  .../Include/Library/MicrocodeFlashAccessLib.h  |   33 +
>  .../Intel/IntelSiliconPkg/Include/Ppi/VtdInfo.h|   37 +
>  .../Include/Protocol/PlatformVtdPolicy.h   |  143 +++
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec  |   80 ++
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc  |   86 ++
>  .../DxeSmbiosDataHobLib/DxeSmbiosDataHobLib.inf|   38 +
>  57 files changed, 12952 insertions(+)
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/Capsule/Library/MicrocodeFlashAccessL
> ibNull/MicrocodeFlashAccessLibNull.c
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/Microco
> deFmp.c
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/Microco
> deUpdate.c
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/BmDma.c
>  create mode 100644
> Silicon/Intel/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c
>  

Re: [edk2-devel] [PATCH v1 1/1] DynamicTablesPkg: Add dynamic PPTT table generation support

[Sami Mujawar]

Pushed as 8349b8683640..77db115601fb

-Original Message-
From: Sami Mujawar 
Sent: 11 June 2019 09:12 AM
To: devel@edk2.groups.io
Cc: nd 
Subject: RE: [PATCH v1 1/1] DynamicTablesPkg: Add dynamic PPTT table generation 
support

Reviewed-by: Sami Mujawar 

-Original Message-
From: Krzysztof Koch  
Sent: 24 May 2019 01:07 PM
To: devel@edk2.groups.io
Cc: leif.lindh...@linaro.org; Sami Mujawar ; Alexei 
Fedorov ; Matteo Carlini ; 
Stephanie Hughes-Fitt ; nd 
Subject: [PATCH v1 1/1] DynamicTablesPkg: Add dynamic PPTT table generation 
support

The PPTT generator uses the configuration manager protocol to
obtain information about platform's processor topology and caches.
This data is then used to generate the PPTT table.

The table generator supports ACPI 6.3, PPTT table revision 2.

The dynamic PPTT generator also carries out extensive input
validation which includes cycle detection and MADT-PPTT
cross-validation. A number of architectural compliance checks
are also performed.

Signed-off-by: Krzysztof Koch 
---

The changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/392_pptt_generator_v1

This patch is dependent on: 
https://github.com/KrzysztofKoch1/edk2/tree/479_find_duplicate_ids_v1

Notes:
v1:
- Add PPTT dynamic generator [Krzysztof]

 DynamicTablesPkg/DynamicTables.dsc.inc  |3 +-
 DynamicTablesPkg/Include/AcpiTableGenerator.h   |3 +
 DynamicTablesPkg/Include/ArmNameSpaceObjects.h  |   95 ++
 DynamicTablesPkg/Include/ConfigurationManagerObject.h   |   22 +-
 DynamicTablesPkg/Include/Library/TableHelperLib.h   |   48 +
 DynamicTablesPkg/Include/TableGenerator.h   |3 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/AcpiPpttLibArm.inf |   29 +
 DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/PpttGenerator.c| 1528 

 DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/PpttGenerator.h|  190 +++
 DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c|   64 +
 10 files changed, 1979 insertions(+), 6 deletions(-)

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
b/DynamicTablesPkg/DynamicTables.dsc.inc
index 
8ea5b0a7d917fa2197e7c6da74afa0cbeb4c7a8d..142832b9fa9c2cd4b73935abf4114c3fa7b26d95
 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -1,7 +1,7 @@
 ## @file
 #  Dsc include file for Dynamic Tables Framework.
 #
-#  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+#  Copyright (c) 2017 - 2019, ARM Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -27,6 +27,7 @@ [Components.common]
   NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/AcpiIortLibArm.inf
   NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/AcpiMadtLibArm.inf
   NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/AcpiMcfgLibArm.inf
+  NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/AcpiPpttLibArm.inf
   NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiRawLibArm/AcpiRawLibArm.inf
   NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/AcpiSpcrLibArm.inf
   }
diff --git a/DynamicTablesPkg/Include/AcpiTableGenerator.h 
b/DynamicTablesPkg/Include/AcpiTableGenerator.h
index 
c4ef05965fc02707307e59130e9caa359e66239b..7d6d3442276db7b4abaeb3b053ba489258adea0b
 100644
--- a/DynamicTablesPkg/Include/AcpiTableGenerator.h
+++ b/DynamicTablesPkg/Include/AcpiTableGenerator.h
@@ -51,6 +51,8 @@ The Dynamic Tables Framework implements the following ACPI 
table generators:
 from the Configuration Manager and builds the MCFG table.
   - IORT  : The IORT generator collates the IO Topology information from the
 Configuration Manager and builds the IORT table.
+  - PPTT  : The PPTT generator collates the processor topology information from
+the Configuration Manager and builds the PPTT table.
 */
 
 /** The ACPI_TABLE_GENERATOR_ID type describes ACPI table generator ID.
@@ -72,6 +74,7 @@ typedef enum StdAcpiTableId {
   EStdAcpiTableIdSpcr,  ///< SPCR Generator
   EStdAcpiTableIdMcfg,  ///< MCFG Generator
   EStdAcpiTableIdIort,  ///< IORT Generator
+  EStdAcpiTableIdPptt,  ///< PPTT Generator
   EStdAcpiTableIdMax
 } ESTD_ACPI_TABLE_ID;
 
diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 
bf70dc76cea044b9a8e8eb529d2ddbf892bafd58..6d6fdac5195021392a5310c32c1cacde44390c58
 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -48,6 +48,10 @@ typedef enum ArmObjectID {
   EArmObjGicItsIdentifierArray,   ///< 24 - GIC ITS Identifier Array
   EArmObjIdMappingArray,  ///< 25 - ID Mapping Array
   EArmObjSmmuInterruptArray,  ///< 26 - SMMU 

Re: [edk2-devel] [PATCH v1 1/1] DynamicTablesPkg: Add dynamic PPTT table generation support

[Sami Mujawar]

Reviewed-by: Sami Mujawar 

-Original Message-
From: Krzysztof Koch  
Sent: 24 May 2019 01:07 PM
To: devel@edk2.groups.io
Cc: leif.lindh...@linaro.org; Sami Mujawar ; Alexei 
Fedorov ; Matteo Carlini ; 
Stephanie Hughes-Fitt ; nd 
Subject: [PATCH v1 1/1] DynamicTablesPkg: Add dynamic PPTT table generation 
support

The PPTT generator uses the configuration manager protocol to
obtain information about platform's processor topology and caches.
This data is then used to generate the PPTT table.

The table generator supports ACPI 6.3, PPTT table revision 2.

The dynamic PPTT generator also carries out extensive input
validation which includes cycle detection and MADT-PPTT
cross-validation. A number of architectural compliance checks
are also performed.

Signed-off-by: Krzysztof Koch 
---

The changes can be seen at: 
https://github.com/KrzysztofKoch1/edk2/tree/392_pptt_generator_v1

This patch is dependent on: 
https://github.com/KrzysztofKoch1/edk2/tree/479_find_duplicate_ids_v1

Notes:
v1:
- Add PPTT dynamic generator [Krzysztof]

 DynamicTablesPkg/DynamicTables.dsc.inc  |3 +-
 DynamicTablesPkg/Include/AcpiTableGenerator.h   |3 +
 DynamicTablesPkg/Include/ArmNameSpaceObjects.h  |   95 ++
 DynamicTablesPkg/Include/ConfigurationManagerObject.h   |   22 +-
 DynamicTablesPkg/Include/Library/TableHelperLib.h   |   48 +
 DynamicTablesPkg/Include/TableGenerator.h   |3 +-
 DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/AcpiPpttLibArm.inf |   29 +
 DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/PpttGenerator.c| 1528 

 DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/PpttGenerator.h|  190 +++
 DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c|   64 +
 10 files changed, 1979 insertions(+), 6 deletions(-)

diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
b/DynamicTablesPkg/DynamicTables.dsc.inc
index 
8ea5b0a7d917fa2197e7c6da74afa0cbeb4c7a8d..142832b9fa9c2cd4b73935abf4114c3fa7b26d95
 100644
--- a/DynamicTablesPkg/DynamicTables.dsc.inc
+++ b/DynamicTablesPkg/DynamicTables.dsc.inc
@@ -1,7 +1,7 @@
 ## @file
 #  Dsc include file for Dynamic Tables Framework.
 #
-#  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
+#  Copyright (c) 2017 - 2019, ARM Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -27,6 +27,7 @@ [Components.common]
   NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/AcpiIortLibArm.inf
   NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/AcpiMadtLibArm.inf
   NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/AcpiMcfgLibArm.inf
+  NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/AcpiPpttLibArm.inf
   NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiRawLibArm/AcpiRawLibArm.inf
   NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/AcpiSpcrLibArm.inf
   }
diff --git a/DynamicTablesPkg/Include/AcpiTableGenerator.h 
b/DynamicTablesPkg/Include/AcpiTableGenerator.h
index 
c4ef05965fc02707307e59130e9caa359e66239b..7d6d3442276db7b4abaeb3b053ba489258adea0b
 100644
--- a/DynamicTablesPkg/Include/AcpiTableGenerator.h
+++ b/DynamicTablesPkg/Include/AcpiTableGenerator.h
@@ -51,6 +51,8 @@ The Dynamic Tables Framework implements the following ACPI 
table generators:
 from the Configuration Manager and builds the MCFG table.
   - IORT  : The IORT generator collates the IO Topology information from the
 Configuration Manager and builds the IORT table.
+  - PPTT  : The PPTT generator collates the processor topology information from
+the Configuration Manager and builds the PPTT table.
 */
 
 /** The ACPI_TABLE_GENERATOR_ID type describes ACPI table generator ID.
@@ -72,6 +74,7 @@ typedef enum StdAcpiTableId {
   EStdAcpiTableIdSpcr,  ///< SPCR Generator
   EStdAcpiTableIdMcfg,  ///< MCFG Generator
   EStdAcpiTableIdIort,  ///< IORT Generator
+  EStdAcpiTableIdPptt,  ///< PPTT Generator
   EStdAcpiTableIdMax
 } ESTD_ACPI_TABLE_ID;
 
diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
index 
bf70dc76cea044b9a8e8eb529d2ddbf892bafd58..6d6fdac5195021392a5310c32c1cacde44390c58
 100644
--- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
@@ -48,6 +48,10 @@ typedef enum ArmObjectID {
   EArmObjGicItsIdentifierArray,   ///< 24 - GIC ITS Identifier Array
   EArmObjIdMappingArray,  ///< 25 - ID Mapping Array
   EArmObjSmmuInterruptArray,  ///< 26 - SMMU Interrupt Array
+  EArmObjProcHierarchyInfo,   ///< 27 - Processor Hierarchy Info
+  EArmObjCacheInfo,   ///< 28 - Cache Info
+  EArmObjProcNodeIdInfo,  ///< 29 - Processor Hierarchy Node ID 
Info
+  

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Wu, Hao A]

> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Tuesday, June 11, 2019 4:01 PM
> To: Wu, Hao A; Justen, Jordan L; devel@edk2.groups.io
> Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> dependency
> 
> On Tue, 2019-06-11 at 07:49 +, Wu, Hao A wrote:
> > Hello all,
> >
> > For the series:
> > [PATCH v2 00/10] Duplicate required CSM components for OVMF
> > https://edk2.groups.io/g/devel/message/41385
> >
> > I sent it out on May 27th, and did not receive a confirmation from David
> > for about 2 weeks. I think maybe the CSM support on OVMF is no longer
> > cared, and thus I sent another series today to drop such support:
> > [PATCH v1 0/2] OVMF: Drop CSM support
> > https://edk2.groups.io/g/devel/message/42142
> >
> > Please help to provide some feedbacks/confirmation on what should I do
> for
> > the next step. (This task actually blocks our proposal to remove
> > IntelFramework[Module]Pkg from edk2.)
> 
> 
> Apologies for the delay. It wasn't clear that the first series was
> actually tested by booting with a CSM, and I was reluctant to ack it
> without knowing that it didn't cause a regression.

Agree, I understand that.

> 
> This is, of course, complicated by the fact that I can't actually get a
> CSM boot to complete at the moment. But it gets a long way into the
> boot process before something goes wrong, so confirmation that it still
> gets at least that far with your 'Duplicate required CSM components'
> series would be good.
> 
> Is there a git tree I can pull from? I seem to recall that last time I
> spent serious time working on OVMF, life was horribly complicated by
> CRLF line endings, and it was extremely painful to just apply patches
> from email... is that still the case?

Yes, you can get the first series at:
https://github.com/hwu25/edk2/commits/ovmf_csm_v2

Best Regards,
Hao Wu

> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42185): https://edk2.groups.io/g/devel/message/42185
Mute This Topic: https://groups.io/mt/32011839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch V3] EmulatorPkg: don't display the cpu current speed

[Jordan Justen]

On 2019-06-11 00:32:27, Zhiguang Liu wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1686
> 
> V3: I hope that changing the status of the mCpuSmbiosType4
> wouldn't affect other features except showing CPU speed.
> The value is zero in NT32Pkg.
> 
> Cc: Jordan Justen 
> Cc: Andrew Fish 
> Cc: Ray Ni 
> Signed-off-by: Zhiguang Liu 
> ---
>  EmulatorPkg/CpuRuntimeDxe/Cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/EmulatorPkg/CpuRuntimeDxe/Cpu.c b/EmulatorPkg/CpuRuntimeDxe/Cpu.c
> index 00e93016af..a5e19b4181 100644
> --- a/EmulatorPkg/CpuRuntimeDxe/Cpu.c
> +++ b/EmulatorPkg/CpuRuntimeDxe/Cpu.c
> @@ -104,7 +104,7 @@ SMBIOS_TABLE_TYPE4 mCpuSmbiosType4 = {
>0,  // ExternalClock;
>0,  // MaxSpeed;
>0,  // CurrentSpeed;
> -  0x41,   // Status;
> +  0,  // Status;

It looks like bit 6 means the process is populated, and bits[2:0]==1
means the CPU is enabled.

So, it looks like this change will make SMBIOS indicate the the
processor socket is not populated, and bit2[2:0]==0 means that the CPU
status is unknown.

I think the commit message for this patch should have been:

===

EmulatorPkg: Change SMBIOS processor to unpopulated

This change updates the SMBIOS processor information to indicate that
the processor is not populated, and that it's status is unknown.

With this change the processor speed will not be shown in setup.

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

===

But, I'm not sure I agree we should make this change to fix this bug.
I'm not particularly concerned with this bug, but I wonder if perhaps
the MdeModulePkg should just suppress the item if the speed is 0.

Or, alternately, perhaps we can investigate some methods to attempt to
determine the processor speed. I guess for all OS's, it might be
difficult, but we probably could support finding the processor speed
under the most common environments.

-Jordan

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42184): https://edk2.groups.io/g/devel/message/42184
Mute This Topic: https://groups.io/mt/32013654/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Wu, Hao A]

> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Tuesday, June 11, 2019 3:37 PM
> To: Justen, Jordan L; Wu, Hao A; devel@edk2.groups.io
> Cc: Ni, Ray; Laszlo Ersek; Ard Biesheuvel; Phillips, D Scott
> Subject: Re: [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg
> dependency
> 
> On Tue, 2019-06-11 at 00:35 -0700, Jordan Justen wrote:
> > I see that https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> > mentions that there is "missing of reviewer/maintainer of the CSM
> > modules in OvmfPkg", so it will be dropped. Yet, I thought David
> > agreed to maintain that support as recently as May 20:
> >
> > https://edk2.groups.io/g/devel/message/41049
> >
> > Maybe he changed his mind about it?
> 
> No, I'm happy to do it. Just been fairly busy recently.
> 
> There appears to be nothing actually on fire this week. I may actually
> get to spend some quality time making sure it works again.

Hello all,

For the series:
[PATCH v2 00/10] Duplicate required CSM components for OVMF
https://edk2.groups.io/g/devel/message/41385

I sent it out on May 27th, and did not receive a confirmation from David
for about 2 weeks. I think maybe the CSM support on OVMF is no longer
cared, and thus I sent another series today to drop such support: 
[PATCH v1 0/2] OVMF: Drop CSM support
https://edk2.groups.io/g/devel/message/42142

Please help to provide some feedbacks/confirmation on what should I do for
the next step. (This task actually blocks our proposal to remove
IntelFramework[Module]Pkg from edk2.)

Thanks in advance.

Best Regards,
Hao Wu


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42183): https://edk2.groups.io/g/devel/message/42183
Mute This Topic: https://groups.io/mt/32011839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Jordan Justen]

On 2019-06-10 18:43:07, Hao A Wu wrote:
> The series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_drop_framework_v2
> 
> V2 changes:
> 
> * Update to module OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf has been
>   dropped, since the module is proposed to be removed in another series:
>   https://edk2.groups.io/g/devel/message/42142

I see that https://bugzilla.tianocore.org/show_bug.cgi?id=1811
mentions that there is "missing of reviewer/maintainer of the CSM
modules in OvmfPkg", so it will be dropped. Yet, I thought David
agreed to maintain that support as recently as May 20:

https://edk2.groups.io/g/devel/message/41049

Maybe he changed his mind about it?

By the way, I know that Scott (Cc'd) was interested in leveraging CSM
support of OVMF for a fork that supports the BSD bhyve hypervisor.

-Jordan

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42182): https://edk2.groups.io/g/devel/message/42182
Mute This Topic: https://groups.io/mt/32011839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch V3] EmulatorPkg: don't display the cpu current speed

[Zhiguang Liu]

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

V3: I hope that changing the status of the mCpuSmbiosType4
wouldn't affect other features except showing CPU speed.
The value is zero in NT32Pkg.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Zhiguang Liu 
---
 EmulatorPkg/CpuRuntimeDxe/Cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/CpuRuntimeDxe/Cpu.c b/EmulatorPkg/CpuRuntimeDxe/Cpu.c
index 00e93016af..a5e19b4181 100644
--- a/EmulatorPkg/CpuRuntimeDxe/Cpu.c
+++ b/EmulatorPkg/CpuRuntimeDxe/Cpu.c
@@ -104,7 +104,7 @@ SMBIOS_TABLE_TYPE4 mCpuSmbiosType4 = {
   0,  // ExternalClock;
   0,  // MaxSpeed;
   0,  // CurrentSpeed;
-  0x41,   // Status;
+  0,  // Status;
   ProcessorUpgradeOther,  // ProcessorUpgrade;  ///< The enumeration value 
from PROCESSOR_UPGRADE.
   0,  // L1CacheHandle;
   0,  // L2CacheHandle;
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42181): https://edk2.groups.io/g/devel/message/42181
Mute This Topic: https://groups.io/mt/32013654/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel][Patch] IntelFspPkg: Remove them

[Ni, Ray]

Chasel, Nate,
Thanks. I will remove the two packages ASAP.

> -Original Message-
> From: Chiu, Chasel 
> Sent: Tuesday, June 11, 2019 3:19 PM
> To: Desimone, Nathaniel L ; Ni, Ray
> ; Zeng, Star 
> Cc: devel@edk2.groups.io
> Subject: RE: [edk2-devel][Patch] IntelFspPkg: Remove
> them
> 
> 
> Just committed this fix.
> https://edk2.groups.io/g/devel/topic/31860753#41659
> 
> Thanks!
> Chasel
> 
> 
> > -Original Message-
> > From: Desimone, Nathaniel L
> > Sent: Thursday, June 6, 2019 1:59 PM
> > To: Ni, Ray ; Chiu, Chasel ;
> > Zeng, Star 
> > Cc: devel@edk2.groups.io
> > Subject: RE: [edk2-devel][Patch] IntelFspPkg:
> > Remove them
> >
> > Please commit Chasel's fix for
> > https://edk2.groups.io/g/devel/topic/31860753#41659
> >
> > Once Chasel's fix is committed...
> >
> > Reviewed-by: Nate DeSimone 
> >
> > -Original Message-
> > From: Ni, Ray
> > Sent: Thursday, May 16, 2019 1:38 AM
> > To: Chiu, Chasel ; Desimone, Nathaniel L
> > ; Zeng, Star 
> > Cc: devel@edk2.groups.io
> > Subject: [edk2-devel][Patch] IntelFspPkg: Remove
> > them
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1819
> >
> > Since there are V2 FSP packages (IntelFsp2Pkg, IntelFsp2WrapperPkg),
> > this patch removes IntelFspPkg, IntelFspWrapperPkg to remove obsolete
> > code in edk2 repo.
> >
> > Signed-off-by: Ray Ni 
> > Cc: Chasel Chiu 
> > Cc: Nate DeSimone 
> > Cc: Star Zeng 
> > --
> > NOTE: This patch is to completely remove IntelFspPkg and
> > IntelFspWrapperPkg folder in edk2 repo.
> > I don't want to flood people's inbox with a big patch just removing
> > every line of code in this two packages.
> >
> > The patch that modifies Maintainers.txt will be sent out later after
> > IntelFspPkg and IntelFspWrapperPkg are removed.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42180): https://edk2.groups.io/g/devel/message/42180
Mute This Topic: https://groups.io/mt/31638674/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel][Patch] IntelFspPkg: Remove them

[Chiu, Chasel]

Just committed this fix.
https://edk2.groups.io/g/devel/topic/31860753#41659

Thanks!
Chasel


> -Original Message-
> From: Desimone, Nathaniel L
> Sent: Thursday, June 6, 2019 1:59 PM
> To: Ni, Ray ; Chiu, Chasel ; Zeng, 
> Star
> 
> Cc: devel@edk2.groups.io
> Subject: RE: [edk2-devel][Patch] IntelFspPkg: Remove
> them
> 
> Please commit Chasel's fix for
> https://edk2.groups.io/g/devel/topic/31860753#41659
> 
> Once Chasel's fix is committed...
> 
> Reviewed-by: Nate DeSimone 
> 
> -Original Message-
> From: Ni, Ray
> Sent: Thursday, May 16, 2019 1:38 AM
> To: Chiu, Chasel ; Desimone, Nathaniel L
> ; Zeng, Star 
> Cc: devel@edk2.groups.io
> Subject: [edk2-devel][Patch] IntelFspPkg: Remove them
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1819
> 
> Since there are V2 FSP packages (IntelFsp2Pkg, IntelFsp2WrapperPkg), this 
> patch
> removes IntelFspPkg, IntelFspWrapperPkg to remove obsolete code in edk2
> repo.
> 
> Signed-off-by: Ray Ni 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Star Zeng 
> --
> NOTE: This patch is to completely remove IntelFspPkg and IntelFspWrapperPkg
> folder in edk2 repo.
> I don't want to flood people's inbox with a big patch just removing every 
> line of
> code in this two packages.
> 
> The patch that modifies Maintainers.txt will be sent out later after 
> IntelFspPkg
> and IntelFspWrapperPkg are removed.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42179): https://edk2.groups.io/g/devel/message/42179
Mute This Topic: https://groups.io/mt/31638674/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/6] Ovmf: Drop IntelFramework[Module]Pkg dependency

[Ard Biesheuvel]

On Tue, 11 Jun 2019 at 03:43, Hao A Wu  wrote:
>
> The series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_drop_framework_v2
>
> V2 changes:
>
> * Update to module OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf has been
>   dropped, since the module is proposed to be removed in another series:
>   https://edk2.groups.io/g/devel/message/42142
>
> * Copy LegacyBios protocol definitions from IntelFrameworkPkg, since
>   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>   has a dependency on it. This was not done in V1 series since such copy
>   was previous covered by another series to duplicate the required CSM
>   modules into OvmfPkg. (Now this series has been dropped.)
>
>
> V1 history:
>
> The series will drop the IntelFramework[Module]Pkg dependency for below
> modules within OvmfPkg:
>
> OvmfPkg/PlatformPei/PlatformPei.inf
> OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
> OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
>
>
> Verification done for the series:
> * Build pass for OvmfPkg;
> * Boot to shell with the built images.
>
> Cc: Ray Ni 
> Cc: David Woodhouse 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
>
> Hao A Wu (6):
>   OvmfPkg/PlatformPei: Remove redundant reference of framework pkg DEC
>   OvmfPkg/OvmfPkg.dec: Add PcdShellFile in OVMF DEC file
>   OvmfPkg/PlatformBootManagerLib: Use PcdShellFile defined in OvmfPkg
>   OvmfPkg/DSC: Remove the consume of PcdShellFile in framework package
>   OvmfPkg: Copy LegacyBios protocol definitions from IntelFrameworkPkg
>   OvmfPkg/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependency
>

As before

Acked-by: Ard Biesheuvel 

but Laszlo needs to ack this as well.

>  OvmfPkg/OvmfPkg.dec  |   
>  4 +
>  OvmfPkg/OvmfPkgIa32.dsc  |   
>  2 -
>  OvmfPkg/OvmfPkgIa32X64.dsc   |   
>  2 -
>  OvmfPkg/OvmfPkgX64.dsc   |   
>  2 -
>  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf |   
>  1 -
>  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf|   
>  5 +-
>  OvmfPkg/PlatformPei/PlatformPei.inf  |   
>  3 +-
>  OvmfPkg/Include/Protocol/LegacyBios.h| 
> 1553 
>  8 files changed, 1560 insertions(+), 12 deletions(-)
>  create mode 100644 OvmfPkg/Include/Protocol/LegacyBios.h
>
> --
> 2.12.0.windows.1
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42178): https://edk2.groups.io/g/devel/message/42178
Mute This Topic: https://groups.io/mt/32011839/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/2] OVMF: Drop CSM support

[Ard Biesheuvel]

On Tue, 11 Jun 2019 at 03:30, Hao A Wu  wrote:
>
> The series is also available at:
> https://github.com/hwu25/edk2/tree/ovmf_drop_csm
>
> The series will drop the CSM support in OvmfPkg and delete the unused
> modules.
>
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
>
> Hao A Wu (2):
>   OvmfPkg: Remove 'CSM_ENABLE' flag & CSM modules in DSC/FDF files
>   OvmfPkg/Csm: Remove the components under this folder
>

For the series

Acked-by: Ard Biesheuvel 

but I will let Laszlo have the final word.

>  OvmfPkg/OvmfPkgIa32.dsc |   21 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc  |   21 +-
>  OvmfPkg/OvmfPkgX64.dsc  |   21 +-
>  OvmfPkg/OvmfPkgIa32.fdf |6 -
>  OvmfPkg/OvmfPkgIa32X64.fdf  |6 -
>  OvmfPkg/OvmfPkgX64.fdf  |6 -
>  OvmfPkg/Csm/Csm16/Csm16.inf |   17 -
>  OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf |   56 --
>  OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.h   |   49 -
>  OvmfPkg/Csm/CsmSupportLib/LegacyInterrupt.h |  117 ---
>  OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.h  |   98 --
>  OvmfPkg/Csm/CsmSupportLib/LegacyRegion.h|  203 
>  OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.c   |   32 -
>  OvmfPkg/Csm/CsmSupportLib/LegacyInterrupt.c |  214 
>  OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c  | 1060 
>  OvmfPkg/Csm/CsmSupportLib/LegacyRegion.c|  498 -
>  OvmfPkg/Csm/Csm16/ReadMe.txt|   12 -
>  17 files changed, 3 insertions(+), 2434 deletions(-)
>  delete mode 100644 OvmfPkg/Csm/Csm16/Csm16.inf
>  delete mode 100644 OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
>  delete mode 100644 OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.h
>  delete mode 100644 OvmfPkg/Csm/CsmSupportLib/LegacyInterrupt.h
>  delete mode 100644 OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.h
>  delete mode 100644 OvmfPkg/Csm/CsmSupportLib/LegacyRegion.h
>  delete mode 100644 OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.c
>  delete mode 100644 OvmfPkg/Csm/CsmSupportLib/LegacyInterrupt.c
>  delete mode 100644 OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c
>  delete mode 100644 OvmfPkg/Csm/CsmSupportLib/LegacyRegion.c
>  delete mode 100644 OvmfPkg/Csm/Csm16/ReadMe.txt
>
> --
> 2.12.0.windows.1
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42177): https://edk2.groups.io/g/devel/message/42177
Mute This Topic: https://groups.io/mt/32011732/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 1/1] BaseTools:Build cache cannot store the cache files for library package

[Steven Shi]

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

Current build cache cannot store the cache for library package.
build -p MdePkg\MdePkg.dsc -a IA32 -b DEBUG -t VS2015x86 --hash
--binary-destination=BinCache
After build, the expected result is the BinCache folder is generated
and the MdePkg build cache files (e.g. .hash and .lib) are stored in
the BinCache folder. But the BinCache folder is not generated at all.

This patch is going to fix that issue.

Cc: Liming Gao 
Cc: Bob Feng 
Cc: Zhiju.Fan 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py 
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 3f41fbb507..f59a8038d5 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -3569,8 +3569,11 @@ class ModuleAutoGen(AutoGen):
 if self.IsAsBuiltInfCreated:
 return
 
-# Skip the following code for libraries
+# Skip INF file generation for libraries
 if self.IsLibrary:
+# Only store the library cache if needed
+if GlobalData.gBinCacheDest:
+self.CopyModuleToCache()
 return
 
 # Skip the following code for modules with no source files
-- 
2.17.1.windows.2


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42176): https://edk2.groups.io/g/devel/message/42176
Mute This Topic: https://groups.io/mt/32013383/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 0/1] BaseTools:Build cache cannot store the cache files for library package

[Steven Shi]

V2:
As Bob suggestion to remove the "pass" in except block.
Enhance the comments as well

V1:
Initial fix from Zhiju 

Steven Shi (1):
  BaseTools:Build cache cannot store the cache files for library package

 BaseTools/Source/Python/AutoGen/AutoGen.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.17.1.windows.2


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42175): https://edk2.groups.io/g/devel/message/42175
Mute This Topic: https://groups.io/mt/32013382/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 1/1] BaseTools/Capsule: Tool to Generate Windows Firmware Update Driver

[Eric Jin]

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

The tool is designed to generate Windows Firmware Update Drivers, the
input is one drivername.cap with related parameters, the output Windows
Driver package are composed by drivername.cap, drivername.inf and
drivername.cat to update the single payload in device.

usage:
GenerateWindowsDriver [-h] [--output-folder OUTPUTFOLDER]
  [--product-fmp-guid PRODUCTFMPGUID]
  [--capsuleversion-dotstring CAPSULEVERSION_DOTSTRING]
  [--capsuleversion-hexstring CAPSULEVERSION_HEXSTRING]
  [--product-fw-provider PRODUCTFWPROVIDER]
  [--product-fw-mfg-name PRODUCTFWMFGNAME]
  [--product-fw-desc PRODUCTFWDESC]
  [--capsule-file-name CAPSULEFILENAME]
  [--pfx-file PFXFILE] [--arch ARCH]
  [--operating-system-string OPERATINGSYSTEMSTRING]

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Kinney Michael D 
Signed-off-by: Eric Jin 
---
 BaseTools/Source/Python/Capsule/CatGenerator.py| 159 
+++
 BaseTools/Source/Python/Capsule/GenerateWindowsDriver.py   | 114 
++
 BaseTools/Source/Python/Capsule/InfGenerator.py| 210 
++
 BaseTools/Source/Python/Capsule/WindowsCapsuleSupportHelper.py | 102 
++
 4 files changed, 585 insertions(+)

diff --git a/BaseTools/Source/Python/Capsule/CatGenerator.py 
b/BaseTools/Source/Python/Capsule/CatGenerator.py
new file mode 100644
index 00..5f7fefa788
--- /dev/null
+++ b/BaseTools/Source/Python/Capsule/CatGenerator.py
@@ -0,0 +1,159 @@
+## @file
+ # Script to generate Cat files for capsule update based on supplied inf file
+ #
+ # Copyright (c) 2019, Microsoft Corporation
+ # Copyright (c) 2019, Intel Corporation. All rights reserved.
+ # SPDX-License-Identifier: BSD-2-Clause-Patent
+ #
+ ##
+
+import os
+import logging
+import datetime
+import subprocess
+import threading
+
+class PropagatingThread(threading.Thread):
+def run(self):
+self.exc = None
+try:
+if hasattr(self, '_Thread__target'):
+# Thread uses name mangling prior to Python 3.
+self.ret = self._Thread__target(*self._Thread__args, 
**self._Thread__kwargs)
+else:
+self.ret = self._target(*self._args, **self._kwargs)
+except BaseException as e:
+self.exc = e
+def join(self, timeout=None):
+super(PropagatingThread, self).join()
+if self.exc:
+ raise self.exc
+return self.ret
+def reader(filepath, outstream, stream):
+if filepath:
+try:
+with open(filepath, "w") as f:
+print("The file is" + filepath)
+except FileNotFoundError:
+print("Sorry, the file" + filepath + "does not exist.")
+
+while True:
+s = stream.readline().decode()
+if not s:
+stream.close()
+break
+# write to file if caller provideds file
+if filepath:
+try:
+with open(filepath, "a") as f:
+f.write(s)
+except FileNotFoundError:
+print("Sorry, the file" + filepath + "does not exist.")
+if(outstream is not None):
+# write to stream object if caller provided object
+outstream.write(s)
+logging.info(s.rstrip())
+
+def RunCmd(cmd, parameters, capture=True, workingdir=None, outfile=None, 
outstream=None, environ=None):
+cmd = cmd.strip('"\'')
+if " " in cmd:
+cmd = '"' + cmd + '"'
+if parameters is not None:
+parameters = parameters.strip()
+cmd += " " + parameters
+starttime = datetime.datetime.now()
+logging.info("Cmd to run is: " + cmd)
+logging.info("")
+logging.info("--Cmd Output Starting---")
+logging.info("")
+c = subprocess.Popen(cmd, stdout=subprocess.PIPE, 
stderr=subprocess.STDOUT, cwd=workingdir, shell=True, env=environ)
+if(capture):
+outr = PropagatingThread(target=reader, args=(outfile, outstream, 
c.stdout,))
+outr.start()
+outr.join()
+c.wait()
+
+endtime = datetime.datetime.now()
+delta = endtime - starttime
+

[edk2-devel] [PATCH v3 0/1] BaseTools/Capsule: Tool to Generate Windows Firmware Update Driver

[Eric Jin]

V3 change:
Remove unnecessary else block
Remove f.close() from with open() block

V2 change:
Use "with" statement for the open() calls.
Remove trailing whitespace.

V1: Initial version to enable this tool

Eric Jin (1):
  BaseTools/Capsule: Tool to Generate Windows Firmware Update Driver

 BaseTools/Source/Python/Capsule/CatGenerator.py| 159 
+++
 BaseTools/Source/Python/Capsule/GenerateWindowsDriver.py   | 114 
++
 BaseTools/Source/Python/Capsule/InfGenerator.py| 210 
++
 BaseTools/Source/Python/Capsule/WindowsCapsuleSupportHelper.py | 102 
++
 4 files changed, 585 insertions(+)
 create mode 100644 BaseTools/Source/Python/Capsule/CatGenerator.py
 create mode 100644 BaseTools/Source/Python/Capsule/GenerateWindowsDriver.py
 create mode 100644 BaseTools/Source/Python/Capsule/InfGenerator.py
 create mode 100644 
BaseTools/Source/Python/Capsule/WindowsCapsuleSupportHelper.py

-- 
2.20.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42173): https://edk2.groups.io/g/devel/message/42173
Mute This Topic: https://groups.io/mt/3201/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop IntelFramework[Module]Pkg dependency

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Leif Lindholm
> Sent: Monday, June 10, 2019 11:13 PM
> To: Wu, Hao A
> Cc: 'devel@edk2.groups.io'; 'Ard Biesheuvel'; ming.hu...@linaro.org; Ni,
> Ray
> Subject: Re: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop
> IntelFramework[Module]Pkg dependency
> 
> Hi Hao Wu,
> 
> Given Ming's confirmation regarding d06, I'm happy for this set to go
> ahead. Also, we're just past the edk2 stable tag, so people should be
> expecting some volatility :)
> 
> Acked-by: Leif Lindholm 

Thanks Leif,

Can I go ahead to push this series?
Or should I wait someone for additional review?

Best Regards,
Hao Wu

> 
> On Mon, Jun 10, 2019 at 05:13:42AM +, Wu, Hao A wrote:
> > Hello Ard and Leif,
> >
> > I saw Ming Huang  validated the patch (OS boot):
> > Hisilicon/D0x: Use StatusCode Router & Handler in MdeModulePkg
> >
> > https://edk2.groups.io/g/devel/message/41419
> > (Thanks a lot for the validation effort.)
> >
> > Do you have remaining concerns for review this series?
> > Thanks in advance.
> >
> > Best Regards,
> > Hao Wu
> >
> >
> > > -Original Message-
> > > From: Wu, Hao A
> > > Sent: Monday, May 27, 2019 10:43 AM
> > > To: devel@edk2.groups.io; Ard Biesheuvel; Leif Lindholm
> > > Cc: Kinney, Michael D; Andrew Fish; Laszlo Ersek; Ni, Ray;
> > > guoh...@huawei.com
> > > Subject: RE: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop
> > > IntelFramework[Module]Pkg dependency
> > >
> > > Hello Ard and Leif,
> > >
> > > Do you have comments on this series?
> > >
> > > Also, for the below patch to Hisilicon platforms:
> > > [PATCH v2 06/18] Hisilicon/D0x: Use StatusCode Router & Handler in
> > > MdeModulePkg
> > >
> > > it is suggested to be verified on actual hardware:
> > > https://edk2.groups.io/g/devel/topic/31614327#41188
> > >
> > > However, it seems that there is no accessible hardware for such
> verification
> > > at this moment. Do you think it is fine to push this change anyway?
> > >
> > > (Also CCed the stewards here for comments.)
> > >
> > > Best Regards,
> > > Hao Wu
> > >
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf
> Of
> > > > Wu, Hao A
> > > > Sent: Monday, May 20, 2019 4:41 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Wu, Hao A; Ard Biesheuvel; Leif Lindholm; Kinney, Michael D
> > > > Subject: [edk2-devel] [edk2-platforms][PATCH v2 00/18] Drop
> > > > IntelFramework[Module]Pkg dependency
> > > >
> > > > The series is also available at:
> > > > https://github.com/hwu25/edk2-
> > > > platforms/commits/drop_intelframework_v2
> > > >
> > > > V2 changes:
> > > > A. For platforms BeagleBoard, CelloBoard and Overdrive1000Board,
> update
> > > >their DSC file to consume the null ReportStatusCodeLib in MdePkg.
> The
> > > >change is done since these platforms do not have a StatusCode
> Router
> > > >module;
> > > > B. Add the change for platform RaspberryPi/RPi3 to drop its
> dependency
> > > on
> > > >the framework packages;
> > > > C. Update the commit log message for patch
> > > >'Silicon/Hisilicon: Use ReportStatusCodeLib (DXE) in MdeModulePkg'
> > > >to better reflect the commit impact.
> > > >
> > > >
> > > > This series will drop the IntelFramework[Module]Pkg dependency for
> > > > platforms within the edk2-platforms repo.
> > > > packages.
> > > >
> > > > Tests done for the series:
> > > > Platforms build verified with GCC5 toolchain:
> > > > * Platform/AMD/OverdriveBoard
> > > > * Platform/ARM/JunoPkg
> > > > * Platform/ARM/SgiPkg
> > > > * Platform/ARM/VExpressPkg
> > > > * Platform/BeagleBoard
> > > > * Platform/Hisilicon/D0x
> > > > * Platform/Hisilicon/HiKey
> > > > * Platform/Hisilicon/HiKey960
> > > > * Platform/LeMaker/CelloBoard
> > > > * Platform/Marvell/Armada70x0Db (only AARCH64)
> > > > * Platform/Marvell/Armada80x0Db (only AARCH64)
> > > > * Platform/RaspberryPi/RPi3
> > > > * Platform/Socionext/DeveloperBox
> > > > * Platform/Socionext/SynQuacerEvalBoard (only AARCH64)
> > > > * Platform/SoftIron/Overdrive1000Board
> > > > * Platform/SolidRun/Armada80x0McBin (only AARCH64)
> > > >
> > > > Platforms originally cannot be built via GCC5 toolchain (thus, not
> > > > verified):
> > > > * Platform/Comcast/RDKQemu (ARM, AARCH64)
> > > > * Platform/Marvell/Armada70x0Db (ARM)
> > > > * Platform/Marvell/Armada80x0Db (ARM)
> > > > * Platform/Socionext/SynQuacerEvalBoard (ARM, AARCH64)
> > > > * Platform/SolidRun/Armada80x0McBin (ARM)
> > > >
> > > > Cc: Ard Biesheuvel 
> > > > Cc: Leif Lindholm 
> > > > Cc: Michael D Kinney 
> > > >
> > > > Hao A Wu (18):
> > > >   Platform/AMD: Use Lzma decompress lib in MdeModulePkg
> > > >   Platform/BeagleBoard: Use ReportStatusCodeLib null instance
> > > >   Platform/BeagleBoard: Drop the consume of PcdShellFile
> > > >   Hisilicon/D0x: Use Lzma decompress lib in MdeModulePkg
> > > >   Hisilicon/D0x: Drop the consume of GenericBdsLib &