Date   

Re: [PATCH v1] IntelFsp2WrapperPkg: Remove microcode PCDs

Chiu, Chasel
 

Reviewed-by: Chasel Chiu <chasel.chiu@...>

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jason Lou
Sent: Wednesday, April 14, 2021 10:34 AM
To: devel@edk2.groups.io
Cc: Lou, Yun <yun.lou@...>; Ni, Ray <ray.ni@...>
Subject: [edk2-devel] [PATCH v1] IntelFsp2WrapperPkg: Remove microcode
PCDs

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

IntelFsp2WrapperPkg defines following PCDs:
PcdCpuMicrocodePatchAddress
PcdCpuMicrocodePatchRegionSize
PcdFlashMicrocodeOffset

But the meanings of PcdCpuMicrocodePatchAddress and
PcdCpuMicrocodePatchRegionSize are different from the ones that have The
same name in UefiCpuPkg. To avoid confusion, remove the three PCDs defined
in IntelFsp2WrapperPkg.

Signed-off-by: Jason Lou <yun.lou@...>
Cc: Ray Ni <ray.ni@...>
---

IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInit
Data.c | 6 +++---
IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec
| 8 +-------

IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWra
pperPlatformSecLibSample.inf | 7 +++----
3 files changed, 7 insertions(+), 14 deletions(-)

diff --git
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamI
nitData.c
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamI
nitData.c
index 96b47e23da..e57b5b57be 100644
---
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamI
nitData.c
+++ b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecR
+++ amInitData.c
@@ -1,7 +1,7 @@
/** @file Sample to provide TempRamInitParams data. - Copyright (c) 2014 -
2020, Intel Corporation. All rights reserved.<BR>+ Copyright (c) 2014 - 2021,
Intel Corporation. All rights reserved.<BR> SPDX-License-Identifier: BSD-2-
Clause-Patent **/@@ -52,8 +52,8 @@ GLOBAL_REMOVE_IF_UNREFERENCED
CONST FSPT_UPD_CORE_DATA FsptUpdDataPtr = {
} }, {- ((UINT32)FixedPcdGet64 (PcdCpuMicrocodePatchAddress) +
FixedPcdGet32 (PcdFlashMicrocodeOffset)),- ((UINT32)FixedPcdGet64
(PcdCpuMicrocodePatchRegionSize) - FixedPcdGet32
(PcdFlashMicrocodeOffset)),+ FixedPcdGet32
(PcdCpuMicrocodePatchAddress),+ FixedPcdGet32
(PcdCpuMicrocodePatchRegionSize), FixedPcdGet32
(PcdFlashCodeCacheAddress), FixedPcdGet32 (PcdFlashCodeCacheSize), }diff
--git a/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec
b/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec
index 6852bf1271..a3b9363779 100644
--- a/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec
+++ b/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec
@@ -1,7 +1,7 @@
## @file # Provides drivers and definitions to support fsp in EDKII bios. #-#
Copyright (c) 2014 - 2020, Intel Corporation. All rights reserved.<BR>+#
Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.<BR> # SPDX-
License-Identifier: BSD-2-Clause-Patent # ##@@ -56,12 +56,6 @@
## Provides the size of the BIOS Flash Device.
gIntelFsp2WrapperTokenSpaceGuid.PcdFlashCodeCacheSize|0x00200000|UINT
32|0x10000002 - ## Indicates the base address of the first Microcode Patch in
the Microcode Region-
gIntelFsp2WrapperTokenSpaceGuid.PcdCpuMicrocodePatchAddress|0x0|UINT6
4|0x10000005-
gIntelFsp2WrapperTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize|0x0|UI
NT64|0x10000006- ## Indicates the offset of the Cpu Microcode.-
gIntelFsp2WrapperTokenSpaceGuid.PcdFlashMicrocodeOffset|0x90|UINT32|0x
10000007- ## Indicate the PEI memory size platform want to report
gIntelFsp2WrapperTokenSpaceGuid.PcdPeiMinMemSize|0x1800000|UINT32|0x
40000004 ## Indicate the PEI memory size platform want to reportdiff --git
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspW
rapperPlatformSecLibSample.inf
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspW
rapperPlatformSecLibSample.inf
index d7f8301bef..027b127724 100644
---
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspW
rapperPlatformSecLibSample.inf
+++ b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecF
+++ spWrapperPlatformSecLibSample.inf
@@ -1,7 +1,7 @@
## @file # Sample to provide FSP wrapper platform sec related function. #-#
Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.<BR>+#
Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.<BR> # # SPDX-
License-Identifier: BSD-2-Clause-Patent #@@ -76,8 +76,7 @@
gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress ##
CONSUMES [FixedPcd]-
gIntelFsp2WrapperTokenSpaceGuid.PcdCpuMicrocodePatchAddress ##
CONSUMES-
gIntelFsp2WrapperTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize ##
CONSUMES- gIntelFsp2WrapperTokenSpaceGuid.PcdFlashMicrocodeOffset
## CONSUMES+ gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchAddress
## CONSUMES+
gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize ##
CONSUMES gIntelFsp2WrapperTokenSpaceGuid.PcdFlashCodeCacheAddress
## CONSUMES gIntelFsp2WrapperTokenSpaceGuid.PcdFlashCodeCacheSize
## CONSUMES--
2.28.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74076): https://edk2.groups.io/g/devel/message/74076
Mute This Topic: https://groups.io/mt/82082551/1777047
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [chasel.chiu@...] -=-
=-=-=-=-=


Re: [PATCH v2] IntelFsp2WrapperPkg: Remove microcode related PCDs

Nate DeSimone
 

Reviewed-by: Nate DeSimone <nathaniel.l.desimone@...>

-----Original Message-----
From: Lou, Yun <yun.lou@...>
Sent: Wednesday, April 14, 2021 11:49 PM
To: devel@edk2.groups.io
Cc: Lou, Yun <yun.lou@...>; Chiu, Chasel <chasel.chiu@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Zeng, Star <star.zeng@...>; Ni, Ray <ray.ni@...>
Subject: [PATCH v2] IntelFsp2WrapperPkg: Remove microcode related PCDs

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

IntelFsp2WrapperPkg defines following PCDs:
PcdCpuMicrocodePatchAddress
PcdCpuMicrocodePatchRegionSize
PcdFlashMicrocodeOffset

But the PCD name caused confusion because UefiCpuPkg defines:
PcdCpuMicrocodePatchAddress
PcdCpuMicrocodePatchRegionSize

PcdCpuMicrocodePatchAddress in IntelFsp2WrapperPkg means the base address of the FV that holds the microcode.
PcdCpuMicrocodePatchAddress in UefiCpuPkg means the address of the microcode.

The relationship between the PCDs is:
IntelFsp2WrapperPkg.PcdCpuMicrocodePatchAddress
+ IntelFsp2WrapperPkg.PcdFlashMicrocodeOffset
== UefiCpuPkg.PcdCpuMicrocodePatchAddress

IntelFsp2WrapperPkg.PcdCpuMicrocodePatchRegionSize
- IntelFsp2WrapperPkg.PcdFlashMicrocodeOffset
== UefiCpuPkg.PcdCpuMicrocodePatchRegionSize

To avoid confusion and actually the PCDs in IntelFsp2WrapperPkg are only used by a sample FSP-T wrapper, this patch removes the 3 PCDs defined in IntelFsp2WrapperPkg.

The FSP-T wrapper is updated to directly use the ones in UefiCpuPkg.

Signed-off-by: Jason Lou <yun.lou@...>
Cc: Chasel Chiu <chasel.chiu@...>
Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Star Zeng <star.zeng@...>
Cc: Ray Ni <ray.ni@...>
---
IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c | 6 +++---
IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec | 8 +-------
IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf | 7 +++----
3 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c
index 96b47e23da..e57b5b57be 100644
--- a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c
+++ b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecR
+++ amInitData.c
@@ -1,7 +1,7 @@
/** @file Sample to provide TempRamInitParams data. - Copyright (c) 2014 - 2020, Intel Corporation. All rights reserved.<BR>+ Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.<BR> SPDX-License-Identifier: BSD-2-Clause-Patent **/@@ -52,8 +52,8 @@ GLOBAL_REMOVE_IF_UNREFERENCED CONST FSPT_UPD_CORE_DATA FsptUpdDataPtr = {
} }, {- ((UINT32)FixedPcdGet64 (PcdCpuMicrocodePatchAddress) + FixedPcdGet32 (PcdFlashMicrocodeOffset)),- ((UINT32)FixedPcdGet64 (PcdCpuMicrocodePatchRegionSize) - FixedPcdGet32 (PcdFlashMicrocodeOffset)),+ FixedPcdGet32 (PcdCpuMicrocodePatchAddress),+ FixedPcdGet32 (PcdCpuMicrocodePatchRegionSize), FixedPcdGet32 (PcdFlashCodeCacheAddress), FixedPcdGet32 (PcdFlashCodeCacheSize), }diff --git a/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec b/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec
index 6852bf1271..a3b9363779 100644
--- a/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec
+++ b/IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec
@@ -1,7 +1,7 @@
## @file # Provides drivers and definitions to support fsp in EDKII bios. #-# Copyright (c) 2014 - 2020, Intel Corporation. All rights reserved.<BR>+# Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.<BR> # SPDX-License-Identifier: BSD-2-Clause-Patent # ##@@ -56,12 +56,6 @@
## Provides the size of the BIOS Flash Device. gIntelFsp2WrapperTokenSpaceGuid.PcdFlashCodeCacheSize|0x00200000|UINT32|0x10000002 - ## Indicates the base address of the first Microcode Patch in the Microcode Region- gIntelFsp2WrapperTokenSpaceGuid.PcdCpuMicrocodePatchAddress|0x0|UINT64|0x10000005- gIntelFsp2WrapperTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize|0x0|UINT64|0x10000006- ## Indicates the offset of the Cpu Microcode.- gIntelFsp2WrapperTokenSpaceGuid.PcdFlashMicrocodeOffset|0x90|UINT32|0x10000007- ## Indicate the PEI memory size platform want to report gIntelFsp2WrapperTokenSpaceGuid.PcdPeiMinMemSize|0x1800000|UINT32|0x40000004 ## Indicate the PEI memory size platform want to reportdiff --git a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
index d7f8301bef..027b127724 100644
--- a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecFspWrapperPlatformSecLibSample.inf
+++ b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecF
+++ spWrapperPlatformSecLibSample.inf
@@ -1,7 +1,7 @@
## @file # Sample to provide FSP wrapper platform sec related function. #-# Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.<BR>+# Copyright (c) 2014 - 2021, Intel Corporation. All rights reserved.<BR> # # SPDX-License-Identifier: BSD-2-Clause-Patent #@@ -76,8 +76,7 @@
gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress ## CONSUMES [FixedPcd]- gIntelFsp2WrapperTokenSpaceGuid.PcdCpuMicrocodePatchAddress ## CONSUMES- gIntelFsp2WrapperTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize ## CONSUMES- gIntelFsp2WrapperTokenSpaceGuid.PcdFlashMicrocodeOffset ## CONSUMES+ gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchAddress ## CONSUMES+ gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize ## CONSUMES gIntelFsp2WrapperTokenSpaceGuid.PcdFlashCodeCacheAddress ## CONSUMES gIntelFsp2WrapperTokenSpaceGuid.PcdFlashCodeCacheSize ## CONSUMES--
2.28.0.windows.1


Re: GSOC 2021 EXT4 driver Project

Michael Brown
 

On 24/05/2021 20:26, Pedro Falcato wrote:
Me and my project have been selected for GSoC this year, under Michael Kinney and bret. Thank you for the opportunity to collaborate with you and improve Tianocore!
If anyone has any questions, please fire away :)
How do I get started? I'd like to find some easier tasks as to start trying out patch submission and generally programming in a firmware environment.
Also, I've been talking with my mentors and a relevant question to ask the mailing list is: Where should we put the EXT4 driver?
Michael said there are other filesystems in MdeModulePkg, but it might be getting too big and proposed the following options:
1) EXT4 in new package in edk2 repo as a peer to FatPkg.
2) EXT4 in edk2 repo in MdeModulePkg
3) EXT4 in edk2-platforms advanced feature package.
4) EXT4 in edk2 advanced feature package
FWIW, the most natural positioning seems to me to be as a separate Ext4Pkg similar to FatPkg.

For the sake of your own sanity, you probably want to start by maintaining Ext4Pkg as a completely standalone git repo that you happen to place within your local edk2 checkout directory. This will let you develop in isolation without worrying about where the code will eventually live, at least until the code has reached a state of maturity that makes it worth considering its eventual home. Keeping it in a separate Ext4Pkg repo will also enforce some level of discipline on your coding: you'll naturally avoid being tempted into letting your development work leak outside of Ext4Pkg into other packages.

In terms of questions, there are two that immediately spring to mind:

- Are you planning on making this read-only, or read-write?

- If you're planning on making it read-write: what simplifications will you be able to make to the write path in the UEFI environment? (UEFI is basically a single-user environment in which all filesystem writes should be flushed immediately: you may want to consider a simplified write path that never uses journalling, for example).

HTH,

Michael


Re: 回复: [edk2-devel] Generic MinPlatform

Daniel Schaefer
 

I had a closer look at the MinPlatform specification and I made a TODO list: https://github.com/riscv/riscv-edk2-platforms/issues/24

Mostly I just have to:
  • reorganize and split the FVs to fit the spec
  • use the include files to ensure that they contain the correct modules
  • switch to the MinPlatform PCDs instead of the ones that I currently use (for PreMemRamBase for example)
  • make sure the test functions to validate the stages are included and run
The tasks for x86 QEMU/OVMF should be the same. Doesn't look too scary.

Since there are these test functions, is there a way to test compliance with the spec?


