Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 08/22]: MdePkg/BasePeCoff: Add RISC-V PE/Coff related code.

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:03PM +0800, Abner Chang wrote:
> Support RISC-V image relocation.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 
> ---
>  MdePkg/Library/BasePeCoffLib/BasePeCoff.c  |   3 +-
>  MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf |   5 +
>  MdePkg/Library/BasePeCoffLib/BasePeCoffLib.uni |   4 +-
>  .../Library/BasePeCoffLib/BasePeCoffLibInternals.h |   1 +
>  .../Library/BasePeCoffLib/RiscV/PeCoffLoaderEx.c   | 149 
> +
>  5 files changed, 160 insertions(+), 2 deletions(-)
>  create mode 100644 MdePkg/Library/BasePeCoffLib/RiscV/PeCoffLoaderEx.c
> 
> diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c 
> b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> index 07bb62f..97e0ff4 100644
> --- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> @@ -1,6 +1,6 @@
>  /** @file
>Base PE/COFF loader supports loading any PE32/PE32+ or TE image, but
> -  only supports relocating IA32, x64, IPF, and EBC images.
> +  only supports relocating IA32, x64, IPF, ARM, RISC-V and EBC images.
>  
>Caution: This file requires additional review when modified.
>This library will have external input - PE/COFF image.
> @@ -17,6 +17,7 @@
>  
>Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> +  Portions Copyright (c) 2016, Hewlett Packard Enterprise Development LP. 
> All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
> diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf 
> b/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
> index 395c140..e5c8e66 100644
> --- a/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
> +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
> @@ -3,6 +3,7 @@
>  #  The IPF version library supports loading IPF and EBC PE/COFF image.
>  #  The IA32 version library support loading IA32, X64 and EBC PE/COFF images.
>  #  The X64 version library support loading IA32, X64 and EBC PE/COFF images.
> +#  The RISC-V version library support loading RISC-V images.
>  #
>  #  Caution: This module requires additional review when modified.
>  #  This library will have external input - PE/COFF image.
> @@ -11,6 +12,7 @@
>  #
>  #  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>  #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> +#  Copyright (c) 2016, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -41,6 +43,9 @@
>  [Sources.ARM]
>Arm/PeCoffLoaderEx.c
>  
> +[Sources.RISCV64]
> +  RiscV/PeCoffLoaderEx.c
> +  
>  [Packages]
>MdePkg/MdePkg.dec
>  
> diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.uni 
> b/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.uni
> index b0ea702..edc48cd 100644
> --- a/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.uni
> +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.uni
> @@ -4,7 +4,8 @@
>  // The IPF version library supports loading IPF and EBC PE/COFF image.
>  // The IA32 version library support loading IA32, X64 and EBC PE/COFF images.
>  // The X64 version library support loading IA32, X64 and EBC PE/COFF images.
> -//
> +// The RISC-V version library support loading RISC-V32 and RISC-V64 PE/COFF 
> images.
> +// 

The above diff looks like you're adding a blank line and deleting
another one. This happens because you have added a trailing space on
the gap line. PatchCheck.py finds these.

/
Leif

>  // Caution: This module requires additional review when modified.
>  // This library will have external input - PE/COFF image.
>  // This external input must be validated carefully to avoid security issue 
> like
> @@ -12,6 +13,7 @@
>  //
>  // Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>  // Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> +// Copyright (c) 2016, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
>  //
>  // SPDX-License-Identifier: BSD-2-Clause-Patent
>  //
> diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoffLibInternals.h 
> b/MdePkg/Library/BasePeCoffLib/BasePeCoffLibInternals.h
> index b74277f..9c33703 100644
> --- a/MdePkg/Library/BasePeCoffLib/BasePeCoffLibInternals.h
> +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoffLibInternals.h
> @@ -2,6 +2,7 @@
>Declaration of internal functions in PE/COFF Lib.
>  
>Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
> +  Copyright (c) 2016, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
> diff --git a/MdePkg/Library/BasePeCoffLib/RiscV/PeCoffLoaderEx.c 
> b/MdePkg/Library/BasePeCoffLib/RiscV/PeCoffLoaderEx.c
> new file mode 100644
> index 000..a99550f
> --- /dev/null
> +++ b/MdePkg/Library/BasePeCoffLib/RiscV/PeCoffLoaderEx.c
> @@ -0,0 +1,149 @@
> 

Re: [edk2-devel] [Patch 0/2] Enable --genfds-multi-thread to default build

[Bob Feng]

Emulator
Ovmf
MinPlatforms
And Intel Server Platform.

-Bob

-Original Message-
From: Gao, Liming 
Sent: Thursday, September 5, 2019 9:09 PM
To: devel@edk2.groups.io; Feng, Bob C 
Subject: RE: [edk2-devel] [Patch 0/2] Enable --genfds-multi-thread to default 
build

Bob:
  Can you list the platform list have been verified with this change?

Thanks
Liming> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Bob Feng
> Sent: Thursday, September 5, 2019 11:11 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [Patch 0/2] Enable --genfds-multi-thread to 
> default build
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1302
> 
> Enable --genfds-multi-thread as default build behavior can improve 
> build performance but will not bring nagtive impact.
> 
> Feng, Bob C (2):
>   BaseTools: Fixed the build fail on Linux with --genfds-multi-thread
>   BaseTools: Enable --genfds-multi-thread to default build
> 
>  BaseTools/Source/Python/AutoGen/GenMake.py | 4 ++--
>  BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py| 3 +--
>  BaseTools/Source/Python/Common/GlobalData.py   | 2 +-
>  BaseTools/Source/Python/Common/buildoptions.py | 3 ++-
>  BaseTools/Source/Python/GenFds/GenFds.py   | 9 ++---
>  BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py | 4 ++--
>  BaseTools/Source/Python/build/build.py | 2 +-
>  7 files changed, 15 insertions(+), 12 deletions(-)
> 
> --
> 2.20.1.windows.1
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linking

[Leif Lindholm]

On Wed, Sep 04, 2019 at 04:04:23PM -0700, Ard Biesheuvel wrote:
> In some cases, the CLANG38 toolchain profile in LTO mode emits GOT
> based relocations in spite of our attempts to avoid this, by using
> hidden visibility, -Bsymbolic etc.
> 
> On AARCH64, we managed to work around this by processing the GOT
> based relocations in GenFw. As it turns out, the same issue exists
> on 32-bit ARM, but unfortunately, we cannot use a similar trick to
> get rid of the GOT entry, and the relocation metadata is insufficient
> to locate the GOT entry in the binary.
> 
> A bit of trial and error reveals that switching the linker options from
> -pie to -shared in commit e07092edca8442db4a941dbeea0cd196c7bf8ec9 was
> not the best approach, and instead, we can pass -pie to the linker
> directly (using -Wl,xxx) rather than to the compiler directly, which
> turns out to massage the linker in the right way, and prevents if from
> emitting GOT based relocations. Your mileage may vary ...
> 
> Signed-off-by: Ard Biesheuvel 
> ---
> Let's test this on a couple of different Clang versions. If it still
> produces problems, the only other way I see is to disable the builds
> of platforms that incorporate this module for ARM/CLANG38 [which is
> not the end of the world]
> 
>  ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf 
> b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.in
> index 683397b7afd1..9e58e56fce09 100755
> --- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> +++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> @@ -97,4 +97,4 @@
>gArmTokenSpaceGuid.PcdFvBaseAddress
>  
>  [BuildOptions]
> -  GCC:*_*_*_DLINK_FLAGS = -shared -Wl,-Bsymbolic 
> -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> +  GCC:*_*_*_DLINK_FLAGS = 
> -Wl,-Bsymbolic,-pie,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds

We already merged a fix for AARCH64 though - could/should this be
active on ARM only?

A problem I have with this patch is that ArmVirtQemuKernel curently
doesn't boot on my qemu (with/without kvm, built with GCC5 or CLANG38,
with or without this patch):
ProcessPciHost: Config[0x401000+0x1000) Bus[0x0..0xFF]
Io[0x0+0x1)@0x3EFF Mem32[0x1000+0x2EFF)@0x0
Mem64[0x80+0x80)@0x0
MapGcdMmioSpace: failed to set memory space attributes for region
[0x401000+0x1000)

ASSERT_EFI_ERROR (Status = Unsupported)
ASSERT [PciHostBridgeDxe]
/work/git/edk2/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(293):
!EFI_ERROR (Status)
qemu-system-arm: terminating on signal 15 from pid 4680 (killall)

/
Leif

> -- 
> 2.17.1
> 

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

View/Reply Online (#46902): https://edk2.groups.io/g/devel/message/46902
Mute This Topic: https://groups.io/mt/33144570/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] BaseTools: Fixed issue for IgnoreAutoGen

[Bob Feng]

Sorry for the incomplete mail.

I verified this patch on Ovmf, Emulator, MinPlatforms and Intel Server Platform.

Thanks,
Bob

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Bob Feng
Sent: Thursday, September 5, 2019 10:04 PM
To: Gao, Liming ; devel@edk2.groups.io
Cc: Shi, Steven 
Subject: Re: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue for IgnoreAutoGen

Liming,

Yes, this change only impact -u option. 

I separate _MultiThreadBuildPlatform function into two functions and create 2 
new functions specially for IgnoreAutoGen, so the there looks  big change for 
build.py in this patch. I verified this patch on Ovmf, E

-Bob

-Original Message-
From: Gao, Liming
Sent: Thursday, September 5, 2019 9:12 PM
To: devel@edk2.groups.io; Feng, Bob C 
Cc: Shi, Steven 
Subject: RE: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue for IgnoreAutoGen

Bob: 
 Does this change only impact -u option behavior? 

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Bob Feng
> Sent: Thursday, September 5, 2019 5:05 PM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Shi, Steven 
> ; Feng, Bob C 
> Subject: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue for 
> IgnoreAutoGen
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2080
> 
> This patch is to improve build -u option to re-use 
> GlobalVar__.bin file which is introduced by 
> multiple-process-autogen feature.
> 
> Cc: Liming Gao 
> Cc: Steven Shi 
> Signed-off-by: Bob Feng 
> ---
>  .../Source/Python/AutoGen/AutoGenWorker.py|   2 +-
>  .../Source/Python/AutoGen/ModuleAutoGen.py|   4 +-
>  .../Python/AutoGen/ModuleAutoGenHelper.py |  29 ++
>  .../Source/Python/AutoGen/PlatformAutoGen.py  |   2 +
>  .../Source/Python/AutoGen/WorkspaceAutoGen.py |   1 -
>  BaseTools/Source/Python/build/build.py| 355 +++---
>  6 files changed, 255 insertions(+), 138 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
> b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
> index 2e68538b1cb4..f488ae9d5f80 100755
> --- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
> @@ -236,11 +236,11 @@ class AutoGenWorkerInProcess(mp.Process):
>  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
> +continue
> 
>  Ma.CreateCodeFile(False)
>
> Ma.CreateMakeFile(False,GenFfsList=FfsCmd.get((Ma.MetaFile.File,
> Ma.Arch),[]))
> 
>  if GlobalData.gBinCacheSource and CommandTarget in [None, 
> "", "all"]:
> diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> index 3bb7e91154ac..5f28681e3146 100755
> --- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> @@ -2058,12 +2058,12 @@ class ModuleAutoGen(AutoGen):
> not gDict[(self.MetaFile.Path, self.Arch)].ModuleFilesHashDigest:
>  self.GenModuleFilesHash(gDict)
> 
>  if not (self.MetaFile.Path, self.Arch) in gDict or \
> not gDict[(self.MetaFile.Path, self.Arch)].ModuleFilesHashDigest:
> -   EdkLogger.quiet("[cache warning]: Cannot generate 
> ModuleFilesHashDigest for module %s[%s]" %(self.MetaFile.Path,
> self.Arch))
> -   return
> +EdkLogger.quiet("[cache warning]: Cannot generate 
> + ModuleFilesHashDigest for module %s[%s]" %(self.MetaFile.Path,
> self.Arch))
> +return
> 
>  # Initialze hash object
>  m = hashlib.md5()
> 
>  # Add Platform level hash
> diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
> b/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
> index c7591253debd..9dd93b9beb12 100644
> --- a/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
> +++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
> @@ -234,22 +234,51 @@ class AutoGenInfo(object):
>  #
>  #This class is the pruned WorkSpaceAutoGen for ModuleAutoGen in 
> multiple thread  #  class WorkSpaceInfo(AutoGenInfo):
>  def __init__(self,Workspace, MetaFile, Target, ToolChain, Arch):
> +if not hasattr(self, "_Init"):
> +self.do_init(Workspace, MetaFile, Target, ToolChain, Arch)
> +self._Init = True
> +def do_init(self,Workspace, MetaFile, Target, ToolChain, Arch):
>  self._SrcTimeStamp = 0
>  self.Db = BuildDB
>  self.BuildDatabase = self.Db.BuildObject
>  self.Target = Target
>  self.ToolChain 

Re: [edk2-devel] [edk2] [Patch 32/33] BaseTools: ECC tool Python3 adaption

[Laszlo Ersek]

On 09/05/19 12:37, Leif Lindholm wrote:
> Hi Bob, (+Laszlo, due to a question at the end)
>
> On Thu, Sep 05, 2019 at 05:39:05AM +, Feng, Bob C wrote:
>> Would you try to install antlr4-python3-runtime on debian.
>> pip install antlr4-python3-runtime
>
> I'd rather not. For the reasons described by Laszlo in the
> discussion leading to the creation of edk2-tools:
> https://edk2.groups.io/g/devel/message/40380
>
> Now, if Ecc was moved to edk2-tools, I guess that would be fine. It
> also means we increase the hurdle for running Ecc.
>
>> I think python3 + antlr3 would not be a good combination, since the
>> antlr3 for python3 is still in beta and has not been update for 7
>> years. And I think there is no ECC test for such combination.
>
> Nevertheless python3-antlr3 was packaged by debian/ubuntu as late as
> last year, as part of their OpenStack work. And is now part of both
> distributions.
>
> Laszlo - which python-antlr versions are packaged in
> centos/fedora/redhat?

None.

* antlr4:

The following Fedora feature requests have been dormant for quite some
time:

- antlr4-4.7.1 is available
  https://bugzilla.redhat.com/show_bug.cgi?id=1596974

- antlr4: python 3 runtime support
  https://bugzilla.redhat.com/show_bug.cgi?id=1599015

This proved so much of a problem for the maintainers of the "coq"
package that they went ahead and bundled the python 3 runtime with the
"coq" package, for their own internal use only:

  https://koji.fedoraproject.org/koji/buildinfo?buildID=1370928

The SPEC file in the "coq-8.9.1-6.fc32.src.rpm" file, downloaded from
that link, says:

> # NOTE: Due to no action on bz 1596974 and bz 1599015 for months, we now 
> bundle
> # the necessary python3 runtime for antlr4.  Once those bugs are addressed, we
> # can unbundle and use the system antlr4 python3 runtime.

So now you can install "antlr4-python3-runtime", but it's not built from
the "antlr4" source package, it's built from the "coq" one. I don't
think anyone would want to rely on that, for use cases not related to
"coq".

Regarding Python 2 support -- no need to look.

  https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal

For example, the changelog of even the antlr-2 package says,

  https://koji.fedoraproject.org/koji/buildinfo?buildID=1321182

> * Wed Mar 27 2019 Miro Hron
ok  - 0:2.7.7-58
> - Subpackage python2-antlr was removed
>   https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal

In Debian too, "python3-antlr4" is a wish-list / prospective package:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897129


* Regarding antlr3, I couldn't find a standalone python support package
in Fedora.

And, the antlr3 source package itself:

  https://koji.fedoraproject.org/koji/buildinfo?buildID=1345133

doesn't seem to produce python bindings (see under "noarch").


* Given the Fedora situation, it's virtually impossible that CentOS or
RHEL ship the package (I haven't even checked).


* However; since the discussion that you link near the top, I've come
across the following blog post:

  https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/

and virtual environments were also mentioned by Mike and Sean, in the
same thread that you link:

- 
http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F5B9CA5998@ORSMSX113.amr.corp.intel.com
  https://edk2.groups.io/g/devel/message/40389

- http://mid.mail-archive.com/19931.1557456493073446522@groups.io
  https://edk2.groups.io/g/devel/message/40393

So I guess there should be a way to make "pip install" work, without
messing up the system. I've never tried.

Thanks
Laszlo

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

View/Reply Online (#46899): https://edk2.groups.io/g/devel/message/46899
Mute This Topic: https://groups.io/mt/33115040/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] UefiCpuPkg: support single EFI_PEI_CORE_FV_LOCATION_PPI in PpiList

[Chiu, Chasel]

Thanks Laszlo!
Pushed: 8a1305a11f3bda2d6c1ab758e4aea79ee021dd1c

> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, September 5, 2019 9:16 PM
> To: Ni, Ray ; Dong, Eric ; Chiu,
> Chasel ; devel@edk2.groups.io
> Subject: Re: [PATCH v2] UefiCpuPkg: support single
> EFI_PEI_CORE_FV_LOCATION_PPI in PpiList
> 
> Hi All,
> 
> On 09/05/19 08:46, Ni, Ray wrote:
> > Reviewed-by: Ray Ni 
> 
> Please go ahead with the push, I'll skip this.
> 
> Thanks
> Laszlo
> 
> >> -Original Message-
> >> From: Dong, Eric
> >> Sent: Wednesday, September 4, 2019 11:15 PM
> >> To: Chiu, Chasel ; devel@edk2.groups.io
> >> Cc: Ni, Ray ; Laszlo Ersek 
> >> Subject: RE: [PATCH v2] UefiCpuPkg: support single
> >> EFI_PEI_CORE_FV_LOCATION_PPI in PpiList
> >>
> >> Reviewed-by: Eric Dong 
> >>
> >>> -Original Message-
> >>> From: Chiu, Chasel
> >>> Sent: Thursday, September 5, 2019 12:27 PM
> >>> To: devel@edk2.groups.io
> >>> Cc: Dong, Eric ; Ni, Ray ;
> >>> Laszlo Ersek 
> >>> Subject: [PATCH v2] UefiCpuPkg: support single
> >>> EFI_PEI_CORE_FV_LOCATION_PPI in PpiList
> >>>
> >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2153
> >>>
> >>> Current logic will skip searching EFI_PEI_CORE_FV_LOCATION_PPI when
> >>> the PPI in PpiList having EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST
> >>> flag, but platform may pass single PPI in PpiList that should be
> supported.
> >>>
> >>> Changed the logic to verify PpiList first before checking
> >>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag.
> >>>
> >>> Test: Verified both single EFI_PEI_CORE_FV_LOCATION_PPI and multiple
> >>>   PPIs in PpiList cases and both can boot with the PeiCore
> >>>   specified by EFI_PEI_CORE_FV_LOCATION_PPI.
> >>>
> >>> Cc: Eric Dong 
> >>> Cc: Ray Ni 
> >>> Cc: Laszlo Ersek 
> >>> Signed-off-by: Chasel Chiu 
> >>> ---
> >>>  UefiCpuPkg/SecCore/SecMain.c | 9 -
> >>>  1 file changed, 4 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/UefiCpuPkg/SecCore/SecMain.c
> >>> b/UefiCpuPkg/SecCore/SecMain.c index 66c952b897..5d5e7f17dc 100644
> >>> --- a/UefiCpuPkg/SecCore/SecMain.c
> >>> +++ b/UefiCpuPkg/SecCore/SecMain.c
> >>> @@ -238,9 +238,8 @@ SecStartupPhase2(
> >>>// is enabled.
> >>>//
> >>>if (PpiList != NULL) {
> >>> -for (Index = 0;
> >>> -  (PpiList[Index].Flags &
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) !=
> >>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST;
> >>> -  Index++) {
> >>> +Index = 0;
> >>> +do {
> >>>if (CompareGuid (PpiList[Index].Guid,
> ) &&
> >>>(((EFI_PEI_CORE_FV_LOCATION_PPI *) PpiList[Index].Ppi)-
>  PeiCoreFvLocation != 0)
> >>>   ) {
> >>> @@ -256,12 +255,12 @@ SecStartupPhase2(
> >>>break;
> >>>  } else {
> >>>//
> >>> -  // PeiCore not found
> >>> +  // Invalid PeiCore FV provided by platform
> >>>//
> >>>CpuDeadLoop ();
> >>>  }
> >>>}
> >>> -}
> >>> +} while ((PpiList[Index++].Flags &
> >>> + EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) !=
> >>> + EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST);
> >>>}
> >>>//
> >>>// If EFI_PEI_CORE_FV_LOCATION_PPI not found, try to locate
> >>> PeiCore from BFV.
> >>> --
> >>> 2.13.3.windows.1
> >


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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 07/22]: MdePkg/BaseIoLibIntrinsic: RISC-V I/O intrinsic functions.

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:02PM +0800, Abner Chang wrote:
> RISC-V MMIO library instance.  RISC-V only supports memory map I/O. However 
> the first implementation
> of RISC-V EDK2 port uses PC/AT as the RISC-V platform spec. We have
> to keep the I/O functions as the temporary solution.

Can you expand on the I/O port situation?
Since the architecture doesn't support it, what do these functions do?

For the pure MMIO ops using compliant C, we really don't need yet
another implementation pretending it's architecture specific. We
should just have a single IoLibMmio.c and an IoLibMmioNonCompliant.c
if the x86 folks want to keep their current one.

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 
> ---
>  .../BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf  |   8 +-
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibRiscV.c | 697 
> +
>  2 files changed, 703 insertions(+), 2 deletions(-)
>  create mode 100644 MdePkg/Library/BaseIoLibIntrinsic/IoLibRiscV.c
> 
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf 
> b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> index 457cce9..fbb568e 100644
> --- a/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> @@ -2,13 +2,14 @@
>  #  Instance of I/O Library using compiler intrinsics.
>  #
>  #  I/O Library that uses compiler intrinsics to perform IN and OUT 
> instructions
> -#  for IA-32 and x64.  On IPF, I/O port requests are translated into MMIO 
> requests.
> +#  for IA-32, x64 and RISC-V.  On IPF, I/O port requests are translated into 
> MMIO requests.
>  #  MMIO requests are forwarded directly to memory.  For EBC, I/O port 
> requests
>  #  ASSERT().
>  #
>  #  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
>  #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
>  #  Copyright (c) 2017, AMD Incorporated. All rights reserved.
> +#  Portinos Copyright (c) 2016, Hewlett Packard Enterprise Development LP. 
> All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -25,7 +26,7 @@
>  
>  
>  #
> -#  VALID_ARCHITECTURES   = IA32 X64 EBC ARM AARCH64
> +#  VALID_ARCHITECTURES   = IA32 X64 EBC ARM AARCH64 RISCV64
>  #
>  
>  [Sources]
> @@ -55,6 +56,9 @@
>  [Sources.AARCH64]
>IoLibArm.c
>  
> +[Sources.RISCV64]
> +  IoLibRiscV.c
> +
>  [Packages]
>MdePkg/MdePkg.dec
>  
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/IoLibRiscV.c 
> b/MdePkg/Library/BaseIoLibIntrinsic/IoLibRiscV.c
> new file mode 100644
> index 000..6173d25
> --- /dev/null
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/IoLibRiscV.c
> @@ -0,0 +1,697 @@
> +/** @file
> +  Common I/O Library routines for RISC-V
> +
> +  Copyright (c) 2016 - 2019, Hewlett Packard Enterprise Development LP. All 
> rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution. The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +**/
> +
> +#include "BaseIoLibIntrinsicInternal.h"
> +
> +/**
> +  Reads an 8-bit MMIO register.
> +
> +  Reads the 8-bit MMIO register specified by Address. The 8-bit read value is
> +  returned. This function must guarantee that all MMIO read and write
> +  operations are serialized.
> +
> +  If 8-bit MMIO register operations are not supported, then ASSERT().
> +
> +  @param  Address The MMIO register to read.
> +
> +  @return The value read.
> +
> +**/
> +UINT8
> +EFIAPI
> +MmioRead8 (
> +  IN  UINTN Address
> +  )
> +{
> +  return *(volatile UINT8*)Address;
> +}
> +
> +/**
> +  Writes an 8-bit MMIO register.
> +
> +  Writes the 8-bit MMIO register specified by Address with the value 
> specified
> +  by Value and returns Value. This function must guarantee that all MMIO read
> +  and write operations are serialized.
> +
> +  If 8-bit MMIO register operations are not supported, then ASSERT().
> +
> +  @param  Address The MMIO register to write.
> +  @param  Value   The value to write to the MMIO register.
> +
> +  @return Value.
> +
> +**/
> +UINT8
> +EFIAPI
> +MmioWrite8 (
> +  IN  UINTN Address,
> +  IN  UINT8 Value
> +  )
> +{
> +  *(volatile UINT8 *)Address = Value;
> +  return Value;
> +}
> +
> +/**
> +  Reads a 16-bit MMIO register.
> +
> +  Reads the 16-bit MMIO register specified by Address. The 16-bit read value 
> is
> +  returned. This function must guarantee that all MMIO read and write
> +  operations are serialized.
> +
> +  If 16-bit MMIO register operations are not supported, then ASSERT().
> +  If Address is 

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

[Laszlo Ersek]

On 09/04/19 11:52, Igor Mammedov wrote:

>  it could be stolen RAM + black hole like TSEG, assuming fw can live without 
> RAM(0x3+128K) range
>   (in this case fwcfg interface would only work for locking down the range)
> 
>  or
> 
>  we can actually have a dedicated SMRAM (like in my earlier RFC),
>  in this case FW can use RAM(0x3+128K) when SMRAM isn't mapped into RAM 
> address space
>  (in this case fwcfg would be used to temporarily map SMRAM into normal RAM 
> and unmap/lock
>   after SMI relocation handler was initialized).
> 
> If possible I'd prefer a simpler TSEG like variant.

I think TSEG-like behavior is between these two. That is, I believe we
should have explicit open/close/lock operations. And, when the range is
closed (meaning, closed+unlocked, or closed+locked), then the black hole
should take effect for code that's not running in SMM.

Put differently, its like the second choice, except the range never
appears as normal RAM. "When SMRAM isn't mapped into RAM address space",
then the address range shows "nothing" (black hole).


Regarding "fw can live without RAM(0x3+128K) range" -- do you mean
whether the firmware could use another RAM area for fw_cfg DMA?

If that's the question, then I wouldn't worry about it. I'd remove the
0x3+128K range from the memory map, so the fw_cfg stuff (or anything
else) would never allocate memory from the range. It's much more
concerning to me however how the SMM infrastructure would deal with a
hole in the memory map right there.

Thanks
Laszlo

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

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

Re: [edk2-devel] [edk2-platforms][PATCH] AdvancedFeaturePkg/S3Advanced Add S3 Advanced PEIM driver

[Liming Gao]

Marc:
  Please remove Change-Id: Ie5841047be350f411650ad30f16d210b98197dc4 in the 
commit message for the updated one. 

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Marc W 
> Chen
> Sent: Thursday, September 5, 2019 4:52 PM
> To: devel@edk2.groups.io
> Cc: Kubacki, Michael A ; Chaganty, Rangasai V 
> ; Gao, Liming
> ; Chen, Marc W 
> Subject: [edk2-devel] [edk2-platforms][PATCH] AdvancedFeaturePkg/S3Advanced 
> Add S3 Advanced PEIM driver
> 
> Implement a S3 Advanced PEIM driver for supporting S3 feature.
> So far this driver only install EFI_PEI_MM_ACCESS_PPI for S3 resume case.
> 
> Change-Id: Ie5841047be350f411650ad30f16d210b98197dc4
> Cc: Michael Kubacki 
> Cc: Sai Chaganty 
> Cc: Liming Gao 
> Signed-off-by: Marc Chen 
> ---
>  .../S3Advanced/S3AdvancedPei/S3AdvancedPei.c   | 36 
> ++
>  .../S3Advanced/S3AdvancedPei/S3AdvancedPei.inf | 31 +++
>  2 files changed, 67 insertions(+)
>  create mode 100644 
> Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
>  create mode 100644 
> Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf
> 
> diff --git 
> a/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
> b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
> new file mode 100644
> index ..9ce4cc6a
> --- /dev/null
> +++ 
> b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
> @@ -0,0 +1,36 @@
> +/** @file
> +  Source code file for S3 Advanced PEI module
> +
> +Copyright (c) 2019, Intel Corporation. All rights reserved.
> +SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +#include 
> +
> +/**
> +  S3 Advanced PEI module entry point
> +
> +  @param[in]  FileHandle   Not used.
> +  @param[in]  PeiServices  General purpose services available to 
> every PEIM.
> +
> +  @retval EFI_SUCCESS  The function completes successfully
> +  @retval EFI_OUT_OF_RESOURCES Insufficient resources to create database
> +**/
> +EFI_STATUS
> +EFIAPI
> +S3AdvancedEntryPoint (
> +  IN   EFI_PEI_FILE_HANDLE  FileHandle,
> +  IN CONST EFI_PEI_SERVICES **PeiServices
> +  )
> +{
> +  EFI_STATUS Status;
> +
> +  //
> +  // Install EFI_PEI_MM_ACCESS_PPI for S3 resume case
> +  //
> +  Status = PeiInstallSmmAccessPpi ();
> +
> +  return Status;
> +}
> diff --git 
> a/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf
> b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf
> new file mode 100644
> index ..9b654bfa
> --- /dev/null
> +++ 
> b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf
> @@ -0,0 +1,31 @@
> +### @file
> +# Component information file for the S3 Advanced PEI module.
> +#
> +# Copyright (c) 2019, Intel Corporation. All rights reserved.
> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +###
> +
> +[Defines]
> +  INF_VERSION= 0x00010017
> +  BASE_NAME  = S3AdvancedPei
> +  FILE_GUID  = 8683EFB2-FDE1-4AFF-B2DB-E96449FDD4E9
> +  VERSION_STRING = 1.0
> +  MODULE_TYPE= PEIM
> +  ENTRY_POINT= S3AdvancedEntryPoint
> +
> +[LibraryClasses]
> +  PeimEntryPoint
> +  PeiServicesLib
> +  SmmAccessLib
> +
> +[Packages]
> +  IntelSiliconPkg/IntelSiliconPkg.dec
> +  MdePkg/MdePkg.dec
> +
> +[Sources]
> +  S3AdvancedPei.c
> +
> +[Depex]
> +  TRUE
> --
> 2.16.2.windows.1
> 
> 
> 


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

View/Reply Online (#46892): https://edk2.groups.io/g/devel/message/46892
Mute This Topic: https://groups.io/mt/33151404/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] BaseTools: Fixed issue for IgnoreAutoGen

[Liming Gao]

Bob: 
 Does this change only impact -u option behavior? 

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Bob Feng
> Sent: Thursday, September 5, 2019 5:05 PM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Shi, Steven ; 
> Feng, Bob C 
> Subject: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue for IgnoreAutoGen
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2080
> 
> This patch is to improve build -u option to re-use
> GlobalVar__.bin file which is
> introduced by multiple-process-autogen feature.
> 
> Cc: Liming Gao 
> Cc: Steven Shi 
> Signed-off-by: Bob Feng 
> ---
>  .../Source/Python/AutoGen/AutoGenWorker.py|   2 +-
>  .../Source/Python/AutoGen/ModuleAutoGen.py|   4 +-
>  .../Python/AutoGen/ModuleAutoGenHelper.py |  29 ++
>  .../Source/Python/AutoGen/PlatformAutoGen.py  |   2 +
>  .../Source/Python/AutoGen/WorkspaceAutoGen.py |   1 -
>  BaseTools/Source/Python/build/build.py| 355 +++---
>  6 files changed, 255 insertions(+), 138 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
> b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
> index 2e68538b1cb4..f488ae9d5f80 100755
> --- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
> @@ -236,11 +236,11 @@ class AutoGenWorkerInProcess(mp.Process):
>  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
> +continue
> 
>  Ma.CreateCodeFile(False)
>  
> Ma.CreateMakeFile(False,GenFfsList=FfsCmd.get((Ma.MetaFile.File, Ma.Arch),[]))
> 
>  if GlobalData.gBinCacheSource and CommandTarget in [None, 
> "", "all"]:
> diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
> b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> index 3bb7e91154ac..5f28681e3146 100755
> --- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> @@ -2058,12 +2058,12 @@ class ModuleAutoGen(AutoGen):
> not gDict[(self.MetaFile.Path, self.Arch)].ModuleFilesHashDigest:
>  self.GenModuleFilesHash(gDict)
> 
>  if not (self.MetaFile.Path, self.Arch) in gDict or \
> not gDict[(self.MetaFile.Path, self.Arch)].ModuleFilesHashDigest:
> -   EdkLogger.quiet("[cache warning]: Cannot generate 
> ModuleFilesHashDigest for module %s[%s]" %(self.MetaFile.Path,
> self.Arch))
> -   return
> +EdkLogger.quiet("[cache warning]: Cannot generate 
> ModuleFilesHashDigest for module %s[%s]" %(self.MetaFile.Path,
> self.Arch))
> +return
> 
>  # Initialze hash object
>  m = hashlib.md5()
> 
>  # Add Platform level hash
> diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py 
> b/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
> index c7591253debd..9dd93b9beb12 100644
> --- a/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
> +++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
> @@ -234,22 +234,51 @@ class AutoGenInfo(object):
>  #
>  #This class is the pruned WorkSpaceAutoGen for ModuleAutoGen in multiple 
> thread
>  #
>  class WorkSpaceInfo(AutoGenInfo):
>  def __init__(self,Workspace, MetaFile, Target, ToolChain, Arch):
> +if not hasattr(self, "_Init"):
> +self.do_init(Workspace, MetaFile, Target, ToolChain, Arch)
> +self._Init = True
> +def do_init(self,Workspace, MetaFile, Target, ToolChain, Arch):
>  self._SrcTimeStamp = 0
>  self.Db = BuildDB
>  self.BuildDatabase = self.Db.BuildObject
>  self.Target = Target
>  self.ToolChain = ToolChain
>  self.WorkspaceDir = Workspace
>  self.ActivePlatform = MetaFile
>  self.ArchList = Arch
> +self.AutoGenObjectList = []
> +@property
> +def BuildDir(self):
> +return self.AutoGenObjectList[0].BuildDir
> 
> +@property
> +def Name(self):
> +return self.AutoGenObjectList[0].Platform.PlatformName
> +
> +@property
> +def FlashDefinition(self):
> +return self.AutoGenObjectList[0].Platform.FlashDefinition
> +@property
> +def GenFdsCommandDict(self):
> +FdsCommandDict = 
> self.AutoGenObjectList[0].DataPipe.Get("FdsCommandDict")
> +if FdsCommandDict:
> +return FdsCommandDict
> +return {}
> +
> +@cached_property
> +def FvDir(self):
> +return os.path.join(self.BuildDir, TAB_FV_DIRECTORY)
> 
>  class 

