date:20190814

Re: [edk2-devel] [Patch v2 0/6] Add "test then write" mechanism.

2019-08-14 Thread Liming Gao

Eric:
  Is this a bug fix or new feature? Dose it catch to this 201908 stable tag? 

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Dong, Eric
>Sent: Tuesday, August 13, 2019 10:29 AM
>To: devel@edk2.groups.io; ler...@redhat.com
>Cc: Ni, Ray 
>Subject: Re: [edk2-devel] [Patch v2 0/6] Add "test then write" mechanism.
>
>Hi Laszlo,
>
>Yes, I already checked IA32 build.
>
>As Ray is leaving these days, can you help to review this serial?
>
>Thanks,
>Eric
>
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Laszlo Ersek
>> Sent: Monday, August 12, 2019 10:15 PM
>> To: Dong, Eric ; devel@edk2.groups.io
>> Cc: Ni, Ray 
>> Subject: Re: [edk2-devel] [Patch v2 0/6] Add "test then write" mechanism.
>>
>> On 08/12/19 12:31, Eric Dong wrote:
>> > V2 changes:
>> > 1. Split CR read/write action in to one discrete patch 2. Keep the old
>> > logic which continue the process if error found.
>> >
>> > Below code is current implementation:
>> >   if (MsrRegister[ProcessorNumber].Bits.Lock == 0) {
>> > CPU_REGISTER_TABLE_WRITE_FIELD (
>> >   ProcessorNumber,
>> >   Msr,
>> >   MSR_IA32_FEATURE_CONTROL,
>> >   MSR_IA32_FEATURE_CONTROL_REGISTER,
>> >   Bits.Lock,
>> >   1
>> > );
>> >   }
>> >
>> > With below steps, the Bits.Lock bit will lose its value:
>> > 1. Trig normal boot, the Bits.Lock is 0. 1 will be added
>> >into the register table and then will set to the MSR.
>> > 2. Trig warm reboot, MSR value preserves. After normal boot phase,
>> >the Bits.Lock is 1, so it will not be added into the register
>> >table during the warm reboot phase.
>> > 3. Trig S3 then resume, the Bits.Lock change to 0 and Bits.Lock is
>> >not added in register table during normal boot phase. so it's
>> >still 0 after resume.
>> > This is not an expect behavior. The expect result is the value should
>> > always 1 after booting or resuming from S3.
>> >
>> > The root cause for this issue is
>> > 1. driver bases on current value to insert the "set value action" to
>> >the register table.
>> > 2. Some MSRs may reserve their value during warm reboot. So the insert
>> >action may be skip after warm reboot.
>> >
>> > The solution for this issue is:
>> > 1. Always add "Test then Set" action for above referred MSRs.
>> > 2. Detect current value before set new value. Only set new value when
>> >current value not same as new value.
>> >
>> > Cc: Ray Ni 
>> > Cc: Laszlo Ersek 
>> >
>> > Eric Dong (6):
>> >   UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.
>> >   UefiCpuPkg/PiSmmCpuDxeSmm: Combine CR read/write action in one
>> > function.
>> >   UefiCpuPkg/PiSmmCpuDxeSmm: Supports test then write new value
>logic.
>> >   UefiCpuPkg/RegisterCpuFeaturesLib: Combine CR read/write action in
>> one
>> > function.
>> >   UefiCpuPkg/RegisterCpuFeaturesLib: Supports test then write new value
>> > logic.
>> >   UefiCpuPkg/CpuCommonFeaturesLib: Use new macros.
>> >
>> >  UefiCpuPkg/Include/AcpiCpuData.h  |   1 +
>> >  .../Include/Library/RegisterCpuFeaturesLib.h  |  77 +-
>> > .../CpuCommonFeaturesLib/CpuCommonFeatures.h  |  15 --
>> >  .../CpuCommonFeaturesLib.c|   8 +-
>> >  .../CpuCommonFeaturesLib/FeatureControl.c | 141 ++
>> >  .../CpuCommonFeaturesLib/MachineCheck.c   |  23 ++-
>> >  .../CpuFeaturesInitialize.c   | 141 --
>> >  .../RegisterCpuFeaturesLib.c  |  14 +-
>> >  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 135 +++--
>> >  9 files changed, 323 insertions(+), 232 deletions(-)
>> >
>>
>> Please don't forget to build-test this series for IA32 too.
>>
>> Thanks
>> Laszlo
>>
>>
>
>
>


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

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