From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Daniel Schaefer <daniel.schaefer@...>
Sent: Tuesday, May 25, 2021 02:59
To: devel@edk2.groups.io <devel@edk2.groups.io>; gaoliming@... <gaoliming@...>; kaaira7319@... <kaaira7319@...>; Ni, Ray <ray.ni@...>; mikuback@... <mikuback@...>; isaac.w.oram@... <isaac.w.oram@...>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Subject: Re: 回复: [edk2-devel] Generic MinPlatform
 
    • Rather than commenting out things you don’t need in the build, our thinking was to allow some unnecessary building in the interest of reducing porting complexity.  It doesn’t really matter if you don’t need the PciCf8 library as long as it builds fine.
    • If you need the PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf Instead of the PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can just override it in your DSC file after you have included the CoreCommonLib.dsc.  This is to reduce the number of includes that a typical board port needs to deal with correctly, but allow fine tuning and optimization later.
  • Hm, you're right. However I added another PCD to exclude things that RISC-V and many other non-x86 platforms don't have: SMM, port-mapped I/O, PC/AT architecture:


    And what's most relevant to Kaaira, the commit to make my QEMU platform use MinPlatform include files:

    Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.
    Yes, absolutely. As above, for now I created one for common x86 concepts. But there should probably be one for PCI and USB should move to AdvancedFeatures, like you said.
    The other two RISC-V platforms I'm working on don't have PCI and one of them doesn't have USB.

    Add “Core System Design” includes.  E.G. one for x86, one for QEMU, one for RISKV, etc.  I am not sure how many of these we would need.
    Right, that's a good idea. Kaaira and me can create one for QEMU with all of the virtio drivers.
    And those for x86 and RISC-V wouldn't actually too big, as you can see in my change. RISC-V needs even less special modules.

    Thanks,
    Daniel


    From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Oram, Isaac W <isaac.w.oram@...>
    Sent: Friday, May 21, 2021 11:38
    To: Schaefer, Daniel <daniel.schaefer@...>; devel@edk2.groups.io <devel@edk2.groups.io>; gaoliming@... <gaoliming@...>; kaaira7319@... <kaaira7319@...>; Ni, Ray <ray.ni@...>; mikuback@... <mikuback@...>
    Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
    Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
     

    I think we should patch first and move to a common location later.

     

    Looking at some of your changes and comments, I have these comments:

    • Rather than commenting out things you don’t need in the build, our thinking was to allow some unnecessary building in the interest of reducing porting complexity.  It doesn’t really matter if you don’t need the PciCf8 library as long as it builds fine.
    • If you need the PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf Instead of the PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can just override it in your DSC file after you have included the CoreCommonLib.dsc.  This is to reduce the number of includes that a typical board port needs to deal with correctly, but allow fine tuning and optimization later.
    • Rather than commenting out or adding !if modifications, you can set the feature PCD to false in your DSC file before including the file.  We are allowed to have multiple sections and the tools do a good job of applying them and aggregating them in sensible ways.  For example:

    #!if gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable == TRUE

    #  PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf

    #!endif

      • If you just have:

    [PcdsFeatureFlag]

      #

      # MinPlatform control flags

      #

      gMinPlatformPkgTokenSpaceGuid.PcdStopAfterDebugInit     |FALSE

      gMinPlatformPkgTokenSpaceGuid.PcdStopAfterMemInit       |FALSE

      gMinPlatformPkgTokenSpaceGuid.PcdBootToShellOnly        |FALSE

      gMinPlatformPkgTokenSpaceGuid.PcdUefiSecureBootEnable   |FALSE

      gMinPlatformPkgTokenSpaceGuid.PcdTpm2Enable             |FALSE

      gMinPlatformPkgTokenSpaceGuid.PcdSmiHandlerProfileEnable|TRUE

      gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable      |FALSE

    !include $(PLATFORM_PACKAGE)/Include/Dsc/CoreCommonLib.dsc

      • Then you should get the same result you want.

     

    This is useful feedback and we should think about how we want to enable optimization (stage 7) in a reasonable way.  We haven’t gotten that far into the optimization details as we wanted to get the basics worked out, but it might very much make sense to make more of these things controlled by MinPlatform Arch defined feature flags.  Or to move to Advanced Features.  And some things we haven’t cleaned up yet.  We still have USB in common includes, but those drivers should move to an Advanced Feature.  The main thing is we want intelligent default behavior so new board porting people can get productive fast without having to know all these edk2 special features.  Then as they get things working, they can start to take advantage of more edk2 and UEFI capabilities as they learn them.  Eventually hitting an optimization phase where common things can be quickly stripped out if not needed.  I hadn’t thought much about build optimization, but I think that this is reasonable to include in scope.

     

    Looking at your feedback/challenges, I see a few options:

    ·         Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.

    ·         Add Advanced Features for them

    ·         Add “Core System Design” includes.  E.G. one for x86, one for QEMU, one for RISKV, etc.  I am not sure how many of these we would need.

     

    Thoughts and preferences?  I think that we need to keep in mind KISS for new board ports and new users.

     

    The checklists should be “Board Porting Activity Checklist” and unfortunately for you both, you are making the first reference QemuOpenBoardPkg and boards and that is a little more involved than making derivatives, which is what those checklists are going to help the most.

     

    Regards,
    Isaac

     

     

    From: Schaefer, Daniel <daniel.schaefer@...>
    Sent: Thursday, May 20, 2021 7:27 PM
    To: Oram, Isaac W <isaac.w.oram@...>; devel@edk2.groups.io; gaoliming@...; kaaira7319@...; Ni, Ray <ray.ni@...>; mikuback@...
    Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
    Subject: Re:
    回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

     

    Thanks for the answers, that's very helpful, guys!

     

    I've started to replace some of my DSC and FDF with the include files mentioned by Michael.

    Since RISC-V doesn't have I/O registers, SMM and some other things, I had to make some changes but not too many.

    Maybe for Qemu there would have be some more non-Intel changes.

    Would you accept patches to make it more arch agnostic? Or should we first move it out of the Intel directory?

     

    Sorry for hijacking your thread Kaaira, but I hope this discussion would also be helpful for you 🙂

    Just like you, I'm trying to convert a QEMU platform to MinPlatform. (And then the other RISC-V platforms)

    If you want to have a look, you can check out my progress here: https://github.com/riscv/riscv-edk2-platforms/commits/riscv-virt-minplatform-gh-actions

     

    My plan is:

    1. Make DSC and FDF smaller by including generic files (WIP)
    2. Try to take advantage of "AdvancedFeatures"
    3. Reformat the FD into the FVs mandated by the MinPlatform spec
    4. Check the detailed requirements of each stage (e.g. required functions, build files, ...)

    I see that each stage in the MinPlatform spec has a checklist. They don't look like checklist but rather steps to achieve a certain state but that's also ok.

     

    Thanks,

    Daniel

     


    From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Michael Kubacki <mikuback@...>
    Sent: Friday, May 21, 2021 00:32
    To: Oram, Isaac W <
    isaac.w.oram@...>; devel@edk2.groups.io <devel@edk2.groups.io>; Schaefer, Daniel <daniel.schaefer@...>; gaoliming@... <gaoliming@...>; kaaira7319@... <kaaira7319@...>; Ni, Ray <ray.ni@...>
    Subject: Re:
    回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

     

    Daniel,

    You will specifically find attempts to consolidate common libraries and
    modules in DSC and FDF files that can be included into a board package
    here -
    https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Include.
    Files are split such that they can be included in the corresponding
    section in the board package DSC/FDF file. Note there are some mixed
    opinions I've encountered in the industry on the complexity trade off
    associated with includes in DSC and FDF files.

    But as Isaac mentioned, while MinPlatform is designed to support
    multiple architectures, it has only be enabled on Intel platforms,
    therefore, you should expect to encounter some problems enabling a
    different architecture but identifying and/or resolving those would be
    very valuable.

    As you are exploring how to port a platform to MinPlatform I also
    recommend familiarizing yourself the concept of advanced features
    described here -
    https://github.com/tianocore/edk2-platforms/blob/master/Features/Intel/Readme.md.
    You might find your board package is relatively simpler than the
    original platform package after accounting for advanced features being
    separated out.

    Thanks,
    Michael


    On 5/20/2021 8:05 AM, Oram, Isaac W wrote:
    > Daniel,
    >
    > The MinPlatform spec was intended to be architecture and product
    > independent for a mainstream set of products.  It is intended to
    > constrain some of the nearly unlimited extensibility and flexibility of
    > UEFI specs and edk2 codebase.  We took an 80/20 kind of approach.  Base
    > design should work for 80% of designs, but some will need to leverage
    > full edk2 and UEFI specification flexibility.  I think that a basic QEMU
    > kind of port would fit in 80% target.  I would ultimately like to see a
    > progression of edk2 use that starts with QEMU then moves more seamlessly
    > to open designs and then proprietary product designs.  MinPlatform
    > consistency is hoped to help that developer ramp into system firmware
    > productivity.
    >
    > We have only seen MinPlatform applied to Intel based products so far.
    > Which is why we are not rushing to move the spec from a 0.7 broad
    > feedback state to a 1.0 initially complete state.  Like edk2,
    > MinPlatformPkg and BoardModulePkg content is intended to support
    > multiple silicon and product architectures and we will happily promote
    > content out of Intel scope when that is an accurate reflection of use
    > and not just wishful thinking.  While 100% of uses are Intel scope, it
    > makes sense to land in the Intel part of edk2-platforms repo.  Similar
    > logic applies to Features/Intel content, though more there may have ties
    > to Intel specific product features.
    >
    > The Minimum Platform Arch spec details base requirements for FV layout
    > (thus enabling more common code to publish FV details), base silicon
    > policy configuration flow (thus more common PEIM/drivers to gather
    > config information and reduce board porting to relatively simple
    > libraries), and such things.  By enabling more common PEIM and drivers,
    > we hope to see benefits to ease of use and consistent quality. Similar
    > approaches for the other elements of the spec should help to improve
    > code sharing.
    >
    > Anyway, yes, it should be able to help you reduce the copies of mostly
    > common code that you encountered and the code and spec are open to
    > welcome the additional use and feedback from additional applications.
    >
    > Regards,
    > Isaac
    >
    > *From:*devel@edk2.groups.io <
    devel@edk2.groups.io> *On Behalf Of *Daniel
    > Schaefer
    > *Sent:* Wednesday, May 19, 2021 8:40 PM
    > *To:*
    devel@edk2.groups.io; gaoliming@...;
    >
    kaaira7319@...; Ni, Ray <ray.ni@...>;
    >
    mikuback@...
    > *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
    >
    > Hi,
    >
    > that sounds like a great project!
    >
    > I'm currently trying to create an equivalent of OvmfPkg for the RISCV64
    > generic QEMU virt machine.
    >
    > I don't like how much of my DSC and FDF file has modules that pretty
    > much all platforms should have.
    >
    > MinPlatform would help reduce that, right?
    >
    > Is MinPlatform flexible enough to account for non-X64 platforms?
    >
    > If so, then I think Kaaira and I could collaborate.
    >
    > Cheers,
    > Daniel
    >
    > ------------------------------------------------------------------------
    >
    > *From:*devel@edk2.groups.io
    > <
    mailto:devel@edk2.groups.io><devel@edk2.groups.io
    > <mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki
    > <mikuback@... <
    mailto:mikuback@...>>
    > *Sent:* Thursday, May 20, 2021 02:57
    > *To:*
    devel@edk2.groups.io
    > <
    mailto:devel@edk2.groups.io><devel@edk2.groups.io
    > <mailto:devel@edk2.groups.io>>; gaoliming@...
    > <
    mailto:gaoliming@...><gaoliming@...
    > <mailto:gaoliming@...>>; kaaira7319@...
    > <
    mailto:kaaira7319@...><kaaira7319@...
    > <mailto:kaaira7319@...>>; 'Ray Ni' <ray.ni@...
    > <mailto:ray.ni@...>>
    > *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
    >
    > I also wanted to add that I will be setting up weekly video calls
    > including Ray that we can use to supplement mailing list communication.
    >
    > I suggest the primary communication mechanism be the mailing list and we
    > use those calls for clarification, detailed project planning, and topics
    > not directly relevant to the list.
    >
    > Regards,
    > Michael
    >
    > On 5/19/2021 10:29 AM, Michael Kubacki wrote:
    >> Thanks Liming.
    >>
    >> Hi Kaaira,
    >>
    >> Welcome! You can contact me at
    mikuback@... <mailto:mikuback@...>. You
    > will
    >> sometimes see my email as
    michael.kubacki@... <mailto:michael.kubacki@...>and
    > that is fine
    >> to use for communication though I tend to not use it on the mailing list
    >> due to way the mail server manipulates plaintext email.
    >>
    >> GENERIC RESOURCES
    >>
    >> I'm sharing some general resources in case you are not already familiar
    >> with them:
    >>
    >> 1.
    https://github.com/tianocore-training/Tianocore_Training_Contents/wiki
    > <
    https://github.com/tianocore-training/Tianocore_Training_Contents/wiki>
    >>
    >> This one is good for topics like UEFI overview, EDK II concepts, and
    >> Minimum Platform.
    >>
    >> In particular for your project, I recommend looking through the
    >> MinPlatform training -
    >>
    https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf
    > <
    https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf>
    >>
    >>
    >> 2.
    >>
    https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html
    > <
    https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html>
    >>
    >>
    >> These whitepapers are useful when you need more in depth detail about a
    >> particular area (like capsule update or work related to the memory map).
    >> I recommend bookmarking it and keeping it in mind as a reference.
    >>
    >> 3.
    https://uefi.org/learning_center/presentationsandvideos/
    > <
    https://uefi.org/learning_center/presentationsandvideos/>
    >>
    >> Scroll through here if you have some time and see if there's anything
    >> interesting. To help keep on your project schedule I don't think these
    >> are as important but there is a lot of interesting material there.
    >>
    >> Reading through some of the key concepts in Beyond BIOS can be helpful
    >> and like the UEFI, ACPI, and PI (Platform Initialization) specs at
    >>
    https://uefi.org/specifications <https://uefi.org/specifications>, I
    > believe they are most useful as
    >> references when you are solving specific problems.
    >>
    >> PROJECT-SPECIFIC RESOURCES
    >>
    >> Since your project involves creating QEMU board within the Minimum
    >> Platform architecture, you can start looking into:
    >>
    >> 1. QEMU - An open source machine emulator
    >> 2. Minimum Platform Architecture - A software architecture to create
    >> basic platform firmware that can be extended with advanced functionality.
    >> 3. Intel FSP - Try to understand the high-level goals and how FSP
    >> interfaces with firmware.
    >>
    >> 1. QEMU -
    https://www.qemu.org/  <https://www.qemu.org/>
    >>
    >> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to
    >> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit
    >> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a
    >> 64-bit DXE.
    >>
    >> I suggest you start with the OvmfPkg README -
    >>
    https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
    > <
    https://github.com/tianocore/edk2/blob/master/OvmfPkg/README>
    >>
    >> As an initial step you can try to build an OVMF FW with a 32-bit PEI
    >> (IA32) and 64-bit DXE (X64) and boot to the EFI shell.
    >> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these
    >> target architectures.
    >>
    >> Any time you submit patches to edk2, you can check edk2/maintainers.txt
    >> -
    https://github.com/tianocore/edk2/blob/master/Maintainers.txt
    > <
    https://github.com/tianocore/edk2/blob/master/Maintainers.txt>for the
    >> appropriate maintainers and reviewers to CC on the patch. As you can
    >> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a
    >> reviewer. If there are any questions that require deep expertise in QEMU
    >> or OVMF, we will reach out to them. The Minimum Platform code is
    >> maintained in the edk2-platforms repository and it has a similar
    >> maintainers.txt file for its packages -
    >>
    https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt
    > <
    https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt>.
    >>
    >> I suggest you try sending a very trivial patch for a change in the
    >> edk2-platforms repository -
    https://github.com/tianocore/edk2-platforms
    > <
    https://github.com/tianocore/edk2-platforms>
    >> to make sure that your git environment is set up properly to format edk2
    >> patches and your email service can send patches correctly.
    >>
    >> We can discuss the details about how to set up your environment and what
    >> to change when you are ready. You can use this page to get started -
    >>
    https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute
    > <
    https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute>.
    >>
    >> 2. EDK II Minimum Platform Specification -
    >>
    https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/ 
    > <
    https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/>
    >>
    >> For your project, this spec will be very useful. It describes why
    >> Minimum Platform was created and how it works at a high-level. Like the
    >> code, this document is open and available to the community. You might
    >> contribute content here in addition to your code. You can fix any bugs
    >> or update content in the spec using git patches and the mailing list
    >> similar to code.
    >>
    >> 3. Intel FSP -
    >>
    https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
    > <
    https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html>
    >>
    >>
    >> For more information about Intel FSP check out the Intel FSP External
    >> Architecture Specification in the link above. v2.2 is currently the
    >> latest version.
    >>
    >> There is an open source QEMU FSP available here
    >>
    https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64
    > <
    https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64>. You will
    >> find the existing Minimum Platform boards use Intel FSP while OvmfPkg
    >> does not use FSP.
    >>
    >> Firmware is really best learned hands on. Using the links and background
    >> info above, I suggest:
    >>
    >> 1. Read the OvmfPkg readme.
    >> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell
    >> using QEMU.
    >> 3. Reading through the EDK II Minimum Platform Specification to gain a
    >> high level understanding of Minimum Platform.
    >> 4. Connect what you read to the code in
    >>
    https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel
    > <
    https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel>.
    >> Focus on higher level pieces like the board initialization library.
    >> 5. Note what each board package is doing. You will find common patterns
    >> for what a board package needs to implement to make the system boot.
    >> 6. As you read through the code, reference the general resources listed
    >> above to understand anything not Minimum Platform specific. Part of the
    >> learning process is knowing which spec to use for different interfaces.
    >> If you're unsure which spec something is in, feel free to reach out.
    >> 7. While looking through the code in edk2-platforms, think about a patch
    >> you can send to edk2-platforms for something very trivial such as a bug
    >> fix or documentation update.
    >> 8. Send the patch and get it reviewed-by the appropriate
    >> maintainers/reviewers and merged into the master branch.
    >> 9. Read through the code in OvmfPkg. Try to map the work it is doing to
    >> the board code you reviewed in edk2-platforms.
    >> 10. At this point, you could start outlining major pieces of
    >> initialization in OVMF and how they might map to a board package. Try to
    >> identify where the initialization pieces would reside in the board
    >> package and try to identify challenges that might arise. We will likely
    >> spend quite a bit of time here before jumping into too much code.
    >>
    >> I know this is a lot of info. Please don't hesitate to reach out if you
    >> have any questions and I look forward to working with you.
    >>
    >> Regards,
    >> Michael
    >>
    >> On 5/18/2021 6:05 PM, gaoliming wrote:
    >>> Include Michael Kubacki.
    >>>
    >>> Thanks
    >>> Liming
    >>>> -----邮件原件-----
    >>>> 发件人:
    devel@edk2.groups.io
    > <
    mailto:devel@edk2.groups.io><devel@edk2.groups.io
    > <mailto:devel@edk2.groups.io>> 代表 KAAIRA
    >>>> GUPTA
    >>>> 发送时间: 2021518 22:42
    >>>> 收件人: Ray Ni <ray.ni@... <
    mailto:ray.ni@...>>;
    >
    devel@edk2.groups.io <mailto:devel@edk2.groups.io>
    >>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
    >>>>
    >>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
    >>>>> Hey everyone,
    >>>>>
    >>>>> I have been selected as a student developer for the project MinPlatform
    >>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
    >>>> Thankyou
    >>>>> for this opportunity. I have been over the major chapters of Beyond
    >>>>> BIOS
    >>>>> as recommended by Nate DeSimone. I want to get familiar with the code
    >>>>> now to help me undersatnd the community practices and get my hands
    >>>>> dirty. Where should I start? What development environment do I need?
    >>>>> How can I use this community bonding period to give me a better start
    >>>>> for the coding phase?
    >>>>>
    >>>>> How do the mentors want me to connect with them? Can we have a meet
    >>>> to
    >>>>> discuss this project's plan to add more details? This would be very
    >>>>> helpful for me considering I don't have prior experience with EDK2.
    >>>>
    >>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
    >>>> exist anymore. Please let me know how I can contact him.
    >>>>
    >>>>>
    >>>>> Thank you,
    >>>>> Kaaira
    >>>>
    >>>> Thanks,
    >>>> Kaaira
    >>>>
    >>>>
    >>>>
    >>>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >
    >
    >
    >
    >
    >





    [edk2-platforms][PATCH V1 3/3] Platform/Sgi: enable support for UEFI secure boot

    Sayanta Pattanayak
     

    Enable the use of UEFI secure boot for Arm's Neoverse reference design
    platforms. The UEFI authenticated variable store uses NOR flash 2 which
    is accessible from Standalone MM context residing in a secure partition.

    Signed-off-by: Sayanta Pattanayak <sayanta.pattanayak@...>
    ---
    Platform/ARM/SgiPkg/SgiPlatform.dsc.inc | 31 +++++++++++++++++++
    Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc | 32 ++++++++++++++++++++
    Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 15 +++++++++
    Platform/ARM/SgiPkg/PlatformStandaloneMm2.dsc | 15 +++++++++
    Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf | 5 +++
    Platform/ARM/SgiPkg/SgiPlatform.fdf | 9 +++++-
    6 files changed, 106 insertions(+), 1 deletion(-)

    diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc b/Platform/ARM/SgiPk=
    g/SgiPlatform.dsc.inc
    index 091de0c99c74..e4aee7a09acf 100644
    --- a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
    +++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
    @@ -6,6 +6,14 @@
    =20
    !include Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
    =20
    +[Defines]
    + # To allow the use of secure storage, set this to TRUE.
    + DEFINE SECURE_STORAGE_ENABLE =3D FALSE
    +
    + # To allow the use of UEFI secure boot, set this to TRUE.
    + # Secure boot requires secure storage to be enabled as well.
    + DEFINE SECURE_BOOT_ENABLE =3D FALSE
    +
    [BuildOptions]
    *_*_*_CC_FLAGS =3D -D DISABLE_NEW_DEPRECATED_INTERFACES
    =20
    @@ -22,6 +30,9 @@
    NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/NorFlashLi=
    b.inf
    HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
    TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
    +!if $(SECURE_BOOT_ENABLE) =3D=3D TRUE
    + MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLi=
    bNull.inf
    +!endif
    =20
    # Virtio Support
    VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
    @@ -84,6 +95,7 @@
    [PcdsFeatureFlag.common]
    gArmSgiTokenSpaceGuid.PcdVirtioBlkSupported|TRUE
    gArmSgiTokenSpaceGuid.PcdVirtioNetSupported|TRUE
    + gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache|FALSE
    =20
    [PcdsFixedAtBuild.common]
    gArmTokenSpaceGuid.PcdVFPEnabled|1
    @@ -230,7 +242,15 @@
    MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
    MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
    MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRunt=
    imeDxe.inf
    +!if $(SECURE_BOOT_ENABLE) =3D=3D TRUE
    + MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
    + <LibraryClasses>
    + NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificat=
    ionLib.inf
    + }
    + SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig=
    Dxe.inf
    +!else
    MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
    +!endif
    OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
    =20
    MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
    @@ -238,6 +258,9 @@
    MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.i=
    nf
    MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
    MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
    +!if $(SECURE_STORAGE_ENABLE) =3D=3D TRUE
    + MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
    +!else
    MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
    <LibraryClasses>
    NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
    @@ -245,6 +268,7 @@
    BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
    }
    MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
    +!endif
    =20
    #
    # ACPI Support
    @@ -314,4 +338,11 @@
    #
    MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
    =20
    +!if $(SECURE_STORAGE_ENABLE) =3D=3D TRUE
    + ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf {
    + <LibraryClasses>
    + NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDepend=
    ency.inf
    + }
    +!else
    ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
    +!endif
    diff --git a/Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc b/Platform/ARM/Sgi=
    Pkg/SgiPlatformMm.dsc.inc
    index 3389ff676a91..6839ec35da8a 100644
    --- a/Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc
    +++ b/Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc
    @@ -59,6 +59,19 @@
    HobLib|StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.i=
    nf
    MmServicesTableLib|MdePkg/Library/StandaloneMmServicesTableLib/Standal=
    oneMmServicesTableLib.inf
    MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmMemoryAllocati=
    onLib/StandaloneMmMemoryAllocationLib.inf
    +!if $(SECURE_STORAGE_ENABLE) =3D=3D TRUE
    + AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.in=
    f
    + BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
    + IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
    + NorFlashPlatformLib|Platform/ARM/SgiPkg/Library/NorFlashLib/Standalone=
    MmNorFlashLib.inf
    + OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
    + RngLib|MdePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
    + PlatformSecureLib|SecurityPkg/Library/PlatformSecureLibNull/PlatformSe=
    cureLibNull.inf
    + SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchroni=
    zationLib.inf
    + TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTempl=
    ate.inf
    + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
    + SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
    +!endif
    =20
    ########################################################################=
    ########
    #
    @@ -75,6 +88,12 @@
    =20
    gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
    =20
    +!if $(SECURE_STORAGE_ENABLE) =3D=3D TRUE
    + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
    + gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
    + gEfiSecurityPkgTokenSpaceGuid.PcdUserPhysicalPresence|TRUE
    +!endif
    +
    ########################################################################=
    ###########################
    #
    # Components Section - list of the modules and components that will be p=
    rocessed by compilation
    @@ -101,6 +120,19 @@
    =20
    [Components.AARCH64]
    StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
    +!if $(SECURE_STORAGE_ENABLE) =3D=3D TRUE
    + ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
    + MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal=
    oneMm.inf
    + MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf {
    + <LibraryClasses>
    + DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.i=
    nf
    + NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
    + NULL|MdeModulePkg/Library/VarCheckPolicyLib/VarCheckPolicyLibStand=
    aloneMm.inf
    + BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
    + VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariableP=
    olicyLib.inf
    + VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperL=
    ib/VariablePolicyHelperLib.inf
    + }
    +!endif
    =20
    ########################################################################=
    ###########################
    #
    diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc b/Platform/ARM/=
    SgiPkg/PlatformStandaloneMm.dsc
    index cdf8aaa88f03..2cb4895cfcff 100644
    --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
    +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
    @@ -39,3 +39,18 @@
    [PcdsFixedAtBuild]
    ## PL011 - Serial Terminal
    gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x7FF70000
    +
    +!if $(SECURE_STORAGE_ENABLE) =3D=3D TRUE
    + ##Secure NOR Flash 2
    + gArmSgiTokenSpaceGuid.PcdSmcCs2Base|0x10000000
    + gArmSgiTokenSpaceGuid.PcdSysPeriphBase|0x1C000000
    + gArmSgiTokenSpaceGuid.PcdSysPeriphSysRegBase|0x1C010000
    +
    + ##Secure Variable Storage in NOR Flash 2
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x1000000=
    0
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0010000=
    0
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x10100=
    000
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x00100=
    000
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x1020000=
    0
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0010000=
    0
    +!endif
    diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm2.dsc b/Platform/ARM=
    /SgiPkg/PlatformStandaloneMm2.dsc
    index bb359a15cc0d..46c2ae3529d1 100644
    --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm2.dsc
    +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm2.dsc
    @@ -38,3 +38,18 @@
    [PcdsFixedAtBuild]
    ## PL011 - Serial Terminal
    gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x0EF80000
    +
    +!if $(SECURE_STORAGE_ENABLE) =3D=3D TRUE
    + ##Secure NOR Flash 2
    + gArmSgiTokenSpaceGuid.PcdSmcCs2Base|0x1054000000
    + gArmSgiTokenSpaceGuid.PcdSysPeriphBase|0x0C000000
    + gArmSgiTokenSpaceGuid.PcdSysPeriphSysRegBase|0x0C010000
    +
    + ##Secure Variable Storage in NOR Flash 2
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0x10540=
    00000
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0010000=
    0
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0x105=
    4100000
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x00100=
    000
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0x10542=
    00000
    + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0010000=
    0
    +!endif
    diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf b/Platform/ARM/=
    SgiPkg/PlatformStandaloneMm.fdf
    index 5a0772cd8522..474c9c0ce764 100644
    --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
    +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
    @@ -49,6 +49,11 @@ READ_LOCK_CAP =3D TRUE
    READ_LOCK_STATUS =3D TRUE
    =20
    INF StandaloneMmPkg/Core/StandaloneMmCore.inf
    +!if $(SECURE_STORAGE_ENABLE) =3D=3D TRUE
    + INF ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
    + INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSta=
    ndaloneMm.inf
    + INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.in=
    f
    +!endif
    INF StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.in=
    f
    =20
    ########################################################################=
    ########
    diff --git a/Platform/ARM/SgiPkg/SgiPlatform.fdf b/Platform/ARM/SgiPkg/Sg=
    iPlatform.fdf
    index e11d943d6efc..d94e4633e36c 100644
    --- a/Platform/ARM/SgiPkg/SgiPlatform.fdf
    +++ b/Platform/ARM/SgiPkg/SgiPlatform.fdf
    @@ -90,10 +90,17 @@ READ_LOCK_STATUS =3D TRUE
    INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
    INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
    INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
    - INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe=
    .inf
    INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounter=
    RuntimeDxe.inf
    INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
    +!if $(SECURE_BOOT_ENABLE) =3D=3D TRUE
    + INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCo=
    nfigDxe.inf
    +!endif
    +!if $(SECURE_STORAGE_ENABLE) =3D=3D TRUE
    + INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.i=
    nf
    +!else
    + INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe=
    .inf
    INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
    +!endif
    =20
    #
    # ACPI Support
    --=20
    2.17.1


    [edk2-platforms][PATCH V1 2/3] Platform/Sgi: add StandaloneMM usable NorFlashPlatformLib

    Sayanta Pattanayak
     

    Add the NorFlashPlatformLib library instance that can be linked with
    MM_STANDALONE modules that implement a secure variable storage. The
    third instance of the NOR flash is used as the non-volatile storage.

    Signed-off-by: Sayanta Pattanayak <sayanta.pattanayak@...>
    ---
    Platform/ARM/SgiPkg/SgiPlatform.dec | 1=
    +
    Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf | 33=
    ++++++++
    Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c | 82=
    ++++++++++++++++++++
    3 files changed, 116 insertions(+)

    diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dec b/Platform/ARM/SgiPkg/Sg=
    iPlatform.dec
    index 3effd49592ea..af08ed153eae 100644
    --- a/Platform/ARM/SgiPkg/SgiPlatform.dec
    +++ b/Platform/ARM/SgiPkg/SgiPlatform.dec
    @@ -54,6 +54,7 @@
    =20
    gArmSgiTokenSpaceGuid.PcdSmcCs0Base|0|UINT64|0x0000000C
    gArmSgiTokenSpaceGuid.PcdSmcCs1Base|0|UINT64|0x0000000D
    + gArmSgiTokenSpaceGuid.PcdSmcCs2Base|0|UINT64|0x00001000
    gArmSgiTokenSpaceGuid.PcdSysPeriphBase|0x00000000|UINT64|0x0000000E
    gArmSgiTokenSpaceGuid.PcdSysPeriphSysRegBase|0x0|UINT64|0x0000000F
    =20
    diff --git a/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlash=
    Lib.inf b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib=
    .inf
    new file mode 100644
    index 000000000000..96bbf1e42313
    --- /dev/null
    +++ b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.inf
    @@ -0,0 +1,33 @@
    +## @file
    +# StandaloneMM instance of NOR Flash library.
    +#
    +# Copyright (c) 2021, ARM Limited. All rights reserved.
    +# SPDX-License-Identifier: BSD-2-Clause-Patent
    +#
    +##
    +
    +[Defines]
    + INF_VERSION =3D 0x0001001A
    + BASE_NAME =3D NorFlashMmLib
    + FILE_GUID =3D 2ce22190-b933-4d1e-99ba-8bf1f076825=
    5
    + MODULE_TYPE =3D MM_STANDALONE
    + VERSION_STRING =3D 1.0
    + PI_SPECIFICATION_VERSION =3D 0x00010032
    + LIBRARY_CLASS =3D NorFlashPlatformLib
    +
    +[Sources.common]
    + StandaloneMmNorFlashLib.c
    +
    +[Packages]
    + ArmPlatformPkg/ArmPlatformPkg.dec
    + MdePkg/MdePkg.dec
    + Platform/ARM/SgiPkg/SgiPlatform.dec
    +
    +[LibraryClasses]
    + BaseLib
    + DebugLib
    + IoLib
    +
    +[FixedPcd]
    + gArmSgiTokenSpaceGuid.PcdSysPeriphSysRegBase
    + gArmSgiTokenSpaceGuid.PcdSmcCs2Base
    diff --git a/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlash=
    Lib.c b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
    new file mode 100644
    index 000000000000..3e5a5612c17e
    --- /dev/null
    +++ b/Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmNorFlashLib.c
    @@ -0,0 +1,82 @@
    +/** @file
    +* NOR flash platform library to be used in StandaloneMM context
    +*
    +* This file provides platform callbacks for the NOR flash module that ex=
    ecutes
    +* in the StandaloneMM context. The third NOR flash instance of 64MB size=
    on the
    +* reference design platform is assigned to be used in the StandaloneMM c=
    ontext.
    +*
    +* Copyright (c) 2021, ARM Ltd. All rights reserved.
    +*
    +* SPDX-License-Identifier: BSD-2-Clause-Patent
    +*
    +**/
    +
    +#include <Library/DebugLib.h>
    +#include <Library/IoLib.h>
    +#include <Library/NorFlashPlatformLib.h>
    +#include <PiMm.h>
    +#include <SgiPlatform.h>
    +
    +//
    +// 64MB NOR flash connected to CS2 is assigned to be used in StandaloneM=
    M
    +// context.
    +//
    +STATIC NOR_FLASH_DESCRIPTION mNorFlashDevices[] =3D {
    + {
    + // NOR-Flash2 assigned for secure storage.
    + FixedPcdGet64 (PcdSmcCs2Base),
    + FixedPcdGet64 (PcdSmcCs2Base),
    + SIZE_256KB * 256,
    + SIZE_256KB,
    + },
    +};
    +
    +/** Allow access to NOR flash
    +
    + On the reference design platforms, the access to NOR flash has to be
    + explicitly permitted by writing to the FLASH_RWEN bit of the SYSPH_SYS=
    _REG
    + register.
    +
    + @retval EFI_SUCCESS Initialize required to access NOR flash is compl=
    ete.
    +
    +**/
    +EFI_STATUS
    +NorFlashPlatformInitialization (
    + VOID
    + )
    +{
    + UINT64 SysRegFlash;
    +
    + SysRegFlash =3D FixedPcdGet64 (PcdSysPeriphSysRegBase) + SGI_SYSPH_SYS=
    _REG_FLASH;
    + MmioOr32 (SysRegFlash, SGI_SYSPH_SYS_REG_FLASH_RWEN);
    + return EFI_SUCCESS;
    +}
    +
    +/** Returns the list of available NOR flash devices
    +
    + For the StandaloneMM execution context, return the list of available N=
    OR
    + flash devices that are available for use.
    +
    + @param[in] NorFlashDevices Pointer to array of NOR flash devices.
    + @param[in] Count Number of elements in the NOR flash devi=
    ces
    + array.
    +
    + @retval EFI_SUCCESS Valid set of NOR flash devices is retu=
    rned.
    + @retval EFI_INVALID_PARAMETER Pointers to NOR flash devices and/or c=
    ount is
    + invalid.
    +
    +**/
    +EFI_STATUS
    +NorFlashPlatformGetDevices (
    + OUT NOR_FLASH_DESCRIPTION **NorFlashDevices,
    + OUT UINT32 *Count
    + )
    +{
    + if ((NorFlashDevices =3D=3D NULL) || (Count =3D=3D NULL)) {
    + return EFI_INVALID_PARAMETER;
    + }
    +
    + *NorFlashDevices =3D mNorFlashDevices;
    + *Count =3D ARRAY_SIZE (mNorFlashDevices);
    + return EFI_SUCCESS;
    +}
    --=20
    2.17.1


    [edk2-platforms][PATCH V1 1/3] Platform/Sgi: refactor StandaloneMM platform description file

    Sayanta Pattanayak
     

    The RD-N2 platform has a different memory map from that of the other
    platforms supported under the SgiPkg. To enable the use of StandaloneMM
    as a secure partition on RD-N2 platform, refactor the existing
    StandaloneMM platform description file. The differing portions are split
    into two different files and the rest of the platform description file
    is converted into a include file.

    Signed-off-by: Sayanta Pattanayak <sayanta.pattanayak@...>
    ---
    Platform/ARM/SgiPkg/{PlatformStandaloneMm.dsc =3D> SgiPlatformMm.dsc.inc=
    } | 30 +----
    Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc =
    | 117 ++------------------
    Platform/ARM/SgiPkg/PlatformStandaloneMm2.dsc =
    | 40 +++++++
    3 files changed, 53 insertions(+), 134 deletions(-)

    diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc b/Platform/ARM/=
    SgiPkg/SgiPlatformMm.dsc.inc
    similarity index 83%
    copy from Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
    copy to Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc
    index e281d5490912..3389ff676a91 100644
    --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
    +++ b/Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc
    @@ -1,37 +1,16 @@
    +## @file
    +# StandaloneMM platform description include file for all supported plat=
    forms.
    #
    -# Copyright (c) 2018, ARM Limited. All rights reserved.
    +# Copyright (c) 2021, ARM Limited. All rights reserved.
    #
    # SPDX-License-Identifier: BSD-2-Clause-Patent
    -#
    -
    -########################################################################=
    ########
    -#
    -# Defines Section - statements that will be processed to create a Makefi=
    le.
    -#
    -########################################################################=
    ########
    -[Defines]
    - PLATFORM_NAME =3D SgiMmStandalone
    - PLATFORM_GUID =3D 34B78C8F-CFD5-49D5-8360-E91143F6106=
    D
    - PLATFORM_VERSION =3D 1.0
    - DSC_SPECIFICATION =3D 0x00010011
    - OUTPUT_DIRECTORY =3D Build/$(PLATFORM_NAME)
    - SUPPORTED_ARCHITECTURES =3D AARCH64
    - BUILD_TARGETS =3D DEBUG|RELEASE|NOOPT
    - SKUID_IDENTIFIER =3D DEFAULT
    - FLASH_DEFINITION =3D Platform/ARM/SgiPkg/PlatformStandal=
    oneMm.fdf
    - DEFINE DEBUG_MESSAGE =3D TRUE
    -
    - # LzmaF86
    - DEFINE COMPRESSION_TOOL_GUID =3D D42AE6BD-1352-4bfb-909A-CA72A6EAE88=
    9
    +##
    =20
    ########################################################################=
    ########
    #
    # Library Class section - list of all Library Classes needed by this Pla=
    tform.
    #
    ########################################################################=
    ########
    -
    -!include MdePkg/MdeLibs.dsc.inc
    -
    [LibraryClasses]
    #
    # Basic
    @@ -92,7 +71,6 @@
    gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x0f
    =20
    ## PL011 - Serial Terminal
    - gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x7FF70000
    gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
    =20
    gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
    diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc b/Platform/ARM/=
    SgiPkg/PlatformStandaloneMm.dsc
    index e281d5490912..cdf8aaa88f03 100644
    --- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
    +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
    @@ -1,8 +1,11 @@
    +## @file
    +# StandaloneMM platform description file for SGI-575, RD-N1-Edge, RD-E1=
    -Edge
    +# and RD-V1 platforms.
    #
    -# Copyright (c) 2018, ARM Limited. All rights reserved.
    +# Copyright (c) 2021, ARM Limited. All rights reserved.
    #
    # SPDX-License-Identifier: BSD-2-Clause-Patent
    -#
    +##
    =20
    ########################################################################=
    ########
    #
    @@ -11,9 +14,9 @@
    ########################################################################=
    ########
    [Defines]
    PLATFORM_NAME =3D SgiMmStandalone
    - PLATFORM_GUID =3D 34B78C8F-CFD5-49D5-8360-E91143F6106=
    D
    + PLATFORM_GUID =3D 503b97f6-1be9-4661-97fd-9a55bbd2680=
    d
    PLATFORM_VERSION =3D 1.0
    - DSC_SPECIFICATION =3D 0x00010011
    + DSC_SPECIFICATION =3D 0x0001001B
    OUTPUT_DIRECTORY =3D Build/$(PLATFORM_NAME)
    SUPPORTED_ARCHITECTURES =3D AARCH64
    BUILD_TARGETS =3D DEBUG|RELEASE|NOOPT
    @@ -24,62 +27,9 @@
    # LzmaF86
    DEFINE COMPRESSION_TOOL_GUID =3D D42AE6BD-1352-4bfb-909A-CA72A6EAE88=
    9
    =20
    -########################################################################=
    ########
    -#
    -# Library Class section - list of all Library Classes needed by this Pla=
    tform.
    -#
    -########################################################################=
    ########
    -
    +# include common definitions.
    !include MdePkg/MdeLibs.dsc.inc
    -
    -[LibraryClasses]
    - #
    - # Basic
    - #
    - BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
    - BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
    - DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.=
    inf
    - DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/Bas=
    eDebugPrintErrorLevelLib.inf
    - ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionL=
    ib/PrePiExtractGuidedSectionLib.inf
    - FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf
    - HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCore=
    HobLib.inf
    - IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
    - MemLib|StandaloneMmPkg/Library/StandaloneMmMemLib/StandaloneMmMemLib.i=
    nf
    - MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllo=
    cationLib/StandaloneMmCoreMemoryAllocationLib.inf
    - PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
    - PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
    - PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
    - ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseRep=
    ortStatusCodeLibNull.inf
    -
    - #
    - # Entry point
    - #
    - StandaloneMmDriverEntryPoint|MdePkg/Library/StandaloneMmDriverEntryPoi=
    nt/StandaloneMmDriverEntryPoint.inf
    -
    - ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
    - StandaloneMmMmuLib|ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneM=
    mLib.inf
    - ArmSvcLib|ArmPkg/Library/ArmSvcLib/ArmSvcLib.inf
    - CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMain=
    tenanceLib.inf
    - PeCoffExtraActionLib|StandaloneMmPkg/Library/StandaloneMmPeCoffExtraAc=
    tionLib/StandaloneMmPeCoffExtraActionLib.inf
    -
    - # ARM PL011 UART Driver
    - PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartCl=
    ockLib.inf
    - PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
    - SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPor=
    tLib.inf
    -
    - StandaloneMmCoreEntryPoint|StandaloneMmPkg/Library/StandaloneMmCoreEnt=
    ryPoint/StandaloneMmCoreEntryPoint.inf
    -
    - #
    - # It is not possible to prevent the ARM compiler for generic intrinsic=
    functions.
    - # This library provides the instrinsic functions generate by a given c=
    ompiler.
    - # And NULL mean link this library into all ARM images.
    - #
    - NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
    -
    -[LibraryClasses.common.MM_STANDALONE]
    - HobLib|StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.i=
    nf
    - MmServicesTableLib|MdePkg/Library/StandaloneMmServicesTableLib/Standal=
    oneMmServicesTableLib.inf
    - MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmMemoryAllocati=
    onLib/StandaloneMmMemoryAllocationLib.inf
    +!include Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc
    =20
    ########################################################################=
    ########
    #
    @@ -87,54 +37,5 @@
    #
    ########################################################################=
    ########
    [PcdsFixedAtBuild]
    - gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x800000CF
    - gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xff
    - gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x0f
    -
    ## PL011 - Serial Terminal
    gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x7FF70000
    - gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
    -
    - gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
    -
    -########################################################################=
    ###########################
    -#
    -# Components Section - list of the modules and components that will be p=
    rocessed by compilation
    -# tools and the EDK II tools to generate PE32/PE32+=
    /Coff image files.
    -#
    -# Note: The EDK II DSC file is not used to specify how compiled binary i=
    mages get placed
    -# into firmware volume images. This section is just a list of modu=
    les to compile from
    -# source into UEFI-compliant binaries.
    -# It is the FDF file that contains information on combining binary=
    files into firmware
    -# volume images, whose concept is beyond UEFI and is described in =
    PI specification.
    -# Binary modules do not need to be listed in this section, as they=
    should be
    -# specified in the FDF file. For example: Shell binary (Shell_Full=
    .efi), FAT binary (Fat.efi),
    -# Logo (Logo.bmp), and etc.
    -# There may also be modules listed in this section that are not re=
    quired in the FDF file,
    -# When a module listed here is excluded from FDF file, then UEFI-c=
    ompliant binary will be
    -# generated for it, but the binary will not be put into any firmwa=
    re volume.
    -#
    -########################################################################=
    ###########################
    -[Components.common]
    - #
    - # MM Core
    - #
    - StandaloneMmPkg/Core/StandaloneMmCore.inf
    -
    -[Components.AARCH64]
    - StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
    -
    -########################################################################=
    ###########################
    -#
    -# BuildOptions Section - Define the module specific tool chain flags tha=
    t should be used as
    -# the default flags for a module. These flags are=
    appended to any
    -# standard flags that are defined by the build pr=
    ocess. They can be
    -# applied for any modules or only those modules w=
    ith the specific
    -# module style (EDK or EDKII) specified in [Compo=
    nents] section.
    -#
    -########################################################################=
    ###########################
    -[BuildOptions.AARCH64]
    - GCC:*_*_*_DLINK_FLAGS =3D -z common-page-size=3D0x1000 -march=3Darmv8-=
    a+nofp
    -
    -[BuildOptions]
    - *_*_*_CC_FLAGS =3D -D DISABLE_NEW_DEPRECATED_INTERFACES
    diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm2.dsc b/Platform/ARM=
    /SgiPkg/PlatformStandaloneMm2.dsc
    new file mode 100644
    index 000000000000..bb359a15cc0d
    --- /dev/null
    +++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm2.dsc
    @@ -0,0 +1,40 @@
    +## @file
    +# StandaloneMM platform description file for RD-N2 platforms.
    +#
    +# Copyright (c) 2021, ARM Limited. All rights reserved.
    +#
    +# SPDX-License-Identifier: BSD-2-Clause-Patent
    +##
    +
    +########################################################################=
    ########
    +#
    +# Defines Section - statements that will be processed to create a Makefi=
    le.
    +#
    +########################################################################=
    ########
    +[Defines]
    + PLATFORM_NAME =3D SgiMmStandalone
    + PLATFORM_GUID =3D 67309f8a-d278-4df5-86ee-a1826cf481e=
    d
    + PLATFORM_VERSION =3D 1.0
    + DSC_SPECIFICATION =3D 0x0001001B
    + OUTPUT_DIRECTORY =3D Build/$(PLATFORM_NAME)
    + SUPPORTED_ARCHITECTURES =3D AARCH64
    + BUILD_TARGETS =3D DEBUG|RELEASE|NOOPT
    + SKUID_IDENTIFIER =3D DEFAULT
    + FLASH_DEFINITION =3D Platform/ARM/SgiPkg/PlatformStandal=
    oneMm.fdf
    + DEFINE DEBUG_MESSAGE =3D TRUE
    +
    + # LzmaF86
    + DEFINE COMPRESSION_TOOL_GUID =3D D42AE6BD-1352-4bfb-909A-CA72A6EAE88=
    9
    +
    +# include common definitions.
    +!include MdePkg/MdeLibs.dsc.inc
    +!include Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc
    +
    +########################################################################=
    ########
    +#
    +# Pcd Section - list of all EDK II PCD Entries defined by this Platform
    +#
    +########################################################################=
    ########
    +[PcdsFixedAtBuild]
    + ## PL011 - Serial Terminal
    + gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x0EF80000
    --=20
    2.17.1


    [edk2-platforms][PATCH V1 0/3] Platform/Sgi: enable support for UEFI secure boot

    Sayanta Pattanayak
     

    This patch series adds secure boot support for Arm's reference design
    platforms. The first patch refactors the existing StandaloneMM platform
    description file and splits into three different files. This is required
    to accomodate for changes register base addresses in RD-N2 platform and
    the other supported platforms. The second path add support for NOR flash
    platform library to be used with StandaloneMM execution context. The
    third patch then enables the support for UEFI secure for all the
    supported reference design platforms.

    This patch series should be applied on top of the patch series
    https://edk2.groups.io/g/devel/message/75368

    Link to github branch with the patches in this series -
    https://github.com/SayantaP-arm/edk2-platforms/tree/rd_platform_secure_bo=
    ot

    Sayanta Pattanayak (3):
    Platform/Sgi: refactor StandaloneMM platform description file
    Platform/Sgi: add StandaloneMM usable NorFlashPlatformLib
    Platform/Sgi: enable support for UEFI secure boot

    Platform/ARM/SgiPkg/SgiPlatform.dec | 1 +
    Platform/ARM/SgiPkg/SgiPlatform.dsc.inc | 31 +++++
    ...StandaloneMm.dsc =3D> SgiPlatformMm.dsc.inc} | 62 +++++----
    Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 130 ++++--------------
    Platform/ARM/SgiPkg/PlatformStandaloneMm2.dsc | 55 ++++++++
    Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf | 5 +
    Platform/ARM/SgiPkg/SgiPlatform.fdf | 9 +-
    .../NorFlashLib/StandaloneMmNorFlashLib.inf | 33 +++++
    .../NorFlashLib/StandaloneMmNorFlashLib.c | 82 +++++++++++
    9 files changed, 274 insertions(+), 134 deletions(-)
    copy Platform/ARM/SgiPkg/{PlatformStandaloneMm.dsc =3D> SgiPlatformMm.ds=
    c.inc} (73%)
    create mode 100644 Platform/ARM/SgiPkg/PlatformStandaloneMm2.dsc
    create mode 100644 Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmN=
    orFlashLib.inf
    create mode 100644 Platform/ARM/SgiPkg/Library/NorFlashLib/StandaloneMmN=
    orFlashLib.c

    --=20
    2.17.1


    [PATCH] MdePkg: Fix AsmReadSs() with GCC toolchain

    Satoshi Tanda
     

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

    AsmReadSs() in Ia32/GccInlinePriv.c and X64/GccInlinePriv.c return the
    DS segment selector value instead of SS.

    Signed-off-by: Satoshi Tanda <tanda.sat@...>
    ---
    MdePkg/Library/BaseLib/Ia32/GccInlinePriv.c | 2 +-
    MdePkg/Library/BaseLib/X64/GccInlinePriv.c | 2 +-
    2 files changed, 2 insertions(+), 2 deletions(-)

    diff --git a/MdePkg/Library/BaseLib/Ia32/GccInlinePriv.c b/MdePkg/Library/B=
    aseLib/Ia32/GccInlinePriv.c
    index 40e8c08beb..b8b5b85e73 100644
    --- a/MdePkg/Library/BaseLib/Ia32/GccInlinePriv.c
    +++ b/MdePkg/Library/BaseLib/Ia32/GccInlinePriv.c
    @@ -902,7 +902,7 @@ AsmReadSs (
    UINT16 Data;=0D
    =0D
    __asm__ __volatile__ (=0D
    - "mov %%ds, %0"=0D
    + "mov %%ss, %0"=0D
    :"=3Da" (Data)=0D
    );=0D
    =0D
    diff --git a/MdePkg/Library/BaseLib/X64/GccInlinePriv.c b/MdePkg/Library/Ba=
    seLib/X64/GccInlinePriv.c
    index 244bd62ee6..c3feb9f922 100644
    --- a/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
    +++ b/MdePkg/Library/BaseLib/X64/GccInlinePriv.c
    @@ -911,7 +911,7 @@ AsmReadSs (
    UINT16 Data;=0D
    =0D
    __asm__ __volatile__ (=0D
    - "mov %%ds, %0"=0D
    + "mov %%ss, %0"=0D
    :"=3Da" (Data)=0D
    );=0D
    =0D
    --=20
    2.25.1


    Re: [PATCH 1/2] MdePkg: Standalone PCD driver

    Michael D Kinney
     

    Why do we need a new PCD?

    Can't we make this the default behavior to only install one instance?

    Thanks,

    Mike

    -----Original Message-----
    From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Zhiguang Liu
    Sent: Monday, May 24, 2021 2:25 AM
    To: devel@edk2.groups.io
    Cc: Kinney, Michael D <michael.d.kinney@...>; Liming Gao <gaoliming@...>
    Subject: [edk2-devel] [PATCH 1/2] MdePkg: Standalone PCD driver

    Add a feature PCD to control if the PCD driver is build as standalone mode.
    This way, two mode PCD driver won't share the data base.

    Cc: Michael D Kinney <michael.d.kinney@...>
    Cc: Liming Gao <gaoliming@...>
    Signed-off-by: Zhiguang Liu <zhiguang.liu@...>
    ---
    MdeModulePkg/Universal/PCD/Dxe/Pcd.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++----------------------
    --
    MdeModulePkg/Universal/PCD/Dxe/Pcd.inf | 16 ++++++++++++----
    MdeModulePkg/Universal/PCD/Dxe/Service.c | 7 ++++++-
    MdePkg/Include/Protocol/Pcd.h | 5 -----
    MdePkg/Include/Protocol/PcdInfo.h | 5 -----
    MdePkg/Library/DxePcdLib/DxePcdLib.c | 24 ++++++++++++++++++++----
    MdePkg/Library/DxePcdLib/DxePcdLib.inf | 16 ++++++++++++----
    MdePkg/Library/DxePcdLib/PayloadPcdLib.inf | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    MdePkg/MdePkg.dec | 12 ++++++++++++
    9 files changed, 184 insertions(+), 47 deletions(-)

    diff --git a/MdeModulePkg/Universal/PCD/Dxe/Pcd.c b/MdeModulePkg/Universal/PCD/Dxe/Pcd.c
    index cdb9b4fac1..dc9c4be022 100644
    --- a/MdeModulePkg/Universal/PCD/Dxe/Pcd.c
    +++ b/MdeModulePkg/Universal/PCD/Dxe/Pcd.c
    @@ -129,34 +129,61 @@ PcdDxeInit (
    //

    // Make sure the Pcd Protocol is not already installed in the system

    //

    + if (FeaturePcdGet (PcdStandalonePcdDatabaseEnable)) {

    + ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, &gEdkiiPayloadStandalonePcdProtocolGuid);

    + BuildPcdDxeDataBase ();



    - ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, &gPcdProtocolGuid);

    + //

    + // Install PCD_PROTOCOL to handle dynamic type PCD

    + // Install EFI_PCD_PROTOCOL to handle dynamicEx type PCD

    + //

    + Status = gBS->InstallMultipleProtocolInterfaces (

    + &mPcdHandle,

    + &gEdkiiPayloadStandalonePcdProtocolGuid, &mPcdInstance,

    + &gEdkiiEfiPayloadStandalonePcdProtocolGuid, &mEfiPcdInstance,

    + NULL

    + );

    + ASSERT_EFI_ERROR (Status);



    - BuildPcdDxeDataBase ();

    + //

    + // Install GET_PCD_INFO_PROTOCOL to handle dynamic type PCD

    + // Install EFI_GET_PCD_INFO_PROTOCOL to handle dynamicEx type PCD

    + //

    + Status = gBS->InstallMultipleProtocolInterfaces (

    + &mPcdHandle,

    + &gEdkiiPayloadGetStandalonePcdInfoProtocolGuid, &mGetPcdInfoInstance,

    + &gEdkiiEfiPayloadGetStandalonePcdInfoProtocolGuid, &mEfiGetPcdInfoInstance,

    + NULL

    + );

    + ASSERT_EFI_ERROR (Status);

    + } else {

    + ASSERT_PROTOCOL_ALREADY_INSTALLED (NULL, &gPcdProtocolGuid);

    + BuildPcdDxeDataBase ();



    - //

    - // Install PCD_PROTOCOL to handle dynamic type PCD

    - // Install EFI_PCD_PROTOCOL to handle dynamicEx type PCD

    - //

    - Status = gBS->InstallMultipleProtocolInterfaces (

    - &mPcdHandle,

    - &gPcdProtocolGuid, &mPcdInstance,

    - &gEfiPcdProtocolGuid, &mEfiPcdInstance,

    - NULL

    - );

    - ASSERT_EFI_ERROR (Status);

    + //

    + // Install PCD_PROTOCOL to handle dynamic type PCD

    + // Install EFI_PCD_PROTOCOL to handle dynamicEx type PCD

    + //

    + Status = gBS->InstallMultipleProtocolInterfaces (

    + &mPcdHandle,

    + &gPcdProtocolGuid, &mPcdInstance,

    + &gEfiPcdProtocolGuid, &mEfiPcdInstance,

    + NULL

    + );

    + ASSERT_EFI_ERROR (Status);



    - //

    - // Install GET_PCD_INFO_PROTOCOL to handle dynamic type PCD

    - // Install EFI_GET_PCD_INFO_PROTOCOL to handle dynamicEx type PCD

    - //

    - Status = gBS->InstallMultipleProtocolInterfaces (

    - &mPcdHandle,

    - &gGetPcdInfoProtocolGuid, &mGetPcdInfoInstance,

    - &gEfiGetPcdInfoProtocolGuid, &mEfiGetPcdInfoInstance,

    - NULL

    - );

    - ASSERT_EFI_ERROR (Status);

    + //

    + // Install GET_PCD_INFO_PROTOCOL to handle dynamic type PCD

    + // Install EFI_GET_PCD_INFO_PROTOCOL to handle dynamicEx type PCD

    + //

    + Status = gBS->InstallMultipleProtocolInterfaces (

    + &mPcdHandle,

    + &gGetPcdInfoProtocolGuid, &mGetPcdInfoInstance,

    + &gEfiGetPcdInfoProtocolGuid, &mEfiGetPcdInfoInstance,

    + NULL

    + );

    + ASSERT_EFI_ERROR (Status);

    + }



    //

    // Register callback function upon VariableLockProtocol

    diff --git a/MdeModulePkg/Universal/PCD/Dxe/Pcd.inf b/MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
    index eb9f757f14..f3e704f083 100644
    --- a/MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
    +++ b/MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
    @@ -329,10 +329,15 @@
    gEfiMdeModulePkgTokenSpaceGuid ## SOMETIMES_CONSUMES ## GUID



    [Protocols]

    - gPcdProtocolGuid ## PRODUCES

    - gEfiPcdProtocolGuid ## PRODUCES

    - gGetPcdInfoProtocolGuid ## SOMETIMES_PRODUCES

    - gEfiGetPcdInfoProtocolGuid ## SOMETIMES_PRODUCES

    + gPcdProtocolGuid ## PRODUCES

    + gEfiPcdProtocolGuid ## PRODUCES

    + gGetPcdInfoProtocolGuid ## SOMETIMES_PRODUCES

    + gEfiGetPcdInfoProtocolGuid ## SOMETIMES_PRODUCES

    +

    + gEdkiiPayloadStandalonePcdProtocolGuid ## PRODUCES

    + gEdkiiEfiPayloadStandalonePcdProtocolGuid ## PRODUCES

    + gEdkiiPayloadGetStandalonePcdInfoProtocolGuid ## SOMETIMES_PRODUCES

    + gEdkiiEfiPayloadGetStandalonePcdInfoProtocolGuid ## SOMETIMES_PRODUCES

    ## NOTIFY

    ## SOMETIMES_CONSUMES

    gEdkiiVariableLockProtocolGuid

    @@ -342,6 +347,9 @@
    gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress64 ## SOMETIMES_CONSUMES

    gEfiMdeModulePkgTokenSpaceGuid.PcdSetNvStoreDefaultId ## SOMETIMES_CONSUMES



    +[FeaturePcd]

    + gEfiMdePkgTokenSpaceGuid.PcdStandalonePcdDatabaseEnable ## CONSUMES

    +

    [Depex]

    TRUE



    diff --git a/MdeModulePkg/Universal/PCD/Dxe/Service.c b/MdeModulePkg/Universal/PCD/Dxe/Service.c
    index ea7edc3cbb..fe16ba713b 100644
    --- a/MdeModulePkg/Universal/PCD/Dxe/Service.c
    +++ b/MdeModulePkg/Universal/PCD/Dxe/Service.c
    @@ -861,7 +861,12 @@ BuildPcdDxeDataBase (
    CopyMem (PcdDxeDb, mPcdDatabase.DxeDb, mPcdDatabase.DxeDb->Length);

    mPcdDatabase.DxeDb = PcdDxeDb;



    - GuidHob = GetFirstGuidHob (&gPcdDataBaseHobGuid);

    + if (FeaturePcdGet (PcdStandalonePcdDatabaseEnable)) {

    + GuidHob = NULL;

    + } else {

    + GuidHob = GetFirstGuidHob (&gPcdDataBaseHobGuid);

    + }

    +

    if (GuidHob != NULL) {



    //

    diff --git a/MdePkg/Include/Protocol/Pcd.h b/MdePkg/Include/Protocol/Pcd.h
    index 9cd1a998f8..cfa6ac2360 100644
    --- a/MdePkg/Include/Protocol/Pcd.h
    +++ b/MdePkg/Include/Protocol/Pcd.h
    @@ -17,11 +17,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
    #ifndef __PCD_H__

    #define __PCD_H__



    -extern EFI_GUID gPcdProtocolGuid;

    -

    -#define PCD_PROTOCOL_GUID \

    - { 0x11b34006, 0xd85b, 0x4d0a, { 0xa2, 0x90, 0xd5, 0xa5, 0x71, 0x31, 0xe, 0xf7 } }

    -

    #define PCD_INVALID_TOKEN_NUMBER ((UINTN) 0)





    diff --git a/MdePkg/Include/Protocol/PcdInfo.h b/MdePkg/Include/Protocol/PcdInfo.h
    index b0ec7f6770..5691215c42 100644
    --- a/MdePkg/Include/Protocol/PcdInfo.h
    +++ b/MdePkg/Include/Protocol/PcdInfo.h
    @@ -19,11 +19,6 @@
    #ifndef __PCD_INFO_H__

    #define __PCD_INFO_H__



    -extern EFI_GUID gGetPcdInfoProtocolGuid;

    -

    -#define GET_PCD_INFO_PROTOCOL_GUID \

    - { 0x5be40f57, 0xfa68, 0x4610, { 0xbb, 0xbf, 0xe9, 0xc5, 0xfc, 0xda, 0xd3, 0x65 } }

    -

    ///

    /// The forward declaration for GET_PCD_INFO_PROTOCOL.

    ///

    diff --git a/MdePkg/Library/DxePcdLib/DxePcdLib.c b/MdePkg/Library/DxePcdLib/DxePcdLib.c
    index 2accaeda2c..8a61486832 100644
    --- a/MdePkg/Library/DxePcdLib/DxePcdLib.c
    +++ b/MdePkg/Library/DxePcdLib/DxePcdLib.c
    @@ -43,7 +43,11 @@ GetPiPcdProtocol (
    // PI Pcd protocol defined in PI 1.2 vol3 should be installed before the module

    // access DynamicEx type PCD.

    //

    - Status = gBS->LocateProtocol (&gEfiPcdProtocolGuid, NULL, (VOID **) &mPiPcd);

    + if (FeaturePcdGet (PcdStandalonePcdDatabaseEnable)) {

    + Status = gBS->LocateProtocol (&gEdkiiEfiPayloadStandalonePcdProtocolGuid, NULL, (VOID **) &mPiPcd);

    + } else {

    + Status = gBS->LocateProtocol (&gEfiPcdProtocolGuid, NULL, (VOID **) &mPiPcd);

    + }

    ASSERT_EFI_ERROR (Status);

    ASSERT (mPiPcd != NULL);

    }

    @@ -68,7 +72,11 @@ GetPcdProtocol (
    // PCD protocol need to be installed before the module access Dynamic type PCD.

    // But dynamic type PCD is not required in PI 1.2 specification.

    //

    - Status = gBS->LocateProtocol (&gPcdProtocolGuid, NULL, (VOID **)&mPcd);

    + if (FeaturePcdGet (PcdStandalonePcdDatabaseEnable)) {

    + Status = gBS->LocateProtocol (&gEdkiiPayloadStandalonePcdProtocolGuid, NULL, (VOID **)&mPcd);

    + } else {

    + Status = gBS->LocateProtocol (&gPcdProtocolGuid, NULL, (VOID **)&mPcd);

    + }

    ASSERT_EFI_ERROR (Status);

    ASSERT (mPcd != NULL);

    }

    @@ -88,7 +96,11 @@ GetPiPcdInfoProtocolPointer (
    EFI_STATUS Status;



    if (mPiPcdInfo == NULL) {

    - Status = gBS->LocateProtocol (&gEfiGetPcdInfoProtocolGuid, NULL, (VOID **)&mPiPcdInfo);

    + if (FeaturePcdGet (PcdStandalonePcdDatabaseEnable)) {

    + Status = gBS->LocateProtocol (&gEdkiiEfiPayloadGetStandalonePcdInfoProtocolGuid, NULL, (VOID **)&mPiPcdInfo);

    + } else{

    + Status = gBS->LocateProtocol (&gEfiGetPcdInfoProtocolGuid, NULL, (VOID **)&mPiPcdInfo);

    + }

    ASSERT_EFI_ERROR (Status);

    ASSERT (mPiPcdInfo != NULL);

    }

    @@ -108,7 +120,11 @@ GetPcdInfoProtocolPointer (
    EFI_STATUS Status;



    if (mPcdInfo == NULL) {

    - Status = gBS->LocateProtocol (&gGetPcdInfoProtocolGuid, NULL, (VOID **)&mPcdInfo);

    + if (FeaturePcdGet (PcdStandalonePcdDatabaseEnable)) {

    + Status = gBS->LocateProtocol (&gEdkiiPayloadGetStandalonePcdInfoProtocolGuid, NULL, (VOID **)&mPcdInfo);

    + } else {

    + Status = gBS->LocateProtocol (&gGetPcdInfoProtocolGuid, NULL, (VOID **)&mPcdInfo);

    + }

    ASSERT_EFI_ERROR (Status);

    ASSERT (mPcdInfo != NULL);

    }

    diff --git a/MdePkg/Library/DxePcdLib/DxePcdLib.inf b/MdePkg/Library/DxePcdLib/DxePcdLib.inf
    index 3d4d21b442..59d9fe4f11 100644
    --- a/MdePkg/Library/DxePcdLib/DxePcdLib.inf
    +++ b/MdePkg/Library/DxePcdLib/DxePcdLib.inf
    @@ -53,10 +53,18 @@




    [Protocols]

    - gPcdProtocolGuid ## SOMETIMES_CONSUMES

    - gEfiPcdProtocolGuid ## CONSUMES

    - gGetPcdInfoProtocolGuid ## SOMETIMES_CONSUMES

    - gEfiGetPcdInfoProtocolGuid ## SOMETIMES_CONSUMES

    + gPcdProtocolGuid ## SOMETIMES_CONSUMES

    + gEfiPcdProtocolGuid ## SOMETIMES_CONSUMES

    + gGetPcdInfoProtocolGuid ## SOMETIMES_CONSUMES

    + gEfiGetPcdInfoProtocolGuid ## SOMETIMES_CONSUMES

    +

    + gEdkiiPayloadStandalonePcdProtocolGuid ## SOMETIMES_CONSUMES

    + gEdkiiEfiPayloadStandalonePcdProtocolGuid ## SOMETIMES_CONSUMES

    + gEdkiiPayloadGetStandalonePcdInfoProtocolGuid ## SOMETIMES_CONSUMES

    + gEdkiiEfiPayloadGetStandalonePcdInfoProtocolGuid ## SOMETIMES_CONSUMES

    +

    +[FeaturePcd]

    + gEfiMdePkgTokenSpaceGuid.PcdStandalonePcdDatabaseEnable ## CONSUMES



    [Depex.common.DXE_DRIVER, Depex.common.DXE_RUNTIME_DRIVER, Depex.common.DXE_SAL_DRIVER, Depex.common.DXE_SMM_DRIVER]

    gEfiPcdProtocolGuid

    diff --git a/MdePkg/Library/DxePcdLib/PayloadPcdLib.inf b/MdePkg/Library/DxePcdLib/PayloadPcdLib.inf
    new file mode 100644
    index 0000000000..e61296e11a
    --- /dev/null
    +++ b/MdePkg/Library/DxePcdLib/PayloadPcdLib.inf
    @@ -0,0 +1,71 @@
    +## @file

    +# Instance of PCD Library using PCD Protocol.

    +#

    +# There are two PCD protocols as follows:

    +# 1) PCD_PROTOCOL

    +# It is EDKII implementation which support Dynamic/DynamicEx Pcds.

    +# 2) EFI_PCD_PROTOCOL

    +# It is defined by PI specification 1.2, Vol 3 which only support dynamicEx

    +# type Pcd.

    +#

    +# For dynamicEx type PCD, it is compatible between PCD_PROTOCOL and EFI_PCD_PROTOCOL.

    +#

    +# This library instance uses the PCD_PROTOCOL to handle dynamic PCD request and use

    +# EFI_PCD_PROTOCOL to handle dynamicEx type PCD.

    +#

    +# Note: A driver of type DXE_RUNTIME_DRIVER and DXE_SMM_DRIVER can only use this DxePcdLib

    +# in their initialization without any issues to access Dynamic and DynamicEx PCD. They can't

    +# access Dynamic and DynamicEx PCD in the implementation of runtime services and SMI handlers.

    +# Because EFI_PCD_PROTOCOL is DXE protocol that is not available in OS runtime phase.

    +#

    +# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.<BR>

    +#

    +# SPDX-License-Identifier: BSD-2-Clause-Patent

    +#

    +#

    +##

    +

    +[Defines]

    + INF_VERSION = 0x00010005

    + BASE_NAME = DxePcdLib

    + MODULE_UNI_FILE = DxePcdLib.uni

    + FILE_GUID = f9af2f38-09e2-4ff1-b661-5d1c19d9f75c

    + MODULE_TYPE = DXE_DRIVER

    + VERSION_STRING = 1.0

    + LIBRARY_CLASS = PcdLib|DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER SMM_CORE UEFI_APPLICATION
    UEFI_DRIVER

    +

    +#

    +# VALID_ARCHITECTURES = IA32 X64 EBC

    +#

    +

    +[Sources]

    + DxePcdLib.c

    +

    +

    +[Packages]

    + MdePkg/MdePkg.dec

    +

    +

    +[LibraryClasses]

    + BaseMemoryLib

    + UefiBootServicesTableLib

    + DebugLib

    +

    +

    +[Protocols]

    + gPcdProtocolGuid ## SOMETIMES_CONSUMES

    + gEfiPcdProtocolGuid ## SOMETIMES_CONSUMES

    + gGetPcdInfoProtocolGuid ## SOMETIMES_CONSUMES

    + gEfiGetPcdInfoProtocolGuid ## SOMETIMES_CONSUMES

    +

    + gEdkiiPayloadStandalonePcdProtocolGuid ## SOMETIMES_CONSUMES

    + gEdkiiEfiPayloadStandalonePcdProtocolGuid ## SOMETIMES_CONSUMES

    + gEdkiiPayloadGetStandalonePcdInfoProtocolGuid ## SOMETIMES_CONSUMES

    + gEdkiiEfiPayloadGetStandalonePcdInfoProtocolGuid ## SOMETIMES_CONSUMES

    +

    +[FeaturePcd]

    + gEfiMdePkgTokenSpaceGuid.PcdStandalonePcdDatabaseEnable ## CONSUMES

    +

    +[Depex.common.DXE_DRIVER, Depex.common.DXE_RUNTIME_DRIVER, Depex.common.DXE_SAL_DRIVER, Depex.common.DXE_SMM_DRIVER]

    + gEdkiiEfiPayloadStandalonePcdProtocolGuid

    +

    diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
    index b49f88d8e1..44f60e2086 100644
    --- a/MdePkg/MdePkg.dec
    +++ b/MdePkg/MdePkg.dec
    @@ -1000,6 +1000,12 @@
    ## Include/Protocol/PcdInfo.h

    gGetPcdInfoProtocolGuid = { 0x5be40f57, 0xfa68, 0x4610, { 0xbb, 0xbf, 0xe9, 0xc5, 0xfc, 0xda, 0xd3, 0x65 } }



    + ## Payload Standalone Pcd Protocol

    + gEdkiiPayloadStandalonePcdProtocolGuid = {0x8ef6ff48, 0x2260, 0x5407, {0x0d, 0x18, 0x2e, 0x2c, 0xaa, 0x7d,
    0xc9, 0x1f}}

    + gEdkiiEfiPayloadStandalonePcdProtocolGuid = {0x7e50c422, 0xae76, 0xbdc9, {0x16, 0x66, 0xca, 0x67, 0x95, 0x04,
    0x4d, 0xea}}

    + gEdkiiPayloadGetStandalonePcdInfoProtocolGuid = {0xd7214c03, 0x27e0, 0x5b35, {0xd5, 0xb1, 0xeb, 0x1a, 0x50, 0x14,
    0x5e, 0x15}}

    + gEdkiiEfiPayloadGetStandalonePcdInfoProtocolGuid = {0x1039ecdf, 0x5908, 0xf76c, {0x51, 0xf9, 0xae, 0x09, 0xc5, 0xa9,
    0x68, 0x9e}}

    +

    #

    # Protocols defined in PI1.0.

    #

    @@ -1945,6 +1951,12 @@
    # @Prompt Validate ORDERED_COLLECTION structure

    gEfiMdePkgTokenSpaceGuid.PcdValidateOrderedCollection|FALSE|BOOLEAN|0x0000002a



    + ## Indicates if the standalone PCD database is enabled for Payload.<BR><BR>

    + # TRUE - Enable tandalone PCD database is enabled for Payload.<BR>

    + # FALSE - Disable tandalone PCD database is enabled for Payload.<BR>

    + # @Prompt Enable tandalone PCD database is enabled for Payload.

    + gEfiMdePkgTokenSpaceGuid.PcdStandalonePcdDatabaseEnable|FALSE|BOOLEAN|0x0000002e

    +

    [PcdsFixedAtBuild]

    ## Status code value for indicating a watchdog timer has expired.

    # EFI_COMPUTING_UNIT_HOST_PROCESSOR | EFI_CU_HP_EC_TIMER_EXPIRED

    --
    2.30.0.windows.2



    -=-=-=-=-=-=
    Groups.io Links: You receive all messages sent to this group.
    View/Reply Online (#75502): https://edk2.groups.io/g/devel/message/75502
    Mute This Topic: https://groups.io/mt/83046935/1643496
    Group Owner: devel+owner@edk2.groups.io
    Unsubscribe: https://edk2.groups.io/g/devel/unsub [michael.d.kinney@...]
    -=-=-=-=-=-=


    Re: GSOC 2021 EXT4 driver Project

    Michael D Kinney
     

    Hi Pedro,

    Here is a link to background materials to get started with EDK II.

    https://github.com/tianocore-training/Tianocore_Training_Contents/wiki

    The detailed specifications for the EDK II build systems and coding style are:

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

    Best regards,

    Mike

    ===================

    From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
    Sent: Monday, May 24, 2021 12:27 PM
    To: devel@edk2.groups.io
    Subject: [edk2-devel] GSOC 2021 EXT4 driver Project

    Hi everyone,

    Me and my project have been selected for GSoC this year, under Michael Kinney and bret. Thank you for the opportunity to collaborate with you and improve Tianocore!
    If anyone has any questions, please fire away :)
    How do I get started? I'd like to find some easier tasks as to start trying out patch submission and generally programming in a firmware environment.
    Also, I've been talking with my mentors and a relevant question to ask the mailing list is: Where should we put the EXT4 driver?
    Michael said there are other filesystems in MdeModulePkg, but it might be getting too big and proposed the following options:

    1) EXT4 in new package in edk2 repo as a peer to FatPkg.
    2) EXT4 in edk2 repo in MdeModulePkg
    3) EXT4 in edk2-platforms advanced feature package.
    4) EXT4 in edk2 advanced feature package

    As someone that's still learning how to navigate the project's tree(s), this is a bit over my head and so I'd like your opinion on the matter.
    Also, I would love if someone could point me to some good reading material and/or examples of the package/build system, as I couldn't find documentation on those
    and my previous experiment with Tianocore involved looking at FatPkg and mindlessly copying what it was doing.

    Thanks,

    Pedro


    Re: [PATCH v1 1/1] FmpDevicePkg: FmpDeviceLib interface change for Driver Unload support

    John Rahn
     

    Just to get some closure on this thread for the list.

    I've had some additional side discussions with Michael D Kinney about the reasoning behind the patch and wanted to summarize the results after we got to the root of the issue.

    Proposed patch is not required.
    Expected usage of the FmpDxe is as follows:
    Sample FmpDxe code incorporating FmpDeviceLib for single Fmp instance on ImageHandle.
    UEFI driver incorporating FmpDxeLib and FmpDeviceLib for FmpInstance(s) on ControllerHandle(s)

    Attempting to create a driver using and based on the sample FmpDxe code and documentation currently available and extending it to the UEFI driver model can be done but results in inability to properly specify a driver unload function for the driver without modifications to the project.
    This is not the recommended process as it mixes the expected usage models.

    The solution to the DriverUnload issue is to create a UEFI driver leveraging FmpDxeLib and FmpDeviceLib with the DRIVER_UNLOAD specified in the UEFI driver INF file and is the proper solution.

    -----Original Message-----
    From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of John Rahn via groups.io
    Sent: Tuesday, April 20, 2021 4:25 PM
    To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io
    Cc: Liming Gao <gaoliming@...>; Jiang, Guomin <guomin.jiang@...>; Xu, Wei6 <wei6.xu@...>; John Rahn <JRahn@...>
    Subject: Re: [edk2-devel] [PATCH v1 1/1] FmpDevicePkg: FmpDeviceLib interface change for Driver Unload support

    External email: Use caution opening links or attachments


    Driver unload in the sample FmpDxe is currently configured to directly call UninstallFmpInstance (UNLOAD_IMAGE) with the ImageHandle and EFI_UNSUPPORTED is returned because the driver binding provided by FmpDeviceLib is managing the instance on the DeviceHandle, not the ImageHandle.
    The FmpDeviceLib supporting the UEFI Driver Binding model is never notified of the driver unload and the Fmp Instance(s) are not uninstalled and the driver is not unloaded.
    The sample FmpDxe does not provide a interface for the required driver unload notification to be passed to the FmpDeviceLib implementation.
    Attempting to have the UninstallFmpInstance in the sample FmpDxe check Fmp instances for drivers managing the device and calling DriverStop with the DeviceHandle didn't align with the standard driver implementation model and was not as straightforward of an approach as exposing a driver unload interface for FmpDeviceLib use for the driver unload notification, so that the FmpDeviceLib can properly stop on it's managed devices and clean up any internal context/private data.

    A FmpDeviceLib following the driver binding model and implementing the proposed interface can unload the Fmp instance(s) being managed and clean up any allocations before exit. Any remaining allocations in the FmpDxe are properly dealt with in the UninstallFmpInstance path.

    I was able to successfully build a functional FmpDeviceLib that will properly unload the installed Fmp instance(s) using the proposed interface change.

    -----Original Message-----
    From: Kinney, Michael D <michael.d.kinney@...>
    Sent: Tuesday, April 20, 2021 3:37 PM
    To: John Rahn <JRahn@...>; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>
    Cc: Liming Gao <gaoliming@...>; Jiang, Guomin <guomin.jiang@...>; Xu, Wei6 <wei6.xu@...>
    Subject: RE: [PATCH v1 1/1] FmpDevicePkg: FmpDeviceLib interface change for Driver Unload support

    External email: Use caution opening links or attachments


    Hi John,

    The FmpDeviceLib provides the RegisterFmpInstaller() and RegisterFmpUninstaller() APIs for UEFI Driver Model drivers to manage the FMP contexts.

    Why does the Unload need to be extended into the FmpDeviceLib when these APIs are used? I would think that a UEFI Driver Model Driver that supports FMP could call Stop() on all instances when an Unload() request is received and the Stop() services would use the FMP Uninstaller path to clean up the FMP instances. If all Stops() succeed, then the UEFI Driver that is producing the FMP instances can be unloaded,


    /**
    Callback function that installs a Firmware Management Protocol instance onto
    a handle.

    @param[in] Handle The device handle to install a Firmware Management
    Protocol instance.

    @retval EFI_SUCCESS A Firmware Management Protocol instance was
    installed onto Handle.
    @retval EFI_INVALID_PARAMETER Handle is invalid
    @retval other A Firmware Management Protocol instance could
    not be installed onto Handle.

    **/
    typedef
    EFI_STATUS
    (EFIAPI *FMP_DEVICE_LIB_REGISTER_FMP_INSTALLER)(
    IN EFI_HANDLE Handle
    );

    /**
    Callback function that uninstalls a Firmware Management Protocol instance from
    a handle.

    @param[in] Handle The device handle to uninstall a Firmware Management
    Protocol instance.

    @retval EFI_SUCCESS A Firmware Management Protocol instance was
    uninstalled from Handle.
    @retval EFI_INVALID_PARAMETER Handle is invalid
    @retval other A Firmware Management Protocol instance could
    not be uninstalled from Handle.

    **/
    typedef
    EFI_STATUS
    (EFIAPI *FMP_DEVICE_LIB_REGISTER_FMP_UNINSTALLER)(
    IN EFI_HANDLE Handle
    );

    /**
    Provide a function to install the Firmware Management Protocol instance onto a
    device handle when the device is managed by a driver that follows the UEFI
    Driver Model. If the device is not managed by a driver that follows the UEFI
    Driver Model, then EFI_UNSUPPORTED is returned.

    @param[in] FmpInstaller Function that installs the Firmware Management
    Protocol.

    @retval EFI_SUCCESS The device is managed by a driver that follows the
    UEFI Driver Model. FmpInstaller must be called on
    each Driver Binding Start().
    @retval EFI_UNSUPPORTED The device is not managed by a driver that follows
    the UEFI Driver Model.
    @retval other The Firmware Management Protocol for this firmware
    device is not installed. The firmware device is
    still locked using FmpDeviceLock().

    **/
    EFI_STATUS
    EFIAPI
    RegisterFmpInstaller (
    IN FMP_DEVICE_LIB_REGISTER_FMP_INSTALLER FmpInstaller
    );

    /**
    Provide a function to uninstall the Firmware Management Protocol instance from a
    device handle when the device is managed by a driver that follows the UEFI
    Driver Model. If the device is not managed by a driver that follows the UEFI
    Driver Model, then EFI_UNSUPPORTED is returned.

    @param[in] FmpUninstaller Function that installs the Firmware Management
    Protocol.

    @retval EFI_SUCCESS The device is managed by a driver that follows the
    UEFI Driver Model. FmpUninstaller must be called on
    each Driver Binding Stop().
    @retval EFI_UNSUPPORTED The device is not managed by a driver that follows
    the UEFI Driver Model.
    @retval other The Firmware Management Protocol for this firmware
    device is not installed. The firmware device is
    still locked using FmpDeviceLock().

    **/
    EFI_STATUS
    EFIAPI
    RegisterFmpUninstaller (
    IN FMP_DEVICE_LIB_REGISTER_FMP_UNINSTALLER FmpUninstaller
    );

    Best regards,

    Mike

    -----Original Message-----
    From: John Rahn <jrahn@...>
    Sent: Tuesday, April 20, 2021 2:36 PM
    To: devel@edk2.groups.io
    Cc: Liming Gao <gaoliming@...>; Kinney, Michael D
    <michael.d.kinney@...>; Jiang, Guomin <guomin.jiang@...>;
    Xu, Wei6 <wei6.xu@...>
    Subject: [PATCH v1 1/1] FmpDevicePkg: FmpDeviceLib interface change
    for Driver Unload support

    https://bugzilla.tianocore.org/show_bug.cgi?id=3342
    FmpDeviceLib interface for Driver Unload is missing
    Add FmpDeviceLibUnloadImage function declaration and NULL sample.
    Add FmpDxeUnloadImage function.
    Replace UNLOAD_IMAGE function in FmpDxe sample with FmpDxeUnloadImage.

    Cc: Liming Gao <gaoliming@...>
    Cc: Michael D Kinney <michael.d.kinney@...>
    Cc: Guomin Jiang <guomin.jiang@...>
    Cc: Wei6 Xu <wei6.xu@...>
    Signed-off-by: John Rahn <jrahn@...>
    ---
    FmpDevicePkg/FmpDxe/FmpDxe.inf | 2 +-
    FmpDevicePkg/Include/Library/FmpDeviceLib.h | 21 +++++++++++++++++
    FmpDevicePkg/FmpDxe/FmpDxe.c | 21 +++++++++++++++++
    FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c | 24
    ++++++++++++++++++++
    4 files changed, 67 insertions(+), 1 deletion(-)

    diff --git a/FmpDevicePkg/FmpDxe/FmpDxe.inf
    b/FmpDevicePkg/FmpDxe/FmpDxe.inf index eeb904a09148..2de9e3e4f2ad
    100644
    --- a/FmpDevicePkg/FmpDxe/FmpDxe.inf
    +++ b/FmpDevicePkg/FmpDxe/FmpDxe.inf
    @@ -17,7 +17,7 @@ [Defines]
    MODULE_TYPE = DXE_DRIVER
    VERSION_STRING = 1.0
    ENTRY_POINT = FmpDxeEntryPoint
    - UNLOAD_IMAGE = UninstallFmpInstance
    + UNLOAD_IMAGE = BZ3342FmpDxeUnloadImage

    #
    # The following information is for reference only and not required by the build tools.
    diff --git a/FmpDevicePkg/Include/Library/FmpDeviceLib.h
    b/FmpDevicePkg/Include/Library/FmpDeviceLib.h
    index 6abd99fa1f47..d9da5b940886 100644
    --- a/FmpDevicePkg/Include/Library/FmpDeviceLib.h
    +++ b/FmpDevicePkg/Include/Library/FmpDeviceLib.h
    @@ -104,6 +104,27 @@ RegisterFmpUninstaller (
    IN FMP_DEVICE_LIB_REGISTER_FMP_UNINSTALLER FmpUninstaller
    );

    +/**
    + Function that unloads a Firmware Management Device Library based
    +driver instance when
    + the FmpDeviceLib supports the driver binding model.
    + If the FmpDeviceLib does not support the UEFI driver model, the
    +FmpDeviceLib Unload Image
    + should return EFI_UNSUPPORTED.
    +
    + @param[in] ImageHandle The driver handle managing the Firmware Management Protocol instance to unload.
    +
    + @retval EFI_SUCCESS Driver image was removed successfully.
    + @retval EFI_UNSUPPORTED The device is not managed by a driver that follows
    + the UEFI Driver Model.
    + @retval EFI_INVALID_PARAMETER ImageHandle is NULL.
    + @retval EFI_INVALID_PARAMETER ImageHandle does not match driver image handle.
    + @retval other Driver image was not removed.
    +**/
    +EFI_STATUS
    +EFIAPI
    +BZ3342FmpDeviceLibUnloadImage (
    + IN EFI_HANDLE ImageHandle
    + );
    +
    /**
    Set the device context for the FmpDeviceLib services when the device is
    managed by a driver that follows the UEFI Driver Model. If the
    device is not diff --git a/FmpDevicePkg/FmpDxe/FmpDxe.c
    b/FmpDevicePkg/FmpDxe/FmpDxe.c index 6b0675ea38f8..6680a381b8fe 100644
    --- a/FmpDevicePkg/FmpDxe/FmpDxe.c
    +++ b/FmpDevicePkg/FmpDxe/FmpDxe.c
    @@ -1813,6 +1813,27 @@ UninstallFmpInstance (
    return EFI_SUCCESS;
    }

    +/**
    + Unloads the application and its installed protocol.
    +
    + @param ImageHandle Handle that identifies the image to be unloaded.
    +
    + @retval EFI_SUCCESS The image has been unloaded.
    +
    +**/
    +EFI_STATUS
    +EFIAPI
    +BZ3342FmpDxeUnloadImage (
    + IN EFI_HANDLE ImageHandle
    + )
    +{
    + if (mFmpSingleInstance) {
    + return UninstallFmpInstance (ImageHandle);
    + } else {
    + return BZ3342FmpDeviceLibUnloadImage (ImageHandle);
    + }
    +}
    +
    /**
    Unloads the application and its installed protocol.

    diff --git a/FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c
    b/FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c
    index f4f57b29bdb1..4d2cbc64b7c6 100644
    --- a/FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c
    +++ b/FmpDevicePkg/Library/FmpDeviceLibNull/FmpDeviceLib.c
    @@ -41,6 +41,30 @@ RegisterFmpInstaller (
    return EFI_UNSUPPORTED;
    }

    +/**
    + Function that unloads a Firmware Management Device Library based
    +driver instance when
    + the FmpDeviceLib supports the driver binding model.
    + If the FmpDeviceLib does not support the UEFI driver model, the
    +FmpDeviceLib Unload Image
    + should return EFI_UNSUPPORTED.
    +
    + @param[in] ImageHandle The driver handle managing the Firmware Management Protocol instance to unload.
    +
    + @retval EFI_SUCCESS Driver image was removed successfully.
    + @retval EFI_UNSUPPORTED The device is not managed by a driver that follows
    + the UEFI Driver Model.
    + @retval EFI_INVALID_PARAMETER ImageHandle is NULL.
    + @retval EFI_INVALID_PARAMETER ImageHandle does not match driver image handle.
    + @retval other Driver image was not removed.
    +**/
    +EFI_STATUS
    +EFIAPI
    +BZ3342FmpDeviceLibUnloadImage (
    + IN EFI_HANDLE ImageHandle
    + )
    +{
    + return EFI_UNSUPPORTED;
    +}
    +
    /**
    Provide a function to uninstall the Firmware Management Protocol instance from a
    device handle when the device is managed by a driver that follows
    the UEFI
    --
    2.17.1


    GSOC 2021 EXT4 driver Project

    Pedro Falcato
     

    Hi everyone,

    Me and my project have been selected for GSoC this year, under Michael Kinney and bret. Thank you for the opportunity to collaborate with you and improve Tianocore!
    If anyone has any questions, please fire away :)
    How do I get started? I'd like to find some easier tasks as to start trying out patch submission and generally programming in a firmware environment.
    Also, I've been talking with my mentors and a relevant question to ask the mailing list is: Where should we put the EXT4 driver?
    Michael said there are other filesystems in MdeModulePkg, but it might be getting too big and proposed the following options:

    1) EXT4 in new package in edk2 repo as a peer to FatPkg.
    2) EXT4 in edk2 repo in MdeModulePkg
    3) EXT4 in edk2-platforms advanced feature package.
    4) EXT4 in edk2 advanced feature package

    As someone that's still learning how to navigate the project's tree(s), this is a bit over my head and so I'd like your opinion on the matter.
    Also, I would love if someone could point me to some good reading material and/or examples of the package/build system, as I couldn't find documentation on those
    and my previous experiment with Tianocore involved looking at FatPkg and mindlessly copying what it was doing.

    Thanks,

    Pedro 


    Re: 回复: [edk2-devel] Generic MinPlatform

    Daniel Schaefer
     

    • Rather than commenting out things you don’t need in the build, our thinking was to allow some unnecessary building in the interest of reducing porting complexity.  It doesn’t really matter if you don’t need the PciCf8 library as long as it builds fine.
    • If you need the PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf Instead of the PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can just override it in your DSC file after you have included the CoreCommonLib.dsc.  This is to reduce the number of includes that a typical board port needs to deal with correctly, but allow fine tuning and optimization later.
  • Hm, you're right. However I added another PCD to exclude things that RISC-V and many other non-x86 platforms don't have: SMM, port-mapped I/O, PC/AT architecture:


    And what's most relevant to Kaaira, the commit to make my QEMU platform use MinPlatform include files:

    Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.
    Yes, absolutely. As above, for now I created one for common x86 concepts. But there should probably be one for PCI and USB should move to AdvancedFeatures, like you said.
    The other two RISC-V platforms I'm working on don't have PCI and one of them doesn't have USB.

    Add “Core System Design” includes.  E.G. one for x86, one for QEMU, one for RISKV, etc.  I am not sure how many of these we would need.
    Right, that's a good idea. Kaaira and me can create one for QEMU with all of the virtio drivers.
    And those for x86 and RISC-V wouldn't actually too big, as you can see in my change. RISC-V needs even less special modules.

    Thanks,
    Daniel


    From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Oram, Isaac W <isaac.w.oram@...>
    Sent: Friday, May 21, 2021 11:38
    To: Schaefer, Daniel <daniel.schaefer@...>; devel@edk2.groups.io <devel@edk2.groups.io>; gaoliming@... <gaoliming@...>; kaaira7319@... <kaaira7319@...>; Ni, Ray <ray.ni@...>; mikuback@... <mikuback@...>
    Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
    Subject: Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
     

    I think we should patch first and move to a common location later.

     

    Looking at some of your changes and comments, I have these comments:

    • Rather than commenting out things you don’t need in the build, our thinking was to allow some unnecessary building in the interest of reducing porting complexity.  It doesn’t really matter if you don’t need the PciCf8 library as long as it builds fine.
    • If you need the PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf Instead of the PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf, you can just override it in your DSC file after you have included the CoreCommonLib.dsc.  This is to reduce the number of includes that a typical board port needs to deal with correctly, but allow fine tuning and optimization later.
    • Rather than commenting out or adding !if modifications, you can set the feature PCD to false in your DSC file before including the file.  We are allowed to have multiple sections and the tools do a good job of applying them and aggregating them in sensible ways.  For example:

    #!if gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable == TRUE

    #  PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf

    #!endif

      • If you just have:

    [PcdsFeatureFlag]

      #

      # MinPlatform control flags

      #

      gMinPlatformPkgTokenSpaceGuid.PcdStopAfterDebugInit     |FALSE

      gMinPlatformPkgTokenSpaceGuid.PcdStopAfterMemInit       |FALSE

      gMinPlatformPkgTokenSpaceGuid.PcdBootToShellOnly        |FALSE

      gMinPlatformPkgTokenSpaceGuid.PcdUefiSecureBootEnable   |FALSE

      gMinPlatformPkgTokenSpaceGuid.PcdTpm2Enable             |FALSE

      gMinPlatformPkgTokenSpaceGuid.PcdSmiHandlerProfileEnable|TRUE

      gMinPlatformPkgTokenSpaceGuid.PcdPerformanceEnable      |FALSE

    !include $(PLATFORM_PACKAGE)/Include/Dsc/CoreCommonLib.dsc

      • Then you should get the same result you want.

     

    This is useful feedback and we should think about how we want to enable optimization (stage 7) in a reasonable way.  We haven’t gotten that far into the optimization details as we wanted to get the basics worked out, but it might very much make sense to make more of these things controlled by MinPlatform Arch defined feature flags.  Or to move to Advanced Features.  And some things we haven’t cleaned up yet.  We still have USB in common includes, but those drivers should move to an Advanced Feature.  The main thing is we want intelligent default behavior so new board porting people can get productive fast without having to know all these edk2 special features.  Then as they get things working, they can start to take advantage of more edk2 and UEFI capabilities as they learn them.  Eventually hitting an optimization phase where common things can be quickly stripped out if not needed.  I hadn’t thought much about build optimization, but I think that this is reasonable to include in scope.

     

    Looking at your feedback/challenges, I see a few options:

    ·         Add more MinPlatform Arch defined feature flags for PCI, SMM, etc.

    ·         Add Advanced Features for them

    ·         Add “Core System Design” includes.  E.G. one for x86, one for QEMU, one for RISKV, etc.  I am not sure how many of these we would need.

     

    Thoughts and preferences?  I think that we need to keep in mind KISS for new board ports and new users.

     

    The checklists should be “Board Porting Activity Checklist” and unfortunately for you both, you are making the first reference QemuOpenBoardPkg and boards and that is a little more involved than making derivatives, which is what those checklists are going to help the most.

     

    Regards,
    Isaac

     

     

    From: Schaefer, Daniel <daniel.schaefer@...>
    Sent: Thursday, May 20, 2021 7:27 PM
    To: Oram, Isaac W <isaac.w.oram@...>; devel@edk2.groups.io; gaoliming@...; kaaira7319@...; Ni, Ray <ray.ni@...>; mikuback@...
    Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
    Subject: Re:
    回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

     

    Thanks for the answers, that's very helpful, guys!

     

    I've started to replace some of my DSC and FDF with the include files mentioned by Michael.

    Since RISC-V doesn't have I/O registers, SMM and some other things, I had to make some changes but not too many.

    Maybe for Qemu there would have be some more non-Intel changes.

    Would you accept patches to make it more arch agnostic? Or should we first move it out of the Intel directory?

     

    Sorry for hijacking your thread Kaaira, but I hope this discussion would also be helpful for you 🙂

    Just like you, I'm trying to convert a QEMU platform to MinPlatform. (And then the other RISC-V platforms)

    If you want to have a look, you can check out my progress here: https://github.com/riscv/riscv-edk2-platforms/commits/riscv-virt-minplatform-gh-actions

     

    My plan is:

    1. Make DSC and FDF smaller by including generic files (WIP)
    2. Try to take advantage of "AdvancedFeatures"
    3. Reformat the FD into the FVs mandated by the MinPlatform spec
    4. Check the detailed requirements of each stage (e.g. required functions, build files, ...)

    I see that each stage in the MinPlatform spec has a checklist. They don't look like checklist but rather steps to achieve a certain state but that's also ok.

     

    Thanks,

    Daniel

     


    From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Michael Kubacki <mikuback@...>
    Sent: Friday, May 21, 2021 00:32
    To: Oram, Isaac W <
    isaac.w.oram@...>; devel@edk2.groups.io <devel@edk2.groups.io>; Schaefer, Daniel <daniel.schaefer@...>; gaoliming@... <gaoliming@...>; kaaira7319@... <kaaira7319@...>; Ni, Ray <ray.ni@...>
    Subject: Re:
    回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project

     

    Daniel,

    You will specifically find attempts to consolidate common libraries and
    modules in DSC and FDF files that can be included into a board package
    here -
    https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Include.
    Files are split such that they can be included in the corresponding
    section in the board package DSC/FDF file. Note there are some mixed
    opinions I've encountered in the industry on the complexity trade off
    associated with includes in DSC and FDF files.

    But as Isaac mentioned, while MinPlatform is designed to support
    multiple architectures, it has only be enabled on Intel platforms,
    therefore, you should expect to encounter some problems enabling a
    different architecture but identifying and/or resolving those would be
    very valuable.

    As you are exploring how to port a platform to MinPlatform I also
    recommend familiarizing yourself the concept of advanced features
    described here -
    https://github.com/tianocore/edk2-platforms/blob/master/Features/Intel/Readme.md.
    You might find your board package is relatively simpler than the
    original platform package after accounting for advanced features being
    separated out.

    Thanks,
    Michael


    On 5/20/2021 8:05 AM, Oram, Isaac W wrote:
    > Daniel,
    >
    > The MinPlatform spec was intended to be architecture and product
    > independent for a mainstream set of products.  It is intended to
    > constrain some of the nearly unlimited extensibility and flexibility of
    > UEFI specs and edk2 codebase.  We took an 80/20 kind of approach.  Base
    > design should work for 80% of designs, but some will need to leverage
    > full edk2 and UEFI specification flexibility.  I think that a basic QEMU
    > kind of port would fit in 80% target.  I would ultimately like to see a
    > progression of edk2 use that starts with QEMU then moves more seamlessly
    > to open designs and then proprietary product designs.  MinPlatform
    > consistency is hoped to help that developer ramp into system firmware
    > productivity.
    >
    > We have only seen MinPlatform applied to Intel based products so far.
    > Which is why we are not rushing to move the spec from a 0.7 broad
    > feedback state to a 1.0 initially complete state.  Like edk2,
    > MinPlatformPkg and BoardModulePkg content is intended to support
    > multiple silicon and product architectures and we will happily promote
    > content out of Intel scope when that is an accurate reflection of use
    > and not just wishful thinking.  While 100% of uses are Intel scope, it
    > makes sense to land in the Intel part of edk2-platforms repo.  Similar
    > logic applies to Features/Intel content, though more there may have ties
    > to Intel specific product features.
    >
    > The Minimum Platform Arch spec details base requirements for FV layout
    > (thus enabling more common code to publish FV details), base silicon
    > policy configuration flow (thus more common PEIM/drivers to gather
    > config information and reduce board porting to relatively simple
    > libraries), and such things.  By enabling more common PEIM and drivers,
    > we hope to see benefits to ease of use and consistent quality. Similar
    > approaches for the other elements of the spec should help to improve
    > code sharing.
    >
    > Anyway, yes, it should be able to help you reduce the copies of mostly
    > common code that you encountered and the code and spec are open to
    > welcome the additional use and feedback from additional applications.
    >
    > Regards,
    > Isaac
    >
    > *From:*devel@edk2.groups.io <
    devel@edk2.groups.io> *On Behalf Of *Daniel
    > Schaefer
    > *Sent:* Wednesday, May 19, 2021 8:40 PM
    > *To:*
    devel@edk2.groups.io; gaoliming@...;
    >
    kaaira7319@...; Ni, Ray <ray.ni@...>;
    >
    mikuback@...
    > *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
    >
    > Hi,
    >
    > that sounds like a great project!
    >
    > I'm currently trying to create an equivalent of OvmfPkg for the RISCV64
    > generic QEMU virt machine.
    >
    > I don't like how much of my DSC and FDF file has modules that pretty
    > much all platforms should have.
    >
    > MinPlatform would help reduce that, right?
    >
    > Is MinPlatform flexible enough to account for non-X64 platforms?
    >
    > If so, then I think Kaaira and I could collaborate.
    >
    > Cheers,
    > Daniel
    >
    > ------------------------------------------------------------------------
    >
    > *From:*devel@edk2.groups.io
    > <
    mailto:devel@edk2.groups.io><devel@edk2.groups.io
    > <mailto:devel@edk2.groups.io>> on behalf of Michael Kubacki
    > <mikuback@... <
    mailto:mikuback@...>>
    > *Sent:* Thursday, May 20, 2021 02:57
    > *To:*
    devel@edk2.groups.io
    > <
    mailto:devel@edk2.groups.io><devel@edk2.groups.io
    > <mailto:devel@edk2.groups.io>>; gaoliming@...
    > <
    mailto:gaoliming@...><gaoliming@...
    > <mailto:gaoliming@...>>; kaaira7319@...
    > <
    mailto:kaaira7319@...><kaaira7319@...
    > <mailto:kaaira7319@...>>; 'Ray Ni' <ray.ni@...
    > <mailto:ray.ni@...>>
    > *Subject:* Re: 回复: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
    >
    > I also wanted to add that I will be setting up weekly video calls
    > including Ray that we can use to supplement mailing list communication.
    >
    > I suggest the primary communication mechanism be the mailing list and we
    > use those calls for clarification, detailed project planning, and topics
    > not directly relevant to the list.
    >
    > Regards,
    > Michael
    >
    > On 5/19/2021 10:29 AM, Michael Kubacki wrote:
    >> Thanks Liming.
    >>
    >> Hi Kaaira,
    >>
    >> Welcome! You can contact me at
    mikuback@... <mailto:mikuback@...>. You
    > will
    >> sometimes see my email as
    michael.kubacki@... <mailto:michael.kubacki@...>and
    > that is fine
    >> to use for communication though I tend to not use it on the mailing list
    >> due to way the mail server manipulates plaintext email.
    >>
    >> GENERIC RESOURCES
    >>
    >> I'm sharing some general resources in case you are not already familiar
    >> with them:
    >>
    >> 1.
    https://github.com/tianocore-training/Tianocore_Training_Contents/wiki
    > <
    https://github.com/tianocore-training/Tianocore_Training_Contents/wiki>
    >>
    >> This one is good for topics like UEFI overview, EDK II concepts, and
    >> Minimum Platform.
    >>
    >> In particular for your project, I recommend looking through the
    >> MinPlatform training -
    >>
    https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf
    > <
    https://github.com/tianocore-training/Presentation_FW/blob/master/FW/Presentations/_D_05_EDK_II_Open_Source_MinPlatform_pres_gp.pdf>
    >>
    >>
    >> 2.
    >>
    https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html
    > <
    https://software.intel.com/content/www/us/en/develop/articles/unified-extensible-firmware-interface.html>
    >>
    >>
    >> These whitepapers are useful when you need more in depth detail about a
    >> particular area (like capsule update or work related to the memory map).
    >> I recommend bookmarking it and keeping it in mind as a reference.
    >>
    >> 3.
    https://uefi.org/learning_center/presentationsandvideos/
    > <
    https://uefi.org/learning_center/presentationsandvideos/>
    >>
    >> Scroll through here if you have some time and see if there's anything
    >> interesting. To help keep on your project schedule I don't think these
    >> are as important but there is a lot of interesting material there.
    >>
    >> Reading through some of the key concepts in Beyond BIOS can be helpful
    >> and like the UEFI, ACPI, and PI (Platform Initialization) specs at
    >>
    https://uefi.org/specifications <https://uefi.org/specifications>, I
    > believe they are most useful as
    >> references when you are solving specific problems.
    >>
    >> PROJECT-SPECIFIC RESOURCES
    >>
    >> Since your project involves creating QEMU board within the Minimum
    >> Platform architecture, you can start looking into:
    >>
    >> 1. QEMU - An open source machine emulator
    >> 2. Minimum Platform Architecture - A software architecture to create
    >> basic platform firmware that can be extended with advanced functionality.
    >> 3. Intel FSP - Try to understand the high-level goals and how FSP
    >> interfaces with firmware.
    >>
    >> 1. QEMU -
    https://www.qemu.org/  <https://www.qemu.org/>
    >>
    >> Please set up the QEMU environment. Your QemuOpenBoardPkg will need to
    >> run on qemu-system-x86_64 at a minimum with a 32-bit PEI and a 64-bit
    >> DXE phase. Most real hardware firmwares also use a 32-bit PEI and a
    >> 64-bit DXE.
    >>
    >> I suggest you start with the OvmfPkg README -
    >>
    https://github.com/tianocore/edk2/blob/master/OvmfPkg/README
    > <
    https://github.com/tianocore/edk2/blob/master/OvmfPkg/README>
    >>
    >> As an initial step you can try to build an OVMF FW with a 32-bit PEI
    >> (IA32) and 64-bit DXE (X64) and boot to the EFI shell.
    >> OvmfPkg/OvmfPkgIa32X64.dsc can be used to build a firmware for these
    >> target architectures.
    >>
    >> Any time you submit patches to edk2, you can check edk2/maintainers.txt
    >> -
    https://github.com/tianocore/edk2/blob/master/Maintainers.txt
    > <
    https://github.com/tianocore/edk2/blob/master/Maintainers.txt>for the
    >> appropriate maintainers and reviewers to CC on the patch. As you can
    >> see, Laszlo and Ard are the maintainers for OvmfPkg and Jordan is a
    >> reviewer. If there are any questions that require deep expertise in QEMU
    >> or OVMF, we will reach out to them. The Minimum Platform code is
    >> maintained in the edk2-platforms repository and it has a similar
    >> maintainers.txt file for its packages -
    >>
    https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt
    > <
    https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt>.
    >>
    >> I suggest you try sending a very trivial patch for a change in the
    >> edk2-platforms repository -
    https://github.com/tianocore/edk2-platforms
    > <
    https://github.com/tianocore/edk2-platforms>
    >> to make sure that your git environment is set up properly to format edk2
    >> patches and your email service can send patches correctly.
    >>
    >> We can discuss the details about how to set up your environment and what
    >> to change when you are ready. You can use this page to get started -
    >>
    https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute
    > <
    https://github.com/tianocore/tianocore.github.io/wiki/How-To-Contribute>.
    >>
    >> 2. EDK II Minimum Platform Specification -
    >>
    https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/ 
    > <
    https://edk2-docs.gitbook.io/edk-ii-minimum-platform-specification/>
    >>
    >> For your project, this spec will be very useful. It describes why
    >> Minimum Platform was created and how it works at a high-level. Like the
    >> code, this document is open and available to the community. You might
    >> contribute content here in addition to your code. You can fix any bugs
    >> or update content in the spec using git patches and the mailing list
    >> similar to code.
    >>
    >> 3. Intel FSP -
    >>
    https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
    > <
    https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html>
    >>
    >>
    >> For more information about Intel FSP check out the Intel FSP External
    >> Architecture Specification in the link above. v2.2 is currently the
    >> latest version.
    >>
    >> There is an open source QEMU FSP available here
    >>
    https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64
    > <
    https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64>. You will
    >> find the existing Minimum Platform boards use Intel FSP while OvmfPkg
    >> does not use FSP.
    >>
    >> Firmware is really best learned hands on. Using the links and background
    >> info above, I suggest:
    >>
    >> 1. Read the OvmfPkg readme.
    >> 2. Build a 32-bit PEI and 64-bit DXE OVMF FW and boot it to EFI shell
    >> using QEMU.
    >> 3. Reading through the EDK II Minimum Platform Specification to gain a
    >> high level understanding of Minimum Platform.
    >> 4. Connect what you read to the code in
    >>
    https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel
    > <
    https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel>.
    >> Focus on higher level pieces like the board initialization library.
    >> 5. Note what each board package is doing. You will find common patterns
    >> for what a board package needs to implement to make the system boot.
    >> 6. As you read through the code, reference the general resources listed
    >> above to understand anything not Minimum Platform specific. Part of the
    >> learning process is knowing which spec to use for different interfaces.
    >> If you're unsure which spec something is in, feel free to reach out.
    >> 7. While looking through the code in edk2-platforms, think about a patch
    >> you can send to edk2-platforms for something very trivial such as a bug
    >> fix or documentation update.
    >> 8. Send the patch and get it reviewed-by the appropriate
    >> maintainers/reviewers and merged into the master branch.
    >> 9. Read through the code in OvmfPkg. Try to map the work it is doing to
    >> the board code you reviewed in edk2-platforms.
    >> 10. At this point, you could start outlining major pieces of
    >> initialization in OVMF and how they might map to a board package. Try to
    >> identify where the initialization pieces would reside in the board
    >> package and try to identify challenges that might arise. We will likely
    >> spend quite a bit of time here before jumping into too much code.
    >>
    >> I know this is a lot of info. Please don't hesitate to reach out if you
    >> have any questions and I look forward to working with you.
    >>
    >> Regards,
    >> Michael
    >>
    >> On 5/18/2021 6:05 PM, gaoliming wrote:
    >>> Include Michael Kubacki.
    >>>
    >>> Thanks
    >>> Liming
    >>>> -----邮件原件-----
    >>>> 发件人:
    devel@edk2.groups.io
    > <
    mailto:devel@edk2.groups.io><devel@edk2.groups.io
    > <mailto:devel@edk2.groups.io>> 代表 KAAIRA
    >>>> GUPTA
    >>>> 发送时间: 2021518 22:42
    >>>> 收件人: Ray Ni <ray.ni@... <
    mailto:ray.ni@...>>;
    >
    devel@edk2.groups.io <mailto:devel@edk2.groups.io>
    >>>> 主题: Re: [edk2-devel] GSoC 2021 Qemu OpenBoardPkg Project
    >>>>
    >>>> On Tue, May 18, 2021 at 08:01:57PM +0530, Kaaira Gupta wrote:
    >>>>> Hey everyone,
    >>>>>
    >>>>> I have been selected as a student developer for the project MinPlatform
    >>>>> Qemu OpenBoardPkg under the mentors Ray Ni and Michael Kubacki.
    >>>> Thankyou
    >>>>> for this opportunity. I have been over the major chapters of Beyond
    >>>>> BIOS
    >>>>> as recommended by Nate DeSimone. I want to get familiar with the code
    >>>>> now to help me undersatnd the community practices and get my hands
    >>>>> dirty. Where should I start? What development environment do I need?
    >>>>> How can I use this community bonding period to give me a better start
    >>>>> for the coding phase?
    >>>>>
    >>>>> How do the mentors want me to connect with them? Can we have a meet
    >>>> to
    >>>>> discuss this project's plan to add more details? This would be very
    >>>>> helpful for me considering I don't have prior experience with EDK2.
    >>>>
    >>>> I noticed that the mail-id that I have used of Michael Kubacki doesn't
    >>>> exist anymore. Please let me know how I can contact him.
    >>>>
    >>>>>
    >>>>> Thank you,
    >>>>> Kaaira
    >>>>
    >>>> Thanks,
    >>>> Kaaira
    >>>>
    >>>>
    >>>>
    >>>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >
    >
    >
    >
    >
    >





    Re: [edk2-platforms][PATCH V4 00/11] Add SMBIOS tables for Arm's Reference Design platforms

    Sami Mujawar
     

    Hi Ard,

    EDKII is in hard feature freeze starting 2021-05-24 (See https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning).


    However, does this apply to the edk2-platforms repo as well? Can you let me know, please?

    Regards,

    Sami Mujawar

    On 24/05/2021 03:28 PM, Pranav Madhu wrote:
    Changes since V3:
    - Add UpdateMemorySize API to update memory size information as suggested by Sami.

    Changes since V2:
    - Addressed comments from Sami
    - Picked up Sami's reviewed-by tags.

    Changes since V1:
    - Rebase the patches on top of latest master branch

    SMBIOS provides basic hardware and firmware configuration information
    through table-driven data structure. This patch series adds SMBIOS
    support for Arm's SGI/RD platforms.

    The first patch in this series defines platform-id values for the
    RD-N2 platform library header. The second patch add SgiGetProductId API,
    which is used by the SMBIOS driver to distinguish between the platforms,
    and install the right table. The third patch in this series adds SMBIOS
    driver support that allows for installation of multiple SMBIOS tables.
    And subsequent patches in this series add SMBIOS tables, which are
    mandatory as per Arm serverready SBBR specification.

    Link to github branch with the patches in this series -
    https://github.com/Pranav-Madhu/edk2-platforms/tree/topics/rd_smbios

    Pranav Madhu (11):
    Platform/Sgi: Define RD-N2 platform id values
    Platform/Sgi: Add GetProductId API for SGI/RD Platforms
    Platform/Sgi: Add Initial SMBIOS support
    Platform/Sgi: Add SMBIOS Type1 Table
    Platform/Sgi: Add SMBIOS Type3 Table
    Platform/Sgi: Add SMBIOS Type4 Table
    Platform/Sgi: Add SMBIOS Type7 Table
    Platform/Sgi: Add SMBIOS Type16 Table
    Platform/Sgi: Add SMBIOS Type17 Table
    Platform/Sgi: Add SMBIOS Type19 Table
    Platform/Sgi: Add SMBIOS Type32 Table

    Platform/ARM/SgiPkg/SgiPlatform.dsc.inc | 11 +
    Platform/ARM/SgiPkg/SgiPlatform.fdf | 8 +-
    .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 62 +++
    .../SmbiosPlatformDxe/SmbiosPlatformDxe.h | 197 +++++++++
    Platform/ARM/SgiPkg/Include/SgiPlatform.h | 36 +-
    .../SmbiosPlatformDxe/SmbiosPlatformDxe.c | 106 +++++
    .../SmbiosPlatformDxe/Type0BiosInformation.c | 135 ++++++
    .../Type16PhysicalMemoryArray.c | 106 +++++
    .../SmbiosPlatformDxe/Type17MemoryDevice.c | 409 ++++++++++++++++++
    .../Type19MemoryArrayMappedAddress.c | 97 +++++
    .../Type1SystemInformation.c | 142 ++++++
    .../Type32SystemBootInformation.c | 84 ++++
    .../SmbiosPlatformDxe/Type3SystemEnclosure.c | 103 +++++
    .../Type4ProcessorInformation.c | 219 ++++++++++
    .../SmbiosPlatformDxe/Type7CacheInformation.c | 342 +++++++++++++++
    .../SgiPkg/Library/PlatformLib/PlatformLib.c | 86 +++-
    16 files changed, 2140 insertions(+), 3 deletions(-)
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type0BiosInformation.c
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type16PhysicalMemoryArray.c
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type17MemoryDevice.c
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type19MemoryArrayMappedAddress.c
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type1SystemInformation.c
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type32SystemBootInformation.c
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type3SystemEnclosure.c
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type4ProcessorInformation.c
    create mode 100644 Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type7CacheInformation.c


    Re: [edk2-platforms PATCH 3/6] Marvell: Armada7k8k/OcteonTx: Switch SPCR UART subtype to 0x1

    Samer El-Haj-Mahmoud
     

    That being said, for this particular patch

    Reviewed-By: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>

    -----Original Message-----
    From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer
    El-Haj-Mahmoud via groups.io
    Sent: Monday, May 24, 2021 7:07 AM
    To: Marcin Wojtas <mw@...>; devel@edk2.groups.io
    Cc: leif@...; ardb+tianocore@...; Sunny Wang
    <Sunny.Wang@...>; gjb@...; upstream@...;
    Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
    Subject: Re: [edk2-devel] [edk2-platforms PATCH 3/6] Marvell:
    Armada7k8k/OcteonTx: Switch SPCR UART subtype to 0x1

    Thanks for the patch.

    Not an issue with this patch specifically, but it seems this #define
    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
    16450 should probably be renamed to reflect the latest spec (at
    https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-
    debug-port-table), which says:

    0x0001 : 16550 subset compatible with DBGP Revision 1

    Maybe you could send another patch to do this in
    SerialPortConsoleRedirectionTable.h ? Hopefully before this value is used by
    other platforms (this patch introduces the first usage of this value in edk2
    and edk2-platforms)



    -----Original Message-----
    From: Marcin Wojtas <mw@...>
    Sent: Monday, May 24, 2021 1:29 AM
    To: devel@edk2.groups.io
    Cc: leif@...; ardb+tianocore@...; Samer El-Haj-
    Mahmoud
    <Samer.El-Haj-Mahmoud@...>; Sunny Wang
    <Sunny.Wang@...>; gjb@...; upstream@...;
    Marcin Wojtas <mw@...>
    Subject: [edk2-platforms PATCH 3/6] Marvell: Armada7k8k/OcteonTx:
    Switch
    SPCR UART subtype to 0x1

    DBG2 ACPI table description [1] specifies three subtypes
    related to 16550 UART:
    0x0 - 16550 compatible
    0x1 - 16550 subset
    0x12 - 16550 compatible with parameters defined in
    Generic Address Structure (GAS)

    It turned out however, that the Windows OS treats 0x0 subtype as
    legacy x86 UART with 8-bit access. ARM SoCs can use types 0x1 (16550 with
    fixed mmio32 access) or 0x12 (16550 with fully respected GAS contents).

    Switch Marvell SoCs ACPI UART subtype to 0x1 - thanks to that the
    same firmware can run properly with UART output in Windows 10, Linux
    and ESXI hypervisor.

    [1] https://docs.microsoft.com/en-us/windows-
    hardware/drivers/bringup/acpi-debug-port-table

    Signed-off-by: Marcin Wojtas <mw@...>
    ---
    Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc | 2 +-
    Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc | 2 +-
    2 files changed, 2 insertions(+), 2 deletions(-)

    diff --git a/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
    b/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
    index 438cf7880e..6efc175bdf 100644
    --- a/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
    +++ b/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
    @@ -22,7 +22,7 @@
    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE Spcr = {
    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE,

    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_REVISION

    ),

    -
    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
    16550, // InterfaceType

    +
    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
    16450, // InterfaceType

    { EFI_ACPI_RESERVED_BYTE,

    EFI_ACPI_RESERVED_BYTE,

    EFI_ACPI_RESERVED_BYTE }, // Reserved1[3]

    diff --git a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
    b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
    index f663d8ade8..2a3415f0a6 100644
    --- a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
    +++ b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
    @@ -22,7 +22,7 @@
    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE Spcr = {
    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE,

    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_REVISION

    ),

    -
    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
    16550, // InterfaceType

    +
    EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
    16450, // InterfaceType

    { EFI_ACPI_RESERVED_BYTE,

    EFI_ACPI_RESERVED_BYTE,

    EFI_ACPI_RESERVED_BYTE }, // Reserved1[3]

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



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


    [edk2-platforms][PATCH V4 11/11] Platform/Sgi: Add SMBIOS Type32 Table

    Pranav Madhu
     

    Add the SMBIOS type 32 table (System Boot Information) that includes
    information about the System Boot Status.

    Signed-off-by: Pranav Madhu <pranav.madhu@...>
    Reviewed-by: Sami Mujawar <sami.mujawar@...>
    ---
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf =
    | 1 +
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h =
    | 17 ++++
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c =
    | 1 +
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type32SystemBootInformatio=
    n.c | 84 ++++++++++++++++++++
    4 files changed, 103 insertions(+)

    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatform=
    Dxe.inf b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe=
    .inf
    index f81494114188..4258eb9deadb 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
    @@ -23,6 +23,7 @@
    Type16PhysicalMemoryArray.c
    Type17MemoryDevice.c
    Type19MemoryArrayMappedAddress.c
    + Type32SystemBootInformation.c
    =20
    [Packages]
    ArmPkg/ArmPkg.dec
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatform=
    Dxe.h b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    index d4b838689a32..f8f69f0785b9 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    @@ -158,6 +158,23 @@ InstallType19MemoryArrayMappedAddress (
    IN EFI_SMBIOS_PROTOCOL *Smbios
    );
    =20
    +/**
    + Install SMBIOS system boot information
    +
    + Install the SMBIOS system boot information (type 32) table for RD plat=
    forms.
    +
    + @param[in] Smbios SMBIOS protocol.
    +
    + @retval EFI_SUCCESS Record was added.
    + @retval EFI_OUT_OF_RESOURCES Record was not added.
    + @retval EFI_ALREADY_STARTED The SmbiosHandle passed is already in us=
    e.
    +**/
    +EFI_STATUS
    +EFIAPI
    +InstallType32SystemBootInformation (
    + IN EFI_SMBIOS_PROTOCOL *Smbios
    + );
    +
    typedef enum {
    SMBIOS_HANDLE_ENCLOSURE =3D 0x1000,
    SMBIOS_HANDLE_CLUSTER1,
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatform=
    Dxe.c b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    index bed5da77786d..29535b247b7c 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    @@ -34,6 +34,7 @@ ARM_RD_SMBIOS_TABLE_INSTALL_FPTR mSmbiosTableList[] =3D=
    {
    &InstallType16PhysicalMemoryArray,
    &InstallType17MemoryDevice,
    &InstallType19MemoryArrayMappedAddress,
    + &InstallType32SystemBootInformation,
    };
    =20
    /**
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type32SystemBo=
    otInformation.c b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type32Sys=
    temBootInformation.c
    new file mode 100644
    index 000000000000..e98e23fe8fe0
    --- /dev/null
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type32SystemBootInfor=
    mation.c
    @@ -0,0 +1,84 @@
    +/** @file
    + SMBIOS Type 32 (System Boot Information) table for ARM RD platforms.
    +
    + This file installs SMBIOS Type 32 (System Boot Information) table for =
    Arm's
    + Reference Design platforms. It includes information about the System B=
    oot
    + Status.
    +
    + Copyright (c) 2021, ARM Limited. All rights reserved.
    + SPDX-License-Identifier: BSD-2-Clause-Patent
    +
    + @par Specification Reference:
    + - SMBIOS Reference Specification 3.4.0, Chapter 7.33
    +**/
    +
    +#include <Library/BaseMemoryLib.h>
    +#include <Library/DebugLib.h>
    +#include <Protocol/Smbios.h>
    +
    +#include "SmbiosPlatformDxe.h"
    +
    +#define TYPE32_STRINGS \
    + "\0" /* Null string */
    +
    +/* SMBIOS Type32 structure */
    +#pragma pack(1)
    +typedef struct {
    + SMBIOS_TABLE_TYPE32 Base;
    + CHAR8 Strings[sizeof (TYPE32_STRINGS)];
    +} ARM_RD_SMBIOS_TYPE32;
    +#pragma pack()
    +
    +/* System Boot Information */
    +STATIC ARM_RD_SMBIOS_TYPE32 mArmRdSmbiosType32 =3D {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_SYSTEM_BOOT_INFORMATION, // Type 32
    + sizeof (SMBIOS_TABLE_TYPE32), // Length
    + SMBIOS_HANDLE_PI_RESERVED
    + },
    + {0}, // Reserved field
    + BootInformationStatusNoError // Boot status
    + },
    + // Text strings (unformatted area)
    + TYPE32_STRINGS
    +};
    +
    +/**
    + Install SMBIOS system boot information
    +
    + Install the SMBIOS system boot information (type 32) table for RD plat=
    forms.
    +
    + @param[in] Smbios SMBIOS protocol.
    +
    + @retval EFI_SUCCESS Record was added.
    + @retval EFI_OUT_OF_RESOURCES Record was not added.
    + @retval EFI_ALREADY_STARTED The SmbiosHandle passed is already in us=
    e.
    +**/
    +EFI_STATUS
    +InstallType32SystemBootInformation (
    + IN EFI_SMBIOS_PROTOCOL *Smbios
    + )
    +{
    + EFI_STATUS Status;
    + EFI_SMBIOS_HANDLE SmbiosHandle;
    +
    + SmbiosHandle =3D ((EFI_SMBIOS_TABLE_HEADER *)&mArmRdSmbiosType32)->Han=
    dle;
    +
    + /* Install type 32 table */
    + Status =3D Smbios->Add (
    + Smbios,
    + NULL,
    + &SmbiosHandle,
    + (EFI_SMBIOS_TABLE_HEADER *)&mArmRdSmbiosType32
    + );
    + if (EFI_ERROR (Status)) {
    + DEBUG ((
    + DEBUG_ERROR,
    + "SMBIOS: Failed to install Type32 SMBIOS table.\n"
    + ));
    + }
    +
    + return Status;
    +}
    --=20
    2.17.1


    [edk2-platforms][PATCH V4 10/11] Platform/Sgi: Add SMBIOS Type19 Table

    Pranav Madhu
     

    Add the SMBIOS type 19 table (Memory Array Mapped Addr) that includes
    information about the address mapping for a Physical Memory Array.

    Signed-off-by: Pranav Madhu <pranav.madhu@...>
    Reviewed-by: Sami Mujawar <sami.mujawar@...>
    ---
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf =
    | 1 +
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h =
    | 18 ++++
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c =
    | 1 +
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type19MemoryArrayMappedAdd=
    ress.c | 97 ++++++++++++++++++++
    4 files changed, 117 insertions(+)

    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatform=
    Dxe.inf b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe=
    .inf
    index 9061c491d461..f81494114188 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
    @@ -22,6 +22,7 @@
    Type7CacheInformation.c
    Type16PhysicalMemoryArray.c
    Type17MemoryDevice.c
    + Type19MemoryArrayMappedAddress.c
    =20
    [Packages]
    ArmPkg/ArmPkg.dec
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatform=
    Dxe.h b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    index 4e663033d515..d4b838689a32 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    @@ -140,6 +140,24 @@ InstallType17MemoryDevice (
    IN EFI_SMBIOS_PROTOCOL *Smbios
    );
    =20
    +/**
    + Install SMBIOS memory array mapped address table
    +
    + Install the SMBIOS memory array mapped address (type 19) table for RD
    + platforms.
    +
    + @param[in] Smbios SMBIOS protocol.
    +
    + @retval EFI_SUCCESS Record was added.
    + @retval EFI_OUT_OF_RESOURCES Record was not added.
    + @retval EFI_ALREADY_STARTED The SmbiosHandle passed is already in us=
    e.
    +**/
    +EFI_STATUS
    +EFIAPI
    +InstallType19MemoryArrayMappedAddress (
    + IN EFI_SMBIOS_PROTOCOL *Smbios
    + );
    +
    typedef enum {
    SMBIOS_HANDLE_ENCLOSURE =3D 0x1000,
    SMBIOS_HANDLE_CLUSTER1,
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatform=
    Dxe.c b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    index 4e6a6b250813..bed5da77786d 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    @@ -33,6 +33,7 @@ ARM_RD_SMBIOS_TABLE_INSTALL_FPTR mSmbiosTableList[] =3D=
    {
    &InstallType7CacheInformation,
    &InstallType16PhysicalMemoryArray,
    &InstallType17MemoryDevice,
    + &InstallType19MemoryArrayMappedAddress,
    };
    =20
    /**
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type19MemoryAr=
    rayMappedAddress.c b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type19=
    MemoryArrayMappedAddress.c
    new file mode 100644
    index 000000000000..301208c4bc03
    --- /dev/null
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type19MemoryArrayMapp=
    edAddress.c
    @@ -0,0 +1,97 @@
    +/** @file
    + SMBIOS Type 19 (Memory Array Mapped Address) table for ARM RD platform=
    s.
    +
    + This file installs SMBIOS Type 19 (Memory Array Mapped Address) table =
    for Arm's
    + Reference Design platforms. It includes information about the address =
    mapping
    + for a Physical Memory Array.
    +
    + Copyright (c) 2021, ARM Limited. All rights reserved.
    + SPDX-License-Identifier: BSD-2-Clause-Patent
    +
    + @par Specification Reference:
    + - SMBIOS Reference Specification 3.4.0, Chapter 7.20
    +**/
    +
    +#include <Library/BaseMemoryLib.h>
    +#include <Library/DebugLib.h>
    +#include <Protocol/Smbios.h>
    +
    +#include "SmbiosPlatformDxe.h"
    +
    +#define TYPE19_STRINGS \
    + "\0" /* Null string */
    +
    +/* SMBIOS Type19 structure */
    +#pragma pack(1)
    +typedef struct {
    + SMBIOS_TABLE_TYPE19 Base;
    + CHAR8 Strings[sizeof (TYPE19_STRINGS)];
    +} ARM_RD_SMBIOS_TYPE19;
    +#pragma pack()
    +
    +/* Memory Array Mapped Address */
    +STATIC ARM_RD_SMBIOS_TYPE19 mArmRdSmbiosType19 =3D {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_MEMORY_ARRAY_MAPPED_ADDRESS, // Type 19
    + sizeof (SMBIOS_TABLE_TYPE19), // Length
    + SMBIOS_HANDLE_PI_RESERVED, // Assign an unused handle numbe=
    r
    + },
    + 0, // Starting address
    + 0, // Ending address
    + SMBIOS_HANDLE_PHYSICAL_MEMORY, // Memory array handle
    + 1 // Partition width
    + },
    + // Text strings (unformatted area)
    + TYPE19_STRINGS
    +};
    +
    +/**
    + Install SMBIOS memory array mapped address table
    +
    + Install the SMBIOS memory array mapped address (type 19) table for RD
    + platforms.
    +
    + @param[in] Smbios SMBIOS protocol.
    +
    + @retval EFI_SUCCESS Record was added.
    + @retval EFI_OUT_OF_RESOURCES Record was not added.
    + @retval EFI_ALREADY_STARTED The SmbiosHandle passed is already in us=
    e.
    +**/
    +EFI_STATUS
    +InstallType19MemoryArrayMappedAddress (
    + IN EFI_SMBIOS_PROTOCOL *Smbios
    + )
    +{
    + EFI_STATUS Status;
    + EFI_SMBIOS_HANDLE SmbiosHandle;
    +
    + SmbiosHandle =3D ((EFI_SMBIOS_TABLE_HEADER *)&mArmRdSmbiosType19)->Han=
    dle;
    +
    + mArmRdSmbiosType19.Base.StartingAddress =3D 0xFFFFFFFF;
    + mArmRdSmbiosType19.Base.EndingAddress =3D 0xFFFFFFFF;
    + mArmRdSmbiosType19.Base.ExtendedStartingAddress =3D
    + PcdGet64 (PcdSystemMemoryBase);
    + mArmRdSmbiosType19.Base.ExtendedEndingAddress =3D
    + (PcdGet64 (PcdSystemMemoryBase) +
    + PcdGet64 (PcdSystemMemorySize) +
    + SIZE_16MB // 16MB Trusted DRAM
    + ) - 1;
    +
    + /* Install type 19 table */
    + Status =3D Smbios->Add (
    + Smbios,
    + NULL,
    + &SmbiosHandle,
    + (EFI_SMBIOS_TABLE_HEADER *)&mArmRdSmbiosType19
    + );
    + if (EFI_ERROR (Status)) {
    + DEBUG ((
    + DEBUG_ERROR,
    + "SMBIOS: Failed to install Type19 SMBIOS table.\n"
    + ));
    + }
    +
    + return Status;
    +}
    --=20
    2.17.1


    [edk2-platforms][PATCH V4 09/11] Platform/Sgi: Add SMBIOS Type17 Table

    Pranav Madhu
     

    Add the SMBIOS type 17 table (Memory Device) that includes the
    specification of each installed memory device such as size of each
    device, bank locator, memory device type, and other related information.

    Signed-off-by: Pranav Madhu <pranav.madhu@...>
    Reviewed-by: Sami Mujawar <sami.mujawar@...>
    ---
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf | 1 +
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h | 26 ++
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 1 +
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type17MemoryDevice.c | 409 ++++++++++++++++++++
    4 files changed, 437 insertions(+)

    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
    index ebd19c1882bb..9061c491d461 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
    @@ -21,6 +21,7 @@
    Type4ProcessorInformation.c
    Type7CacheInformation.c
    Type16PhysicalMemoryArray.c
    + Type17MemoryDevice.c

    [Packages]
    ArmPkg/ArmPkg.dec
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    index 95bb2c4bfc70..4e663033d515 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    @@ -122,6 +122,24 @@ InstallType16PhysicalMemoryArray (
    IN EFI_SMBIOS_PROTOCOL *Smbios
    );

    +
    +/**
    + Install SMBIOS memory device table.
    +
    + Install the SMBIOS memory device (type 17) table for RD platforms.
    +
    + @param[in] Smbios SMBIOS protocol.
    +
    + @retval EFI_SUCCESS Record was added.
    + @retval EFI_OUT_OF_RESOURCES Record was not added.
    + @retval EFI_ALREADY_STARTED The SmbiosHandle passed is already in use.
    +**/
    +EFI_STATUS
    +EFIAPI
    +InstallType17MemoryDevice (
    + IN EFI_SMBIOS_PROTOCOL *Smbios
    + );
    +
    typedef enum {
    SMBIOS_HANDLE_ENCLOSURE = 0x1000,
    SMBIOS_HANDLE_CLUSTER1,
    @@ -131,6 +149,14 @@ typedef enum {
    SMBIOS_HANDLE_L3_CACHE,
    SMBIOS_HANDLE_L4_CACHE,
    SMBIOS_HANDLE_PHYSICAL_MEMORY,
    + SMBIOS_HANDLE_MEMORY_DEVICE0000, // Chip 0 Bank 0
    + SMBIOS_HANDLE_MEMORY_DEVICE0001, // Chip 0 Bank 1
    + SMBIOS_HANDLE_MEMORY_DEVICE0100, // Chip 1 Bank 0
    + SMBIOS_HANDLE_MEMORY_DEVICE0101, // Chip 1 Bank 1
    + SMBIOS_HANDLE_MEMORY_DEVICE0200, // Chip 2 Bank 0
    + SMBIOS_HANDLE_MEMORY_DEVICE0201, // Chip 2 Bank 1
    + SMBIOS_HANDLE_MEMORY_DEVICE0300, // Chip 3 Bank 0
    + SMBIOS_HANDLE_MEMORY_DEVICE0301, // Chip 3 Bank 1
    } SMBIOS_REFRENCE_HANDLES;

    #endif // SMBIOS_PLATFORM_DXE_H_
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    index 4f14be165c94..4e6a6b250813 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    @@ -32,6 +32,7 @@ ARM_RD_SMBIOS_TABLE_INSTALL_FPTR mSmbiosTableList[] = {
    &InstallType4ProcessorInformation,
    &InstallType7CacheInformation,
    &InstallType16PhysicalMemoryArray,
    + &InstallType17MemoryDevice,
    };

    /**
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type17MemoryDevice.c b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type17MemoryDevice.c
    new file mode 100644
    index 000000000000..b51e2b3fa1a6
    --- /dev/null
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type17MemoryDevice.c
    @@ -0,0 +1,409 @@
    +/** @file
    + SMBIOS Type 17 (Memory Device) table for ARM RD platforms.
    +
    + This file installs SMBIOS Type 17 (Memory Device) table for Arm's Reference
    + Design platforms. It includes the specification of each installed memory
    + device such as size of each device, bank locator, memory device type, and
    + other related information.
    +
    + Copyright (c) 2021, ARM Limited. All rights reserved.
    + SPDX-License-Identifier: BSD-2-Clause-Patent
    +
    + @par Specification Reference:
    + - SMBIOS Reference Specification 3.4.0, Chapter 7.18
    +**/
    +
    +#include <Library/BaseMemoryLib.h>
    +#include <Library/DebugLib.h>
    +#include <Protocol/Smbios.h>
    +
    +#include "SmbiosPlatformDxe.h"
    +
    +#define TYPE17_STRINGS \
    + "Chip 0 Bank 0\0" \
    + "Chip 1 Bank 0\0" \
    + "Chip 2 Bank 0\0" \
    + "Chip 3 Bank 0\0" \
    + "Chip 0 Bank 1\0" \
    + "Chip 1 Bank 1\0" \
    + "Chip 2 Bank 1\0" \
    + "Chip 3 Bank 1\0"
    +
    +typedef enum {
    + Chip0Bank0 = 1,
    + Chip1Bank0,
    + Chip2Bank0,
    + Chip3Bank0,
    + Chip0Bank1,
    + Chip1Bank1,
    + Chip2Bank1,
    + Chip3Bank1
    +} TYPE17_STRING_ELEMENTS;
    +
    +/* SMBIOS Type17 structure */
    +#pragma pack(1)
    +typedef struct {
    + SMBIOS_TABLE_TYPE17 Base;
    + CHAR8 Strings[sizeof (TYPE17_STRINGS)];
    +} ARM_RD_SMBIOS_TYPE17;
    +#pragma pack()
    +
    +/* Memory Device */
    +STATIC ARM_RD_SMBIOS_TYPE17 mArmRdSmbiosType17[] = {
    + {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_MEMORY_DEVICE, // Type 17
    + sizeof (SMBIOS_TABLE_TYPE17), // Length
    + SMBIOS_HANDLE_MEMORY_DEVICE0000
    + },
    + SMBIOS_HANDLE_PHYSICAL_MEMORY, // Physical memory array handle
    + 0xFFFE, // Memory error info handle
    + 0xFFFF, // Total width unknown
    + 0xFFFF, // Data width unknown
    + 0, // Size, Update dynamically
    + MemoryFormFactorOther, // Form Factor
    + 0, // Device set, not part of a set
    + 0, // Device locator
    + Chip0Bank0, // Chip 0 Bank 0
    + MemoryTypeDram, // Memory type
    + {0, 1}, // Type details others
    + },
    + // Text strings (unformatted area)
    + TYPE17_STRINGS
    + },
    + {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_MEMORY_DEVICE, // Type 17
    + sizeof (SMBIOS_TABLE_TYPE17), // Length
    + SMBIOS_HANDLE_MEMORY_DEVICE0001
    + },
    + SMBIOS_HANDLE_PHYSICAL_MEMORY, // Physical memory array handle
    + 0xFFFE, // Memory error info handle
    + 0xFFFF, // Total width unknown
    + 0xFFFF, // Data width unknown
    + 0, // Size, Update dynamically
    + MemoryFormFactorOther, // Form Factor
    + 0, // Device set, not part of a set
    + 0, // Device locator
    + Chip0Bank1, // Chip 0 Bank 1
    + MemoryTypeDram, // Memory type
    + {0, 1}, // Type details others
    + },
    + // Text strings (unformatted area)
    + TYPE17_STRINGS
    + },
    + {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_MEMORY_DEVICE, // Type 17
    + sizeof (SMBIOS_TABLE_TYPE17), // Length
    + SMBIOS_HANDLE_MEMORY_DEVICE0100
    + },
    + SMBIOS_HANDLE_PHYSICAL_MEMORY, // Physical memory array handle
    + 0xFFFE, // Memory error info handle
    + 0xFFFF, // Total width unknown
    + 0xFFFF, // Data width unknown
    + 0, // Size, Update dynamically
    + MemoryFormFactorOther, // Form Factor
    + 0, // Device set, not part of a set
    + 0, // Device locator
    + Chip1Bank0, // Chip 1 Bank 0
    + MemoryTypeDram, // Memory type
    + {0, 1}, // Type details others
    + },
    + // Text strings (unformatted area)
    + TYPE17_STRINGS
    + },
    + {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_MEMORY_DEVICE, // Type 17
    + sizeof (SMBIOS_TABLE_TYPE17), // Length
    + SMBIOS_HANDLE_MEMORY_DEVICE0101
    + },
    + SMBIOS_HANDLE_PHYSICAL_MEMORY, // Physical memory array handle
    + 0xFFFE, // Memory error info handle
    + 0xFFFF, // Total width unknown
    + 0xFFFF, // Data width unknown
    + 0, // Size, Update dynamically
    + MemoryFormFactorOther, // Form Factor
    + 0, // Device set, not part of a set
    + 0, // Device locator
    + Chip1Bank1, // Chip 1 Bank 1
    + MemoryTypeDram, // Memory type
    + {0, 1}, // Type details others
    + },
    + // Text strings (unformatted area)
    + TYPE17_STRINGS
    + },
    + {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_MEMORY_DEVICE, // Type 17
    + sizeof (SMBIOS_TABLE_TYPE17), // Length
    + SMBIOS_HANDLE_MEMORY_DEVICE0200
    + },
    + SMBIOS_HANDLE_PHYSICAL_MEMORY, // Physical memory array handle
    + 0xFFFE, // Memory error info handle
    + 0xFFFF, // Total width unknown
    + 0xFFFF, // Data width unknown
    + 0, // Size, Update dynamically
    + MemoryFormFactorOther, // Form Factor
    + 0, // Device set, not part of a set
    + 0, // Device locator
    + Chip2Bank0, // Chip 2 Bank 0
    + MemoryTypeDram, // Memory type
    + {0, 1}, // Type details others
    + },
    + // Text strings (unformatted area)
    + TYPE17_STRINGS
    + },
    + {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_MEMORY_DEVICE, // Type 17
    + sizeof (SMBIOS_TABLE_TYPE17), // Length
    + SMBIOS_HANDLE_MEMORY_DEVICE0201
    + },
    + SMBIOS_HANDLE_PHYSICAL_MEMORY, // Physical memory array handle
    + 0xFFFE, // Memory error info handle
    + 0xFFFF, // Total width unknown
    + 0xFFFF, // Data width unknown
    + 0, // Size, Update dynamically
    + MemoryFormFactorOther, // Form Factor
    + 0, // Device set, not part of a set
    + 0, // Device locator
    + Chip2Bank1, // Chip 2 Bank 1
    + MemoryTypeDram, // Memory type
    + {0, 1}, // Type details others
    + },
    + // Text strings (unformatted area)
    + TYPE17_STRINGS
    + },
    + {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_MEMORY_DEVICE, // Type 17
    + sizeof (SMBIOS_TABLE_TYPE17), // Length
    + SMBIOS_HANDLE_MEMORY_DEVICE0300
    + },
    + SMBIOS_HANDLE_PHYSICAL_MEMORY, // Physical memory array handle
    + 0xFFFE, // Memory error info handle
    + 0xFFFF, // Total width unknown
    + 0xFFFF, // Data width unknown
    + 0, // Size, Update dynamically
    + MemoryFormFactorOther, // Form Factor
    + 0, // Device set, not part of a set
    + 0, // Device locator
    + Chip3Bank0, // Chip 3 Bank 0
    + MemoryTypeDram, // Memory type
    + {0, 1}, // Type details others
    + },
    + // Text strings (unformatted area)
    + TYPE17_STRINGS
    + },
    + {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_MEMORY_DEVICE, // Type 17
    + sizeof (SMBIOS_TABLE_TYPE17), // Length
    + SMBIOS_HANDLE_MEMORY_DEVICE0301
    + },
    + SMBIOS_HANDLE_PHYSICAL_MEMORY, // Physical memory array handle
    + 0xFFFE, // Memory error info handle
    + 0xFFFF, // Total width unknown
    + 0xFFFF, // Data width unknown
    + 0, // Size, Update dynamically
    + MemoryFormFactorOther, // Form Factor
    + 0, // Device set, not part of a set
    + 0, // Device locator
    + Chip3Bank1, // Chip 3 Bank 1
    + MemoryTypeDram, // Memory type
    + {0, 1}, // Type details others
    + },
    + // Text strings (unformatted area)
    + TYPE17_STRINGS
    + },
    +};
    +
    +/** Update the memory size fields in SMBIOS Memory Device (Type 17) table.
    +
    + @param [in] Type17Table Pointer to the Type 17 table.
    + @param [in] MemorySize Memory size available on the platform.
    + - If no memory device is installed, this value
    + is 0.
    + - If size is unknown, this value is MAX_UINT64.
    +
    + @retval EFI_SUCCESS Success.
    + @retval EFI_INVALID_PARAMETER Invalid Type 17 Table pointer.
    +**/
    +STATIC
    +UINTN
    +UpdateMemorySize (
    + IN SMBIOS_TABLE_TYPE17 *Type17Table,
    + IN UINT64 MemorySize
    + )
    +{
    + if (Type17Table == NULL) {
    + return EFI_INVALID_PARAMETER;
    + }
    +
    + /* Ref: SMBIOS Specifiation, Version 3.4.0, Document Identifier: DSP0134,
    + Table 75 – Memory Device (Type 17) structure, description for Size field.
    + If the value is 0, no memory device is installed in the socket; if
    + the size is unknown, the field value is FFFFh.
    + */
    + if (MemorySize == 0) {
    + Type17Table->Size = 0;
    + Type17Table->ExtendedSize = 0;
    + return EFI_SUCCESS;
    + }
    +
    + if (MemorySize == MAX_UINT64) {
    + Type17Table->Size = MAX_UINT16;
    + Type17Table->ExtendedSize = 0;
    + return EFI_SUCCESS;
    + }
    +
    + /* Ref: SMBIOS Specifiation, Version 3.4.0, Document Identifier: DSP0134,
    + Table 75 – Memory Device (Type 17) structure, description for Size field.
    + If the size is 32 GB-1 MB or greater, the field value is 7FFFh and the
    + actual size is stored in the Extended Size field.
    + */
    + if (MemorySize < (SIZE_32GB - SIZE_1MB)) {
    + /* Ref: SMBIOS Specifiation, Version 3.4.0, Document Identifier: DSP0134,
    + section 7.18.5 Memory Device — Extended Size
    + For compatibility with older SMBIOS parsers, memory devices
    + smaller than (32 GB - 1 MB) should be represented using their
    + size in the Size field, leaving the Extended Size field set to 0.
    + */
    + Type17Table->ExtendedSize = 0;
    +
    + /* Ref: SMBIOS Specifiation, Version 3.4.0, Document Identifier: DSP0134,
    + Table 75 – Memory Device (Type 17) structure, description for Size field.
    + The granularity in which the value is specified depends on the setting
    + of the most-significant bit (bit 15). If the bit is 0, the value is
    + specified in megabyte units; if the bit is 1, the value is specified
    + in kilobyte units.
    + For example, the value 8100h identifies a 256 KB memory device
    + and 0100h identifies a 256 MB memory device.
    + */
    + if (MemorySize < SIZE_1MB) {
    + Type17Table->Size = MemorySize >> 10;
    + Type17Table->Size |= BIT15;
    + } else {
    + Type17Table->Size = MemorySize >> 20;
    + }
    + return EFI_SUCCESS;
    + }
    +
    + /* Ref: SMBIOS Specifiation, Version 3.4.0, Document Identifier: DSP0134,
    + section 7.18.5 Memory Device — Extended Size
    + The Extended Size field is intended to represent memory devices
    + larger than 32,767 MB (32 GB - 1 MB), which cannot be described
    + using the Size field. This field is only meaningful if the value
    + in the Size field is 7FFFh.
    + */
    + Type17Table->Size = 0x7FFF;
    +
    + /* Ref: SMBIOS Specifiation, Version 3.4.0, Document Identifier: DSP0134,
    + section 7.18.5 Memory Device — Extended Size
    + Bit 31 is reserved for future use and must be set to 0.
    + Bits 30:0 represent the size of the memory device in megabytes.
    + EXAMPLE: 0000_8000h indicates a 32 GB memory device (32,768 MB),
    + 0002_0000h represents a 128 GB memory device (131,072 MB), and
    + 0000_7FFFh represents a 32,767 MB (32 GB – 1 MB) device.
    + */
    + Type17Table->ExtendedSize = (MemorySize >> 20) & (~BIT31);
    + return EFI_SUCCESS;
    +}
    +
    +/**
    + Install SMBIOS memory device Table.
    +
    + Install the SMBIOS memory device (type 17) table for RD platforms.
    +
    + @param[in] Smbios SMBIOS protocol.
    +
    + @retval EFI_SUCCESS Record was added.
    + @retval EFI_OUT_OF_RESOURCES Record was not added.
    + @retval EFI_ALREADY_STARTED The SmbiosHandle passed is already in use.
    +**/
    +EFI_STATUS
    +InstallType17MemoryDevice (
    + IN EFI_SMBIOS_PROTOCOL *Smbios
    + )
    +{
    + EFI_STATUS Status;
    + EFI_SMBIOS_HANDLE SmbiosHandle;
    + UINT8 Idx;
    +
    + /* Get system memory information */
    + for (Idx = 0; Idx < (FixedPcdGet32 (PcdChipCount) * 2); Idx += 2) {
    + Status = UpdateMemorySize (
    + &mArmRdSmbiosType17[Idx].Base,
    + PcdGet64 (PcdSystemMemorySize) + SIZE_16MB
    + );
    + if (EFI_ERROR (Status)) {
    + DEBUG ((
    + DEBUG_ERROR,
    + "SMBIOS: Failed to update DRAM size for chip%d.\n",
    + Idx / 2
    + ));
    + } else {
    + mArmRdSmbiosType17[Idx].Base.MemoryTechnology = MemoryTechnologyDram;
    + mArmRdSmbiosType17[Idx].Base.MemoryOperatingModeCapability.Bits.
    + VolatileMemory = 1;
    + }
    +
    + if (PcdGet64 (PcdDramBlock2Size) != 0) {
    + Status = UpdateMemorySize (
    + &mArmRdSmbiosType17[Idx + 1].Base,
    + PcdGet64 (PcdDramBlock2Size)
    + );
    + if (EFI_ERROR (Status)) {
    + DEBUG ((
    + DEBUG_ERROR,
    + "SMBIOS: Failed to update DRAM block 2 size for chip%d.\n",
    + Idx / 2
    + ));
    + } else {
    + mArmRdSmbiosType17[Idx + 1].Base.MemoryTechnology =
    + MemoryTechnologyDram;
    + mArmRdSmbiosType17[Idx + 1].Base.MemoryOperatingModeCapability.Bits.
    + VolatileMemory = 1;
    + }
    + }
    + }
    +
    + /* Install valid entries */
    + for (Idx = 0; Idx < (FixedPcdGet32 (PcdChipCount) * 2); Idx++) {
    + SmbiosHandle =
    + ((EFI_SMBIOS_TABLE_HEADER *)&mArmRdSmbiosType17[Idx])->Handle;
    + Status = Smbios->Add (
    + Smbios,
    + NULL,
    + &SmbiosHandle,
    + (EFI_SMBIOS_TABLE_HEADER *)&mArmRdSmbiosType17[Idx]
    + );
    + if (EFI_ERROR (Status)) {
    + DEBUG ((
    + DEBUG_ERROR,
    + "SMBIOS: Failed to install Type17 SMBIOS table.\n"
    + ));
    + break;
    + }
    + }
    +
    + return Status;
    +}
    --
    2.17.1


    [edk2-platforms][PATCH V4 08/11] Platform/Sgi: Add SMBIOS Type16 Table

    Pranav Madhu
     

    Add the SMBIOS type 16 table (Physical Memory Array) describes a
    collection of memory devices that operate together to form a memory
    address. It includes information about number of devices, total memory
    installed, error correction mechanism used and other related information.

    Signed-off-by: Pranav Madhu <pranav.madhu@...>
    Reviewed-by: Sami Mujawar <sami.mujawar@...>
    ---
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf =
    | 4 +
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h =
    | 19 ++++
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c =
    | 1 +
    Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type16PhysicalMemoryArray.=
    c | 106 ++++++++++++++++++++
    4 files changed, 130 insertions(+)

    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatform=
    Dxe.inf b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe=
    .inf
    index ee00b773912b..ebd19c1882bb 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
    @@ -20,6 +20,7 @@
    Type3SystemEnclosure.c
    Type4ProcessorInformation.c
    Type7CacheInformation.c
    + Type16PhysicalMemoryArray.c
    =20
    [Packages]
    ArmPkg/ArmPkg.dec
    @@ -44,6 +45,9 @@
    gArmPlatformTokenSpaceGuid.PcdClusterCount
    gArmPlatformTokenSpaceGuid.PcdCoreCount
    gArmSgiTokenSpaceGuid.PcdChipCount
    + gArmSgiTokenSpaceGuid.PcdDramBlock2Size
    + gArmTokenSpaceGuid.PcdSystemMemoryBase
    + gArmTokenSpaceGuid.PcdSystemMemorySize
    gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareRevision
    =20
    [Protocols]
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatform=
    Dxe.h b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    index 43f35ea0518f..95bb2c4bfc70 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h
    @@ -104,6 +104,24 @@ InstallType7CacheInformation (
    IN EFI_SMBIOS_PROTOCOL *Smbios
    );
    =20
    +/**
    + Install SMBIOS physical memory array table.
    +
    + Install the SMBIOS physical memory array (type 16) table for Arm's Ref=
    erence
    + Design platforms.
    +
    + @param[in] Smbios SMBIOS protocol.
    +
    + @retval EFI_SUCCESS Record was added.
    + @retval EFI_OUT_OF_RESOURCES Record was not added.
    + @retval EFI_ALREADY_STARTED The SmbiosHandle passed is already in us=
    e.
    +**/
    +EFI_STATUS
    +EFIAPI
    +InstallType16PhysicalMemoryArray (
    + IN EFI_SMBIOS_PROTOCOL *Smbios
    + );
    +
    typedef enum {
    SMBIOS_HANDLE_ENCLOSURE =3D 0x1000,
    SMBIOS_HANDLE_CLUSTER1,
    @@ -112,6 +130,7 @@ typedef enum {
    SMBIOS_HANDLE_L2_CACHE,
    SMBIOS_HANDLE_L3_CACHE,
    SMBIOS_HANDLE_L4_CACHE,
    + SMBIOS_HANDLE_PHYSICAL_MEMORY,
    } SMBIOS_REFRENCE_HANDLES;
    =20
    #endif // SMBIOS_PLATFORM_DXE_H_
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatform=
    Dxe.c b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    index d3b161b77550..4f14be165c94 100644
    --- a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
    @@ -31,6 +31,7 @@ ARM_RD_SMBIOS_TABLE_INSTALL_FPTR mSmbiosTableList[] =3D=
    {
    &InstallType3SystemEnclosure,
    &InstallType4ProcessorInformation,
    &InstallType7CacheInformation,
    + &InstallType16PhysicalMemoryArray,
    };
    =20
    /**
    diff --git a/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type16Physical=
    MemoryArray.c b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type16Physi=
    calMemoryArray.c
    new file mode 100644
    index 000000000000..b1b41bf405a2
    --- /dev/null
    +++ b/Platform/ARM/SgiPkg/Drivers/SmbiosPlatformDxe/Type16PhysicalMemoryA=
    rray.c
    @@ -0,0 +1,106 @@
    +/** @file
    + SMBIOS Type 16 (Physical Memory Array) table for ARM RD platforms.
    +
    + This file installs SMBIOS Type 16 (Physical Memory Array) table for Ar=
    m's
    + Reference Design platforms. It describes a collection of memory device=
    s that
    + operate together to form a memory address. It includes information abo=
    ut
    + number of devices, total memory installed, error correction mechanism =
    used
    + and other related information.
    +
    + Copyright (c) 2021, ARM Limited. All rights reserved.
    + SPDX-License-Identifier: BSD-2-Clause-Patent
    +
    + @par Specification Reference:
    + - SMBIOS Reference Specification 3.4.0, Chapter 7.17
    +**/
    +
    +#include <Library/BaseMemoryLib.h>
    +#include <Library/DebugLib.h>
    +#include <Protocol/Smbios.h>
    +
    +#include "SmbiosPlatformDxe.h"
    +
    +#define TYPE16_STRINGS \
    + "\0" /* Null string */
    +
    +/* SMBIOS Type16 structure */
    +#pragma pack(1)
    +typedef struct {
    + SMBIOS_TABLE_TYPE16 Base;
    + CHAR8 Strings[sizeof (TYPE16_STRINGS)];
    +} ARM_RD_SMBIOS_TYPE16;
    +#pragma pack()
    +
    +/* Physical Memory Array */
    +STATIC ARM_RD_SMBIOS_TYPE16 mArmRdSmbiosType16 =3D {
    + {
    + {
    + // SMBIOS header
    + EFI_SMBIOS_TYPE_PHYSICAL_MEMORY_ARRAY, // Type 16
    + sizeof (SMBIOS_TABLE_TYPE16), // Length
    + SMBIOS_HANDLE_PHYSICAL_MEMORY
    + },
    + MemoryArrayLocationSystemBoard, // Location
    + MemoryArrayUseSystemMemory, // Used as system memory
    + MemoryErrorCorrectionUnknown, // Error correction
    + 0x80000000, // Maximum capacity in KiB, uses Extended Maximum capaci=
    ty field
    + 0xFFFE, // Memory error info handle, does not provide this info
    + 0, // Num of memory devices, update dymamically
    + 0 // Extended Maximum capacity, update dymamically
    + },
    + // Text strings (unformatted area)
    + TYPE16_STRINGS
    +};
    +
    +/**
    + Install SMBIOS physical memory array table.
    +
    + Install the SMBIOS physical memory array (type 16) table for Arm's Ref=
    erence
    + Design platforms.
    +
    + @param[in] Smbios SMBIOS protocol.
    +
    + @retval EFI_SUCCESS Record was added.
    + @retval EFI_OUT_OF_RESOURCES Record was not added.
    + @retval EFI_ALREADY_STARTED The SmbiosHandle passed is already in us=
    e.
    +**/
    +EFI_STATUS
    +InstallType16PhysicalMemoryArray (
    + IN EFI_SMBIOS_PROTOCOL *Smbios
    + )
    +{
    + EFI_STATUS Status;
    + EFI_SMBIOS_HANDLE SmbiosHandle;
    + UINT16 NumOfMemoryDevices =3D 1;
    + UINT64 InstalledMemory;
    +
    + SmbiosHandle =3D ((EFI_SMBIOS_TABLE_HEADER *)&mArmRdSmbiosType16)->Han=
    dle;
    +
    + /* Include 16MB of Trusted DRAM as well */
    + InstalledMemory =3D PcdGet64 (PcdSystemMemorySize) + SIZE_16MB;
    + if (PcdGet64 (PcdDramBlock2Size) !=3D 0) {
    + NumOfMemoryDevices++;
    + InstalledMemory +=3D PcdGet64 (PcdDramBlock2Size);
    + }
    +
    + mArmRdSmbiosType16.Base.ExtendedMaximumCapacity =3D
    + InstalledMemory * FixedPcdGet32 (PcdChipCount);
    + mArmRdSmbiosType16.Base.NumberOfMemoryDevices =3D
    + NumOfMemoryDevices * FixedPcdGet32 (PcdChipCount);
    +
    + /* Install type 16 table */
    + Status =3D Smbios->Add (
    + Smbios,
    + NULL,
    + &SmbiosHandle,
    + (EFI_SMBIOS_TABLE_HEADER *)&mArmRdSmbiosType16
    + );
    + if (EFI_ERROR (Status)) {
    + DEBUG ((
    + DEBUG_ERROR,
    + "SMBIOS: Failed to install Type16 SMBIOS table.\n"
    + ));
    + }
    +
    + return Status;
    +}
    --=20
    2.17.1