Re: [edk2-devel] [Patch 0/2] Enable --genfds-multi-thread to default build

[Liming Gao]

Bob:
  Can you list the platform list have been verified with this change?

Thanks
Liming> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Bob Feng
> Sent: Thursday, September 5, 2019 11:11 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [Patch 0/2] Enable --genfds-multi-thread to default 
> build
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1302
> 
> Enable --genfds-multi-thread as default build behavior can improve
> build performance but will not bring nagtive impact.
> 
> Feng, Bob C (2):
>   BaseTools: Fixed the build fail on Linux with --genfds-multi-thread
>   BaseTools: Enable --genfds-multi-thread to default build
> 
>  BaseTools/Source/Python/AutoGen/GenMake.py | 4 ++--
>  BaseTools/Source/Python/AutoGen/WorkspaceAutoGen.py| 3 +--
>  BaseTools/Source/Python/Common/GlobalData.py   | 2 +-
>  BaseTools/Source/Python/Common/buildoptions.py | 3 ++-
>  BaseTools/Source/Python/GenFds/GenFds.py   | 9 ++---
>  BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py | 4 ++--
>  BaseTools/Source/Python/build/build.py | 2 +-
>  7 files changed, 15 insertions(+), 12 deletions(-)
> 
> --
> 2.20.1.windows.1
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linking

[Ard Biesheuvel]

On Thu, 5 Sep 2019 at 07:19, Leif Lindholm  wrote:
>
> On Wed, Sep 04, 2019 at 04:04:23PM -0700, Ard Biesheuvel wrote:
> > In some cases, the CLANG38 toolchain profile in LTO mode emits GOT
> > based relocations in spite of our attempts to avoid this, by using
> > hidden visibility, -Bsymbolic etc.
> >
> > On AARCH64, we managed to work around this by processing the GOT
> > based relocations in GenFw. As it turns out, the same issue exists
> > on 32-bit ARM, but unfortunately, we cannot use a similar trick to
> > get rid of the GOT entry, and the relocation metadata is insufficient
> > to locate the GOT entry in the binary.
> >
> > A bit of trial and error reveals that switching the linker options from
> > -pie to -shared in commit e07092edca8442db4a941dbeea0cd196c7bf8ec9 was
> > not the best approach, and instead, we can pass -pie to the linker
> > directly (using -Wl,xxx) rather than to the compiler directly, which
> > turns out to massage the linker in the right way, and prevents if from
> > emitting GOT based relocations. Your mileage may vary ...
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> > Let's test this on a couple of different Clang versions. If it still
> > produces problems, the only other way I see is to disable the builds
> > of platforms that incorporate this module for ARM/CLANG38 [which is
> > not the end of the world]
> >
> >  ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf 
> > b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.in
> > index 683397b7afd1..9e58e56fce09 100755
> > --- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> > +++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> > @@ -97,4 +97,4 @@
> >gArmTokenSpaceGuid.PcdFvBaseAddress
> >
> >  [BuildOptions]
> > -  GCC:*_*_*_DLINK_FLAGS = -shared -Wl,-Bsymbolic 
> > -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > +  GCC:*_*_*_DLINK_FLAGS = 
> > -Wl,-Bsymbolic,-pie,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
>
> We already merged a fix for AARCH64 though - could/should this be
> active on ARM only?
>

I'd like to keep the GenFw change, since we've confirmed that it
correctly handles GOT based relocations should they appear. But if
this fix works for all Clang versions, I'd rather have it active for
AArch64 as well, since the best solution is still not to have any such
relocations in the first place.

> A problem I have with this patch is that ArmVirtQemuKernel curently
> doesn't boot on my qemu (with/without kvm, built with GCC5 or CLANG38,
> with or without this patch):
> ProcessPciHost: Config[0x401000+0x1000) Bus[0x0..0xFF]
> Io[0x0+0x1)@0x3EFF Mem32[0x1000+0x2EFF)@0x0
> Mem64[0x80+0x80)@0x0
> MapGcdMmioSpace: failed to set memory space attributes for region
> [0x401000+0x1000)
>
> ASSERT_EFI_ERROR (Status = Unsupported)
> ASSERT [PciHostBridgeDxe]
> /work/git/edk2/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(293):
> !EFI_ERROR (Status)
> qemu-system-arm: terminating on signal 15 from pid 4680 (killall)
>
> /
> Leif
>
> > --
> > 2.17.1
> >

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

View/Reply Online (#46904): https://edk2.groups.io/g/devel/message/46904
Mute This Topic: https://groups.io/mt/33144570/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] UefiCpuPkg: support single EFI_PEI_CORE_FV_LOCATION_PPI in PpiList

[Laszlo Ersek]

Hi All,

On 09/05/19 08:46, Ni, Ray wrote:
> Reviewed-by: Ray Ni 

Please go ahead with the push, I'll skip this.

Thanks
Laszlo

>> -Original Message-
>> From: Dong, Eric
>> Sent: Wednesday, September 4, 2019 11:15 PM
>> To: Chiu, Chasel ; devel@edk2.groups.io
>> Cc: Ni, Ray ; Laszlo Ersek 
>> Subject: RE: [PATCH v2] UefiCpuPkg: support single 
>> EFI_PEI_CORE_FV_LOCATION_PPI in PpiList
>>
>> Reviewed-by: Eric Dong 
>>
>>> -Original Message-
>>> From: Chiu, Chasel
>>> Sent: Thursday, September 5, 2019 12:27 PM
>>> To: devel@edk2.groups.io
>>> Cc: Dong, Eric ; Ni, Ray ; Laszlo
>>> Ersek 
>>> Subject: [PATCH v2] UefiCpuPkg: support single
>>> EFI_PEI_CORE_FV_LOCATION_PPI in PpiList
>>>
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2153
>>>
>>> Current logic will skip searching EFI_PEI_CORE_FV_LOCATION_PPI when the
>>> PPI in PpiList having EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag, but
>>> platform may pass single PPI in PpiList that should be supported.
>>>
>>> Changed the logic to verify PpiList first before checking
>>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag.
>>>
>>> Test: Verified both single EFI_PEI_CORE_FV_LOCATION_PPI and multiple
>>>   PPIs in PpiList cases and both can boot with the PeiCore
>>>   specified by EFI_PEI_CORE_FV_LOCATION_PPI.
>>>
>>> Cc: Eric Dong 
>>> Cc: Ray Ni 
>>> Cc: Laszlo Ersek 
>>> Signed-off-by: Chasel Chiu 
>>> ---
>>>  UefiCpuPkg/SecCore/SecMain.c | 9 -
>>>  1 file changed, 4 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/UefiCpuPkg/SecCore/SecMain.c b/UefiCpuPkg/SecCore/SecMain.c
>>> index 66c952b897..5d5e7f17dc 100644
>>> --- a/UefiCpuPkg/SecCore/SecMain.c
>>> +++ b/UefiCpuPkg/SecCore/SecMain.c
>>> @@ -238,9 +238,8 @@ SecStartupPhase2(
>>>// is enabled.
>>>//
>>>if (PpiList != NULL) {
>>> -for (Index = 0;
>>> -  (PpiList[Index].Flags & EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) !=
>>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST;
>>> -  Index++) {
>>> +Index = 0;
>>> +do {
>>>if (CompareGuid (PpiList[Index].Guid, ) 
>>> &&
>>>(((EFI_PEI_CORE_FV_LOCATION_PPI *) PpiList[Index].Ppi)-
 PeiCoreFvLocation != 0)
>>>   ) {
>>> @@ -256,12 +255,12 @@ SecStartupPhase2(
>>>break;
>>>  } else {
>>>//
>>> -  // PeiCore not found
>>> +  // Invalid PeiCore FV provided by platform
>>>//
>>>CpuDeadLoop ();
>>>  }
>>>}
>>> -}
>>> +} while ((PpiList[Index++].Flags &
>>> + EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) !=
>>> + EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST);
>>>}
>>>//
>>>// If EFI_PEI_CORE_FV_LOCATION_PPI not found, try to locate PeiCore from
>>> BFV.
>>> --
>>> 2.13.3.windows.1
> 


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

View/Reply Online (#46896): https://edk2.groups.io/g/devel/message/46896
Mute This Topic: https://groups.io/mt/33150264/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] BaseTools: Fixed issue for IgnoreAutoGen

[Bob Feng]

Liming,

Yes, this change only impact -u option. 

I separate _MultiThreadBuildPlatform function into two functions and create 2 
new functions specially for IgnoreAutoGen, so the there looks  big change for 
build.py in this patch. I verified this patch on Ovmf, E

-Bob

-Original Message-
From: Gao, Liming 
Sent: Thursday, September 5, 2019 9:12 PM
To: devel@edk2.groups.io; Feng, Bob C 
Cc: Shi, Steven 
Subject: RE: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue for IgnoreAutoGen

Bob: 
 Does this change only impact -u option behavior? 

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Bob Feng
> Sent: Thursday, September 5, 2019 5:05 PM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Shi, Steven 
> ; Feng, Bob C 
> Subject: [edk2-devel] [Patch 1/1] BaseTools: Fixed issue for 
> IgnoreAutoGen
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2080
> 
> This patch is to improve build -u option to re-use 
> GlobalVar__.bin file which is introduced by 
> multiple-process-autogen feature.
> 
> Cc: Liming Gao 
> Cc: Steven Shi 
> Signed-off-by: Bob Feng 
> ---
>  .../Source/Python/AutoGen/AutoGenWorker.py|   2 +-
>  .../Source/Python/AutoGen/ModuleAutoGen.py|   4 +-
>  .../Python/AutoGen/ModuleAutoGenHelper.py |  29 ++
>  .../Source/Python/AutoGen/PlatformAutoGen.py  |   2 +
>  .../Source/Python/AutoGen/WorkspaceAutoGen.py |   1 -
>  BaseTools/Source/Python/build/build.py| 355 +++---
>  6 files changed, 255 insertions(+), 138 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
> b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
> index 2e68538b1cb4..f488ae9d5f80 100755
> --- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
> @@ -236,11 +236,11 @@ class AutoGenWorkerInProcess(mp.Process):
>  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
> +continue
> 
>  Ma.CreateCodeFile(False)
>
> Ma.CreateMakeFile(False,GenFfsList=FfsCmd.get((Ma.MetaFile.File, 
> Ma.Arch),[]))
> 
>  if GlobalData.gBinCacheSource and CommandTarget in [None, 
> "", "all"]:
> diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
> b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> index 3bb7e91154ac..5f28681e3146 100755
> --- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
> @@ -2058,12 +2058,12 @@ class ModuleAutoGen(AutoGen):
> not gDict[(self.MetaFile.Path, self.Arch)].ModuleFilesHashDigest:
>  self.GenModuleFilesHash(gDict)
> 
>  if not (self.MetaFile.Path, self.Arch) in gDict or \
> not gDict[(self.MetaFile.Path, self.Arch)].ModuleFilesHashDigest:
> -   EdkLogger.quiet("[cache warning]: Cannot generate 
> ModuleFilesHashDigest for module %s[%s]" %(self.MetaFile.Path,
> self.Arch))
> -   return
> +EdkLogger.quiet("[cache warning]: Cannot generate 
> + ModuleFilesHashDigest for module %s[%s]" %(self.MetaFile.Path,
> self.Arch))
> +return
> 
>  # Initialze hash object
>  m = hashlib.md5()
> 
>  # Add Platform level hash
> diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py 
> b/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
> index c7591253debd..9dd93b9beb12 100644
> --- a/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
> +++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
> @@ -234,22 +234,51 @@ class AutoGenInfo(object):
>  #
>  #This class is the pruned WorkSpaceAutoGen for ModuleAutoGen in 
> multiple thread  #  class WorkSpaceInfo(AutoGenInfo):
>  def __init__(self,Workspace, MetaFile, Target, ToolChain, Arch):
> +if not hasattr(self, "_Init"):
> +self.do_init(Workspace, MetaFile, Target, ToolChain, Arch)
> +self._Init = True
> +def do_init(self,Workspace, MetaFile, Target, ToolChain, Arch):
>  self._SrcTimeStamp = 0
>  self.Db = BuildDB
>  self.BuildDatabase = self.Db.BuildObject
>  self.Target = Target
>  self.ToolChain = ToolChain
>  self.WorkspaceDir = Workspace
>  self.ActivePlatform = MetaFile
>  self.ArchList = Arch
> +self.AutoGenObjectList = []
> +@property
> +def BuildDir(self):
> +return self.AutoGenObjectList[0].BuildDir
> 
> +@property
> +def Name(self):
> +return self.AutoGenObjectList[0].Platform.PlatformName
> +
> 

Re: [edk2-devel] [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linking

[Ard Biesheuvel]

On Thu, 5 Sep 2019 at 07:19, Leif Lindholm  wrote:
>
> On Wed, Sep 04, 2019 at 04:04:23PM -0700, Ard Biesheuvel wrote:
> > In some cases, the CLANG38 toolchain profile in LTO mode emits GOT
> > based relocations in spite of our attempts to avoid this, by using
> > hidden visibility, -Bsymbolic etc.
> >
> > On AARCH64, we managed to work around this by processing the GOT
> > based relocations in GenFw. As it turns out, the same issue exists
> > on 32-bit ARM, but unfortunately, we cannot use a similar trick to
> > get rid of the GOT entry, and the relocation metadata is insufficient
> > to locate the GOT entry in the binary.
> >
> > A bit of trial and error reveals that switching the linker options from
> > -pie to -shared in commit e07092edca8442db4a941dbeea0cd196c7bf8ec9 was
> > not the best approach, and instead, we can pass -pie to the linker
> > directly (using -Wl,xxx) rather than to the compiler directly, which
> > turns out to massage the linker in the right way, and prevents if from
> > emitting GOT based relocations. Your mileage may vary ...
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> > Let's test this on a couple of different Clang versions. If it still
> > produces problems, the only other way I see is to disable the builds
> > of platforms that incorporate this module for ARM/CLANG38 [which is
> > not the end of the world]
> >
> >  ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf 
> > b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.in
> > index 683397b7afd1..9e58e56fce09 100755
> > --- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> > +++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> > @@ -97,4 +97,4 @@
> >gArmTokenSpaceGuid.PcdFvBaseAddress
> >
> >  [BuildOptions]
> > -  GCC:*_*_*_DLINK_FLAGS = -shared -Wl,-Bsymbolic 
> > -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > +  GCC:*_*_*_DLINK_FLAGS = 
> > -Wl,-Bsymbolic,-pie,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
>
> We already merged a fix for AARCH64 though - could/should this be
> active on ARM only?
>
> A problem I have with this patch is that ArmVirtQemuKernel curently
> doesn't boot on my qemu (with/without kvm, built with GCC5 or CLANG38,
> with or without this patch):
> ProcessPciHost: Config[0x401000+0x1000) Bus[0x0..0xFF]
> Io[0x0+0x1)@0x3EFF Mem32[0x1000+0x2EFF)@0x0
> Mem64[0x80+0x80)@0x0
> MapGcdMmioSpace: failed to set memory space attributes for region
> [0x401000+0x1000)
>
> ASSERT_EFI_ERROR (Status = Unsupported)
> ASSERT [PciHostBridgeDxe]
> /work/git/edk2/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(293):
> !EFI_ERROR (Status)
> qemu-system-arm: terminating on signal 15 from pid 4680 (killall)
>

Does it work with -M virt,highmem=off ?

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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 09/22]: MdePkg/BaseCpuLib: RISC-V Base CPU library implementation.

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:04PM +0800, Abner Chang wrote:
> Implement RISC-V CPU related functions in BaseCpuLib.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0

Apart from the CLA and the License of the new file, this one looks
fine to me.

/
Leif

> Signed-off-by: Abner Chang 
> ---
>  MdePkg/Library/BaseCpuLib/BaseCpuLib.inf |  4 
>  MdePkg/Library/BaseCpuLib/RiscV/Cpu.s| 25 +
>  2 files changed, 29 insertions(+)
>  create mode 100644 MdePkg/Library/BaseCpuLib/RiscV/Cpu.s
> 
> diff --git a/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf 
> b/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
> index a7cb381..20ee774 100644
> --- a/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
> +++ b/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
> @@ -7,6 +7,7 @@
>  #  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
>  #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
>  #  Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
> +#  Copyright (c) 2016, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -59,6 +60,9 @@
>AArch64/CpuFlushTlb.asm | MSFT
>AArch64/CpuSleep.asm| MSFT
>  
> +[Sources.RISCV64]
> +  RiscV/Cpu.s
> +
>  [Packages]
>MdePkg/MdePkg.dec
>  
> diff --git a/MdePkg/Library/BaseCpuLib/RiscV/Cpu.s 
> b/MdePkg/Library/BaseCpuLib/RiscV/Cpu.s
> new file mode 100644
> index 000..9a1bf0f
> --- /dev/null
> +++ b/MdePkg/Library/BaseCpuLib/RiscV/Cpu.s
> @@ -0,0 +1,25 @@
> +//--
> +//
> +// CpuSleep for RISC-V
> +//
> +// Copyright (c) 2016, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +// This program and the accompanying materials
> +// are licensed and made available under the terms and conditions of the BSD 
> License
> +// which accompanies this distribution.  The full text of the license may be 
> found at
> +// http://opensource.org/licenses/bsd-license.php.
> +//
> +// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +// WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +//
> +//--
> +.data
> +.align 3
> +.section .text
> +
> +.global ASM_PFX(_CpuSleep)
> +
> +ASM_PFX(_CpuSleep):
> +wfi
> +ret
> +
> +
> -- 
> 2.7.4
> 
> 
> 
> 

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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 11/22]: BaseTools: BaseTools changes for RISC-V platform.

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:06PM +0800, Abner Chang wrote:
> BaseTools changes for building EDK2 RISC-V platform.
> The changes made to build_rule.template is to avoid build errors cause by 
> GCC711RISCV tool chain.

What errors?

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 
> ---
>  BaseTools/Conf/build_rule.template |   23 +-
>  BaseTools/Conf/tools_def.template  |  108 +-
>  BaseTools/Source/C/Common/BasePeCoff.c |   19 +-
>  BaseTools/Source/C/Common/PeCoffLoaderEx.c |   96 ++
>  BaseTools/Source/C/GenFv/GenFvInternalLib.c|  281 -
>  BaseTools/Source/C/GenFw/Elf32Convert.c|6 +-
>  BaseTools/Source/C/GenFw/Elf64Convert.c|  273 -
>  BaseTools/Source/C/GenFw/elf_common.h  |   63 ++
>  .../Source/C/Include/IndustryStandard/PeImage.h|   10 +
>  BaseTools/Source/Python/Common/DataType.py | 1075 
> ++--
>  10 files changed, 1393 insertions(+), 561 deletions(-)
> 
> diff --git a/BaseTools/Conf/build_rule.template 
> b/BaseTools/Conf/build_rule.template
> index db06d3a..8e7f6e0 100755
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -145,14 +145,6 @@
>  
>  "$(CC)" $(CC_FLAGS) $(CC_XIPFLAGS) -c -o ${dst} $(INC) ${src}
>  
> -[C-Header-File]
> -
> -*.h, *.H
> -
> -
> -
> -
> -
>  [Assembly-Code-File.COMMON.COMMON]
>  
>  ?.asm, ?.Asm, ?.ASM
> @@ -321,6 +313,21 @@
>  "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
>  
>  
> +[Static-Library-File.COMMON.RISCV64, Static-Library-File.COMMON.RISCV32]
> +
> +*.lib
> +
> +
> +$(MAKE_FILE)
> +
> +
> +$(DEBUG_DIR)(+)$(MODULE_NAME).dll
> +
> +
> +"$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
> @$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
> +"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
> +
> +
>  [Static-Library-File.USER_DEFINED, Static-Library-File.HOST_APPLICATION]
>  
>  *.lib
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 8f0e6cb..36a301a 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -3,7 +3,7 @@
>  #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
>  #  Portions copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
>  #  Copyright (c) 2015, Hewlett-Packard Development Company, L.P.
> -#  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
> +#  (C) Copyright 2016-2019 Hewlett Packard Enterprise Development LP
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -114,6 +114,12 @@ DEFINE GCC49_X64_PREFIX= ENV(GCC49_BIN)
>  DEFINE GCC5_IA32_PREFIX= ENV(GCC5_BIN)
>  DEFINE GCC5_X64_PREFIX = ENV(GCC5_BIN)
>  DEFINE GCC_HOST_PREFIX = ENV(GCC_HOST_BIN)
> +#
> +# RISC-V GCC toolchain
> +# This is the default directory used when install official riscv-tools.
> +#
> +DEFINE GCCRISCV_RISCV32_PREFIX = ENV(GCC_RISCV32_BIN)

I won't complain about adding 32-bit RISC-V things to industry
standard headers, but apart from that I don't want to see bits of
32-bit support trickle through until there is actually a full port
going in. So please delete all lines including "RISCV32" in this file.

> +DEFINE GCCRISCV_RISCV64_PREFIX = ENV(GCC_RISCV64_BIN)
>  
>  DEFINE UNIX_IASL_BIN   = ENV(IASL_PREFIX)iasl
>  DEFINE WIN_IASL_BIN= ENV(IASL_PREFIX)iasl.exe
> @@ -236,6 +242,15 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
>  # Required to build platforms or ACPI tables:
>  #   Intel(r) ACPI Compiler from
>  #   https://acpica.org/downloads
> +#   GCCRISCV- Linux   -  Requires:
> +# RISC-V official release of RISC-V GNU 
> toolchain,
> +#   https://github.com/riscv/riscv-gnu-toolchain 
> @64879b24
> +#   The commit ID 64879b24 is the one can build 
> RISC-V platform and boo to EFI shell.
> +#   Follow the instructions mentioned in 
> README.md to build RISC-V tool change.
> +# Set below environment variables to the RISC-V 
> tool chain binaries before building RISC-V EDK2 port.
> +#   - GCC_RISCV32_BIN
> +#   - GCC_RISCV64_BIN
> +#
>  #   CLANG35 -Linux,Windows-  Requires:
>  # Clang v3.5 or later, and GNU binutils 
> targeting aarch64-linux-gnu or arm-linux-gnueabi
>  #Optional:
> @@ -1806,6 +1821,26 @@ DEFINE GCC5_ARM_ASLDLINK_FLAGS   = 
> DEF(GCC49_ARM_ASLDLINK_FLAGS)
>  DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   = DEF(GCC49_AARCH64_ASLDLINK_FLAGS)
>  DEFINE GCC5_ASLCC_FLAGS  = 

[edk2-devel] [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address

[Igor Mammedov]

lpc already has SMI negotiation feature, extend it by adding
optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features.

Writing this bit into "etc/smi/requested-features" fw_cfg file,
tells QEMU to alias 0x3,128K RAM range into SMRAM address
space and mask this region from normal RAM address space
(reads return 0xff and writes are ignored, i.e. guest code
should be able to deal with not usable 0x3,128K RAM range
once ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT is activated).

To make negotiated change effective, guest should read
"etc/smi/features-ok" fw_cfg file, which activates negotiated
features and locks down negotiating capabilities until hard reset.

Flow for initializing SMI handler on guest side:
 1. set SMI handler entry point at default SMBASE location
 2. check that host supports ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT
in "etc/smi/supported-features" and set if supported set
it in "etc/smi/requested-features"
 3. read "etc/smi/features-ok", if returned value is 1
negotiated at step 2 features are activated successfully.

Signed-off-by: Igor Mammedov 
---
 include/hw/i386/ich9.h | 11 ++--
 hw/i386/pc.c   |  4 ++-
 hw/i386/pc_q35.c   |  3 ++-
 hw/isa/lpc_ich9.c  | 58 +-
 4 files changed, 71 insertions(+), 5 deletions(-)

diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
index 72e803f6e2..c28685b753 100644
--- a/include/hw/i386/ich9.h
+++ b/include/hw/i386/ich9.h
@@ -12,11 +12,14 @@
 #include "hw/acpi/acpi.h"
 #include "hw/acpi/ich9.h"
 #include "hw/pci/pci_bus.h"
+#include "qemu/units.h"
 
 void ich9_lpc_set_irq(void *opaque, int irq_num, int level);
 int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx);
 PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
-void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled);
+void ich9_lpc_pm_init(PCIDevice *pci_lpc, bool smm_enabled,
+  MemoryRegion *system_memory, MemoryRegion *ram,
+  MemoryRegion *smram);
 I2CBus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
 
 void ich9_generate_smi(void);
@@ -71,6 +74,8 @@ typedef struct ICH9LPCState {
 uint8_t smi_features_ok;  /* guest-visible, read-only; selecting it
* triggers feature lockdown */
 uint64_t smi_negotiated_features; /* guest-invisible, host endian */
+MemoryRegion smbase_blackhole;
+MemoryRegion smbase_window;
 
 /* isa bus */
 ISABus *isa_bus;
@@ -248,5 +253,7 @@ typedef struct ICH9LPCState {
 
 /* bit positions used in fw_cfg SMI feature negotiation */
 #define ICH9_LPC_SMI_F_BROADCAST_BIT0
-
+#define ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT1
+#define ICH9_LPC_SMBASE_ADDR0x3
+#define ICH9_LPC_SMBASE_RAM_SIZE(128 * KiB)
 #endif /* HW_ICH9_H */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index c14ed86439..99a98303eb 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -119,7 +119,9 @@ struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
 /* Physical Address of PVH entry point read from kernel ELF NOTE */
 static size_t pvh_start_addr;
 
-GlobalProperty pc_compat_4_1[] = {};
+GlobalProperty pc_compat_4_1[] = {
+{ "ICH9-LPC", "x-smi-locked-smbase", "off" },
+};
 const size_t pc_compat_4_1_len = G_N_ELEMENTS(pc_compat_4_1);
 
 GlobalProperty pc_compat_4_0[] = {};
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d4e8a1cb9f..50462686a0 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -292,7 +292,8 @@ static void pc_q35_init(MachineState *machine)
  0xff0104);
 
 /* connect pm stuff to lpc */
-ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms));
+ich9_lpc_pm_init(lpc, pc_machine_is_smm_enabled(pcms), get_system_memory(),
+ram_memory, MEMORY_REGION(object_resolve_path("/machine/smram", 
NULL)));
 
 if (pcms->sata_enabled) {
 /* ahci and SATA device, for q35 1 ahci controller is built-in */
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 17c292e306..17a8cd1b51 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -359,6 +359,38 @@ static void ich9_set_sci(void *opaque, int irq_num, int 
level)
 }
 }
 