[edk2-devel] [PATCH 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

2019-08-14 Thread Zhang, Shenglei

Initialize PageMapLevel5Entry at the beginning of the function.

This commit will fix a GCC 4.8.5 build failure introduced by commit
b3527dedc3951f061c5a73cb4fb2b0f95f47e08b.

OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to fix
the build failure completely.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Hao A Wu 
Signed-off-by: Shenglei Zhang 
---
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index 2389f3eb485b..aae80536ac3d 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -652,6 +652,8 @@ CreateIdentityMappingPageTables (
   UINT64AddressEncMask;
   IA32_CR4  Cr4;
 
+  PageMapLevel5Entry = NULL;
+
   //
   // Make sure AddressEncMask is contained to smallest supported address field
   //
-- 
2.18.0.windows.1


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

View/Reply Online (#45591): https://edk2.groups.io/g/devel/message/45591
Mute This Topic: https://groups.io/mt/32861558/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] Add "test then write" mechanism.

2019-08-14 Thread Dong, Eric

Hi liming,

This is a bug fix. It is required by 201908 stable tag.

Thanks,
Eric

> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, August 14, 2019 3:27 PM
> To: devel@edk2.groups.io; Dong, Eric ;
> ler...@redhat.com
> Cc: Ni, Ray ; leif.lindh...@linaro.org; af...@apple.com;
> Cetola, Stephano ; Kinney, Michael D
> 
> Subject: RE: [edk2-devel] [Patch v2 0/6] Add "test then write" mechanism.
> 
> Eric:
>   Is this a bug fix or new feature? Dose it catch to this 201908 stable tag?
> 
> Thanks
> Liming
> >-Original Message-
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >Dong, Eric
> >Sent: Tuesday, August 13, 2019 10:29 AM
> >To: devel@edk2.groups.io; ler...@redhat.com
> >Cc: Ni, Ray 
> >Subject: Re: [edk2-devel] [Patch v2 0/6] Add "test then write" mechanism.
> >
> >Hi Laszlo,
> >
> >Yes, I already checked IA32 build.
> >
> >As Ray is leaving these days, can you help to review this serial?
> >
> >Thanks,
> >Eric
> >
> >> -Original Message-
> >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >> Laszlo Ersek
> >> Sent: Monday, August 12, 2019 10:15 PM
> >> To: Dong, Eric ; devel@edk2.groups.io
> >> Cc: Ni, Ray 
> >> Subject: Re: [edk2-devel] [Patch v2 0/6] Add "test then write" mechanism.
> >>
> >> On 08/12/19 12:31, Eric Dong wrote:
> >> > V2 changes:
> >> > 1. Split CR read/write action in to one discrete patch 2. Keep the
> >> > old logic which continue the process if error found.
> >> >
> >> > Below code is current implementation:
> >> >   if (MsrRegister[ProcessorNumber].Bits.Lock == 0) {
> >> > CPU_REGISTER_TABLE_WRITE_FIELD (
> >> >   ProcessorNumber,
> >> >   Msr,
> >> >   MSR_IA32_FEATURE_CONTROL,
> >> >   MSR_IA32_FEATURE_CONTROL_REGISTER,
> >> >   Bits.Lock,
> >> >   1
> >> > );
> >> >   }
> >> >
> >> > With below steps, the Bits.Lock bit will lose its value:
> >> > 1. Trig normal boot, the Bits.Lock is 0. 1 will be added
> >> >into the register table and then will set to the MSR.
> >> > 2. Trig warm reboot, MSR value preserves. After normal boot phase,
> >> >the Bits.Lock is 1, so it will not be added into the register
> >> >table during the warm reboot phase.
> >> > 3. Trig S3 then resume, the Bits.Lock change to 0 and Bits.Lock is
> >> >not added in register table during normal boot phase. so it's
> >> >still 0 after resume.
> >> > This is not an expect behavior. The expect result is the value
> >> > should always 1 after booting or resuming from S3.
> >> >
> >> > The root cause for this issue is
> >> > 1. driver bases on current value to insert the "set value action" to
> >> >the register table.
> >> > 2. Some MSRs may reserve their value during warm reboot. So the
> insert
> >> >action may be skip after warm reboot.
> >> >
> >> > The solution for this issue is:
> >> > 1. Always add "Test then Set" action for above referred MSRs.
> >> > 2. Detect current value before set new value. Only set new value when
> >> >current value not same as new value.
> >> >
> >> > Cc: Ray Ni 
> >> > Cc: Laszlo Ersek 
> >> >
> >> > Eric Dong (6):
> >> >   UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.
> >> >   UefiCpuPkg/PiSmmCpuDxeSmm: Combine CR read/write action in one
> >> > function.
> >> >   UefiCpuPkg/PiSmmCpuDxeSmm: Supports test then write new value
> >logic.
> >> >   UefiCpuPkg/RegisterCpuFeaturesLib: Combine CR read/write action
> >> > in
> >> one
> >> > function.
> >> >   UefiCpuPkg/RegisterCpuFeaturesLib: Supports test then write new
> value
> >> > logic.
> >> >   UefiCpuPkg/CpuCommonFeaturesLib: Use new macros.
> >> >
> >> >  UefiCpuPkg/Include/AcpiCpuData.h  |   1 +
> >> >  .../Include/Library/RegisterCpuFeaturesLib.h  |  77 +-
> >> > .../CpuCommonFeaturesLib/CpuCommonFeatures.h  |  15 --
> >> >  .../CpuCommonFeaturesLib.c|   8 +-
> >> >  .../CpuCommonFeaturesLib/FeatureControl.c | 141 ++
> >> >  .../CpuCommonFeaturesLib/MachineCheck.c   |  23 ++-
> >> >  .../CpuFeaturesInitialize.c   | 141 --
> >> >  .../RegisterCpuFeaturesLib.c  |  14 +-
> >> >  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 135 +++
> --
> >> >  9 files changed, 323 insertions(+), 232 deletions(-)
> >> >
> >>
> >> Please don't forget to build-test this series for IA32 too.
> >>
> >> Thanks
> >> Laszlo
> >>
> >>
> >
> >
> >


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

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

[edk2-devel] [PATCH v3 2/2] CryptoPkg/OpensslLib: remove clone commands

2019-08-14 Thread Wang, Jian J

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

edk2/Readme.md has added a section to explain the correct clone
commands for submodules. Detailed steps in the OpenSSL-HOWTO.txt
are removed to avoid any inconsistency.

Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Jian J Wang 
Reviewed-by: Leif Lindholm 
---
 CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt 
b/CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt
index db45eb88d1..e52ee27b49 100644
--- a/CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt
+++ b/CryptoPkg/Library/OpensslLib/OpenSSL-HOWTO.txt
@@ -24,22 +24,8 @@ on the cryptography.
 =
   HOW to Install OpenSSL for UEFI Building
 =
-  OpenSSL repository was added as one submodule of EDKII project.
-
-  The user can use the following commands to clone both main EDKII repo and
-openssl submodule:
-  1) Add the "--recursive" flag to the git clone command:
- $ git clone --recursive https://github.com/tianocore/edk2
-or
-  2) Manually initialize and update the submodules after the clone operation
- on main project:
- $ git clone https://github.com/tianocore/edk2
- $ git submodule update --init --recursive
-
-  And use the following combined commands to pull the remote submodule updates
-(e.g. Updating the new supported OpenSSL release tag):
- $ git pull --recurse-submodules && \
-   git submodule update --recursive
+  OpenSSL repository was added as one submodule of EDKII project. Please
+refer to edk2/Readme.md for how to clone the code.
 
 =
   About process_files.pl
-- 
2.17.1.windows.2


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

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

[edk2-devel] [PATCH v3 0/2] Add edk2 submodule policy

2019-08-14 Thread Wang, Jian J

>v3 change
>  [1/2] a. change wording about submodule per Liming's comment.
>b. add more steps to do submodule update per Mike's comment.
>c. add commands for update of submodule
>  [2/2] no changes.

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

Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Liming Gao 

Jian J Wang (2):
  Readme.md: add submodule policy and clone commands
  CryptoPkg/OpensslLib: remove clone commands

 .../Library/OpensslLib/OpenSSL-HOWTO.txt  | 18 +
 Readme.md | 39 +++
 2 files changed, 41 insertions(+), 16 deletions(-)

-- 
2.17.1.windows.2


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

View/Reply Online (#45592): https://edk2.groups.io/g/devel/message/45592
Mute This Topic: https://groups.io/mt/32861686/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/2] Readme.md: add submodule policy and clone commands

2019-08-14 Thread Wang, Jian J

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

A section 'Submodules' is added to clarify the submodule policy
in edk2 repo. Git commands are also added to show the correct
way to clone submodule repos, in which '--recursive' is removed
because it's not needed but recommended in other document.

Related commits:
Openssl-1.1.1b upgrade: acfb90911840c38a0beb9bcfe0065668244d2b4d
berkeley-softfloat-3:   3cc57695df5a6e8c65fb46b993836c315cabf49d

Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Jian J Wang 
Reviewed-by: Leif Lindholm 
---
 Readme.md | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/Readme.md b/Readme.md
index 7c873759a5..27e4ce0771 100644
--- a/Readme.md
+++ b/Readme.md
@@ -140,3 +140,42 @@ Signed-off-by: Contributor Name 
   the change.  Each line should be less than ~70 characters.
 * `Signed-off-by` is the contributor's signature identifying them
   by their real/legal name and their email address.
+
+# Submodules
+
+Submodule in EDK II is allowed but submodule chain should be avoided
+as possible as we can. Currently EDK II contains two submodules
+
+- CryptoPkg/Library/OpensslLib/openssl
+- ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3
+
+The latter one is actually required by previous one. It's inevitable
+in openssl-1.1.1 (since stable201905) for floating point parameter
+conversion, but should be dropped once there's no such need in future
+release of openssl.
+
+To get a full, buildable EDK II repository, use following steps of git
+command
+
+```
+$ git clone https://github.com/tianocore/edk2.git
+$ cd edk2
+$ git submodule update --init
+$ cd ..
+```
+
+If there's update for submodules, use following git commands to get the
+latest submodules code.
+
+```
+$ cd edk2
+$ git pull
+$ git submodule update
+```
+
+Note: When cloning submodule repos, '--recursive' option is not
+recommended. EDK II itself will not use any code/feature from
+submodules in above submodules. So using '--recursive' adds a
+dependency on being able to reach servers we do not actually want
+any code from, as well as needlessly downloading code we will not
+use.
-- 
2.17.1.windows.2


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

View/Reply Online (#45593): https://edk2.groups.io/g/devel/message/45593
Mute This Topic: https://groups.io/mt/32861688/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] ShellPkg/UefiShellDriver1CommandsLib: Make array big enough

2019-08-14 Thread Gao, Zhichao

Ping again.

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Gao, Zhichao
> Sent: Friday, July 26, 2019 3:47 PM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray ;
> oleks...@ami.com
> Subject: FW: [edk2-devel] [PATCH V2]
> ShellPkg/UefiShellDriver1CommandsLib: Make array big enough
> 
> Ping. Please help to review it.
> 
> Thanks,
> Zhichao
> 
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Gao, Zhichao
> Sent: Monday, July 22, 2019 2:58 PM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray ;
> Oleksiy 
> Subject: [edk2-devel] [PATCH V2] ShellPkg/UefiShellDriver1CommandsLib:
> Make array big enough
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1941
> 
> The two CHAR16 array ChildCountStr and DeviceCountStr is defined to hold
> the decimal string data of UINTN. The max of UINTN is
> 18446744073709551615 and it contain 20 characters.
> So make their size to 21 CHAR16s to hold the string data with a null-
> terminate.
> UnicodeValueToStringS regard the value input as INT64, and
> 21 CHARs is enough to hold the lowest value with minus '-'.
> Although the value shouldn't be such big.
> 
> Cc: Jaben Carsey 
> Cc: Ray Ni 
> Cc: Oleksiy 
> Signed-off-by: Zhichao Gao 
> ---
> 
> V2:
> Update the copyright.
> 
>  ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> index 794b737bd1..27cd278cf0 100644
> --- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> +++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> @@ -2,7 +2,7 @@
>Main file for Drivers shell Driver1 function.
> 
>(C) Copyright 2012-2015 Hewlett-Packard Development Company, L.P.
> -  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2010 - 2019, Intel Corporation. All rights
> + reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -263,8 +263,8 @@ ShellCommandRunDrivers (
>EFI_HANDLE  *HandleWalker;
>UINTN   ChildCount;
>UINTN   DeviceCount;
> -  CHAR16  ChildCountStr[3];
> -  CHAR16  DeviceCountStr[3];
> +  CHAR16  ChildCountStr[21];
> +  CHAR16  DeviceCountStr[21];
>CHAR16  *Temp2;
>CONST CHAR16*FullDriverName;
>CHAR16  *TruncatedDriverName;
> --
> 2.21.0.windows.1
> 
> 
> 
> 
> 
> 


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

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

Re: [edk2-devel] [RFC] BZ 1837 Enable Windows Firmware Update Driver Tool in Edk2/BaseTools for 201908 stable tag

2019-08-14 Thread Eric Jin

Hi Leif,

Thank for the valuable suggestion.
In the patch series V2, Sean has been set as author on patch 1/2. Thank you.

Best Regards
Eric

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif 
Lindholm
Sent: Wednesday, August 14, 2019 2:47 AM
To: Gao, Liming 
Cc: Jin, Eric ; r...@edk2.groups.io; devel@edk2.groups.io; 
Feng, Bob C ; Cetola, Stephano 
; Laszlo Ersek (ler...@redhat.com) 
; af...@apple.com; Kinney, Michael D 

Subject: Re: [edk2-devel] [RFC] BZ 1837 Enable Windows Firmware Update Driver 
Tool in Edk2/BaseTools for 201908 stable tag

Hi Liming,

This is the other one. As I said, the fact that we are slipping multiple 
scripts in *just* before freeze is a concern for me.

I have no objection to the code here though.

I would however request that Sean is set as author on patch 1/2 as he was the 
original author of the script. (This was easy for me to find out because the 
commit message was exemplary.)

Best Regards,

Leif

On Tue, Aug 13, 2019 at 01:49:24PM +, Gao, Liming wrote:
> I see this patch was sent a week ago. This is a standalone tool. There is no 
> impact on normal build and boot. I am OK to add it for 201908 stable tag.
> 
> Thanks
> Liming
> From: Jin, Eric
> Sent: Monday, August 12, 2019 3:09 PM
> To: r...@edk2.groups.io
> Cc: Gao, Liming ; Jin, Eric 
> ; devel@edk2.groups.io; Feng, Bob C 
> 
> Subject: [RFC] BZ 1837 Enable Windows Firmware Update Driver Tool in 
> Edk2/BaseTools for 201908 stable tag
> 
> Hi All,
> 
> It is the request to Enable Windows Firmware Update Driver Tool in 
> Edk2/BaseTools  and catch the Q3 tag.
> The new tool will leverage the edk2-pytool-library to generate the cat/inf 
> file based on the cap file. The output driver package can be trigged in 
> Windows OS to complete capsule update.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1837
> 
> Patch link: https://edk2.groups.io/g/devel/topic/32780378#44992
> 
> Best Regards
> Eric
> 
> 




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

View/Reply Online (#45587): https://edk2.groups.io/g/devel/message/45587
Mute This Topic: https://groups.io/mt/32838310/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 00/10] Multiple Controllers Support solution

2019-08-14 Thread Eric Jin

Liming,

Thank you for notification. 

Best Regards
Eric

-Original Message-
From: Gao, Liming  
Sent: Wednesday, August 14, 2019 12:38 PM
To: Jin, Eric ; devel@edk2.groups.io
Subject: RE: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support solution

Eric:
  I push the first 3 patches 
82407bd129dca8ec6d96e85f541b0974c8d7e087..1f06aa24c29405f271f514f01c396c2ba19c1370.
 
  Then, the changes in edk2 platform can be submitted. After edk2platform 
change is ready, I will push the remaining patch set. 

Thanks
Liming
>-Original Message-
>From: Jin, Eric
>Sent: Monday, August 12, 2019 11:17 PM
>To: Gao, Liming ; devel@edk2.groups.io
>Cc: Jin, Eric 
>Subject: RE: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support 
>solution
>
>Liming,
>
>Thank you for comment.
>We will update GetLowestSupportedVersion() API function header to 
>include Private param when we push the code to repo. Thanks.
>
>Best Regards
>Eric
>
>-Original Message-
>From: Gao, Liming
>Sent: Monday, August 12, 2019 5:24 PM
>To: Jin, Eric ; devel@edk2.groups.io
>Subject: RE: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support 
>solution
>
>That's good information.
>
>In patch 5, GetLowestSupportedVersion() API function header should be 
>updated to include Private param. I have no other comments.
>
>With this change, Reviewed-by: Liming Gao 
>
>///
>@@ -193,7 +200,7 @@ GetImageTypeNameString (  **/
> UINT32
> GetLowestSupportedVersion (
>-  VOID
>+  FIRMWARE_MANAGEMENT_PRIVATE_DATA  *Private
>   )
>
>Thanks
>Liming
>>-Original Message-
>>From: Jin, Eric
>>Sent: Monday, August 12, 2019 3:14 PM
>>To: Gao, Liming ; devel@edk2.groups.io
>>Subject: RE: [edk2-devel] [PATCH V2 00/10] Multiple Controllers 
>>Support solution
>>
>>Liming,
>>
>>The differences between V2 and V1 are listed below.
>>
>>1) The series is composed of 10 patches in V2 (14 in V1). patch 14 is 
>>merged into patch 4, and patch 11/12/13 are merged into patch 5.
>>2) Try to fix the issue exposed by ECC.
>>
>>Btw, the patch of edk2-platform
>>Platform\Intel\Vlv2TbltDevicePkg\Feature\Capsule\Library\FmpDeviceLib
>>to support new APIs is provided in separated patch
>>https://edk2.groups.io/g/devel/message/45328
>>
>>Best Regards
>>Eric
>>
>>-Original Message-
>>From: Gao, Liming
>>Sent: Monday, August 12, 2019 1:19 PM
>>To: devel@edk2.groups.io; Jin, Eric 
>>Subject: RE: [edk2-devel] [PATCH V2 00/10] Multiple Controllers 
>>Support solution
>>
>>Eric:
>>  Can you list the difference compared to version 1?
>>
>>Thanks
>>Liming
>>>-Original Message-
>>>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
>>>Eric Jin
>>>Sent: Monday, August 12, 2019 9:46 AM
>>>To: devel@edk2.groups.io
>>>Subject: [edk2-devel] [PATCH V2 00/10] Multiple Controllers Support 
>>>solution
>>>
>>>REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1525
>>>
>>>The patch set is to support drivers that manage multiple controllers 
>>>and also provide a firmware update capability to each managed controller.
>>>
>>>The following modules are related to Multiple Controllers Support 
>>>solution
>>>
>>>FmpDevicePkg\FmpDxe\FmpDxe.inf - Driver to manage multiple
>controllers
>>>and provide the firmware update capability to each managed controller.
>>>FmpDevicePkg\CapsuleUpdatePolicyDxe\CapsuleUpdatePolicyDxe.inf -
>>Driver
>>>to produce the Capsule Update Policy Protocol using the services of 
>>>the CapsuleUpdatePolicyLib class. The protocol is a private interface 
>>>to the FmpDevicePkg 
>>>FmpDevicePkg\Library\CapsuleUpdatePolicyLibOnProtocol\CapsuleUpdate
>P
>>o
>>>licyLibOnProtocol.inf -
>>>CapsuleUpdatePolicyLib instance that uses the services of the Capsule 
>>>Update Policy Protocol produced by CapsuleUpdatePolicyDxe 
>>>FmpDevicePkg\Library\CapsuleUpdatePolicyLibNull\CapsuleUpdatePolicyLi
>b
>>N
>>>ull.inf -
>>>Null CapsuleUpdatePolicyLib instance and the template for platform 
>>>specific implementation 
>>>FmpDevicePkg\Library\FmpDeviceLibNull\FmpDeviceLibNull.inf - Null 
>>>FmpDeviceLib instance and the template for platform specific 
>>>implementation
>>>
>>>Eric Jin (10):
>>>  FmpDevicePkg: Add UEFI_DRIVER support
>>>  FmpDevicePkg: Add APIs to FmpDeviceLib
>>>  FmpDEvicePkg/FmpDeviceLibNull: Implement new APIs
>>>  FmpDevicePkg/FmpDxe: Use new FmpDeviceLib APIs
>>>  FmpDevicePkg/FmpDxe: Different variable for each FMP Descriptor
>>>  FmpDevicePkg: Add Capsule Update Policy Protocol
>>>  FmpDevicePkg/FmpDxe: Improve all DEBUG() messages
>>>  FmpDevicePkg/FmpDxe: Add PcdFmpDeviceImageTypeIdGuid
>>>  FmpDevicePkg/FmpDxe: Add PcdFmpDeviceStorageAccessEnable
>>>  FmpDevicePkg/FmpDxe: Remove use of CatSprint()
>>>
>>> .../CapsuleUpdatePolicyDxe.c  | 173 
>>> .../CapsuleUpdatePolicyDxe.h  | 140 +++
>>> .../CapsuleUpdatePolicyDxe.inf|  48 +
>>> .../CapsuleUpdatePolicyDxe.uni|  14 +
>>> .../CapsuleUpdatePolicyDxeExtra.uni   |  14 +
>>>

Re: [edk2-devel] [PATCH v3 0/2] Add edk2 submodule policy

2019-08-14 Thread Wang, Jian J

Sorry for the late update for this patch series. Please find v2 review at
https://edk2.groups.io/g/devel/topic/32413655#43457

Regards,
Jian

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Wang, Jian J
> Sent: Wednesday, August 14, 2019 4:15 PM
> To: devel@edk2.groups.io
> Cc: Leif Lindholm ; Kinney, Michael D
> ; Gao, Liming 
> Subject: [edk2-devel] [PATCH v3 0/2] Add edk2 submodule policy
> 
> >v3 change
> >  [1/2] a. change wording about submodule per Liming's comment.
> >b. add more steps to do submodule update per Mike's comment.
> >c. add commands for update of submodule
> >  [2/2] no changes.
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1910
> 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> 
> Jian J Wang (2):
>   Readme.md: add submodule policy and clone commands
>   CryptoPkg/OpensslLib: remove clone commands
> 
>  .../Library/OpensslLib/OpenSSL-HOWTO.txt  | 18 +
>  Readme.md | 39 +++
>  2 files changed, 41 insertions(+), 16 deletions(-)
> 
> --
> 2.17.1.windows.2
> 
> 
> 


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

View/Reply Online (#45595): https://edk2.groups.io/g/devel/message/45595
Mute This Topic: https://groups.io/mt/32861686/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] BaseTools/Scripts: Add GetUtcDateTime script.

2019-08-14 Thread Leif Lindholm

On Wed, Aug 14, 2019 at 06:21:06PM +0800, Chasel Chiu wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2067
> 
> A script that can return UTC date and time in ascii
> format which is convenient for patching build time
> information in any binary.
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Leif Lindholm 
> Signed-off-by: Chasel Chiu 

Yeah, this looks a lot better, thanks.
Acked-by: Leif Lindholm 

> ---
>  BaseTools/Scripts/GetUtcDateTime.py | 44 
> 
>  1 file changed, 44 insertions(+)
> 
> diff --git a/BaseTools/Scripts/GetUtcDateTime.py 
> b/BaseTools/Scripts/GetUtcDateTime.py
> new file mode 100644
> index 00..3cfb6ac2ae
> --- /dev/null
> +++ b/BaseTools/Scripts/GetUtcDateTime.py
> @@ -0,0 +1,44 @@
> +## @file
> +#  Get current UTC date and time information and output as ascii code.
> +#
> +#  Copyright (c) 2019, Intel Corporation. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +
> +VersionNumber = '0.1'
> +import sys
> +import datetime
> +import argparse
> +
> +def Main():
> +PARSER = argparse.ArgumentParser(
> +description='Retrieves UTC date and time information (output 
> ordering: year, date, time) - Version ' + VersionNumber)
> +PARSER.add_argument('--year',
> +action='store_true',
> +help='Return UTC year of now. [Example output 
> (2019): 39313032]')
> +PARSER.add_argument('--date',
> +action='store_true',
> +help='Return UTC date MMDD of now. [Example output 
> (7th August): 37303830]')
> +PARSER.add_argument('--time',
> +action='store_true',
> +help='Return 24-hour-format UTC time HHMM of now. 
> [Example output (14:25): 35323431]')
> +
> +ARGS = PARSER.parse_args()
> +if len(sys.argv) == 1:
> +print ("ERROR: At least one argument is required!\n")
> +PARSER.print_help()
> +
> +today = datetime.datetime.utcnow()
> +if ARGS.year:
> +ReversedNumber = str(today.year)[::-1]
> +print (''.join(hex(ord(HexString))[2:] for HexString in 
> ReversedNumber))
> +if ARGS.date:
> +ReversedNumber = str(today.strftime("%m%d"))[::-1]
> +print (''.join(hex(ord(HexString))[2:] for HexString in 
> ReversedNumber))
> +if ARGS.time:
> +ReversedNumber = str(today.strftime("%H%M"))[::-1]
> +print (''.join(hex(ord(HexString))[2:] for HexString in 
> ReversedNumber))
> +
> +if __name__ == '__main__':
> +Main()
> -- 
> 2.13.3.windows.1
> 

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

View/Reply Online (#45603): https://edk2.groups.io/g/devel/message/45603
Mute This Topic: https://groups.io/mt/32862249/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] BaseTools/Scripts: Add GetUtcDateTime script.

2019-08-14 Thread rebecca

On 2019-08-14 04:21, Chiu, Chasel wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2067
>
> A script that can return UTC date and time in ascii
> format which is convenient for patching build time
> information in any binary.


I know it's not a required tool to be run before committing, but could
you consider the following issues pylama reported, please?

BaseTools/Scripts/GetUtcDateTime.py:1:1: E266 too many leading '#' for
block comment [pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:10:1: E402 module level import not
at top of file [pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:11:1: E402 module level import not
at top of file [pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:12:1: E402 module level import not
at top of file [pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:14:1: E302 expected 2 blank lines,
found 1 [pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:29:14: E211 whitespace before '('
[pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:35:14: E211 whitespace before '('
[pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:38:14: E211 whitespace before '('
[pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:41:14: E211 whitespace before '('
[pycodestyle]
BaseTools/Scripts/GetUtcDateTime.py:43:1: E305 expected 2 blank lines
after class or function definition, found 1 [pycodestyle]

-- 
Rebecca Cran


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

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

Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl definition.

2019-08-14 Thread Marc W Chen

Thanks Liming for pushing the code.

Can we have a conclusion for the SmmAccess.h removal from MdeModulePkg? Who can 
make the decision? Or do we need any further discussion?

Thanks,
Marc

> -Original Message-
> From: Gao, Liming
> Sent: Tuesday, August 13, 2019 5:20 PM
> To: devel@edk2.groups.io; Gao, Liming ; Chen, Marc
> W ; ler...@redhat.com; Ni, Ray
> 
> Cc: Kinney, Michael D 
> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> definition.
> 
> Push @6f33f7a262314af35e2b99c849e08928ea49aa55
> 
> >-Original Message-
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >Liming Gao
> >Sent: Saturday, August 10, 2019 11:34 AM
> >To: Chen, Marc W ; devel@edk2.groups.io;
> >ler...@redhat.com; Ni, Ray 
> >Cc: Kinney, Michael D 
> >Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and MmControl
> >definition.
> >
> >I agree. The patch to add them in MdePkg is clear. I will push it next 
> >Monday.
> >
> >Thanks
> >Liming
> >> -Original Message-
> >> From: Chen, Marc W
> >> Sent: Saturday, August 10, 2019 11:33 AM
> >> To: devel@edk2.groups.io; ler...@redhat.com; Ni, Ray
> ;
> >Gao, Liming 
> >> Cc: Kinney, Michael D 
> >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> MmControl
> >definition.
> >>
> >> Hi Liming
> >>
> >> Since the SmmAccess.h of MdeModulePkg removal is still under discussion,
> >can we push the MmAccess.h and MmControl.h to MdePkg
> >> first? I have other tasks pending by this.
> >> We can keep discussing the SmmAccess after push the code.
> >>
> >> Thanks,
> >> Marc
> >>
> >> > -Original Message-
> >> > From: devel@edk2.groups.io  On Behalf Of
> Laszlo
> >> > Ersek
> >> > Sent: Thursday, August 8, 2019 12:11 AM
> >> > To: Ni, Ray ; Chen, Marc W
> ;
> >> > devel@edk2.groups.io; Gao, Liming 
> >> > Cc: Kinney, Michael D 
> >> > Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >MmControl
> >> > definition.
> >> >
> >> > On 08/06/19 12:08, Ni, Ray wrote:
> >> > > Laszlo,
> >> > > Do you want to avoid touching the OvmfPkg due the file removal in
> >> > MdeModulePkg?
> >> >
> >> > My main problem with this *specific* update proposal is that the
> >> > identifiers (type names and such) that would be subject to removal were
> >> > publicly specified in earlier PI spec releases.
> >> >
> >> > I don't suggest that we maintain two parallel sets of typedefs and such
> >> > in edk2. It's fine to keep the new "MM" nomenclature the main one. But
> >> > we should keep the "SMM" set of terms too, as a thin wrapper, if that's
> >> > technically feasible.
> >> >
> >> > If we remove "SMM", that will not only affect OvmfPkg unpleasantly, but
> >> > a bunch of other, out-of-tree code. And the reason I suddenly care
> about
> >> > out-of-tree code is that such code was written against a public industry
> >> > spec (= earlier versions of the PI spec).
> >> >
> >> > I don't think that the simplicity that would come from removing "SMM"
> >> > altogether, is well-balanced against the pain that it would cause for
> >> > platforms.
> >> >
> >> > Earlier this was solved in the following commits:
> >> > - 07c6a47e70ba ("MdePkg: Add new definitions for Management
> Mode.",
> >> > 2017-08-29)
> >> > - 2f208e59e4b9 ("MdePkg: Reference new definitions for Management
> >> > Mode.", 2017-08-29)
> >> >
> >> > Thanks
> >> > Laszlo
> >> >
> >> > > I prefer to remove the files in MdeModulePkg to avoid future
> confusion.
> >> > >
> >> > > Thanks,
> >> > > Ray
> >> > >
> >> > >> -Original Message-
> >> > >> From: Chen, Marc W
> >> > >> Sent: Tuesday, August 6, 2019 4:57 PM
> >> > >> To: devel@edk2.groups.io; ler...@redhat.com; Ni, Ray
> >> > ;
> >> > >> Gao, Liming 
> >> > >> Cc: Kinney, Michael D 
> >> > >> Subject: RE: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >> > MmControl
> >> > >> definition.
> >> > >>
> >> > >> Hi Liming and Ray
> >> > >>
> >> > >> Do you also agree?
> >> > >>
> >> > >> Thanks,
> >> > >> Marc
> >> > >>
> >> > >>> -Original Message-
> >> > >>> From: devel@edk2.groups.io  On Behalf Of
> >> > Laszlo
> >> > >>> Ersek
> >> > >>> Sent: Friday, August 2, 2019 10:14 AM
> >> > >>> To: devel@edk2.groups.io; Chen, Marc W
> ;
> >Ni,
> >> > >>> Ray ; Gao, Liming 
> >> > >>> Cc: Kinney, Michael D 
> >> > >>> Subject: Re: [edk2-devel] [PATCH] MdePkg: Add MmAccess and
> >> > >> MmControl
> >> > >>> definition.
> >> > >>>
> >> > >>> On 08/01/19 12:15, Marc W Chen wrote:
> >> >  Yes, my purpose is to avoid platform code update if the package is
> >> >  allowed
> >> > >>> to use MdeModulePkg like OvmfPkg.
> >> >  For those packages that cannot depend on MdeModulePkg must
> >> > change
> >> > >> to
> >> > >>> use new definition.
> >> > >>>
> >> > >>> Agreed.
> >> > >>>
> >> > >>> Thanks!
> >> > >>> Laszlo
> >> > >>>
> >> > > -Original Message-
> >> > > From: Ni, Ray
> >> > > Sent: Thursday, August 1, 2019 6:04 PM
> >> > > To: Chen, Marc W ; Gao, Liming
> >> > >

[edk2-devel] [PATCH v2] BaseTools/Scripts: Add GetUtcDateTime script.

2019-08-14 Thread Chiu, Chasel

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

A script that can return UTC date and time in ascii
format which is convenient for patching build time
information in any binary.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Leif Lindholm 
Signed-off-by: Chasel Chiu 
---
 BaseTools/Scripts/GetUtcDateTime.py | 44 

 1 file changed, 44 insertions(+)

diff --git a/BaseTools/Scripts/GetUtcDateTime.py 
b/BaseTools/Scripts/GetUtcDateTime.py
new file mode 100644
index 00..3cfb6ac2ae
--- /dev/null
+++ b/BaseTools/Scripts/GetUtcDateTime.py
@@ -0,0 +1,44 @@
+## @file
+#  Get current UTC date and time information and output as ascii code.
+#
+#  Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+VersionNumber = '0.1'
+import sys
+import datetime
+import argparse
+
+def Main():
+PARSER = argparse.ArgumentParser(
+description='Retrieves UTC date and time information (output ordering: 
year, date, time) - Version ' + VersionNumber)
+PARSER.add_argument('--year',
+action='store_true',
+help='Return UTC year of now. [Example output (2019): 
39313032]')
+PARSER.add_argument('--date',
+action='store_true',
+help='Return UTC date MMDD of now. [Example output 
(7th August): 37303830]')
+PARSER.add_argument('--time',
+action='store_true',
+help='Return 24-hour-format UTC time HHMM of now. 
[Example output (14:25): 35323431]')
+
+ARGS = PARSER.parse_args()
+if len(sys.argv) == 1:
+print ("ERROR: At least one argument is required!\n")
+PARSER.print_help()
+
+today = datetime.datetime.utcnow()
+if ARGS.year:
+ReversedNumber = str(today.year)[::-1]
+print (''.join(hex(ord(HexString))[2:] for HexString in 
ReversedNumber))
+if ARGS.date:
+ReversedNumber = str(today.strftime("%m%d"))[::-1]
+print (''.join(hex(ord(HexString))[2:] for HexString in 
ReversedNumber))
+if ARGS.time:
+ReversedNumber = str(today.strftime("%H%M"))[::-1]
+print (''.join(hex(ord(HexString))[2:] for HexString in 
ReversedNumber))
+
+if __name__ == '__main__':
+Main()
-- 
2.13.3.windows.1


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

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

Re: [edk2-devel][Patch] MdeModulePkg/CapsuleApp: Improve comparisons in CapsuleOnDisk.c

2019-08-14 Thread Wu, Hao A

> -Original Message-
> From: Xu, Wei6
> Sent: Tuesday, August 13, 2019 6:53 PM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A; Gao, Liming
> Subject: [edk2-devel][Patch] MdeModulePkg/CapsuleApp: Improve
> comparisons in CapsuleOnDisk.c
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2028
> 
> Non-Boolean comparisons should use a compare operator
> (==, !=, >, < >=, <=).
> 
> Cc: Hao A Wu 
> Cc: Liming Gao 
> Signed-off-by: Wei6 Xu 
> ---
>  MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> index 382efa9aa0..b161d1a981 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> @@ -742,11 +742,11 @@ IsCapsuleOnDiskSupported (
>);
>if (EFI_ERROR (Status)) {
>  return FALSE;
>}
> 
> -  if (OsIndicationsSupported &
> EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED) {
> +  if ((OsIndicationsSupported &
> EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED) != 0) {
>  return TRUE;
>}


Reviewed-by: Hao A Wu 
Pushed via commit 34651e7d76.

Best Regards,
Hao Wu


> 
>return FALSE;
>  }
> --
> 2.16.2.windows.1


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

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

Re: [edk2-devel][Patch] MdeModulePkg/DxeCapsuleLibFmp: Improve comparisons in CapsuleOnDisk.c

2019-08-14 Thread Wu, Hao A

> -Original Message-
> From: Xu, Wei6
> Sent: Tuesday, August 13, 2019 6:54 PM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A; Gao, Liming
> Subject: [edk2-devel][Patch] MdeModulePkg/DxeCapsuleLibFmp: Improve
> comparisons in CapsuleOnDisk.c
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2028
> 
> Non-Boolean comparisons should use a compare operator
> (==, !=, >, < >=, <=).
> 
> Cc: Hao A Wu 
> Cc: Liming Gao 
> Signed-off-by: Wei6 Xu 
> ---
>  MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
> b/MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
> index 3193ca8f4d..4c32c6cdcf 100644
> --- a/MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
> +++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
> @@ -125,11 +125,11 @@ UpperCaseString (
>IN CHAR16 *Str
>)
>  {
>CHAR16  *Cptr;
> 
> -  for (Cptr = Str; *Cptr; Cptr++) {
> +  for (Cptr = Str; *Cptr != L'\0'; Cptr++) {


Reviewed-by: Hao A Wu 
Pushed via commit f5892aa8d8.

Best Regards,
Hao Wu


>  if (L'a' <= *Cptr && *Cptr <= L'z') {
>*Cptr = *Cptr - L'a' + L'A';
>  }
>}
> 
> --
> 2.16.2.windows.1


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

View/Reply Online (#45647): https://edk2.groups.io/g/devel/message/45647
Mute This Topic: https://groups.io/mt/32851277/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] BaseTools/Scripts: Add GetUtcDateTime script.

2019-08-14 Thread Bob Feng

Reviewed-by: Bob Feng 

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Chiu, 
Chasel
Sent: Wednesday, August 14, 2019 6:21 PM
To: devel@edk2.groups.io
Cc: Feng, Bob C ; Gao, Liming ; 
Leif Lindholm 
Subject: [edk2-devel] [PATCH v2] BaseTools/Scripts: Add GetUtcDateTime script.

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

A script that can return UTC date and time in ascii format which is convenient 
for patching build time information in any binary.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Leif Lindholm 
Signed-off-by: Chasel Chiu 
---
 BaseTools/Scripts/GetUtcDateTime.py | 44 

 1 file changed, 44 insertions(+)

diff --git a/BaseTools/Scripts/GetUtcDateTime.py 
b/BaseTools/Scripts/GetUtcDateTime.py
new file mode 100644
index 00..3cfb6ac2ae
--- /dev/null
+++ b/BaseTools/Scripts/GetUtcDateTime.py
@@ -0,0 +1,44 @@
+## @file
+#  Get current UTC date and time information and output as ascii code.
+#
+#  Copyright (c) 2019, Intel Corporation. All rights reserved. # #
+SPDX-License-Identifier: BSD-2-Clause-Patent #
+
+VersionNumber = '0.1'
+import sys
+import datetime
+import argparse
+
+def Main():
+PARSER = argparse.ArgumentParser(
+description='Retrieves UTC date and time information (output ordering: 
year, date, time) - Version ' + VersionNumber)
+PARSER.add_argument('--year',
+action='store_true',
+help='Return UTC year of now. [Example output (2019): 
39313032]')
+PARSER.add_argument('--date',
+action='store_true',
+help='Return UTC date MMDD of now. [Example output 
(7th August): 37303830]')
+PARSER.add_argument('--time',
+action='store_true',
+help='Return 24-hour-format UTC time HHMM of 
+now. [Example output (14:25): 35323431]')
+
+ARGS = PARSER.parse_args()
+if len(sys.argv) == 1:
+print ("ERROR: At least one argument is required!\n")
+PARSER.print_help()
+
+today = datetime.datetime.utcnow()
+if ARGS.year:
+ReversedNumber = str(today.year)[::-1]
+print (''.join(hex(ord(HexString))[2:] for HexString in 
ReversedNumber))
+if ARGS.date:
+ReversedNumber = str(today.strftime("%m%d"))[::-1]
+print (''.join(hex(ord(HexString))[2:] for HexString in 
ReversedNumber))
+if ARGS.time:
+ReversedNumber = str(today.strftime("%H%M"))[::-1]
+print (''.join(hex(ord(HexString))[2:] for HexString in 
+ ReversedNumber))
+
+if __name__ == '__main__':
+Main()
--
2.13.3.windows.1





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

View/Reply Online (#45648): https://edk2.groups.io/g/devel/message/45648
Mute This Topic: https://groups.io/mt/32862249/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 1/1] MdePkg: Add STATIC_ASSERT macro

2019-08-14 Thread Vitaly Cheptosv via Groups.Io

Liming,

Thank you for adding everyone to the CC list. Yes, I would like this to be 
merged into the next EDK II stable release.

Best regards,
Vitaly

On чт, авг. 15, 2019 at 04:59, Gao, Liming  wrote:

> Vitaly:
>
>   As you know, edk2 201908 stable tag will start soft freeze tomorrow. Dose 
> this patch plan to catch this stable tag?
>
>  If yes, please ask the feedback from Tianocore Stewards. I have cc this 
> patch to all Stewards.
>
> Thanks
>
> Liming[]
>
> []From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Yao, 
> Jiewen
> Sent: Thursday, August 15, 2019 9:05 AM
> To: devel@edk2.groups.io; vit9...@protonmail.com; Kinney, Michael D 
> 
> Cc: Laszlo Ersek 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
>
> Good input.
>
> I think we should separate the work to convert all EDKII code to use 
> STATIC_ASSERT.
>
> We can do that work once we add STATIC_ASSERT.
>
> I recommend:
>
> 1)  Step 1: Add STATIS_ASSERT - this patch and this Bugzilla
>
> 2)  Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove 
> VERIFY_SIZE_OF – the other patch and the other Bugzilla
>
> 3)  Step 3: Scan the rest, if there is need. – Another patch and another 
> Bugzilla
>
> Thank you
>
> Yao Jiewen
>
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Vitaly 
> Cheptosv via Groups.Io
> Sent: Thursday, August 15, 2019 12:23 AM
> To: Kinney, Michael D 
> Cc: devel@edk2.groups.io; Laszlo Ersek 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
>
> Michael, Liming, Laszlo,
>
> Static assertions via _Static_assert are standard C11 functionality, thus any 
> at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support 
> the second argument with the diagnostic description.
>
> The notation without the message currently is only present in C++, not in C, 
> thus the two-argument notation is the only allowed notation for 
> _Static_assert for at least C17 (ISO/IEC 9899 2018) and below.
>
> In the bottom of this message I included a quote from C17 for the relevant 
> section (6.7.10).
>
> GCC and CLANG (including Xcode) appear to be conforming to the standard for 
> this section, and MSVC compiler static_assert extension also supports the 
> diagnostic message argument. This is pretty much all we care about.
>
> As for examples, I see little reason to clarify STATIC_ASSERT behaviour 
> outside of the standard reference in its description and actual usage in the 
> source code, but can do that just fine if you think that it may help somebody.
>
> I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, 
> and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. 
> This should be fairly costless, as apparently it is only used in Base.h and 
> MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in 
> the same patch set.
>
> As for select ASSERT usage switching to STATIC_ASSERT, this would also be 
> great, as let us be honest, the use of ASSERT in EDK II codebase is very 
> questioning. In fact, this was one of the reasons we introduced our own 
> static assertions some time ago. However, fixing up all broken assertions is 
> unlikely a best place to fit into this patchset, but I can surely add a few 
> examples, in case somebody points them out. This will be useful for reference 
> purposes and may help the maintainers to get a better idea when static 
> assertions are to be used.
>
> Looking forward to hearing your opinions.
>
> Best regards,
> Vitaly
>
> 6.7.10 Static assertions
>
> Syntax
> 1 static_assert-declaration:
> _Static_assert ( constant-expression , string-literal ) ;
>
> Constraints
> 2 The constant expression shall compare unequal to 0.
>
> Semantics
> 3 The constant expression shall be an integer constant expression. If the 
> value of the constant expression compares unequal to 0, the declaration has 
> no effect. Otherwise, the constraint is violated and the implementation shall 
> produce a diagnostic message that includes the text of the string literal, 
> except that characters not in the basic source character set are not required 
> to appear in the message.
>
> Forward references: diagnostics (7.2).
>
> 7.2 Diagnostics 
>
> 3 The macro
> static_assert
> expands to _Static_assert.
>
>> 14авг. 2019 г., в 18:47, Kinney, Michael D  
>> написал(а):
>>
>>
>> Liming,
>>
>> I think a good candidate to demonstrate this
>> feature are the checks made in MdePkg/Include/Base.h.
>> The current implementation forces a divide by 0
>> in the C pre-processor to break the build.
>> STATIC_ASSERT() would be a better way to do this.
>> I would also remove unused externs from the builds.
>>
>> /**
>>  Verifies the storage size of a given data type.
>>
>>  This macro generates a divide by zero error or a zero size array 
>> declaration in
>>  the preprocessor if the size is incorrect.  These are declared as "extern" 
>> so
>>  the space for these

[edk2-devel] [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

2019-08-14 Thread Zhang, Shenglei

Initialize PageMapLevel5Entry at the beginning of the function.

This commit will fix a GCC 4.8.5 build failure introduced by commit
b3527dedc3951f061c5a73cb4fb2b0f95f47e08b.

OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to fix
the build failure completely.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Hao A Wu 
Signed-off-by: Shenglei Zhang 
---
v2: Add comments to state why set initialize to NULL.

 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index 2389f3eb485b..2f1038b1e67e 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -652,6 +652,11 @@ CreateIdentityMappingPageTables (
   UINT64AddressEncMask;
   IA32_CR4  Cr4;
 
+  //
+  // set PageMapLevel5Entry to suppress incorrect compiler/analyzer warnigns
+  //
+  PageMapLevel5Entry = NULL;
+
   //
   // Make sure AddressEncMask is contained to smallest supported address field
   //
-- 
2.18.0.windows.1


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

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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

2019-08-14 Thread Donald Kuo

Hi Liming,

As we plan to add new TimerLib to use CPUID Leaf 0x15 (CPU XTAL clock 
frequency) to calculate TSC to resolve performance value unreliable concern.

As the code review had got approved and planning into 201908 stable tag. Please 
help to review whether any concern for 201908 stable tag.

Thanks,
Donald

> -Original Message-
> From: Dong, Eric
> Sent: Thursday, August 15, 2019 10:46 AM
> To: devel@edk2.groups.io; Kuo, Donald 
> Cc: Ni, Ray ; Zeng, Star ; Chan,
> Amy ; Chaganty, Rangasai V
> 
> Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by
> using CPUID(0x15) TSC leaf
> 
> Reviewed-by: Eric Dong 
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Donald Kuo
> > Sent: Tuesday, August 13, 2019 6:53 PM
> > To: devel@edk2.groups.io
> > Cc: Ni, Ray ; Zeng, Star ;
> > Dong, Eric ; Chan, Amy ;
> > Chaganty, Rangasai V 
> > Subject: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by
> > using
> > CPUID(0x15) TSC leaf
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1909
> >
> > Cc: Ray Ni 
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Cc: Amy Chan 
> > Cc: Rangasai V Chaganty 
> > Signed-off-by: Donald Kuo 
> > ---
> >  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c   |  41 +++
> >  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf |  35 +++
> > UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni |  17 ++
> >  UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c   | 274
> > +
> >  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c|  81 ++
> >  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf  |  37 +++
> > UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni  |  17 ++
> >  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c|  58 +
> >  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf  |  36 +++
> > UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni  |  17 ++
> >  UefiCpuPkg/UefiCpuPkg.dec  |   8 +
> >  UefiCpuPkg/UefiCpuPkg.dsc  |   3 +
> >  12 files changed, 624 insertions(+)
> >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> >  create mode 100644
> UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> >  create mode 100644
> UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
> >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c
> >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
> >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf
> >  create mode 100644
> UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni
> >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c
> >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf
> >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni
> >
> > diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > new file mode 100644
> > index 00..6ddf917bad
> > --- /dev/null
> > +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > @@ -0,0 +1,41 @@
> > +/** @file
> > +  CPUID Leaf 0x15 for Core Crystal Clock frequency instance as Base
> > +Timer
> > Library.
> > +
> > +  Copyright (c) 2019 Intel Corporation. All rights reserved.
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +
> > +**/
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/**
> > +  CPUID Leaf 0x15 for Core Crystal Clock Frequency.
> > +
> > +  The TSC counting frequency is determined by using CPUID leaf 0x15.
> > Frequency in MHz = Core XTAL frequency * EBX/EAX.
> > +  In newer flavors of the CPU, core xtal frequency is returned in ECX
> > + or 0 if
> > not supported.
> > +  @return The number of TSC counts per second.
> > +
> > +**/
> > +UINT64
> > +CpuidCoreClockCalculateTscFrequency (
> > +  VOID
> > +  );
> > +
> > +/**
> > +  Internal function to retrieves the 64-bit frequency in Hz.
> > +
> > +  Internal function to retrieves the 64-bit frequency in Hz.
> > +
> > +  @return The frequency in Hz.
> > +
> > +**/
> > +UINT64
> > +InternalGetPerformanceCounterFrequency (
> > +  VOID
> > +  )
> > +{
> > +  return CpuidCoreClockCalculateTscFrequency (); }
> > +
> > diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> > b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> > new file mode 100644
> > index 00..fd93adc5f1
> > --- /dev/null
> > +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> > @@ -0,0 +1,35 @@
> > +## @file
> > +#  Base CPU Timer Library
> > +#
> > +#  Provides basic timer support using CPUID Leaf 0x15 XTAL frequency.
> > +The performance #  counter features are provided by the processors
> > +time
> > stamp counter.
> > +#
> > +#  Copyright (c) 2019, Intel Corporation. All rights reserved. #
> > +SPDX-License-Identifier: BSD-2-Clause-Patent # ##
> > +
> > +[Defines]
> > +  INF_VERSION= 0x00010005
> > +  BASE_NAME  =

[edk2-devel] [edk2-platforms: PATCH v2 10/10] Marvell/Drivers: SmbiosPlatformDxe: Use more generic board name

2019-08-14 Thread Marcin Wojtas

SmbiosPlatformDxe is used both by Armada 7k8k and CN913x platforms.
Replace board name placeholder in order to avoid confusion.

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
index 08f4fa7..cdacd90 100644
--- a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
+++ b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
@@ -102,7 +102,7 @@ STATIC SMBIOS_TABLE_TYPE1 mArmadaDefaultType1 = {
 
 STATIC CHAR8 CONST *mArmadaDefaultType1Strings[] = {
   "Marvell\0",/* Manufacturer */
-  "Armada 7k/8k Family Board  \0",/* Product Name placeholder*/
+  "Marvell Development Board  \0",/* Product Name placeholder*/
   "Revision unknown   \0",/* Version placeholder */
   "   \0",/* 32 character buffer */
   NULL
@@ -130,7 +130,7 @@ STATIC SMBIOS_TABLE_TYPE2 mArmadaDefaultType2 = {
 
 STATIC CHAR8 CONST *mArmadaDefaultType2Strings[] = {
   "Marvell\0",/* Manufacturer */
-  "Armada 7k/8k Family Board  \0",/* Product Name placeholder*/
+  "Marvell Development Board  \0",/* Product Name placeholder*/
   "Revision unknown   \0",/* Version placeholder */
   "Serial Not Set \0",/* Serial */
   "Base of Chassis\0",/* Board location */
-- 
2.7.4


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

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

[edk2-devel] [edk2-platforms: PATCH v2 02/10] Marvell/Cn9130Db: Add ACPI tables

2019-08-14 Thread Marcin Wojtas

This patch adds ACPI tables and necessary headers,
which are common for Cn913x SoCs and the CN9130 development board
(variant A). Wiring up of support will be done in the follow-up
commits.

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf   |  56 
 Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h|  37 +++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Pcie.h|  20 ++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/IcuInterrupts.h |  36 +++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Dsdt.asl  | 324 

 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Mcfg.aslc |  41 +++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Fadt.aslc   |  80 +
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Gtdt.aslc   |  58 
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Madt.aslc   | 135 
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc   | 210 +
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc   |  49 +++
 11 files changed, 1046 insertions(+)
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Pcie.h
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/IcuInterrupts.h
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Dsdt.asl
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Mcfg.aslc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Fadt.aslc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Gtdt.aslc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Madt.aslc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc

diff --git a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf 
b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf
new file mode 100644
index 000..191a747
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf
@@ -0,0 +1,56 @@
+## @file
+#  Component description file for PlatformAcpiTables module.
+#
+#  ACPI table data and ASL sources required to boot the platform.
+#
+#  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+#  Copyright (C) 2019, Marvell International Ltd. and its affiliates.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001B
+  BASE_NAME  = PlatformAcpiTables
+  FILE_GUID  = 7E374E25-8E01-4FEE-87F2-390C23C606CD
+  MODULE_TYPE= USER_DEFINED
+  VERSION_STRING = 1.0
+
+[Sources]
+  Cn913xDbA/Dsdt.asl
+  Cn913xDbA/Mcfg.aslc
+  Fadt.aslc
+  Gtdt.aslc
+  Madt.aslc
+  Pptt.aslc
+  Spcr.aslc
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  Silicon/Marvell/Marvell.dec
+
+[FixedPcd]
+  gArmPlatformTokenSpaceGuid.PcdCoreCount
+
+  gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum
+  gArmTokenSpaceGuid.PcdArmArchTimerIntrNum
+  gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum
+  gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum
+
+  gArmTokenSpaceGuid.PcdGenericWatchdogControlBase
+  gArmTokenSpaceGuid.PcdGenericWatchdogEl2IntrNum
+  gArmTokenSpaceGuid.PcdGenericWatchdogRefreshBase
+
+  gArmTokenSpaceGuid.PcdGicDistributorBase
+  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
+
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase
+
+[BuildOptions]
+  *_*_*_ASLCC_FLAGS = -DCN9130
diff --git a/Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h 
b/Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h
new file mode 100644
index 000..b5fd397
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h
@@ -0,0 +1,37 @@
+/** @file
+
+  Multiple APIC Description Table (MADT)
+
+  Copyright (c) 2017, Linaro Ltd. All rights reserved.
+  Copyright (C) 2019, Marvell International Ltd. and its affiliates.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+#define ACPI_OEM_ID_ARRAY{'M','V','E','B','U',' '}
+#define ACPI_OEM_REVISION0
+#define ACPI_CREATOR_ID  SIGNATURE_32('L','N','R','O')
+#define ACPI_CREATOR_REVISION0
+
+#if defined(CN9130)
+#define ACPI_OEM_TABLE_IDSIGNATURE_64('C','N','9','1','3','0',' ',' ')
+#endif
+
+/**
+ * A macro to initialize the common header part of EFI ACPI tables
+ * as defined by EFI_ACPI_DESCRIPTION_HEADER structure.
+ **/
+#define __ACPI_HEADER(sign, type, rev) {\
+  sign,   /* UINT32  Signature */   \
+  sizeof (type),  /* UINT32  Length */  \
+  rev,/* UINT8   Revision */\
+  0,  /* UINT8   Checksum */\
+

[edk2-devel] [edk2-platforms: PATCH v2 06/10] Marvell/Library: MppLib: Allow to configure more Xenon PHYs

2019-08-14 Thread Marcin Wojtas

Hitherto MppLib code assumed that there could be only two
Xenon SdMmc controllers' PHYs. Remove this limitation, so that to
support CN913x SoCs, which may have up to 4 of such interfaces.

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Library/MppLib/MppLib.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Silicon/Marvell/Library/MppLib/MppLib.c 
b/Silicon/Marvell/Library/MppLib/MppLib.c
index 40d9077..f20668d 100644
--- a/Silicon/Marvell/Library/MppLib/MppLib.c
+++ b/Silicon/Marvell/Library/MppLib/MppLib.c
@@ -139,11 +139,9 @@ SetSdMmcPhyMpp (
   case 0:
 Offset = SD_MMC_PHY_AP_MPP_OFFSET;
 break;
-  case 1:
+  default:
 Offset = SD_MMC_PHY_CP0_MPP_OFFSET;
 break;
-  default:
-return;
   }
 
   /*
-- 
2.7.4


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

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

[edk2-devel] [edk2-platforms: PATCH v2 08/10] Marvell/Cn9131Db: Introduce board support

2019-08-14 Thread Marcin Wojtas

This patch introduces all necessary components required
for building EDK2 firmware for CN9131-DB setup A.

In order to build this variant, '-D CN9131' flag should be added.
Otherwise the default (CN9130) will be compiled.

Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc   | 72 
++
 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc   |  7 
++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA.inf | 57 

 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9131DbA.inf | 22 
+
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h |  2 
+
 Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h  |  2 
+
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c | 29 
++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl| 98 

 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi| 26 
+++---
 9 files changed, 303 insertions(+), 12 deletions(-)
 create mode 100644 Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA.inf
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9131DbA.inf
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl

diff --git a/Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc 
b/Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc
new file mode 100644
index 000..7235b9f
--- /dev/null
+++ b/Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc
@@ -0,0 +1,72 @@
+## @file
+#  Component description file for the CN9131 Development Board (variant A)
+#
+#  Copyright (c) 2019 Marvell International Ltd.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+
+[PcdsFixedAtBuild.common]
+  # CP115 count
+  gMarvellTokenSpaceGuid.PcdMaxCpCount|2
+
+  # MPP
+  gMarvellTokenSpaceGuid.PcdMppChipCount|3
+
+  # CP115 #1 MPP
+  gMarvellTokenSpaceGuid.PcdChip2MppReverseFlag|FALSE
+  gMarvellTokenSpaceGuid.PcdChip2MppBaseAddress|0xF444
+  gMarvellTokenSpaceGuid.PcdChip2MppPinCount|64
+  gMarvellTokenSpaceGuid.PcdChip2MppSel0|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel1|{ 0x0, 0x0, 0x0, 0x3, 0x3, 0x3, 0x3, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel2|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x9, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel3|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x7, 0x7, 
0x2, 0x2, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel4|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel5|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel6|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+
+  # ComPhy
+  gMarvellTokenSpaceGuid.PcdComPhyDevices|{ 0x1, 0x1 }
+  # ComPhy1
+  # 0: PCIE0 5 Gbps
+  # 1: PCIE0 5 Gbps
+  # 2: UNCONNECTED
+  # 3: USB3_HOST15 Gbps
+  # 4: SFI   10.31 Gbps
+  # 5: SATA1 5 Gbps
+  gMarvellTokenSpaceGuid.PcdChip1ComPhyTypes|{ $(CP_PCIE0), $(CP_PCIE0), 
$(CP_UNCONNECTED), $(CP_USB3_HOST1), $(CP_SFI), $(CP_SATA1)}
+  gMarvellTokenSpaceGuid.PcdChip1ComPhySpeeds|{ $(CP_5G), $(CP_5G), 
$(CP_DEFAULT), $(CP_5G), $(CP_10_3125G), $(CP_5G) }
+
+  # UtmiPhy
+  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1, 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdUtmiPortType|{ $(UTMI_USB_HOST0), 
$(UTMI_USB_HOST1), $(UTMI_USB_HOST0), $(UTMI_USB_HOST1) }
+
+  # MDIO
+  gMarvellTokenSpaceGuid.PcdMdioControllersEnabled|{ 0x1, 0x0 }
+
+  # PHY
+  gMarvellTokenSpaceGuid.PcdPhy2MdioController|{ 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPhyDeviceIds|{ 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPhySmiAddresses|{ 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPhyStartupAutoneg|FALSE
+
+  # NET
+  gMarvellTokenSpaceGuid.PcdPp2GopIndexes|{ 0x0, 0x2, 0x3, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2InterfaceAlwaysUp|{ 0x0, 0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2InterfaceSpeed|{ $(PHY_SPEED_1), 
$(PHY_SPEED_1000), $(PHY_SPEED_1000), $(PHY_SPEED_1) }
+  gMarvellTokenSpaceGuid.PcdPp2PhyConnectionTypes|{ $(PHY_SFI), $(PHY_RGMII), 
$(PHY_RGMII), $(PHY_SFI) }
+  gMarvellTokenSpaceGuid.PcdPp2PhyIndexes|{ 0xFF, 0x0, 0x1, 0xFF }
+  gMarvellTokenSpaceGuid.PcdPp2Port2Controller|{ 0x0, 0x0, 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPp2PortIds|{ 0x0, 0x1, 0x2, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2Controllers|{ 0x1, 0x1 }
+
+  # NonDiscoverableDevices
+  gMarvellTokenSpaceGuid.PcdPciEXhci|{ 0x1, 0x1, 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPciEAhci|{ 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPciESdhci|{ 0x1, 0x1 }
diff --git

[edk2-devel] [edk2-platforms: PATCH v2 04/10] Marvell/Cn9130Db: Introduce board support

2019-08-14 Thread Marcin Wojtas

This patch introduces all necessary components required
for building EDK2 firmware for CN9130-DB setup A.
Because the board is modular and can be extended to support
also CN9131 and CN9132 SoC variants, extract common part into
.dsc.inc file, which will be included by them.

Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc | 
107 +++
 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc |  
46 +++
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf |  
29 
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf |  
37 +
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h   |  
19 +++
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.c   | 
126 +
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c   | 
144 
 Platform/Marvell/Cn913xDb/Cn913xDbA.fdf.inc |  
18 +++
 8 files changed, 526 insertions(+)
 create mode 100644 Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc
 create mode 100644 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc
 create mode 100644 
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf
 create mode 100644 
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
 create mode 100644 
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h
 create mode 100644 
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.c
 create mode 100644 
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c
 create mode 100644 Platform/Marvell/Cn913xDb/Cn913xDbA.fdf.inc

diff --git a/Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc 
b/Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc
new file mode 100644
index 000..33fb7cc
--- /dev/null
+++ b/Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc
@@ -0,0 +1,107 @@
+## @file
+#  Component description file for the CN9130 Development Board (variant A)
+#
+#  Copyright (c) 2019 Marvell International Ltd.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+
+[PcdsFixedAtBuild.common]
+  # CP115 count
+  gMarvellTokenSpaceGuid.PcdMaxCpCount|1
+
+  # MPP
+  gMarvellTokenSpaceGuid.PcdMppChipCount|2
+
+  # APN807 MPP
+  gMarvellTokenSpaceGuid.PcdChip0MppReverseFlag|FALSE
+  gMarvellTokenSpaceGuid.PcdChip0MppBaseAddress|0xF06F4000
+  gMarvellTokenSpaceGuid.PcdChip0MppPinCount|20
+  gMarvellTokenSpaceGuid.PcdChip0MppSel0|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 
0x1, 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdChip0MppSel1|{ 0x1, 0x3, 0x1, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x3 }
+
+  # CP115 #0 MPP
+  gMarvellTokenSpaceGuid.PcdChip1MppReverseFlag|FALSE
+  gMarvellTokenSpaceGuid.PcdChip1MppBaseAddress|0xF244
+  gMarvellTokenSpaceGuid.PcdChip1MppPinCount|64
+  gMarvellTokenSpaceGuid.PcdChip1MppSel0|{ 0x3, 0x3, 0x3, 0x3, 0x3, 0x3, 0x3, 
0x3, 0x3, 0x3 }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel1|{ 0x3, 0x3, 0x0, 0x3, 0x3, 0x3, 0x3, 
0x1, 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel2|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 
0x1, 0x3, 0x9 }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel3|{ 0x9, 0x3, 0x7, 0x6, 0x7, 0x2, 0x2, 
0x2, 0x2, 0x1 }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel4|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 
0x1, 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel5|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0xE, 
0xE, 0xE, 0xE }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel6|{ 0xE, 0xE, 0xE, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+
+  # I2C
+  gMarvellTokenSpaceGuid.PcdI2cSlaveAddresses|{ 0x21 }
+  gMarvellTokenSpaceGuid.PcdI2cSlaveBuses|{ 0x0 }
+  gMarvellTokenSpaceGuid.PcdI2cControllersEnabled|{ 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdI2cClockFrequency|25000
+  gMarvellTokenSpaceGuid.PcdI2cBaudRate|10
+
+  # SPI
+  gMarvellTokenSpaceGuid.PcdSpiRegBase|0xF2700680
+  gMarvellTokenSpaceGuid.PcdSpiMaxFrequency|1000
+  gMarvellTokenSpaceGuid.PcdSpiClockFrequency|2
+
+  gMarvellTokenSpaceGuid.PcdSpiFlashMode|3
+  gMarvellTokenSpaceGuid.PcdSpiFlashCs|0
+
+  # ComPhy
+  gMarvellTokenSpaceGuid.PcdComPhyDevices|{ 0x1 }
+  # ComPhy0
+  # 0: PCIE0 5 Gbps
+  # 1: PCIE0 5 Gbps
+  # 2: PCIE0 5 Gbps
+  # 3: PCIE0 5 Gbps
+  # 4: SFI   10.31 Gbps
+  # 5: SATA1 5 Gbps
+  gMarvellTokenSpaceGuid.PcdChip0ComPhyTypes|{ $(CP_PCIE0), $(CP_PCIE0), 
$(CP_PCIE0), $(CP_PCIE0), $(CP_SFI), $(CP_SATA1)}
+  gMarvellTokenSpaceGuid.PcdChip0ComPhySpeeds|{ $(CP_5G), $(CP_5G), $(CP_5G), 
$(CP_5G), $(CP_10_3125G), $(CP_5G) }
+
+  # UtmiPhy
+  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdUtmiPortType|{ $(UTMI_USB_HOST0),

Re: [edk2-devel] [PATCH 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

2019-08-14 Thread Wu, Hao A

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, August 15, 2019 8:26 AM
> To: devel@edk2.groups.io; ler...@redhat.com; Zhang, Shenglei
> Cc: Bi, Dandan; Wu, Hao A
> Subject: RE: [edk2-devel] [PATCH 1/1] MdeModulePkg/DxeIplPeim: Initialize
> pointer PageMapLevel5Entry
> 
> Shenglei:
>   The change is good. I agree to add comments for this change purpose like BZ
> https://bugzilla.tianocore.org/show_bug.cgi?id=607


Hello Shenglei,

Could you help to send out a V2 patch to address Laszlo's comments.
Thanks in advance.

Best Regards,
Hao Wu


> 
>   With this change, Reviewed-by: Liming Gao .
> 
> Thanks
> Liming
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> > Sent: Thursday, August 15, 2019 1:12 AM
> > To: devel@edk2.groups.io; Zhang, Shenglei 
> > Cc: Bi, Dandan ; Gao, Liming
> ; Wu, Hao A 
> > Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg/DxeIplPeim:
> Initialize pointer PageMapLevel5Entry
> >
> > On 08/14/19 09:37, Zhang, Shenglei wrote:
> > > Initialize PageMapLevel5Entry at the beginning of the function.
> > >
> > > This commit will fix a GCC 4.8.5 build failure introduced by commit
> > > b3527dedc3951f061c5a73cb4fb2b0f95f47e08b.
> > >
> > > OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
> > > The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to
> fix
> > > the build failure completely.
> > >
> > > Cc: Dandan Bi 
> > > Cc: Liming Gao 
> > > Cc: Hao A Wu 
> > > Signed-off-by: Shenglei Zhang 
> > > ---
> > >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > > index 2389f3eb485b..aae80536ac3d 100644
> > > --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > > +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > > @@ -652,6 +652,8 @@ CreateIdentityMappingPageTables (
> > >UINT64AddressEncMask;
> > >IA32_CR4  Cr4;
> > >
> > > +  PageMapLevel5Entry = NULL;
> > > +
> > >//
> > >// Make sure AddressEncMask is contained to smallest supported
> address field
> > >//
> > >
> >
> > If you are convinced that we need this assignment *only* for suppressing
> > an invalid compiler warning, then please add a comment about it:
> >
> >   //
> >   // set PageMapLevel5Entry to suppress incorrect compiler/analyzer
> >   // warnings
> >   //
> >
> > Related documentation BZ:
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=607
> >
> > ... Just a suggestion from my side; I defer to the MdeModulePkg
> maintainers.
> >
> > Thanks
> > Laszlo
> >
> > 


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

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

[edk2-devel] [edk2-non-osi][PATCH V2 0/2] Add CoffeelakeSiliconBinPkg

2019-08-14 Thread Kubacki, Michael A

Adds binaries needed for Coffee Lake and Whiskey Lake.

V2 changes:
* Corrected repository name in subject to edk2-non-osi

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 

Michael Kubacki (2):
  CoffeelakeSiliconBinPkg: Add package contents
  edk2-non-osi: Add CoffeelakeSiliconBinPkg maintainers

 Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/MicrocodeUpdates.inf   
   |  21 ++
 Maintainers.txt
   |   5 +
 
Silicon/Intel/CoffeelakeSiliconBinPkg/ChipsetInit/CnlPchLpChipsetInitTable_Dx.bin
 | Bin 0 -> 4620 bytes
 Silicon/Intel/CoffeelakeSiliconBinPkg/Contributions.txt
   | 218 
 Silicon/Intel/CoffeelakeSiliconBinPkg/License.txt  
   |  30 +++
 Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/IntelMicrocodeLicense.txt  
   |  37 
 Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/m90806EC_00AA.mcb  
   | Bin 0 -> 98304 bytes
 Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/mC0806EA_009E.mcb  
   | Bin 0 -> 98304 bytes
 Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/mD0806EB_00A4.mcb  
   | Bin 0 -> 99328 bytes
 9 files changed, 311 insertions(+)
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/MicrocodeUpdates.inf
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/ChipsetInit/CnlPchLpChipsetInitTable_Dx.bin
 create mode 100644 Silicon/Intel/CoffeelakeSiliconBinPkg/Contributions.txt
 create mode 100644 Silicon/Intel/CoffeelakeSiliconBinPkg/License.txt
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/IntelMicrocodeLicense.txt
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/m90806EC_00AA.mcb
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/mC0806EA_009E.mcb
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/mD0806EB_00A4.mcb

-- 
2.16.2.windows.1


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

View/Reply Online (#45679): https://edk2.groups.io/g/devel/message/45679
Mute This Topic: https://groups.io/mt/32883413/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] MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

2019-08-14 Thread Liming Gao

Shenglei:
  The change is good. I agree to add comments for this change purpose like BZ 
https://bugzilla.tianocore.org/show_bug.cgi?id=607

  With this change, Reviewed-by: Liming Gao .

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Laszlo 
> Ersek
> Sent: Thursday, August 15, 2019 1:12 AM
> To: devel@edk2.groups.io; Zhang, Shenglei 
> Cc: Bi, Dandan ; Gao, Liming ; Wu, 
> Hao A 
> Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg/DxeIplPeim: Initialize 
> pointer PageMapLevel5Entry
> 
> On 08/14/19 09:37, Zhang, Shenglei wrote:
> > Initialize PageMapLevel5Entry at the beginning of the function.
> >
> > This commit will fix a GCC 4.8.5 build failure introduced by commit
> > b3527dedc3951f061c5a73cb4fb2b0f95f47e08b.
> >
> > OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
> > The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to fix
> > the build failure completely.
> >
> > Cc: Dandan Bi 
> > Cc: Liming Gao 
> > Cc: Hao A Wu 
> > Signed-off-by: Shenglei Zhang 
> > ---
> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
> > b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > index 2389f3eb485b..aae80536ac3d 100644
> > --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > @@ -652,6 +652,8 @@ CreateIdentityMappingPageTables (
> >UINT64AddressEncMask;
> >IA32_CR4  Cr4;
> >
> > +  PageMapLevel5Entry = NULL;
> > +
> >//
> >// Make sure AddressEncMask is contained to smallest supported address 
> > field
> >//
> >
> 
> If you are convinced that we need this assignment *only* for suppressing
> an invalid compiler warning, then please add a comment about it:
> 
>   //
>   // set PageMapLevel5Entry to suppress incorrect compiler/analyzer
>   // warnings
>   //
> 
> Related documentation BZ:
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=607
> 
> ... Just a suggestion from my side; I defer to the MdeModulePkg maintainers.
> 
> Thanks
> Laszlo
> 
> 


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

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

Re: [edk2-devel][Patch] MdeModulePkg/DxeCapsuleLibFmp: Improve comparisons in CapsuleOnDisk.c

2019-08-14 Thread Liming Gao

Reviewed-by: Liming Gao 

> -Original Message-
> From: Xu, Wei6
> Sent: Tuesday, August 13, 2019 6:54 PM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A ; Gao, Liming 
> Subject: [edk2-devel][Patch] MdeModulePkg/DxeCapsuleLibFmp: Improve 
> comparisons in CapsuleOnDisk.c
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2028
> 
> Non-Boolean comparisons should use a compare operator
> (==, !=, >, < >=, <=).
> 
> Cc: Hao A Wu 
> Cc: Liming Gao 
> Signed-off-by: Wei6 Xu 
> ---
>  MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c 
> b/MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
> index 3193ca8f4d..4c32c6cdcf 100644
> --- a/MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
> +++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/CapsuleOnDisk.c
> @@ -125,11 +125,11 @@ UpperCaseString (
>IN CHAR16 *Str
>)
>  {
>CHAR16  *Cptr;
> 
> -  for (Cptr = Str; *Cptr; Cptr++) {
> +  for (Cptr = Str; *Cptr != L'\0'; Cptr++) {
>  if (L'a' <= *Cptr && *Cptr <= L'z') {
>*Cptr = *Cptr - L'a' + L'A';
>  }
>}
> 
> --
> 2.16.2.windows.1


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

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

Re: [edk2-devel][Patch] MdeModulePkg/CapsuleApp: Improve comparisons in CapsuleOnDisk.c

2019-08-14 Thread Liming Gao

Reviewed-by: Liming Gao 

> -Original Message-
> From: Xu, Wei6
> Sent: Tuesday, August 13, 2019 6:53 PM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A ; Gao, Liming 
> Subject: [edk2-devel][Patch] MdeModulePkg/CapsuleApp: Improve comparisons in 
> CapsuleOnDisk.c
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2028
> 
> Non-Boolean comparisons should use a compare operator
> (==, !=, >, < >=, <=).
> 
> Cc: Hao A Wu 
> Cc: Liming Gao 
> Signed-off-by: Wei6 Xu 
> ---
>  MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c 
> b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> index 382efa9aa0..b161d1a981 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> @@ -742,11 +742,11 @@ IsCapsuleOnDiskSupported (
>);
>if (EFI_ERROR (Status)) {
>  return FALSE;
>}
> 
> -  if (OsIndicationsSupported & 
> EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED) {
> +  if ((OsIndicationsSupported & 
> EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED) != 0) {
>  return TRUE;
>}
> 
>return FALSE;
>  }
> --
> 2.16.2.windows.1


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

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

[edk2-devel] [Patch v3 6/6] UefiCpuPkg/CpuCommonFeaturesLib: Use new macros.

2019-08-14 Thread Dong, Eric

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

Below code is current implementation:
  if (MsrRegister[ProcessorNumber].Bits.Lock == 0) {
CPU_REGISTER_TABLE_WRITE_FIELD (
  ProcessorNumber,
  Msr,
  MSR_IA32_FEATURE_CONTROL,
  MSR_IA32_FEATURE_CONTROL_REGISTER,
  Bits.Lock,
  1
);
  }

1. In first normal boot, the Bits.Lock is 0, 1 will be added
   into the register table and then will set to the MSR.
2. Trig warm reboot, MSR value preserves. After normal boot phase,
   the Bits.Lock is 1, so it will not be added into the register
   table during the warm reboot phase.
3. Trig S3 then resume, the Bits.Lock change to 0 and Bits.Lock is
   not added in register table, so it's still 0 after resume. This
   is not an expect behavior. The expect value is the value should
   always 1 after booting or resuming from S3.

The root cause for this issue is
1. driver bases on current value to insert the "set value action" to
   the register table.
2. Some MSRs may reserve their value during warm reboot.

The solution for this issue is using new added macros for the MSRs which
preserve value during warm reboot.

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Acked-by: Laszlo Ersek 
---
 .../CpuCommonFeaturesLib/CpuCommonFeatures.h  |  15 --
 .../CpuCommonFeaturesLib.c|   8 +-
 .../CpuCommonFeaturesLib/FeatureControl.c | 141 ++
 .../CpuCommonFeaturesLib/MachineCheck.c   |  23 ++-
 4 files changed, 58 insertions(+), 129 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
index 25d0174727..b2390e6c39 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeatures.h
@@ -848,21 +848,6 @@ X2ApicInitialize (
   IN BOOLEAN   State
   );
 
-/**
-  Prepares for the data used by CPU feature detection and initialization.
-
-  @param[in]  NumberOfProcessors  The number of CPUs in the platform.
-
-  @return  Pointer to a buffer of CPU related configuration data.
-
-  @note This service could be called by BSP only.
-**/
-VOID *
-EFIAPI
-FeatureControlGetConfigData (
-  IN UINTN   NumberOfProcessors
-  );
-
 /**
   Prepares for the data used by CPU feature detection and initialization.
 
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c
index fd43b8d662..f0dd3a3b43 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.c
@@ -91,7 +91,7 @@ CpuCommonFeaturesLibConstructor (
   if (IsCpuFeatureSupported (CPU_FEATURE_LOCK_FEATURE_CONTROL_REGISTER)) {
 Status = RegisterCpuFeature (
"Lock Feature Control Register",
-   FeatureControlGetConfigData,
+   NULL,
LockFeatureControlRegisterSupport,
LockFeatureControlRegisterInitialize,
CPU_FEATURE_LOCK_FEATURE_CONTROL_REGISTER,
@@ -102,7 +102,7 @@ CpuCommonFeaturesLibConstructor (
   if (IsCpuFeatureSupported (CPU_FEATURE_SMX)) {
 Status = RegisterCpuFeature (
"SMX",
-   FeatureControlGetConfigData,
+   NULL,
SmxSupport,
SmxInitialize,
CPU_FEATURE_SMX,
@@ -114,7 +114,7 @@ CpuCommonFeaturesLibConstructor (
   if (IsCpuFeatureSupported (CPU_FEATURE_VMX)) {
 Status = RegisterCpuFeature (
"VMX",
-   FeatureControlGetConfigData,
+   NULL,
VmxSupport,
VmxInitialize,
CPU_FEATURE_VMX,
@@ -214,7 +214,7 @@ CpuCommonFeaturesLibConstructor (
   if (IsCpuFeatureSupported (CPU_FEATURE_LMCE)) {
 Status = RegisterCpuFeature (
"LMCE",
-   FeatureControlGetConfigData,
+   NULL,
LmceSupport,
LmceInitialize,
CPU_FEATURE_LMCE,
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
index 3712ef1e5c..6679df8ba4 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/FeatureControl.c
@@ -8,28 +8,6 @@
 
 #include "CpuCommonFeatures.h"
 
-/**
-  Prepares for the data used by CPU feature detection and initialization.
-
-  @param[in]  NumberOfProcessors  The number of CPUs in the platform.
-
-  @return  Pointer to a buffer of CPU related configuration data.
-
-  @note This service could be called by BSP only.
-**/
-VOID *
-EFIAPI
-FeatureControlGetConfigData (
-  IN UINTN   NumberOfProcessors
-  )
-{
-  VOID  *ConfigData;
-
-  ConfigData = AllocateZeroPool (sizeof (MSR_IA32_FEATURE_CONTROL_REGISTER) * 
NumberOfProcessors);
-  ASSERT (ConfigData != NULL);

[edk2-devel] [Patch v3 0/6] Add "test then write" mechanism

2019-08-14 Thread Dong, Eric

v3 changes:
1. Avoid changing exist API CpuRegisterTableWrite, add new API 
CpuRegisterTableTestThenWrite which align new adds macros.
Only 1/6 patch been changed in v3.

V2 changes:
1. Split CR read/write action in to one discrete patch 2. Keep the old logic 
which continue the process if error found.

Below code is current implementation:
  if (MsrRegister[ProcessorNumber].Bits.Lock == 0) {
CPU_REGISTER_TABLE_WRITE_FIELD (
  ProcessorNumber,
  Msr,
  MSR_IA32_FEATURE_CONTROL,
  MSR_IA32_FEATURE_CONTROL_REGISTER,
  Bits.Lock,
  1
);
  }

With below steps, the Bits.Lock bit will lose its value:
1. Trig normal boot, the Bits.Lock is 0. 1 will be added
   into the register table and then will set to the MSR.
2. Trig warm reboot, MSR value preserves. After normal boot phase,
   the Bits.Lock is 1, so it will not be added into the register
   table during the warm reboot phase.
3. Trig S3 then resume, the Bits.Lock change to 0 and Bits.Lock is
   not added in register table during normal boot phase. so it's
   still 0 after resume. 
This is not an expect behavior. The expect result is the value should always 1 
after booting or resuming from S3.

The root cause for this issue is
1. driver bases on current value to insert the "set value action" to
   the register table.
2. Some MSRs may reserve their value during warm reboot. So the insert
   action may be skip after warm reboot.

The solution for this issue is:
1. Always add "Test then Set" action for above referred MSRs.
2. Detect current value before set new value. Only set new value when
   current value not same as new value.

Cc: Ray Ni 
Cc: Laszlo Ersek 


Eric Dong (6):
  UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.
  UefiCpuPkg/PiSmmCpuDxeSmm: Combine CR read/write action.
  UefiCpuPkg/PiSmmCpuDxeSmm: Supports test then write new value logic.
  UefiCpuPkg/RegisterCpuFeaturesLib: Combine CR read/write action.
  UefiCpuPkg/RegisterCpuFeaturesLib: Supports test then write new value
logic.
  UefiCpuPkg/CpuCommonFeaturesLib: Use new macros.

 UefiCpuPkg/Include/AcpiCpuData.h  |   1 +
 .../Include/Library/RegisterCpuFeaturesLib.h  |  91 +++
 .../CpuCommonFeaturesLib/CpuCommonFeatures.h  |  15 --
 .../CpuCommonFeaturesLib.c|   8 +-
 .../CpuCommonFeaturesLib/FeatureControl.c | 141 ++
 .../CpuCommonFeaturesLib/MachineCheck.c   |  23 ++-
 .../CpuFeaturesInitialize.c   | 139 +++--
 .../RegisterCpuFeaturesLib.c  |  45 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 133 +++--
 9 files changed, 375 insertions(+), 221 deletions(-)

-- 
2.21.0.windows.1


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

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

[edk2-devel] [Patch v3 4/6] UefiCpuPkg/RegisterCpuFeaturesLib: Combine CR read/write action.

2019-08-14 Thread Dong, Eric

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Acked-by: Laszlo Ersek 
---
 .../CpuFeaturesInitialize.c   | 110 ++
 1 file changed, 63 insertions(+), 47 deletions(-)

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index fb0535edd6..63bc50a55f 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -744,6 +744,58 @@ LibWaitForSemaphore (
  ) != Value);
 }
 
+/**
+  Read / write CR value.
+
+  @param[in]  CrIndex The CR index which need to read/write.
+  @param[in]  ReadRead or write. TRUE is read.
+  @param[in,out]  CrValue CR value.
+
+  @retvalEFI_SUCCESS means read/write success, else return EFI_UNSUPPORTED.
+**/
+UINTN
+ReadWriteCr (
+  IN UINT32   CrIndex,
+  IN BOOLEAN  Read,
+  IN OUT UINTN*CrValue
+  )
+{
+  switch (CrIndex) {
+  case 0:
+if (Read) {
+  *CrValue = AsmReadCr0 ();
+} else {
+  AsmWriteCr0 (*CrValue);
+}
+break;
+  case 2:
+if (Read) {
+  *CrValue = AsmReadCr2 ();
+} else {
+  AsmWriteCr2 (*CrValue);
+}
+break;
+  case 3:
+if (Read) {
+  *CrValue = AsmReadCr3 ();
+} else {
+  AsmWriteCr3 (*CrValue);
+}
+break;
+  case 4:
+if (Read) {
+  *CrValue = AsmReadCr4 ();
+} else {
+  AsmWriteCr4 (*CrValue);
+}
+break;
+  default:
+return EFI_UNSUPPORTED;;
+  }
+
+  return EFI_SUCCESS;
+}
+
 /**
   Initialize the CPU registers from a register table.
 
@@ -773,6 +825,7 @@ ProgramProcessorRegister (
   UINTN ProcessorIndex;
   UINTN ValidThreadCount;
   UINT32*ValidCoreCountPerPackage;
+  EFI_STATUSStatus;
 
   //
   // Traverse Register Table of this logical processor
@@ -791,55 +844,18 @@ ProgramProcessorRegister (
 // The specified register is Control Register
 //
 case ControlRegister:
-  switch (RegisterTableEntry->Index) {
-  case 0:
-Value = AsmReadCr0 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  RegisterTableEntry->Value
-  );
-AsmWriteCr0 (Value);
-break;
-  case 2:
-Value = AsmReadCr2 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  RegisterTableEntry->Value
-  );
-AsmWriteCr2 (Value);
-break;
-  case 3:
-Value = AsmReadCr3 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  RegisterTableEntry->Value
-  );
-AsmWriteCr3 (Value);
-break;
-  case 4:
-Value = AsmReadCr4 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  RegisterTableEntry->Value
-  );
-AsmWriteCr4 (Value);
-break;
-  case 8:
-//
-//  Do we need to support CR8?
-//
-break;
-  default:
+  Status = ReadWriteCr (RegisterTableEntry->Index, TRUE, );
+  if (EFI_ERROR (Status)) {
 break;
   }
+
+  Value = (UINTN) BitFieldWrite64 (
+Value,
+RegisterTableEntry->ValidBitStart,
+RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
+RegisterTableEntry->Value
+);
+  ReadWriteCr (RegisterTableEntry->Index, FALSE, );
   break;
 //
 // The specified register is Model Specific Register
-- 
2.21.0.windows.1


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

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

[edk2-devel] [Patch v3 2/6] UefiCpuPkg/PiSmmCpuDxeSmm: Combine CR read/write action.

2019-08-14 Thread Dong, Eric

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Reviewed-by: Laszlo Ersek 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 104 ++
 1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
index d8c6b19ead..627a3b87ac 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
@@ -159,6 +159,58 @@ S3WaitForSemaphore (
  ) != Value);
 }
 
+/**
+  Read / write CR value.
+
+  @param[in]  CrIndex The CR index which need to read/write.
+  @param[in]  ReadRead or write. TRUE is read.
+  @param[in,out]  CrValue CR value.
+
+  @retvalEFI_SUCCESS means read/write success, else return EFI_UNSUPPORTED.
+**/
+UINTN
+ReadWriteCr (
+  IN UINT32   CrIndex,
+  IN BOOLEAN  Read,
+  IN OUT UINTN*CrValue
+  )
+{
+  switch (CrIndex) {
+  case 0:
+if (Read) {
+  *CrValue = AsmReadCr0 ();
+} else {
+  AsmWriteCr0 (*CrValue);
+}
+break;
+  case 2:
+if (Read) {
+  *CrValue = AsmReadCr2 ();
+} else {
+  AsmWriteCr2 (*CrValue);
+}
+break;
+  case 3:
+if (Read) {
+  *CrValue = AsmReadCr3 ();
+} else {
+  AsmWriteCr3 (*CrValue);
+}
+break;
+  case 4:
+if (Read) {
+  *CrValue = AsmReadCr4 ();
+} else {
+  AsmWriteCr4 (*CrValue);
+}
+break;
+  default:
+return EFI_UNSUPPORTED;;
+  }
+
+  return EFI_SUCCESS;
+}
+
 /**
   Initialize the CPU registers from a register table.
 
@@ -188,6 +240,7 @@ ProgramProcessorRegister (
   UINTN ProcessorIndex;
   UINTN ValidThreadCount;
   UINT32*ValidCoreCountPerPackage;
+  EFI_STATUSStatus;
 
   //
   // Traverse Register Table of this logical processor
@@ -206,50 +259,17 @@ ProgramProcessorRegister (
 // The specified register is Control Register
 //
 case ControlRegister:
-  switch (RegisterTableEntry->Index) {
-  case 0:
-Value = AsmReadCr0 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  (UINTN) RegisterTableEntry->Value
-  );
-AsmWriteCr0 (Value);
-break;
-  case 2:
-Value = AsmReadCr2 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  (UINTN) RegisterTableEntry->Value
-  );
-AsmWriteCr2 (Value);
-break;
-  case 3:
-Value = AsmReadCr3 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  (UINTN) RegisterTableEntry->Value
-  );
-AsmWriteCr3 (Value);
-break;
-  case 4:
-Value = AsmReadCr4 ();
-Value = (UINTN) BitFieldWrite64 (
-  Value,
-  RegisterTableEntry->ValidBitStart,
-  RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
-  (UINTN) RegisterTableEntry->Value
-  );
-AsmWriteCr4 (Value);
-break;
-  default:
+  Status = ReadWriteCr (RegisterTableEntry->Index, TRUE, );
+  if (EFI_ERROR (Status)) {
 break;
   }
+  Value = (UINTN) BitFieldWrite64 (
+Value,
+RegisterTableEntry->ValidBitStart,
+RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1,
+RegisterTableEntry->Value
+);
+  ReadWriteCr (RegisterTableEntry->Index, FALSE, );
   break;
 //
 // The specified register is Model Specific Register
-- 
2.21.0.windows.1


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

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

[edk2-devel] [edk2-platforms: PATCH v2 01/10] Marvell/Armada7k8k: Fix 32-bit compilation

2019-08-14 Thread Marcin Wojtas

It turned out, that the recently added features broke
ARM compilation. Fix all issues:
* Use SIGNATURE_32 only
* Do not shift address by 32-bit in ICU
* Limit memory for ARM build to 1GB and stop using non-existent PCD

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h   |  2 
+-
 Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h   |  2 
+-
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c  |  4 

 Silicon/Marvell/Library/IcuLib/IcuLib.c  |  7 
++-
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S | 11 
---
 5 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h 
b/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h
index a6f551b..7ecb4e1 100644
--- a/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h
+++ b/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h
@@ -18,7 +18,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 #include 
 
-#define MV_BOARD_DESC_SIGNATURE SIGNATURE_64 ('M', 'V', 'B', 'R', 'D', 'D', 
'S', 'C')
+#define MV_BOARD_DESC_SIGNATURE SIGNATURE_32 ('B', 'D', 'S', 'C')
 
 typedef struct {
   MARVELL_BOARD_DESC_PROTOCOL   BoardDescProtocol;
diff --git a/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h 
b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
index 1cb006a..600d5db 100644
--- a/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
+++ b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
@@ -23,7 +23,7 @@
 
 #include 
 
-#define MV_GPIO_SIGNATURESIGNATURE_64 ('M', 'V','_','G', 'P', 
'I','O',' ')
+#define MV_GPIO_SIGNATURESIGNATURE_32 ('G', 'P', 'I', 'O')
 
 // Marvell MV_GPIO Controller Registers
 #define MV_GPIO_DATA_OUT_REG (0x0)
diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
index a735fe5..5ff6bb1 100644
--- a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
+++ b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
@@ -36,6 +36,7 @@ GetDramSize (
   IN OUT UINT64 *MemSize
   )
 {
+#if defined(MDE_CPU_AARCH64)
   ARM_SMC_ARGS SmcRegs = {0};
   EFI_STATUS Status;
 
@@ -48,6 +49,9 @@ GetDramSize (
   ArmCallSmc ();
 
   *MemSize = SmcRegs.Arg0;
+#else
+  *MemSize = FixedPcdGet64 (PcdSystemMemorySize);
+#endif
 
   return EFI_SUCCESS;
 }
diff --git a/Silicon/Marvell/Library/IcuLib/IcuLib.c 
b/Silicon/Marvell/Library/IcuLib/IcuLib.c
index 343c21b..422388c 100644
--- a/Silicon/Marvell/Library/IcuLib/IcuLib.c
+++ b/Silicon/Marvell/Library/IcuLib/IcuLib.c
@@ -185,10 +185,15 @@ IcuConfigure (
   for (Index = 0; Index < IcuGroupMax; Index++, Msi++) {
 MmioWrite32 (IcuBase + ICU_SET_SPI_AL (Msi->Group),
   Msi->SetSpiAddr & 0x);
-MmioWrite32 (IcuBase + ICU_SET_SPI_AH (Msi->Group), Msi->SetSpiAddr >> 32);
 MmioWrite32 (IcuBase + ICU_CLR_SPI_AL (Msi->Group),
   Msi->ClrSpiAddr & 0x);
+#if defined(MDE_CPU_AARCH64)
+MmioWrite32 (IcuBase + ICU_SET_SPI_AH (Msi->Group), Msi->SetSpiAddr >> 32);
 MmioWrite32 (IcuBase + ICU_CLR_SPI_AH (Msi->Group), Msi->ClrSpiAddr >> 32);
+#else
+MmioWrite32 (IcuBase + ICU_SET_SPI_AH (Msi->Group), 0);
+MmioWrite32 (IcuBase + ICU_CLR_SPI_AH (Msi->Group), 0);
+#endif
   }
 
   /* Mask all ICU interrupts */
diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S
index 4416163..db43b0f 100644
--- a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S
+++ b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S
@@ -28,17 +28,6 @@ ASM_FUNC(ArmPlatformPeiBootAction)
   .err  PcdSystemMemoryBase should be 0x0 on this platform!
   .endif
 
-  .if   FixedPcdGet64 (PcdSystemMemorySize) > FixedPcdGet32 
(PcdDramRemapTarget)
-//
-// Use the low range for UEFI itself. The remaining memory will be mapped
-// and added to the GCD map later.
-//
-ADRL  (r0, mSystemMemoryEnd)
-MOV32 (r2, FixedPcdGet32 (PcdDramRemapTarget) - 1)
-mov   r3, #0
-strd  r2, r3, [r0]
-  .endif
-
   bxlr
 
 //UINTN
-- 
2.7.4


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

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

[edk2-devel] [edk2-platforms: PATCH v2 09/10] Marvell/Cn9132Db: Introduce board support

2019-08-14 Thread Marcin Wojtas

This patch introduces all necessary components required
for building EDK2 firmware for CN9132-DB setup A. Note
the ACPI is not yet available for this variant, due to
the current ICU (CP1xx interrupt controller) support
implementation.

In order to build this variant, '-D CN9132' flag should be added.
Otherwise the default (CN9130) will be compiled.

Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc   |  
72 +++
 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc   |  
15 ++-
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf   |  
29 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9132DbA.inf |  
22 
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h |   
4 +
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.c | 
135 
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c |  
42 ++
 Platform/Marvell/Cn913xDb/Cn913xDbA.fdf.inc   |   
2 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts   |   
6 -
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi|  
20 ++-
 10 files changed, 333 insertions(+), 14 deletions(-)
 create mode 100644 Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc
 create mode 100644 
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9132DbA.inf
 create mode 100644 
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.c

diff --git a/Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc 
b/Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc
new file mode 100644
index 000..a0b90fa
--- /dev/null
+++ b/Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc
@@ -0,0 +1,72 @@
+## @file
+#  Component description file for the CN9132 Development Board (variant A)
+#
+#  Copyright (c) 2019 Marvell International Ltd.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+
+[PcdsFixedAtBuild.common]
+  # CP115 count
+  gMarvellTokenSpaceGuid.PcdMaxCpCount|3
+
+  # MPP
+  gMarvellTokenSpaceGuid.PcdMppChipCount|4
+
+  # CP115 #2 MPP
+  gMarvellTokenSpaceGuid.PcdChip3MppReverseFlag|FALSE
+  gMarvellTokenSpaceGuid.PcdChip3MppBaseAddress|0xF644
+  gMarvellTokenSpaceGuid.PcdChip3MppPinCount|64
+  gMarvellTokenSpaceGuid.PcdChip3MppSel0|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel1|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel2|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x9, 0x9, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel3|{ 0x0, 0x0, 0x8, 0x0, 0x8, 0x0, 0x0, 
0x2, 0x2, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel4|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel5|{ 0x0, 0x0, 0x0, 0x0, 0xA, 0xB, 0xE, 
0xE, 0xE, 0xE }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel6|{ 0xE, 0xE, 0xE, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+
+  # ComPhy
+  gMarvellTokenSpaceGuid.PcdComPhyDevices|{ 0x1, 0x1, 0x1 }
+  # ComPhy1
+  # 0: PCIE0 5 Gbps
+  # 1: PCIE0 5 Gbps
+  # 2: SATA0 5 Gbps
+  # 3: USB3_HOST15 Gbps
+  # 4: SFI   10.31 Gbps
+  # 5: PCIE2 5 Gbps
+  gMarvellTokenSpaceGuid.PcdChip2ComPhyTypes|{ $(CP_PCIE0), $(CP_PCIE0), 
$(CP_SATA0), $(CP_USB3_HOST1), $(CP_SFI), $(CP_PCIE2)}
+  gMarvellTokenSpaceGuid.PcdChip2ComPhySpeeds|{ $(CP_5G), $(CP_5G), $(CP_5G), 
$(CP_5G), $(CP_10_3125G), $(CP_5G) }
+
+  # UtmiPhy
+  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1, 0x0, 0x1, 0x1, 
0x1 }
+  gMarvellTokenSpaceGuid.PcdUtmiPortType|{ $(UTMI_USB_HOST0), 
$(UTMI_USB_HOST1), $(UTMI_USB_HOST0), $(UTMI_USB_HOST1), $(UTMI_USB_HOST0), 
$(UTMI_USB_HOST1) }
+
+  # MDIO
+  gMarvellTokenSpaceGuid.PcdMdioControllersEnabled|{ 0x1, 0x0 }
+
+  # PHY
+  gMarvellTokenSpaceGuid.PcdPhy2MdioController|{ 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPhyDeviceIds|{ 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPhySmiAddresses|{ 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPhyStartupAutoneg|FALSE
+
+  # NET
+  gMarvellTokenSpaceGuid.PcdPp2GopIndexes|{ 0x0, 0x2, 0x3, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2InterfaceAlwaysUp|{ 0x0, 0x0, 0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2InterfaceSpeed|{ $(PHY_SPEED_1), 
$(PHY_SPEED_1000), $(PHY_SPEED_1000), $(PHY_SPEED_1), $(PHY_SPEED_1) }
+  gMarvellTokenSpaceGuid.PcdPp2PhyConnectionTypes|{ $(PHY_SFI), $(PHY_RGMII), 
$(PHY_RGMII), $(PHY_SFI), $(PHY_SFI) }
+  gMarvellTokenSpaceGuid.PcdPp2PhyIndexes|{ 0xFF, 0x0, 0x1, 0xFF, 0xFF }
+  gMarvellTokenSpaceGuid.PcdPp2Port2Controller|{ 0x0, 0x0, 0x0, 0x1, 0x2 }
+

[edk2-devel] [edk2-platforms: PATCH v2 05/10] Marvell/Library: ArmadaSoCDescLib: Extend Xenon information

2019-08-14 Thread Marcin Wojtas

Hitherto SoC description library code assumed that there could
be only two Xenon SdMmc controller instances in the SoC. Remove this
limitation, so that to support CN913x SoCs, which may have up to 4 of
such interfaces.

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h 
|  5 +--
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c 
| 34 +---
 2 files changed, 25 insertions(+), 14 deletions(-)

diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
index 0296d43..265b4f4 100644
--- 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
+++ 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
@@ -90,8 +90,9 @@
 //
 // Platform description of SDMMC controllers
 //
-#define MV_SOC_MAX_SDMMC_COUNT   2
-#define MV_SOC_SDMMC_BASE(Index) ((Index) == 0 ? 0xF06E : 
0xF278)
+#define MV_SOC_SDMMC_PER_CP_COUNT1
+#define MV_SOC_AP80X_SDMMC_BASE  0xF06E
+#define MV_SOC_CP_SDMMC_BASE(Cp) (MV_SOC_CP_BASE (Cp) + 0x78)
 
 //
 // Platform description of UTMI PHY's
diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
index 5947601..3ffd57e 100644
--- 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
+++ 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
@@ -349,26 +349,36 @@ EFI_STATUS
 EFIAPI
 ArmadaSoCDescSdMmcGet (
   IN OUT MV_SOC_SDMMC_DESC  **SdMmcDesc,
-  IN OUT UINTN   *DescCount
+  IN OUT UINTN   *Count
   )
 {
-  MV_SOC_SDMMC_DESC *Desc;
-  UINTN Index;
+  MV_SOC_SDMMC_DESC *SdMmc;
+  UINTN CpCount, CpIndex;
 
-  Desc = AllocateZeroPool (MV_SOC_MAX_SDMMC_COUNT * sizeof 
(MV_SOC_SDMMC_DESC));
-  if (Desc == NULL) {
+  CpCount = FixedPcdGet8 (PcdMaxCpCount);
+
+  *Count = CpCount * MV_SOC_SDMMC_PER_CP_COUNT + MV_SOC_AP806_COUNT;
+  SdMmc = AllocateZeroPool (*Count * sizeof (MV_SOC_SDMMC_DESC));
+  if (SdMmc == NULL) {
 DEBUG ((DEBUG_ERROR, "%a: Cannot allocate memory\n", __FUNCTION__));
 return EFI_OUT_OF_RESOURCES;
   }
 
-  for (Index = 0; Index < MV_SOC_MAX_SDMMC_COUNT; Index++) {
-Desc[Index].SdMmcBaseAddress = MV_SOC_SDMMC_BASE (Index);
-Desc[Index].SdMmcMemSize = SIZE_1KB;
-Desc[Index].SdMmcDmaType = NonDiscoverableDeviceDmaTypeCoherent;
-  }
+  *SdMmcDesc = SdMmc;
+
+  /* AP80x controller */
+  SdMmc->SdMmcBaseAddress = MV_SOC_AP80X_SDMMC_BASE;
+  SdMmc->SdMmcMemSize = SIZE_1KB;
+  SdMmc->SdMmcDmaType = NonDiscoverableDeviceDmaTypeCoherent;
+  SdMmc++;
 
-  *SdMmcDesc = Desc;
-  *DescCount = MV_SOC_MAX_SDMMC_COUNT;
+  /* CP11x controllers */
+  for (CpIndex = 0; CpIndex < CpCount; CpIndex++) {
+SdMmc->SdMmcBaseAddress = MV_SOC_CP_SDMMC_BASE (CpIndex);
+SdMmc->SdMmcMemSize = SIZE_1KB;
+SdMmc->SdMmcDmaType = NonDiscoverableDeviceDmaTypeCoherent;
+SdMmc++;
+  }
 
   return EFI_SUCCESS;
 }
-- 
2.7.4


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

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

[edk2-devel] [edk2-platforms: PATCH v2 03/10] Marvell/Cn9130Db: Add DeviceTree

2019-08-14 Thread Marcin Wojtas

This patch adds device tree sources which are common for Cn913x SoCs
and the CN9130 development board (variant A). Wiring up of support
will be done in the follow-up commits.

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf  |  22 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi |  43 ++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi  | 264 ++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-common.dtsi |  10 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-cp110.dtsi  | 552 

 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db-A.dts| 185 +++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db.dtsi | 168 ++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130.dtsi| 126 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db-A.dts|  29 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi | 173 ++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts|  76 +++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi | 151 ++
 12 files changed, 1799 insertions(+)
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf
 create mode 100644 
Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-common.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-cp110.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db-A.dts
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db-A.dts
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi

diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf
new file mode 100644
index 000..091a5b4
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf
@@ -0,0 +1,22 @@
+## @file
+#
+#  Device tree description of the Marvell CN9130-DB-A platform
+#
+#  Copyright (c) 2019, Marvell International Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001B
+  BASE_NAME  = Cn9130DbADeviceTree
+  FILE_GUID  = 25462CDA-221F-47DF-AC1D-259CFAA4E326 # 
gDtPlatformDefaultDtbFileGuid
+  MODULE_TYPE= USER_DEFINED
+  VERSION_STRING = 1.0
+
+[Sources]
+  cn9130-db-A.dts
+
+[Packages]
+  MdePkg/MdePkg.dec
diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi
new file mode 100644
index 000..bae0ed9
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * Device Tree file for Marvell Armada AP806.
+ */
+
+#include "armada-ap806.dtsi"
+
+/ {
+model = "Marvell Armada AP806 Quad";
+compatible = "marvell,armada-ap806-quad", "marvell,armada-ap806";
+
+cpus {
+#address-cells = <1>;
+#size-cells = <0>;
+
+cpu@0 {
+device_type = "cpu";
+compatible = "arm,cortex-a72", "arm,armv8";
+reg = <0x000>;
+enable-method = "psci";
+};
+cpu@1 {
+device_type = "cpu";
+compatible = "arm,cortex-a72", "arm,armv8";
+reg = <0x001>;
+enable-method = "psci";
+};
+cpu@100 {
+device_type = "cpu";
+compatible = "arm,cortex-a72", "arm,armv8";
+reg = <0x100>;
+enable-method = "psci";
+};
+cpu@101 {
+device_type = "cpu";
+compatible = "arm,cortex-a72", "arm,armv8";
+reg = <0x101>;
+enable-method = "psci";
+};
+};
+};
diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi
new file mode 100644
index 000..66124bf
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * Device Tree file for Marvell Armada

[edk2-devel] [edk2-platforms: PATCH v2 07/10] Marvell/Library: IcuLib: Fix debug information

2019-08-14 Thread Marcin Wojtas

In case the number of CP11x components exceeded the maximum
of currently supported, the user is informed with the information.
It turned out that the print arguments were incorrect - fix it.

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Library/IcuLib/IcuLib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Silicon/Marvell/Library/IcuLib/IcuLib.c 
b/Silicon/Marvell/Library/IcuLib/IcuLib.c
index 422388c..8d99409 100644
--- a/Silicon/Marvell/Library/IcuLib/IcuLib.c
+++ b/Silicon/Marvell/Library/IcuLib/IcuLib.c
@@ -285,8 +285,8 @@ ArmadaIcuInitialize (
   if (CpCount > ICU_MAX_SUPPORTED_UNITS) {
 DEBUG ((DEBUG_ERROR,
   "%a: Default ICU to GIC mapping is available for maximum %d CP110 units",
-  ICU_MAX_SUPPORTED_UNITS,
-  __FUNCTION__));
+  __FUNCTION__,
+  ICU_MAX_SUPPORTED_UNITS));
 CpCount = ICU_MAX_SUPPORTED_UNITS;
   }
 
-- 
2.7.4


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

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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

2019-08-14 Thread Liming Gao

Donald:
  This change is a new feature. Now, it is not in edk2 feature planning list. 
If you want to catch it into 201908 stable tag, please get approve from 
Stewards first. I have cc this mail to all Stewards. 

  For this patch, I have one minor comment. You add one PCD in UefiCpuPkg DEC. 
Please also add this PCD into UefiCpuPkg.uni. 

Thanks
Liming
> -Original Message-
> From: Kuo, Donald
> Sent: Thursday, August 15, 2019 11:02 AM
> To: Dong, Eric ; devel@edk2.groups.io; Gao, Liming 
> 
> Cc: Ni, Ray ; Zeng, Star ; Chan, Amy 
> ; Chaganty, Rangasai V
> ; Lai, Luke ; Li, Kevin Y 
> 
> Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by 
> using CPUID(0x15) TSC leaf
> 
> Hi Liming,
> 
> As we plan to add new TimerLib to use CPUID Leaf 0x15 (CPU XTAL clock 
> frequency) to calculate TSC to resolve performance value
> unreliable concern.
> 
> As the code review had got approved and planning into 201908 stable tag. 
> Please help to review whether any concern for 201908 stable
> tag.
> 
> Thanks,
> Donald
> 
> > -Original Message-
> > From: Dong, Eric
> > Sent: Thursday, August 15, 2019 10:46 AM
> > To: devel@edk2.groups.io; Kuo, Donald 
> > Cc: Ni, Ray ; Zeng, Star ; Chan,
> > Amy ; Chaganty, Rangasai V
> > 
> > Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by
> > using CPUID(0x15) TSC leaf
> >
> > Reviewed-by: Eric Dong 
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > > Donald Kuo
> > > Sent: Tuesday, August 13, 2019 6:53 PM
> > > To: devel@edk2.groups.io
> > > Cc: Ni, Ray ; Zeng, Star ;
> > > Dong, Eric ; Chan, Amy ;
> > > Chaganty, Rangasai V 
> > > Subject: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by
> > > using
> > > CPUID(0x15) TSC leaf
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1909
> > >
> > > Cc: Ray Ni 
> > > Cc: Star Zeng 
> > > Cc: Eric Dong 
> > > Cc: Amy Chan 
> > > Cc: Rangasai V Chaganty 
> > > Signed-off-by: Donald Kuo 
> > > ---
> > >  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c   |  41 +++
> > >  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf |  35 +++
> > > UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni |  17 ++
> > >  UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c   | 274
> > > +
> > >  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c|  81 ++
> > >  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf  |  37 +++
> > > UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni  |  17 ++
> > >  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c|  58 +
> > >  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf  |  36 +++
> > > UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni  |  17 ++
> > >  UefiCpuPkg/UefiCpuPkg.dec  |   8 +
> > >  UefiCpuPkg/UefiCpuPkg.dsc  |   3 +
> > >  12 files changed, 624 insertions(+)
> > >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > >  create mode 100644
> > UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> > >  create mode 100644
> > UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
> > >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c
> > >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
> > >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf
> > >  create mode 100644
> > UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni
> > >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c
> > >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf
> > >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni
> > >
> > > diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > > b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > > new file mode 100644
> > > index 00..6ddf917bad
> > > --- /dev/null
> > > +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > > @@ -0,0 +1,41 @@
> > > +/** @file
> > > +  CPUID Leaf 0x15 for Core Crystal Clock frequency instance as Base
> > > +Timer
> > > Library.
> > > +
> > > +  Copyright (c) 2019 Intel Corporation. All rights reserved.
> > > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > > +
> > > +**/
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +/**
> > > +  CPUID Leaf 0x15 for Core Crystal Clock Frequency.
> > > +
> > > +  The TSC counting frequency is determined by using CPUID leaf 0x15.
> > > Frequency in MHz = Core XTAL frequency * EBX/EAX.
> > > +  In newer flavors of the CPU, core xtal frequency is returned in ECX
> > > + or 0 if
> > > not supported.
> > > +  @return The number of TSC counts per second.
> > > +
> > > +**/
> > > +UINT64
> > > +CpuidCoreClockCalculateTscFrequency (
> > > +  VOID
> > > +  );
> > > +
> > > +/**
> > > +  Internal function to retrieves the 64-bit frequency in Hz.
> > > +
> > > +  Internal function to retrieves the 64-bit frequency in Hz.
> > > +
> > > +  @return

[edk2-devel] [Patch v3 1/6] UefiCpuPkg/RegisterCpuFeaturesLib: Add "Test Then Write" Macros.

2019-08-14 Thread Dong, Eric

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

Add below new micros which test the current value before write
the new value. Only write new value when current value not
same as new value.
  CPU_REGISTER_TABLE_TEST_THEN_WRITE32
  CPU_REGISTER_TABLE_TEST_THEN_WRITE64
  CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD

Also add below API:
  CpuRegisterTableTestThenWrite

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Cc: Star Zeng 
---
 UefiCpuPkg/Include/AcpiCpuData.h  |  1 +
 .../Include/Library/RegisterCpuFeaturesLib.h  | 91 +++
 .../RegisterCpuFeaturesLib.c  | 45 -
 3 files changed, 134 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/Include/AcpiCpuData.h b/UefiCpuPkg/Include/AcpiCpuData.h
index b963a2f592..472a1a8070 100644
--- a/UefiCpuPkg/Include/AcpiCpuData.h
+++ b/UefiCpuPkg/Include/AcpiCpuData.h
@@ -81,6 +81,7 @@ typedef struct {
   UINT16 Reserved;  // offset 10 - 11
   UINT32 HighIndex; // offset 12-15, only valid for 
MemoryMapped
   UINT64 Value; // offset 16-23
+  UINT8  TestThenWrite;   // 0ffset 24
 } CPU_REGISTER_TABLE_ENTRY;
 
 //
diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
index e420e7f075..5bd464b32e 100644
--- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
+++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
@@ -348,6 +348,32 @@ CpuRegisterTableWrite (
   IN UINT64  Value
   );
 
+/**
+  Adds an entry in specified register table.
+
+  This function adds an entry in specified register table, with given register 
type,
+  register index, bit section and value.
+
+  Driver will  test the current value before setting new value.
+
+  @param[in]  ProcessorNumber  The index of the CPU to add a register table 
entry
+  @param[in]  RegisterType Type of the register to program
+  @param[in]  IndexIndex of the register to program
+  @param[in]  ValueMaskMask of bits in register to write
+  @param[in]  ValueValue to write
+
+  @note This service could be called by BSP only.
+**/
+VOID
+EFIAPI
+CpuRegisterTableTestThenWrite (
+  IN UINTN   ProcessorNumber,
+  IN REGISTER_TYPE   RegisterType,
+  IN UINT64  Index,
+  IN UINT64  ValueMask,
+  IN UINT64  Value
+  );
+
 /**
   Adds an entry in specified Pre-SMM register table.
 
@@ -390,6 +416,26 @@ PreSmmCpuRegisterTableWrite (
 CpuRegisterTableWrite (ProcessorNumber, RegisterType, Index, MAX_UINT32, 
Value);  \
   } while(FALSE);
 
+/**
+  Adds a 32-bit register write entry in specified register table.
+
+  This macro adds an entry in specified register table, with given register 
type,
+  register index, and value.
+
+  Driver will  test the current value before setting new value.
+
+  @param[in]  ProcessorNumber  The index of the CPU to add a register table 
entry.
+  @param[in]  RegisterType Type of the register to program
+  @param[in]  IndexIndex of the register to program
+  @param[in]  ValueValue to write
+
+  @note This service could be called by BSP only.
+**/
+#define CPU_REGISTER_TABLE_TEST_THEN_WRITE32(ProcessorNumber, RegisterType, 
Index, Value) \
+  do { 
   \
+CpuRegisterTableTestThenWrite (ProcessorNumber, RegisterType, Index, 
MAX_UINT32, Value);  \
+  } while(FALSE);
+
 /**
   Adds a 64-bit register write entry in specified register table.
 
@@ -408,6 +454,26 @@ PreSmmCpuRegisterTableWrite (
 CpuRegisterTableWrite (ProcessorNumber, RegisterType, Index, MAX_UINT64, 
Value);  \
   } while(FALSE);
 
+/**
+  Adds a 64-bit register write entry in specified register table.
+
+  This macro adds an entry in specified register table, with given register 
type,
+  register index, and value.
+
+  Driver will  test the current value before setting new value.
+
+  @param[in]  ProcessorNumber  The index of the CPU to add a register table 
entry.
+  @param[in]  RegisterType Type of the register to program
+  @param[in]  IndexIndex of the register to program
+  @param[in]  ValueValue to write
+
+  @note This service could be called by BSP only.
+**/
+#define CPU_REGISTER_TABLE_TEST_THEN_WRITE64(ProcessorNumber, RegisterType, 
Index, Value) \
+  do { 
   \
+CpuRegisterTableTestThenWrite (ProcessorNumber, RegisterType, Index, 
MAX_UINT64, Value);  \
+  } while(FALSE);
+
 /**
   Adds a bit field write entry in specified register table.
 
@@ -431,6 +497,31 @@ PreSmmCpuRegisterTableWrite (
 CpuRegisterTableWrite (ProcessorNumber, RegisterType, Index, ~ValueMask, 
Value); \
   } while(FALSE);
 
+/**
+  Adds a bit field write entry in specified register table.
+
+

[edk2-devel] [Patch v3 3/6] UefiCpuPkg/PiSmmCpuDxeSmm: Supports test then write new value logic.

2019-08-14 Thread Dong, Eric

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

Supports new logic which test current value before write new value.
Only write new value when current value not same as new value.

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Reviewed-by: Laszlo Ersek 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
index 627a3b87ac..ba5cc0194c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
@@ -241,6 +241,7 @@ ProgramProcessorRegister (
   UINTN ValidThreadCount;
   UINT32*ValidCoreCountPerPackage;
   EFI_STATUSStatus;
+  UINT64CurrentValue;
 
   //
   // Traverse Register Table of this logical processor
@@ -263,6 +264,16 @@ ProgramProcessorRegister (
   if (EFI_ERROR (Status)) {
 break;
   }
+  if (RegisterTableEntry->TestThenWrite) {
+CurrentValue = BitFieldRead64 (
+ Value,
+ RegisterTableEntry->ValidBitStart,
+ RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1
+ );
+if (CurrentValue == RegisterTableEntry->Value) {
+  break;
+}
+  }
   Value = (UINTN) BitFieldWrite64 (
 Value,
 RegisterTableEntry->ValidBitStart,
@@ -275,6 +286,24 @@ ProgramProcessorRegister (
 // The specified register is Model Specific Register
 //
 case Msr:
+  if (RegisterTableEntry->TestThenWrite) {
+Value = (UINTN)AsmReadMsr64 (RegisterTableEntry->Index);
+if (RegisterTableEntry->ValidBitLength >= 64) {
+  if (Value == RegisterTableEntry->Value) {
+break;
+  }
+} else {
+  CurrentValue = BitFieldRead64 (
+   Value,
+   RegisterTableEntry->ValidBitStart,
+   RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1
+   );
+  if (CurrentValue == RegisterTableEntry->Value) {
+break;
+  }
+}
+  }
+
   //
   // If this function is called to restore register setting after INIT 
signal,
   // there is no need to restore MSRs in register table.
-- 
2.21.0.windows.1


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

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

[edk2-devel] [Patch v3 5/6] UefiCpuPkg/RegisterCpuFeaturesLib: Supports test then write new value logic.

2019-08-14 Thread Dong, Eric

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

Supports new logic which test current value before write new value.
Only write new value when current value not same as new value.

Signed-off-by: Eric Dong 
Cc: Ray Ni 
Acked-by: Laszlo Ersek 
---
 .../CpuFeaturesInitialize.c   | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index 63bc50a55f..0a4fcff033 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -826,6 +826,7 @@ ProgramProcessorRegister (
   UINTN ValidThreadCount;
   UINT32*ValidCoreCountPerPackage;
   EFI_STATUSStatus;
+  UINT64CurrentValue;
 
   //
   // Traverse Register Table of this logical processor
@@ -848,7 +849,16 @@ ProgramProcessorRegister (
   if (EFI_ERROR (Status)) {
 break;
   }
-
+  if (RegisterTableEntry->TestThenWrite) {
+CurrentValue = BitFieldRead64 (
+ Value,
+ RegisterTableEntry->ValidBitStart,
+ RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1
+ );
+if (CurrentValue == RegisterTableEntry->Value) {
+  break;
+}
+  }
   Value = (UINTN) BitFieldWrite64 (
 Value,
 RegisterTableEntry->ValidBitStart,
@@ -857,10 +867,29 @@ ProgramProcessorRegister (
 );
   ReadWriteCr (RegisterTableEntry->Index, FALSE, );
   break;
+
 //
 // The specified register is Model Specific Register
 //
 case Msr:
+  if (RegisterTableEntry->TestThenWrite) {
+Value = (UINTN)AsmReadMsr64 (RegisterTableEntry->Index);
+if (RegisterTableEntry->ValidBitLength >= 64) {
+  if (Value == RegisterTableEntry->Value) {
+break;
+  }
+} else {
+  CurrentValue = BitFieldRead64 (
+   Value,
+   RegisterTableEntry->ValidBitStart,
+   RegisterTableEntry->ValidBitStart + 
RegisterTableEntry->ValidBitLength - 1
+   );
+  if (CurrentValue == RegisterTableEntry->Value) {
+break;
+  }
+}
+  }
+
   if (RegisterTableEntry->ValidBitLength >= 64) {
 //
 // If length is not less than 64 bits, then directly write without 
reading
-- 
2.21.0.windows.1


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

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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

2019-08-14 Thread Dong, Eric

Reviewed-by: Eric Dong 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Donald Kuo
> Sent: Tuesday, August 13, 2019 6:53 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Zeng, Star ; Dong, Eric
> ; Chan, Amy ; Chaganty,
> Rangasai V 
> Subject: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using
> CPUID(0x15) TSC leaf
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1909
> 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Amy Chan 
> Cc: Rangasai V Chaganty 
> Signed-off-by: Donald Kuo 
> ---
>  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c   |  41 +++
>  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf |  35 +++
> UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni |  17 ++
>  UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c   | 274
> +
>  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c|  81 ++
>  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf  |  37 +++
> UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni  |  17 ++
>  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c|  58 +
>  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf  |  36 +++
> UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni  |  17 ++
>  UefiCpuPkg/UefiCpuPkg.dec  |   8 +
>  UefiCpuPkg/UefiCpuPkg.dsc  |   3 +
>  12 files changed, 624 insertions(+)
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf
>  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni
> 
> diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> new file mode 100644
> index 00..6ddf917bad
> --- /dev/null
> +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> @@ -0,0 +1,41 @@
> +/** @file
> +  CPUID Leaf 0x15 for Core Crystal Clock frequency instance as Base Timer
> Library.
> +
> +  Copyright (c) 2019 Intel Corporation. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> +  CPUID Leaf 0x15 for Core Crystal Clock Frequency.
> +
> +  The TSC counting frequency is determined by using CPUID leaf 0x15.
> Frequency in MHz = Core XTAL frequency * EBX/EAX.
> +  In newer flavors of the CPU, core xtal frequency is returned in ECX or 0 if
> not supported.
> +  @return The number of TSC counts per second.
> +
> +**/
> +UINT64
> +CpuidCoreClockCalculateTscFrequency (
> +  VOID
> +  );
> +
> +/**
> +  Internal function to retrieves the 64-bit frequency in Hz.
> +
> +  Internal function to retrieves the 64-bit frequency in Hz.
> +
> +  @return The frequency in Hz.
> +
> +**/
> +UINT64
> +InternalGetPerformanceCounterFrequency (
> +  VOID
> +  )
> +{
> +  return CpuidCoreClockCalculateTscFrequency (); }
> +
> diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> new file mode 100644
> index 00..fd93adc5f1
> --- /dev/null
> +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> @@ -0,0 +1,35 @@
> +## @file
> +#  Base CPU Timer Library
> +#
> +#  Provides basic timer support using CPUID Leaf 0x15 XTAL frequency.
> +The performance #  counter features are provided by the processors time
> stamp counter.
> +#
> +#  Copyright (c) 2019, Intel Corporation. All rights reserved. #
> +SPDX-License-Identifier: BSD-2-Clause-Patent # ##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = BaseCpuTimerLib
> +  FILE_GUID  = F10B5B91-D15A-496C-B044-B5235721AA08
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = TimerLib|SEC PEI_CORE PEIM
> +  MODULE_UNI_FILE= BaseCpuTimerLib.uni
> +
> +[Sources]
> +  CpuTimerLib.c
> +  BaseCpuTimerLib.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  UefiCpuPkg/UefiCpuPkg.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  PcdLib
> +  DebugLib
> +
> +[Pcd]
> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ##
> +CONSUMES
> diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
> b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
> new file mode 100644
> index 00..fcf2b0fbcb
> --- /dev/null
> +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
> @@ -0,0 +1,17 @@
> +// /** @file
> +// Base CPU

Re: [edk2-devel] [PATCH v3 0/2] Add edk2 submodule policy

2019-08-14 Thread Wang, Jian J

Pushed at 2556350d1b..5ab96088ae

Regards,
Jian


> -Original Message-
> From: Gao, Liming
> Sent: Thursday, August 15, 2019 8:33 AM
> To: Wang, Jian J ; devel@edk2.groups.io
> Cc: Leif Lindholm ; Kinney, Michael D
> 
> Subject: RE: [PATCH v3 0/2] Add edk2 submodule policy
> 
> Jian:
>   Thanks for your update. The change is good. Reviewed-by: Liming Gao
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, August 14, 2019 4:15 PM
> > To: devel@edk2.groups.io
> > Cc: Leif Lindholm ; Kinney, Michael D
> ; Gao, Liming 
> > Subject: [PATCH v3 0/2] Add edk2 submodule policy
> >
> > >v3 change
> > >  [1/2] a. change wording about submodule per Liming's comment.
> > >b. add more steps to do submodule update per Mike's comment.
> > >c. add commands for update of submodule
> > >  [2/2] no changes.
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1910
> >
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> >
> > Jian J Wang (2):
> >   Readme.md: add submodule policy and clone commands
> >   CryptoPkg/OpensslLib: remove clone commands
> >
> >  .../Library/OpensslLib/OpenSSL-HOWTO.txt  | 18 +
> >  Readme.md | 39 +++
> >  2 files changed, 41 insertions(+), 16 deletions(-)
> >
> > --
> > 2.17.1.windows.2


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

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

[edk2-devel] [edk2-platforms][PATCH V1 0/2] Add CoffeelakeSiliconBinPkg

2019-08-14 Thread Kubacki, Michael A

Adds binaries needed for Coffee Lake and Whiskey Lake.

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 

Michael Kubacki (2):
  CoffeelakeSiliconBinPkg: Add package contents
  edk2-non-osi: Add CoffeelakeSiliconBinPkg maintainers

 Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/MicrocodeUpdates.inf   
   |  21 ++
 Maintainers.txt
   |   5 +
 
Silicon/Intel/CoffeelakeSiliconBinPkg/ChipsetInit/CnlPchLpChipsetInitTable_Dx.bin
 | Bin 0 -> 4620 bytes
 Silicon/Intel/CoffeelakeSiliconBinPkg/Contributions.txt
   | 218 
 Silicon/Intel/CoffeelakeSiliconBinPkg/License.txt  
   |  30 +++
 Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/IntelMicrocodeLicense.txt  
   |  37 
 Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/m90806EC_00AA.mcb  
   | Bin 0 -> 98304 bytes
 Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/mC0806EA_009E.mcb  
   | Bin 0 -> 98304 bytes
 Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/mD0806EB_00A4.mcb  
   | Bin 0 -> 99328 bytes
 9 files changed, 311 insertions(+)
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/MicrocodeUpdates.inf
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/ChipsetInit/CnlPchLpChipsetInitTable_Dx.bin
 create mode 100644 Silicon/Intel/CoffeelakeSiliconBinPkg/Contributions.txt
 create mode 100644 Silicon/Intel/CoffeelakeSiliconBinPkg/License.txt
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/IntelMicrocodeLicense.txt
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/m90806EC_00AA.mcb
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/mC0806EA_009E.mcb
 create mode 100644 
Silicon/Intel/CoffeelakeSiliconBinPkg/Microcode/mD0806EB_00A4.mcb

--
2.16.2.windows.1


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

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

[edk2-devel] [edk2-platforms][PATCH V1 2/2] edk2-non-osi: Add CoffeelakeSiliconBinPkg maintainers

2019-08-14 Thread Kubacki, Michael A

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 
---
 Maintainers.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 9fba131..5759e4c 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -46,6 +46,11 @@ M: Michael Kubacki 
 M: Ankit Sinha 
 M: Nate DeSimone 
 
+Platform/Intel/CoffeelakeSiliconBinPkg
+M: Chasel Chiu 
+M: Michael A Kubacki 
+M: Sai Chaganty 
+
 Silicon/Intel/KabylakeSiliconBinPkg
 M: Chasel Chiu 
 M: Michael A Kubacki 
-- 
2.16.2.windows.1


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

View/Reply Online (#45677): https://edk2.groups.io/g/devel/message/45677
Mute This Topic: https://groups.io/mt/32883237/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 0/2] Add edk2 submodule policy

2019-08-14 Thread Liming Gao

Jian:
  Thanks for your update. The change is good. Reviewed-by: Liming Gao 


> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, August 14, 2019 4:15 PM
> To: devel@edk2.groups.io
> Cc: Leif Lindholm ; Kinney, Michael D 
> ; Gao, Liming 
> Subject: [PATCH v3 0/2] Add edk2 submodule policy
> 
> >v3 change
> >  [1/2] a. change wording about submodule per Liming's comment.
> >b. add more steps to do submodule update per Mike's comment.
> >c. add commands for update of submodule
> >  [2/2] no changes.
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1910
> 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> 
> Jian J Wang (2):
>   Readme.md: add submodule policy and clone commands
>   CryptoPkg/OpensslLib: remove clone commands
> 
>  .../Library/OpensslLib/OpenSSL-HOWTO.txt  | 18 +
>  Readme.md | 39 +++
>  2 files changed, 41 insertions(+), 16 deletions(-)
> 
> --
> 2.17.1.windows.2


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

View/Reply Online (#45643): https://edk2.groups.io/g/devel/message/45643
Mute This Topic: https://groups.io/mt/32861686/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 1/1] MdePkg: Add STATIC_ASSERT macro

2019-08-14 Thread Liming Gao

Vitaly:
  As you know, edk2 201908 stable tag will start soft freeze tomorrow. Dose 
this patch plan to catch this stable tag?
 If yes, please ask the feedback from Tianocore Stewards. I have cc this patch 
to all Stewards.

Thanks
Liming
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Yao, 
Jiewen
Sent: Thursday, August 15, 2019 9:05 AM
To: devel@edk2.groups.io; vit9...@protonmail.com; Kinney, Michael D 

Cc: Laszlo Ersek 
Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

Good input.
I think we should separate the work to convert all EDKII code to use 
STATIC_ASSERT.
We can do that work once we add STATIC_ASSERT.

I recommend:

1)  Step 1: Add STATIS_ASSERT - this patch and this Bugzilla

2)  Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove 
VERIFY_SIZE_OF – the other patch and the other Bugzilla

3)  Step 3: Scan the rest, if there is need. – Another patch and another 
Bugzilla

Thank you
Yao Jiewen

From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Vitaly Cheptosv via Groups.Io
Sent: Thursday, August 15, 2019 12:23 AM
To: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: devel@edk2.groups.io; Laszlo Ersek 
mailto:ler...@redhat.com>>
Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro


Michael, Liming, Laszlo,

Static assertions via _Static_assert are standard C11 functionality, thus any 
at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support the 
second argument with the diagnostic description.

The notation without the message currently is only present in C++, not in C, 
thus the two-argument notation is the only allowed notation for _Static_assert 
for at least C17 (ISO/IEC 9899 2018) and below.

In the bottom of this message I included a quote from C17 for the relevant 
section (6.7.10).

GCC and CLANG (including Xcode) appear to be conforming to the standard for 
this section, and MSVC compiler static_assert extension also supports the 
diagnostic message argument. This is pretty much all we care about.

As for examples, I see little reason to clarify STATIC_ASSERT behaviour outside 
of the standard reference in its description and actual usage in the source 
code, but can do that just fine if you think that it may help somebody.

I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, 
and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. 
This should be fairly costless, as apparently it is only used in Base.h and 
MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in the 
same patch set.

As for select ASSERT usage switching to STATIC_ASSERT, this would also be 
great, as let us be honest, the use of ASSERT in EDK II codebase is very 
questioning. In fact, this was one of the reasons we introduced our own static 
assertions some time ago. However, fixing up all broken assertions is unlikely 
a best place to fit into this patchset, but I can surely add a few examples, in 
case somebody points them out. This will be useful for reference purposes and 
may help the maintainers to get a better idea when static assertions are to be 
used.

Looking forward to hearing your opinions.

Best regards,
Vitaly


6.7.10 Static assertions

Syntax
1 static_assert-declaration:
_Static_assert ( constant-expression , string-literal ) ;

Constraints
2 The constant expression shall compare unequal to 0.

Semantics
3 The constant expression shall be an integer constant expression. If the value 
of the constant expression compares unequal to 0, the declaration has no 
effect. Otherwise, the constraint is violated and the implementation shall 
produce a diagnostic message that includes the text of the string literal, 
except that characters not in the basic source character set are not required 
to appear in the message.

Forward references: diagnostics (7.2).

7.2 Diagnostics 

3 The macro
static_assert
expands to _Static_assert.


> 14 авг. 2019 г., в 18:47, Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>> написал(а):
>
>
> Liming,
>
> I think a good candidate to demonstrate this
> feature are the checks made in MdePkg/Include/Base.h.
> The current implementation forces a divide by 0
> in the C pre-processor to break the build.
> STATIC_ASSERT() would be a better way to do this.
> I would also remove unused externs from the builds.
>
> /**
>  Verifies the storage size of a given data type.
>
>  This macro generates a divide by zero error or a zero size array declaration 
> in
>  the preprocessor if the size is incorrect.  These are declared as "extern" so
>  the space for these arrays will not be in the modules.
>
>  @param  TYPE  The date type to determine the size of.
>  @param  Size  The expected size for the TYPE.
>
> **/
> #define VERIFY_SIZE_OF(TYPE, Size) extern UINT8 
> _VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) ==

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

2019-08-14 Thread Yao, Jiewen

Good input.
I think we should separate the work to convert all EDKII code to use 
STATIC_ASSERT.
We can do that work once we add STATIC_ASSERT.

I recommend:

1)  Step 1: Add STATIS_ASSERT - this patch and this Bugzilla

2)  Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove 
VERIFY_SIZE_OF – the other patch and the other Bugzilla

3)  Step 3: Scan the rest, if there is need. – Another patch and another 
Bugzilla

Thank you
Yao Jiewen

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Vitaly 
Cheptosv via Groups.Io
Sent: Thursday, August 15, 2019 12:23 AM
To: Kinney, Michael D 
Cc: devel@edk2.groups.io; Laszlo Ersek 
Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro


Michael, Liming, Laszlo,

Static assertions via _Static_assert are standard C11 functionality, thus any 
at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support the 
second argument with the diagnostic description.

The notation without the message currently is only present in C++, not in C, 
thus the two-argument notation is the only allowed notation for _Static_assert 
for at least C17 (ISO/IEC 9899 2018) and below.

In the bottom of this message I included a quote from C17 for the relevant 
section (6.7.10).

GCC and CLANG (including Xcode) appear to be conforming to the standard for 
this section, and MSVC compiler static_assert extension also supports the 
diagnostic message argument. This is pretty much all we care about.

As for examples, I see little reason to clarify STATIC_ASSERT behaviour outside 
of the standard reference in its description and actual usage in the source 
code, but can do that just fine if you think that it may help somebody.

I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, 
and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. 
This should be fairly costless, as apparently it is only used in Base.h and 
MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in the 
same patch set.

As for select ASSERT usage switching to STATIC_ASSERT, this would also be 
great, as let us be honest, the use of ASSERT in EDK II codebase is very 
questioning. In fact, this was one of the reasons we introduced our own static 
assertions some time ago. However, fixing up all broken assertions is unlikely 
a best place to fit into this patchset, but I can surely add a few examples, in 
case somebody points them out. This will be useful for reference purposes and 
may help the maintainers to get a better idea when static assertions are to be 
used.

Looking forward to hearing your opinions.

Best regards,
Vitaly


6.7.10 Static assertions

Syntax
1 static_assert-declaration:
_Static_assert ( constant-expression , string-literal ) ;

Constraints
2 The constant expression shall compare unequal to 0.

Semantics
3 The constant expression shall be an integer constant expression. If the value 
of the constant expression compares unequal to 0, the declaration has no 
effect. Otherwise, the constraint is violated and the implementation shall 
produce a diagnostic message that includes the text of the string literal, 
except that characters not in the basic source character set are not required 
to appear in the message.

Forward references: diagnostics (7.2).

7.2 Diagnostics 

3 The macro
static_assert
expands to _Static_assert.


> 14 авг. 2019 г., в 18:47, Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>> написал(а):
>
>
> Liming,
>
> I think a good candidate to demonstrate this
> feature are the checks made in MdePkg/Include/Base.h.
> The current implementation forces a divide by 0
> in the C pre-processor to break the build.
> STATIC_ASSERT() would be a better way to do this.
> I would also remove unused externs from the builds.
>
> /**
>  Verifies the storage size of a given data type.
>
>  This macro generates a divide by zero error or a zero size array declaration 
> in
>  the preprocessor if the size is incorrect.  These are declared as "extern" so
>  the space for these arrays will not be in the modules.
>
>  @param  TYPE  The date type to determine the size of.
>  @param  Size  The expected size for the TYPE.
>
> **/
> #define VERIFY_SIZE_OF(TYPE, Size) extern UINT8 
> _VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))]

>
> //
> // Verify that ProcessorBind.h produced UEFI Data Types that are compliant 
> with
> // Section 2.3.1 of the UEFI 2.3 Specification.
> //
> VERIFY_SIZE_OF (BOOLEAN, 1);
> VERIFY_SIZE_OF (INT8, 1);
> VERIFY_SIZE_OF (UINT8, 1);
> VERIFY_SIZE_OF (INT16, 2);
> VERIFY_SIZE_OF (UINT16, 2);
> VERIFY_SIZE_OF (INT32, 4);
> VERIFY_SIZE_OF (UINT32, 4);
> VERIFY_SIZE_OF (INT64, 8);
> VERIFY_SIZE_OF (UINT64, 8);
> VERIFY_SIZE_OF (CHAR8, 1);
> VERIFY_SIZE_OF (CHAR16, 2);
>
> //
> // The following three enum types are used to verify that the compiler
> // configuration for enum types is compliant with Section 2.3.1 of the
> // UEFI 2.3

Re: [edk2-devel] [PATCH] SecurityPkg/SecurityPkg.uni: Add missing strings for new PCDs

2019-08-14 Thread Zhang, Chao B

Reviewed-by : Chao Zhang 

-Original Message-
From: Wang, Jian J 
Sent: Wednesday, August 14, 2019 5:01 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen ; Zhang, Chao B ; 
Zhang, Shenglei 
Subject: [PATCH] SecurityPkg/SecurityPkg.uni: Add missing strings for new PCDs

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

Cc: Jiewen Yao 
Cc: Chao Zhang 
Cc: Shenglei Zhang 
Signed-off-by: Jian J Wang 
---
 SecurityPkg/SecurityPkg.uni | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/SecurityPkg/SecurityPkg.uni b/SecurityPkg/SecurityPkg.uni index 
9c0c008f9c..14077fbc28 100644
--- a/SecurityPkg/SecurityPkg.uni
+++ b/SecurityPkg/SecurityPkg.uni
@@ -263,3 +263,26 @@

   "0x01 - Do not support IdleByPass.\n"

   "0x02 - Support IdleByPass.\n"

   "0xFF - IdleByPass State is not synced with TPM hardware."
+
+#string 
STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationPass_PROMPT  
#language en-US "Status Code for FV verification pass."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationPass_HELP 
 #language en-US "Progress Code for FV verification result.\n"
+   
 "  (EFI_SOFTWARE_PEI_MODULE | EFI_SUBCLASS_SPECIFIC | 00A).\n"
+
+#string 
STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationFail_PROMPT  
#language en-US "Status Code for FV verification failure."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationFail_HELP 
 #language en-US "Progress Code for FV verification result.\n"
+   
 "  (EFI_SOFTWARE_PEI_MODULE | EFI_SUBCLASS_SPECIFIC | 00B).\n"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipOpalPasswordPrompt_PROMPT  
#language en-US "Skip Opal DXE driver password prompt."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipOpalPasswordPrompt_HELP  
#language en-US "Indicates if Opal DXE driver skip password prompt.\n\n"
+   
   "  TRUE  - Skip password prompt.\n"
+   
   "  FALSE - Does not skip password prompt.\n"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipHddPasswordPrompt_PROMPT  
#language en-US "Skip Hdd Password prompt."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipHddPasswordPrompt_HELP  
#language en-US "Indicates if Hdd Password driver skip password prompt.\n\n"
+   
   "  TRUE  - Skip password prompt.\n"
+   
   "  FALSE - Does not skip password prompt.\n"
+
--
2.17.1.windows.2


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

View/Reply Online (#45649): https://edk2.groups.io/g/devel/message/45649
Mute This Topic: https://groups.io/mt/32861906/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 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

2019-08-14 Thread Liming Gao

Shenglei:

> -Original Message-
> From: Zhang, Shenglei
> Sent: Thursday, August 15, 2019 10:23 AM
> To: devel@edk2.groups.io
> Cc: Bi, Dandan ; Gao, Liming ; Wu, 
> Hao A 
> Subject: [PATCH v2 1/1] MdeModulePkg/DxeIplPeim: Initialize pointer 
> PageMapLevel5Entry
> 
> Initialize PageMapLevel5Entry at the beginning of the function.
> 
> This commit will fix a GCC 4.8.5 build failure introduced by commit
> b3527dedc3951f061c5a73cb4fb2b0f95f47e08b.
> 
> OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
> The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to fix
> the build failure completely.
> 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Cc: Hao A Wu 
> Signed-off-by: Shenglei Zhang 
> ---
> v2: Add comments to state why set initialize to NULL.
> 
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> index 2389f3eb485b..2f1038b1e67e 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> @@ -652,6 +652,11 @@ CreateIdentityMappingPageTables (
>UINT64AddressEncMask;
>IA32_CR4  Cr4;
> 
> +  //
> +  // set PageMapLevel5Entry to suppress incorrect compiler/analyzer warnigns

Please fix the typo warnigns ==> warnings

Thanks
Liming
> +  //
> +  PageMapLevel5Entry = NULL;
> +
>//
>// Make sure AddressEncMask is contained to smallest supported address 
> field
>//
> --
> 2.18.0.windows.1


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

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

[edk2-devel] [edk2-non-osi][PATCH V2 2/2] edk2-non-osi: Add CoffeelakeSiliconBinPkg maintainers

2019-08-14 Thread Kubacki, Michael A

Cc: Sai Chaganty 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 
---
 Maintainers.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 9fba131..5759e4c 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -46,6 +46,11 @@ M: Michael Kubacki 
 M: Ankit Sinha 
 M: Nate DeSimone 
 
+Platform/Intel/CoffeelakeSiliconBinPkg
+M: Chasel Chiu 
+M: Michael A Kubacki 
+M: Sai Chaganty 
+
 Silicon/Intel/KabylakeSiliconBinPkg
 M: Chasel Chiu 
 M: Michael A Kubacki 
-- 
2.16.2.windows.1


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

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

Re: [edk2-devel] [edk2-non-osi][PATCH V2 2/2] edk2-non-osi: Add CoffeelakeSiliconBinPkg maintainers

2019-08-14 Thread Chiu, Chasel



Reviewed-by: Chasel Chiu 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Kubacki, Michael A
> Sent: Thursday, August 15, 2019 12:15 PM
> To: devel@edk2.groups.io
> Cc: Chaganty, Rangasai V ; Chiu, Chasel
> ; Desimone, Nathaniel L
> ; Kinney, Michael D
> 
> Subject: [edk2-devel] [edk2-non-osi][PATCH V2 2/2] edk2-non-osi: Add
> CoffeelakeSiliconBinPkg maintainers
> 
> Cc: Sai Chaganty 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Michael D Kinney 
> Signed-off-by: Michael Kubacki 
> ---
>  Maintainers.txt | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt index 9fba131..5759e4c 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -46,6 +46,11 @@ M: Michael Kubacki 
>  M: Ankit Sinha 
>  M: Nate DeSimone 
> 
> +Platform/Intel/CoffeelakeSiliconBinPkg
> +M: Chasel Chiu 
> +M: Michael A Kubacki 
> +M: Sai Chaganty 
> +
>  Silicon/Intel/KabylakeSiliconBinPkg
>  M: Chasel Chiu 
>  M: Michael A Kubacki 
> --
> 2.16.2.windows.1
> 
> 
> 


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

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

[edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

2019-08-14 Thread Donald Kuo

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

Cc: Ray Ni 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Amy Chan 
Cc: Rangasai V Chaganty 
Signed-off-by: Donald Kuo 
---
 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c   |  41 +++
 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf |  35 +++
 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni |  17 ++
 UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c   | 274 +
 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c|  81 ++
 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf  |  37 +++
 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni  |  17 ++
 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c|  58 +
 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf  |  36 +++
 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni  |  17 ++
 UefiCpuPkg/UefiCpuPkg.dec  |   8 +
 UefiCpuPkg/UefiCpuPkg.dsc  |   3 +
 UefiCpuPkg/UefiCpuPkg.uni  |  10 +
 13 files changed, 634 insertions(+)
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf
 create mode 100644 UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni

diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c 
b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
new file mode 100644
index 00..6ddf917bad
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
@@ -0,0 +1,41 @@
+/** @file
+  CPUID Leaf 0x15 for Core Crystal Clock frequency instance as Base Timer 
Library.
+
+  Copyright (c) 2019 Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+
+/**
+  CPUID Leaf 0x15 for Core Crystal Clock Frequency.
+
+  The TSC counting frequency is determined by using CPUID leaf 0x15. Frequency 
in MHz = Core XTAL frequency * EBX/EAX.
+  In newer flavors of the CPU, core xtal frequency is returned in ECX or 0 if 
not supported.
+  @return The number of TSC counts per second.
+
+**/
+UINT64
+CpuidCoreClockCalculateTscFrequency (
+  VOID
+  );
+
+/**
+  Internal function to retrieves the 64-bit frequency in Hz.
+
+  Internal function to retrieves the 64-bit frequency in Hz.
+
+  @return The frequency in Hz.
+
+**/
+UINT64
+InternalGetPerformanceCounterFrequency (
+  VOID
+  )
+{
+  return CpuidCoreClockCalculateTscFrequency ();
+}
+
diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf 
b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
new file mode 100644
index 00..fd93adc5f1
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
@@ -0,0 +1,35 @@
+## @file
+#  Base CPU Timer Library
+#
+#  Provides basic timer support using CPUID Leaf 0x15 XTAL frequency. The 
performance
+#  counter features are provided by the processors time stamp counter.
+#
+#  Copyright (c) 2019, Intel Corporation. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = BaseCpuTimerLib
+  FILE_GUID  = F10B5B91-D15A-496C-B044-B5235721AA08
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = TimerLib|SEC PEI_CORE PEIM
+  MODULE_UNI_FILE= BaseCpuTimerLib.uni
+
+[Sources]
+  CpuTimerLib.c
+  BaseCpuTimerLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  PcdLib
+  DebugLib
+
+[Pcd]
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ## CONSUMES
diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni 
b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
new file mode 100644
index 00..fcf2b0fbcb
--- /dev/null
+++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
@@ -0,0 +1,17 @@
+// /** @file
+// Base CPU Timer Library
+//
+// Provides basic timer support using CPUID Leaf 0x15 XTAL frequency.  The 
performance
+// counter features are provided by the processors time stamp counter.
+//
+// Copyright (c) 2019, Intel Corporation. All rights reserved.
+//
+// SPDX-License-Identifier: BSD-2-Clause-Patent
+//
+// **/
+
+
+#string STR_MODULE_ABSTRACT #language en-US "CPU Timer Library"
+
+#string STR_MODULE_DESCRIPTION  #language en-US "Provides basic timer 
support using CPUID Leaf 0x15 XTAL frequency."
+
diff --git a/UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c

[edk2-devel] [PATCH 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Initialize local variables

2019-08-14 Thread Zhang, Shenglei

At latest edk2 version, there is build failure when building ShellPkg
with VS2012x86, which results from uninitialized local variables.

Cc: Jaben Carsey 
Cc: Ray Ni 
Cc: Zhichao Gao 
Signed-off-by: Shenglei Zhang 
---
 .../Library/UefiShellAcpiViewCommandLib/AcpiParser.c   |  8 
 .../Library/UefiShellAcpiViewCommandLib/AcpiView.c | 10 ++
 2 files changed, 18 insertions(+)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
index 2d6ff80e299e..94bafa22ef4c 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
@@ -121,6 +121,10 @@ VerifyChecksum (
   UINT8 Checksum;
   UINTN OriginalAttribute;
 
+  //
+  // set local variables to suppress incorrect compiler/analyzer warnings
+  //
+  OriginalAttribute = 0;
   ByteCount = 0;
   Checksum = 0;
 
@@ -472,6 +476,10 @@ ParseAcpi (
   BOOLEAN HighLight;
   UINTN   OriginalAttribute;
 
+  //
+  // set local variables to suppress incorrect compiler/analyzer warnings
+  //
+  OriginalAttribute = 0;
   Offset = 0;
 
   // Increment the Indent
diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
index 9feb2df2078f..de0851dd5fba 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiView.c
@@ -211,6 +211,10 @@ ProcessTableReportOptions (
   BOOLEAN Log;
   BOOLEAN HighLight;
 
+  //
+  // set local variables to suppress incorrect compiler/analyzer warnings
+  //
+  OriginalAttribute = 0;
   SignaturePtr = (UINT8*)(UINTN)
   Log = FALSE;
   HighLight = GetColourHighlighting ();
@@ -347,6 +351,12 @@ AcpiView (
   PARSE_ACPI_TABLE_PROCRsdpParserProc;
   BOOLEAN  Trace;
 
+  //
+  // set local variables to suppress incorrect compiler/analyzer warnings
+  //
+  EfiConfigurationTable = NULL;
+  OriginalAttribute = 0;
+
   // Search the table for an entry that matches the ACPI Table Guid
   FoundAcpiTable = FALSE;
   for (Index = 0; Index < SystemTable->NumberOfTableEntries; Index++) {
-- 
2.18.0.windows.1


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

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

Re: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by using CPUID(0x15) TSC leaf

2019-08-14 Thread Donald Kuo

Thanks Liming for review.

Update UefiCpuPkg.uni for review again.

Thanks,
Donald

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, August 15, 2019 12:03 PM
> To: Kuo, Donald ; Dong, Eric
> ; devel@edk2.groups.io
> Cc: Ni, Ray ; Zeng, Star ; Chan,
> Amy ; Chaganty, Rangasai V
> ; Lai, Luke ; Li, Kevin
> Y ; Laszlo Ersek (ler...@redhat.com)
> ; leif.lindh...@linaro.org; af...@apple.com; Kinney,
> Michael D 
> Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library by
> using CPUID(0x15) TSC leaf
> 
> Donald:
>   This change is a new feature. Now, it is not in edk2 feature planning list. 
> If
> you want to catch it into 201908 stable tag, please get approve from
> Stewards first. I have cc this mail to all Stewards.
> 
>   For this patch, I have one minor comment. You add one PCD in UefiCpuPkg
> DEC. Please also add this PCD into UefiCpuPkg.uni.
> 
> Thanks
> Liming
> > -Original Message-
> > From: Kuo, Donald
> > Sent: Thursday, August 15, 2019 11:02 AM
> > To: Dong, Eric ; devel@edk2.groups.io; Gao,
> > Liming 
> > Cc: Ni, Ray ; Zeng, Star ;
> > Chan, Amy ; Chaganty, Rangasai V
> > ; Lai, Luke ; Li,
> > Kevin Y 
> > Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library
> > by using CPUID(0x15) TSC leaf
> >
> > Hi Liming,
> >
> > As we plan to add new TimerLib to use CPUID Leaf 0x15 (CPU XTAL clock
> > frequency) to calculate TSC to resolve performance value unreliable
> concern.
> >
> > As the code review had got approved and planning into 201908 stable
> > tag. Please help to review whether any concern for 201908 stable tag.
> >
> > Thanks,
> > Donald
> >
> > > -Original Message-
> > > From: Dong, Eric
> > > Sent: Thursday, August 15, 2019 10:46 AM
> > > To: devel@edk2.groups.io; Kuo, Donald 
> > > Cc: Ni, Ray ; Zeng, Star ;
> > > Chan, Amy ; Chaganty, Rangasai V
> > > 
> > > Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC
> > > library by using CPUID(0x15) TSC leaf
> > >
> > > Reviewed-by: Eric Dong 
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf
> > > > Of Donald Kuo
> > > > Sent: Tuesday, August 13, 2019 6:53 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: Ni, Ray ; Zeng, Star ;
> > > > Dong, Eric ; Chan, Amy ;
> > > > Chaganty, Rangasai V 
> > > > Subject: [edk2-devel] [PATCH] UefiCpuPkg: Adding a new TSC library
> > > > by using
> > > > CPUID(0x15) TSC leaf
> > > >
> > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1909
> > > >
> > > > Cc: Ray Ni 
> > > > Cc: Star Zeng 
> > > > Cc: Eric Dong 
> > > > Cc: Amy Chan 
> > > > Cc: Rangasai V Chaganty 
> > > > Signed-off-by: Donald Kuo 
> > > > ---
> > > >  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c   |  41 +++
> > > >  UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf |  35 +++
> > > > UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni |  17 ++
> > > >  UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c   | 274
> > > > +
> > > >  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c|  81 ++
> > > >  UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf  |  37 +++
> > > > UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni  |  17 ++
> > > >  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c|  58 +
> > > >  UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf  |  36 +++
> > > > UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni  |  17 ++
> > > >  UefiCpuPkg/UefiCpuPkg.dec  |   8 +
> > > >  UefiCpuPkg/UefiCpuPkg.dsc  |   3 +
> > > >  12 files changed, 624 insertions(+)  create mode 100644
> > > > UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > > >  create mode 100644
> > > UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf
> > > >  create mode 100644
> > > UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.uni
> > > >  create mode 100644 UefiCpuPkg/Library/CpuTimerLib/CpuTimerLib.c
> > > >  create mode 100644
> > > > UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.c
> > > >  create mode 100644
> > > > UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.inf
> > > >  create mode 100644
> > > UefiCpuPkg/Library/CpuTimerLib/DxeCpuTimerLib.uni
> > > >  create mode 100644
> > > > UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.c
> > > >  create mode 100644
> > > > UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.inf
> > > >  create mode 100644
> > > > UefiCpuPkg/Library/CpuTimerLib/PeiCpuTimerLib.uni
> > > >
> > > > diff --git a/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > > > b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > > > new file mode 100644
> > > > index 00..6ddf917bad
> > > > --- /dev/null
> > > > +++ b/UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.c
> > > > @@ -0,0 +1,41 @@
> > > > +/** @file
> > > > +  CPUID Leaf 0x15 for Core Crystal Clock frequency instance as
> > > > +Base Timer
> > > > Library.
> > > > +
> > > > +  Copyright (c) 2019 Intel Corporation. All rights reserved.
> > > > +  SPDX-License-Identifier:

[edk2-devel] [PATCH] SecurityPkg/SecurityPkg.uni: Add missing strings for new PCDs

2019-08-14 Thread Wang, Jian J

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

Cc: Jiewen Yao 
Cc: Chao Zhang 
Cc: Shenglei Zhang 
Signed-off-by: Jian J Wang 
---
 SecurityPkg/SecurityPkg.uni | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/SecurityPkg/SecurityPkg.uni b/SecurityPkg/SecurityPkg.uni
index 9c0c008f9c..14077fbc28 100644
--- a/SecurityPkg/SecurityPkg.uni
+++ b/SecurityPkg/SecurityPkg.uni
@@ -263,3 +263,26 @@

   "0x01 - Do not support IdleByPass.\n"

   "0x02 - Support IdleByPass.\n"

   "0xFF - IdleByPass State is not synced with TPM hardware."
+
+#string 
STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationPass_PROMPT  
#language en-US "Status Code for FV verification pass."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationPass_HELP 
 #language en-US "Progress Code for FV verification result.\n"
+   
 "  (EFI_SOFTWARE_PEI_MODULE | EFI_SUBCLASS_SPECIFIC | 00A).\n"
+
+#string 
STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationFail_PROMPT  
#language en-US "Status Code for FV verification failure."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdStatusCodeFvVerificationFail_HELP 
 #language en-US "Progress Code for FV verification result.\n"
+   
 "  (EFI_SOFTWARE_PEI_MODULE | EFI_SUBCLASS_SPECIFIC | 00B).\n"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipOpalPasswordPrompt_PROMPT  
#language en-US "Skip Opal DXE driver password prompt."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipOpalPasswordPrompt_HELP  
#language en-US "Indicates if Opal DXE driver skip password prompt.\n\n"
+   
   "  TRUE  - Skip password prompt.\n"
+   
   "  FALSE - Does not skip password prompt.\n"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipHddPasswordPrompt_PROMPT  
#language en-US "Skip Hdd Password prompt."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipHddPasswordPrompt_HELP  
#language en-US "Indicates if Hdd Password driver skip password prompt.\n\n"
+   
   "  TRUE  - Skip password prompt.\n"
+   
   "  FALSE - Does not skip password prompt.\n"
+
-- 
2.17.1.windows.2


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

View/Reply Online (#45597): https://edk2.groups.io/g/devel/message/45597
Mute This Topic: https://groups.io/mt/32861906/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] ShellPkg/UefiShellDriver1CommandsLib: Make array big enough

2019-08-14 Thread Augustine, Linson

Reviewed-by: Linson Augustine 

Regards,
-Linson

-Original Message-
From: Gao, Zhichao 
Sent: Wednesday, August 14, 2019 2:03 PM
To: devel@edk2.groups.io; Gao, Zhichao 
Cc: Carsey, Jaben ; Ni, Ray ; 
oleks...@ami.com; Augustine, Linson 
Subject: RE: [edk2-devel] [PATCH V2] ShellPkg/UefiShellDriver1CommandsLib: Make 
array big enough

Ping again.

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Gao, Zhichao
> Sent: Friday, July 26, 2019 3:47 PM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray 
> ; oleks...@ami.com
> Subject: FW: [edk2-devel] [PATCH V2]
> ShellPkg/UefiShellDriver1CommandsLib: Make array big enough
> 
> Ping. Please help to review it.
> 
> Thanks,
> Zhichao
> 
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Gao, Zhichao
> Sent: Monday, July 22, 2019 2:58 PM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray 
> ; Oleksiy 
> Subject: [edk2-devel] [PATCH V2] ShellPkg/UefiShellDriver1CommandsLib:
> Make array big enough
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1941
> 
> The two CHAR16 array ChildCountStr and DeviceCountStr is defined to 
> hold the decimal string data of UINTN. The max of UINTN is
> 18446744073709551615 and it contain 20 characters.
> So make their size to 21 CHAR16s to hold the string data with a null- 
> terminate.
> UnicodeValueToStringS regard the value input as INT64, and
> 21 CHARs is enough to hold the lowest value with minus '-'.
> Although the value shouldn't be such big.
> 
> Cc: Jaben Carsey 
> Cc: Ray Ni 
> Cc: Oleksiy 
> Signed-off-by: Zhichao Gao 
> ---
> 
> V2:
> Update the copyright.
> 
>  ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> index 794b737bd1..27cd278cf0 100644
> --- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> +++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> @@ -2,7 +2,7 @@
>Main file for Drivers shell Driver1 function.
> 
>(C) Copyright 2012-2015 Hewlett-Packard Development Company, 
> L.P.
> -  Copyright (c) 2010 - 2018, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2010 - 2019, Intel Corporation. All rights 
> + reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -263,8 +263,8 @@ ShellCommandRunDrivers (
>EFI_HANDLE  *HandleWalker;
>UINTN   ChildCount;
>UINTN   DeviceCount;
> -  CHAR16  ChildCountStr[3];
> -  CHAR16  DeviceCountStr[3];
> +  CHAR16  ChildCountStr[21];
> +  CHAR16  DeviceCountStr[21];
>CHAR16  *Temp2;
>CONST CHAR16*FullDriverName;
>CHAR16  *TruncatedDriverName;
> --
> 2.21.0.windows.1
> 
> 
> 
> 
> 
> 


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

View/Reply Online (#45600): https://edk2.groups.io/g/devel/message/45600
Mute This Topic: https://groups.io/mt/32861764/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] ShellPkg: update drivers command for more children

2019-08-14 Thread Augustine, Linson

Reviewed-by: Linson Augustine 

Regards,
-Linson

-Original Message-
From: Carsey, Jaben 
Sent: Tuesday, August 13, 2019 8:12 PM
To: devel@edk2.groups.io
Cc: Ni, Ray ; Augustine, Linson ; 
Gao, Zhichao 
Subject: [Patch v1] ShellPkg: update drivers command for more children

this allows for > 99 children

Cc: ray ni 
Cc: linson augustine 
Cc: zhichao gao 
Signed-off-by: Jaben Carsey 
---
 ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c 
b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
index 794b737bd1..7d45f2fc40 100644
--- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
+++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
@@ -2,7 +2,7 @@
   Main file for Drivers shell Driver1 function.
 
   (C) Copyright 2012-2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -263,8 +263,8 @@ ShellCommandRunDrivers (
   EFI_HANDLE  *HandleWalker;
   UINTN   ChildCount;
   UINTN   DeviceCount;
-  CHAR16  ChildCountStr[3];
-  CHAR16  DeviceCountStr[3];
+  CHAR16  ChildCountStr[7];
+  CHAR16  DeviceCountStr[7];
   CHAR16  *Temp2;
   CONST CHAR16*FullDriverName;
   CHAR16  *TruncatedDriverName;
-- 
2.16.2.windows.1


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

View/Reply Online (#45599): https://edk2.groups.io/g/devel/message/45599
Mute This Topic: https://groups.io/mt/32853156/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] BaseTools/Scripts: Add GetUtcDateTime script.

2019-08-14 Thread Chiu, Chasel



V2 re-wrote the script to use ArgumentParser and remove sys.exit().

Regards,
Chasel


> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Chiu, Chasel
> Sent: Wednesday, August 14, 2019 6:21 PM
> To: devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming ;
> Leif Lindholm 
> Subject: [edk2-devel] [PATCH v2] BaseTools/Scripts: Add GetUtcDateTime
> script.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2067
> 
> A script that can return UTC date and time in ascii format which is convenient
> for patching build time information in any binary.
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Leif Lindholm 
> Signed-off-by: Chasel Chiu 
> ---
>  BaseTools/Scripts/GetUtcDateTime.py | 44
> 
>  1 file changed, 44 insertions(+)
> 
> diff --git a/BaseTools/Scripts/GetUtcDateTime.py
> b/BaseTools/Scripts/GetUtcDateTime.py
> new file mode 100644
> index 00..3cfb6ac2ae
> --- /dev/null
> +++ b/BaseTools/Scripts/GetUtcDateTime.py
> @@ -0,0 +1,44 @@
> +## @file
> +#  Get current UTC date and time information and output as ascii code.
> +#
> +#  Copyright (c) 2019, Intel Corporation. All rights reserved. # #
> +SPDX-License-Identifier: BSD-2-Clause-Patent #
> +
> +VersionNumber = '0.1'
> +import sys
> +import datetime
> +import argparse
> +
> +def Main():
> +PARSER = argparse.ArgumentParser(
> +description='Retrieves UTC date and time information (output 
> ordering:
> year, date, time) - Version ' + VersionNumber)
> +PARSER.add_argument('--year',
> +action='store_true',
> +help='Return UTC year of now. [Example output (2019):
> 39313032]')
> +PARSER.add_argument('--date',
> +action='store_true',
> +help='Return UTC date MMDD of now. [Example output
> (7th August): 37303830]')
> +PARSER.add_argument('--time',
> +action='store_true',
> +help='Return 24-hour-format UTC time HHMM of
> +now. [Example output (14:25): 35323431]')
> +
> +ARGS = PARSER.parse_args()
> +if len(sys.argv) == 1:
> +print ("ERROR: At least one argument is required!\n")
> +PARSER.print_help()
> +
> +today = datetime.datetime.utcnow()
> +if ARGS.year:
> +ReversedNumber = str(today.year)[::-1]
> +print (''.join(hex(ord(HexString))[2:] for HexString in 
> ReversedNumber))
> +if ARGS.date:
> +ReversedNumber = str(today.strftime("%m%d"))[::-1]
> +print (''.join(hex(ord(HexString))[2:] for HexString in 
> ReversedNumber))
> +if ARGS.time:
> +ReversedNumber = str(today.strftime("%H%M"))[::-1]
> +print (''.join(hex(ord(HexString))[2:] for HexString in
> + ReversedNumber))
> +
> +if __name__ == '__main__':
> +Main()
> --
> 2.13.3.windows.1
> 
> 
> 


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

View/Reply Online (#45602): https://edk2.groups.io/g/devel/message/45602
Mute This Topic: https://groups.io/mt/32862249/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 1/1] MdePkg: Add STATIC_ASSERT macro

2019-08-14 Thread Liming Gao

Can you add the sample usage of new macro STATIC_ASSERT?

Or, give the link of static_assert or _Static_assert. 

If so, the developer knows how to use them in source code. 

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of vit9696 
> via Groups.Io
> Sent: Tuesday, August 13, 2019 4:17 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048
> 
> Provide a macro for compile time assertions.
> Equivalent to C11 static_assert macro from assert.h.
> 
> Signed-off-by: Vitaly Cheptsov 
> ---
>  MdePkg/Include/Base.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> index ce20b5f01dce..f85f7028a262 100644
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -843,6 +843,17 @@ typedef UINTN  *BASE_LIST;
>  #define OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)->Field))
>  #endif
> 
> +///
> +/// Portable definition for compile time assertions.
> +/// Equivalent to C11 static_assert macro from assert.h.
> +/// Takes condtion and error message as its arguments.
> +///
> +#ifdef _MSC_EXTENSIONS
> +  #define STATIC_ASSERT static_assert
> +#else
> +  #define STATIC_ASSERT _Static_assert
> +#endif
> +
>  /**
>Macro that returns a pointer to the data structure that contains a 
> specified field of
>that data structure.  This is a lightweight method to hide information by 
> placing a
> --
> 2.20.1 (Apple Git-117)
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> 
> View/Reply Online (#45503): https://edk2.groups.io/g/devel/message/45503
> Mute This Topic: https://groups.io/mt/32850582/1759384
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub  [liming@intel.com]
> -=-=-=-=-=-=


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

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

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-14 Thread Yao, Jiewen

My comments below.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, August 14, 2019 12:09 AM
> To: edk2-devel-groups-io 
> Cc: edk2-rfc-groups-io ; qemu devel list
> ; Igor Mammedov ;
> Paolo Bonzini ; Yao, Jiewen
> ; Chen, Yingwen ;
> Nakajima, Jun ; Boris Ostrovsky
> ; Joao Marcal Lemos Martins
> ; Phillip Goerl 
> Subject: Re: CPU hotplug using SMM with QEMU+OVMF
> 
> On 08/13/19 16:16, Laszlo Ersek wrote:
> 
> > Yingwen and Jiewen suggested the following process.
> >
> > Legend:
> >
> > - "New CPU":  CPU being hot-added
> > - "Host CPU": existing CPU
> > - (Flash):code running from flash
> > - (SMM):  code running from SMRAM
> >
> > Steps:
> >
> > (01) New CPU: (Flash) enter reset vector, Global SMI disabled by
> >  default.
> 
> - What does "Global SMI disabled by default" mean? In particular, what
>   is "global" here?
[Jiewen] OK. Let's don’t use the term "global".


>   Do you mean that the CPU being hot-plugged should mask (by default)
>   broadcast SMIs? What about directed SMIs? (An attacker could try that
>   too.)
[Jiewen] I mean all SMIs are blocked for this specific hot-added CPU.


>   And what about other processors? (I'd assume step (01)) is not
>   relevant for other processors, but "global" is quite confusing here.)
[Jiewen] No impact to other processors.


> - Does this part require a new branch somewhere in the OVMF SEC code?
>   How do we determine whether the CPU executing SEC is BSP or
>   hot-plugged AP?
[Jiewen] I think this is blocked from hardware perspective, since the first 
instruction.
There are some hardware specific registers can be used to determine if the CPU 
is new added.
I don’t think this must be same as the real hardware.
You are free to invent some registers in device model to be used in OVMF hot 
plug driver.


> - How do we tell the hot-plugged AP where to start execution? (I.e. that
>   it should execute code at a particular pflash location.)
[Jiewen] Same real mode reset vector at :FFF0.


>   For example, in MpInitLib, we start a specific AP with INIT-SIPI-SIPI,
>   where "SIPI" stores the startup address in the "Interrupt Command
>   Register" (which is memory-mapped in xAPIC mode, and an MSR in x2APIC
>   mode, apparently). That doesn't apply here -- should QEMU auto-start
>   the new CPU?
[Jiewen] You can send INIT-SIPI-SIPI to new CPU only after it can access memory.
SIPI need give AP an below 1M memory address as waking vector.


> - What memory is used as stack by the new CPU, when it runs code from
>   flash?
[Jiewen] Same as other CPU in normal boot. You can use special reserved memory.


>   QEMU does not emulate CAR (Cache As RAM). The new CPU doesn't have
>   access to SMRAM. And we cannot use AcpiNVS or Reserved memory,
> because
>   a malicious OS could use other CPUs -- or PCI device DMA -- to attack
>   the stack (unless QEMU forcibly paused other CPUs upon hotplug; I'm
>   not sure).
[Jiewen] Excellent point!
I don’t think there is problem for real hardware, who always has CAR.
Can QEMU provide some CPU specific space, such as MMIO region?


> - If an attempt is made to hotplug multiple CPUs in quick succession,
>   does something serialize those attempts?
[Jiewen] The BIOS need consider this as availability requirement.
I don’t have strong opinion.
You can design a system that required hotplug must be one-by-one, or fail the 
hot-add.
Or you can design a system that did not have such restriction.
Again, all we need to do is to maintain the integrity of SMM.
The availability should be considered as separate requirement.


>   Again, stack usage could be a concern, even with Cache-As-RAM --
>   HyperThreads (logical processors) on a single core don't have
>   dedicated cache.
[Jiewen] Agree with you on the virtual environment.
For real hardware, we do socket level hot-add only. So HT is not the concern.
But if you want to do that in virtual environment, a processor specific memory
should be considered.


>   Does CPU hotplug apply only at the socket level? If the CPU is
>   multi-core, what is responsible for hot-plugging all cores present in
>   the socket?
[Jiewen] Ditto.


> > (02) New CPU: (Flash) configure memory control to let it access global
> >  host memory.
> 
> In QEMU/KVM guests, we don't have to enable memory explicitly, it just
> exists and works.
> 
> In OVMF X64 SEC, we can't access RAM above 4GB, but that shouldn't be an
> issue per se.
[Jiewen] Agree. I do not see the issue.


> > (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
> >  -- I am waiting for hot-add message.
> 
> Maybe we can simplify this in QEMU by broadcasting an SMI to existent
> processors immediately upon plugging the new CPU.
> 
> 
> >(NOTE: Host CPU can only
> send
> >  instruction in SMM mode. -- The register is SMM only)
> 
> Sorry, I don't follow -- what register are we talking about here, and
> why is the BSP needed

Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT update

2019-08-14 Thread Liming Gao

Laszlo:

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, August 13, 2019 5:48 PM
> To: Kinney, Michael D ; devel@edk2.groups.io; 
> Gao, Liming 
> Cc: Mike Turner ; Wang, Jian J 
> ; Wu, Hao A ; Bi, Dandan
> 
> Subject: Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT 
> update
> 
> On 08/13/19 01:22, Kinney, Michael D wrote:
> >
> >
> >> -Original Message-
> >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> >> On Behalf Of Laszlo Ersek
> >> Sent: Monday, August 12, 2019 9:24 AM
> >> To: devel@edk2.groups.io; Gao, Liming
> >> 
> >> Cc: Mike Turner ; Wang, Jian J
> >> ; Wu, Hao A ;
> >> Bi, Dandan 
> >> Subject: Re: [edk2-devel] [Patch] MdeModulePkg DxeCore:
> >> Fix for missing MAT update
> >>
> >> On 08/10/19 16:10, Liming Gao wrote:
> >>> From: Mike Turner 
> >>>
> >>> The Fpdt driver (FirmwarePerformanceDxe) saves a memory
> >> address across
> >>> reboots, and then does an AllocatePage for that memory
> >> address.
> >>> If, on this boot, that memory comes from a Runtime
> >> memory bucket, the
> >>> MAT table is not updated. This causes Windows to boot
> >> into Recovery.
> >>
> >> (1) What is "MAT"?
> >
> > Memory Attributes Table (EFI_MEMORY_ATTRIBUTES_TABLE)
> >
> >>
> >>> This patch blocks the memory manager from changing the
> >> page from a
> >>> special bucket to a different memory type.  Once the
> >> buckets are
> >>> allocated, we freeze the memory ranges for the OS, and
> >> fragmenting the
> >>> special buckets will cause errors resuming from
> >> hibernate.
> >>
> >> (2) My understanding is that CoreConvertPages() will only
> >> hand out the requested pages if those pages are currently
> >> free. I suggest clarifying the commit message that the
> >> intent is to prevent the allocation of otherwise *free*
> >> pages, if the allocation would fragment special buckets.
> >>
> >> (3) I don't understand the conjunction "and". I would
> >> understand if the statement were:
> >>
> >> Once the buckets are allocated, we freeze the memory
> >> ranges for the
> >> OS, *because* fragmenting the special buckets *would*
> >> cause errors
> >> resuming from hibernate.
> >>
> >> Is this the intent?
> >>
> >>>
> >>> This patch is cherry pick from Project Mu:
> >>>
> >> https://github.com/microsoft/mu_basecore/commit/a9be767d9
> >> be96af94016eb
> >>> d391ea6f340920735a
> >>> With the minor change,
> >>> 1. Update commit message format to keep the message in
> >> 80 characters one line.
> >>> 2. Remove // MU_CHANGE comments in source code.
> >>>
> >>> Cc: Jian J Wang 
> >>> Cc: Hao A Wu 
> >>> Cc: Dandan Bi 
> >>> Signed-off-by: Liming Gao 
> >>> ---
> >>>  MdeModulePkg/Core/Dxe/Mem/Page.c | 43
> >>> ++--
> >>>  1 file changed, 37 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> >>> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> >>> index bd9e116aa5..637518889d 100644
> >>> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> >>> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> >>> @@ -1265,12 +1265,13 @@ CoreInternalAllocatePages (
> >>>IN BOOLEANNeedGuard
> >>>)
> >>>  {
> >>> -  EFI_STATUS  Status;
> >>> -  UINT64  Start;
> >>> -  UINT64  NumberOfBytes;
> >>> -  UINT64  End;
> >>> -  UINT64  MaxAddress;
> >>> -  UINTN   Alignment;
> >>> +  EFI_STATUS   Status;
> >>> +  UINT64   Start;
> >>> +  UINT64   NumberOfBytes;
> >>> +  UINT64   End;
> >>> +  UINT64   MaxAddress;
> >>> +  UINTNAlignment;
> >>> +  EFI_MEMORY_TYPE  CheckType;
> >>>
> >>>if ((UINT32)Type >= MaxAllocateType) {
> >>>  return EFI_INVALID_PARAMETER;
> >>> @@ -1321,6 +1322,7 @@ CoreInternalAllocatePages (
> >>>// if (Start + NumberOfBytes) rolls over 0 or
> >>>// if Start is above MAX_ALLOC_ADDRESS or
> >>>// if End is above MAX_ALLOC_ADDRESS,
> >>> +  // if Start..End overlaps any tracked
> >> MemoryTypeStatistics range
> >>>// return EFI_NOT_FOUND.
> >>>//
> >>>if (Type == AllocateAddress) {
> >>> @@ -1336,6 +1338,35 @@ CoreInternalAllocatePages (
> >>>  (End > MaxAddress)) {
> >>>return EFI_NOT_FOUND;
> >>>  }
> >>> +
> >>> +// Problem summary
> >>> +
> >>> +/*
> >>> +A driver is allowed to call AllocatePages using an
> >> AllocateAddress type.  This type of
> >>> +AllocatePage request the exact physical address if
> >> it is not used.  The existing code
> >>> +will allow this request even in 'special' pages.
> >> The problem with this is that the
> >>> +reason to have 'special' pages for OS
> >> hibernate/resume is defeated as memory is
> >>> +fragmented.
> >>> +*/
> >>
> >> (4) This comment style is not native to edk2.
> >>
> >> I think the "problem summary" line should be removed, and
> >> the actual problem statement should use the following
> >> comment style:
> >>
> >>   //
> >>   // blah
> >>

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

2019-08-14 Thread Michael D Kinney

Liming,

I think a good candidate to demonstrate this
feature are the checks made in MdePkg/Include/Base.h.
The current implementation forces a divide by 0 
in the C pre-processor to break the build.
STATIC_ASSERT() would be a better way to do this.
I would also remove unused externs from the builds.

/**
  Verifies the storage size of a given data type.

  This macro generates a divide by zero error or a zero size array declaration 
in
  the preprocessor if the size is incorrect.  These are declared as "extern" so
  the space for these arrays will not be in the modules.

  @param  TYPE  The date type to determine the size of.
  @param  Size  The expected size for the TYPE.

**/
#define VERIFY_SIZE_OF(TYPE, Size) extern UINT8 
_VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))]

//
// Verify that ProcessorBind.h produced UEFI Data Types that are compliant with
// Section 2.3.1 of the UEFI 2.3 Specification.
//
VERIFY_SIZE_OF (BOOLEAN, 1);
VERIFY_SIZE_OF (INT8, 1);
VERIFY_SIZE_OF (UINT8, 1);
VERIFY_SIZE_OF (INT16, 2);
VERIFY_SIZE_OF (UINT16, 2);
VERIFY_SIZE_OF (INT32, 4);
VERIFY_SIZE_OF (UINT32, 4);
VERIFY_SIZE_OF (INT64, 8);
VERIFY_SIZE_OF (UINT64, 8);
VERIFY_SIZE_OF (CHAR8, 1);
VERIFY_SIZE_OF (CHAR16, 2);

//
// The following three enum types are used to verify that the compiler
// configuration for enum types is compliant with Section 2.3.1 of the
// UEFI 2.3 Specification. These enum types and enum values are not
// intended to be used. A prefix of '__' is used avoid conflicts with
// other types.
//
typedef enum {
  __VerifyUint8EnumValue = 0xff
} __VERIFY_UINT8_ENUM_SIZE;

typedef enum {
  __VerifyUint16EnumValue = 0x
} __VERIFY_UINT16_ENUM_SIZE;

typedef enum {
  __VerifyUint32EnumValue = 0x
} __VERIFY_UINT32_ENUM_SIZE;

VERIFY_SIZE_OF (__VERIFY_UINT8_ENUM_SIZE, 4);
VERIFY_SIZE_OF (__VERIFY_UINT16_ENUM_SIZE, 4);
VERIFY_SIZE_OF (__VERIFY_UINT32_ENUM_SIZE, 4);

A couple examples.  Do all the compilers support the message parameter too?

STATIC_ASSERT (sizeof (BOOLEAN) == 1, "sizeof (BOOLEAN) does not meet UEFI 
Specification Data Type requirements")
STATIC_ASSERT (sizeof (UINT16)  == 2, "sizeof (UINT16) does not meet UEFI 
Specification Data Type requirements")
STATIC_ASSERT (sizeof (INT32)   == 4, "sizeof (INT32) does not meet UEFI 
Specification Data Type requirements")
STATIC_ASSERT (sizeof (CHAR16)  == 2, "sizeof (CHAR16) does not meet UEFI 
Specification Data Type requirements")
STATIC_ASSERT (sizeof (__VERIFY_UINT8_ENUM_SIZE) == 4, "Size of enum does not 
meet UEFI Specification Data Type requirements")
STATIC_ASSERT (sizeof (__VERIFY_UINT32_ENUM_SIZE) == 4, "Size of enum does not 
meet UEFI Specification Data Type requirements")

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> On Behalf Of Liming Gao
> Sent: Wednesday, August 14, 2019 6:50 AM
> To: devel@edk2.groups.io; vit9...@protonmail.com
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
> STATIC_ASSERT macro
> 
> Can you add the sample usage of new macro STATIC_ASSERT?
> 
> Or, give the link of static_assert or _Static_assert.
> 
> If so, the developer knows how to use them in source
> code.
> 
> Thanks
> Liming
> > -Original Message-
> > From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On Behalf Of
> > vit9696 via Groups.Io
> > Sent: Tuesday, August 13, 2019 4:17 PM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
> STATIC_ASSERT macro
> >
> >
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048
> >
> > Provide a macro for compile time assertions.
> > Equivalent to C11 static_assert macro from assert.h.
> >
> > Signed-off-by: Vitaly Cheptsov
> 
> > ---
> >  MdePkg/Include/Base.h | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/MdePkg/Include/Base.h
> b/MdePkg/Include/Base.h index
> > ce20b5f01dce..f85f7028a262 100644
> > --- a/MdePkg/Include/Base.h
> > +++ b/MdePkg/Include/Base.h
> > @@ -843,6 +843,17 @@ typedef UINTN  *BASE_LIST;
> #define
> > OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)->Field))
> #endif
> >
> > +///
> > +/// Portable definition for compile time assertions.
> > +/// Equivalent to C11 static_assert macro from
> assert.h.
> > +/// Takes condtion and error message as its
> arguments.
> > +///
> > +#ifdef _MSC_EXTENSIONS
> > +  #define STATIC_ASSERT static_assert #else
> > +  #define STATIC_ASSERT _Static_assert #endif
> > +
> >  /**
> >Macro that returns a pointer to the data structure
> that contains a specified field of
> >that data structure.  This is a lightweight method
> to hide
> > information by placing a
> > --
> > 2.20.1 (Apple Git-117)
> >
> >
> > -=-=-=-=-=-=
> > Groups.io Links: You receive all messages sent to this
> group.
> >
> > View/Reply Online (#45503):
> > https://edk2.groups.io/g/devel/message/45503
> > Mute This Topic: https://groups.io/mt/32850582/1759384
> > Group Owner: devel+ow...@edk2.groups.io
> > Unsubscribe:

Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT update

2019-08-14 Thread Liming Gao

Laszlo:

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Laszlo 
> Ersek
> Sent: Wednesday, August 14, 2019 11:13 PM
> To: Gao, Liming ; Kinney, Michael D 
> ; devel@edk2.groups.io
> Cc: Mike Turner ; Wang, Jian J 
> ; Wu, Hao A ; Bi, Dandan
> 
> Subject: Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT 
> update
> 
> On 08/14/19 16:00, Gao, Liming wrote:
> > Laszlo:
> 
> >
> > I cherry pick this patch from Mu project with the minimal change.
> > I can update the comment style.
> 
> Yes, please. Thanks!
> 
> >> The gEfiMemoryTypeInformationGuid HOB is supposed to be built -- if it
> >> is built at all -- no later than in the DXE IPL PEIM (if VariablePei is
> >> included in the platform, and the underlying UEFI variable exists). Is
> >> that correct?
> >>
> > gEfiMemoryTypeInformationGuid HOB is installed by platform PEI.
> 
> Yes, that's what I meant by "no later than in the DXE IPL PEIM".
> 
> > If the platform PEI doesn't install this HOB, it means this feature is 
> > disabled.
> 
> PlatformPei is supposed to build the HOB in the first place, yes.
> 
> However, if it doesn't, then there still may be a feedback loop between
> the DXE IPL PEIM and BDS. The former builds the HOB from the UEFI
> variable, and the latter updates the variable (as I understand) for
> future boots.
> 
UEFI variable is created by BDS only when HOB can be found. 
If Platform PEIM doesn't build HOB, DxeIpl will not build HOB, 
then BDS will not create UEFI variable. If so, there is no HOB in 
every boot. 

Thanks
Liming
> Thanks
> Laszlo
> 
> 


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

View/Reply Online (#45619): https://edk2.groups.io/g/devel/message/45619
Mute This Topic: https://groups.io/mt/32821535/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] BaseTools/Scripts: Add GetUtcDateTime script.

2019-08-14 Thread Chiu, Chasel


Yes, as pylama currently not requirement yet we will evaluate this later.

Thanks!

Regards,
Chasel


> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> rebe...@bsdio.com
> Sent: Wednesday, August 14, 2019 7:51 PM
> To: devel@edk2.groups.io; Chiu, Chasel 
> Cc: Feng, Bob C ; Gao, Liming ;
> Leif Lindholm 
> Subject: Re: [edk2-devel] [PATCH v2] BaseTools/Scripts: Add GetUtcDateTime
> script.
> 
> On 2019-08-14 04:21, Chiu, Chasel wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2067
> >
> > A script that can return UTC date and time in ascii format which is
> > convenient for patching build time information in any binary.
> 
> 
> I know it's not a required tool to be run before committing, but could
> you consider the following issues pylama reported, please?
> 
> BaseTools/Scripts/GetUtcDateTime.py:1:1: E266 too many leading '#' for
> block comment [pycodestyle]
> BaseTools/Scripts/GetUtcDateTime.py:10:1: E402 module level import not
> at top of file [pycodestyle]
> BaseTools/Scripts/GetUtcDateTime.py:11:1: E402 module level import not
> at top of file [pycodestyle]
> BaseTools/Scripts/GetUtcDateTime.py:12:1: E402 module level import not
> at top of file [pycodestyle]
> BaseTools/Scripts/GetUtcDateTime.py:14:1: E302 expected 2 blank lines,
> found 1 [pycodestyle]
> BaseTools/Scripts/GetUtcDateTime.py:29:14: E211 whitespace before '('
> [pycodestyle]
> BaseTools/Scripts/GetUtcDateTime.py:35:14: E211 whitespace before '('
> [pycodestyle]
> BaseTools/Scripts/GetUtcDateTime.py:38:14: E211 whitespace before '('
> [pycodestyle]
> BaseTools/Scripts/GetUtcDateTime.py:41:14: E211 whitespace before '('
> [pycodestyle]
> BaseTools/Scripts/GetUtcDateTime.py:43:1: E305 expected 2 blank lines
> after class or function definition, found 1 [pycodestyle]
> 
> --
> Rebecca Cran
> 
> 
> 


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

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

Re: [edk2-devel] [RFC] BZ 1837 Enable Windows Firmware Update Driver Tool in Edk2/BaseTools for 201908 stable tag

2019-08-14 Thread Eric Jin

Hi Leif,

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Leif Lindholm
> Sent: Wednesday, August 14, 2019 2:47 AM
> To: Gao, Liming 
> Cc: Jin, Eric ; r...@edk2.groups.io; devel@edk2.groups.io;
> Feng, Bob C ; Cetola, Stephano
> ; Laszlo Ersek (ler...@redhat.com)
> ; af...@apple.com; Kinney, Michael D
> 
> Subject: Re: [edk2-devel] [RFC] BZ 1837 Enable Windows Firmware Update
> Driver Tool in Edk2/BaseTools for 201908 stable tag
> 
> Hi Liming,
> 
> This is the other one. As I said, the fact that we are slipping multiple 
> scripts in
> *just* before freeze is a concern for me.

I realize it is my fault that I don't notify the release plan as early as 
possible even the BZ1837 is created in May and want to catch 201908 stable tag.

> 
> I have no objection to the code here though.

Thanks.

> 
> I would however request that Sean is set as author on patch 1/2 as he was
> the original author of the script. (This was easy for me to find out because
> the commit message was exemplary.)

In the patch series V2, Sean has been set as author on patch 1/2. Thank you for 
this valuable suggestion.

Best Regards
Eric

> 
> Best Regards,
> 
> Leif
> 
> On Tue, Aug 13, 2019 at 01:49:24PM +, Gao, Liming wrote:
> > I see this patch was sent a week ago. This is a standalone tool. There is no
> impact on normal build and boot. I am OK to add it for 201908 stable tag.
> >
> > Thanks
> > Liming
> > From: Jin, Eric
> > Sent: Monday, August 12, 2019 3:09 PM
> > To: r...@edk2.groups.io
> > Cc: Gao, Liming ; Jin, Eric
> > ; devel@edk2.groups.io; Feng, Bob C
> > 
> > Subject: [RFC] BZ 1837 Enable Windows Firmware Update Driver Tool in
> > Edk2/BaseTools for 201908 stable tag
> >
> > Hi All,
> >
> > It is the request to Enable Windows Firmware Update Driver Tool in
> Edk2/BaseTools  and catch the Q3 tag.
> > The new tool will leverage the edk2-pytool-library to generate the cat/inf
> file based on the cap file. The output driver package can be trigged in
> Windows OS to complete capsule update.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1837
> >
> > Patch link: https://edk2.groups.io/g/devel/topic/32780378#44992
> >
> > Best Regards
> > Eric
> >
> >
> 
> 


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

View/Reply Online (#45621): https://edk2.groups.io/g/devel/message/45621
Mute This Topic: https://groups.io/mt/32838310/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 1/1] MdePkg: Add STATIC_ASSERT macro

2019-08-14 Thread Vitaly Cheptosv via Groups.Io

Michael, Liming, Laszlo,

Static assertions via _Static_assert are standard C11 functionality, thus any 
at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support the 
second argument with the diagnostic description.
The notation without the message currently is only present in C++, not in C, 
thus the two-argument notation is the only allowed notation for _Static_assert 
for at least C17 (ISO/IEC 9899 2018) and below.
In the bottom of this message I included a quote from C17 for the relevant 
section (6.7.10).

GCC and CLANG (including Xcode) appear to be conforming to the standard for 
this section, and MSVC compiler static_assert extension also supports the 
diagnostic message argument. This is pretty much all we care about.

As for examples, I see little reason to clarify STATIC_ASSERT behaviour outside 
of the standard reference in its description and actual usage in the source 
code, but can do that just fine if you think that it may help somebody.

I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, 
and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. 
This should be fairly costless, as apparently it is only used in Base.h and 
MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in the 
same patch set.

As for select ASSERT usage switching to STATIC_ASSERT, this would also be 
great, as let us be honest, the use of ASSERT in EDK II codebase is very 
questioning. In fact, this was one of the reasons we introduced our own static 
assertions some time ago. However, fixing up all broken assertions is unlikely 
a best place to fit into this patchset, but I can surely add a few examples, in 
case somebody points them out. This will be useful for reference purposes and 
may help the maintainers to get a better idea when static assertions are to be 
used.

Looking forward to hearing your opinions.

Best regards,
Vitaly


6.7.10 Static assertions

Syntax
1 static_assert-declaration:
_Static_assert ( constant-expression , string-literal ) ;

Constraints
2 The constant expression shall compare unequal to 0.

Semantics
3 The constant expression shall be an integer constant expression. If the value 
of the constant expression compares unequal to 0, the declaration has no 
effect. Otherwise, the constraint is violated and the implementation shall 
produce a diagnostic message that includes the text of the string literal, 
except that characters not in the basic source character set are not required 
to appear in the message.
Forward references: diagnostics (7.2).

7.2 Diagnostics 

3 The macro
static_assert
expands to _Static_assert.


> 14 авг. 2019 г., в 18:47, Kinney, Michael D  
> написал(а):
> 
> 
> Liming,
> 
> I think a good candidate to demonstrate this
> feature are the checks made in MdePkg/Include/Base.h.
> The current implementation forces a divide by 0
> in the C pre-processor to break the build.
> STATIC_ASSERT() would be a better way to do this.
> I would also remove unused externs from the builds.
> 
> /**
>  Verifies the storage size of a given data type.
> 
>  This macro generates a divide by zero error or a zero size array declaration 
> in
>  the preprocessor if the size is incorrect.  These are declared as "extern" so
>  the space for these arrays will not be in the modules.
> 
>  @param  TYPE  The date type to determine the size of.
>  @param  Size  The expected size for the TYPE.
> 
> **/
> #define VERIFY_SIZE_OF(TYPE, Size) extern UINT8 
> _VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))]
> 
> //
> // Verify that ProcessorBind.h produced UEFI Data Types that are compliant 
> with
> // Section 2.3.1 of the UEFI 2.3 Specification.
> //
> VERIFY_SIZE_OF (BOOLEAN, 1);
> VERIFY_SIZE_OF (INT8, 1);
> VERIFY_SIZE_OF (UINT8, 1);
> VERIFY_SIZE_OF (INT16, 2);
> VERIFY_SIZE_OF (UINT16, 2);
> VERIFY_SIZE_OF (INT32, 4);
> VERIFY_SIZE_OF (UINT32, 4);
> VERIFY_SIZE_OF (INT64, 8);
> VERIFY_SIZE_OF (UINT64, 8);
> VERIFY_SIZE_OF (CHAR8, 1);
> VERIFY_SIZE_OF (CHAR16, 2);
> 
> //
> // The following three enum types are used to verify that the compiler
> // configuration for enum types is compliant with Section 2.3.1 of the
> // UEFI 2.3 Specification. These enum types and enum values are not
> // intended to be used. A prefix of '__' is used avoid conflicts with
> // other types.
> //
> typedef enum {
>  __VerifyUint8EnumValue = 0xff
> } __VERIFY_UINT8_ENUM_SIZE;
> 
> typedef enum {
>  __VerifyUint16EnumValue = 0x
> } __VERIFY_UINT16_ENUM_SIZE;
> 
> typedef enum {
>  __VerifyUint32EnumValue = 0x
> } __VERIFY_UINT32_ENUM_SIZE;
> 
> VERIFY_SIZE_OF (__VERIFY_UINT8_ENUM_SIZE, 4);
> VERIFY_SIZE_OF (__VERIFY_UINT16_ENUM_SIZE, 4);
> VERIFY_SIZE_OF (__VERIFY_UINT32_ENUM_SIZE, 4);
> 
> A couple examples.  Do all the compilers support the message parameter too?
> 
> STATIC_ASSERT (sizeof (BOOLEAN) == 1, "sizeof (BOOLEAN) does not meet UEFI 
> Specification Data Type requirements")
>

[edk2-devel] [PATCH v5 5/5] BaseTools: Improve the file saving and copying reliability

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

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

The Basetool CopyFileOnChange() and SaveFileOnChange()
functions might raise the IOError occasionally when build
in Windows with multi-process and build cache enabled.
The CopyFileOnChange() and SaveFileOnChange() might be invoked
in multiple sub-processes simultaneously, and this patch adds
global locks to sync these functions invoking which can
harden their reliability.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/AutoGenWorker.py |  4 +++-
 BaseTools/Source/Python/AutoGen/GenC.py  |  0
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 18 +-
 BaseTools/Source/Python/Common/GlobalData.py |  2 ++
 BaseTools/Source/Python/Common/Misc.py   | 29 
+++--
 BaseTools/Source/Python/build/build.py   |  5 -
 6 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
index 30d2f96fc7..21c5efbe6a 100755
--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
@@ -133,7 +133,7 @@ class AutoGenManager(threading.Thread):
 def kill(self):
 self.feedback_q.put(None)
 class AutoGenWorkerInProcess(mp.Process):
-def __init__(self,module_queue,data_pipe_file_path,feedback_q,file_lock, 
share_data,log_q,error_event):
+def 
__init__(self,module_queue,data_pipe_file_path,feedback_q,file_lock,cache_lock,share_data,log_q,error_event):
 mp.Process.__init__(self)
 self.module_queue = module_queue
 self.data_pipe_file_path =data_pipe_file_path
@@ -141,6 +141,7 @@ class AutoGenWorkerInProcess(mp.Process):
 self.feedback_q = feedback_q
 self.PlatformMetaFileSet = {}
 self.file_lock = file_lock
+self.cache_lock = cache_lock
 self.share_data = share_data
 self.log_q = log_q
 self.error_event = error_event
@@ -187,6 +188,7 @@ class AutoGenWorkerInProcess(mp.Process):
 GlobalData.gCacheIR = self.data_pipe.Get("CacheIR")
 GlobalData.gEnableGenfdsMultiThread = 
self.data_pipe.Get("EnableGenfdsMultiThread")
 GlobalData.file_lock = self.file_lock
+GlobalData.cache_lock = self.cache_lock
 CommandTarget = self.data_pipe.Get("CommandTarget")
 pcd_from_build_option = []
 for pcd_tuple in self.data_pipe.Get("BuildOptPcd"):
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
old mode 100644
new mode 100755
diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index c489c3b9c4..0f319e5b26 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -1806,7 +1806,7 @@ class ModuleAutoGen(AutoGen):
 MewIR.MakefilePath = MakefilePath
 MewIR.DependencyHeaderFileSet = Makefile.DependencyHeaderFileSet
 MewIR.CreateMakeFileDone = True
-with GlobalData.file_lock:
+with GlobalData.cache_lock:
 try:
 IR = gDict[(self.MetaFile.Path, self.Arch)]
 IR.MakefilePath = MakefilePath
@@ -1891,7 +1891,7 @@ class ModuleAutoGen(AutoGen):
 self.IsCodeFileCreated = True
 MewIR = ModuleBuildCacheIR(self.MetaFile.Path, self.Arch)
 MewIR.CreateCodeFileDone = True
-with GlobalData.file_lock:
+with GlobalData.cache_lock:
 try:
 IR = gDict[(self.MetaFile.Path, self.Arch)]
 IR.CreateCodeFileDone = True
@@ -2032,7 +2032,7 @@ class ModuleAutoGen(AutoGen):
 MewIR.ModuleFilesHashDigest = m.digest()
 MewIR.ModuleFilesHashHexDigest = m.hexdigest()
 MewIR.ModuleFilesChain = FileList
-with GlobalData.file_lock:
+with GlobalData.cache_lock:
 try:
 IR = gDict[(self.MetaFile.Path, self.Arch)]
 IR.ModuleFilesHashDigest = m.digest()
@@ -2091,7 +2091,7 @@ class ModuleAutoGen(AutoGen):
 # Add Module self
 m.update(gDict[(self.MetaFile.Path, self.Arch)].ModuleFilesHashDigest)
 
-with GlobalData.file_lock:
+with GlobalData.cache_lock:
 IR = gDict[(self.MetaFile.Path, self.Arch)]
 IR.PreMakefileHashHexDigest = m.hexdigest()
 gDict[(self.MetaFile.Path, self.Arch)] = IR
@@ -2159,7 +2159,7 @@ class ModuleAutoGen(AutoGen):
 m.update(Content)
 FileList.append((str(File), hashlib.md5(Content).hexdigest()))
 
-with GlobalData.file_lock:
+with GlobalData.cache_lock:
 IR = gDict[(self.MetaFile.Path, self.Arch)]
 IR.AutoGenFileList = self.AutoGenFileList.keys()
 IR.MakeHeaderFilesHashChain = FileList
@@ -,7 +,7 @@

[edk2-devel] [PATCH v5 1/5] BaseTools: Improve the cache hit in the edk2 build cache

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

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

Current cache hash algorithm does not parse and generate
the makefile to get the accurate dependency files for a
module. It instead use the platform and package meta files
to get the module depenedency in a quick but over approximate
way. These meta files are monolithic and involve many redundant
dependency for the module, which cause the module build
cache miss easily.
This patch introduces one more cache checkpoint and a new
hash algorithm besides the current quick one. The new hash
algorithm leverages the module makefile to achieve more
accurate and precise dependency info for a module. When
the build cache miss with the first quick hash, the
Basetool will caculate new one after makefile is generated
and then check again.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/AutoGenWorker.py |  21 +
 BaseTools/Source/Python/AutoGen/CacheIR.py   |  28 

 BaseTools/Source/Python/AutoGen/DataPipe.py  |   8 
 BaseTools/Source/Python/AutoGen/GenMake.py   | 223 
++-
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 639 
++-
 BaseTools/Source/Python/Common/GlobalData.py |   9 +
 BaseTools/Source/Python/build/build.py   | 129 
+
 7 files changed, 863 insertions(+), 194 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
old mode 100644
new mode 100755
index e583828741..a84ed46f2e
--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
@@ -182,6 +182,12 @@ class AutoGenWorkerInProcess(mp.Process):
 GlobalData.gDisableIncludePathCheck = False
 GlobalData.gFdfParser = self.data_pipe.Get("FdfParser")
 GlobalData.gDatabasePath = self.data_pipe.Get("DatabasePath")
+GlobalData.gBinCacheSource = self.data_pipe.Get("BinCacheSource")
+GlobalData.gBinCacheDest = self.data_pipe.Get("BinCacheDest")
+GlobalData.gCacheIR = self.data_pipe.Get("CacheIR")
+GlobalData.gEnableGenfdsMultiThread = 
self.data_pipe.Get("EnableGenfdsMultiThread")
+GlobalData.file_lock = self.file_lock
+CommandTarget = self.data_pipe.Get("CommandTarget")
 pcd_from_build_option = []
 for pcd_tuple in self.data_pipe.Get("BuildOptPcd"):
 pcd_id = ".".join((pcd_tuple[0],pcd_tuple[1]))
@@ -193,10 +199,13 @@ class AutoGenWorkerInProcess(mp.Process):
 FfsCmd = self.data_pipe.Get("FfsCommand")
 if FfsCmd is None:
 FfsCmd = {}
+GlobalData.FfsCmd = FfsCmd
 PlatformMetaFile = 
self.GetPlatformMetaFile(self.data_pipe.Get("P_Info").get("ActivePlatform"),
  
self.data_pipe.Get("P_Info").get("WorkspaceDir"))
 libConstPcd = self.data_pipe.Get("LibConstPcd")
 Refes = self.data_pipe.Get("REFS")
+GlobalData.libConstPcd = libConstPcd
+GlobalData.Refes = Refes
 while True:
 if self.module_queue.empty():
 break
@@ -223,8 +232,20 @@ class AutoGenWorkerInProcess(mp.Process):
 Ma.ConstPcd = 
libConstPcd[(Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path)]
 if 
(Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path) in Refes:
 Ma.ReferenceModules = 
Refes[(Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path)]
+if GlobalData.gBinCacheSource and CommandTarget in [None, "", 
"all"]:
+Ma.GenModuleFilesHash(GlobalData.gCacheIR)
+Ma.GenPreMakefileHash(GlobalData.gCacheIR)
+if Ma.CanSkipbyPreMakefileCache(GlobalData.gCacheIR):
+   continue
+

[edk2-devel] [PATCH v5 3/5] BaseTools: Change the [Arch][Name] module key in Build cache

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

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

Current build cache use the module's [self.Arch][self.Name]
info as the ModuleAutoGen object key in hash list and dictionary.
The [self.Arch][self.Name] is not safe as the module key because
there could be two modules with same module name and arch name in
one platform. E.g. A platform can override a module or library
instance in another different path, the overriding module can has
the same module name and arch name as the original one.
Directly use the ModuleAutoGen obj self as the key, because
the obj __hash__ and __repr__ attributes already contain the
full path and arch name.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/GenMake.py |  6 +-
 BaseTools/Source/Python/build/build.py | 48 

 2 files changed, 21 insertions(+), 33 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index ce047e7f64..3e6ec4085c 100755
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -959,16 +959,12 @@ cleanlib:
 # Keep the file to be checked
 headerFileDependencySet.add(aFileName)
 
-# Ensure that gModuleBuildTracking has been initialized per 
architecture
-if self._AutoGenObject.Arch not in GlobalData.gModuleBuildTracking:
-GlobalData.gModuleBuildTracking[self._AutoGenObject.Arch] = dict()
-
 # Check if a module dependency header file is missing from the 
module's MetaFile
 for aFile in headerFileDependencySet:
 if aFile in headerFilesInMetaFileSet:
 continue
 if GlobalData.gUseHashCache:
-
GlobalData.gModuleBuildTracking[self._AutoGenObject.Arch][self._AutoGenObject] 
= 'FAIL_METAFILE'
+GlobalData.gModuleBuildTracking[self._AutoGenObject] = 
'FAIL_METAFILE'
 EdkLogger.warn("build","Module MetaFile [Sources] is missing local 
header!",
 ExtraData = "Local Header: " + aFile + " not found in 
" + self._AutoGenObject.MetaFile.Path
 )
diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index d7c817b95c..299fa64311 100755
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -630,12 +630,11 @@ class BuildTask:
 
 # Set the value used by hash invalidation flow in 
GlobalData.gModuleBuildTracking to 'SUCCESS'
 # If Module or Lib is being tracked, it did not fail header check 
test, and built successfully
-if (self.BuildItem.BuildObject.Arch in GlobalData.gModuleBuildTracking 
and
-   self.BuildItem.BuildObject in 
GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject.Arch] and
-   
GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject.Arch][self.BuildItem.BuildObject]
 != 'FAIL_METAFILE' and
+if (self.BuildItem.BuildObject in GlobalData.gModuleBuildTracking and
+   GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject] != 
'FAIL_METAFILE' and
not BuildTask._ErrorFlag.isSet()
):
-
GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject.Arch][self.BuildItem.BuildObject]
 = 'SUCCESS'
+GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject] = 
'SUCCESS'
 
 # indicate there's a thread is available for another build task
 BuildTask._RunningQueueLock.acquire()
@@ -1171,25 +1170,24 @@ class Build():
 return
 
 # GlobalData.gModuleBuildTracking contains only modules or libs that 
cannot be skipped by hash
-for moduleAutoGenObjArch in GlobalData.gModuleBuildTracking.keys():
-for moduleAutoGenObj in 
GlobalData.gModuleBuildTracking[moduleAutoGenObjArch].keys():
-# Skip invalidating for Successful Module/Lib builds
-if 
GlobalData.gModuleBuildTracking[moduleAutoGenObjArch][moduleAutoGenObj] == 
'SUCCESS':
-continue
+for Ma in GlobalData.gModuleBuildTracking:
+# Skip invalidating for Successful Module/Lib builds
+if GlobalData.gModuleBuildTracking[Ma] == 'SUCCESS':
+continue
 
-# The module failed to build, failed to start building, or 
failed the header check test from this point on
+# The module failed to build, failed to start building, or failed 
the header check test from this point on
 
-# Remove .hash from build
-ModuleHashFile = os.path.join(moduleAutoGenObj.BuildDir, 
moduleAutoGenObj.Name + ".hash")
-if os.path.exists(ModuleHashFile):
-os.remove(ModuleHashFile)
+# Remove .hash from build
+ModuleHashFile = os.path.join(Ma.BuildDir, Ma.Name + ".hash")
+

[edk2-devel] [PATCH v5 4/5] BaseTools: Add GenFds multi-thread support in build cache

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

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

Fix the issue that the GenFds multi-thread will build fail
if enable the build cache together.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index 6db3b47a91..c489c3b9c4 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -1262,11 +1262,13 @@ class ModuleAutoGen(AutoGen):
 fStringIO.close ()
 fInputfile.close ()
 return OutputName
+
 @cached_property
 def OutputFile(self):
 retVal = set()
 OutputDir = self.OutputDir.replace('\\', '/').strip('/')
 DebugDir = self.DebugDir.replace('\\', '/').strip('/')
+FfsOutputDir = self.FfsOutputDir.replace('\\', '/').rstrip('/')
 for Item in self.CodaTargetList:
 File = Item.Target.Path.replace('\\', 
'/').strip('/').replace(DebugDir, '').replace(OutputDir, '').strip('/')
 retVal.add(File)
@@ -1282,6 +1284,12 @@ class ModuleAutoGen(AutoGen):
 if File.lower().endswith('.pdb'):
 retVal.add(File)
 
+for Root, Dirs, Files in os.walk(FfsOutputDir):
+for File in Files:
+if File.lower().endswith('.ffs') or 
File.lower().endswith('.offset') or File.lower().endswith('.raw') \
+or File.lower().endswith('.raw.txt'):
+retVal.add(File)
+
 return retVal
 
 ## Create AsBuilt INF file the module
@@ -1652,13 +1660,16 @@ class ModuleAutoGen(AutoGen):
 for File in self.OutputFile:
 File = str(File)
 if not os.path.isabs(File):
-File = os.path.join(self.OutputDir, File)
+NewFile = os.path.join(self.OutputDir, File)
+if not os.path.exists(NewFile):
+NewFile = os.path.join(self.FfsOutputDir, File)
+File = NewFile
 if os.path.exists(File):
-sub_dir = os.path.relpath(File, self.OutputDir)
-destination_file = os.path.join(FileDir, sub_dir)
-destination_dir = os.path.dirname(destination_file)
-CreateDirectory(destination_dir)
-CopyFileOnChange(File, destination_dir)
+if File.lower().endswith('.ffs') or 
File.lower().endswith('.offset') or File.lower().endswith('.raw') \
+or File.lower().endswith('.raw.txt'):
+self.CacheCopyFile(FfsDir, self.FfsOutputDir, File)
+else:
+self.CacheCopyFile(FileDir, self.OutputDir, File)
 
 def SaveHashChainFileToCache(self, gDict):
 if not GlobalData.gBinCacheDest:
-- 
2.17.1


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

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

[edk2-devel] [PATCH v5 2/5] BaseTools: Print first cache missing file for build cachle

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

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

When a module build cache miss, add support to print the first
cache missing file path and name.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/AutoGenWorker.py |  2 ++
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 76 

 2 files changed, 78 insertions(+)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
index a84ed46f2e..30d2f96fc7 100755
--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
@@ -246,6 +246,8 @@ class AutoGenWorkerInProcess(mp.Process):
 Ma.GenMakeHash(GlobalData.gCacheIR)
 if Ma.CanSkipbyMakeCache(GlobalData.gCacheIR):
 continue
+else:
+Ma.PrintFirstMakeCacheMissFile(GlobalData.gCacheIR)
 except Empty:
 pass
 except:
diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index 613b0d2fb8..6db3b47a91 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -2379,6 +2379,82 @@ class ModuleAutoGen(AutoGen):
 print("[cache hit]: checkpoint_Makefile:", self.MetaFile.Path, 
self.Arch)
 return True
 
+## Show the first file name which causes cache miss
+def PrintFirstMakeCacheMissFile(self, gDict):
+if not GlobalData.gBinCacheSource:
+return
+
+# skip binary module
+if self.IsBinaryModule:
+return
+
+if not (self.MetaFile.Path, self.Arch) in gDict:
+return
+
+# Only print cache miss file for the MakeCache not hit module
+if gDict[(self.MetaFile.Path, self.Arch)].MakeCacheHit:
+return
+
+if not gDict[(self.MetaFile.Path, self.Arch)].MakeHashChain:
+EdkLogger.quiet("[cache insight]: MakeHashChain is missing for: 
%s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+# Find the cache dir name through the .ModuleHashPair file info
+FileDir = path.join(GlobalData.gBinCacheSource, 
self.PlatformInfo.OutputDir, self.BuildTarget + "_" + self.ToolChain, 
self.Arch, self.SourceDir, self.MetaFile.BaseName)
+
+ModuleHashPairList = [] # tuple list: [tuple(PreMakefileHash, 
MakeHash)]
+ModuleHashPair = path.join(FileDir, self.Name + ".ModuleHashPair")
+if not os.path.exists(ModuleHashPair):
+EdkLogger.quiet("[cache insight]: Cannot find ModuleHashPair file 
for module: %s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+try:
+f = open(ModuleHashPair, 'r')
+ModuleHashPairList = json.load(f)
+f.close()
+except:
+EdkLogger.quiet("[cache insight]: Cannot load ModuleHashPair file 
for module: %s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+MakeHashSet = set()
+for idx, (PreMakefileHash, MakeHash) in enumerate (ModuleHashPairList):
+TargetHashDir = path.join(FileDir, str(MakeHash))
+if os.path.exists(TargetHashDir):
+MakeHashSet.add(MakeHash)
+if not MakeHashSet:
+EdkLogger.quiet("[cache insight]: Cannot find valid cache dir for 
module: %s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+TargetHash = list(MakeHashSet)[0]
+TargetHashDir = path.join(FileDir, str(TargetHash))
+if len(MakeHashSet) > 1 :
+EdkLogger.quiet("[cache insight]: found multiple cache dirs for 
this module, random select dir '%s' to search the first cache miss file: 
%s[%s]" % (TargetHash, self.MetaFile.Path, self.Arch))
+
+ListFile = path.join(TargetHashDir, self.Name + '.MakeHashChain')
+if os.path.exists(ListFile):
+try:
+f = open(ListFile, 'r')
+CachedList = json.load(f)
+f.close()
+except:
+EdkLogger.quiet("[cache insight]: Cannot load MakeHashChain 
file: %s" % ListFile)
+return
+else:
+EdkLogger.quiet("[cache insight]: Cannot find MakeHashChain file: 
%s" % ListFile)
+return
+
+CurrentList = gDict[(self.MetaFile.Path, self.Arch)].MakeHashChain
+for idx, (file, hash) in enumerate (CurrentList):
+(filecached, hashcached) = CachedList[idx]
+if file != filecached:
+EdkLogger.quiet("[cache insight]: first different file in 
%s[%s] is %s, the cached one is %s" % (self.MetaFile.Path, self.Arch, file, 
filecached))
+break
+if hash != hashcached:
+EdkLogger.quiet("[cache insight]: first cache miss file in

[edk2-devel] [PATCH v5 0/5] Build cache enhancement

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

This patch set is for the 201908 stable tag

Enhance the edk2 build cache with below patches:
Patch 01/05: Improve the cache hit rate through new cache checkpoint and hash 
algorithm
Patch 02/05: Print more info to explain why a module build cache miss
Patch 03/05: Fix the unsafe [self.Arch][self.Name] key usage in build cache
Patch 04/05  Add the GenFds multi-thread support in build cache
Patch 05/05  Improve the file saving and copying functions reliability in build 
cache


You can directly try this patch set in the branch:
https://github.com/shijunjing/edk2/tree/build_cache_improve_v5

V5:
Fix the method name typo in Misc.py from EdkLogger.quite() to EdkLogger.quiet()

V4:
Change single global lock into two locks, which are cache_lock and file_lock,
for better cache performance and IO reliability in windows

V3:
Add patch 5. To improve the autogen CopyFileOnChange() and SaveFileOnChange()
functions reliability for build cache

V2:
Enhance the SaveHashChainFileToCache() function in ModuleAutoGen.py and
not need to call f.close() in the "with open(xxx) as f:" block. The
with block will close the file automatically

V1:
Initial patch set

Shi, Steven (5):
  BaseTools: Improve the cache hit in the edk2 build cache
  BaseTools: Print first cache missing file for build cachle
  BaseTools: Change the [Arch][Name] module key in Build cache
  BaseTools: Add GenFds multi-thread support in build cache
  BaseTools: Improve the file saving and copying reliability

 .../Source/Python/AutoGen/AutoGenWorker.py|  27 +-
 BaseTools/Source/Python/AutoGen/CacheIR.py|  28 +
 BaseTools/Source/Python/AutoGen/DataPipe.py   |   8 +
 BaseTools/Source/Python/AutoGen/GenC.py   |   0
 BaseTools/Source/Python/AutoGen/GenMake.py| 229 +++---
 .../Source/Python/AutoGen/ModuleAutoGen.py| 738 --
 BaseTools/Source/Python/Common/GlobalData.py  |  11 +
 BaseTools/Source/Python/Common/Misc.py|  29 +-
 BaseTools/Source/Python/build/build.py| 182 +++--
 9 files changed, 1011 insertions(+), 241 deletions(-)
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/AutoGenWorker.py
 create mode 100755 BaseTools/Source/Python/AutoGen/CacheIR.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/DataPipe.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/GenC.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/GenMake.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
 mode change 100644 => 100755 BaseTools/Source/Python/Common/GlobalData.py
 mode change 100644 => 100755 BaseTools/Source/Python/Common/Misc.py
 mode change 100644 => 100755 BaseTools/Source/Python/build/build.py

-- 
2.17.1


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

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

Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

2019-08-14 Thread Paolo Bonzini

On 14/08/19 15:20, Yao, Jiewen wrote:
>> - Does this part require a new branch somewhere in the OVMF SEC code?
>>   How do we determine whether the CPU executing SEC is BSP or
>>   hot-plugged AP?
> [Jiewen] I think this is blocked from hardware perspective, since the first 
> instruction.
> There are some hardware specific registers can be used to determine if the 
> CPU is new added.
> I don’t think this must be same as the real hardware.
> You are free to invent some registers in device model to be used in OVMF hot 
> plug driver.

Yes, this would be a new operation mode for QEMU, that only applies to
hot-plugged CPUs.  In this mode the AP doesn't reply to INIT or SMI, in
fact it doesn't reply to anything at all.

>> - How do we tell the hot-plugged AP where to start execution? (I.e. that
>>   it should execute code at a particular pflash location.)
> [Jiewen] Same real mode reset vector at :FFF0.

You do not need a reset vector or INIT/SIPI/SIPI sequence at all in
QEMU.  The AP does not start execution at all when it is unplugged, so
no cache-as-RAM etc.

We only need to modify QEMU so that hot-plugged APIs do not reply to
INIT/SIPI/SMI.

> I don’t think there is problem for real hardware, who always has CAR.
> Can QEMU provide some CPU specific space, such as MMIO region?

Why is a CPU-specific region needed if every other processor is in SMM
and thus trusted.

>>   Does CPU hotplug apply only at the socket level? If the CPU is
>>   multi-core, what is responsible for hot-plugging all cores present in
>>   the socket?

I can answer this: the SMM handler would interact with the hotplug
controller in the same way that ACPI DSDT does normally.  This supports
multiple hotplugs already.

Writes to the hotplug controller from outside SMM would be ignored.

>>> (03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)
>>>  -- I am waiting for hot-add message.
>>
>> Maybe we can simplify this in QEMU by broadcasting an SMI to existent
>> processors immediately upon plugging the new CPU.

The QEMU DSDT could be modified (when secure boot is in effect) to OUT
to 0xB2 when hotplug happens.  It could write a well-known value to
0xB2, to be read by an SMI handler in edk2.


>>
>>>(NOTE: Host CPU can only
>> send
>>>  instruction in SMM mode. -- The register is SMM only)
>>
>> Sorry, I don't follow -- what register are we talking about here, and
>> why is the BSP needed to send anything at all? What "instruction" do you
>> have in mind?
> [Jiewen] The new CPU does not enable SMI at reset.
> At some point of time later, the CPU need enable SMI, right?
> The "instruction" here means, the host CPUs need tell to CPU to enable SMI.

Right, this would be a write to the CPU hotplug controller

>>> (04) Host CPU: (OS) get message from board that a new CPU is added.
>>>  (GPIO -> SCI)
>>>
>>> (05) Host CPU: (OS) All CPUs enter SMM (SCI->SWSMI) (NOTE: New CPU
>>>  will not enter CPU because SMI is disabled)
>>
>> I don't understand the OS involvement here. But, again, perhaps QEMU can
>> force all existent CPUs into SMM immediately upon adding the new CPU.
> [Jiewen] OS here means the Host CPU running code in OS environment, not in 
> SMM environment.

See above.

>>> (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM
>>>  rebase code.
>>>
>>> (07) Host CPU: (SMM) Send message to New CPU to Enable SMI.
>>
>> Aha, so this is the SMM-only register you mention in step (03). Is the
>> register specified in the Intel SDM?
> [Jiewen] Right. That is the register to let host CPU tell new CPU to enable 
> SMI.
> It is platform specific register. Not defined in SDM.
> You may invent one in device model.

See above.

>>> (10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE to
>>>  TSEG.
>>
>> What code does the new CPU execute after it completes step (10)? Does it
>> halt?
>
> [Jiewen] The new CPU exits SMM and return to original place - where it is
> interrupted to enter SMM - running code on the flash.

So in our case we'd need an INIT/SIPI/SIPI sequence between (06) and (07).

>>> (11) Host CPU: (SMM) Restore 38000.
>>
>> These steps (i.e., (06) through (11)) don't appear RAS-specific. The
>> only platform-specific feature seems to be SMI masking register, which
>> could be extracted into a new SmmCpuFeaturesLib API.
>>
>> Thus, would you please consider open sourcing firmware code for steps
>> (06) through (11)?
>>
>> Alternatively -- and in particular because the stack for step (01)
>> concerns me --, we could approach this from a high-level, functional
>> perspective. The states that really matter are the relocated SMBASE for
>> the new CPU, and the state of the full system, right at the end of step
>> (11).
>>
>> When the SMM setup quiesces during normal firmware boot, OVMF could
>> use
>> existent (finalized) SMBASE infomation to *pre-program* some virtual
>> QEMU hardware, with such state that would be expected, as

Re: [edk2-devel] [PATCH V2] ShellPkg/UefiShellDriver1CommandsLib: Make array big enough

2019-08-14 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

Thanks
-Jaben


> -Original Message-
> From: Augustine, Linson
> Sent: Wednesday, August 14, 2019 1:41 AM
> To: Gao, Zhichao ; devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray ;
> oleks...@ami.com
> Subject: RE: [edk2-devel] [PATCH V2]
> ShellPkg/UefiShellDriver1CommandsLib: Make array big enough
> 
> Reviewed-by: Linson Augustine 
> 
> Regards,
> -Linson
> 
> -Original Message-
> From: Gao, Zhichao
> Sent: Wednesday, August 14, 2019 2:03 PM
> To: devel@edk2.groups.io; Gao, Zhichao 
> Cc: Carsey, Jaben ; Ni, Ray ;
> oleks...@ami.com; Augustine, Linson 
> Subject: RE: [edk2-devel] [PATCH V2]
> ShellPkg/UefiShellDriver1CommandsLib: Make array big enough
> 
> Ping again.
> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Gao, Zhichao
> > Sent: Friday, July 26, 2019 3:47 PM
> > To: devel@edk2.groups.io
> > Cc: Carsey, Jaben ; Ni, Ray
> > ; oleks...@ami.com
> > Subject: FW: [edk2-devel] [PATCH V2]
> > ShellPkg/UefiShellDriver1CommandsLib: Make array big enough
> >
> > Ping. Please help to review it.
> >
> > Thanks,
> > Zhichao
> >
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Gao, Zhichao
> > Sent: Monday, July 22, 2019 2:58 PM
> > To: devel@edk2.groups.io
> > Cc: Carsey, Jaben ; Ni, Ray
> > ; Oleksiy 
> > Subject: [edk2-devel] [PATCH V2] ShellPkg/UefiShellDriver1CommandsLib:
> > Make array big enough
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1941
> >
> > The two CHAR16 array ChildCountStr and DeviceCountStr is defined to
> > hold the decimal string data of UINTN. The max of UINTN is
> > 18446744073709551615 and it contain 20 characters.
> > So make their size to 21 CHAR16s to hold the string data with a null-
> > terminate.
> > UnicodeValueToStringS regard the value input as INT64, and
> > 21 CHARs is enough to hold the lowest value with minus '-'.
> > Although the value shouldn't be such big.
> >
> > Cc: Jaben Carsey 
> > Cc: Ray Ni 
> > Cc: Oleksiy 
> > Signed-off-by: Zhichao Gao 
> > ---
> >
> > V2:
> > Update the copyright.
> >
> >  ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> > b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> > index 794b737bd1..27cd278cf0 100644
> > --- a/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> > +++ b/ShellPkg/Library/UefiShellDriver1CommandsLib/Drivers.c
> > @@ -2,7 +2,7 @@
> >Main file for Drivers shell Driver1 function.
> >
> >(C) Copyright 2012-2015 Hewlett-Packard Development Company,
> > L.P.
> > -  Copyright (c) 2010 - 2018, Intel Corporation. All rights
> > reserved.
> > +  Copyright (c) 2010 - 2019, Intel Corporation. All rights
> > + reserved.
> >SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -263,8 +263,8 @@ ShellCommandRunDrivers (
> >EFI_HANDLE  *HandleWalker;
> >UINTN   ChildCount;
> >UINTN   DeviceCount;
> > -  CHAR16  ChildCountStr[3];
> > -  CHAR16  DeviceCountStr[3];
> > +  CHAR16  ChildCountStr[21];
> > +  CHAR16  DeviceCountStr[21];
> >CHAR16  *Temp2;
> >CONST CHAR16*FullDriverName;
> >CHAR16  *TruncatedDriverName;
> > --
> > 2.21.0.windows.1
> >
> >
> >
> >
> >
> > 


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

View/Reply Online (#45613): https://edk2.groups.io/g/devel/message/45613
Mute This Topic: https://groups.io/mt/32861764/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] ShellPkg/UefiShellAcpiViewCommandLib: Remove the variable "Index"

2019-08-14 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

Thanks
-Jaben


> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, August 13, 2019 8:37 PM
> To: Zhang, Shenglei ; devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray 
> Subject: RE: [PATCH 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Remove
> the variable "Index"
> 
> Reviewed-by: Zhichao Gao 
> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Wednesday, August 14, 2019 11:07 AM
> > To: devel@edk2.groups.io
> > Cc: Carsey, Jaben ; Ni, Ray ;
> > Gao, Zhichao 
> > Subject: [PATCH 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Remove
> the
> > variable "Index"
> >
> > In IortParser.c ,the variable Index is set but not used in function
> > DumpIortNodeNamedComponent. This will cause build failure when
> building
> > ShellPkg with GCC.
> >
> > Cc: Jaben Carsey 
> > Cc: Ray Ni 
> > Cc: Zhichao Gao 
> > Signed-off-by: Shenglei Zhang 
> > ---
> >  .../UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c   | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git
> >
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c
> >
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c
> > index 8912d415a755..f1cdb9ac01d8 100644
> > ---
> >
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortParser.c
> > +++
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Iort/IortPars
> > +++ er.c
> > @@ -472,7 +472,6 @@ DumpIortNodeNamedComponent (
> >)
> >  {
> >UINT32 Offset;
> > -  UINT32 Index;
> >
> >Offset = ParseAcpi (
> >   TRUE,
> > @@ -485,7 +484,6 @@ DumpIortNodeNamedComponent (
> >
> >// Estimate the Device Name length
> >PrintFieldName (2, L"Device Object Name");
> > -  Index = 0;
> >
> >while ((*(Ptr + Offset) != 0) &&
> >   (Offset < Length)) {
> > --
> > 2.18.0.windows.1


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

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

Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT update

2019-08-14 Thread Laszlo Ersek

On 08/14/19 16:00, Gao, Liming wrote:
> Laszlo:

> 
> I cherry pick this patch from Mu project with the minimal change. 
> I can update the comment style. 

Yes, please. Thanks!

>> The gEfiMemoryTypeInformationGuid HOB is supposed to be built -- if it
>> is built at all -- no later than in the DXE IPL PEIM (if VariablePei is
>> included in the platform, and the underlying UEFI variable exists). Is
>> that correct?
>>
> gEfiMemoryTypeInformationGuid HOB is installed by platform PEI. 

Yes, that's what I meant by "no later than in the DXE IPL PEIM".

> If the platform PEI doesn't install this HOB, it means this feature is 
> disabled. 

PlatformPei is supposed to build the HOB in the first place, yes.

However, if it doesn't, then there still may be a feedback loop between
the DXE IPL PEIM and BDS. The former builds the HOB from the UEFI
variable, and the latter updates the variable (as I understand) for
future boots.

Thanks
Laszlo

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

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

Re: [edk2-devel] [PATCH] MdePkg: Add STATIC_ASSERT macro

2019-08-14 Thread Laszlo Ersek

(adding back the list)

On 08/13/19 16:30, vit9...@protonmail.com wrote:
> Laszlo,
> 
> GCC implemented _Static_assert in 4.6. See its official wiki for C11 
> compatibility documentation:
> 
> https://gcc.gnu.org/wiki/C11Status

Awesome news!

Once this is upstreamed, we should go through all the ASSERT()s in the
code, and replace those that are compile-time checkable with
STATIC_ASSERT(). I know that I've added quite a few ASSERT()s that I
wished would be checked at build time.

Of course, I'll probably never have time for that. :/

Thanks
Laszlo

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

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

[edk2-devel] Cancelled Event: TianoCore Design / Bug Triage - EMEA - Wednesday, 14 August 2019 #cal-cancelled

2019-08-14 Thread devel@edk2.groups.io Calendar

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCEL
CALSCALE:GREGORIAN
BEGIN:VEVENT
STATUS:CANCELLED
UID:calendar.15...@groups.io
DTSTAMP:20190814T144618Z
ORGANIZER;CN=Stephano Cetola:mailto:stephano.cet...@linux.intel.com
DTSTART;TZID=America/Los_Angeles:20190814T08
DTEND;TZID=America/Los_Angeles:20190814T09
SUMMARY:TianoCore Design / Bug Triage - EMEA
DESCRIPTION:Join Zoom Meeting\n\nhttps://zoom.us/j/695893389\n\nOne tap mobile\n\n+17207072699,,695893389# US\n\n+16465588656,,695893389# US (New York)\n\nDial by your location\n\n+1 720 707 2699 US\n\n+1 646 558 8656 US (New York)\n\nMeeting ID: 695 893 389\n\nFind your local number: https://zoom.us/u/abOtdJckxL
LOCATION:https://zoom.us/j/695893389
RECURRENCE-ID;TZID=America/Los_Angeles:20190814T08
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] Cancelled Event: TianoCore Design / Bug Triage - EMEA - Wednesday, 14 August 2019 #cal-cancelled

2019-08-14 Thread Stephano Cetola

No topics this week.

Also, I'll be at the Open Source Summit next week. Ray will likely run
the design meeting on Thursday, and unless anyone has any topics for
Wednesday, we'll probably cancel that one.

Cheers,
Stephano

On Wed, Aug 14, 2019 at 7:46 AM devel@edk2.groups.io Calendar
 wrote:
>
> Cancelled: TianoCore Design / Bug Triage - EMEA
>
> This event has been cancelled.
>
> When:
> Wednesday, 14 August 2019
> 8:00am to 9:00am
> (UTC-07:00) America/Los Angeles
>
> Where:
> https://zoom.us/j/695893389
>
> Organizer:
> stephano.cet...@linux.intel.com
>
> 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 (#45611): https://edk2.groups.io/g/devel/message/45611
Mute This Topic: https://groups.io/mt/32864423/21656
Mute #cal-cancelled: https://groups.io/mk?hashtag=cal-cancelled=3846945
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] static data in dxe_runtime modules

2019-08-14 Thread Laszlo Ersek

On 08/13/19 13:23, Roman Kagan wrote:
> On Tue, Aug 13, 2019 at 11:10:27AM +0200, Laszlo Ersek wrote:
>> On 08/12/19 20:43, Roman Kagan wrote:
>>> On Fri, Aug 09, 2019 at 04:07:00PM +, Roman Kagan via Groups.Io wrote:
 On Thu, Aug 08, 2019 at 07:39:14PM +0200, Laszlo Ersek wrote:
> On 08/07/19 19:41, Andrew Fish wrote:
>>> On Aug 7, 2019, at 10:29 AM, Laszlo Ersek  wrote:
>>> On 08/05/19 12:18, Roman Kagan wrote:
 On Sat, Aug 03, 2019 at 04:03:04AM +0200, Laszlo Ersek via Groups.Io 
 wrote:
> On 08/01/19 21:16, Roman Kagan wrote:
>>> I'm convinced that OpenSSL needs to expose a new API for this particular
>>> problem.

 Since, as you point out below, the problem only affects the essentially
 broken configuration (SECURE_BOOT_ENABLE && !SMM_REQUIRE), I'm fine with
 saving time and effort and sticking to the hack-ish approach proposed in
 the bugzilla issue, which is to iterate over "thread-local" pointers and
 EfiConvertPointer() on each.  (As long as it fixes the problem of
 course; I'll test and report back.)
>>>
>>> It doesn't :(  It just gets slightly further and hits another static
>>> pointer variable which is not part of the thread-local array:
>>>
>>> ...
>>>   Pkcs7Verify
>>> EVP_add_digest
>>>   OBJ_NAME_add
>>>
>>> this one uses a few static pointer variables that are also initialized
>>> on demand and become stale upon SetVirtualAddressMap().
>>
>> So it looks like the issue can't be solved without making OpenSSL aware
>> of this use case.
> 
> Is reloading the module from scratch ruled out completely?

Not my place to say authoritatively, but:
- it would be a first, as much as I can say,
- it would duplicate (in purpose) an existing facility.

Personally I'd expect it to be rejected, but it's not up to me. If
you're willing to "build one to (possibly) throw away", that could be
the most direct way to get authoritative (= maintainer) feedback.

Thanks
Laszlo

> I'd try to cook up a patch for that unless there's a strong no-go.
> 
> Thanks,
> Roman.
> 


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

View/Reply Online (#45615): https://edk2.groups.io/g/devel/message/45615
Mute This Topic: https://groups.io/mt/32686575/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/1] Added GOP driver for DisplayLink-based Universal USB Docks to edk2-platforms

2019-08-14 Thread Michael D Kinney

Hi Andy,

Thanks for the contribution.  Is this patch for the edk2-platform repo?  The 
email subject can help clarify the intended repo.

Also, we prefer the patches to be provided inline instead of an attachment.  
You can use the
'git send-email' feature to do this.  Here are a couple links to useful wikis.

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

I also noticed looking at the patch file that there are some inconsistencies 
with the
EDK II C Coding Standards.  Most are around function headers and indents.  Here 
is a link
to the latest version:

https://www.gitbook.com/download/pdf/book/edk2-docs/edk-ii-c-coding-standards-specification

I see a few #if 0 and commented out lines of code and TODO comments.  Can you 
please clean these up
and if needed add Tianocore Bugzillas for future enhancements/work items for 
this driver.

https://bugzilla.tianocore.org/

I also noticed that you are using named fields to initialize C structures:

STATIC CONST struct VideoMode ModeData[] = {
+  {
+ // 640 x 480 @ 60Hz
+.Reserved2 = 2,
+.PixelClock = 2517,
+.HActive = 640,
+.HBlanking = 160,
+.HSyncOffset = 16,
+.HSyncWidth = 96,

I do like this style because it has better self documentation of the field being
initialized to a value.  However, I do not see this style in the rest of the 
EDK II
sources, so I am concerned that we may have required compilers for the EDK II
that may not support this syntax.

If we find all the supported compilers do support this syntax, this would be
a great addition to the EDK II C Coding Standards.

I am curious how this driver interacts with the ConSplitter when displays
are hot added and hot removed.  I see a reference to a feature that appears
to sync the GOP content between frame buffers when a display is hot added.
I would be better if the common code in the ConSplitter handled these types
of operations instead of putting that code in individual GOP drivers. I have
added Ray to this thread who may have ideas on how to handle these hot
add events.

Thanks,

Mike

From: Andy Hayes [mailto:andy.ha...@displaylink.com]
Sent: Wednesday, August 14, 2019 7:44 AM
To: devel@edk2.groups.io
Cc: Leif Lindholm ; Kinney, Michael D 

Subject: [PATCH v1 0/1] Added GOP driver for DisplayLink-based Universal USB 
Docks to edk2-platforms

>From 4a42eb997aeb3699217b40bf3bc47dec56458847 Mon Sep 17 00:00:00 2001
From: "Andy Hayes" < 
andy.ha...@displaylink.com >
Date: Wed, 14 Aug 2019 15:30:20 +0100
Subject: [PATCH v1 0/1] Added GOP graphics driver for DisplayLink-based 
Universal USB Docks to edk2-platforms

andy.ha...@displaylink.com (1):
  Added GOP driver for USB Docks which use DisplayLink chips.

.../DisplayLinkPkg/DisplayLinkPkg.dsc |   61 +
.../DisplayLinkGop/DisplayLinkGopDxe.inf  |   63 +
.../DisplayLinkPkg/DisplayLinkGop/Edid.h  |  129 ++
.../DisplayLinkGop/UsbDescriptors.h   |  109 ++
.../DisplayLinkGop/UsbDisplayLink.h   |  284 +
.../DisplayLinkGop/CapabilityDescriptor.c |  137 ++
.../DisplayLinkGop/ComponentName.c|  235 
.../DisplayLinkPkg/DisplayLinkGop/Edid.c  |  598 +
.../DisplayLinkPkg/DisplayLinkGop/Gop.c   |  587 +
.../DisplayLinkGop/UsbDescriptors.c   |  144 +++
.../DisplayLinkGop/UsbDisplayLink.c   | 1109 +
.../DisplayLinkGop/UsbTransfer.c  |  180 +++
.../DisplayLinkGop/VideoModes.c   |  254 
Drivers/DisplayLink/DisplayLinkPkg/ReadMe.md  |   77 ++
Maintainers.txt   |5 +
15 files changed, 3972 insertions(+)
create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc
create mode 100644 
Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/DisplayLinkGopDxe.inf
create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.h
create mode 100644 
Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.h
create mode 100644 
Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.h
create mode 100644 
Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/CapabilityDescriptor.c
create mode 100644 
Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/ComponentName.c
create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c
create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Gop.c
create mode 100644 
Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.c
create mode 100644 
Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.c
create mode 100644 
Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
create mode 100644 
Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/VideoModes.c
create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/ReadMe.md

--
2.17.1

Re: [edk2-devel] [PATCH v1 0/1] Added GOP driver for DisplayLink-based Universal USB Docks to edk2-platforms

2019-08-14 Thread Leif Lindholm

Hi Andy,

Many thanks for this submission.

I am finding a few issues when building with gcc/clang (I expect you
use Visual Studio).

The RELEASE target barfs with
.../edk2-platforms/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Gop.c:363:1:
error: unused function 'CalculateRefreshRate'
since the function is only called from a DEBUG statement.
Could be resolved by putting the function inside #ifndef MDEPKG_NDEBUG

Clang triggers an error on the
USB_DISPLAYLINK_DEV_FROM_GRAPHICS_OUTPUT_PROTOCOL macro which seems to
go away if the USB_DISPLAYLINK_DEV_SIGNATURE macro is moved below the
USB_DISPLAYLINK_DEV definition. (I haven't bothered to figure out why
this helps.)

The NOOPT build fails for IA32/X64 on clang with
.../edk2-platforms/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.c:35:
undefined reference to `memset'
You could get rid of this by doing the assignment separate from the
definition. (Indeed, I believe this is one of the reasons for the
rule.)

On X64/clang, the build fails with
.../edk2-platforms/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.c:410:3:
error: '__builtin_ms_va_start' used in System V ABI function
Adding EFIAPI to the definition/declaration of DlGopPrintTextToScreen
makes this one go away.

Best Regards,

Leif

On Wed, Aug 14, 2019 at 02:43:43PM +, Andy Hayes wrote:
> From 4a42eb997aeb3699217b40bf3bc47dec56458847 Mon Sep 17 00:00:00 2001
> From: "Andy Hayes" < andy.ha...@displaylink.com >
> Date: Wed, 14 Aug 2019 15:30:20 +0100
> Subject: [PATCH v1 0/1] Added GOP graphics driver for DisplayLink-based 
> Universal USB Docks to edk2-platforms
> 
> andy.ha...@displaylink.com (1):
>   Added GOP driver for USB Docks which use DisplayLink chips.
> 
> .../DisplayLinkPkg/DisplayLinkPkg.dsc |   61 +
> .../DisplayLinkGop/DisplayLinkGopDxe.inf  |   63 +
> .../DisplayLinkPkg/DisplayLinkGop/Edid.h  |  129 ++
> .../DisplayLinkGop/UsbDescriptors.h   |  109 ++
> .../DisplayLinkGop/UsbDisplayLink.h   |  284 +
> .../DisplayLinkGop/CapabilityDescriptor.c |  137 ++
> .../DisplayLinkGop/ComponentName.c|  235 
> .../DisplayLinkPkg/DisplayLinkGop/Edid.c  |  598 +
> .../DisplayLinkPkg/DisplayLinkGop/Gop.c   |  587 +
> .../DisplayLinkGop/UsbDescriptors.c   |  144 +++
> .../DisplayLinkGop/UsbDisplayLink.c   | 1109 +
> .../DisplayLinkGop/UsbTransfer.c  |  180 +++
> .../DisplayLinkGop/VideoModes.c   |  254 
> Drivers/DisplayLink/DisplayLinkPkg/ReadMe.md  |   77 ++
> Maintainers.txt   |5 +
> 15 files changed, 3972 insertions(+)
> create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc
> create mode 100644 
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/DisplayLinkGopDxe.inf
> create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.h
> create mode 100644 
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.h
> create mode 100644 
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.h
> create mode 100644 
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/CapabilityDescriptor.c
> create mode 100644 
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/ComponentName.c
> create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c
> create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Gop.c
> create mode 100644 
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.c
> create mode 100644 
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.c
> create mode 100644 
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> create mode 100644 
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/VideoModes.c
> create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/ReadMe.md
> 
> --
> 2.17.1

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

View/Reply Online (#45624): https://edk2.groups.io/g/devel/message/45624
Mute This Topic: https://groups.io/mt/32864415/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] MdeModulePkg/DxeIplPeim: Initialize pointer PageMapLevel5Entry

2019-08-14 Thread Laszlo Ersek

On 08/14/19 09:37, Zhang, Shenglei wrote:
> Initialize PageMapLevel5Entry at the beginning of the function.
> 
> This commit will fix a GCC 4.8.5 build failure introduced by commit
> b3527dedc3951f061c5a73cb4fb2b0f95f47e08b.
> 
> OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
> The commit 46f8a6891606746ca8b1e684ac379ce271306dc0 seems not to fix
> the build failure completely.
> 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Cc: Hao A Wu 
> Signed-off-by: Shenglei Zhang 
> ---
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> index 2389f3eb485b..aae80536ac3d 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> @@ -652,6 +652,8 @@ CreateIdentityMappingPageTables (
>UINT64AddressEncMask;
>IA32_CR4  Cr4;
>  
> +  PageMapLevel5Entry = NULL;
> +
>//
>// Make sure AddressEncMask is contained to smallest supported address 
> field
>//
> 

If you are convinced that we need this assignment *only* for suppressing
an invalid compiler warning, then please add a comment about it:

  //
  // set PageMapLevel5Entry to suppress incorrect compiler/analyzer
  // warnings
  //

Related documentation BZ:

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

... Just a suggestion from my side; I defer to the MdeModulePkg maintainers.

Thanks
Laszlo

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

View/Reply Online (#45625): https://edk2.groups.io/g/devel/message/45625
Mute This Topic: https://groups.io/mt/32861558/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/1] Added GOP driver for DisplayLink-based Universal USB Docks to edk2-platforms

2019-08-14 Thread Leif Lindholm

Hi Andy,

A follow-up - a few more things need changing:

UsbDisplayLink.h (well, any .h file) should only contain the headers
it itself requires.
Moreover, the inclusion of wchar.h must disappear completely.
Instead, use CHAR16 * in the two locations in UsbDisplayLink.c.

Removing wchar.h will then trip you up in Edid.h, at
#define EDID_HEADER_SIZE  ((size_t)8)
Please change the size_t to UINTN.

Finally, you need to (and now can after the above changes) get rid of
#undef _DEBUG

#undef NULL
#undef _ASSERT
in UsbDisplayLink.h.

With these additional changes, the driver builds successfully across
GCC 8.3 and CLANG 7.0 for AARCH64/ARM/IA32/X64.

Best Regards,

Leif

On Wed, Aug 14, 2019 at 06:03:51PM +0100, Leif Lindholm wrote:
> Hi Andy,
> 
> Many thanks for this submission.
> 
> I am finding a few issues when building with gcc/clang (I expect you
> use Visual Studio).
> 
> The RELEASE target barfs with
> .../edk2-platforms/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Gop.c:363:1:
> error: unused function 'CalculateRefreshRate'
> since the function is only called from a DEBUG statement.
> Could be resolved by putting the function inside #ifndef MDEPKG_NDEBUG
> 
> Clang triggers an error on the
> USB_DISPLAYLINK_DEV_FROM_GRAPHICS_OUTPUT_PROTOCOL macro which seems to
> go away if the USB_DISPLAYLINK_DEV_SIGNATURE macro is moved below the
> USB_DISPLAYLINK_DEV definition. (I haven't bothered to figure out why
> this helps.)
> 
> The NOOPT build fails for IA32/X64 on clang with
> .../edk2-platforms/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.c:35:
> undefined reference to `memset'
> You could get rid of this by doing the assignment separate from the
> definition. (Indeed, I believe this is one of the reasons for the
> rule.)
> 
> On X64/clang, the build fails with
> .../edk2-platforms/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.c:410:3:
> error: '__builtin_ms_va_start' used in System V ABI function
> Adding EFIAPI to the definition/declaration of DlGopPrintTextToScreen
> makes this one go away.
> 
> Best Regards,
> 
> Leif
> 
> On Wed, Aug 14, 2019 at 02:43:43PM +, Andy Hayes wrote:
> > From 4a42eb997aeb3699217b40bf3bc47dec56458847 Mon Sep 17 00:00:00 2001
> > From: "Andy Hayes" < andy.ha...@displaylink.com >
> > Date: Wed, 14 Aug 2019 15:30:20 +0100
> > Subject: [PATCH v1 0/1] Added GOP graphics driver for DisplayLink-based 
> > Universal USB Docks to edk2-platforms
> > 
> > andy.ha...@displaylink.com (1):
> >   Added GOP driver for USB Docks which use DisplayLink chips.
> > 
> > .../DisplayLinkPkg/DisplayLinkPkg.dsc |   61 +
> > .../DisplayLinkGop/DisplayLinkGopDxe.inf  |   63 +
> > .../DisplayLinkPkg/DisplayLinkGop/Edid.h  |  129 ++
> > .../DisplayLinkGop/UsbDescriptors.h   |  109 ++
> > .../DisplayLinkGop/UsbDisplayLink.h   |  284 +
> > .../DisplayLinkGop/CapabilityDescriptor.c |  137 ++
> > .../DisplayLinkGop/ComponentName.c|  235 
> > .../DisplayLinkPkg/DisplayLinkGop/Edid.c  |  598 +
> > .../DisplayLinkPkg/DisplayLinkGop/Gop.c   |  587 +
> > .../DisplayLinkGop/UsbDescriptors.c   |  144 +++
> > .../DisplayLinkGop/UsbDisplayLink.c   | 1109 +
> > .../DisplayLinkGop/UsbTransfer.c  |  180 +++
> > .../DisplayLinkGop/VideoModes.c   |  254 
> > Drivers/DisplayLink/DisplayLinkPkg/ReadMe.md  |   77 ++
> > Maintainers.txt   |5 +
> > 15 files changed, 3972 insertions(+)
> > create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc
> > create mode 100644 
> > Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/DisplayLinkGopDxe.inf
> > create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.h
> > create mode 100644 
> > Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.h
> > create mode 100644 
> > Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.h
> > create mode 100644 
> > Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/CapabilityDescriptor.c
> > create mode 100644 
> > Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/ComponentName.c
> > create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c
> > create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Gop.c
> > create mode 100644 
> > Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDescriptors.c
> > create mode 100644 
> > Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbDisplayLink.c
> > create mode 100644 
> > Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> > create mode 100644 
> > Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/VideoModes.c
> > create mode 100644 Drivers/DisplayLink/DisplayLinkPkg/ReadMe.md
> > 
> > --
> > 2.17.1
> 
> 

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

View/Reply Online (#45626):

[edk2-devel] [PATCH v4 0/5] Build cache enhancement

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

Enhance the edk2 build cache with below patches:
Patch 01/05: Improve the cache hit rate through new cache checkpoint and hash 
algorithm
Patch 02/05: Print more info to explain why a module build cache miss
Patch 03/05: Fix the unsafe [self.Arch][self.Name] key usage in build cache
Patch 04/05  Add the GenFds multi-thread support in build cache
Patch 05/05  Improve the file saving and copying functions reliability in build 
cache


You can directly try this patch set in the branch:
https://github.com/shijunjing/edk2/tree/build_cache_improve_v4

V4:
Change single global lock into two locks, which are cache_lock and file_lock,
for better cache performance and IO reliability in windows

V3:
Add patch 5. To improve the autogen CopyFileOnChange() and SaveFileOnChange()
functions reliability for build cache

V2:
Enhance the SaveHashChainFileToCache() function in ModuleAutoGen.py and
not need to call f.close() in the "with open(xxx) as f:" block. The
with block will close the file automatically

V1:
Initial patch set

Shi, Steven (5):
  BaseTools: Improve the cache hit in the edk2 build cache
  BaseTools: Print first cache missing file for build cachle
  BaseTools: Change the [Arch][Name] module key in Build cache
  BaseTools: Add GenFds multi-thread support in build cache
  BaseTools: Improve the file saving and copying reliability

 .../Source/Python/AutoGen/AutoGenWorker.py|  27 +-
 BaseTools/Source/Python/AutoGen/CacheIR.py|  28 +
 BaseTools/Source/Python/AutoGen/DataPipe.py   |   8 +
 BaseTools/Source/Python/AutoGen/GenC.py   |   0
 BaseTools/Source/Python/AutoGen/GenMake.py| 229 +++---
 .../Source/Python/AutoGen/ModuleAutoGen.py| 738 --
 BaseTools/Source/Python/Common/GlobalData.py  |  11 +
 BaseTools/Source/Python/Common/Misc.py|  29 +-
 BaseTools/Source/Python/build/build.py| 182 +++--
 9 files changed, 1011 insertions(+), 241 deletions(-)
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/AutoGenWorker.py
 create mode 100755 BaseTools/Source/Python/AutoGen/CacheIR.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/DataPipe.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/GenC.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/GenMake.py
 mode change 100644 => 100755 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
 mode change 100644 => 100755 BaseTools/Source/Python/Common/GlobalData.py
 mode change 100644 => 100755 BaseTools/Source/Python/Common/Misc.py
 mode change 100644 => 100755 BaseTools/Source/Python/build/build.py

-- 
2.17.1


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

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

[edk2-devel] [PATCH v4 3/5] BaseTools: Change the [Arch][Name] module key in Build cache

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

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

Current build cache use the module's [self.Arch][self.Name]
info as the ModuleAutoGen object key in hash list and dictionary.
The [self.Arch][self.Name] is not safe as the module key because
there could be two modules with same module name and arch name in
one platform. E.g. A platform can override a module or library
instance in another different path, the overriding module can has
the same module name and arch name as the original one.
Directly use the ModuleAutoGen obj self as the key, because
the obj __hash__ and __repr__ attributes already contain the
full path and arch name.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/GenMake.py |  6 +-
 BaseTools/Source/Python/build/build.py | 48 

 2 files changed, 21 insertions(+), 33 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index ce047e7f64..3e6ec4085c 100755
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -959,16 +959,12 @@ cleanlib:
 # Keep the file to be checked
 headerFileDependencySet.add(aFileName)
 
-# Ensure that gModuleBuildTracking has been initialized per 
architecture
-if self._AutoGenObject.Arch not in GlobalData.gModuleBuildTracking:
-GlobalData.gModuleBuildTracking[self._AutoGenObject.Arch] = dict()
-
 # Check if a module dependency header file is missing from the 
module's MetaFile
 for aFile in headerFileDependencySet:
 if aFile in headerFilesInMetaFileSet:
 continue
 if GlobalData.gUseHashCache:
-
GlobalData.gModuleBuildTracking[self._AutoGenObject.Arch][self._AutoGenObject] 
= 'FAIL_METAFILE'
+GlobalData.gModuleBuildTracking[self._AutoGenObject] = 
'FAIL_METAFILE'
 EdkLogger.warn("build","Module MetaFile [Sources] is missing local 
header!",
 ExtraData = "Local Header: " + aFile + " not found in 
" + self._AutoGenObject.MetaFile.Path
 )
diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index d7c817b95c..299fa64311 100755
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -630,12 +630,11 @@ class BuildTask:
 
 # Set the value used by hash invalidation flow in 
GlobalData.gModuleBuildTracking to 'SUCCESS'
 # If Module or Lib is being tracked, it did not fail header check 
test, and built successfully
-if (self.BuildItem.BuildObject.Arch in GlobalData.gModuleBuildTracking 
and
-   self.BuildItem.BuildObject in 
GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject.Arch] and
-   
GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject.Arch][self.BuildItem.BuildObject]
 != 'FAIL_METAFILE' and
+if (self.BuildItem.BuildObject in GlobalData.gModuleBuildTracking and
+   GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject] != 
'FAIL_METAFILE' and
not BuildTask._ErrorFlag.isSet()
):
-
GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject.Arch][self.BuildItem.BuildObject]
 = 'SUCCESS'
+GlobalData.gModuleBuildTracking[self.BuildItem.BuildObject] = 
'SUCCESS'
 
 # indicate there's a thread is available for another build task
 BuildTask._RunningQueueLock.acquire()
@@ -1171,25 +1170,24 @@ class Build():
 return
 
 # GlobalData.gModuleBuildTracking contains only modules or libs that 
cannot be skipped by hash
-for moduleAutoGenObjArch in GlobalData.gModuleBuildTracking.keys():
-for moduleAutoGenObj in 
GlobalData.gModuleBuildTracking[moduleAutoGenObjArch].keys():
-# Skip invalidating for Successful Module/Lib builds
-if 
GlobalData.gModuleBuildTracking[moduleAutoGenObjArch][moduleAutoGenObj] == 
'SUCCESS':
-continue
+for Ma in GlobalData.gModuleBuildTracking:
+# Skip invalidating for Successful Module/Lib builds
+if GlobalData.gModuleBuildTracking[Ma] == 'SUCCESS':
+continue
 
-# The module failed to build, failed to start building, or 
failed the header check test from this point on
+# The module failed to build, failed to start building, or failed 
the header check test from this point on
 
-# Remove .hash from build
-ModuleHashFile = os.path.join(moduleAutoGenObj.BuildDir, 
moduleAutoGenObj.Name + ".hash")
-if os.path.exists(ModuleHashFile):
-os.remove(ModuleHashFile)
+# Remove .hash from build
+ModuleHashFile = os.path.join(Ma.BuildDir, Ma.Name + ".hash")
+

[edk2-devel] [PATCH v4 1/5] BaseTools: Improve the cache hit in the edk2 build cache

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

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

Current cache hash algorithm does not parse and generate
the makefile to get the accurate dependency files for a
module. It instead use the platform and package meta files
to get the module depenedency in a quick but over approximate
way. These meta files are monolithic and involve many redundant
dependency for the module, which cause the module build
cache miss easily.
This patch introduces one more cache checkpoint and a new
hash algorithm besides the current quick one. The new hash
algorithm leverages the module makefile to achieve more
accurate and precise dependency info for a module. When
the build cache miss with the first quick hash, the
Basetool will caculate new one after makefile is generated
and then check again.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/AutoGenWorker.py |  21 +
 BaseTools/Source/Python/AutoGen/CacheIR.py   |  28 

 BaseTools/Source/Python/AutoGen/DataPipe.py  |   8 
 BaseTools/Source/Python/AutoGen/GenMake.py   | 223 
++-
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 639 
++-
 BaseTools/Source/Python/Common/GlobalData.py |   9 +
 BaseTools/Source/Python/build/build.py   | 129 
+
 7 files changed, 863 insertions(+), 194 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
old mode 100644
new mode 100755
index e583828741..a84ed46f2e
--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
@@ -182,6 +182,12 @@ class AutoGenWorkerInProcess(mp.Process):
 GlobalData.gDisableIncludePathCheck = False
 GlobalData.gFdfParser = self.data_pipe.Get("FdfParser")
 GlobalData.gDatabasePath = self.data_pipe.Get("DatabasePath")
+GlobalData.gBinCacheSource = self.data_pipe.Get("BinCacheSource")
+GlobalData.gBinCacheDest = self.data_pipe.Get("BinCacheDest")
+GlobalData.gCacheIR = self.data_pipe.Get("CacheIR")
+GlobalData.gEnableGenfdsMultiThread = 
self.data_pipe.Get("EnableGenfdsMultiThread")
+GlobalData.file_lock = self.file_lock
+CommandTarget = self.data_pipe.Get("CommandTarget")
 pcd_from_build_option = []
 for pcd_tuple in self.data_pipe.Get("BuildOptPcd"):
 pcd_id = ".".join((pcd_tuple[0],pcd_tuple[1]))
@@ -193,10 +199,13 @@ class AutoGenWorkerInProcess(mp.Process):
 FfsCmd = self.data_pipe.Get("FfsCommand")
 if FfsCmd is None:
 FfsCmd = {}
+GlobalData.FfsCmd = FfsCmd
 PlatformMetaFile = 
self.GetPlatformMetaFile(self.data_pipe.Get("P_Info").get("ActivePlatform"),
  
self.data_pipe.Get("P_Info").get("WorkspaceDir"))
 libConstPcd = self.data_pipe.Get("LibConstPcd")
 Refes = self.data_pipe.Get("REFS")
+GlobalData.libConstPcd = libConstPcd
+GlobalData.Refes = Refes
 while True:
 if self.module_queue.empty():
 break
@@ -223,8 +232,20 @@ class AutoGenWorkerInProcess(mp.Process):
 Ma.ConstPcd = 
libConstPcd[(Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path)]
 if 
(Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path) in Refes:
 Ma.ReferenceModules = 
Refes[(Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path)]
+if GlobalData.gBinCacheSource and CommandTarget in [None, "", 
"all"]:
+Ma.GenModuleFilesHash(GlobalData.gCacheIR)
+Ma.GenPreMakefileHash(GlobalData.gCacheIR)
+if Ma.CanSkipbyPreMakefileCache(GlobalData.gCacheIR):
+   continue
+

[edk2-devel] [PATCH v4 5/5] BaseTools: Improve the file saving and copying reliability

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

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

The Basetool CopyFileOnChange() and SaveFileOnChange()
functions might raise the IOError occasionally when build
in Windows with multi-process and build cache enabled.
The CopyFileOnChange() and SaveFileOnChange() might be invoked
in multiple sub-processes simultaneously, and this patch adds
a global lock to sync these functions invoking which can
harden their reliability.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/AutoGenWorker.py |  4 +++-
 BaseTools/Source/Python/AutoGen/GenC.py  |  0
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 18 +-
 BaseTools/Source/Python/Common/GlobalData.py |  2 ++
 BaseTools/Source/Python/Common/Misc.py   | 29 
+++--
 BaseTools/Source/Python/build/build.py   |  5 -
 6 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
index 30d2f96fc7..21c5efbe6a 100755
--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
@@ -133,7 +133,7 @@ class AutoGenManager(threading.Thread):
 def kill(self):
 self.feedback_q.put(None)
 class AutoGenWorkerInProcess(mp.Process):
-def __init__(self,module_queue,data_pipe_file_path,feedback_q,file_lock, 
share_data,log_q,error_event):
+def 
__init__(self,module_queue,data_pipe_file_path,feedback_q,file_lock,cache_lock,share_data,log_q,error_event):
 mp.Process.__init__(self)
 self.module_queue = module_queue
 self.data_pipe_file_path =data_pipe_file_path
@@ -141,6 +141,7 @@ class AutoGenWorkerInProcess(mp.Process):
 self.feedback_q = feedback_q
 self.PlatformMetaFileSet = {}
 self.file_lock = file_lock
+self.cache_lock = cache_lock
 self.share_data = share_data
 self.log_q = log_q
 self.error_event = error_event
@@ -187,6 +188,7 @@ class AutoGenWorkerInProcess(mp.Process):
 GlobalData.gCacheIR = self.data_pipe.Get("CacheIR")
 GlobalData.gEnableGenfdsMultiThread = 
self.data_pipe.Get("EnableGenfdsMultiThread")
 GlobalData.file_lock = self.file_lock
+GlobalData.cache_lock = self.cache_lock
 CommandTarget = self.data_pipe.Get("CommandTarget")
 pcd_from_build_option = []
 for pcd_tuple in self.data_pipe.Get("BuildOptPcd"):
diff --git a/BaseTools/Source/Python/AutoGen/GenC.py 
b/BaseTools/Source/Python/AutoGen/GenC.py
old mode 100644
new mode 100755
diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index c489c3b9c4..0f319e5b26 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -1806,7 +1806,7 @@ class ModuleAutoGen(AutoGen):
 MewIR.MakefilePath = MakefilePath
 MewIR.DependencyHeaderFileSet = Makefile.DependencyHeaderFileSet
 MewIR.CreateMakeFileDone = True
-with GlobalData.file_lock:
+with GlobalData.cache_lock:
 try:
 IR = gDict[(self.MetaFile.Path, self.Arch)]
 IR.MakefilePath = MakefilePath
@@ -1891,7 +1891,7 @@ class ModuleAutoGen(AutoGen):
 self.IsCodeFileCreated = True
 MewIR = ModuleBuildCacheIR(self.MetaFile.Path, self.Arch)
 MewIR.CreateCodeFileDone = True
-with GlobalData.file_lock:
+with GlobalData.cache_lock:
 try:
 IR = gDict[(self.MetaFile.Path, self.Arch)]
 IR.CreateCodeFileDone = True
@@ -2032,7 +2032,7 @@ class ModuleAutoGen(AutoGen):
 MewIR.ModuleFilesHashDigest = m.digest()
 MewIR.ModuleFilesHashHexDigest = m.hexdigest()
 MewIR.ModuleFilesChain = FileList
-with GlobalData.file_lock:
+with GlobalData.cache_lock:
 try:
 IR = gDict[(self.MetaFile.Path, self.Arch)]
 IR.ModuleFilesHashDigest = m.digest()
@@ -2091,7 +2091,7 @@ class ModuleAutoGen(AutoGen):
 # Add Module self
 m.update(gDict[(self.MetaFile.Path, self.Arch)].ModuleFilesHashDigest)
 
-with GlobalData.file_lock:
+with GlobalData.cache_lock:
 IR = gDict[(self.MetaFile.Path, self.Arch)]
 IR.PreMakefileHashHexDigest = m.hexdigest()
 gDict[(self.MetaFile.Path, self.Arch)] = IR
@@ -2159,7 +2159,7 @@ class ModuleAutoGen(AutoGen):
 m.update(Content)
 FileList.append((str(File), hashlib.md5(Content).hexdigest()))
 
-with GlobalData.file_lock:
+with GlobalData.cache_lock:
 IR = gDict[(self.MetaFile.Path, self.Arch)]
 IR.AutoGenFileList = self.AutoGenFileList.keys()
 IR.MakeHeaderFilesHashChain = FileList
@@ -,7 +,7 @@

[edk2-devel] [PATCH v4 4/5] BaseTools: Add GenFds multi-thread support in build cache

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

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

Fix the issue that the GenFds multi-thread will build fail
if enable the build cache together.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index 6db3b47a91..c489c3b9c4 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -1262,11 +1262,13 @@ class ModuleAutoGen(AutoGen):
 fStringIO.close ()
 fInputfile.close ()
 return OutputName
+
 @cached_property
 def OutputFile(self):
 retVal = set()
 OutputDir = self.OutputDir.replace('\\', '/').strip('/')
 DebugDir = self.DebugDir.replace('\\', '/').strip('/')
+FfsOutputDir = self.FfsOutputDir.replace('\\', '/').rstrip('/')
 for Item in self.CodaTargetList:
 File = Item.Target.Path.replace('\\', 
'/').strip('/').replace(DebugDir, '').replace(OutputDir, '').strip('/')
 retVal.add(File)
@@ -1282,6 +1284,12 @@ class ModuleAutoGen(AutoGen):
 if File.lower().endswith('.pdb'):
 retVal.add(File)
 
+for Root, Dirs, Files in os.walk(FfsOutputDir):
+for File in Files:
+if File.lower().endswith('.ffs') or 
File.lower().endswith('.offset') or File.lower().endswith('.raw') \
+or File.lower().endswith('.raw.txt'):
+retVal.add(File)
+
 return retVal
 
 ## Create AsBuilt INF file the module
@@ -1652,13 +1660,16 @@ class ModuleAutoGen(AutoGen):
 for File in self.OutputFile:
 File = str(File)
 if not os.path.isabs(File):
-File = os.path.join(self.OutputDir, File)
+NewFile = os.path.join(self.OutputDir, File)
+if not os.path.exists(NewFile):
+NewFile = os.path.join(self.FfsOutputDir, File)
+File = NewFile
 if os.path.exists(File):
-sub_dir = os.path.relpath(File, self.OutputDir)
-destination_file = os.path.join(FileDir, sub_dir)
-destination_dir = os.path.dirname(destination_file)
-CreateDirectory(destination_dir)
-CopyFileOnChange(File, destination_dir)
+if File.lower().endswith('.ffs') or 
File.lower().endswith('.offset') or File.lower().endswith('.raw') \
+or File.lower().endswith('.raw.txt'):
+self.CacheCopyFile(FfsDir, self.FfsOutputDir, File)
+else:
+self.CacheCopyFile(FileDir, self.OutputDir, File)
 
 def SaveHashChainFileToCache(self, gDict):
 if not GlobalData.gBinCacheDest:
-- 
2.17.1


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

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

[edk2-devel] [PATCH v4 2/5] BaseTools: Print first cache missing file for build cachle

2019-08-14 Thread Steven Shi

From: "Shi, Steven" 

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

When a module build cache miss, add support to print the first
cache missing file path and name.

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Steven Shi 
---
 BaseTools/Source/Python/AutoGen/AutoGenWorker.py |  2 ++
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 76 

 2 files changed, 78 insertions(+)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
index a84ed46f2e..30d2f96fc7 100755
--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
@@ -246,6 +246,8 @@ class AutoGenWorkerInProcess(mp.Process):
 Ma.GenMakeHash(GlobalData.gCacheIR)
 if Ma.CanSkipbyMakeCache(GlobalData.gCacheIR):
 continue
+else:
+Ma.PrintFirstMakeCacheMissFile(GlobalData.gCacheIR)
 except Empty:
 pass
 except:
diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index 613b0d2fb8..6db3b47a91 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -2379,6 +2379,82 @@ class ModuleAutoGen(AutoGen):
 print("[cache hit]: checkpoint_Makefile:", self.MetaFile.Path, 
self.Arch)
 return True
 
+## Show the first file name which causes cache miss
+def PrintFirstMakeCacheMissFile(self, gDict):
+if not GlobalData.gBinCacheSource:
+return
+
+# skip binary module
+if self.IsBinaryModule:
+return
+
+if not (self.MetaFile.Path, self.Arch) in gDict:
+return
+
+# Only print cache miss file for the MakeCache not hit module
+if gDict[(self.MetaFile.Path, self.Arch)].MakeCacheHit:
+return
+
+if not gDict[(self.MetaFile.Path, self.Arch)].MakeHashChain:
+EdkLogger.quiet("[cache insight]: MakeHashChain is missing for: 
%s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+# Find the cache dir name through the .ModuleHashPair file info
+FileDir = path.join(GlobalData.gBinCacheSource, 
self.PlatformInfo.OutputDir, self.BuildTarget + "_" + self.ToolChain, 
self.Arch, self.SourceDir, self.MetaFile.BaseName)
+
+ModuleHashPairList = [] # tuple list: [tuple(PreMakefileHash, 
MakeHash)]
+ModuleHashPair = path.join(FileDir, self.Name + ".ModuleHashPair")
+if not os.path.exists(ModuleHashPair):
+EdkLogger.quiet("[cache insight]: Cannot find ModuleHashPair file 
for module: %s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+try:
+f = open(ModuleHashPair, 'r')
+ModuleHashPairList = json.load(f)
+f.close()
+except:
+EdkLogger.quiet("[cache insight]: Cannot load ModuleHashPair file 
for module: %s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+MakeHashSet = set()
+for idx, (PreMakefileHash, MakeHash) in enumerate (ModuleHashPairList):
+TargetHashDir = path.join(FileDir, str(MakeHash))
+if os.path.exists(TargetHashDir):
+MakeHashSet.add(MakeHash)
+if not MakeHashSet:
+EdkLogger.quiet("[cache insight]: Cannot find valid cache dir for 
module: %s[%s]" % (self.MetaFile.Path, self.Arch))
+return
+
+TargetHash = list(MakeHashSet)[0]
+TargetHashDir = path.join(FileDir, str(TargetHash))
+if len(MakeHashSet) > 1 :
+EdkLogger.quiet("[cache insight]: found multiple cache dirs for 
this module, random select dir '%s' to search the first cache miss file: 
%s[%s]" % (TargetHash, self.MetaFile.Path, self.Arch))
+
+ListFile = path.join(TargetHashDir, self.Name + '.MakeHashChain')
+if os.path.exists(ListFile):
+try:
+f = open(ListFile, 'r')
+CachedList = json.load(f)
+f.close()
+except:
+EdkLogger.quiet("[cache insight]: Cannot load MakeHashChain 
file: %s" % ListFile)
+return
+else:
+EdkLogger.quiet("[cache insight]: Cannot find MakeHashChain file: 
%s" % ListFile)
+return
+
+CurrentList = gDict[(self.MetaFile.Path, self.Arch)].MakeHashChain
+for idx, (file, hash) in enumerate (CurrentList):
+(filecached, hashcached) = CachedList[idx]
+if file != filecached:
+EdkLogger.quiet("[cache insight]: first different file in 
%s[%s] is %s, the cached one is %s" % (self.MetaFile.Path, self.Arch, file, 
filecached))
+break
+if hash != hashcached:
+EdkLogger.quiet("[cache insight]: first cache miss file in

Re: [edk2-devel] [PATCH v4 1/5] BaseTools: Improve the cache hit in the edk2 build cache

2019-08-14 Thread Christian Rodriguez

For all 5 patches in patch set: Acked-by: Christian Rodriguez 


>-Original Message-
>From: Shi, Steven
>Sent: Wednesday, August 14, 2019 11:11 AM
>To: devel@edk2.groups.io
>Cc: Gao, Liming ; Feng, Bob C
>; Rodriguez, Christian
>; Johnson, Michael
>; Shi, Steven 
>Subject: [PATCH v4 1/5] BaseTools: Improve the cache hit in the edk2 build
>cache
>
>From: "Shi, Steven" 
>
>BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1927
>
>Current cache hash algorithm does not parse and generate
>the makefile to get the accurate dependency files for a
>module. It instead use the platform and package meta files
>to get the module depenedency in a quick but over approximate
>way. These meta files are monolithic and involve many redundant
>dependency for the module, which cause the module build
>cache miss easily.
>This patch introduces one more cache checkpoint and a new
>hash algorithm besides the current quick one. The new hash
>algorithm leverages the module makefile to achieve more
>accurate and precise dependency info for a module. When
>the build cache miss with the first quick hash, the
>Basetool will caculate new one after makefile is generated
>and then check again.
>
>Cc: Liming Gao 
>Cc: Bob Feng 
>Signed-off-by: Steven Shi 
>---
> BaseTools/Source/Python/AutoGen/AutoGenWorker.py |  21
>+
> BaseTools/Source/Python/AutoGen/CacheIR.py   |  28
>
> BaseTools/Source/Python/AutoGen/DataPipe.py  |   8 
> BaseTools/Source/Python/AutoGen/GenMake.py   | 223
>+++
>+++---
>---
>---
> BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 639
>+++
>+++
>+++
>+++
>+++
>+++
>+++
>+++
>+++
>+++-
>
> BaseTools/Source/Python/Common/GlobalData.py |   9 +
> BaseTools/Source/Python/build/build.py   | 129
>+++
>++
> 7 files changed, 863 insertions(+), 194 deletions(-)
>
>diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
>b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
>old mode 100644
>new mode 100755
>index e583828741..a84ed46f2e
>--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
>+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
>@@ -182,6 +182,12 @@ class AutoGenWorkerInProcess(mp.Process):
> GlobalData.gDisableIncludePathCheck = False
> GlobalData.gFdfParser = self.data_pipe.Get("FdfParser")
> GlobalData.gDatabasePath = self.data_pipe.Get("DatabasePath")
>+GlobalData.gBinCacheSource = self.data_pipe.Get("BinCacheSource")
>+GlobalData.gBinCacheDest = self.data_pipe.Get("BinCacheDest")
>+GlobalData.gCacheIR = self.data_pipe.Get("CacheIR")
>+GlobalData.gEnableGenfdsMultiThread =
>self.data_pipe.Get("EnableGenfdsMultiThread")
>+GlobalData.file_lock = self.file_lock
>+CommandTarget = self.data_pipe.Get("CommandTarget")
> pcd_from_build_option = []
> for pcd_tuple in self.data_pipe.Get("BuildOptPcd"):
> pcd_id = ".".join((pcd_tuple[0],pcd_tuple[1]))
>@@ -193,10 +199,13 @@ class AutoGenWorkerInProcess(mp.Process):
> FfsCmd = self.data_pipe.Get("FfsCommand")
> if FfsCmd is None:
> FfsCmd = {}
>+GlobalData.FfsCmd = FfsCmd
> PlatformMetaFile =
>self.GetPlatformMetaFile(self.data_pipe.Get("P_Info").get("ActivePlatform")
>,
>  
> self.data_pipe.Get("P_Info").get("WorkspaceDir"))
> libConstPcd = self.data_pipe.Get("LibConstPcd")
> Refes = self.data_pipe.Get("REFS")
>+GlobalData.libConstPcd = libConstPcd
>+GlobalData.Refes = Refes
> while True:
> if self.module_queue.empty():
> break
>@@ -223,8 +232,20 @@ class AutoGenWorkerInProcess(mp.Process):
> Ma.ConstPcd =
>libConstPcd[(Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path)
>]
> if 
> (Ma.MetaFile.File,Ma.MetaFile.Root,Ma.Arch,Ma.MetaFile.Path)
>in

Re: [edk2-devel] static data in dxe_runtime modules

2019-08-14 Thread Andrew Fish via Groups.Io

> On Aug 14, 2019, at 8:16 AM, Laszlo Ersek  wrote:
> 
> On 08/13/19 13:23, Roman Kagan wrote:
>> On Tue, Aug 13, 2019 at 11:10:27AM +0200, Laszlo Ersek wrote:
>>> On 08/12/19 20:43, Roman Kagan wrote:
 On Fri, Aug 09, 2019 at 04:07:00PM +, Roman Kagan via Groups.Io wrote:
> On Thu, Aug 08, 2019 at 07:39:14PM +0200, Laszlo Ersek wrote:
>> On 08/07/19 19:41, Andrew Fish wrote:
 On Aug 7, 2019, at 10:29 AM, Laszlo Ersek  wrote:
 On 08/05/19 12:18, Roman Kagan wrote:
> On Sat, Aug 03, 2019 at 04:03:04AM +0200, Laszlo Ersek via Groups.Io 
> wrote:
>> On 08/01/19 21:16, Roman Kagan wrote:
 I'm convinced that OpenSSL needs to expose a new API for this 
 particular
 problem.
> 
> Since, as you point out below, the problem only affects the essentially
> broken configuration (SECURE_BOOT_ENABLE && !SMM_REQUIRE), I'm fine with
> saving time and effort and sticking to the hack-ish approach proposed in
> the bugzilla issue, which is to iterate over "thread-local" pointers and
> EfiConvertPointer() on each.  (As long as it fixes the problem of
> course; I'll test and report back.)

 It doesn't :(  It just gets slightly further and hits another static
 pointer variable which is not part of the thread-local array:

 ...
  Pkcs7Verify
EVP_add_digest
  OBJ_NAME_add

 this one uses a few static pointer variables that are also initialized
 on demand and become stale upon SetVirtualAddressMap().
>>> 
>>> So it looks like the issue can't be solved without making OpenSSL aware
>>> of this use case.
>> 
>> Is reloading the module from scratch ruled out completely?
> 
> Not my place to say authoritatively, but:
> - it would be a first, as much as I can say,
> - it would duplicate (in purpose) an existing facility.
> 
> Personally I'd expect it to be rejected, but it's not up to me. If
> you're willing to "build one to (possibly) throw away", that could be
> the most direct way to get authoritative (= maintainer) feedback.
> 

Laszlo,

I thunk it is more likely to get rejected as it would not work. 

Every runtime driver I've every seen usually works like this:
1) Loads as an EFI driver and uses EFI Boot Services in its constructor (gBS, 
gDS, AllocatePool(), etc.)
2) You use the EFI Boot Service to register the ExitBootServices Event. 
3) SetVirtualAddressMap event fires and converts all the pointers 
4) After all the ExitBootServices events have been processed the DXE Runtime 
driver re-relocates the Runtime Driver
5) The next code that runs is a call from the kernel virtual mapping, and the 
system is at runtime 

It is important to remember that when gRT->SetVirtualAddressMap() is called by 
the OS Loader (or early kernel) that gBS->ExitBootServices() has already been 
called. So by the time you get 3) almost all of EFI is gone. The only services 
that remain are gRT. Note you find the location of gRT by using the gST passed 
into the entry point of the driver. So here is lies the problem the entry point 
is passed a Handle (EFI Boot Services concept) and a pointer to gST (another 
boot services table). So you can't really reload a module and expect it to 
work. 

In EFI the transition from Boot Service time to Runtime already requires a lot 
of coding discipline to not call services at runtime that will go away after 
ExitBootServices. Having C code that can be called in Physical mode, and then 
with a virtual mapping is a very unnatural and what EFI does today is the 
minimum required to make things work. 

Also remember dumping more into EFI runtime is stealing memory and usually 
kernel virtual address space from the OS. 

Thanks,

Andrew Fish

> Thanks
> Laszlo
> 
>> I'd try to cook up a patch for that unless there's a strong no-go.
>> 
>> Thanks,
>> Roman.

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

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

95 matches

Mail list logo