+static uint64_t smbase_blackhole_read(void *ptr, hwaddr reg, unsigned size)
+{
+return 0x;
+}
+
+static void smbase_blackhole_write(void *opaque, hwaddr addr, uint64_t val,
+   unsigned width)
+{
+/* nothing */
+}
+
+static const MemoryRegionOps smbase_blackhole_ops = {
+.read = smbase_blackhole_read,
+.write = smbase_blackhole_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.valid.min_access_size = 1,
+.valid.max_access_size = 4,
+.impl.min_access_size = 4,
+.impl.max_access_size = 4,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void ich9_lpc_smbase_locked_update(ICH9LPCState *lpc)
+{
+bool en = lpc->smi_negotiated_features & ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT;
+
+

Re: [edk2-devel] [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linking

[Leif Lindholm]

On Thu, Sep 05, 2019 at 07:25:39AM -0700, Ard Biesheuvel wrote:
> > >  [BuildOptions]
> > > -  GCC:*_*_*_DLINK_FLAGS = -shared -Wl,-Bsymbolic 
> > > -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > > +  GCC:*_*_*_DLINK_FLAGS = 
> > > -Wl,-Bsymbolic,-pie,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> >
> > We already merged a fix for AARCH64 though - could/should this be
> > active on ARM only?
> >
> > A problem I have with this patch is that ArmVirtQemuKernel curently
> > doesn't boot on my qemu (with/without kvm, built with GCC5 or CLANG38,
> > with or without this patch):
> > ProcessPciHost: Config[0x401000+0x1000) Bus[0x0..0xFF]
> > Io[0x0+0x1)@0x3EFF Mem32[0x1000+0x2EFF)@0x0
> > Mem64[0x80+0x80)@0x0
> > MapGcdMmioSpace: failed to set memory space attributes for region
> > [0x401000+0x1000)
> >
> > ASSERT_EFI_ERROR (Status = Unsupported)
> > ASSERT [PciHostBridgeDxe]
> > /work/git/edk2/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(293):
> > !EFI_ERROR (Status)
> > qemu-system-arm: terminating on signal 15 from pid 4680 (killall)
> >
> 
> Does it work with -M virt,highmem=off ?

Ah, yes - that works fine then, also with the patch.

Well, with that, and your explanation in the other thread:
Acked-by: Leif Lindholm 

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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 17/22]: RiscVPkg/SmbiosDxe: RISC-V platform generic SMBIOS DXE driver

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:12PM +0800, Abner Chang wrote:
> RISC-V generic SMBIOS DXE driver for building up SMBIOS type 4, type 7 and 
> type 44 records.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 
> ---
>  RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.c  | 343 
> +
>  RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.h  |  38 +++
>  RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.inf|  63 
>  RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.uni| Bin 0 -> 1542 bytes
>  .../Universal/SmbiosDxe/RiscVSmbiosDxeExtra.uni| Bin 0 -> 1438 bytes
>  5 files changed, 444 insertions(+)
>  create mode 100644 RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.c
>  create mode 100644 RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.h
>  create mode 100644 RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.inf
>  create mode 100644 RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.uni
>  create mode 100644 RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxeExtra.uni
> 
> diff --git a/RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.c 
> b/RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.c
> new file mode 100644
> index 000..b59af1a
> --- /dev/null
> +++ b/RiscVPkg/Universal/SmbiosDxe/RiscVSmbiosDxe.c
> @@ -0,0 +1,343 @@
> +/** @file
> +  RISC-V generic SMBIOS DXE driver to build up SMBIOS type 4, type 7 and 
> type 44 records.
> +
> +  Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +
> +  This program and the accompanying materials are
> +  licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include "RiscVSmbiosDxe.h"
> +
> +#define RISCV_SMBIOS_DEBUG_INFO 1
> +
> +EFI_SMBIOS_PROTOCOL   *Smbios;
> +
> +/**
> +  This function builds SMBIOS type 7 record according to 
> +  the given  RISC_V_PROCESSOR_TYPE7_DATA_HOB.
> +   
> +  @param Type4DataHob   Pointer to RISC_V_PROCESSOR_TYPE4_DATA_HOB   
> +  @param Type7DataHob   Pointer to RISC_V_PROCESSOR_TYPE7_DATA_HOB
> +  @param SmbiosHandle   Pointer to SMBIOS_HANDLE
> +   
> +  @retval EFI_STATUS
> +
> +**/
> +static
> +EFI_STATUS
> +BuildSmbiosType7 (
> + IN RISC_V_PROCESSOR_TYPE4_DATA_HOB *Type4DataHob,
> + IN RISC_V_PROCESSOR_TYPE7_DATA_HOB *Type7DataHob,
> + OUT SMBIOS_HANDLE *SmbiosHandle
> +)
> +{
> +  EFI_STATUS Status;
> +  SMBIOS_HANDLE Handle;
> +
> +  if (!CompareGuid (>PrcessorGuid, 
> >PrcessorGuid) ||
> +Type4DataHob->ProcessorUid != Type7DataHob->ProcessorUid) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +  Handle = SMBIOS_HANDLE_PI_RESERVED;
> +  Type7DataHob->SmbiosType7Cache.Hdr.Type = SMBIOS_TYPE_CACHE_INFORMATION; 
> +  Type7DataHob->SmbiosType7Cache.Hdr.Length = sizeof(SMBIOS_TABLE_TYPE7);
> +  Type7DataHob->SmbiosType7Cache.Hdr.Handle = 0;
> +  Status = Smbios->Add (Smbios, NULL, , 
> >SmbiosType7Cache.Hdr);
> +  if (EFI_ERROR(Status)) {
> +DEBUG ((EFI_D_ERROR, "[RISC-V SMBIOS Builder]: Fail to add SMBIOS Type 
> 7\n"));
> +return Status;
> +  }
> +  DEBUG ((EFI_D_INFO, "[RISC-V SMBIOS Builder]: SMBIOS Type 7 was added. 
> SMBIOS Handle: 0x%x\n", Handle));
> +#if RISCV_SMBIOS_DEBUG_INFO
> +  DEBUG ((EFI_D_INFO, " Cache belone to processor 
> GUID: %g\n", >PrcessorGuid));
> +  DEBUG ((EFI_D_INFO, " Cache belone processor  UID: 
> %d\n", Type7DataHob->ProcessorUid));
> +  DEBUG ((EFI_D_INFO, " 
> ==\n"));
> +  DEBUG ((EFI_D_INFO, " Socket Designation: %d\n", 
> Type7DataHob->SmbiosType7Cache.SocketDesignation));
> +  DEBUG ((EFI_D_INFO, " Cache Configuration: 
> 0x%x\n", Type7DataHob->SmbiosType7Cache.CacheConfiguration));
> +  DEBUG ((EFI_D_INFO, " Maximum Cache Size: 0x%x\n", 
> Type7DataHob->SmbiosType7Cache.MaximumCacheSize));
> +  DEBUG ((EFI_D_INFO, " Installed Size: 0x%x\n", 
> Type7DataHob->SmbiosType7Cache.InstalledSize));
> +  DEBUG ((EFI_D_INFO, " Supported SRAM Type: 
> 0x%x\n", Type7DataHob->SmbiosType7Cache.SupportedSRAMType));
> +  DEBUG ((EFI_D_INFO, " Current SRAMT ype: 0x%x\n", 
> Type7DataHob->SmbiosType7Cache.CurrentSRAMType));
> +  DEBUG ((EFI_D_INFO, " Cache Speed: 0x%x\n", 
> Type7DataHob->SmbiosType7Cache.CacheSpeed));
> +  DEBUG ((EFI_D_INFO, " Error Correction Type: 
> 0x%x\n", Type7DataHob->SmbiosType7Cache.ErrorCorrectionType));
> +  DEBUG ((EFI_D_INFO, " System Cache Type: 0x%x\n", 
> Type7DataHob->SmbiosType7Cache.SystemCacheType));
> +  DEBUG ((EFI_D_INFO, "   

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 19/22]: MdeModulePkg/DxeIplPeim:RISC-V platform DXEIPL.

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:14PM +0800, Abner Chang wrote:
> - Implement RISC-V DxeIpl.
> - Provide DxeIpl platform implementation-specifc library for RISC-V platform. 
> Two libraries are provided in this commit,
>   * Defualt library which simply switch stack and transfer
> control to DXE core.
>   * Switch stack, privilege mode and then transfer control to
> DXE core through RISC-V opensbi.

No comments beyond SPDX/license and contribution agreement.

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 
> ---
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf| 13 +++-
>  MdeModulePkg/Core/DxeIplPeim/RiscV64/DxeLoadFunc.c | 76 
> ++
>  2 files changed, 88 insertions(+), 1 deletion(-)
>  create mode 100644 MdeModulePkg/Core/DxeIplPeim/RiscV64/DxeLoadFunc.c
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> index 98bc17f..5532323 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> @@ -7,6 +7,7 @@
>  #
>  #  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #  Copyright (c) 2017, AMD Incorporated. All rights reserved.
> +#  Copyright (c) 2016 - 2019, Hewlett Packard Enterprise Development LP. All 
> rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -25,7 +26,7 @@
>  #
>  # The following information is for reference only and not required by the 
> build tools.
>  #
> -#  VALID_ARCHITECTURES   = IA32 X64 EBC (EBC is for build only) 
> AARCH64
> +#  VALID_ARCHITECTURES   = IA32 X64 EBC (EBC is for build only) 
> AARCH64 RISCV64
>  #
>  
>  [Sources]
> @@ -49,6 +50,9 @@
>  [Sources.ARM, Sources.AARCH64]
>Arm/DxeLoadFunc.c
>  
> +[Sources.RISCV64]
> +  RiscV64/DxeLoadFunc.c
> +
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> @@ -56,6 +60,9 @@
>  [Packages.ARM, Packages.AARCH64]
>ArmPkg/ArmPkg.dec
>  
> +[Packages.RISCV64]
> +  RiscVPkg/RiscVPkg.dec
> +
>  [LibraryClasses]
>PcdLib
>MemoryAllocationLib
> @@ -75,6 +82,10 @@
>  [LibraryClasses.ARM, LibraryClasses.AARCH64]
>ArmMmuLib
>  
> +[LibraryClasses.RISCV64]
> +  RiscVPlatformDxeIplLib
> +  RiscVOpensbiLib
> +
>  [Ppis]
>gEfiDxeIplPpiGuid  ## PRODUCES
>gEfiPeiDecompressPpiGuid   ## PRODUCES
> diff --git a/MdeModulePkg/Core/DxeIplPeim/RiscV64/DxeLoadFunc.c 
> b/MdeModulePkg/Core/DxeIplPeim/RiscV64/DxeLoadFunc.c
> new file mode 100644
> index 000..934dfa5
> --- /dev/null
> +++ b/MdeModulePkg/Core/DxeIplPeim/RiscV64/DxeLoadFunc.c
> @@ -0,0 +1,76 @@
> +/** @file
> +  RISC-V specific functionality for DxeLoad.
> +
> +  Copyright (c) 2016 - 2019, Hewlett Packard Enterprise Development LP. All 
> rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution. The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +**/
> +
> +#include "DxeIpl.h"
> +#include "Library/RiscVPlatformDxeIpl.h"
> +
> +typedef
> +VOID*
> +(EFIAPI *DXEENTRYPOINT) (
> +  IN  VOID *HobStart
> +  );
> +
> +/**
> +   Transfers control to DxeCore.
> +
> +   This function performs a CPU architecture specific operations to execute
> +   the entry point of DxeCore with the parameters of HobList.
> +   It also installs EFI_END_OF_PEI_PPI to signal the end of PEI phase.
> +
> +   @param DxeCoreEntryPoint The entry point of DxeCore.
> +   @param HobList   The start of HobList passed to DxeCore.
> +
> +**/
> +VOID
> +HandOffToDxeCore (
> +  IN EFI_PHYSICAL_ADDRESS   DxeCoreEntryPoint,
> +  IN EFI_PEI_HOB_POINTERS   HobList
> +  )
> +{
> +  VOID*BaseOfStack;
> +  VOID*TopOfStack;
> +  EFI_STATUS  Status;
> +  //
> +  //
> +  // Allocate 128KB for the Stack
> +  //
> +  BaseOfStack = AllocatePages (EFI_SIZE_TO_PAGES (STACK_SIZE));
> +  ASSERT (BaseOfStack != NULL);
> +
> +  //
> +  // Compute the top of the stack we were allocated. Pre-allocate a UINTN
> +  // for safety.
> +  //
> +  TopOfStack = (VOID *) ((UINTN) BaseOfStack + EFI_SIZE_TO_PAGES 
> (STACK_SIZE) * EFI_PAGE_SIZE - CPU_STACK_ALIGNMENT);
> +  TopOfStack = ALIGN_POINTER (TopOfStack, CPU_STACK_ALIGNMENT);
> +
> +  //
> +  // End of PEI phase signal
> +  //
> +  Status = PeiServicesInstallPpi ();
> +  ASSERT_EFI_ERROR (Status);
> +
> +  //
> +  // Update the contents of BSP stack HOB to reflect the real stack info 
> passed to DxeCore.
> +  //
> +  UpdateStackHob ((EFI_PHYSICAL_ADDRESS)(UINTN) BaseOfStack, STACK_SIZE);
> +
> +  DEBUG ((EFI_D_INFO, "DXE Core new 

Re: [edk2-devel] [PATCH 00/22] RISC-V EDK2 Port on edk2-staging/RISC-V-V2 branch

[Leif Lindholm]

Hi Abner,

Many thanks for this.
I have now gone through all of the patches, and left some specific as
well as some general comments. Please address those, or comment on why
you would prefer not changing.

For v2, could you do a few things please (some of which I've mentioned
throughout my comments on various patches):
- Run PatchCheck.py on all patches and address the output. If you
  disagree with some specific failure, please comment on this below
  the --- in the commit message in the generated patch.
- Run SetupGit.py in your edk2 repository (this includes installing
  git-python)
- Run BaseTools/Scripts/GetMaintainer.py on each of the commits, and
  add a Cc: tag for each person listed in the output to the commit
  message of that patch. Then add all of those Cc:d people as Cc: tags
  to the [0/xx patch for the next set. This wat they will all get Cc:d
  on the patches that are relevant to them.
  Few read all messages posted to edk2-devel diligently, so it's
  possible they will have missed this set completely. (Feel free to
  reply to your patches from v1, adding the relevant reviewers to cc.)
- Add your own entry in Maintainers.txt for the new packages.
  My suggestion would be that you add yourself as a designated
  reviewer (R:) for now. Find some people willing to actually sling
  the patches and add them as M: for now. I would be willing to be one
  of them as long as you can also find others :)
- Convert all of the .uni files to UTF-8 (no BOM, I think?).

Additionally, it would be really helpful if you could include a link
to the set on a branch in a public git repository
somewhere. Converting the .uni files to UTF-8 should make it possible
for my usual scripts to start working again, but being able to just
pull from a repo is even easier.

Best Regards,

Leif

On Wed, Sep 04, 2019 at 06:42:55PM +0800, Abner Chang wrote:
> This branch "RISC-V-V2" is used to contribute RISC-V architecture on EDK2.
> Compare to the old branch "RISC-V", this branch "RISC-V-V2" is created based 
> on
> the most recent edk2/master @37eef910. This is easier for reviewers to have
> clear ideas of edk2 code changes for RISC-V EDK2 implementation.
> Because of the code changes made on old branch "RISC-V" is stale and not
> compliant with the latest RISC-V spec, this new branch has the fresh changes
> for RISC-V EDK2 implementation.
> 
> The main changes of these series of patches are,
> - Add RiscVPkg which conform with RISC-V Privilege Spec v1.10.
> - Incorporate and leverage RISC-V OpenSBI to provide EDK2 port OpenSBI 
> library.
> - Provide RISC-V platform implementation specific drivers to EDK2 RISC-V 
> platform
>   package.
> - Provide generic RISC-V SMBIOS DXE drive to create SMBIOS type 4, 7 and 44 
> records,
>   in which the SMBIOS type 44 record is introduced in SMBIOS spec 3.3.0.
> 
> 
> Abner Chang (22):
>   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg: RISC-V processor package.
>   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg/Include: Add header files
> of RISC-V CPU package
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg: RISC-V sections in DEC
> file.
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/Include: RISC-V definitions.
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdeModulePkg/CapsuleRuntimeDxe: Add
> RISC-V arch.
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BaseCacheMaintenanceLib:
> RISC-V cache maintenance implementation.
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BaseIoLibIntrinsic: RISC-V
> I/O intrinsic functions.
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BasePeCoff: Add RISC-V
> PE/Coff related code.
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BaseCpuLib: RISC-V Base CPU
> library implementation.
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BaseSynchronizationLib:
> RISC-V cache related code.
>   [edk2-staging/RISC-V-V2 PATCH v1]: BaseTools: BaseTools changes for
> RISC-V platform.
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BaseLib: BaseLib for RISC-V
> RV64 Processor.
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/Include: Update SmBios
> header file.
>   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg/opesbi: Add
> opensbi-HOWTO.txt
>   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg/RealTimeClockRuntimeDxe:
> Add RISC-V RTC Runtime Driver
>   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg/CpuDxe: Add RISC-V CPU DXE
> driver.
>   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg/SmbiosDxe: RISC-V platform
> generic SMBIOS DXE driver
>   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg/Library: Add/Update/Remove
> Library instances for RISC-V platform
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdeModulePkg/DxeIplPeim:RISC-V
> platform DXEIPL.
>   [edk2-staging/RISC-V-V2 PATCH v1]: MdeModulePkg/Logo
>   [edk2-staging/RISC-V-V2 PATCH v1]: NetworkPkg
>   [edk2-staging/RISC-V-V2 PATCH v1]: BaseTools/Scripts
> 
>  BaseTools/Conf/build_rule.template |   23 +-
>  BaseTools/Conf/tools_def.template  |  108 +-
>  

Re: [edk2-devel] Mappings and StdLib

[Tim Lewis]

Andrew –

 

There is a standard call that provides this service, but I am porting over BSD 
utils to the shell and they just take a straight path and call open. So I want 
open to behave the way I expect it to. IN fact, the low level code separates 
out the “drive”  from the path already, but the current library doesn’t add in 
the mappings into the list that gets created (it is used for stdin: stdout: and 
stderr:) The thing is that the underlying Shell APIs do handle this case, but 
the mapping is stripped before it gets to that layer.

 

Tim

 

From: devel@edk2.groups.io  On Behalf Of Andrew Fish via 
Groups.Io
Sent: Wednesday, September 4, 2019 5:35 PM
To: devel@edk2.groups.io; tim.le...@insyde.com
Subject: Re: [edk2-devel] Mappings and StdLib

 

Tim,

 

I don't know about the plans with the StdLib, but I do remember a long time ago 
with the old shell there was a protocol that let you translate volume names 
(mappings) into handles and device paths. 

 

So you could write a simple library that has 2 styles of APIs:

1) Handle + FilePath in Shell mapping with Volume Name out

2) Shell file path with mapping Volume names in and Simple File System handle 
Out with the file path

   a) A device path out version of this is also useful

 

You can make the lib just error return if the Shell protocol does not exist so 
you don't make it a requirement. The caller handles that failure as the current 
working volume/directory case. 

 

Thanks,

 

Andrew Fish





On Sep 4, 2019, at 5:14 PM, Tim Lewis mailto:tim.le...@insyde.com> > wrote:

 

Following up on my last e-mail, I guess I had the wrong assumption: there 
doesn’t appear to be a way to resolve mappings within StdLib.

 

Are there any plans here?

 

Thanks,

 

Tim

 




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

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

Re: [edk2-devel] [PATCH] ArmVirtPkg/PlatformBootManagerLib: unload image on EFI_SECURITY_VIOLATION

[Laszlo Ersek]

On 09/04/19 16:16, Philippe Mathieu-Daudé wrote:
> On 9/3/19 6:38 PM, Laszlo Ersek wrote:
>> The LoadImage() boot service is a bit unusual in that it allocates
>> resources in a particular failure case; namely, it produces a valid
>> "ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to
>> happen e.g. when Secure Boot verification fails for the image, but the
>> platform policy for the particular image origin (such as "fixed media" or
>> "removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code
>> allows platform logic to selectively override the verification failure,
>> and launch the image nonetheless.
>>
>> ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION
>> for the kernel image loaded from fw_cfg -- any LoadImage() error is
>> considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any
>> other LoadImage() error, we leak the resources associated with
>> "KernelImageHandle". From a resource usage perspective,
>> EFI_SECURITY_VIOLATION must be considered "success", and rolled back.
>>
>> Implement this rollback, without breaking the proper "nesting" of error
>> handling jumps and labels.
>>
>> Cc: Ard Biesheuvel 
>> Cc: Dandan Bi 
>> Cc: Leif Lindholm 
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
>> Fixes: 23d04b58e27b382bbd3f9b16ba9adb1cb203dad5
>> Signed-off-by: Laszlo Ersek 
> 
> Reviewed-by: Philippe Mathieu-Daude 

Thank you all, pushed as commit ae9f12058d71.

Laszlo

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

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

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

[Igor Mammedov]

On Thu, 5 Sep 2019 15:08:31 +0200
Laszlo Ersek  wrote:

> On 09/04/19 11:52, Igor Mammedov wrote:
> 
> >  it could be stolen RAM + black hole like TSEG, assuming fw can live 
> > without RAM(0x3+128K) range
> >   (in this case fwcfg interface would only work for locking down the range)
> > 
> >  or
> > 
> >  we can actually have a dedicated SMRAM (like in my earlier RFC),
> >  in this case FW can use RAM(0x3+128K) when SMRAM isn't mapped into RAM 
> > address space
> >  (in this case fwcfg would be used to temporarily map SMRAM into normal RAM 
> > and unmap/lock
> >   after SMI relocation handler was initialized).
> > 
> > If possible I'd prefer a simpler TSEG like variant.  
> 
> I think TSEG-like behavior is between these two. That is, I believe we
> should have explicit open/close/lock operations. And, when the range is
> closed (meaning, closed+unlocked, or closed+locked), then the black hole
> should take effect for code that's not running in SMM.
> 
> Put differently, its like the second choice, except the range never
> appears as normal RAM. "When SMRAM isn't mapped into RAM address space",
> then the address range shows "nothing" (black hole).
I guess we at point where patch is better then words, I'll send one as reply 
here shortly.
I've just implemented subset of above (opened, closed+locked).


> Regarding "fw can live without RAM(0x3+128K) range" -- do you mean
> whether the firmware could use another RAM area for fw_cfg DMA?
> 
> If that's the question, then I wouldn't worry about it. I'd remove the
> 0x3+128K range from the memory map, so the fw_cfg stuff (or anything
> else) would never allocate memory from the range. It's much more
> concerning to me however how the SMM infrastructure would deal with a
> hole in the memory map right there.
I didn't mean fwcfg in this context, what I meant if firmware were able
to avoid using RAM(0x3+128K) range (since it becomes unusable after 
locking).
Looks like you just answered it here


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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 14/22]: RiscVPkg/opesbi: Add opensbi-HOWTO.txt

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:09PM +0800, Abner Chang wrote:
> Add opensbi-HOWTO.txt for users to build RISC-V platform with RISC-V OpenSBI 
> library.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 
> ---
>  RiscVPkg/opensbi/opensbi-HOWTO.txt | 17 +

Could you replace this patch with one that adds the stated repository
as a git submodule at the specified tag?

/
Leif

>  1 file changed, 17 insertions(+)
>  create mode 100644 RiscVPkg/opensbi/opensbi-HOWTO.txt
> 
> diff --git a/RiscVPkg/opensbi/opensbi-HOWTO.txt 
> b/RiscVPkg/opensbi/opensbi-HOWTO.txt
> new file mode 100644
> index 000..aff7a69
> --- /dev/null
> +++ b/RiscVPkg/opensbi/opensbi-HOWTO.txt
> @@ -0,0 +1,17 @@
> +
> +  Instroduction
> +
> +RISC-V Open Source Supervisor Binary Interface (OpenSBI) is an open source
> +implementation (Refer to https://github.com/riscv/opensbi) of RISC-V SBI spec
> +(Refer to https://github.com/riscv/riscv-sbi-doc), whcih is designed for the
> +platform-specific firmwares executing in RISC-V Machine mode (M-mode).
> +EDK2 RISC-V port leverage OpenSBI source files and build it into EDK2 RISC-V
> +OpenSBI library (RiscVPkg/Library/RiscVOpensbiLib) using edk2 toolchain.
> +
> +User has to get OpenSBI source code and put it under RiscVPkg/opensbi using 
> below
> +command before building RISC-V platform in EDK2 build environment.
> +
> +Current supported RISC-V OpenSBI version on EDK2 is v0.4
> +
> +  $ git clone https://github.com/riscv/opensbi
> +  $ git checkout tags/v0.4
> -- 
> 2.7.4
> 
> 
> 
> 

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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 16/22]: RiscVPkg/CpuDxe: Add RISC-V CPU DXE driver.

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:11PM +0800, Abner Chang wrote:
> The driver produces RISC-V EFI_CPU_ARCH_PROTOCOL and use RISC-V platform 
> level timer library
> 
> Due to RISC-V timer CSR is platform implementation specific, RISC-V CPU DXE 
> driver invokes platform level timer library
> to access to timer CSRs.

No comments beyond PatchCheck.py, license/SPDX and contribution agreement.

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 
> ---
>  RiscVPkg/Universal/CpuDxe/CpuDxe.c| 324 +++
>  RiscVPkg/Universal/CpuDxe/CpuDxe.h| 212 ++
>  RiscVPkg/Universal/CpuDxe/CpuDxe.inf  |  66 +++
>  RiscVPkg/Universal/CpuDxe/CpuDxe.uni  | Bin 0 -> 1564 bytes
>  RiscVPkg/Universal/CpuDxe/CpuDxeExtra.uni | Bin 0 -> 1392 bytes
>  RiscVPkg/Universal/CpuDxe/CpuMp.h | 648 
> ++
>  6 files changed, 1250 insertions(+)
>  create mode 100644 RiscVPkg/Universal/CpuDxe/CpuDxe.c
>  create mode 100644 RiscVPkg/Universal/CpuDxe/CpuDxe.h
>  create mode 100644 RiscVPkg/Universal/CpuDxe/CpuDxe.inf
>  create mode 100644 RiscVPkg/Universal/CpuDxe/CpuDxe.uni
>  create mode 100644 RiscVPkg/Universal/CpuDxe/CpuDxeExtra.uni
>  create mode 100644 RiscVPkg/Universal/CpuDxe/CpuMp.h
> 
> diff --git a/RiscVPkg/Universal/CpuDxe/CpuDxe.c 
> b/RiscVPkg/Universal/CpuDxe/CpuDxe.c
> new file mode 100644
> index 000..37d9bcf
> --- /dev/null
> +++ b/RiscVPkg/Universal/CpuDxe/CpuDxe.c
> @@ -0,0 +1,324 @@
> +/** @file
> +  RISC-V CPU DXE driver.
> +
> +  Copyright (c) 2016, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +
> +  This program and the accompanying materials are
> +  licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include "CpuDxe.h"
> +
> +//
> +// Global Variables
> +//
> +BOOLEAN   InterruptState = FALSE;
> +EFI_HANDLEmCpuHandle = NULL;
> +BOOLEAN   mIsFlushingGCD;
> +
> +EFI_CPU_ARCH_PROTOCOL  gCpu = {
> +  CpuFlushCpuDataCache,
> +  CpuEnableInterrupt,
> +  CpuDisableInterrupt,
> +  CpuGetInterruptState,
> +  CpuInit,
> +  CpuRegisterInterruptHandler,
> +  CpuGetTimerValue,
> +  CpuSetMemoryAttributes,
> +  1,  // NumberOfTimers
> +  4   // DmaBufferAlignment
> +};
> +
> +//
> +// CPU Arch Protocol Functions
> +//
> +
> +/**
> +  Flush CPU data cache. If the instruction cache is fully coherent
> +  with all DMA operations then function can just return EFI_SUCCESS.
> +
> +  @param  This  Protocol instance structure
> +  @param  Start Physical address to start flushing from.
> +  @param  LengthNumber of bytes to flush. Round up to chipset
> +granularity.
> +  @param  FlushType Specifies the type of flush operation to perform.
> +
> +  @retval EFI_SUCCESS   If cache was flushed
> +  @retval EFI_UNSUPPORTED   If flush type is not supported.
> +  @retval EFI_DEVICE_ERROR  If requested range could not be flushed.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +CpuFlushCpuDataCache (
> +  IN EFI_CPU_ARCH_PROTOCOL *This,
> +  IN EFI_PHYSICAL_ADDRESS  Start,
> +  IN UINT64Length,
> +  IN EFI_CPU_FLUSH_TYPEFlushType
> +  )
> +{
> +  return EFI_SUCCESS;
> +}
> +
> +
> +/**
> +  Enables CPU interrupts.
> +
> +  @param  This  Protocol instance structure
> +
> +  @retval EFI_SUCCESS   If interrupts were enabled in the CPU
> +  @retval EFI_DEVICE_ERROR  If interrupts could not be enabled on the CPU.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +CpuEnableInterrupt (
> +  IN EFI_CPU_ARCH_PROTOCOL  *This
> +  )
> +{
> +  EnableInterrupts ();
> +  InterruptState = TRUE;
> +  return EFI_SUCCESS;
> +}
> +
> +
> +/**
> +  Disables CPU interrupts.
> +
> +  @param  This  Protocol instance structure
> +
> +  @retval EFI_SUCCESS   If interrupts were disabled in the CPU.
> +  @retval EFI_DEVICE_ERROR  If interrupts could not be disabled on the CPU.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +CpuDisableInterrupt (
> +  IN EFI_CPU_ARCH_PROTOCOL *This
> +  )
> +{
> +  DisableInterrupts ();
> +  InterruptState = FALSE;
> +  return EFI_SUCCESS;
> +}
> +
> +
> +/**
> +  Return the state of interrupts.
> +
> +  @param  This   Protocol instance structure
> +  @param  State  Pointer to the CPU's current interrupt state
> +
> +  @retval EFI_SUCCESSIf interrupts were disabled in the CPU.
> +  @retval EFI_INVALID_PARAMETER  State is NULL.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +CpuGetInterruptState (
> +  IN 

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 18/22]: RiscVPkg/Library: Add/Update/Remove Library instances for RISC-V platform

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:13PM +0800, Abner Chang wrote:
> RiscVCpuLib: Add RISC-V CPU Library.
> - This library provides CSR assembly functions to read/write RISC-V specific 
> Control and Status registers.
> 
> RiscVDxeIplHandoffLib
> RiscVDxeIplHandoffOpenSbiLib
> - Provide DxeIpl platform implementation-specifc library for RISC-V platform. 
> Two libraries are provided in this commit,
>   * Defualt library which simply switch stack and transfer
> control to DXE core.
>   * Switch stack, privilege mode and then transfer control to
> DXE core through RISC-V opensbi.
> 
> RiscvOpensbiLib
> - EDK2 RISC-V OpenSBI library which pull in external source files under 
> RiscVPkg/opensbi to the build process.
> 
> PeiServicesTablePointerLibOpenSbi
> - Library instance of PEI Service Table for RISC-V platform based on OpenSBI.
> 
> RiscVPlatformTempMemoryInitLibNull
> - NULL lib to return temporary memory information.
> 
> RiscVDxeIplHandoffOpenSbiLib
> - This is the instance of platform level DXE IPL library based on RISC-V 
> OpenSBI implementation.
> 
> RiscVExceptionLib
> - Initial RISC-V Supervisor Mode trap handler
> 
> RiscVTimerLib
> - Add RiscVTimerLib library.
> - Due to RISC-V timer CSR is platform implementation specific, RISC-V timer 
> library invokes platform level timer library mputo access to timer CSRs.

This sounds like it should really be multiple separate patches.

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 
> ---
>  .../PeiServicesTablePointerLibOpenSbi.inf  |  45 +
>  .../PeiServicesTablePointerLibOpenSbi.uni  | Bin 0 -> 2462 bytes
>  .../PeiServicesTablePointerOpenSbi.c   | 127 +
>  RiscVPkg/Library/RiscVCpuLib/Cpu.s | 121 +
>  RiscVPkg/Library/RiscVCpuLib/RiscVCpuLib.inf   |  46 +
>  .../RiscVDxeIplHandoffLib/RiscVDxeIplHandoffLib.c  |  47 +
>  .../RiscVDxeIplHandoffLib.inf  |  39 
>  .../RiscVDxeIplHandoffOpenSbiLib.c | 108 +++
>  .../RiscVDxeIplHandoffOpenSbiLib.inf   |  39 
>  .../RiscVExceptionLib/CpuExceptionHandler.s|  94 ++
>  .../CpuExceptionHandlerDxeLib.inf  |  47 +
>  .../RiscVExceptionLib/CpuExceptionHandlerLib.c | 187 +++
>  .../RiscVExceptionLib/CpuExceptionHandlerLib.uni   | Bin 0 -> 1516 bytes
>  .../Library/RiscVOpensbiLib/RiscVOpensbiLib.inf|  65 +++
>  .../RiscVPlatformTempMemoryInitLibNull.inf |  42 +
>  .../Riscv64/TempMemInit.s  |  31 
>  .../Library/RiscVTimerLib/BaseRiscVTimerLib.inf|  40 
>  RiscVPkg/Library/RiscVTimerLib/RiscVTimerLib.c | 201 
> +
>  RiscVPkg/Library/RiscVTimerLib/RiscVTimerLib.h |  26 +++
>  19 files changed, 1305 insertions(+)
>  create mode 100644 
> RiscVPkg/Library/PeiServicesTablePointerLibOpenSbi/PeiServicesTablePointerLibOpenSbi.inf
>  create mode 100644 
> RiscVPkg/Library/PeiServicesTablePointerLibOpenSbi/PeiServicesTablePointerLibOpenSbi.uni
>  create mode 100644 
> RiscVPkg/Library/PeiServicesTablePointerLibOpenSbi/PeiServicesTablePointerOpenSbi.c
>  create mode 100644 RiscVPkg/Library/RiscVCpuLib/Cpu.s

.S, not .s

>  create mode 100644 RiscVPkg/Library/RiscVCpuLib/RiscVCpuLib.inf
>  create mode 100644 
> RiscVPkg/Library/RiscVDxeIplHandoffLib/RiscVDxeIplHandoffLib.c
>  create mode 100644 
> RiscVPkg/Library/RiscVDxeIplHandoffLib/RiscVDxeIplHandoffLib.inf
>  create mode 100644 
> RiscVPkg/Library/RiscVDxeIplHandoffOpenSbiLib/RiscVDxeIplHandoffOpenSbiLib.c
>  create mode 100644 
> RiscVPkg/Library/RiscVDxeIplHandoffOpenSbiLib/RiscVDxeIplHandoffOpenSbiLib.inf
>  create mode 100644 RiscVPkg/Library/RiscVExceptionLib/CpuExceptionHandler.s

.S, not .s

>  create mode 100644 
> RiscVPkg/Library/RiscVExceptionLib/CpuExceptionHandlerDxeLib.inf
>  create mode 100644 
> RiscVPkg/Library/RiscVExceptionLib/CpuExceptionHandlerLib.c
>  create mode 100644 
> RiscVPkg/Library/RiscVExceptionLib/CpuExceptionHandlerLib.uni
>  create mode 100644 RiscVPkg/Library/RiscVOpensbiLib/RiscVOpensbiLib.inf
>  create mode 100644 
> RiscVPkg/Library/RiscVPlatformTempMemoryInitLibNull/RiscVPlatformTempMemoryInitLibNull.inf
>  create mode 100644 
> RiscVPkg/Library/RiscVPlatformTempMemoryInitLibNull/Riscv64/TempMemInit.s

.S, not .s

>  create mode 100644 RiscVPkg/Library/RiscVTimerLib/BaseRiscVTimerLib.inf
>  create mode 100644 RiscVPkg/Library/RiscVTimerLib/RiscVTimerLib.c
>  create mode 100644 RiscVPkg/Library/RiscVTimerLib/RiscVTimerLib.h
> 
> diff --git 
> a/RiscVPkg/Library/PeiServicesTablePointerLibOpenSbi/PeiServicesTablePointerLibOpenSbi.inf
>  
> b/RiscVPkg/Library/PeiServicesTablePointerLibOpenSbi/PeiServicesTablePointerLibOpenSbi.inf
> new file mode 100644
> index 000..c49377b
> --- /dev/null
> +++ 
> b/RiscVPkg/Library/PeiServicesTablePointerLibOpenSbi/PeiServicesTablePointerLibOpenSbi.inf
> @@ -0,0 +1,45 @@
> 

Re: [edk2-devel] [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linking

[Leif Lindholm]

On Thu, Sep 05, 2019 at 10:06:56AM -0700, Ard Biesheuvel wrote:
> On Thu, 5 Sep 2019 at 08:55, Leif Lindholm  wrote:
> >
> > On Thu, Sep 05, 2019 at 07:25:39AM -0700, Ard Biesheuvel wrote:
> > > > >  [BuildOptions]
> > > > > -  GCC:*_*_*_DLINK_FLAGS = -shared -Wl,-Bsymbolic 
> > > > > -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > > > > +  GCC:*_*_*_DLINK_FLAGS = 
> > > > > -Wl,-Bsymbolic,-pie,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > > >
> > > > We already merged a fix for AARCH64 though - could/should this be
> > > > active on ARM only?
> > > >
> > > > A problem I have with this patch is that ArmVirtQemuKernel curently
> > > > doesn't boot on my qemu (with/without kvm, built with GCC5 or CLANG38,
> > > > with or without this patch):
> > > > ProcessPciHost: Config[0x401000+0x1000) Bus[0x0..0xFF]
> > > > Io[0x0+0x1)@0x3EFF Mem32[0x1000+0x2EFF)@0x0
> > > > Mem64[0x80+0x80)@0x0
> > > > MapGcdMmioSpace: failed to set memory space attributes for region
> > > > [0x401000+0x1000)
> > > >
> > > > ASSERT_EFI_ERROR (Status = Unsupported)
> > > > ASSERT [PciHostBridgeDxe]
> > > > /work/git/edk2/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(293):
> > > > !EFI_ERROR (Status)
> > > > qemu-system-arm: terminating on signal 15 from pid 4680 (killall)
> > > >
> > >
> > > Does it work with -M virt,highmem=off ?
> >
> > Ah, yes - that works fine then, also with the patch.
> >
> > Well, with that, and your explanation in the other thread:
> > Acked-by: Leif Lindholm 
> 
> Thanks. I am going to replace the last paragraph of the commit log with
> 
> Note that in this particular case, we are interested in PIE linking
> only (i.e., producing a .rela section containing dynamic relocations
> that the startup code can process directly), and not in position
> independent code generation, and by passing the -pie option to the
> linker directly using -Wl,-pie (and dropping -shared), we can coerce
> the GOLD linker into doing only the former rather than both when it
> performs its LTO code generation.
> 
> and push (unless you have any objections)

No objections.

/
Leif

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

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

Re: [edk2-devel] [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linking

[Ard Biesheuvel]

On Thu, 5 Sep 2019 at 08:55, Leif Lindholm  wrote:
>
> On Thu, Sep 05, 2019 at 07:25:39AM -0700, Ard Biesheuvel wrote:
> > > >  [BuildOptions]
> > > > -  GCC:*_*_*_DLINK_FLAGS = -shared -Wl,-Bsymbolic 
> > > > -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > > > +  GCC:*_*_*_DLINK_FLAGS = 
> > > > -Wl,-Bsymbolic,-pie,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > >
> > > We already merged a fix for AARCH64 though - could/should this be
> > > active on ARM only?
> > >
> > > A problem I have with this patch is that ArmVirtQemuKernel curently
> > > doesn't boot on my qemu (with/without kvm, built with GCC5 or CLANG38,
> > > with or without this patch):
> > > ProcessPciHost: Config[0x401000+0x1000) Bus[0x0..0xFF]
> > > Io[0x0+0x1)@0x3EFF Mem32[0x1000+0x2EFF)@0x0
> > > Mem64[0x80+0x80)@0x0
> > > MapGcdMmioSpace: failed to set memory space attributes for region
> > > [0x401000+0x1000)
> > >
> > > ASSERT_EFI_ERROR (Status = Unsupported)
> > > ASSERT [PciHostBridgeDxe]
> > > /work/git/edk2/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(293):
> > > !EFI_ERROR (Status)
> > > qemu-system-arm: terminating on signal 15 from pid 4680 (killall)
> > >
> >
> > Does it work with -M virt,highmem=off ?
>
> Ah, yes - that works fine then, also with the patch.
>
> Well, with that, and your explanation in the other thread:
> Acked-by: Leif Lindholm 

Thanks. I am going to replace the last paragraph of the commit log with

Note that in this particular case, we are interested in PIE linking
only (i.e., producing a .rela section containing dynamic relocations
that the startup code can process directly), and not in position
independent code generation, and by passing the -pie option to the
linker directly using -Wl,-pie (and dropping -shared), we can coerce
the GOLD linker into doing only the former rather than both when it
performs its LTO code generation.

and push (unless you have any objections)

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

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

Re: [edk2-devel] [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linking

[Ard Biesheuvel]

On Thu, 5 Sep 2019 at 10:16, Leif Lindholm  wrote:
>
> On Thu, Sep 05, 2019 at 10:06:56AM -0700, Ard Biesheuvel wrote:
> > On Thu, 5 Sep 2019 at 08:55, Leif Lindholm  wrote:
> > >
> > > On Thu, Sep 05, 2019 at 07:25:39AM -0700, Ard Biesheuvel wrote:
> > > > > >  [BuildOptions]
> > > > > > -  GCC:*_*_*_DLINK_FLAGS = -shared -Wl,-Bsymbolic 
> > > > > > -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > > > > > +  GCC:*_*_*_DLINK_FLAGS = 
> > > > > > -Wl,-Bsymbolic,-pie,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> > > > >
> > > > > We already merged a fix for AARCH64 though - could/should this be
> > > > > active on ARM only?
> > > > >
> > > > > A problem I have with this patch is that ArmVirtQemuKernel curently
> > > > > doesn't boot on my qemu (with/without kvm, built with GCC5 or CLANG38,
> > > > > with or without this patch):
> > > > > ProcessPciHost: Config[0x401000+0x1000) Bus[0x0..0xFF]
> > > > > Io[0x0+0x1)@0x3EFF Mem32[0x1000+0x2EFF)@0x0
> > > > > Mem64[0x80+0x80)@0x0
> > > > > MapGcdMmioSpace: failed to set memory space attributes for region
> > > > > [0x401000+0x1000)
> > > > >
> > > > > ASSERT_EFI_ERROR (Status = Unsupported)
> > > > > ASSERT [PciHostBridgeDxe]
> > > > > /work/git/edk2/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c(293):
> > > > > !EFI_ERROR (Status)
> > > > > qemu-system-arm: terminating on signal 15 from pid 4680 (killall)
> > > > >
> > > >
> > > > Does it work with -M virt,highmem=off ?
> > >
> > > Ah, yes - that works fine then, also with the patch.
> > >
> > > Well, with that, and your explanation in the other thread:
> > > Acked-by: Leif Lindholm 
> >
> > Thanks. I am going to replace the last paragraph of the commit log with
> >
> > Note that in this particular case, we are interested in PIE linking
> > only (i.e., producing a .rela section containing dynamic relocations
> > that the startup code can process directly), and not in position
> > independent code generation, and by passing the -pie option to the
> > linker directly using -Wl,-pie (and dropping -shared), we can coerce
> > the GOLD linker into doing only the former rather than both when it
> > performs its LTO code generation.
> >
> > and push (unless you have any objections)
>
> No objections.
>

Thanks

Pushed as 8a1305a11f3b..04d9d89b7dd4

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

View/Reply Online (#46927): https://edk2.groups.io/g/devel/message/46927
Mute This Topic: https://groups.io/mt/33144570/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/3] EmbeddedPkg: Unload image on EFI_SECURITY_VIOLATION

[Laszlo Ersek]

On 09/04/19 10:25, Dandan Bi wrote:
> For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> the Image was loaded and an ImageHandle was created with a valid
> EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
> This follows UEFI Spec.
> 
> But if the caller of LoadImage() doesn't have the option to defer
> the execution of an image, we can not treat EFI_SECURITY_VIOLATION
> like any other LoadImage() error, we should unload image for the
> EFI_SECURITY_VIOLATION to avoid resource leak.
> 
> This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
> for the callers in EmbeddedPkg which don't have the policy to defer the
> execution of the image.
> 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Laszlo Ersek 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> Signed-off-by: Dandan Bi 
> ---
>  .../AndroidFastboot/Arm/BootAndroidBootImg.c |  9 +
>  .../Library/AndroidBootImgLib/AndroidBootImgLib.c| 12 
>  2 files changed, 21 insertions(+)
> 
> diff --git a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c 
> b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
> index 591afbe7cc..9fa28e3390 100644
> --- a/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
> +++ b/EmbeddedPkg/Application/AndroidFastboot/Arm/BootAndroidBootImg.c
> @@ -71,10 +71,19 @@ StartEfiApplication (
>  
>// Load the image from the device path with Boot Services function
>Status = gBS->LoadImage (TRUE, ParentImageHandle, DevicePath, NULL, 0,
>);
>if (EFI_ERROR (Status)) {
> +//
> +// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +// If the caller doesn't have the option to defer the execution of an 
> image, we should
> +// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +//
> +if (Status == EFI_SECURITY_VIOLATION) {
> +  gBS->UnloadImage (ImageHandle);
> +}
>  return Status;
>}
>  
>// Passed LoadOptions to the EFI Application
>if (LoadOptionsSize != 0) {

The return status exists here originally, so this change is strictly an
improvement.

But:

> diff --git a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c 
> b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
> index d9e7aa7d2b..2e9e74db1d 100644
> --- a/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
> +++ b/EmbeddedPkg/Library/AndroidBootImgLib/AndroidBootImgLib.c
> @@ -439,10 +439,22 @@ AndroidBootImgBoot (
> + KernelSize;
>  
>Status = gBS->LoadImage (TRUE, gImageHandle,
> (EFI_DEVICE_PATH *),
> (VOID*)(UINTN)Kernel, KernelSize, );
> +  if (EFI_ERROR (Status)) {
> +//
> +// With EFI_SECURITY_VIOLATION retval, the Image was loaded and an 
> ImageHandle was created
> +// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be 
> started right now.
> +// If the caller doesn't have the option to defer the execution of an 
> image, we should
> +// unload image for the EFI_SECURITY_VIOLATION to avoid resource leak.
> +//
> +if (Status == EFI_SECURITY_VIOLATION) {
> +  gBS->UnloadImage (ImageHandle);
> +}
> +return Status;
> +  }
>  
>// Set kernel arguments
>Status = gBS->HandleProtocol (ImageHandle, ,
>  (VOID **) );
>ImageInfo->LoadOptions = NewKernelArg;
> 

The return status is introduced afresh here. And, at this point in the
function, we have allocated at least "NewKernelArg". (And probably more
resources.)

If we take an early return here, then we're going to leak NewKernelArg.

Hm... Hmm. Well, even without this patch, if the loaded and started
image returns, then the AndroidBootImgBoot() function leaks
"NewKernelArg" anyway.

Sigh. I guess the error handling in this function should be cleaned up
first, to solve the present issue cleanly. On the other hand, I'm not
sure how much this function is used at all. And I guess the patch
doesn't make things worse than they are.

Acked-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 12/22]: MdePkg/BaseLib: BaseLib for RISC-V RV64 Processor.

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:07PM +0800, Abner Chang wrote:
> Add RISC-V processor binding and RISC-V processor specific definitions and 
> macros.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 
> ---
>  MdePkg/Library/BaseLib/BaseLib.inf |  18 +-
>  MdePkg/Library/BaseLib/RiscV64/CpuBreakpoint.c |  33 ++
>  MdePkg/Library/BaseLib/RiscV64/CpuPause.c  |  35 ++
>  MdePkg/Library/BaseLib/RiscV64/DisableInterrupts.c |  33 ++
>  MdePkg/Library/BaseLib/RiscV64/EnableInterrupts.c  |  33 ++
>  MdePkg/Library/BaseLib/RiscV64/FlushCache.S|  28 +
>  MdePkg/Library/BaseLib/RiscV64/GetInterruptState.c |  43 ++
>  .../Library/BaseLib/RiscV64/InternalSwitchStack.c  |  61 +++
>  MdePkg/Library/BaseLib/RiscV64/LongJump.c  |  38 ++
>  .../Library/BaseLib/RiscV64/RiscVCpuBreakpoint.S   |  20 +
>  MdePkg/Library/BaseLib/RiscV64/RiscVCpuPause.S |  20 +
>  MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S|  33 ++
>  .../Library/BaseLib/RiscV64/RiscVSetJumpLongJump.S |  61 +++
>  MdePkg/Library/BaseLib/RiscV64/Unaligned.c | 270 ++
>  MdePkg/Library/BaseLib/RiscV64/riscv_asm.h | 194 +++
>  MdePkg/Library/BaseLib/RiscV64/riscv_encoding.h| 574 
> +
>  MdePkg/Library/BaseLib/RiscV64/sbi_const.h |  53 ++
>  17 files changed, 1546 insertions(+), 1 deletion(-)
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/CpuBreakpoint.c
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/CpuPause.c
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/DisableInterrupts.c
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/EnableInterrupts.c
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/FlushCache.S
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/GetInterruptState.c
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/InternalSwitchStack.c
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/LongJump.c
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/RiscVCpuBreakpoint.S
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/RiscVCpuPause.S
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/RiscVSetJumpLongJump.S
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/Unaligned.c
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/riscv_asm.h
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/riscv_encoding.h
>  create mode 100644 MdePkg/Library/BaseLib/RiscV64/sbi_const.h
> 
> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
> b/MdePkg/Library/BaseLib/BaseLib.inf
> index 3586beb..28d5795 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -4,6 +4,7 @@
>  #  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
>  #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
>  #  Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
> +#  Copyright (c) 2016, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -20,7 +21,7 @@
>LIBRARY_CLASS  = BaseLib
>  
>  #
> -#  VALID_ARCHITECTURES   = IA32 X64 EBC ARM AARCH64
> +#  VALID_ARCHITECTURES   = IA32 X64 EBC ARM AARCH64 RISCV64
>  #
>  
>  [Sources]
> @@ -381,6 +382,21 @@

Ah, right. I just noticed these patches don't follow the patch
generation guidelines from
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers

If you run BaseTools/Scripts/SetupGit.py, it will set up most of the
important defaults for your clone (needs to be done once per
repository). This greatly improves the reviewability of patches.

/
Leif

>AArch64/CpuBreakpoint.asm | MSFT
>AArch64/SpeculationBarrier.asm| MSFT
>  
> +[Sources.RISCV64]
> +  Math64.c
> +  RiscV64/Unaligned.c
> +  RiscV64/InternalSwitchStack.c
> +  RiscV64/CpuBreakpoint.c
> +  RiscV64/GetInterruptState.c
> +  RiscV64/DisableInterrupts.c
> +  RiscV64/EnableInterrupts.c
> +  RiscV64/CpuPause.c
> +  RiscV64/RiscVSetJumpLongJump.S| GCC
> +  RiscV64/RiscVCpuBreakpoint.S  | GCC
> +  RiscV64/RiscVCpuPause.S   | GCC
> +  RiscV64/RiscVInterrupt.S  | GCC
> +  RiscV64/FlushCache.S  | GCC
> +
>  [Packages]
>MdePkg/MdePkg.dec
>  
> diff --git a/MdePkg/Library/BaseLib/RiscV64/CpuBreakpoint.c 
> b/MdePkg/Library/BaseLib/RiscV64/CpuBreakpoint.c
> new file mode 100644
> index 000..763b813
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/RiscV64/CpuBreakpoint.c
> @@ -0,0 +1,33 @@
> +/** @file
> +  CPU breakpoint for RISC-V
> +
> +  Copyright (c) 2016, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution. The full text of 

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 15/22]: RiscVPkg/RealTimeClockRuntimeDxe: Add RISC-V RTC Runtime Driver

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:10PM +0800, Abner Chang wrote:
> This is the abstract driver which incorporate with platform level RTC library 
> (RealTimeClockLib) to provide Real Time Clock Architecture Protocol.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 
> ---
>  .../RealTimeClockRuntimeDxe/RealTimeClock.c| 157 
> +
>  .../RealTimeClockRuntimeDxe.inf|  44 ++
>  2 files changed, 201 insertions(+)
>  create mode 100644 RiscVPkg/Universal/RealTimeClockRuntimeDxe/RealTimeClock.c
>  create mode 100644 
> RiscVPkg/Universal/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf

Why do we have this separate implementation?
It looks pretty much equivalent to
EmbeddedPkg/RealTimeClockRuntimeDxe/, but with the timezone handling
ripped out.

/
Leif


> diff --git a/RiscVPkg/Universal/RealTimeClockRuntimeDxe/RealTimeClock.c 
> b/RiscVPkg/Universal/RealTimeClockRuntimeDxe/RealTimeClock.c
> new file mode 100644
> index 000..c3d04e7
> --- /dev/null
> +++ b/RiscVPkg/Universal/RealTimeClockRuntimeDxe/RealTimeClock.c
> @@ -0,0 +1,157 @@
> +/** @file
> +  Implementation of EFI RealTimeClock runtime services via platform RTC Lib. 
> +
> +  Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights 
> reserved. 
> +  Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +EFI_HANDLE  mHandle = NULL;
> +
> +/**
> +  Returns the current time and date information, and the time-keeping 
> capabilities
> +  of the hardware platform.
> +
> +  @param  Time  A pointer to storage to receive a snapshot 
> of the current time.
> +  @param  Capabilities  An optional pointer to a buffer to receive 
> the real time clock
> +device's capabilities.
> +
> +  @retval EFI_SUCCESS   The operation completed successfully.
> +  @retval EFI_INVALID_PARAMETER Time is NULL.
> +  @retval EFI_DEVICE_ERROR  The time could not be retrieved due to 
> hardware error.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +GetTime (
> +  OUT EFI_TIME*Time,
> +  OUT  EFI_TIME_CAPABILITIES  *Capabilities
> +  )
> +{
> +  return LibGetTime (Time, Capabilities);
> +}
> +
> +
> +
> +/**
> +  Sets the current local time and date information.
> +
> +  @param  Time  A pointer to the current time.
> +
> +  @retval EFI_SUCCESS   The operation completed successfully.
> +  @retval EFI_INVALID_PARAMETER A time field is out of range.
> +  @retval EFI_DEVICE_ERROR  The time could not be set due due to 
> hardware error.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +SetTime (
> +  IN EFI_TIME*Time
> +  )
> +{
> +  return LibSetTime (Time);
> +}
> +
> +
> +/**
> +  Returns the current wakeup alarm clock setting.
> +
> +  @param  Enabled   Indicates if the alarm is currently enabled 
> or disabled.
> +  @param  Pending   Indicates if the alarm signal is pending and 
> requires acknowledgement.
> +  @param  Time  The current alarm setting.
> +
> +  @retval EFI_SUCCESS   The alarm settings were returned.
> +  @retval EFI_INVALID_PARAMETER Any parameter is NULL.
> +  @retval EFI_DEVICE_ERROR  The wakeup time could not be retrieved due 
> to a hardware error.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +GetWakeupTime (
> +  OUT BOOLEAN *Enabled,
> +  OUT BOOLEAN *Pending,
> +  OUT EFI_TIME*Time
> +  )
> +{
> +  return LibGetWakeupTime (Enabled, Pending, Time);
> +}
> +
> +
> +/**
> +  Sets the system wakeup alarm clock time.
> +
> +  @param  Enabled   Enable or disable the wakeup alarm.
> +  @param  Time  If Enable is TRUE, the time to set the 
> wakeup alarm for.
> +
> +  @retval EFI_SUCCESS   If Enable is TRUE, then the wakeup alarm was 
> enabled. If
> +Enable is FALSE, then the wakeup alarm was 
> disabled.
> +  @retval EFI_INVALID_PARAMETER A time field is out of range.
> +  @retval EFI_DEVICE_ERROR  The wakeup time could not be set due to a 
> hardware error.
> +  @retval EFI_UNSUPPORTED   A wakeup timer is not supported on this 
> platform.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +SetWakeupTime (
> +  IN BOOLEAN  Enabled,
> +  OUT EFI_TIME*Time
> +  )
> +{
> +  return LibSetWakeupTime (Enabled, Time);
> +}
> +
> +
> +
> +/**
> +  This is the declaration of an EFI image entry point. This 

Re: [edk2-devel] [PATCH] ShellPkg/ShellPkg.dsc AARCH64: enable stack protector

[Ard Biesheuvel]

On Wed, 4 Sep 2019 at 19:20, Gao, Zhichao  wrote:
>
> Acked-by: Zhichao Gao 
>

Thanks

Pushed as 04d9d89b7dd4..23908d0f5cc6

> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Leif Lindholm
> > Sent: Thursday, September 5, 2019 12:38 AM
> > To: Ard Biesheuvel 
> > Cc: devel@edk2.groups.io; Carsey, Jaben ; Ni, Ray
> > ; Gao, Zhichao ; Gao, Liming
> > 
> > Subject: Re: [edk2-devel] [PATCH] ShellPkg/ShellPkg.dsc AARCH64: enable
> > stack protector
> >
> > On Wed, Sep 04, 2019 at 09:34:34AM -0700, Ard Biesheuvel wrote:
> > > Incorporate the stack protector library into the AARCH64 build of the
> > > Shell binaries as a NULL library resolution, to avoid build errors
> > > when the compiler injects stack integrity checks.
> > >
> > > Signed-off-by: Ard Biesheuvel 
> >
> > Surprised we hadn't triggered this earlier.
> > Reviewed-by: Leif Lindholm 
> >
> >
> > > ---
> > >  ShellPkg/ShellPkg.dsc | 5 +
> > >  1 file changed, 1 insertion(+), 4 deletions(-)
> > >
> > > diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc index
> > > b2065dc028d8..91493400cab7 100644
> > > --- a/ShellPkg/ShellPkg.dsc
> > > +++ b/ShellPkg/ShellPkg.dsc
> > > @@ -58,7 +58,7 @@
> > >DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
> > >
> > >
> > ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseR
> > ep
> > > ortStatusCodeLibNull.inf
> > >
> > > -[LibraryClasses.ARM]
> > > +[LibraryClasses.ARM,LibraryClasses.AARCH64]
> > >#
> > ># It is not possible to prevent the ARM compiler for generic intrinsic
> > functions.
> > ># This library provides the instrinsic functions generate by a given
> > compiler.
> > > @@ -69,9 +69,6 @@
> > ># Add support for GCC stack protector
> > >NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> > >
> > > -[LibraryClasses.AARCH64]
> > > -  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > > -
> > >  [PcdsFixedAtBuild]
> > >gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
> > >gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|16000
> > > --
> > > 2.17.1
> > >
> >
> > 
>

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

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

Re: [edk2-devel] Mappings and StdLib

[Tim Lewis]

Ok, now I found my answer. DevShell library class must be included with StdLib 
in order to correctly process shell-style input parameters. Without it, it 
falls back on DevConsole

 

Thanks,

Tim

 

From: devel@edk2.groups.io  On Behalf Of Tim Lewis
Sent: Thursday, September 5, 2019 10:25 AM
To: devel@edk2.groups.io; af...@apple.com
Subject: Re: [edk2-devel] Mappings and StdLib

 

Andrew –

 

There is a standard call that provides this service, but I am porting over BSD 
utils to the shell and they just take a straight path and call open. So I want 
open to behave the way I expect it to. IN fact, the low level code separates 
out the “drive”  from the path already, but the current library doesn’t add in 
the mappings into the list that gets created (it is used for stdin: stdout: and 
stderr:) The thing is that the underlying Shell APIs do handle this case, but 
the mapping is stripped before it gets to that layer.

 

Tim

 

From: devel@edk2.groups.io   mailto:devel@edk2.groups.io> > On Behalf Of Andrew Fish via Groups.Io
Sent: Wednesday, September 4, 2019 5:35 PM
To: devel@edk2.groups.io  ; tim.le...@insyde.com 
 
Subject: Re: [edk2-devel] Mappings and StdLib

 

Tim,

 

I don't know about the plans with the StdLib, but I do remember a long time ago 
with the old shell there was a protocol that let you translate volume names 
(mappings) into handles and device paths. 

 

So you could write a simple library that has 2 styles of APIs:

1) Handle + FilePath in Shell mapping with Volume Name out

2) Shell file path with mapping Volume names in and Simple File System handle 
Out with the file path

   a) A device path out version of this is also useful

 

You can make the lib just error return if the Shell protocol does not exist so 
you don't make it a requirement. The caller handles that failure as the current 
working volume/directory case. 

 

Thanks,

 

Andrew Fish

 

On Sep 4, 2019, at 5:14 PM, Tim Lewis mailto:tim.le...@insyde.com> > wrote:

 

Following up on my last e-mail, I guess I had the wrong assumption: there 
doesn’t appear to be a way to resolve mappings within StdLib.

 

Are there any plans here?

 

Thanks,

 

Tim

 




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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 20/22]: MdeModulePkg/Logo

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:15PM +0800, Abner Chang wrote:
> Add RISCV64 Arch.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0

If you drop that contribution agreement:
Reviewed-by: Leif Lindholm 

> Signed-off-by: Abner Chang 
> ---
>  MdeModulePkg/Logo/Logo.inf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Logo/Logo.inf b/MdeModulePkg/Logo/Logo.inf
> index 0182025..243748c 100644
> --- a/MdeModulePkg/Logo/Logo.inf
> +++ b/MdeModulePkg/Logo/Logo.inf
> @@ -19,7 +19,7 @@
>  #
>  # The following information is for reference only and not required by the 
> build tools.
>  #
> -#  VALID_ARCHITECTURES   = IA32 X64 EBC ARM AARCH64
> +#  VALID_ARCHITECTURES   = IA32 X64 EBC ARM AARCH64 RISCV64
>  #
>  
>  [Binaries]
> -- 
> 2.7.4
> 
> 
> 
> 

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

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

[edk2-devel] [PATCH edk2-CCSS 3/3] must comment: add rule for documenting spurious variable assignments

[Laszlo Ersek]

Problem statement from Ard:

> Sometimes, the GCC compiler warns about variables potentially being used
> without having been initialized, while visual inspection reveals that
> this is impossible. In such cases, we need to initialize such a variable
> to an arbitrary value only to avoid breaking the build, given our policy
> to treat warnings as errors.

In such cases we generally use

  LocalIntegerVariable = 0;

and

  LocalPointerVariable = NULL;

which takes care of the incorrect warning. However, it also makes the
human analysis of any subsequent logic harder, because it suggests that
assigning that specific zero or NULL value to the local variable is
*required* by the subsequent logic.

In order to highlight such assignments, whose sole purpose is to suppress
invalid "use before init" warnings from compilers or static analysis
tools, we should mandate comments such as:

  //
  // set LocalVariable to suppress incorrect compiler/analyzer warnings
  //
  LocalVariable = 0;

(Magic values such as 0xDEADBEEF, which would obviate the necessity of
explicit comments, have been considered, and rejected for stylistic
reasons.)

Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=607
Signed-off-by: Laszlo Ersek 
---
 6_documenting_software/64_what_you_must_comment.md | 39 
 README.md  |  1 +
 2 files changed, 40 insertions(+)

diff --git a/6_documenting_software/64_what_you_must_comment.md 
b/6_documenting_software/64_what_you_must_comment.md
index abb2114bf5bc..9e51c2e45816 100644
--- a/6_documenting_software/64_what_you_must_comment.md
+++ b/6_documenting_software/64_what_you_must_comment.md
@@ -58,3 +58,42 @@ instance differs.
 
 When possible, you should also list the requirements that are satisfied by the
 code.
+
+### 6.4.6 Comment spurious variable assignments.
+
+A compiler or static code analyzer may warn that an object with automatic or
+allocated storage duration is read without having been initialized, while
+visual inspection reveals that this is impossible.
+
+In order to suppress such a warning (which is emitted due to invalid data flow
+analysis), developers explicitly assign the affected object the value to which
+the same object would be initialized automatically, had the object static
+storage duration, and no initializer. (The value assigned could be arbitrary;
+the above-mentioned value is chosen for stylistic reasons.) For example:
+
+```c
+UINTN LocalIntegerVariable;
+VOID  *LocalPointerVariable;
+
+LocalIntegerVariable = 0;
+LocalPointerVariable = NULL;
+```
+
+This kind of assignment is difficult to distinguish from assignments where the
+initial value of an object is meaningful, and is consumed by other code without
+an intervening assignment. Therefore, each such assignment must be documented,
+as follows:
+
+```c
+UINTN LocalIntegerVariable;
+VOID  *LocalPointerVariable;
+
+//
+// set LocalIntegerVariable to suppress incorrect compiler/analyzer warnings
+//
+LocalIntegerVariable = 0;
+//
+// set LocalPointerVariable to suppress incorrect compiler/analyzer warnings
+//
+LocalPointerVariable = NULL;
+```
diff --git a/README.md b/README.md
index e26133540368..0648819f0d3a 100644
--- a/README.md
+++ b/README.md
@@ -113,3 +113,4 @@ Copyright (c) 2006-2017, Intel Corporation. All rights 
reserved.
 | 2.2  | Convert to Gitbook

| June 2017  |
 |  | [#425](https://bugzilla.tianocore.org/show_bug.cgi?id=425) [CCS] 
clarify line breaking and indentation requirements for multi-line function 
calls ||
 |  | [#1656](https://bugzilla.tianocore.org/show_bug.cgi?id=1656) 
Update all Wiki pages for the BSD+Patent license change with SPDX identifiers   
 ||
+|  | [#607](https://bugzilla.tianocore.org/show_bug.cgi?id=607) 
Document code comment requirements for spurious variable assignments
   ||
-- 
2.19.1.3.g30247aa5d201


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

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

[edk2-devel] [PATCH edk2-CCSS 0/3] Coding Standards: add rule for documenting spurious variable assignments

[Laszlo Ersek]

Repo:   https://github.com/lersek/edk2-CCodingStandardsSpecification.git
Branch: spurious_assign_bz_607

HTML-rendered views of the modified pages:
- 
https://lersek.gitbooks.io/laszlo-s-fork-of-the-edk-ii-c-coding-standards-sp/content/v/spurious_assign_bz_607
- 
https://lersek.gitbooks.io/laszlo-s-fork-of-the-edk-ii-c-coding-standards-sp/content/v/spurious_assign_bz_607/6_documenting_software/62_comments.html
- 
https://lersek.gitbooks.io/laszlo-s-fork-of-the-edk-ii-c-coding-standards-sp/content/v/spurious_assign_bz_607/6_documenting_software/64_what_you_must_comment.html

The first two patches are cleanups for things that popped up in the
discussion in .

The third patch is the one fixing the BZ.

Thanks,
Laszlo

Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Rebecca Cran 

Laszlo Ersek (3):
  comments: remove "Horror Vacui" rule
  comments: restrict and clarify applicability of "/*" comments
  must comment: add rule for documenting spurious variable assignments

 6_documenting_software/62_comments.md  | 20 +-
 6_documenting_software/64_what_you_must_comment.md | 39 
 README.md  |  1 +
 3 files changed, 42 insertions(+), 18 deletions(-)

-- 
2.19.1.3.g30247aa5d201


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

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

[edk2-devel] [PATCH edk2-CCSS 2/3] comments: restrict and clarify applicability of "/*" comments

[Laszlo Ersek]

Section "6.2 Comments" seems to permit "/*" for multi-line comments in
general. That's incorrect; "/*" comments are permitted only for a subset
of multi-line comments (namely Doxygen-style file and function header
comment blocks). Update the rule accordingly.

Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=607
Signed-off-by: Laszlo Ersek 
---
 6_documenting_software/62_comments.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/6_documenting_software/62_comments.md 
b/6_documenting_software/62_comments.md
index ae04e008a1eb..5feb5cee2055 100644
--- a/6_documenting_software/62_comments.md
+++ b/6_documenting_software/62_comments.md
@@ -54,7 +54,7 @@ minimal familiarity with the code. Clarity is important, but 
one should also
 strive for terse and concise comments. One should be able to see both the
 comment, and the code being commented on, on the same screen.
 
-### 6.2.1 Only use C style, "/*", comments for multi-line comments and on the 
same line as pre-processor directives.
+### 6.2.1 Only use C style, "/*", comments on the same line as pre-processor 
directives, and in Doxygen-style file and function header comment blocks.
 
 Compile can vary in their support for use of `//` in preprocessor directives
 (e.g. `#define`). Note that the mixing of `/* ... */` and `//` is not handled
-- 
2.19.1.3.g30247aa5d201



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

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

[edk2-devel] [PATCH edk2-CCSS 1/3] comments: remove "Horror Vacui" rule

[Laszlo Ersek]

The rule about avoiding comments in C code where the opening comment
characters are alone on a line conflicts with everyday edk2 practice --
we use comments like

  //
  // If the total number of lines in the popup is zero, then ASSERT()
  //

all the time. This comment style is actively enforced by reviewers and
maintainers. Remove the rule in order for the CCS to match reality.

Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=607
Signed-off-by: Laszlo Ersek 
---
 6_documenting_software/62_comments.md | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/6_documenting_software/62_comments.md 
b/6_documenting_software/62_comments.md
index 208ce346f607..ae04e008a1eb 100644
--- a/6_documenting_software/62_comments.md
+++ b/6_documenting_software/62_comments.md
@@ -66,23 +66,7 @@ not behave the same.
 Banners can be useful to highlight logical divisions within a file; such as
 before vital sections. This type of usage should be minimized.
 
-### 6.2.3 Avoid comments where the opening comment characters are alone on a 
line.
-
-```
-/*
- * VIOLATION: Horror Vacui
-*/
-```
-
-or
-
-```c
-//
-// VIOLATION: Horror Vacui
-//
-```
-
-### 6.2.4 Do not include jokes or obtuse references in comments.
+### 6.2.3 Do not include jokes or obtuse references in comments.
 
 ```
 "Out of cheese error! Redo from start."
-- 
2.19.1.3.g30247aa5d201



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

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

Re: [edk2-devel] [patch 2/3] MdeModulePkg: Unload image on EFI_SECURITY_VIOLATION

[Laszlo Ersek]

just a meta comment:

On 09/05/19 08:23, Dandan Bi wrote:
>> -Original Message-
>> From: Wu, Hao A
>> Sent: Thursday, September 5, 2019 1:38 PM
>> To: Bi, Dandan ; devel@edk2.groups.io
>> Cc: Wang, Jian J ; Ni, Ray ; Gao,
>> Liming ; Laszlo Ersek 
>> Subject: RE: [patch 2/3] MdeModulePkg: Unload image on
>> EFI_SECURITY_VIOLATION
>>
>>> -Original Message-
>>> From: Bi, Dandan
>>> Sent: Wednesday, September 04, 2019 4:26 PM
>>> To: devel@edk2.groups.io
>>> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Gao, Liming; Laszlo Ersek
>>> Subject: [patch 2/3] MdeModulePkg: Unload image on
>>> EFI_SECURITY_VIOLATION

>>>  MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c  |  9
>>> +
>>>  MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c |  9
>>> +
>>>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c  |  9
>> +
>>>  .../Library/UefiBootManagerLib/BmLoadOption.c | 11 ++-
>>>  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c  | 11
>>> ++-
>>>  .../PlatformDriOverrideDxe/PlatDriOverrideLib.c   | 11 ++-

>> Also, since the patch is touching multiple features (PCI, Capsule, BM and
>> driver override), I would suggest to break this patch into multiple ones so
>> that it will be more clear to evaluate the impact for each change.
>>
> I will separate the patch into module level and send the new patch series.

Yes, do that please, especially because now we have fine-grained
maintainership assignments in "Maintainers.txt" (not for all packages,
but certainly for MdeModulePkg), and a python script to assign reviewers.

Let's say, you have three patches in the series, on your topic branch.
You can do:

$ python BaseTools/Scripts/GetMaintainer.py HEAD~2
$ python BaseTools/Scripts/GetMaintainer.py HEAD~1
$ python BaseTools/Scripts/GetMaintainer.py HEAD

Each invocation will give you the list of people that you should CC on
that particular patch.

You can also invoke the script with the "-l" option, to get reviewers
for a specific file:

$ python BaseTools/Scripts/GetMaintainer.py \
-l MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c

$ python BaseTools/Scripts/GetMaintainer.py \
-l MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c

Other than this, I'll skip the review of patches #2 and #3 in this
series; I've got too many things to do, and I'm not a designated
reviewer / maintainer on either module being modified. I hope that's
acceptable.

Thanks,
Laszlo

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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 13/22]: MdePkg/Include: Update SmBios header file.

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:08PM +0800, Abner Chang wrote:
> Update SmBios header file to conform with SMBIOS v3.3.0.
> The major update is to add definitions of SMBIOS Type 44h record.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 

This would be really useful to get straight into edk2 - could you
submit it straight for inclusion in edk2 master? We can then
cherry-pick that back to the edk2-staging branch.

/
Leif

> ---
>  MdePkg/Include/IndustryStandard/SmBios.h | 74 
> +++-
>  1 file changed, 72 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
> b/MdePkg/Include/IndustryStandard/SmBios.h
> index f3b6f18..a744d06 100644
> --- a/MdePkg/Include/IndustryStandard/SmBios.h
> +++ b/MdePkg/Include/IndustryStandard/SmBios.h
> @@ -3,6 +3,7 @@
>  
>  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>  (C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP
> +(C) Copyright 2015 - 2019 Hewlett Packard Enterprise Development LP
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
> @@ -46,7 +47,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #define SMBIOS_3_0_TABLE_MAX_LENGTH 0x
>  
>  //
> -// SMBIOS type macros which is according to SMBIOS 2.7 specification.
> +// SMBIOS type macros which is according to SMBIOS 3.3.0 specification.
>  //
>  #define SMBIOS_TYPE_BIOS_INFORMATION 0
>  #define SMBIOS_TYPE_SYSTEM_INFORMATION   1
> @@ -92,6 +93,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #define SMBIOS_TYPE_ONBOARD_DEVICES_EXTENDED_INFORMATION 41
>  #define SMBIOS_TYPE_MANAGEMENT_CONTROLLER_HOST_INTERFACE 42
>  #define SMBIOS_TYPE_TPM_DEVICE   43
> +#define SMBIOS_TYPE_PROCESSOR_ADDITIONAL_INFORMATION 44
>  
>  ///
>  /// Inactive type is added from SMBIOS 2.2. Reference SMBIOS 2.6, chapter 
> 3.3.43.
> @@ -727,7 +729,10 @@ typedef enum {
>ProcessorFamilyMII   = 0x012E,
>ProcessorFamilyWinChip   = 0x0140,
>ProcessorFamilyDSP   = 0x015E,
> -  ProcessorFamilyVideoProcessor= 0x01F4
> +  ProcessorFamilyVideoProcessor= 0x01F4,
> +  ProcessorFamilyRiscvRV32 = 0x0200,  ///< SMBIOS spec 3.3.0 
> added
> +  ProcessorFamilyRiscVRV64 = 0x0201,  ///< SMBIOS spec 3.3.0 
> added
> +  ProcessorFamilyRiscVRV128= 0x0202   ///< SMBIOS spec 3.3.0 
> added
>  } PROCESSOR_FAMILY2_DATA;
>  
>  ///
> @@ -857,6 +862,19 @@ typedef struct {
>  } PROCESSOR_FEATURE_FLAGS;
>  
>  typedef struct {
> +  UINT32  ProcessorReserved1 :1;
> +  UINT32  ProcessorUnknown   :1;
> +  UINT32  Processor64BitCapble   :1;
> +  UINT32  ProcessorMultiCore :1;
> +  UINT32  ProcessorHardwareThread:1;
> +  UINT32  ProcessorExecuteProtection :1;
> +  UINT32  ProcessorEnhancedVirtulization :1;
> +  UINT32  ProcessorPowerPerformanceCtrl  :1;
> +  UINT32  Processor128bitCapble  :1;
> +  UINT32  ProcessorReserved2 :7;
> +} PROCESSOR_CHARACTERISTIC_FLAGS;
> +
> +typedef struct {
>PROCESSOR_SIGNATURE Signature;
>PROCESSOR_FEATURE_FLAGS FeatureFlags;
>  } PROCESSOR_ID_DATA;
> @@ -2508,6 +2526,57 @@ typedef struct {
>UINT8 InterfaceTypeSpecificData[4];   ///< 
> This field has a minimum of four bytes
>  } SMBIOS_TABLE_TYPE42;
>  
> +
> +///
> +/// Processor Specific Block - Processor Architecture Type
> +///
> +typedef enum{
> +  ProcessorSpecificBlockArchTypeReserved   = 0x00,
> +  ProcessorSpecificBlockArchTypeIa32   = 0x01,
> +  ProcessorSpecificBlockArchTypeX64= 0x02,
> +  ProcessorSpecificBlockArchTypeItanium= 0x03,
> +  ProcessorSpecificBlockArchTypeAarch32= 0x04,
> +  ProcessorSpecificBlockArchTypeAarch64= 0x05,
> +  ProcessorSpecificBlockArchTypeRiscVRV32  = 0x06,
> +  ProcessorSpecificBlockArchTypeRiscVRV64  = 0x07,
> +  ProcessorSpecificBlockArchTypeRiscVRV128 = 0x08
> +} PROCESSOR_SPECIFIC_BLOCK_ARCH_TYPE;
> +
> +///
> +/// Processor Specific Block is the standard container of processor-specific 
> data.
> +///
> +typedef struct {
> +  UINT8  Length;
> +  UINT8  ProcessorArchType;
> +  ///
> +  /// Below followed by Processor-specific data
> +  ///
> +  ///
> +} PROCESSOR_SPECIFIC_BLOCK;
> +
> +///
> +/// Processor Additional Information(Type 44).
> +///
> +/// The information in this structure defines the processor additional 
> information in case 
> +/// SMBIOS type 4 is not sufficient to describe processor characteristics.
> +/// The SMBIOS type 44 structure has a reference handle field to link back 
> to the related 
> +/// SMBIOS type 4 structure. There may be multiple SMBIOS type 44 structures 
> linked to the 
> +/// same SMBIOS type 4 structure. For example, when cores are not identical 
> in a processor, 
> +/// 

Re: [edk2-devel] [PATCH] ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: revert to PIE linking

[Laszlo Ersek]

On 09/05/19 01:04, Ard Biesheuvel wrote:
> In some cases, the CLANG38 toolchain profile in LTO mode emits GOT
> based relocations in spite of our attempts to avoid this, by using
> hidden visibility, -Bsymbolic etc.
> 
> On AARCH64, we managed to work around this by processing the GOT
> based relocations in GenFw. As it turns out, the same issue exists
> on 32-bit ARM, but unfortunately, we cannot use a similar trick to
> get rid of the GOT entry, and the relocation metadata is insufficient
> to locate the GOT entry in the binary.
> 
> A bit of trial and error reveals that switching the linker options from
> -pie to -shared in commit e07092edca8442db4a941dbeea0cd196c7bf8ec9 was
> not the best approach, and instead, we can pass -pie to the linker
> directly (using -Wl,xxx) rather than to the compiler directly, which
> turns out to massage the linker in the right way, and prevents if from
> emitting GOT based relocations. Your mileage may vary ...
> 
> Signed-off-by: Ard Biesheuvel 
> ---
> Let's test this on a couple of different Clang versions. If it still
> produces problems, the only other way I see is to disable the builds
> of platforms that incorporate this module for ARM/CLANG38 [which is
> not the end of the world]
> 
>  ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf 
> b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> index 683397b7afd1..9e58e56fce09 100755
> --- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> +++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf
> @@ -97,4 +97,4 @@
>gArmTokenSpaceGuid.PcdFvBaseAddress
>  
>  [BuildOptions]
> -  GCC:*_*_*_DLINK_FLAGS = -shared -Wl,-Bsymbolic 
> -Wl,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> +  GCC:*_*_*_DLINK_FLAGS = 
> -Wl,-Bsymbolic,-pie,-T,$(MODULE_DIR)/Scripts/PrePi-PIE.lds
> 

Sorry for being late to this patch, I can see [*] it's upstream alrady.
Nonetheless:

Acked-by: Laszlo Ersek 

[*] Not from my inbox though -- I've got again too much on my plate and
am fetching email in batches. But, between my rebasing of
"ArmVirtPkg/PlatformBootManagerLib: unload image on
EFI_SECURITY_VIOLATION", building it, and attempting to push it, you had
pushed this one -- and I did notice that. :)

Thanks,
Laszlo

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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 21/22]: NetworkPkg

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:16PM +0800, Abner Chang wrote:
> Add RISCV64 Arch.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0

If you drop that contribution agreement:
Reviewed-by: Leif Lindholm 


> Signed-off-by: Abner Chang 
> ---
>  NetworkPkg/Network.dsc.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/NetworkPkg/Network.dsc.inc b/NetworkPkg/Network.dsc.inc
> index c7f4328..b484f9b 100644
> --- a/NetworkPkg/Network.dsc.inc
> +++ b/NetworkPkg/Network.dsc.inc
> @@ -34,7 +34,7 @@
>  !include NetworkPkg/NetworkComponents.dsc.inc
>  
>  !else
> -[Components.IA32, Components.X64, Components.ARM, Components.AARCH64]
> +[Components.IA32, Components.X64, Components.ARM, Components.AARCH64, 
> Components.RISCV64]
>  !include NetworkPkg/NetworkComponents.dsc.inc
>  
>  !endif
> -- 
> 2.7.4
> 
> 
> 
> 

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

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

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 22/22]: BaseTools/Scripts

[Leif Lindholm]

On Wed, Sep 04, 2019 at 06:43:17PM +0800, Abner Chang wrote:
> Add RISC-V specific LD scripts. ."rela(INFO)" in the latest GccBase.lds 
> causes PE32 relocation error. This is the temporaty solution untill we find 
> the root casue.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Abner Chang 

I have no issue with this patch, but I can't claim to have properly
reviewed it. I'll leave that for the BaseTools maintainers.

/
Leif

> ---
>  BaseTools/Scripts/GccBaseRiscV.lds | 71 
> ++
>  1 file changed, 71 insertions(+)
>  create mode 100644 BaseTools/Scripts/GccBaseRiscV.lds
> 
> diff --git a/BaseTools/Scripts/GccBaseRiscV.lds 
> b/BaseTools/Scripts/GccBaseRiscV.lds
> new file mode 100644
> index 000..b24086d
> --- /dev/null
> +++ b/BaseTools/Scripts/GccBaseRiscV.lds
> @@ -0,0 +1,71 @@
> +/** @file
> +
> +  Unified linker script for GCC based builds
> +
> +  Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2015, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials are licensed and made 
> available under
> +  the terms and conditions of the BSD License that accompanies this 
> distribution.
> +  The full text of the license may be found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +SECTIONS {
> +
> +  /*
> +   * The PE/COFF binary consists of DOS and PE/COFF headers, and a sequence 
> of
> +   * section headers adding up to PECOFF_HEADER_SIZE bytes (which differs
> +   * between 32-bit and 64-bit builds). The actual start of the .text section
> +   * will be rounded up based on its actual alignment.
> +   */
> +  . = PECOFF_HEADER_SIZE;
> +
> +  .text : ALIGN(CONSTANT(COMMONPAGESIZE)) {
> +*(.text .text.* .stub .gnu.linkonce.t.*)
> +*(.rodata .rodata.* .gnu.linkonce.r.*)
> +*(.got .got.*)
> +
> +/*
> + * The contents of AutoGen.c files are constant from the POV of the 
> program,
> + * but most of its contents end up in .data or .bss by default since few 
> of
> + * the variable definitions that get emitted are declared as CONST.
> + */
> +*:AutoGen.obj(.data.g*Guid)
> +  }
> +
> +  /*
> +   * The alignment of the .data section should be less than or equal to the
> +   * alignment of the .text section. This ensures that the relative offset
> +   * between these sections is the same in the ELF and the PE/COFF versions 
> of
> +   * this binary.
> +   */
> +  .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) {
> +*(.data .data.* .gnu.linkonce.d.*)
> +*(.bss .bss.*)
> +  }
> +
> +  .eh_frame ALIGN(CONSTANT(COMMONPAGESIZE)) : {
> +KEEP (*(.eh_frame))
> +  }
> +
> +  .rela ALIGN(CONSTANT(COMMONPAGESIZE)) : {
> +*(.rela .rela.*)
> +  }
> +
> +  /DISCARD/ : {
> +*(.note.GNU-stack)
> +*(.gnu_debuglink)
> +*(.interp)
> +*(.dynsym)
> +*(.dynstr)
> +*(.dynamic)
> +*(.hash)
> +*(.comment)
> +*(COMMON)
> +  }
> +}
> -- 
> 2.7.4
> 
> 
> 
> 

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

View/Reply Online (#46923): https://edk2.groups.io/g/devel/message/46923
Mute This Topic: https://groups.io/mt/33137150/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] OvmfPkg/EnrollDefaultKeys: clean up Base64Decode() retval handling

[Laszlo Ersek]

On 09/04/19 14:37, Ard Biesheuvel wrote:
> On Wed, 4 Sep 2019 at 00:52, Laszlo Ersek  wrote:
>>
>> Since commit 35e242b698cd ("MdePkg/BaseLib: rewrite Base64Decode()",
>> 2019-07-16), Base64Decode() guarantees that DestinationSize is larger on
>> output than it was on input if RETURN_BUFFER_TOO_SMALL is returned. Clean
>> up the retval handling for the first Base64Decode() call in
>> EnrollDefaultKeys, which used to work around the ambiguity in the previous
>> Base64Decode() interface contract.
>>
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>> Cc: Philippe Mathieu-Daudé 
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1981
>> Signed-off-by: Laszlo Ersek 
>> Reviewed-by: Philippe Mathieu-Daude 
> 
> Acked-by: Ard Biesheuvel 

Pushed as commit 59b754c9f697.

Thanks everyone!
Laszlo

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

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

[edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction

[Kubacki, Michael A]

Hello,

I would appreciate any feedback you may have for this proposal.

Overview
--
This is a proposal to reduce SMM usage when using VariableSmmRuntimeDxe with 
VariableSmm. It will do so by eliminating SMM usage for the vast majority of 
runtime service GetVariable ( ) and GetNextVariableName ( ) invocations. Most 
UEFI variable usage in typical systems after the variable store is initialized 
(e.g. manufacturing boots) is due to GetVariable ( ) and GetNextVariableName ( 
) not SetVariable ( ). GetVariable ( ) calls can regularly exceed 100 per boot 
while SetVariable ( ) calls typically remain less than 10 per boot. By focusing 
on the common case, the majority of overhead associated with SMM can be avoided 
while still using existing and proven code for operations such as variable 
authentication that require an isolated execution environment.

 * Advantage: Reduces overall system SMM usage
 * Disadvantage: Requires more Runtime data memory usage

Initial Performance Observations
--
 * With these proposed changes, an Intel Atom based SoC saw GetVariable ( ) 
time for an existing variable reduce from ~220us to ~5us.

Major Changes
-
 1. Two UEFI variable caches will be maintained.
 a. "Runtime Cache" - Maintained in VariableSmmRuntimeDxe. Used to serve 
runtime service GetVariable ( ) and GetNextVariableName ( ) callers.
 b. "SMM cache" - Maintained in VariableSmm to service SMM GetVariable ( ) 
and GetNextVariableName ( ) callers.
 i. A cache in SMRAM retained so SMM modules do not operate on data 
outside SMRAM.
 2. A new UEFI variable read and write flow will be used as described below.

At any given time, the two caches would be coherent. On a variable write, the 
runtime cache is only updated after validation in SMM and, in the case of a 
non-volatile UEFI variable, the variable must also be successfully written to 
non-volatile storage. 

Primary Concern
---
The primary item that I believe warrants feedback is whether there are 
substantial concerns with keeping a variable store cache that is used to serve 
UEFI Runtime Services callers in a buffer of EfiRuntimeServicesData type. 

Proof-of-Concept Implementation
--
The implementation is available in the following commit - check the commit 
message for some more details. 
https://github.com/makubacki/edk2/commit/d812d43412a26e44581d283382596a863c1ae825

Please note this is "POC" level code quality and there will be cleanup of lock 
interfaces used and some other minor changes. Please feel free to leave any 
comments on the changes. This code was tested with the master branch of edk2 on 
an Intel Whiskey Lake U reference validation platform.

Why Keep SMM on Variable Writes

 * SMM provides a fairly ubiquitous isolated execution environment in x86 for 
authenticated UEFI variables.
 * BIOS region SPI flash write restrictions to SMM in platforms today can be 
retained.

Today's UEFI Variable Cache
--
 * Maintained in SMRAM via VariableSmm.
 * A "write-through" cache of variable data in the form of a UEFI variable 
store.
 * Non-volatile and volatile variables are maintained in separate buffers 
(variable stores).

Runtime & SMM Cache Coherency
--
The non-volatile cache should always accurately reflect non-volatile storage 
contents (done today) and the "SMM cache" and "Runtime cache" should always be 
coherent on access. The runtime cache is updated by VariableSmm.

Updating both caches from within a SMM SetVariable ( ) operation is fairly 
straightforward but a race condition can occur if an SMI occurs during the 
execution of runtime code reading from the runtime cache. To handle this case, 
a runtime cache read lock is introduced that explicitly moves pending updates 
from SMM to the runtime cache if an SMM update occurs while the runtime cache 
is locked. Note that is not expected a Runtime services call will interrupt SMM 
processing since all cores rendezvous in SMM. 

New Key Elements for Coherence
-
Runtime DXE (VariableSmmRuntimeDxe)
 1. RuntimeCacheReadLock - A global lock used to lock read access to the 
runtime cache.
 2. RuntimeCachePendingUpdate - A global flag used to notify runtime code of a 
pending cache update in SMM.

SMM (VariableSmm)
 1. FlushRuntimeCachePendingUpdate SMI - A SW SMI handler that synchronizes the 
runtime cache buffer with the SMM cache buffer.

Proposed Runtime DXE Read Flow
--
 1. Wait for RuntimeCacheReadLock to be free
 2. Acquire RuntimeCacheReadLock
 3. If RuntimeCachePendingUpdate flag is set then:
 3.a. Trigger FlushRuntimeCachePendingUpdate SMI
 3.b. Verify RuntimeCachePendingUpdate flag is cleared
 4. Perform read from 

[edk2-devel] [PATCH] UefiCpuPkg/PiSmmCpu: Enable 5L paging only when phy addr line > 48

[Ni, Ray]

Today's behavior is to enable 5l paging when CPU supports it
(CPUID[7,0].ECX.BIT[16] is set).

The patch changes the behavior to enable 5l paging when two
conditions are both met:
1. CPU supports it;
2. The max physical address bits is bigger than 48.

Because 4-level paging can support to address physical address up to
2^48 - 1, there is no need to enable 5-level paging with max
physical address bits <= 48.

Signed-off-by: Ray Ni 
Cc: Liming Gao 
Cc: Eric Dong 
Cc: Laszlo Ersek 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 57 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm |  4 +-
 2 files changed, 39 insertions(+), 22 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
index 733d107efd..e5c4788c13 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
@@ -16,8 +16,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 LIST_ENTRY  mPagePool = INITIALIZE_LIST_HEAD_VARIABLE 
(mPagePool);
 BOOLEAN m1GPageTableSupport = FALSE;
 BOOLEAN mCpuSmmRestrictedMemoryAccess;
-BOOLEAN m5LevelPagingSupport;
-X86_ASSEMBLY_PATCH_LABELgPatch5LevelPagingSupport;
+BOOLEAN m5LevelPagingNeeded;
+X86_ASSEMBLY_PATCH_LABELgPatch5LevelPagingNeeded;
 
 /**
   Disable CET.
@@ -63,28 +63,45 @@ Is1GPageSupport (
 }
 
 /**
-  Check if 5-level paging is supported by processor or not.
-
-  @retval TRUE   5-level paging is supported.
-  @retval FALSE  5-level paging is not supported.
+  The routine returns TRUE when CPU supports it (CPUID[7,0].ECX.BIT[16] is 
set) and
+  the max physical address bits is bigger than 48. Because 4-level paging can 
support
+  to address physical address up to 2^48 - 1, there is no need to enable 
5-level paging
+  with max physical address bits <= 48.
 
+  @retval TRUE  5-level paging enabling is needed.
+  @retval FALSE 5-level paging enabling is not needed.
 **/
 BOOLEAN
-Is5LevelPagingSupport (
+Is5LevelPagingNeeded (
   VOID
   )
 {
-  CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_ECX EcxFlags;
+  CPUID_VIR_PHY_ADDRESS_SIZE_EAX  VirPhyAddressSize;
+  CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_ECX ExtFeatureEcx;
+  UINT32  MaxExtendedFunctionId;
 
+  AsmCpuid (CPUID_EXTENDED_FUNCTION, , NULL, NULL, NULL);
+  if (MaxExtendedFunctionId >= CPUID_VIR_PHY_ADDRESS_SIZE) {
+AsmCpuid (CPUID_VIR_PHY_ADDRESS_SIZE, , NULL, 
NULL, NULL);
+  } else {
+VirPhyAddressSize.Bits.PhysicalAddressBits = 36;
+  }
   AsmCpuidEx (
 CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS,
 CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_SUB_LEAF_INFO,
-NULL,
-NULL,
-,
-NULL
+NULL, NULL, , NULL
 );
-  return (BOOLEAN) (EcxFlags.Bits.FiveLevelPage != 0);
+  DEBUG ((
+DEBUG_INFO, "PhysicalAddressBits = %d, 5LPageTable = %d.\n",
+VirPhyAddressSize.Bits.PhysicalAddressBits, 
ExtFeatureEcx.Bits.FiveLevelPage
+));
+
+  if (VirPhyAddressSize.Bits.PhysicalAddressBits > 4 * 9 + 12) {
+ASSERT (ExtFeatureEcx.Bits.FiveLevelPage == 1);
+return TRUE;
+  } else {
+return FALSE;
+  }
 }
 
 /**
@@ -190,7 +207,7 @@ SetStaticPageTable (
   //  when 5-Level Paging is disabled.
   //
   ASSERT (mPhysicalAddressBits <= 52);
-  if (!m5LevelPagingSupport && mPhysicalAddressBits > 48) {
+  if (!m5LevelPagingNeeded && mPhysicalAddressBits > 48) {
 mPhysicalAddressBits = 48;
   }
 
@@ -217,7 +234,7 @@ SetStaticPageTable (
 
   PageMapLevel4Entry = PageMap;
   PageMapLevel5Entry = NULL;
-  if (m5LevelPagingSupport) {
+  if (m5LevelPagingNeeded) {
 //
 // By architecture only one PageMapLevel5 exists - so lets allocate 
storage for it.
 //
@@ -233,7 +250,7 @@ SetStaticPageTable (
 // So lets allocate space for them and fill them in in the 
IndexOfPml4Entries loop.
 // When 5-Level Paging is disabled, below allocation happens only once.
 //
-if (m5LevelPagingSupport) {
+if (m5LevelPagingNeeded) {
   PageMapLevel4Entry = (UINT64 *) ((*PageMapLevel5Entry) & 
~mAddressEncMask & gPhyMask);
   if (PageMapLevel4Entry == NULL) {
 PageMapLevel4Entry = AllocatePageTableMemory (1);
@@ -336,10 +353,10 @@ SmmInitPageTable (
 
   mCpuSmmRestrictedMemoryAccess = PcdGetBool (PcdCpuSmmRestrictedMemoryAccess);
   m1GPageTableSupport   = Is1GPageSupport ();
-  m5LevelPagingSupport  = Is5LevelPagingSupport ();
+  m5LevelPagingNeeded   = Is5LevelPagingNeeded ();
   mPhysicalAddressBits  = CalculateMaximumSupportAddress ();
-  PatchInstructionX86 (gPatch5LevelPagingSupport, m5LevelPagingSupport, 1);
-  DEBUG ((DEBUG_INFO, "5LevelPaging Support- %d\n", 
m5LevelPagingSupport));
+  PatchInstructionX86 (gPatch5LevelPagingNeeded, m5LevelPagingNeeded, 1);
+  DEBUG ((DEBUG_INFO, "5LevelPaging Needed - %d\n", 

Re: [edk2-devel] [edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction

[Johnson, Michael]

Your primary concern is my primary concern.  I can think of two scenarios where 
a runtime memory varstore would hurt.

The less severe one is that any variables measured into a TPM could appear to 
be modified when read back so that if/when some entity wants to verify or 
unseal something, they would be unable to match the TPM's PCR values and unable 
to verify/unseal.  This turns access to runtime EFI memory into a denial of 
service for TPM-based post-boot software.

The more worrying possibility is if somebody decides to use a read-modify-write 
pattern for some variable they have an interest in and thus end up defeating 
the security of the variable write method.  Today a read-modify-write is safe, 
but after this change it would not be.

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

View/Reply Online (#46941): https://edk2.groups.io/g/devel/message/46941
Mute This Topic: https://groups.io/mt/33158252/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 Meeting - APAC/NAMO - Thursday, 5 September 2019 #cal-cancelled

[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.14...@groups.io
DTSTAMP:20190905T215637Z
ORGANIZER;CN=Stephano Cetola:mailto:stephano.cet...@intel.com
DTSTART;TZID=America/Los_Angeles:20190905T183000
DTEND;TZID=America/Los_Angeles:20190905T193000
SUMMARY:TianoCore Design Meeting - APAC/NAMO
DESCRIPTION:Join Zoom Meeting\n\nhttps://zoom.us/j/969264410 ( https://zoom.us/j/969264410 )\n\nOne tap mobile\n\n+16465588656,,969264410# US (New York)\n\n+17207072699,,969264410# US\n\nDial by your location\n\n+1 646 558 8656 US (New York)\n\n+1 720 707 2699 US\n\nMeeting ID: 969 264 410\n\nFind your local number: https://zoom.us/u/abOtdJckxL
LOCATION:https://zoom.us/j/969264410
RECURRENCE-ID;TZID=America/Los_Angeles:20190905T183000
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] [PATCH 00/22] RISC-V EDK2 Port on edk2-staging/RISC-V-V2 branch

[Abner Chang]

Hi Leif, thanks for went through these patches. I will check those comments and 
submit another version.
Abner
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Leif Lindholm
> Sent: Friday, September 6, 2019 1:16 AM
> To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> 
> Subject: Re: [edk2-devel] [PATCH 00/22] RISC-V EDK2 Port on edk2-
> staging/RISC-V-V2 branch
> 
> Hi Abner,
> 
> Many thanks for this.
> I have now gone through all of the patches, and left some specific as well as
> some general comments. Please address those, or comment on why you
> would prefer not changing.
> 
> For v2, could you do a few things please (some of which I've mentioned
> throughout my comments on various patches):
> - Run PatchCheck.py on all patches and address the output. If you
>   disagree with some specific failure, please comment on this below
>   the --- in the commit message in the generated patch.
> - Run SetupGit.py in your edk2 repository (this includes installing
>   git-python)
> - Run BaseTools/Scripts/GetMaintainer.py on each of the commits, and
>   add a Cc: tag for each person listed in the output to the commit
>   message of that patch. Then add all of those Cc:d people as Cc: tags
>   to the [0/xx patch for the next set. This wat they will all get Cc:d
>   on the patches that are relevant to them.
>   Few read all messages posted to edk2-devel diligently, so it's
>   possible they will have missed this set completely. (Feel free to
>   reply to your patches from v1, adding the relevant reviewers to cc.)
> - Add your own entry in Maintainers.txt for the new packages.
>   My suggestion would be that you add yourself as a designated
>   reviewer (R:) for now. Find some people willing to actually sling
>   the patches and add them as M: for now. I would be willing to be one
>   of them as long as you can also find others :)
> - Convert all of the .uni files to UTF-8 (no BOM, I think?).
> 
> Additionally, it would be really helpful if you could include a link to the 
> set on
> a branch in a public git repository somewhere. Converting the .uni files to
> UTF-8 should make it possible for my usual scripts to start working again, but
> being able to just pull from a repo is even easier.
> 
> Best Regards,
> 
> Leif
> 
> On Wed, Sep 04, 2019 at 06:42:55PM +0800, Abner Chang wrote:
> > This branch "RISC-V-V2" is used to contribute RISC-V architecture on EDK2.
> > Compare to the old branch "RISC-V", this branch "RISC-V-V2" is created
> > based on the most recent edk2/master @37eef910. This is easier for
> > reviewers to have clear ideas of edk2 code changes for RISC-V EDK2
> implementation.
> > Because of the code changes made on old branch "RISC-V" is stale and
> > not compliant with the latest RISC-V spec, this new branch has the
> > fresh changes for RISC-V EDK2 implementation.
> >
> > The main changes of these series of patches are,
> > - Add RiscVPkg which conform with RISC-V Privilege Spec v1.10.
> > - Incorporate and leverage RISC-V OpenSBI to provide EDK2 port OpenSBI
> library.
> > - Provide RISC-V platform implementation specific drivers to EDK2 RISC-V
> platform
> >   package.
> > - Provide generic RISC-V SMBIOS DXE drive to create SMBIOS type 4, 7 and
> 44 records,
> >   in which the SMBIOS type 44 record is introduced in SMBIOS spec 3.3.0.
> >
> >
> > Abner Chang (22):
> >   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg: RISC-V processor package.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg/Include: Add header files
> > of RISC-V CPU package
> >   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg: RISC-V sections in DEC
> > file.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/Include: RISC-V definitions.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: MdeModulePkg/CapsuleRuntimeDxe:
> Add
> > RISC-V arch.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BaseCacheMaintenanceLib:
> > RISC-V cache maintenance implementation.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BaseIoLibIntrinsic: RISC-V
> > I/O intrinsic functions.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BasePeCoff: Add RISC-V
> > PE/Coff related code.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BaseCpuLib: RISC-V Base
> CPU
> > library implementation.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BaseSynchronizationLib:
> > RISC-V cache related code.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: BaseTools: BaseTools changes for
> > RISC-V platform.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/BaseLib: BaseLib for RISC-V
> > RV64 Processor.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: MdePkg/Include: Update SmBios
> > header file.
> >   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg/opesbi: Add
> > opensbi-HOWTO.txt
> >   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg/RealTimeClockRuntimeDxe:
> > Add RISC-V RTC Runtime Driver
> >   [edk2-staging/RISC-V-V2 PATCH v1]: RiscVPkg/CpuDxe: Add RISC-V CPU
> DXE
> > driver.
> >   

[edk2-devel] [edk2-platforms][PATCH V2] AdvancedFeaturePkg/S3Advanced Add S3 Advanced PEIM driver

[Marc W Chen]

Implement a S3 Advanced PEIM driver for supporting S3 feature.
So far this driver only install EFI_PEI_MM_ACCESS_PPI for S3 resume case.

Cc: Michael Kubacki 
Cc: Sai Chaganty 
Cc: Liming Gao 
Signed-off-by: Marc Chen 
---
 .../S3Advanced/S3AdvancedPei/S3AdvancedPei.c   | 36 ++
 .../S3Advanced/S3AdvancedPei/S3AdvancedPei.inf | 31 +++
 2 files changed, 67 insertions(+)
 create mode 100644 
Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
 create mode 100644 
Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf

diff --git 
a/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c 
b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
new file mode 100644
index ..9ce4cc6a
--- /dev/null
+++ b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
@@ -0,0 +1,36 @@
+/** @file
+  Source code file for S3 Advanced PEI module
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+
+/**
+  S3 Advanced PEI module entry point
+
+  @param[in]  FileHandle   Not used.
+  @param[in]  PeiServices  General purpose services available to every 
PEIM.
+
+  @retval EFI_SUCCESS  The function completes successfully
+  @retval EFI_OUT_OF_RESOURCES Insufficient resources to create database
+**/
+EFI_STATUS
+EFIAPI
+S3AdvancedEntryPoint (
+  IN   EFI_PEI_FILE_HANDLE  FileHandle,
+  IN CONST EFI_PEI_SERVICES **PeiServices
+  )
+{
+  EFI_STATUS Status;
+
+  //
+  // Install EFI_PEI_MM_ACCESS_PPI for S3 resume case
+  //
+  Status = PeiInstallSmmAccessPpi ();
+
+  return Status;
+}
diff --git 
a/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf 
b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf
new file mode 100644
index ..9b654bfa
--- /dev/null
+++ 
b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf
@@ -0,0 +1,31 @@
+### @file
+# Component information file for the S3 Advanced PEI module.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+###
+
+[Defines]
+  INF_VERSION= 0x00010017
+  BASE_NAME  = S3AdvancedPei
+  FILE_GUID  = 8683EFB2-FDE1-4AFF-B2DB-E96449FDD4E9
+  VERSION_STRING = 1.0
+  MODULE_TYPE= PEIM
+  ENTRY_POINT= S3AdvancedEntryPoint
+
+[LibraryClasses]
+  PeimEntryPoint
+  PeiServicesLib
+  SmmAccessLib
+
+[Packages]
+  IntelSiliconPkg/IntelSiliconPkg.dec
+  MdePkg/MdePkg.dec
+
+[Sources]
+  S3AdvancedPei.c
+
+[Depex]
+  TRUE
-- 
2.16.2.windows.1


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

View/Reply Online (#46954): https://edk2.groups.io/g/devel/message/46954
Mute This Topic: https://groups.io/mt/33161565/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 V3] AdvancedFeaturePkg/S3Advanced Add S3 Advanced PEIM driver

[Marc W Chen]

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

Implement a S3 Advanced PEIM driver for supporting S3 feature.
So far this driver only install EFI_PEI_MM_ACCESS_PPI for S3 resume case.

Cc: Michael Kubacki 
Cc: Sai Chaganty 
Cc: Liming Gao 
Signed-off-by: Marc Chen 
---
 .../S3Advanced/S3AdvancedPei/S3AdvancedPei.c   | 36 ++
 .../S3Advanced/S3AdvancedPei/S3AdvancedPei.inf | 31 +++
 2 files changed, 67 insertions(+)
 create mode 100644 
Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
 create mode 100644 
Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf

diff --git 
a/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c 
b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
new file mode 100644
index ..9ce4cc6a
--- /dev/null
+++ b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
@@ -0,0 +1,36 @@
+/** @file
+  Source code file for S3 Advanced PEI module
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+
+/**
+  S3 Advanced PEI module entry point
+
+  @param[in]  FileHandle   Not used.
+  @param[in]  PeiServices  General purpose services available to every 
PEIM.
+
+  @retval EFI_SUCCESS  The function completes successfully
+  @retval EFI_OUT_OF_RESOURCES Insufficient resources to create database
+**/
+EFI_STATUS
+EFIAPI
+S3AdvancedEntryPoint (
+  IN   EFI_PEI_FILE_HANDLE  FileHandle,
+  IN CONST EFI_PEI_SERVICES **PeiServices
+  )
+{
+  EFI_STATUS Status;
+
+  //
+  // Install EFI_PEI_MM_ACCESS_PPI for S3 resume case
+  //
+  Status = PeiInstallSmmAccessPpi ();
+
+  return Status;
+}
diff --git 
a/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf 
b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf
new file mode 100644
index ..9b654bfa
--- /dev/null
+++ 
b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf
@@ -0,0 +1,31 @@
+### @file
+# Component information file for the S3 Advanced PEI module.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+###
+
+[Defines]
+  INF_VERSION= 0x00010017
+  BASE_NAME  = S3AdvancedPei
+  FILE_GUID  = 8683EFB2-FDE1-4AFF-B2DB-E96449FDD4E9
+  VERSION_STRING = 1.0
+  MODULE_TYPE= PEIM
+  ENTRY_POINT= S3AdvancedEntryPoint
+
+[LibraryClasses]
+  PeimEntryPoint
+  PeiServicesLib
+  SmmAccessLib
+
+[Packages]
+  IntelSiliconPkg/IntelSiliconPkg.dec
+  MdePkg/MdePkg.dec
+
+[Sources]
+  S3AdvancedPei.c
+
+[Depex]
+  TRUE
-- 
2.16.2.windows.1


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

View/Reply Online (#46955): https://edk2.groups.io/g/devel/message/46955
Mute This Topic: https://groups.io/mt/33161584/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 v5 4/7] SimicsOpenBoardPkg: Add DXE driver for Legacy Sio

[David Wei]

Add DXE driver for Legacy Sio support

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 

Signed-off-by: David Wei 
---
 .../LegacySioDxe/ComponentName.c   | 173 ++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioChip.c  | 272 ++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c| 600 +
 .../SimicsOpenBoardPkg/LegacySioDxe/SioService.c   | 249 +
 .../LegacySioDxe/ComponentName.h   |  87 +++
 .../LegacySioDxe/LegacySioDxe.inf  |  54 ++
 .../SimicsOpenBoardPkg/LegacySioDxe/Register.h |  15 +
 .../SimicsOpenBoardPkg/LegacySioDxe/SioChip.h  | 195 +++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioDriver.h| 134 +
 .../SimicsOpenBoardPkg/LegacySioDxe/SioService.h   | 143 +
 10 files changed, 1922 insertions(+)
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioChip.c
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioService.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.h
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/LegacySioDxe.inf
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/Register.h
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioChip.h
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioDriver.h
 create mode 100644 Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/SioService.h

diff --git a/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c 
b/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
new file mode 100644
index 00..4ba02f92c0
--- /dev/null
+++ b/Platform/Intel/SimicsOpenBoardPkg/LegacySioDxe/ComponentName.c
@@ -0,0 +1,173 @@
+/** @file
+  Install Base and Size Info Ppi for Firmware Volume Recovery.
+
+  Copyright (c) 2013 - 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "SioDriver.h"
+
+///
+/// Component Name Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL  mSioComponentName = 
{
+  SioComponentNameGetDriverName,
+  SioComponentNameGetControllerName,
+  "eng"
+};
+
+///
+/// Component Name 2 Protocol instance
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL mSioComponentName2 
= {
+  (EFI_COMPONENT_NAME2_GET_DRIVER_NAME)SioComponentNameGetDriverName,
+  (EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)SioComponentNameGetControllerName,
+  "en"
+};
+
+///
+/// Table of driver names
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE mSioDriverNameTable[] = 
{
+  {
+"eng;en",
+L"Super I/O Driver"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+///
+/// Table of Controller names
+///
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE 
mSioControllerNameTable[] = {
+  {
+"eng;en",
+L"Super I/O Controller"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+/**
+  Retrieves a Unicode string that is the user-readable name of the EFI Driver.
+
+  @param  This   A pointer to the EFI_COMPONENT_NAME_PROTOCOL instance.
+  @param  Language   A pointer to a three-character ISO 639-2 language 
identifier.
+ This is the language of the driver name that that the 
caller
+ is requesting, and it must match one of the languages 
specified
+ in SupportedLanguages.  The number of languages supported 
by a
+ driver is up to the driver writer.
+  @param  DriverName A pointer to the Unicode string to return.  This Unicode 
string
+ is the name of the driver specified by This in the 
language
+ specified by Language.
+
+  @retval EFI_SUCCESS   The Unicode string for the Driver specified by 
This
+and the language specified by Language was 
returned
+in DriverName.
+  @retval EFI_INVALID_PARAMETER Language is NULL.
+  @retval EFI_INVALID_PARAMETER DriverName is NULL.
+  @retval EFI_UNSUPPORTED   The driver specified by This does not support 
the
+language specified by Language.
+
+**/
+EFI_STATUS
+EFIAPI
+SioComponentNameGetDriverName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL  *This,
+  IN  CHAR8*Language,
+  OUT CHAR16   **DriverName
+  )
+{
+  return LookupUnicodeString2 (
+   Language,
+   This->SupportedLanguages,
+   mSioDriverNameTable,
+   DriverName,
+   (BOOLEAN)(This == )
+   );
+}
+
+/**
+  Retrieves a Unicode string that is the user readable name of the controller
+  that is being managed by an EFI Driver.
+
+  @param  This A 

[edk2-devel] [edk2-platforms PATCH v5 7/7] Platform/Intel: Add build option for SIMICS QSP Platform

[David Wei]

Add build option in build script for SIMICS QSP(Quick Start Platform) Platform
Add Maintainers of Simics QSP related packages

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 

Signed-off-by: David Wei 
---
 Maintainers.txt  | 12 
 Platform/Intel/build.cfg |  2 ++
 Platform/Intel/build_bios.py |  3 +++
 3 files changed, 17 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index b16432bf87..90eb3c3dd0 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -103,6 +103,10 @@ M: Chasel Chiu 
 M: Michael Kubacki 
 M: Nate DeSimone 
 
+Platform/Intel/SimicsOpenBoardPkg
+M: Wei David Y 
+M: Agyeman Prince 
+
 Platform/Intel/Tools
 M: Bob Feng 
 M: Liming Gao 
@@ -155,6 +159,14 @@ M: Gillispie, Thad 
 M: Bu, Daocheng 
 M: Oram, Isaac W 
 
+Silicon/Intel/SimicsX58SktPkg
+M: Wei David Y 
+M: Agyeman Prince 
+
+Silicon/Intel/SimicsIch10Pkg
+M: Wei David Y 
+M: Agyeman Prince 
+
 Silicon/Intel/Tools
 M: Bob Feng 
 M: Liming Gao 
diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg
index b6d32ada49..75cb446aa5 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -11,6 +11,7 @@ WORKSPACE =
 WORKSPACE_FSP_BIN = FSP
 EDK_TOOLS_BIN = edk2-BaseTools-win32
 EDK_BASETOOLS = BaseTools
+WORKSPACE_DRIVERS = edk2-platforms/Drivers
 WORKSPACE_PLATFORM = edk2-platforms/Platform/Intel
 WORKSPACE_SILICON = edk2-platforms/Silicon/Intel
 WORKSPACE_PLATFORM_BIN =
@@ -52,6 +53,7 @@ NUMBER_OF_PROCESSORS = 0
 [PLATFORMS]
 # board_name = path_to_board_build_config.cfg
 BoardMtOlympus = PurleyOpenBoardPkg/BoardMtOlympus/build_config.cfg
+BoardX58Ich10 = SimicsOpenBoardPkg/BoardX58Ich10/build_config.cfg
 KabylakeRvp3 = KabylakeOpenBoardPkg/KabylakeRvp3/build_config.cfg
 N1xxWU = ClevoOpenBoardPkg/N1xxWU/build_config.cfg
 WhiskeylakeURvp = WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/build_config.cfg
diff --git a/Platform/Intel/build_bios.py b/Platform/Intel/build_bios.py
index 9152670dcb..46285df19a 100644
--- a/Platform/Intel/build_bios.py
+++ b/Platform/Intel/build_bios.py
@@ -104,6 +104,8 @@ def pre_build(build_config, build_type="DEBUG", 
silent=False, toolchain=None):
 config["WORKSPACE_PLATFORM"])
 config["WORKSPACE_SILICON"] = os.path.join(config["WORKSPACE"],
config["WORKSPACE_SILICON"])
+config["WORKSPACE_DRIVERS"] = os.path.join(config["WORKSPACE"],
+   config["WORKSPACE_DRIVERS"])
 config["WORKSPACE_PLATFORM_BIN"] = \
 os.path.join(config["WORKSPACE"], config["WORKSPACE_PLATFORM_BIN"])
 config["WORKSPACE_SILICON_BIN"] = \
@@ -115,6 +117,7 @@ def pre_build(build_config, build_type="DEBUG", 
silent=False, toolchain=None):
 config["PACKAGES_PATH"] = config["WORKSPACE_PLATFORM"]
 config["PACKAGES_PATH"] += os.pathsep + config["WORKSPACE_SILICON"]
 config["PACKAGES_PATH"] += os.pathsep + config["WORKSPACE_SILICON_BIN"]
+config["PACKAGES_PATH"] += os.pathsep + config["WORKSPACE_DRIVERS"]
 config["PACKAGES_PATH"] += os.pathsep + \
 os.path.join(config["WORKSPACE"], "FSP")
 config["PACKAGES_PATH"] += os.pathsep + \
-- 
2.16.2.windows.1


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

View/Reply Online (#46947): https://edk2.groups.io/g/devel/message/46947
Mute This Topic: https://groups.io/mt/33159242/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 v5 1/7] SimicsX58SktPkg: Add CPU Pkg for SimicsX58

[David Wei]

Add CPU Pkg for SimicsX58. It is added for simics Quick Start Platform project 
support

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 

Signed-off-by: David Wei 
---
 .../SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c | 148 +
 .../SimicsX58SktPkg/Smm/Access/SmmAccessPei.c  | 346 +
 .../SimicsX58SktPkg/Smm/Access/SmramInternal.c | 200 
 .../Include/Register/X58SmramSaveStateMap.h| 178 +++
 Silicon/Intel/SimicsX58SktPkg/SktPkg.dec   |  37 +++
 Silicon/Intel/SimicsX58SktPkg/SktPkgPei.dsc|  14 +
 .../Intel/SimicsX58SktPkg/SktPostMemoryInclude.fdf |   9 +
 .../Intel/SimicsX58SktPkg/SktPreMemoryInclude.fdf  |  10 +
 Silicon/Intel/SimicsX58SktPkg/SktSecInclude.fdf|  16 +
 .../Intel/SimicsX58SktPkg/SktUefiBootInclude.fdf   |  14 +
 .../SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.inf   |  54 
 .../SimicsX58SktPkg/Smm/Access/SmmAccessPei.inf|  65 
 .../SimicsX58SktPkg/Smm/Access/SmramInternal.h |  82 +
 13 files changed, 1173 insertions(+)
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.c
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmramInternal.c
 create mode 100644 
Silicon/Intel/SimicsX58SktPkg/Include/Register/X58SmramSaveStateMap.h
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPkg.dec
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPkgPei.dsc
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPostMemoryInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktPreMemoryInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktSecInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/SktUefiBootInclude.fdf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.inf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccessPei.inf
 create mode 100644 Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmramInternal.h

diff --git a/Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c 
b/Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c
new file mode 100644
index 00..5d3b2c14aa
--- /dev/null
+++ b/Silicon/Intel/SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c
@@ -0,0 +1,148 @@
+/** @file
+  A DXE_DRIVER providing SMRAM access by producing EFI_SMM_ACCESS2_PROTOCOL.
+
+  X58 TSEG is expected to have been verified and set up by the SmmAccessPei
+  driver.
+
+  Copyright (C) 2013, 2015, Red Hat, Inc.
+  Copyright (c) 2009 - 2019, Intel Corporation. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+#include "SmramInternal.h"
+
+/**
+  Opens the SMRAM area to be accessible by a boot-service driver.
+
+  This function "opens" SMRAM so that it is visible while not inside of SMM.
+  The function should return EFI_UNSUPPORTED if the hardware does not support
+  hiding of SMRAM. The function should return EFI_DEVICE_ERROR if the SMRAM
+  configuration is locked.
+
+  @param[in] This   The EFI_SMM_ACCESS2_PROTOCOL instance.
+
+  @retval EFI_SUCCESS   The operation was successful.
+  @retval EFI_UNSUPPORTED   The system does not support opening and closing of
+SMRAM.
+  @retval EFI_DEVICE_ERROR  SMRAM cannot be opened, perhaps because it is
+locked.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+SmmAccess2DxeOpen (
+  IN EFI_SMM_ACCESS2_PROTOCOL  *This
+  )
+{
+  return SmramAccessOpen (>LockState, >OpenState);
+}
+
+/**
+  Inhibits access to the SMRAM.
+
+  This function "closes" SMRAM so that it is not visible while outside of SMM.
+  The function should return EFI_UNSUPPORTED if the hardware does not support
+  hiding of SMRAM.
+
+  @param[in] This   The EFI_SMM_ACCESS2_PROTOCOL instance.
+
+  @retval EFI_SUCCESS   The operation was successful.
+  @retval EFI_UNSUPPORTED   The system does not support opening and closing of
+SMRAM.
+  @retval EFI_DEVICE_ERROR  SMRAM cannot be closed.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+SmmAccess2DxeClose (
+  IN EFI_SMM_ACCESS2_PROTOCOL  *This
+  )
+{
+  return SmramAccessClose (>LockState, >OpenState);
+}
+
+/**
+  Inhibits access to the SMRAM.
+
+  This function prohibits access to the SMRAM region.  This function is usually
+  implemented such that it is a write-once operation.
+
+  @param[in] This  The EFI_SMM_ACCESS2_PROTOCOL instance.
+
+  @retval EFI_SUCCESS  The device was successfully locked.
+  @retval EFI_UNSUPPORTED  The system does not support locking of SMRAM.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+SmmAccess2DxeLock (
+  IN EFI_SMM_ACCESS2_PROTOCOL  *This
+  )
+{
+  return SmramAccessLock (>LockState, >OpenState);
+}
+
+/**
+  Queries the memory controller for the possible regions that will support
+  SMRAM.
+
+  @param[in] This   

[edk2-devel] [edk2-platforms PATCH v5 0/7] Add Initial QSP MinPlatform Pkg for SIMICS

[David Wei]

Create the SimicsOpenBoardPkg and its silicon Pkg to provide the support
for SIMICS quick start platform. it uses X58/ICH10 and emulated by SIMICS
model.

Different from v4:
  Cleanup name of SkyLake
  expand the QSP acronym to Quick Start Package
  ExChange the patch number 6 and 7 to make patch6 as final patch
  Change ICH to Ich in commit comments
David Wei (7):
  SimicsX58SktPkg:  Add CPU Pkg for SimicsX58
  SimicsIch10Pkg:  Add Ich Pkg for SimicsIch10
  SimicsOpenBoardPkg:  Add SimicsOpenBoardPkg and its modules
  SimicsOpenBoardPkg: Add DXE driver for Legacy Sio
  SimicsOpenBoardPkg:  Add modules and dec file under SimicsOpenBoardPkg
  SimicsOpenBoardPkg/BoardX58Ich10: Add board modules for QSP Build tip
  Platform/Intel:  Add build option for SIMICS QSP Platform

 .../MinPlatformAcpiTables/AcpiPlatform.c   | 1579 
 .../AcpiTables/MinPlatformAcpiTables/Facs/Facs.c   |   84 ++
 .../AcpiTables/MinPlatformAcpiTables/Fadt/Fadt.c   |  359 +
 .../AcpiTables/MinPlatformAcpiTables/Hpet/Hpet.c   |   78 +
 .../AcpiTables/MinPlatformAcpiTables/Wsmt/Wsmt.c   |   46 +
 .../Library/BoardInitLib/PeiBoardInitPostMemLib.c  |   44 +
 .../Library/BoardInitLib/PeiBoardInitPreMemLib.c   |  110 ++
 .../Library/BoardInitLib/PeiX58Ich10Detect.c   |   26 +
 .../BoardInitLib/PeiX58Ich10InitPostMemLib.c   |   34 +
 .../BoardInitLib/PeiX58Ich10InitPreMemLib.c|  111 ++
 .../LegacySioDxe/ComponentName.c   |  173 +++
 .../SimicsOpenBoardPkg/LegacySioDxe/SioChip.c  |  272 
 .../SimicsOpenBoardPkg/LegacySioDxe/SioDriver.c|  600 
 .../SimicsOpenBoardPkg/LegacySioDxe/SioService.c   |  249 +++
 .../SimicsOpenBoardPkg/Library/DxeLogoLib/Logo.c   |  647 
 .../Library/LoadLinuxLib/Linux.c   |  662 
 .../Library/LoadLinuxLib/LinuxGdt.c|  175 +++
 .../Library/NvVarsFileLib/FsAccess.c   |  507 +++
 .../Library/NvVarsFileLib/NvVarsFileLib.c  |   77 +
 .../Library/PciHostBridgeLib/PciHostBridgeLib.c|  419 ++
 .../SimicsOpenBoardPkg/Library/PeiReportFvLib/Fv.c |  100 ++
 .../Library/PeiReportFvLib/PeiReportFvLib.c|  119 ++
 .../Library/PlatformBootManagerLib/BdsPlatform.c   | 1553 +++
 .../Library/PlatformBootManagerLib/PlatformData.c  |   35 +
 .../SerializeVariablesLib/SerializeVariablesLib.c  |  869 +++
 .../SiliconPolicyInitLib/SiliconPolicyInitLib.c|  108 ++
 .../SiliconPolicyUpdateLib.c   |   70 +
 .../Intel/SimicsOpenBoardPkg/SecCore/SecMain.c |  956 
 .../Intel/SimicsOpenBoardPkg/SimicsDxe/Platform.c  |  865 +++
 .../SimicsOpenBoardPkg/SimicsDxe/PlatformConfig.c  |  124 ++
 Platform/Intel/SimicsOpenBoardPkg/SimicsPei/Cmos.c |   57 +
 .../SimicsOpenBoardPkg/SimicsPei/FeatureControl.c  |  115 ++
 .../Intel/SimicsOpenBoardPkg/SimicsPei/MemDetect.c |  568 +++
 .../Intel/SimicsOpenBoardPkg/SimicsPei/Platform.c  |  630 
 .../SimicsVideoDxe/ComponentName.c |  205 +++
 .../SimicsOpenBoardPkg/SimicsVideoDxe/Driver.c | 1011 +
 .../SimicsVideoDxe/DriverSupportedEfiVersion.c |   15 +
 .../Intel/SimicsOpenBoardPkg/SimicsVideoDxe/Gop.c  |  416 ++
 .../SimicsOpenBoardPkg/SimicsVideoDxe/Initialize.c |  341 +
 .../SimicsOpenBoardPkg/SimicsVideoDxe/VbeShim.c|  302 
 .../SmbiosPlatformDxe/SmbiosPlatformDxe.c  |  148 ++
 .../Library/ResetSystemLib/ResetSystemLib.c|  137 ++
 .../Library/SmmSpiFlashCommonLib/SpiFlashCommon.c  |  194 +++
 .../SmmSpiFlashCommonLib/SpiFlashCommonSmmLib.c|   54 +
 .../LibraryPrivate/BasePchSpiCommonLib/SpiCommon.c |  935 
 .../SmmControl/RuntimeDxe/SmmControl2Dxe.c |  410 +
 Silicon/Intel/SimicsIch10Pkg/Spi/Smm/PchSpi.c  |  175 +++
 .../SimicsX58SktPkg/Smm/Access/SmmAccess2Dxe.c |  148 ++
 .../SimicsX58SktPkg/Smm/Access/SmmAccessPei.c  |  346 +
 .../SimicsX58SktPkg/Smm/Access/SmramInternal.c |  200 +++
 Maintainers.txt|   12 +
 .../SimicsOpenBoardPkg/AcpiTables/AcpiTables.inf   |   31 +
 .../Intel/SimicsOpenBoardPkg/AcpiTables/Dsdt.asl   |  821 ++
 .../MinPlatformAcpiTables/AcpiPlatform.h   |   45 +
 .../MinPlatformAcpiTables/AcpiPlatform.inf |  105 ++
 .../Intel/SimicsOpenBoardPkg/AcpiTables/Platform.h |   75 +
 .../BoardX58Ich10/DecomprScratchEnd.fdf.inc|   67 +
 .../BoardInitLib/PeiBoardInitPostMemLib.inf|   36 +
 .../Library/BoardInitLib/PeiBoardInitPreMemLib.inf |   39 +
 .../Library/BoardInitLib/PeiX58Ich10InitLib.h  |   16 +
 .../BoardX58Ich10/OpenBoardPkg.dsc |  233 +++
 .../BoardX58Ich10/OpenBoardPkg.fdf |  304 
 .../BoardX58Ich10/OpenBoardPkg.fdf.inc |   54 +
 .../BoardX58Ich10/OpenBoardPkgBuildOption.dsc  |   78 +
 .../BoardX58Ich10/OpenBoardPkgConfig.dsc   |   56 +
 .../BoardX58Ich10/OpenBoardPkgPcd.dsc

[edk2-devel] [edk2-platforms PATCH v5 6/7] SimicsOpenBoardPkg/BoardX58Ich10: Add board modules for QSP Build tip

[David Wei]

Add BoardX58ICH10 modules for QSP(Quick Start Platform) Build tip

Cc: Hao Wu 
Cc: Liming Gao 
Cc: Ankit Sinha 
Cc: Agyeman Prince 
Cc: Kubacki Michael A 
Cc: Nate DeSimone 
Cc: Michael D Kinney 

Signed-off-by: David Wei 
---
 .../Library/BoardInitLib/PeiBoardInitPostMemLib.c  |  44 +++
 .../Library/BoardInitLib/PeiBoardInitPreMemLib.c   | 110 
 .../Library/BoardInitLib/PeiX58Ich10Detect.c   |  26 ++
 .../BoardInitLib/PeiX58Ich10InitPostMemLib.c   |  34 +++
 .../BoardInitLib/PeiX58Ich10InitPreMemLib.c| 111 
 .../BoardX58Ich10/DecomprScratchEnd.fdf.inc|  67 +
 .../BoardInitLib/PeiBoardInitPostMemLib.inf|  36 +++
 .../Library/BoardInitLib/PeiBoardInitPreMemLib.inf |  39 +++
 .../Library/BoardInitLib/PeiX58Ich10InitLib.h  |  16 ++
 .../BoardX58Ich10/OpenBoardPkg.dsc | 233 
 .../BoardX58Ich10/OpenBoardPkg.fdf | 304 +
 .../BoardX58Ich10/OpenBoardPkg.fdf.inc |  54 
 .../BoardX58Ich10/OpenBoardPkgBuildOption.dsc  |  78 ++
 .../BoardX58Ich10/OpenBoardPkgConfig.dsc   |  56 
 .../BoardX58Ich10/OpenBoardPkgPcd.dsc  | 281 +++
 .../BoardX58Ich10/VarStore.fdf.inc |  53 
 .../BoardX58Ich10/build_config.cfg |  31 +++
 17 files changed, 1573 insertions(+)
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPostMemLib.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPreMemLib.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiX58Ich10Detect.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiX58Ich10InitPostMemLib.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiX58Ich10InitPreMemLib.c
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/DecomprScratchEnd.fdf.inc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPostMemLib.inf
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPreMemLib.inf
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiX58Ich10InitLib.h
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkg.dsc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkg.fdf
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkg.fdf.inc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgBuildOption.dsc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgConfig.dsc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/OpenBoardPkgPcd.dsc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/VarStore.fdf.inc
 create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/build_config.cfg

diff --git 
a/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPostMemLib.c
 
b/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPostMemLib.c
new file mode 100644
index 00..5ece8c6e34
--- /dev/null
+++ 
b/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPostMemLib.c
@@ -0,0 +1,44 @@
+/** @file
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardInitBeforeSiliconInit (
+  VOID
+  );
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardInitAfterSiliconInit (
+  VOID
+  );
+
+EFI_STATUS
+EFIAPI
+BoardInitBeforeSiliconInit (
+  VOID
+  )
+{
+  X58Ich10BoardInitBeforeSiliconInit ();
+  return EFI_SUCCESS;
+}
+
+EFI_STATUS
+EFIAPI
+BoardInitAfterSiliconInit (
+  VOID
+  )
+{
+  X58Ich10BoardInitAfterSiliconInit ();
+  return EFI_SUCCESS;
+}
diff --git 
a/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPreMemLib.c
 
b/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPreMemLib.c
new file mode 100644
index 00..d16e649d34
--- /dev/null
+++ 
b/Platform/Intel/SimicsOpenBoardPkg/BoardX58Ich10/Library/BoardInitLib/PeiBoardInitPreMemLib.c
@@ -0,0 +1,110 @@
+/** @file
+  Copyright (c) 2019 Intel Corporation. All rights reserved. 
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardDetect(
+  VOID
+  );
+
+EFI_BOOT_MODE
+EFIAPI
+X58Ich10BoardBootModeDetect (
+  VOID
+  );
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardDebugInit (
+  VOID
+  );
+
+EFI_STATUS
+EFIAPI
+X58Ich10BoardInitBeforeMemoryInit (
+  VOID
+  );
+
+EFI_STATUS
+EFIAPI

[edk2-devel] Upcoming Event: TianoCore Bug Triage - APAC / NAMO - Thu, 09/05/2019 5:00pm-5:30pm #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Bug Triage - APAC / NAMO

*When:* Thursday, 5 September 2019, 5:00pm to 5:30pm, (GMT-07:00) America/Los 
Angeles

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

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

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

*Description:*

Join Zoom Meeting

https://zoom.us/j/251103409 ( https://zoom.us/j/251103409 )

One tap mobile

+17207072699,,251103409# US

+16465588656,,251103409# US (New York)

Dial by your location

+1 720 707 2699 US

+1 646 558 8656 US (New York)

Meeting ID: 251 103 409

Find your local number: https://zoom.us/u/acEIbOAUyA ( 
https://zoom.us/u/acEIbOAUyA )

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

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

[edk2-devel] [PATCH] BaseTools:Ecc handle another copyright format

[Fan, ZhijuX]

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

Ecc can not handle the copyright format like

(C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP

This will cause Ecc to report wrong information.

This patch is going to handle this format

Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/Ecc/c.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Ecc/c.py b/BaseTools/Source/Python/Ecc/c.py
index a99b40a701..a30122a45f 100644
--- a/BaseTools/Source/Python/Ecc/c.py
+++ b/BaseTools/Source/Python/Ecc/c.py
@@ -2388,7 +2388,7 @@ def CheckFileHeaderDoxygenComments(FullFileName):
 PrintErrorMsg(ERROR_HEADER_CHECK_FILE, 'File header 
comment content should start with two spaces at each line', FileTable, ID)
 
 CommentLine = CommentLine.strip()
-if CommentLine.startswith('Copyright'):
+if CommentLine.startswith('Copyright') or ('Copyright' in 
CommentLine and CommentLine.lower().startswith('(c)')):
 NoCopyrightFlag = False
 if CommentLine.find('All rights reserved') == -1:
 for Copyright in EccGlobalData.gConfig.Copyright:
-- 
2.14.1.windows.1


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

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

<>

[edk2-devel] [edk2-rfc] UEFI terminal console keyboard type extend for Putty

[Gao, Zhichao]

Hi everyone,

Putty is a popular terminal console software in windows and it support various 
types of terminal keyboard type. I would like to add most of the type support. 
Here is the key map info. Hope to get comments. Here is the type and mapping 
table:
Putty function key map:
  +=+==+===+=+=+=+
  | | EFI  |   | | | |
  | | Scan |   | |  Normal | |
  |   KEY   | Code |  VT100+   | Xterm R6|  VT400  | Linux   |
  +=+==+===+=+=+=+
  | F1  | 0x0B | ESC O P   | NONE| ESC [ 1 1 ~ | ESC [ [ A   |
  | F2  | 0x0C | ESC O Q   | NONE| ESC [ 1 2 ~ | ESC [ [ B   |
  | F3  | 0x0D | ESC O R   | ESC O R | ESC [ 1 3 ~ | ESC [ [ C   |
  | F4  | 0x0E | ESC O S   | ESC O S | ESC [ 1 3 ~ | ESC [ [ D   |
  | F5  | 0x0F | ESC O T   | ESC [ 1 5 ~ | ESC [ 1 5 ~ | ESC [ [ E   |
  | F6  | 0x10 | ESC O U   | ESC [ 1 7 ~ | ESC [ 1 7 ~ | ESC [ 1 7 ~ |
  | F7  | 0x11 | ESC [ V   | ESC [ 1 8 ~ | ESC [ 1 8 ~ | ESC [ 1 8 ~ |
  | F8  | 0x12 | ESC [ W   | ESC [ 1 9 ~ | ESC [ 1 9 ~ | ESC [ 1 9 ~ |
  | F9  | 0x13 | ESC [ X   | ESC [ 2 0 ~ | ESC [ 2 0 ~ | ESC [ 2 0 ~ |
  | F10 | 0x14 | ESC [ Y   | ESC [ 2 1 ~ | ESC [ 2 1 ~ | ESC [ 2 1 ~ |
  | Escape  | 0x17 | ESC   | ESC | ESC | ESC |
  | F11 | 0x15 | ESC O Z   | ESC [ 2 3 ~ | ESC [ 2 3 ~ | ESC [ 1 3 ~ |
  | F12 | 0x16 | ESC O [   | ESC [ 2 4 ~ | ESC [ 2 4 ~ | ESC [ 1 4 ~ |
  +=+==+===+=+=+=+

For Xterm R6 F1 and F2, it is descripted as ESC+O+P and ESC+O+Q, but it doesn't 
work on UEFI shell. Same with the SCO mode. So I would ignore the unworkable 
key map.
Info refer to 
https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys

Thanks,
Zhichao


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

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

Re: [edk2-devel] [edk2-test] [PATCH 1/1] uefi-sct/SctPkg: fix typo 'supproted'

[Eric Jin]

Reviewed-by: Eric Jin 

-Original Message-
From: Heinrich Schuchardt  
Sent: Wednesday, September 4, 2019 4:37 PM
To: EDK II Development 
Cc: Jin, Eric ; Supreeth Venkatesh 
; Stephano Cetola 
; Heinrich Schuchardt 
Subject: [edk2-test] [PATCH 1/1] uefi-sct/SctPkg: fix typo 'supproted'

%s/supproted/supported/g

Signed-off-by: Heinrich Schuchardt 
---
 .../Protocol/PciIo/BlackBoxTest/PciIoBBTestStress.c  |  2 +-
 .../BlackBoxTest/SimpleNetworkBBTestConformance.c| 12 ++--
 .../BlackBoxTest/SimpleNetworkBBTestFunction.c   | 12 ++--
 .../BlackBoxTest/SimpleNetworkBBTestConformance.c| 12 ++--
 .../BlackBoxTest/SimpleNetworkBBTestFunction.c   | 12 ++--
 5 files changed, 25 insertions(+), 25 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/PciIo/BlackBoxTest/PciIoBBTestStress.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/PciIo/BlackBoxTest/PciIoBBTestStress.c
index 645e37f7..225724ae 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/PciIo/BlackBoxTest/PciIoBBTestStress.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/PciIo/BlackBoxTest/PciIoBBTestStress.c
@@ -999,7 +999,7 @@ GetAndSetBarAttributes_Stress (
StandardLib,

AssertionType,

gPciIoBBTestStressAssertionGuid021,

-   L"EFI_PCI_IO_PROTOCOL.GetBarAttributes - Bar supported 
attributes must in the range of Device supproted attributes",

+   L"EFI_PCI_IO_PROTOCOL.GetBarAttributes - Bar supported 
attributes must in the range of Device supported attributes",

L"%a:%d:Bar Supported - %lXh, Dev Supported - %lXh",

__FILE__,

(UINTN)__LINE__,

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
index 03a0d041..9d5bec18 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
@@ -885,7 +885,7 @@ BBTestStationAddressConformanceTest (
 StandardLib->RecordMessage(

StandardLib,

EFI_VERBOSE_LEVEL_QUIET,

-   L"StationAddress isn't supproted, Status - %r\n",

+   L"StationAddress isn't supported, Status - %r\n",

StatusBuf[0]

);

   } else {

@@ -911,7 +911,7 @@ BBTestStationAddressConformanceTest (
 StandardLib->RecordMessage(

StandardLib,

EFI_VERBOSE_LEVEL_QUIET,

-   L"StationAddress isn't supproted, Status - %r\n",

+   L"StationAddress isn't supported, Status - %r\n",

StatusBuf[1]

);

   } else {

@@ -1369,7 +1369,7 @@ BBTestNVDataConformanceTest (
 StandardLib->RecordMessage(

StandardLib,

EFI_VERBOSE_LEVEL_QUIET,

-   L"NvData isn't supproted, Status - %r\n",

+   L"NvData isn't supported, Status - %r\n",

StatusBuf[0]

);

   } else {

@@ -1394,7 +1394,7 @@ BBTestNVDataConformanceTest (
 StandardLib->RecordMessage(

StandardLib,

EFI_VERBOSE_LEVEL_QUIET,

-   L"NvData isn't supproted, Status - %r\n",

+   L"NvData isn't supported, Status - %r\n",

StatusBuf[1]

);

   } else {

@@ -1419,7 +1419,7 @@ BBTestNVDataConformanceTest (
 StandardLib->RecordMessage(

StandardLib,

EFI_VERBOSE_LEVEL_QUIET,

-   L"NvData isn't supproted, Status - %r\n",

+   L"NvData isn't supported, Status - %r\n",

StatusBuf[2]

);

   } else {

@@ -1444,7 +1444,7 @@ BBTestNVDataConformanceTest (
 StandardLib->RecordMessage(

StandardLib,

EFI_VERBOSE_LEVEL_QUIET,

-   L"NvData isn't supproted, Status - %r\n",

+   L"NvData isn't supported, Status - %r\n",

StatusBuf[3]

);

   } else {

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
index af520430..133ef8a9 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestFunction.c
@@ -1016,7 +1016,7 @@ BBTestStationAddressFunctionTest (
 

Re: [edk2-devel] [edk2-test] [PATCH 1/1] uefi-sct/SctPkg: assertion for UninstallMultipleProtocols

[Eric Jin]

Pushed at 30c4031acbdbdaddc824c67a27ac89a749447138

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Eric Jin
Sent: Tuesday, September 3, 2019 1:46 PM
To: Heinrich Schuchardt ; devel@edk2.groups.io
Cc: Supreeth Venkatesh ; Stephano Cetola 

Subject: Re: [edk2-devel] [edk2-test] [PATCH 1/1] uefi-sct/SctPkg: assertion 
for UninstallMultipleProtocols

Reviewed-by: Eric Jin 

-Original Message-
From: Heinrich Schuchardt  
Sent: Monday, September 2, 2019 4:44 PM
To: devel@edk2.groups.io
Cc: Jin, Eric ; Supreeth Venkatesh 
; Stephano Cetola 
; Heinrich Schuchardt 
Subject: [edk2-test] [PATCH 1/1] uefi-sct/SctPkg: assertion for 
UninstallMultipleProtocols

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

BS.UninstallMultipleProtocolInterfaces - InterfaceTestCheckpoint6 expects
UninstallMultipleProtocols() to return EFI_ACCESS_DENIED but the UEFI spec
has:

"If any errors are generated while the protocol interfaces are being 
uninstalled, then the protocols uninstalled prior to the error will be 
reinstalled with the boot service
EFI_BOOT_SERVICES.InstallProtocolInterface() and the status code 
EFI_INVALID_PARAMETER is returned."

So the SCT should check for EFI_INVALID_PARAMETER and not for EFI_ACCESS_DENIED.

Correct the assertion.

Signed-off-by: Heinrich Schuchardt 
---
 .../BlackBoxTest/ProtocolHandlerBBTestFunction_2.c  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ProtocolHandlerServices/BlackBoxTest/ProtocolHandlerBBTestFunction_2.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ProtocolHandlerServices/BlackBoxTest/ProtocolHandlerBBTestFunction_2.c
index c143e558..fe6146b2 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ProtocolHandlerServices/BlackBoxTest/ProtocolHandlerBBTestFunction_2.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/BootServices/ProtocolHandlerServ
+++ ices/BlackBoxTest/ProtocolHandlerBBTestFunction_2.c
@@ -12778,7 +12778,7 @@ 
BBTestUninstallMultipleProtocolInterfacesInterfaceTestCheckPoint6 (
 // // Step 1: check return status //-if (EFI_ACCESS_DENIED == 
Status) {+if (EFI_INVALID_PARAMETER == Status) {   AssertionType = 
EFI_TEST_ASSERTION_PASSED; } else {   AssertionType = 
EFI_TEST_ASSERTION_FAILED;-- 
2.20.1





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

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

Re: [edk2-devel] [edk2-test] [PATCH] uefi-sct/SctPkg: StrUpr() test for cyrillic letters

[Eric Jin]

Pushed at cce43fc3ae30d343964fe02f09242ec8604eb44b

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Eric Jin
Sent: Tuesday, September 3, 2019 3:43 PM
To: Heinrich Schuchardt ; devel@edk2.groups.io
Cc: Supreeth Venkatesh ; Stephano Cetola 

Subject: Re: [edk2-devel] [edk2-test] [PATCH] uefi-sct/SctPkg: StrUpr() test 
for cyrillic letters

Reviewed-by: Eric Jin 

-Original Message-
From: Heinrich Schuchardt  
Sent: Monday, September 2, 2019 5:57 PM
To: devel@edk2.groups.io
Cc: Jin, Eric ; Supreeth Venkatesh 
; Stephano Cetola 
; Heinrich Schuchardt 
Subject: [edk2-test] [PATCH] uefi-sct/SctPkg: StrUpr() test for cyrillic letters

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

The test of StrUpr() of the UnicodeCollationProtocol2 uses the following test 
string:

L"\x30\x50[A-D]\x40\x20\x30\x50f\x40\x20"

This string contains the Unicode code point 0x050f (CYRILLIC SMALL LETTER KOMI 
TJE). The correct conversion to upper case is 0x050e (CYRILLIC CAPITAL LETTER 
KOMI TJE).

The SCT code uses function ToUpper() which is not a part of the SCT code itself 
for the verification. As the EDK2 implementation of StrUpr() does not support 
upper-casing cyrillic letters it does not convert 0x050f but leaves it 
unchanged.

This leads to rejecting the output of UEFI implementations fully supporting 
cyrillic letters.

Replace cyrillic 0x50f by 0x50 ('P') to avoid false positives.

Signed-off-by: Heinrich Schuchardt 
---
 .../BlackBoxTest/UnicodeCollation2BBTestFunction.c  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/UnicodeCollation2/BlackBoxTest/UnicodeCollation2BBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/UnicodeCollation2/BlackBoxTest/UnicodeCollation2BBTestFunction.c
index a8652a5c..653b263a 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/UnicodeCollation2/BlackBoxTest/UnicodeCollation2BBTestFunction.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/UnicodeCollation2/Black
+++ BoxTest/UnicodeCollation2BBTestFunction.c
@@ -451,7 +451,7 @@ BBTestStrUprFunctionAutoTest (
   CHAR16   *TestData[] ={  

L"\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5Ax61\x62\x7D\x7E",
  
L"\x30\x50[abcdzyxw!)(@#*]\x40\x20\x30\x50\ab\x40\x20",-
 L"\x30\x50[A-D]\x40\x20\x30\x50f\x40\x20",+
 L"\x30\x50[A-D]\x40\x20\x30\x50\x40\x20",  
L"" 
}; -- 
2.20.1





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

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

Re: [edk2-devel] [edk2-test] [PATCH 1/1] uefi-sct/SctPkg: fix typo 'Remained test cases'

[Eric Jin]

Pushed at a916582a12c414775a87c65718b7ebb0756f3fb5

-Original Message-
From: Heinrich Schuchardt  
Sent: Wednesday, September 4, 2019 2:37 PM
To: Jin, Eric ; devel@edk2.groups.io
Cc: Supreeth Venkatesh ; Stephano Cetola 

Subject: Re: [edk2-test] [PATCH 1/1] uefi-sct/SctPkg: fix typo 'Remained test 
cases'

On 9/4/19 4:27 AM, Jin, Eric wrote:
> Hi Heinrich Schuchardt,
>
> According to 
> https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-F
> ormat The statement "Contributed-under:..." need be removed.
> With that: Reviewed-by: Eric Jin 
>
> If no object, I will help to push with this change by end of this week.
>

If that contributed-under is not needed anymore, that is great. Please, feel 
free to remove it when pushing.

Best regards

Heinrich

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

View/Reply Online (#46959): https://edk2.groups.io/g/devel/message/46959
Mute This Topic: https://groups.io/mt/33124786/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] UefiCpuPkg: support single EFI_PEI_CORE_FV_LOCATION_PPI in PpiList

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: Chiu, Chasel
> Sent: Thursday, September 5, 2019 12:27 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Laszlo
> Ersek 
> Subject: [PATCH v2] UefiCpuPkg: support single
> EFI_PEI_CORE_FV_LOCATION_PPI in PpiList
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2153
> 
> Current logic will skip searching EFI_PEI_CORE_FV_LOCATION_PPI when the
> PPI in PpiList having EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag, but
> platform may pass single PPI in PpiList that should be supported.
> 
> Changed the logic to verify PpiList first before checking
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag.
> 
> Test: Verified both single EFI_PEI_CORE_FV_LOCATION_PPI and multiple
>   PPIs in PpiList cases and both can boot with the PeiCore
>   specified by EFI_PEI_CORE_FV_LOCATION_PPI.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Signed-off-by: Chasel Chiu 
> ---
>  UefiCpuPkg/SecCore/SecMain.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/UefiCpuPkg/SecCore/SecMain.c b/UefiCpuPkg/SecCore/SecMain.c
> index 66c952b897..5d5e7f17dc 100644
> --- a/UefiCpuPkg/SecCore/SecMain.c
> +++ b/UefiCpuPkg/SecCore/SecMain.c
> @@ -238,9 +238,8 @@ SecStartupPhase2(
>// is enabled.
>//
>if (PpiList != NULL) {
> -for (Index = 0;
> -  (PpiList[Index].Flags & EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) !=
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST;
> -  Index++) {
> +Index = 0;
> +do {
>if (CompareGuid (PpiList[Index].Guid, ) &&
>(((EFI_PEI_CORE_FV_LOCATION_PPI *) PpiList[Index].Ppi)-
> >PeiCoreFvLocation != 0)
>   ) {
> @@ -256,12 +255,12 @@ SecStartupPhase2(
>break;
>  } else {
>//
> -  // PeiCore not found
> +  // Invalid PeiCore FV provided by platform
>//
>CpuDeadLoop ();
>  }
>}
> -}
> +} while ((PpiList[Index++].Flags &
> + EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) !=
> + EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST);
>}
>//
>// If EFI_PEI_CORE_FV_LOCATION_PPI not found, try to locate PeiCore from
> BFV.
> --
> 2.13.3.windows.1


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

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

[edk2-devel] [PATCH v2] MinPlatformPkg/SecFspWrapperPlatformSecLib: Change TopOfTemporaryRam type

[Zhang, Shenglei]

Update the type of TopOfTemporaryRam from UINT32 to UINTN.
This change is intended to support X64 build scenarios.
The original code(line 64) may cast the overfloewed result
produced by "(TopOfTemporaryRam - sizeof (UINT32))"from
32bit to 64bit.

Cc: Michael Kubacki 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Shenglei Zhang 
---
v2: As TopOfTemporaryRam is defined as UINTN in v2, remove
all the related casting operations which exist in v1 patch. 

 .../SecFspWrapperPlatformSecLib/SecGetPerformance.c   | 8 
 .../SecFspWrapperPlatformSecLib/SecPlatformInformation.c  | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecGetPerformance.c
 
b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecGetPerformance.c
index c4eeb2b1..8535ae04 100644
--- 
a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecGetPerformance.c
+++ 
b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecGetPerformance.c
@@ -41,7 +41,7 @@ SecGetPerformance (
 {
   UINT32  Size;
   UINT32  Count;
-  UINT32  TopOfTemporaryRam;
+  UINTN   TopOfTemporaryRam;
   UINT64  Ticker;
   VOID*TopOfTemporaryRamPpi;
   EFI_STATUS  Status;
@@ -77,12 +77,12 @@ SecGetPerformance (
   // |  TSC[31:00]  |
   // |--|
   //
-  TopOfTemporaryRam = (UINT32)(UINTN)TopOfTemporaryRamPpi - sizeof(UINT32);
+  TopOfTemporaryRam = (UINTN)TopOfTemporaryRamPpi - sizeof(UINT32);
   TopOfTemporaryRam -= sizeof(UINT32) * 2;
-  Count = *(UINT32 *) (UINTN) (TopOfTemporaryRam - sizeof 
(UINT32));
+  Count = *(UINT32 *)(TopOfTemporaryRam - sizeof (UINT32));
   Size  = Count * sizeof (UINT32);
 
-  Ticker = *(UINT64 *) (UINTN) (TopOfTemporaryRam - sizeof (UINT32) - Size - 
sizeof (UINT32) * 2);
+  Ticker = *(UINT64 *) (TopOfTemporaryRam - sizeof (UINT32) - Size - sizeof 
(UINT32) * 2);
   Performance->ResetEnd = GetTimeInNanoSecond (Ticker);
 
   return EFI_SUCCESS;
diff --git 
a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecPlatformInformation.c
 
b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecPlatformInformation.c
index 5b94ed2b..ade36ab5 100644
--- 
a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecPlatformInformation.c
+++ 
b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatformSecLib/SecPlatformInformation.c
@@ -36,7 +36,7 @@ SecPlatformInformation (
   UINT32  *Bist;
   UINT32  Size;
   UINT32  Count;
-  UINT32  TopOfTemporaryRam;
+  UINTN   TopOfTemporaryRam;
   VOID*TopOfTemporaryRamPpi;
   EFI_STATUS  Status;
 
@@ -59,9 +59,9 @@ SecPlatformInformation (
   // This routine copies the BIST information to the buffer pointed by
   // PlatformInformationRecord for output.
   //
-  TopOfTemporaryRam = (UINT32)(UINTN)TopOfTemporaryRamPpi - sizeof (UINT32);
+  TopOfTemporaryRam = (UINTN)TopOfTemporaryRamPpi - sizeof (UINT32);
   TopOfTemporaryRam -= sizeof(UINT32) * 2;
-  Count = *((UINT32 *)(UINTN) (TopOfTemporaryRam - sizeof 
(UINT32)));
+  Count = *((UINT32 *)(TopOfTemporaryRam - sizeof (UINT32)));
   Size  = Count * sizeof (IA32_HANDOFF_STATUS);
 
   if ((*StructureSize) < (UINT64) Size) {
-- 
2.18.0.windows.1


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

View/Reply Online (#46874): https://edk2.groups.io/g/devel/message/46874
Mute This Topic: https://groups.io/mt/33150686/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: Remove gEfiFormBrowserExProtocolGuid

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: Bi, Dandan
> Sent: Thursday, September 5, 2019 12:54 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Gao, Liming 
> Subject: [patch] MdeModulePkg: Remove gEfiFormBrowserExProtocolGuid
> 
> gEfiFormBrowserExProtocolGuid is not used in edk2, and it can be replaced by
> gEdkiiFormBrowserExProtocolGuid.
> So remove gEfiFormBrowserExProtocolGuid to avoid confusion.
> 
> Cc: Eric Dong 
> Cc: Liming Gao 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2145
> Signed-off-by: Dandan Bi 
> ---
>  MdeModulePkg/Include/Protocol/FormBrowserEx.h | 1 -
>  MdeModulePkg/MdeModulePkg.dec | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Include/Protocol/FormBrowserEx.h
> b/MdeModulePkg/Include/Protocol/FormBrowserEx.h
> index c36aa6bdf1..e7e7cd18ab 100644
> --- a/MdeModulePkg/Include/Protocol/FormBrowserEx.h
> +++ b/MdeModulePkg/Include/Protocol/FormBrowserEx.h
> @@ -141,10 +141,9 @@ struct
> _EDKII_FORM_BROWSER_EXTENSION_PROTOCOL {
>REGISTER_HOT_KEY   RegisterHotKey;
>REGISTER_EXIT_HANDLER  RegiserExitHandler;
>SAVE_REMINDER  SaveReminder;
>  };
> 
> -extern EFI_GUID gEfiFormBrowserExProtocolGuid;  extern EFI_GUID
> gEdkiiFormBrowserExProtocolGuid;
> 
>  #endif
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec index 19935c88fa..ab29a279b1 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -529,11 +529,10 @@ [Protocols]
> 
>## Include/Protocol/LockBox.h
>gEfiLockBoxProtocolGuid= { 0xbd445d79, 0xb7ad, 0x4f04, { 0x9a, 
> 0xd8,
> 0x29, 0xbd, 0x20, 0x40, 0xeb, 0x3c }}
> 
>## Include/Protocol/FormBrowserEx.h
> -  gEfiFormBrowserExProtocolGuid = { 0x1f73b18d, 0x4630, 0x43c1, { 0xa1,
> 0xde, 0x6f, 0x80, 0x85, 0x5d, 0x7d, 0xa4 } }
>gEdkiiFormBrowserExProtocolGuid = { 0x1f73b18d, 0x4630, 0x43c1, { 0xa1,
> 0xde, 0x6f, 0x80, 0x85, 0x5d, 0x7d, 0xa4 } }
> 
>## Include/Protocol/EbcVmTest.h
>gEfiEbcVmTestProtocolGuid = { 0xAAEACCFD, 0xF27B, 0x4C17, { 0xB6, 0x10,
> 0x75, 0xCA, 0x1F, 0x2D, 0xFB, 0x52 } }
> 
> --
> 2.18.0.windows.1


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

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

Re: [edk2-devel] [patch 2/3] MdeModulePkg: Unload image on EFI_SECURITY_VIOLATION

[Dandan Bi]

> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, September 5, 2019 1:38 PM
> To: Bi, Dandan ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Ni, Ray ; Gao,
> Liming ; Laszlo Ersek 
> Subject: RE: [patch 2/3] MdeModulePkg: Unload image on
> EFI_SECURITY_VIOLATION
> 
> > -Original Message-
> > From: Bi, Dandan
> > Sent: Wednesday, September 04, 2019 4:26 PM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Gao, Liming; Laszlo Ersek
> > Subject: [patch 2/3] MdeModulePkg: Unload image on
> > EFI_SECURITY_VIOLATION
> >
> > For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> > the Image was loaded and an ImageHandle was created with a valid
> > EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right
> now.
> > This follows UEFI Spec.
> >
> > But if the caller of LoadImage() doesn't have the option to defer the
> > execution of an image, we can not treat EFI_SECURITY_VIOLATION like
> > any other LoadImage() error, we should unload image for the
> > EFI_SECURITY_VIOLATION to avoid resource leak.
> >
> > This patch is to do error handling for EFI_SECURITY_VIOLATION
> > explicitly for the callers in MdeModulePkg which don't have the policy
> > to defer the execution of the image.
> >
> > Cc: Jian J Wang 
> > Cc: Hao A Wu 
> > Cc: Ray Ni 
> > Cc: Liming Gao 
> > Cc: Laszlo Ersek 
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> > Signed-off-by: Dandan Bi 
> > ---
> >  MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c  |  9
> > +
> >  MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c |  9
> > +
> >  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c  |  9
> +
> >  .../Library/UefiBootManagerLib/BmLoadOption.c | 11 ++-
> >  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c  | 11
> > ++-
> >  .../PlatformDriOverrideDxe/PlatDriOverrideLib.c   | 11 ++-
> 
> 
> Hello,
> 
> Could you help to provide the information on what tests have been
> performed for this patch? Thanks.

Previously I only did the VS build since I think these are just the enhancement 
for error handling.
For these callers,  they don't have the real use case to defer the execution of 
the image.
EFI_SECURITY_VIOLATION  for them just like other errors, the only difference is 
that with EFI_SECURITY_VIOLATION  retval, we need to call UnloadImage () to 
free resource.

Hao and other feature owners, do you have any suggestion for the tests?


> 
> Also, since the patch is touching multiple features (PCI, Capsule, BM and
> driver override), I would suggest to break this patch into multiple ones so
> that it will be more clear to evaluate the impact for each change.
> 
I will separate the patch into module level and send the new patch series.


Thanks,
Dandan

> Best Regards,
> Hao Wu
> 
> 
> >  6 files changed, 57 insertions(+), 3 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
> > b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
> > index c994ed5fe3..1a8d9811b0 100644
> > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
> > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
> > @@ -726,10 +726,19 @@ ProcessOpRomImage (
> >  Buffer,
> >  BufferSize,
> >  
> >  );
> >  if (EFI_ERROR (Status)) {
> > +  //
> > +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded and
> > + an
> > ImageHandle was created
> > +  // with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can
> > + not
> > be started right now.
> > +  // If the caller doesn't have the option to defer the execution
> > + of an
> > image, we should
> > +  // unload image for the EFI_SECURITY_VIOLATION to avoid resource
> leak.
> > +  //
> > +  if (Status == EFI_SECURITY_VIOLATION) {
> > +gBS->UnloadImage (ImageHandle);
> > +  }
> >//
> >// Record the Option ROM Image device path when LoadImage fails.
> >// PciOverride.GetDriver() will try to look for the Image
> > Handle using the device path later.
> >//
> >AddDriver (PciDevice, NULL, PciOptionRomImageDevicePath); diff
> > --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> > b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> > index 95aa9de087..74c00ecf9e 100644
> > --- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> > +++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> > @@ -1028,10 +1028,19 @@ StartFmpImage (
> >ImageSize,
> >
> >);
> >DEBUG((DEBUG_INFO, "FmpCapsule: LoadImage - %r\n", Status));
> >if (EFI_ERROR(Status)) {
> > +//
> > +// With EFI_SECURITY_VIOLATION retval, the Image was loaded and
> > + an
> > ImageHandle was created
> > +// with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not
> > + be
> > started right now.
> > +// 

Re: [edk2-devel] [patch 2/3] MdeModulePkg: Unload image on EFI_SECURITY_VIOLATION

[Wu, Hao A]

> -Original Message-
> From: Bi, Dandan
> Sent: Thursday, September 05, 2019 2:24 PM
> To: Wu, Hao A; devel@edk2.groups.io
> Cc: Wang, Jian J; Ni, Ray; Gao, Liming; Laszlo Ersek; Bi, Dandan
> Subject: RE: [patch 2/3] MdeModulePkg: Unload image on
> EFI_SECURITY_VIOLATION
> 
> > -Original Message-
> > From: Wu, Hao A
> > Sent: Thursday, September 5, 2019 1:38 PM
> > To: Bi, Dandan ; devel@edk2.groups.io
> > Cc: Wang, Jian J ; Ni, Ray ; Gao,
> > Liming ; Laszlo Ersek 
> > Subject: RE: [patch 2/3] MdeModulePkg: Unload image on
> > EFI_SECURITY_VIOLATION
> >
> > > -Original Message-
> > > From: Bi, Dandan
> > > Sent: Wednesday, September 04, 2019 4:26 PM
> > > To: devel@edk2.groups.io
> > > Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Gao, Liming; Laszlo Ersek
> > > Subject: [patch 2/3] MdeModulePkg: Unload image on
> > > EFI_SECURITY_VIOLATION
> > >
> > > For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
> > > the Image was loaded and an ImageHandle was created with a valid
> > > EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right
> > now.
> > > This follows UEFI Spec.
> > >
> > > But if the caller of LoadImage() doesn't have the option to defer the
> > > execution of an image, we can not treat EFI_SECURITY_VIOLATION like
> > > any other LoadImage() error, we should unload image for the
> > > EFI_SECURITY_VIOLATION to avoid resource leak.
> > >
> > > This patch is to do error handling for EFI_SECURITY_VIOLATION
> > > explicitly for the callers in MdeModulePkg which don't have the policy
> > > to defer the execution of the image.
> > >
> > > Cc: Jian J Wang 
> > > Cc: Hao A Wu 
> > > Cc: Ray Ni 
> > > Cc: Liming Gao 
> > > Cc: Laszlo Ersek 
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
> > > Signed-off-by: Dandan Bi 
> > > ---
> > >  MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c  |  9
> > > +
> > >  MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c |  9
> > > +
> > >  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c  |  9
> > +
> > >  .../Library/UefiBootManagerLib/BmLoadOption.c | 11 ++-
> > >  MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c  | 11
> > > ++-
> > >  .../PlatformDriOverrideDxe/PlatDriOverrideLib.c   | 11 ++-
> >
> >
> > Hello,
> >
> > Could you help to provide the information on what tests have been
> > performed for this patch? Thanks.
> 
> Previously I only did the VS build since I think these are just the
> enhancement for error handling.
> For these callers,  they don't have the real use case to defer the execution 
> of
> the image.
> EFI_SECURITY_VIOLATION  for them just like other errors, the only
> difference is that with EFI_SECURITY_VIOLATION  retval, we need to call
> UnloadImage () to free resource.
> 
> Hao and other feature owners, do you have any suggestion for the tests?

Hello,

For the PciBusDxe change, I think 'PciOptionRomImageDevicePath', which should
be the loaded image device path, will still be used by AddDriver() when
EFI_SECURITY_VIOLATION is returned by LoadImage():

  //
  // Record the Option ROM Image device path when LoadImage fails.
  // PciOverride.GetDriver() will try to look for the Image Handle using the 
device path later.
  //
  AddDriver (PciDevice, NULL, PciOptionRomImageDevicePath);

Later in GetDriver(), the device path will be used to locate the image handle:

  if (Override->DriverImageHandle == NULL) {
Override->DriverImageHandle = LocateImageHandle (Override->DriverImagePath);
  }

Ray, could you help to share your thoughts on this one? Thanks.


For the DxeCapsuleLibFmp & PlatformDriOverrideDxe changes, I am okay with only
the build test. It looks to me that both of the cases will not attempt to
consume the loaded image later if EFI_SECURITY_VIOLATION is returned.

For the UefiBootManagerLib changes, I will leave it to Ray and Zhichao.

Best Regards,
Hao Wu


> 
> 
> >
> > Also, since the patch is touching multiple features (PCI, Capsule, BM and
> > driver override), I would suggest to break this patch into multiple ones so
> > that it will be more clear to evaluate the impact for each change.
> >
> I will separate the patch into module level and send the new patch series.
> 
> 
> Thanks,
> Dandan
> 
> > Best Regards,
> > Hao Wu
> >
> >
> > >  6 files changed, 57 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
> > > b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
> > > index c994ed5fe3..1a8d9811b0 100644
> > > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
> > > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
> > > @@ -726,10 +726,19 @@ ProcessOpRomImage (
> > >  Buffer,
> > >  BufferSize,
> > >  
> > >  );
> > >  if (EFI_ERROR (Status)) {
> > > +  //
> > > +  // With EFI_SECURITY_VIOLATION retval, the Image was loaded 

[edk2-devel] [edk2-platforms][PATCH] AdvancedFeaturePkg/S3Advanced Add S3 Advanced PEIM driver

[Marc W Chen]

Implement a S3 Advanced PEIM driver for supporting S3 feature.
So far this driver only install EFI_PEI_MM_ACCESS_PPI for S3 resume case.

Change-Id: Ie5841047be350f411650ad30f16d210b98197dc4
Cc: Michael Kubacki 
Cc: Sai Chaganty 
Cc: Liming Gao 
Signed-off-by: Marc Chen 
---
 .../S3Advanced/S3AdvancedPei/S3AdvancedPei.c   | 36 ++
 .../S3Advanced/S3AdvancedPei/S3AdvancedPei.inf | 31 +++
 2 files changed, 67 insertions(+)
 create mode 100644 
Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
 create mode 100644 
Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf

diff --git 
a/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c 
b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
new file mode 100644
index ..9ce4cc6a
--- /dev/null
+++ b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.c
@@ -0,0 +1,36 @@
+/** @file
+  Source code file for S3 Advanced PEI module
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+
+/**
+  S3 Advanced PEI module entry point
+
+  @param[in]  FileHandle   Not used.
+  @param[in]  PeiServices  General purpose services available to every 
PEIM.
+
+  @retval EFI_SUCCESS  The function completes successfully
+  @retval EFI_OUT_OF_RESOURCES Insufficient resources to create database
+**/
+EFI_STATUS
+EFIAPI
+S3AdvancedEntryPoint (
+  IN   EFI_PEI_FILE_HANDLE  FileHandle,
+  IN CONST EFI_PEI_SERVICES **PeiServices
+  )
+{
+  EFI_STATUS Status;
+
+  //
+  // Install EFI_PEI_MM_ACCESS_PPI for S3 resume case
+  //
+  Status = PeiInstallSmmAccessPpi ();
+
+  return Status;
+}
diff --git 
a/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf 
b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf
new file mode 100644
index ..9b654bfa
--- /dev/null
+++ 
b/Platform/Intel/AdvancedFeaturePkg/S3Advanced/S3AdvancedPei/S3AdvancedPei.inf
@@ -0,0 +1,31 @@
+### @file
+# Component information file for the S3 Advanced PEI module.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+###
+
+[Defines]
+  INF_VERSION= 0x00010017
+  BASE_NAME  = S3AdvancedPei
+  FILE_GUID  = 8683EFB2-FDE1-4AFF-B2DB-E96449FDD4E9
+  VERSION_STRING = 1.0
+  MODULE_TYPE= PEIM
+  ENTRY_POINT= S3AdvancedEntryPoint
+
+[LibraryClasses]
+  PeimEntryPoint
+  PeiServicesLib
+  SmmAccessLib
+
+[Packages]
+  IntelSiliconPkg/IntelSiliconPkg.dec
+  MdePkg/MdePkg.dec
+
+[Sources]
+  S3AdvancedPei.c
+
+[Depex]
+  TRUE
-- 
2.16.2.windows.1


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

View/Reply Online (#46888): https://edk2.groups.io/g/devel/message/46888
Mute This Topic: https://groups.io/mt/33151404/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] UefiCpuPkg: support single EFI_PEI_CORE_FV_LOCATION_PPI in PpiList

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, September 4, 2019 11:15 PM
> To: Chiu, Chasel ; devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek 
> Subject: RE: [PATCH v2] UefiCpuPkg: support single 
> EFI_PEI_CORE_FV_LOCATION_PPI in PpiList
> 
> Reviewed-by: Eric Dong 
> 
> > -Original Message-
> > From: Chiu, Chasel
> > Sent: Thursday, September 5, 2019 12:27 PM
> > To: devel@edk2.groups.io
> > Cc: Dong, Eric ; Ni, Ray ; Laszlo
> > Ersek 
> > Subject: [PATCH v2] UefiCpuPkg: support single
> > EFI_PEI_CORE_FV_LOCATION_PPI in PpiList
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2153
> >
> > Current logic will skip searching EFI_PEI_CORE_FV_LOCATION_PPI when the
> > PPI in PpiList having EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag, but
> > platform may pass single PPI in PpiList that should be supported.
> >
> > Changed the logic to verify PpiList first before checking
> > EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag.
> >
> > Test: Verified both single EFI_PEI_CORE_FV_LOCATION_PPI and multiple
> >   PPIs in PpiList cases and both can boot with the PeiCore
> >   specified by EFI_PEI_CORE_FV_LOCATION_PPI.
> >
> > Cc: Eric Dong 
> > Cc: Ray Ni 
> > Cc: Laszlo Ersek 
> > Signed-off-by: Chasel Chiu 
> > ---
> >  UefiCpuPkg/SecCore/SecMain.c | 9 -
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/UefiCpuPkg/SecCore/SecMain.c b/UefiCpuPkg/SecCore/SecMain.c
> > index 66c952b897..5d5e7f17dc 100644
> > --- a/UefiCpuPkg/SecCore/SecMain.c
> > +++ b/UefiCpuPkg/SecCore/SecMain.c
> > @@ -238,9 +238,8 @@ SecStartupPhase2(
> >// is enabled.
> >//
> >if (PpiList != NULL) {
> > -for (Index = 0;
> > -  (PpiList[Index].Flags & EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) !=
> > EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST;
> > -  Index++) {
> > +Index = 0;
> > +do {
> >if (CompareGuid (PpiList[Index].Guid, ) 
> > &&
> >(((EFI_PEI_CORE_FV_LOCATION_PPI *) PpiList[Index].Ppi)-
> > >PeiCoreFvLocation != 0)
> >   ) {
> > @@ -256,12 +255,12 @@ SecStartupPhase2(
> >break;
> >  } else {
> >//
> > -  // PeiCore not found
> > +  // Invalid PeiCore FV provided by platform
> >//
> >CpuDeadLoop ();
> >  }
> >}
> > -}
> > +} while ((PpiList[Index++].Flags &
> > + EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) !=
> > + EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST);
> >}
> >//
> >// If EFI_PEI_CORE_FV_LOCATION_PPI not found, try to locate PeiCore from
> > BFV.
> > --
> > 2.13.3.windows.1


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

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

[edk2-devel] [PATCH 3/4] Platform: Intel: Remove unused packages and clean up

[Loh, Tien Hock]

From: "Tien Hock, Loh" 

Remove some unused packages in Stratix 10 packages, clean up some commented
out codes

Signed-off-by: "Tien Hock, Loh" 
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
---
 Platform/Intel/Stratix10/Stratix10SoCPkg.dsc | 4 
 Platform/Intel/Stratix10/Stratix10SoCPkg.fdf | 1 -
 2 files changed, 5 deletions(-)

diff --git a/Platform/Intel/Stratix10/Stratix10SoCPkg.dsc 
b/Platform/Intel/Stratix10/Stratix10SoCPkg.dsc
index 17d0c5baadc6..643ce625c563 100755
--- a/Platform/Intel/Stratix10/Stratix10SoCPkg.dsc
+++ b/Platform/Intel/Stratix10/Stratix10SoCPkg.dsc
@@ -103,7 +103,6 @@ [PcdsFixedAtBuild.common]
   #  DEBUG_GCD   0x0010  // Global Coherency Database changes
   #  DEBUG_CACHE 0x0020  // Memory range cachability changes
   #  DEBUG_ERROR 0x8000  // Error
-#  gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x803010CF
   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x800F
 
   gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x00
@@ -251,7 +250,6 @@ [LibraryClasses.common]
   PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
 
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
-#  
GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
 
   #
@@ -414,7 +412,6 @@ [Components.common]
   #
   MdeModulePkg/Core/Dxe/DxeMain.inf {
 
-  #PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   
NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32GuidedSectionExtractLib.inf
   }
 
@@ -475,7 +472,6 @@ [Components.common]
   
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
   
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
   
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
-#  
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
   
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
diff --git a/Platform/Intel/Stratix10/Stratix10SoCPkg.fdf 
b/Platform/Intel/Stratix10/Stratix10SoCPkg.fdf
index 2c4e5ee887ca..1ac2da28addf 100755
--- a/Platform/Intel/Stratix10/Stratix10SoCPkg.fdf
+++ b/Platform/Intel/Stratix10/Stratix10SoCPkg.fdf
@@ -140,7 +140,6 @@ [FV.FV_DXE]
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
   INF MdeModulePkg/Application/UiApp/UiApp.inf
-  INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
 
   # FV Filesystem
-- 
2.19.0


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

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

[edk2-devel] [PATCH 0/4] Update Stratix 10 platform support

[Loh, Tien Hock]

From: "Tien Hock, Loh" 

Update maintainer list, SPDX license, remove unused packages
and remove hardcoded UART clock

Tien Hock, Loh (4):
  Platform: Intel: Update maintainers list for Stratix 10 device
  Platform: Intel: Update license to SPDX
  Platform: Intel: Remove unused packages and clean up
  Platform: Intel: Remove hardcoded Stratix 10 UART clock

 Platform/Intel/Stratix10/Stratix10SoCPkg.dec  |   3 +-
 Platform/Intel/Stratix10/Stratix10SoCPkg.dsc  |  15 +-
 Platform/Intel/Stratix10/Stratix10SoCPkg.fdf  |   1 -
 .../IntelPlatformDxe/IntelPlatformDxe.inf |  22 ++-
 .../IntelPlatformLib/IntelPlatformLib.inf |  22 +--
 .../PlatformHookLib/PlatformHookLib.inf   |  41 ++
 .../S10ClockManager/S10ClockManager.inf   |  34 +
 .../Library/S10ClockManager/S10ClockManager.h |  48 +++
 .../IntelPlatformDxe/IntelPlatformDxe.c   |  22 ++-
 .../Library/IntelPlatformLib/Stratix10Mmu.c   |  20 +--
 .../IntelPlatformLib/Stratix10PlatformLib.c   |  19 +--
 .../Library/PlatformHookLib/PlatformHookLib.c |  43 ++
 .../Library/S10ClockManager/S10ClockManager.c | 133 ++
 Maintainers.txt   |   5 +
 .../AArch64/ArmPlatformHelper.S   |   8 +-
 15 files changed, 353 insertions(+), 83 deletions(-)
 create mode 100644 
Platform/Intel/Stratix10/Library/PlatformHookLib/PlatformHookLib.inf
 create mode 100644 
Platform/Intel/Stratix10/Library/S10ClockManager/S10ClockManager.inf
 create mode 100644 
Platform/Intel/Stratix10/Include/Library/S10ClockManager/S10ClockManager.h
 create mode 100644 
Platform/Intel/Stratix10/Library/PlatformHookLib/PlatformHookLib.c
 create mode 100644 
Platform/Intel/Stratix10/Library/S10ClockManager/S10ClockManager.c

-- 
2.19.0


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

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

[edk2-devel] [PATCH 1/4] Platform: Intel: Update maintainers list for Stratix 10 device

[Loh, Tien Hock]

From: "Tien Hock, Loh" 

Update maintainers list for Stratix 10 devices

Signed-off-by: "Tien Hock, Loh" 
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
---
 Maintainers.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 876ae5612ad8..47d58ffa0b2c 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -98,6 +98,11 @@ M: Shifei A Lu 
 M: Xiaohu Zhou 
 M: Isaac W Oram 
 
+Platform/Intel/Stratix10SocPkg
+M: Leif Lindholm 
+M: Michael D Kinney 
+R: Tien Hock Loh 
+
 Platform/Intel/Tools
 M: Bob Feng 
 M: Liming Gao 
-- 
2.19.0


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

View/Reply Online (#46878): https://edk2.groups.io/g/devel/message/46878
Mute This Topic: https://groups.io/mt/33151030/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] BaseTools: Fixed issue for IgnoreAutoGen

[Bob Feng]

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

This patch is to improve build -u option to re-use
GlobalVar__.bin file which is
introduced by multiple-process-autogen feature.

Cc: Liming Gao 
Cc: Steven Shi 
Signed-off-by: Bob Feng 
---
 .../Source/Python/AutoGen/AutoGenWorker.py|   2 +-
 .../Source/Python/AutoGen/ModuleAutoGen.py|   4 +-
 .../Python/AutoGen/ModuleAutoGenHelper.py |  29 ++
 .../Source/Python/AutoGen/PlatformAutoGen.py  |   2 +
 .../Source/Python/AutoGen/WorkspaceAutoGen.py |   1 -
 BaseTools/Source/Python/build/build.py| 355 +++---
 6 files changed, 255 insertions(+), 138 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py 
b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
index 2e68538b1cb4..f488ae9d5f80 100755
--- a/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGenWorker.py
@@ -236,11 +236,11 @@ class AutoGenWorkerInProcess(mp.Process):
 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
+continue
 
 Ma.CreateCodeFile(False)
 
Ma.CreateMakeFile(False,GenFfsList=FfsCmd.get((Ma.MetaFile.File, Ma.Arch),[]))
 
 if GlobalData.gBinCacheSource and CommandTarget in [None, "", 
"all"]:
diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index 3bb7e91154ac..5f28681e3146 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -2058,12 +2058,12 @@ class ModuleAutoGen(AutoGen):
not gDict[(self.MetaFile.Path, self.Arch)].ModuleFilesHashDigest:
 self.GenModuleFilesHash(gDict)
 
 if not (self.MetaFile.Path, self.Arch) in gDict or \
not gDict[(self.MetaFile.Path, self.Arch)].ModuleFilesHashDigest:
-   EdkLogger.quiet("[cache warning]: Cannot generate 
ModuleFilesHashDigest for module %s[%s]" %(self.MetaFile.Path, self.Arch))
-   return
+EdkLogger.quiet("[cache warning]: Cannot generate 
ModuleFilesHashDigest for module %s[%s]" %(self.MetaFile.Path, self.Arch))
+return
 
 # Initialze hash object
 m = hashlib.md5()
 
 # Add Platform level hash
diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
index c7591253debd..9dd93b9beb12 100644
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGenHelper.py
@@ -234,22 +234,51 @@ class AutoGenInfo(object):
 #
 #This class is the pruned WorkSpaceAutoGen for ModuleAutoGen in multiple thread
 #
 class WorkSpaceInfo(AutoGenInfo):
 def __init__(self,Workspace, MetaFile, Target, ToolChain, Arch):
+if not hasattr(self, "_Init"):
+self.do_init(Workspace, MetaFile, Target, ToolChain, Arch)
+self._Init = True
+def do_init(self,Workspace, MetaFile, Target, ToolChain, Arch):
 self._SrcTimeStamp = 0
 self.Db = BuildDB
 self.BuildDatabase = self.Db.BuildObject
 self.Target = Target
 self.ToolChain = ToolChain
 self.WorkspaceDir = Workspace
 self.ActivePlatform = MetaFile
 self.ArchList = Arch
+self.AutoGenObjectList = []
+@property
+def BuildDir(self):
+return self.AutoGenObjectList[0].BuildDir
 
+@property
+def Name(self):
+return self.AutoGenObjectList[0].Platform.PlatformName
+
+@property
+def FlashDefinition(self):
+return self.AutoGenObjectList[0].Platform.FlashDefinition
+@property
+def GenFdsCommandDict(self):
+FdsCommandDict = 
self.AutoGenObjectList[0].DataPipe.Get("FdsCommandDict")
+if FdsCommandDict:
+return FdsCommandDict
+return {}
+
+@cached_property
+def FvDir(self):
+return os.path.join(self.BuildDir, TAB_FV_DIRECTORY)
 
 class PlatformInfo(AutoGenInfo):
 def __init__(self, Workspace, MetaFile, Target, ToolChain, Arch,DataPipe):
+if not hasattr(self, "_Init"):
+self.do_init(Workspace, MetaFile, Target, ToolChain, Arch,DataPipe)
+self._Init = True
+def do_init(self,Workspace, MetaFile, Target, ToolChain, Arch,DataPipe):
 self.Wa = Workspace
 self.WorkspaceDir = self.Wa.WorkspaceDir
 self.MetaFile = MetaFile
 self.Arch = Arch
 self.Target = Target
diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py 

[edk2-devel] [Patch 1/1] BaseTools: Fix a bug for Hii Pcd override

[Bob Feng]

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

Hii Pcd links to a efi variable. The Variable
default value is evaluated by related Hii Pcds
setting. If multiple Hii Pcds links to one variable,
and the offset overlap, the later Hii Pcds setting
should be effective. There is a tool bug that is if
the Pcds are in different dsc file which are included
into the platform dsc file, build tool does not get
the Pcds relative position correctly. That means
build tool does not know which Pcd is the later one. As
the result, the variable default value will be incorrect.

This patch is to fix this bug.

Cc: Liming Gao 
Signed-off-by: Bob Feng 
---
 BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index d2b5ccbb7a30..9192077f9064 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -3012,11 +3012,11 @@ class DscBuildData(PlatformBuildClassObject):
 PcdList.append((PcdCName, TokenSpaceGuid, SkuName, 
DefaultStore, Dummy5))
 PcdDict[Arch, SkuName, PcdCName, TokenSpaceGuid, DefaultStore] = 
Setting
 
 
 # Remove redundant PCD candidates, per the ARCH and SKU
-for PcdCName, TokenSpaceGuid, SkuName, DefaultStore, Dummy4 in PcdList:
+for index,(PcdCName, TokenSpaceGuid, SkuName, DefaultStore, Dummy4) in 
enumerate(PcdList):
 
 Setting = PcdDict[self._Arch, SkuName, PcdCName, TokenSpaceGuid, 
DefaultStore]
 if Setting is None:
 continue
 VariableName, VariableGuid, VariableOffset, DefaultValue, 
VarAttribute = self._ValidatePcd(PcdCName, TokenSpaceGuid, Setting, Type, 
Dummy4)
@@ -3081,11 +3081,11 @@ class DscBuildData(PlatformBuildClassObject):
 IsDsc=True)
 if (PcdCName, TokenSpaceGuid) in UserDefinedDefaultStores:
 PcdClassObj.UserDefinedDefaultStoresFlag = True
 Pcds[PcdCName, TokenSpaceGuid] = PcdClassObj
 
-Pcds[PcdCName, TokenSpaceGuid].CustomAttribute['DscPosition'] 
= int(Dummy4)
+Pcds[PcdCName, TokenSpaceGuid].CustomAttribute['DscPosition'] 
= index
 if SkuName not in Pcds[PcdCName, TokenSpaceGuid].DscRawValue:
 Pcds[PcdCName, TokenSpaceGuid].DscRawValue[SkuName] = {}
 Pcds[PcdCName, TokenSpaceGuid].DscRawValueInfo[SkuName] = {}
 Pcds[PcdCName, TokenSpaceGuid].DscRawValue[SkuName][DefaultStore] 
= DefaultValue
 Pcds[PcdCName, 
TokenSpaceGuid].DscRawValueInfo[SkuName][DefaultStore] = 
(self.MetaFile.File,Dummy4)
-- 
2.20.1.windows.1


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

View/Reply Online (#46890): https://edk2.groups.io/g/devel/message/46890
Mute This Topic: https://groups.io/mt/33151625/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/CpuExceptionHandlerLib: Fix #AC split lock

[Dong, Eric]

Hi John,

I'm not sure whether I understand the code correctly. If not, please correct me.

1. You change to the code to only exchange 32 bits(eax) instead of 64 
bits(rax). After your change, how to handle the above 32 bits value (from bit 
32 to bit 63)?
2. In this file, also have another two xchg codes, do them need to be updated 
also?

Thanks,
Eric
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of John
> E Lofgren
> Sent: Wednesday, September 4, 2019 2:15 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH] UefiCpuPkg/CpuExceptionHandlerLib: Fix #AC
> split lock
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2150
> 
> Fix #AC split lock's caused by seperating base and limit from sgdt and sidt by
> changing xchg operands to 32-bit to stop from crossing cacheline.
> 
> Signed-off-by: John E Lofgren 
> ---
>  UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
> | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nas
> m
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nas
> m
> index 4db1a09f28..6d83dca4b9 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nas
> m
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.
> +++ nasm
> @@ -184,17 +184,17 @@ HasErrorCode:
>  pushrax
>  pushrax
>  sidt[rsp]
> -xchgrax, [rsp + 2]
> -xchgrax, [rsp]
> -xchgrax, [rsp + 8]
> +xchgeax, [rsp + 2]
> +xchgeax, [rsp]
> +xchgeax, [rsp + 8]
> 
>  xor rax, rax
>  pushrax
>  pushrax
>  sgdt[rsp]
> -xchgrax, [rsp + 2]
> -xchgrax, [rsp]
> -xchgrax, [rsp + 8]
> +xchgeax, [rsp + 2]
> +xchgeax, [rsp]
> +xchgeax, [rsp + 8]
> 
>  ;; UINT64  Ldtr, Tr;
>  xor rax, rax
> --
> 2.16.2.windows.1
> 
> 
> 


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

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

[edk2-devel] [PATCH 4/4] Platform: Intel: Remove hardcoded Stratix 10 UART clock

[Loh, Tien Hock]

From: "Tien Hock, Loh" 

Added clock manager so that Stratix 10 UART clock doesn't need to be
hardcoded

Signed-off-by: "Tien Hock, Loh" 
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
---
 Platform/Intel/Stratix10/Stratix10SoCPkg.dec   |   
3 +-
 Platform/Intel/Stratix10/Stratix10SoCPkg.dsc   |  
11 +-
 Platform/Intel/Stratix10/Library/PlatformHookLib/PlatformHookLib.inf   |  
41 ++
 Platform/Intel/Stratix10/Library/S10ClockManager/S10ClockManager.inf   |  
34 +
 Platform/Intel/Stratix10/Include/Library/S10ClockManager/S10ClockManager.h |  
48 +++
 Platform/Intel/Stratix10/Library/PlatformHookLib/PlatformHookLib.c |  
43 +++
 Platform/Intel/Stratix10/Library/S10ClockManager/S10ClockManager.c | 
133 
 7 files changed, 310 insertions(+), 3 deletions(-)

diff --git a/Platform/Intel/Stratix10/Stratix10SoCPkg.dec 
b/Platform/Intel/Stratix10/Stratix10SoCPkg.dec
index 7c44670d591d..346f7f9a042b 100755
--- a/Platform/Intel/Stratix10/Stratix10SoCPkg.dec
+++ b/Platform/Intel/Stratix10/Stratix10SoCPkg.dec
@@ -10,7 +10,8 @@ [Defines]
   PACKAGE_GUID   = 45533DD0-C41F-4ab6-A5DF-65B52684AC60
   PACKAGE_VERSION= 0.1
 
-[Includes.common]
+[Includes]
+  Include
 
 [Guids.common]
   gStratix10SocFpgaTokenSpaceGuid = { 0x0fe272eb, 0xb2cf, 0x4390, { 0xa5, 
0xc4, 0x60, 0x13, 0x2c, 0x6b, 0xd0, 0x34 } }
diff --git a/Platform/Intel/Stratix10/Stratix10SoCPkg.dsc 
b/Platform/Intel/Stratix10/Stratix10SoCPkg.dsc
index 643ce625c563..d3ad0eba7e75 100755
--- a/Platform/Intel/Stratix10/Stratix10SoCPkg.dsc
+++ b/Platform/Intel/Stratix10/Stratix10SoCPkg.dsc
@@ -27,6 +27,8 @@ [Defines]
 # Pcd Section - list of all EDK II PCD Entries defined by this Platform
 #
 

+[PcdsPatchableInModule.common]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate|184320
 
 [PcdsFixedAtBuild.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|TRUE
@@ -226,7 +228,8 @@ [LibraryClasses.common]
   SemihostLib|ArmPkg/Library/SemihostLib/SemihostLib.inf
 
   
SerialPortLib|MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550.inf
-  
PlatformHookLib|MdeModulePkg/Library/BasePlatformHookLibNull/BasePlatformHookLibNull.inf
+  
PlatformHookLib|Platform/Intel/Stratix10/Library/PlatformHookLib/PlatformHookLib.inf
+  
S10ClockManager|Platform/Intel/Stratix10/Library/S10ClockManager/S10ClockManager.inf
 
   
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
@@ -483,9 +486,13 @@ [Components.common]
   }
 
   #
-  # Platform Specific Init for DXE phase
+  # Platform Specific Init
   #
   Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.inf
+  Platform/Intel/Stratix10/Library/PlatformHookLib/PlatformHookLib.inf {
+
+
S10ClockManager|Platform/Intel/Stratix10/Library/S10ClockManager/S10ClockManager.inf
+  }
 
 [BuildOptions]
   #---
diff --git 
a/Platform/Intel/Stratix10/Library/PlatformHookLib/PlatformHookLib.inf 
b/Platform/Intel/Stratix10/Library/PlatformHookLib/PlatformHookLib.inf
new file mode 100644
index ..dc18db7c5444
--- /dev/null
+++ b/Platform/Intel/Stratix10/Library/PlatformHookLib/PlatformHookLib.inf
@@ -0,0 +1,41 @@
+## @file
+#  Platform Hook Library instance for UART device.
+#
+#  Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001B
+  BASE_NAME  = PlatformHookLib
+  FILE_GUID  = 90A73C58-A6E3-4EED-A1A3-6F9C7C3D998F
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = PlatformHookLib
+  CONSTRUCTOR= PlatformHookSerialPortInitialize
+
+[Sources]
+  PlatformHookLib.c
+
+[LibraryClasses]
+  PcdLib
+  PciLib
+  S10ClockManager
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  Platform/Intel/Stratix10/Stratix10SoCPkg.dec
+  UefiPayloadPkg/UefiPayloadPkg.dec
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio ## PRODUCES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase## PRODUCES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialBaudRate## PRODUCES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride  ## PRODUCES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate   ## PRODUCES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## PRODUCES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdPciSerialParameters   ## PRODUCES
+
diff --git 
a/Platform/Intel/Stratix10/Library/S10ClockManager/S10ClockManager.inf 

[edk2-devel] [PATCH 2/4] Platform: Intel: Update license to SPDX

[Loh, Tien Hock]

From: "Tien Hock, Loh" 

Update licenses to SPDX

Signed-off-by: "Tien Hock, Loh" 
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
---
 Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.inf
| 22 +++-
 Platform/Intel/Stratix10/Library/IntelPlatformLib/IntelPlatformLib.inf
| 22 +++-
 Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.c  
| 22 
 Platform/Intel/Stratix10/Library/IntelPlatformLib/Stratix10Mmu.c  
| 20 +++---
 Platform/Intel/Stratix10/Library/IntelPlatformLib/Stratix10PlatformLib.c  
| 19 ++---
 Platform/Intel/Stratix10/Library/IntelPlatformLib/AArch64/ArmPlatformHelper.S 
|  8 +--
 6 files changed, 38 insertions(+), 75 deletions(-)

diff --git 
a/Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.inf 
b/Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.inf
index 64b398969f1e..b16d93f22058 100644
--- a/Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.inf
+++ b/Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.inf
@@ -1,18 +1,12 @@
-#/** @file
-#
-#  Copyright (c) 2019, Intel All rights reserved.
-#
-#  This program and the accompanying materials
-#  are licensed and made available under the terms and conditions of the BSD 
License
-#  which accompanies this distribution.  The full text of the license may be 
found at
-#  http://opensource.org/licenses/bsd-license.php
-#
-#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-#
-#
-#**/
 
+### @file
+#
+#  Intel Stratix 10 Platform
+#  Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+###
+
 [Defines]
   INF_VERSION= 0x0001001B
   BASE_NAME  = IntelPlatformDxe
diff --git 
a/Platform/Intel/Stratix10/Library/IntelPlatformLib/IntelPlatformLib.inf 
b/Platform/Intel/Stratix10/Library/IntelPlatformLib/IntelPlatformLib.inf
index ef5c06aede7f..b6b6c743b800 100644
--- a/Platform/Intel/Stratix10/Library/IntelPlatformLib/IntelPlatformLib.inf
+++ b/Platform/Intel/Stratix10/Library/IntelPlatformLib/IntelPlatformLib.inf
@@ -1,18 +1,10 @@
-/** @file
-*
-*  Stratix 10 Platform Library
-*
-*  Copyright (c) 2019, Intel Corporations All rights reserved.
-*
-*  This program and the accompanying materials
-*  are licensed and made available under the terms and conditions of the BSD 
License
-*  which accompanies this distribution.  The full text of the license may be 
found at
-*  http://opensource.org/licenses/bsd-license.php
-*
-*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-*
-**/
+### @file
+#
+#  Stratix 10 Platform Library
+#  Copyright (c) 2019, Intel Corporation All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+###
 
 [Defines]
   INF_VERSION= 0x0001001B
diff --git 
a/Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.c 
b/Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.c
index 144b4c54ef55..b762fdc69ca4 100644
--- a/Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.c
+++ b/Platform/Intel/Stratix10/Drivers/IntelPlatformDxe/IntelPlatformDxe.c
@@ -1,16 +1,12 @@
-/** @file
-*
-*  Copyright (c) 2019, Intel All rights reserved.
-*
-*  This program and the accompanying materials
-*  are licensed and made available under the terms and conditions of the BSD 
License
-*  which accompanies this distribution.  The full text of the license may be 
found at
-*  http://opensource.org/licenses/bsd-license.php
-*
-*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
-*
-**/
+/** @file
+
+  Stratix 10 Platform Entry code
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
 
 
 #include 
diff --git a/Platform/Intel/Stratix10/Library/IntelPlatformLib/Stratix10Mmu.c 
b/Platform/Intel/Stratix10/Library/IntelPlatformLib/Stratix10Mmu.c
index 892387bf5d07..73ea1b423567 100644
--- a/Platform/Intel/Stratix10/Library/IntelPlatformLib/Stratix10Mmu.c
+++ b/Platform/Intel/Stratix10/Library/IntelPlatformLib/Stratix10Mmu.c
@@ -1,17 +1,11 @@
 /** @file
-*
-*  Stratix 10 Mmu configuration
-*
-*  Copyright (c) 2019, Intel Corporations All rights reserved.
-*
-*  This program and the accompanying materials
-*  are licensed and made available under the terms and conditions of the BSD 
License
-*  which accompanies this distribution.  The full text of the license may be 
found at
-*  http://opensource.org/licenses/bsd-license.php
-*
-*  

Re: [edk2-devel] [PATCH v2] MinPlatformPkg/SecFspWrapperPlatformSecLib: Change TopOfTemporaryRam type

[Chiu, Chasel]

Reviewed-by: Chasel Chiu 

> -Original Message-
> From: Zhang, Shenglei
> Sent: Thursday, September 5, 2019 2:20 PM
> To: devel@edk2.groups.io
> Cc: Kubacki, Michael A ; Chiu, Chasel
> ; Desimone, Nathaniel L
> ; Gao, Liming 
> Subject: [PATCH v2] MinPlatformPkg/SecFspWrapperPlatformSecLib: Change
> TopOfTemporaryRam type
> 
> Update the type of TopOfTemporaryRam from UINT32 to UINTN.
> This change is intended to support X64 build scenarios.
> The original code(line 64) may cast the overfloewed result produced by
> "(TopOfTemporaryRam - sizeof (UINT32))"from 32bit to 64bit.
> 
> Cc: Michael Kubacki 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Signed-off-by: Shenglei Zhang 
> ---
> v2: As TopOfTemporaryRam is defined as UINTN in v2, remove
> all the related casting operations which exist in v1 patch.
> 
>  .../SecFspWrapperPlatformSecLib/SecGetPerformance.c   | 8 
>  .../SecFspWrapperPlatformSecLib/SecPlatformInformation.c  | 6 +++---
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatfor
> mSecLib/SecGetPerformance.c
> b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatfor
> mSecLib/SecGetPerformance.c
> index c4eeb2b1..8535ae04 100644
> ---
> a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatfor
> mSecLib/SecGetPerformance.c
> +++
> b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlat
> +++ formSecLib/SecGetPerformance.c
> @@ -41,7 +41,7 @@ SecGetPerformance (
>  {
>UINT32  Size;
>UINT32  Count;
> -  UINT32  TopOfTemporaryRam;
> +  UINTN   TopOfTemporaryRam;
>UINT64  Ticker;
>VOID*TopOfTemporaryRamPpi;
>EFI_STATUS  Status;
> @@ -77,12 +77,12 @@ SecGetPerformance (
>// |  TSC[31:00]  |
>// |--|
>//
> -  TopOfTemporaryRam = (UINT32)(UINTN)TopOfTemporaryRamPpi -
> sizeof(UINT32);
> +  TopOfTemporaryRam = (UINTN)TopOfTemporaryRamPpi - sizeof(UINT32);
>TopOfTemporaryRam -= sizeof(UINT32) * 2;
> -  Count = *(UINT32 *) (UINTN) (TopOfTemporaryRam - sizeof
> (UINT32));
> +  Count = *(UINT32 *)(TopOfTemporaryRam - sizeof
> (UINT32));
>Size  = Count * sizeof (UINT32);
> 
> -  Ticker = *(UINT64 *) (UINTN) (TopOfTemporaryRam - sizeof (UINT32) - Size
> - sizeof (UINT32) * 2);
> +  Ticker = *(UINT64 *) (TopOfTemporaryRam - sizeof (UINT32) - Size -
> + sizeof (UINT32) * 2);
>Performance->ResetEnd = GetTimeInNanoSecond (Ticker);
> 
>return EFI_SUCCESS;
> diff --git
> a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatfor
> mSecLib/SecPlatformInformation.c
> b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatfor
> mSecLib/SecPlatformInformation.c
> index 5b94ed2b..ade36ab5 100644
> ---
> a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlatfor
> mSecLib/SecPlatformInformation.c
> +++
> b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/SecFspWrapperPlat
> +++ formSecLib/SecPlatformInformation.c
> @@ -36,7 +36,7 @@ SecPlatformInformation (
>UINT32  *Bist;
>UINT32  Size;
>UINT32  Count;
> -  UINT32  TopOfTemporaryRam;
> +  UINTN   TopOfTemporaryRam;
>VOID*TopOfTemporaryRamPpi;
>EFI_STATUS  Status;
> 
> @@ -59,9 +59,9 @@ SecPlatformInformation (
>// This routine copies the BIST information to the buffer pointed by
>// PlatformInformationRecord for output.
>//
> -  TopOfTemporaryRam = (UINT32)(UINTN)TopOfTemporaryRamPpi - sizeof
> (UINT32);
> +  TopOfTemporaryRam = (UINTN)TopOfTemporaryRamPpi - sizeof (UINT32);
>TopOfTemporaryRam -= sizeof(UINT32) * 2;
> -  Count = *((UINT32 *)(UINTN) (TopOfTemporaryRam - sizeof
> (UINT32)));
> +  Count = *((UINT32 *)(TopOfTemporaryRam - sizeof
> (UINT32)));
>Size  = Count * sizeof (IA32_HANDOFF_STATUS);
> 
>if ((*StructureSize) < (UINT64) Size) {
> --
> 2.18.0.windows.1


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

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

[edk2-devel] [PATCH 1/2] EmulatorPkg/PeiEmuSerialPortLib: Update the INF file Guid

[Zhang, Shenglei]

From: shenglei 

FILE GUID in PeiEmuSerialPortLib.inf is same to
MdePkg\Library\BaseSerialPortLibNull\BaseSerialPortLibNull.inf.
PeiEmuSerialPortLib.inf FILE_GUID should be updated.
https://bugzilla.tianocore.org/show_bug.cgi?id=2144

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Signed-off-by: Shenglei Zhang 
---
 EmulatorPkg/Library/PeiEmuSerialPortLib/PeiEmuSerialPortLib.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmulatorPkg/Library/PeiEmuSerialPortLib/PeiEmuSerialPortLib.inf 
b/EmulatorPkg/Library/PeiEmuSerialPortLib/PeiEmuSerialPortLib.inf
index f61346174739..2f5e656fd753 100644
--- a/EmulatorPkg/Library/PeiEmuSerialPortLib/PeiEmuSerialPortLib.inf
+++ b/EmulatorPkg/Library/PeiEmuSerialPortLib/PeiEmuSerialPortLib.inf
@@ -12,7 +12,7 @@
 [Defines]
   INF_VERSION= 0x00010005
   BASE_NAME  = PeiEmuSerialPortLibNull
-  FILE_GUID  = E4541241-8897-411a-91F8-7D7E45837146
+  FILE_GUID  = 76003416-0373-4C3C-BC4C-87E367FD4BD1
   MODULE_TYPE= PEIM
   VERSION_STRING = 1.0
   LIBRARY_CLASS  = SerialPortLib| PEI_CORE PEIM SEC
-- 
2.18.0.windows.1


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

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

[edk2-devel] [PATCH 0/2] Update file guids in INF files

[Zhang, Shenglei]

The file guids of PeiEmuSerialPortLib.inf and SerialDxe.inf
are same to other guids. So update them to new ones.
https://bugzilla.tianocore.org/show_bug.cgi?id=2144

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Cc: Jian J Wang 
Cc: Hao A Wu 
Shenglei Zhang (1):
  MdeModulePkg/SerialDxe: Update the file Guid in SerialDxe.inf

shenglei (1):
  EmulatorPkg/PeiEmuSerialPortLib: Update the INF file Guid

 EmulatorPkg/Library/PeiEmuSerialPortLib/PeiEmuSerialPortLib.inf | 2 +-
 MdeModulePkg/Universal/SerialDxe/SerialDxe.inf  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.18.0.windows.1


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

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

[edk2-devel] [PATCH 2/2] MdeModulePkg/SerialDxe: Update the file Guid in SerialDxe.inf

[Zhang, Shenglei]

FILE GUID in MdeModulePkg\Universal\SerialDxe\SerialDxe.inf is
same to the one gEdkiiSerialPortLibVendorGuid.
Its FILE GUID should be updated to another value.
https://bugzilla.tianocore.org/show_bug.cgi?id=2144

Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Shenglei Zhang 
---
 MdeModulePkg/Universal/SerialDxe/SerialDxe.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf 
b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
index b6c85b3f848d..ab5e045ead3d 100644
--- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
+++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
@@ -11,7 +11,7 @@ [Defines]
   INF_VERSION= 0x00010005
   BASE_NAME  = SerialDxe
   MODULE_UNI_FILE= SerialDxe.uni
-  FILE_GUID  = D3987D4B-971A-435F-8CAF-4967EB627241
+  FILE_GUID  = 3bd86846-4ad0-4e94-81e6-9ea34cd34cxb
   MODULE_TYPE= DXE_DRIVER
   VERSION_STRING = 1.0
 
-- 
2.18.0.windows.1


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

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

Re: [edk2-devel] [edk2] [Patch 32/33] BaseTools: ECC tool Python3 adaption

[Leif Lindholm]

Hi Bob, (+Laszlo, due to a question at the end)

On Thu, Sep 05, 2019 at 05:39:05AM +, Feng, Bob C wrote:
> Would you try to install antlr4-python3-runtime on debian.
> pip install antlr4-python3-runtime

I'd rather not. For the reasons described by Laszlo in the
discussion leading to the creation of edk2-tools:
https://edk2.groups.io/g/devel/message/40380

Now, if Ecc was moved to edk2-tools, I guess that would be fine. It
also means we increase the hurdle for running Ecc.

> I think python3 + antlr3 would not be a good combination, since the
> antlr3 for python3 is still in beta and has not been update for 7
> years. And I think there is no ECC test for such combination.

Nevertheless python3-antlr3 was packaged by debian/ubuntu as late as
last year, as part of their OpenStack work. And is now part of both
distributions.

Laszlo - which python-antlr versions are packaged in
centos/fedora/redhat?

/
Leif

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

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