Re: [edk2-devel] [PATCH edk2-platforms 07/11] Silicon/Ampere: Switch to generic ArmPsciResetSystemLib

[Nhi Pham via groups.io]

Thanks Ard for the patch.

Reviewed-by: Nhi Pham 

Regards,
Nhi

On 7/25/2024 3:24 PM, Ard Biesheuvel wrote:

From: Ard Biesheuvel 

The PSCI reset libraries in ArmPkg are being consolidated into a single
one to reduce the maintenance burden of having multiple libraries doing
the same thing in a slightly different way.

Move this platform to the generic ArmPsciResetSystemLib, and drop the
dependency on ArmSmcPsciResetSystemLib, which is deprecated and will be
removed.

Cc: Nhi Pham 
Cc: Chuong Tran 
Cc: Rebecca Cran 
Signed-off-by: Ard Biesheuvel 
---
  Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc 
b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
index fb170d436d00..977e4c4c238d 100644
--- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
+++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
@@ -73,7 +73,8 @@ [LibraryClasses.common]

ArmPlatformStackLib|ArmPlatformPkg/Library/ArmPlatformStackLib/ArmPlatformStackLib.inf
ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf

ArmGenericTimerCounterLib|ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib.inf
-  
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
+  ResetSystemLib|ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
+  ArmMonitorLib|ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
  
#

# Ampere Altra specific Libraries



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120045): https://edk2.groups.io/g/devel/message/120045
Mute This Topic: https://groups.io/mt/107558451/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 3/4] Platform/Ampere: Switch to generic ResetRuntime DXE driver

[Nhi Pham via groups.io]

Thanks a lot for the patch.

Reviewed-by: Nhi Pham 
Tested-by: Nhi Pham 

On 7/21/2024 9:51 PM, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> The reset runtime DXE driver is deprecated and will be removed soon. It
> is superseded by a generic implementation in MdeModulePkg, which is
> shared between all architectures, and implements the notification
> protocols that the EFI spec describes. So move the Ampere Jade platform
> to this implementation the of ResetSystem EFI runtime service.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
>  Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 3 +--
>  Platform/Ampere/JadePkg/Jade.fdf | 2 +-
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc 
> b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
> index 1f705c68579a..fb170d436d00 100644
> --- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
> +++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
> @@ -259,7 +259,6 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>  !endif
>
> VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
>  
> -  
> EfiResetSystemLib|ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
>ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
>
> NVParamLib|Silicon/Ampere/AmpereAltraPkg/Library/NVParamLib/RuntimeNVParamLib.inf
>
> AmpereCpuLib|Silicon/Ampere/AmpereAltraPkg/Library/AmpereCpuLib/RuntimeAmpereCpuLib.inf
> @@ -588,7 +587,7 @@ [Components.common]
>  !endif
>MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
>
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
> -  EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
> +  MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
>ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> diff --git a/Platform/Ampere/JadePkg/Jade.fdf 
> b/Platform/Ampere/JadePkg/Jade.fdf
> index 7795f0e5..127e4401f69b 100644
> --- a/Platform/Ampere/JadePkg/Jade.fdf
> +++ b/Platform/Ampere/JadePkg/Jade.fdf
> @@ -222,7 +222,7 @@ [FV.FvMain]
>INF 
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
>  !endif
>INF 
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
> -  INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
> +  INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
>INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120001): https://edk2.groups.io/g/devel/message/120001
Mute This Topic: https://groups.io/mt/107476835/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 2/2] SbsaQemu: set CPU model in SMBIOS

[Nhi Pham via groups.io]

On 7/12/2024 5:01 PM, Ard Biesheuvel via groups.io wrote:

On Fri, 12 Jul 2024 at 11:24, Marcin Juszkiewicz
 wrote:


SbsaQemu platform have several cpu models available. Since start it
reported "arm-virt" one in SMBIOS instead of real one.

This change replaces it with the real cpu model like Cortex-A57,
Neoverse-N2 etc.

Requires change in EDK2 to make PcdProcessorVersion dynamic.

Signed-off-by: Marcin Juszkiewicz 


I am going to make the same remark as I did before in a different
context: how is it guaranteed that the code that sets the PCD executes
before the code that consumes it?


We could implement the setting in a 'PlatformInitDxe', which will be 
added to the 'APPRIORI DXE' list to ensure it is scheduled to run in the 
early DXE phase. This approach will help initialize the neccessary 
compoenents early in the DXE phase, providing a stable foundation for 
subsequent operations.




Making PCDs dynamic is usually not the solution here, unless they are
set in the PEI phase and consumed in the DXE phase or after.

The EFI SMBIOS protocol has an 'update string' method that you can
call from a platform driver. That might be a better fit here, and the
PCD can remain fixed, and carry a fallback default value.



In fact that the 'update string' method could eat up the boot time. 
Hence, the SMBIOS string patching is not prefered.


Regards,
Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119931): https://edk2.groups.io/g/devel/message/119931
Mute This Topic: https://groups.io/mt/107179083/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v2] ManageabilityPkg: add support for the phosphor ipmi blob transfer protocol

[Nhi Pham via groups.io]

On 7/10/2024 10:12 PM, Nickle Wang wrote:

Hi @Nhi Pham ,

I am sorry for taking so long to address your review comments. I updated 
pull request here: https://github.com/tianocore/edk2-platforms/pull/76 



Thanks, Nickle. I will continue reviewing (if any comments) on the PR 
instead.




I addressed most of comments and I have questions about below review 
comments. Please find my feedback inline below.


 > Should we add a PCD for the OEN to be configured by platform specific

 > BMC? Or this protocol is only to support OpenBMC.

Yes, per description in Readme.md, this is the protocol only to support 
OpenBMC implementation.


 > I'm thinking the caller sequence here. Typically, the caller might check

 > the presence of a blob by calling GetCount () and Enumerate () before

 > opening a blob session. This check here could waste time. Or, do we call

 > open direction the blob session without pre-checking?

With this implementation, user can call open directly and it will check 
the presence of blob for us. And yes, this is how we use it in NVIDIA 
driver.


 > There might be developer mistake when executing the transfer before

 > opening the session. How do we handle this failure path? Do we need to

 > maintain a state machine for that?

Caller can only get the session ID by calling open(). Session ID is 
required when calling read, write, and commit. If caller make up a 
session ID, caller is expected to see error return.


 > How do callers know the data format of metadata for writing correctly?

I check the spec here: 
https://github.com/openbmc/phosphor-ipmi-blobs?tab=readme-ov-file#bmcblobwritemeta-10   And there is no description about data format.  Since we don't use this function in our driver, may I know if you have suggestion for this?


I don't have a strong opinion here (**That was just my curiosity**). So, 
we can just leave it as your implementation or drop it as there is no 
consumer.




 > +IpmiBlobTransferDxeDriverEntryPoint (

 > +  IN EFI_HANDLE    ImageHandle,

 > +  IN EFI_SYSTEM_TABLE  *SystemTable

 > +  )

 > +{

 > +  return gBS->InstallMultipleProtocolInterfaces (

 > +    ,

 > Nit: Typically, we could also use gImageHandle instead.

Sorry I don't follow you here.

gImageHandle is used as global variable in driver. But here we just use 
the ImageHandle from function parameter and we don't keep it as global 
variable, right?


The pointers should be identical since they are cached by the 
UefiBootServicesTableLib's constructor prior to the call to 
IpmiBlobTransferDxeDriverEntryPoint.


Thanks,
Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119879): https://edk2.groups.io/g/devel/message/119879
Mute This Topic: https://groups.io/mt/106115743/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 2/5] Platform,Silicon: drop redundant uses of PcdArmArchTimerFreqInHz

[Nhi Pham via groups.io]

Thanks for the cleanup.

For Ampere Altra,

Reviewed-by: Nhi Pham 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119663): https://edk2.groups.io/g/devel/message/119663
Mute This Topic: https://groups.io/mt/106780877/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 0/6] JadePkg and common Ampere code fixes

[Nhi Pham via groups.io]

For this series,

Reviewed-by: Nhi Pham 

Thanks,
Nhi

On 6/6/2024 10:04 AM, Rebecca Cran wrote:

These are a set of bug fixes I made to the Mt Jade and common Ampere
code while working on updating and improving ADLINK's edk2_aadp
project.

Rebecca Cran (6):
   Silicon/Ampere: Fix capitalization of Cache strings in PlatformInfoDxe
   Silicon/Ampere: Reduce DEBUG_INFO spam in PciSegmentLibPci
   Silicon/Ampere: Add TimerLib to DwGpioLib.inf for MicroSecondDelay
   Platform/Ampere: Don't try and close the ACPI table if OpenSdt fails
   Silicon/Ampere: Set default SMBIOS fw major/minor version to 0xFF
   Silicon/Ampere: Remove bogus ASSERT that *PpiList is non-NULL

  Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec  
|  4 ++--
  Silicon/Ampere/AmpereAltraPkg/Library/DwGpioLib/DwGpioLib.inf 
|  1 +
  Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiDsdt.c
|  1 -
  Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.c 
|  1 -
  Silicon/Ampere/AmpereAltraPkg/Library/PciSegmentLibPci/PciSegmentLib.c
| 24 ++--
  Silicon/Ampere/AmpereAltraPkg/Drivers/PlatformInfoDxe/PlatformInfoStrings.uni 
|  6 ++---
  6 files changed, 18 insertions(+), 19 deletions(-)




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119513): https://edk2.groups.io/g/devel/message/119513
Mute This Topic: https://groups.io/mt/106517021/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Ampere/JadePkg: Add secure boot default keys initialization

[Nhi Pham via groups.io]

Could you help push my patch to Tianocore/edk2-platforms once approved, 
while I don't have write permission?


Thanks,
Nhi

On 6/5/2024 11:10 AM, Rebecca Cran wrote:

Reviewed-by: Rebecca Cran 




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119467): https://edk2.groups.io/g/devel/message/119467
Mute This Topic: https://groups.io/mt/106495161/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 1/1] Ampere/JadePkg: Add secure boot default keys initialization

[Nhi Pham via groups.io]

This allows to initialize secure boot with the default factory keys
embedded in firmware flash image.

For example, to incorporate PK, KEK, and DB default keys, specify the
corresponding key files in the Jade.dsc as follows:

DEFINE DEFAULT_KEYS= TRUE
DEFINE PK_DEFAULT_FILE = path/to/PK.crt
DEFINE KEK_DEFAULT_FILE1   = path/to/KEK.crt
DEFINE DB_DEFAULT_FILE1= path/to/DB1.crt
DEFINE DB_DEFAULT_FILE2= path/to/DB2.crt

Signed-off-by: Nhi Pham 
---
 Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 2 ++
 Platform/Ampere/JadePkg/Jade.fdf | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc 
b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
index 23579497661d..93b4d1d99dcd 100644
--- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
+++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
@@ -590,6 +590,8 @@ [Components.common]
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+  SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.inf
+  
SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.inf
 !endif
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
diff --git a/Platform/Ampere/JadePkg/Jade.fdf b/Platform/Ampere/JadePkg/Jade.fdf
index 7795f0e5..1e2df5ba6142 100644
--- a/Platform/Ampere/JadePkg/Jade.fdf
+++ b/Platform/Ampere/JadePkg/Jade.fdf
@@ -219,7 +219,9 @@ [FV.FvMain]
   INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
   INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
 !if $(SECURE_BOOT_ENABLE) == TRUE
+!include ArmPlatformPkg/SecureBootDefaultKeys.fdf.inc
   INF 
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+  INF 
SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.inf
 !endif
   INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119455): https://edk2.groups.io/g/devel/message/119455
Mute This Topic: https://groups.io/mt/106495161/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] ASpeed/ASpeedGopBinPkg: Update X64/AArch64 Gop UEFI Driver

[Nhi Pham via groups.io]

On 5/30/2024 8:33 AM, Tommy Huang wrote>> On 5/29/2024 8:18 PM, Leif 
Lindholm via groups.io wrote:

+Nhi,

Could you check/verify these work fine on your systems?


Yes, I can. Thanks Leif for reaching out to me.

Hi Tommy Huang - Could you please create a Pull Request (PR) or share a
branch so I can easily apply and test the AArch64 GOP driver?


Sorry~ We just release our BIOS / GOP resources on our official website.
You could reach it from https://www.aspeedtech.com/support_driver/


Thanks for the link.


It was located VBIOS/UEFI -> Version 1.13.04 -> 1.13.04 -> UEFI -> AARCH64 -> 
uefi_arm_2500_800.efi and uefi_arm_2600.efi
These two binaries have been tested Mt. Collins system. You could double 
confirm it.


I tested the driver on my __BMC AST2600__ system. It works well. Thanks!





Also, I am never aware of GOP driver with secure boot enabled before. Is
the .efi binary signed with Microsoft's key?


Yes. These binaries are all signed with Microsoft's key.


Tested-by: Nhi Pham 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119411): https://edk2.groups.io/g/devel/message/119411
Mute This Topic: https://groups.io/mt/106342303/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] ASpeed/ASpeedGopBinPkg: Update X64/AArch64 Gop UEFI Driver

[Nhi Pham via groups.io]

On 5/29/2024 8:18 PM, Leif Lindholm via groups.io wrote:
> +Nhi,
> 
> Could you check/verify these work fine on your systems?

Yes, I can. Thanks Leif for reaching out to me.

Hi Tommy Huang - Could you please create a Pull Request (PR) or share a
branch so I can easily apply and test the AArch64 GOP driver?

Also, I am never aware of GOP driver with secure boot enabled before. Is
the .efi binary signed with Microsoft's key?

Thanks,
Nhi

> 
> Regards,
> 
> Leif
> 
> On 2024-05-28 03:08, Tommy Huang wrote:
>> 1.Update the X64/AArch64 UEFI GOP driver into v1.13.04.
>> 2.Update the .inf version.
>> 3.Fix display flick on ast2600.
>> 4.Remove 800x600@56 from mode list.
>> 5.Add check EDID header behavior.
>> 6.Signed .efi files for secuity boot needing.
>>
>> Cc: Ard Biesheuvel 
>> Cc: Isaac Oram 
>> Cc: Nate DeSimone 
>> Cc: Leif Lindholm 
>> Cc: Michael D Kinney 
>> Cc: Ryan Chen 
>> Cc: BMC-SW 
>>
>> Signed-off-by: Tommy Huang 
>> ---
>>   .../AArch64/ASpeedAst2500Gop.efi  | Bin 45056 -> 5
>> bytes
>>   .../AArch64/ASpeedAst2600Gop.efi  | Bin 45056 -> 54688
>> bytes
>>   .../ASpeedGopBinPkg/ASpeedAst2500GopDxe.inf   |   4 ++--
>>   .../ASpeedGopBinPkg/ASpeedAst2600GopDxe.inf   |   4 ++--
>>   .../ASpeedGopBinPkg/X64/ASpeedAst2500Gop.efi  | Bin 33600 -> 43720
>> bytes
>>   .../ASpeedGopBinPkg/X64/ASpeedAst2600Gop.efi  | Bin 30016 -> 40224
>> bytes
>>   6 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git
>> a/Drivers/ASpeed/ASpeedGopBinPkg/AArch64/ASpeedAst2500Gop.efi
>> b/Drivers/ASpeed/ASpeedGopBinPkg/AArch64/ASpeedAst2500Gop.efi
>> index
>> fcfe989404022f71aeb893a1002e2a28b0e91d64..b4ec7ec7bded4c0eff58894a99d926ebdd500e92
>>  100644
>> GIT binary patch
>> delta 21907
>> zcmb_?2V9g#^Z!229UbW%fuksh3P> z#S)6W#DcL!jer_kRKO@;yZ`JJASUmdy#LS7?3F-mtJ91%+~28
>> zKnStm2mf|w(IOp3?OJ%%Lum3=0%?i$9q9);eT)E8?+bW^yzXZSLcPVjk#w}KhK4|n
>> zApxDGYp+oRB^LaO=q> zx!fp0ji{hoEQb=|l`g%7gnLE1CF*QvpmGVH+xdY(l)non%1Z4CaRdk=tS7{(E4ZDF
>> z43qN5Cfv?i> zEUu38PK$TQ2BFOCLt8iFULFItX5a?gX&>wHAT8PFS
>> zqQl6E+bMu2$>esHKs^_PNct?@@MQtFOd6;zu4P2s4g~r*E`8hDnMj}sn~Bb~EHR-b
>> zXh2tN#rLJs4O{KdL5(lc2s?zX+X5c@kDcc`cHZTb;|=zTU0F3^al3XLAvi%
>> zMuunkBNDxOfe>z30Szi}!x%YDrPL;bw5LBwH`w$>Su7ZA6GBJ22%kHOV}=2> z#Ke13=6zj=&8> z*as6_C0L>*2anpj5=lHXaHGew3b6Kp-+!5gOr1{X0*AuL|&}i
>> z<*=7> z<4`dSx`l4+>u=Ly3#G>lvfKs{uLyN+=M((k)cu^fM`EQZ^scI> z(9wikYXP|y;*t@92CQb(Xh9b{+L0}ml{Joe3^JlO?ce{5`t`>k(+(q4sWsqNg1l}{
>> zzZ&?GG_#`bxNO$udWm>y
>> z#}Nct!yZQ_TF~L_P*UB3-paOM`dWxP=n}RWGsi;Q3NNN~3tNTEv7p=8JmLh+aqADB
>> zli+4U?4}pHr4TFWRyRwclTXVaM~Ao%2SXIQn-WoUnY#zUryl~s
>> zrTciWNr4qT!DAEAk8bra>)p{`%(H@)8wZFFfL@vy#^of;ujDimuciBVMv&}2^a4*d
>> zqs5j>@Aotzp3-MM9eNe@5g!L50!_7`X!?U^6>*&2=Vhj8)K}bO4BQg?($~BO5<9y<
>> zGdXDEJ&;(V1nUgsV7hl7LZAc*Jvn+h?>n)DTCC-<$CdY>UCw#Z`(x6{@E
>> z<_`R@83M=K_wxBf-~r7> zJ;aj3W>#d6NAwuZK;nCPA;+FLMVD~QOkhMY}I~p1^D^kX_@5i8wlDkQ?o7
>> zXAqjJ=n?ziJGl!LVa@^IEln!WdajF@gw~A=!^>N{9a>Ja$W=^WhX$I?4*C*rC-qKY
>> z@P9B=%ds> z+|>qg@f8=aPYjE4JZK~;v*f>4gR_)(> zAP|CQIBy;?1ZD9+lO^8P;apvAXSOpkQ1wR!YvJjyhB8%{+-d>Xy(ASClU$(JKoM~y
>> zQ;R}mN-7UUl-l`dF?@ORq7WnHcdjguwe0Xgo!hffHFqqxb7wxPE-6IS3~g{_;1i7~
>> z|JxFO)Cm%|lzN~}e=U@`J(~+e-0B@Z5Q;rf1eRK22u~1TXFj*Ot`7+7$GbUb2zQNS
>> zIO-JUl@v?-0$??nE2H)H*{YkUzZ6fjWXCTH#%gowhmAmlp+y39r9mnDNyry!3@
>> zuLS{a_XFaM470++sYb;Tko3WayqhKY!^#jcFZ4&|uXf{Q#RH@rOWOsxcujeXZtMWZ
>> z}b2g)fSzN5)#!7~8_FZUS}*GkKkHy^(%g#=> z5>PTn4T;Sd7KPcQ#pTP;J`UPNlc+E*G5T0su3or(qm3`d> zDt^c97|17*whcDsnw1ks(BO|uUP(SnBkVhWr(RX0Q#Rt8*k#KE{6
>> zV;G_wYXdG5WAvP0XQGBK2{!jMD@VY}23QF?q!BTgO=7gKZK9> zNxup1OGOVK$=M7uW9H9YlMUKf3%`5tYloi=6J-k3QN(A4QF%6Lba^tv2xbO?u#|Tb
>> z^9NII?%)R))nZ@{Ke?02> zs8|3K> z)sYMt58ReVAfN5Sxn2B}yl@{F$Gl!kU8SbDW6Th5hm=GZQ+9-L+z2;#LhBDR41*bo
>> zuz_)z2sSkkqD>9A4TPI*7^bg6z)EhDDTgT1=v9F1J@wFfwA> zyeC5$tO#^zQAjTx)|)yGikobM^e1Oq8BC^-Wh29~eE1(YCRvsXQBlKWf4%T#hJ|y0
>> z0>k1GL{WnuluJvw)iOFL2SCu_0454BbH*4!7BzT5IX1vlRu)3p4a(cWU1jx*q6QJy
>> ze6aHX0Gk;m)`K23+9;W~PP(D>tJKtF(WZua>@zU?LM<*wq{iiJOJx)b81$Us
>> zeZ2})k(V;g5Z`mFYe*ucNd-l0vj#)h_~Xv_xPKak)m8D3=kwoxU-=KY8IR
>> z{dM>(-X?5$z> z{<+UfTrJO<-vW1Cx9tmN$D> zhAABvGE{#V*fE~> zvYoV`8KI+yBlNgXN5Yk!7wSm1x6!4c{q-TvBfLCAoS*wax?{~FqtJlsaBjtn5L
>> zwb7v?=LhU>ldqhOunVe(m2Wu
>> zC04X!SUj@=3Eb$_VV=4bh~*^4Ay~Fr2G9**9DmqR_3wf87f0#oWXi)ZQTPU?9oEYV
>> zB!RV1MZjN6mK588{R!s^z*G#&{oc``qnw@9!BT2TE{6xO#Gc^bs#1F%M-^}~x|_VU
>> zjovcK+oA> zX#Qxs=~ti{_dzH`xq!*}s5J)2n;E9gO1vI$nae2XFpE=wDOsL}cPul>1h-Pq9BHE)
>> zM%$6Q+vpFYtqo|Pz#Nrgo^Pw{JLWcN@Um69p{Mx0+GriVo%KC{8-ZNeq+J#1pH7a3
>> zCBU$}p_LxZw-|jHNVb{sI02dh10~mU7_;PY?0R5z7_;GVnl-xVP6B4vqx`s)uHp~!
>> zDFc|)=_b1l<@I*l>KK?Ui59_;!MQwJ8{4YPV%#G)O;ZTr$ddm47X^=jSi
>> zR{> z*> z=fR#5_aSwGP(;;2SFS~qf(oeoIYY_z(|*1ojJc75gbMk{1kXA7MdX-7J>
>> z(xs7o$#*UErATM%Xqfq}B(s%}N+Tqi+<7)El-UTO4aa|$0c|jTkQR7Sktqv2Lu5ox
>> z7$0o!4Ncm?Yh<`O#=6(KHRG+Q{m}om8C*_4k2x#D7@sS1A3FuU9WaSC?Bq0^
>> zyz5^t?=lxLrZwPlN_%zB(I$)qK!EOnt;HC)W^4~^b@Lwm{60;vFm{?
>> z#+VM5L-xP~E%f>cp_C9@1xErr+v|W#;z4klEWy@1cpQixnz*cVv23WfK~`A;P@@u?
>> zrND%MZG$$Lk2121hq`u4Zs)sjUfKI80cBqnoZpSl@<>&{{~mN{XCTn*t
>> 

Re: [edk2-devel] [PATCH 0/9] Allocate and unblock variable runtime cache buffer in PEI

[Nhi Pham via groups.io]

On 5/17/2024 4:49 PM, duntan via groups.io wrote:

This patch set defines a new VARIABLE_RUNTIME_CACHE_INFO HOB. The HOB is used 
to store the address and size of the buffer that will be used for variable 
runtime service when the PcdEnableVariableRuntimeCache is TRUE.
In following patches, when PcdEnableVariableRuntimeCache is TRUE, VariablePei 
will install a callback of gEfiPeiMemoryDiscoveredPpiGuid to allocate the 
needed buffer for different type variable runtime cache and build the HOB.
Then VariableSmmRuntimeDxe driver will consume 
gEdkiiVariableRuntimeCacheInfoHobGuid to initialize the variable runtime cache 
related content. The code to allocate and unblock the runtime cache buffer in 
VariableSmmRuntimeDxe is also removed in this patc set.

PR for review: https://github.com/tianocore/edk2/pull/5607


Per design, SMM or StandaloneMM needs to access these runtime cache 
buffers for cache coherency. I'm not sure how to implement the 
MmUnblockMemoryLib for ARM to dynamically request mapping of the 
non-secure runtime cache buffers in StandaloneMM (Secure World). Is it 
possible to have these runtime buffers allocated statically with 
predefined PCD at build time. On ARM, they can also define the buffers 
in device tree (manifest)?


Thanks,
Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119068): https://edk2.groups.io/g/devel/message/119068
Mute This Topic: https://groups.io/mt/106150796/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v2] ManageabilityPkg: add support for the phosphor ipmi blob transfer protocol

[Nhi Pham via groups.io]

Hi Abner,

It' hard to say actually. I don't spend full-time for open-source work. 
But I will try to complete it within 2 weeks or sooner.


Most of Ampere Altra drivers including IPMI SSIF are living at 
https://github.com/AmpereComputing/edk2-platforms. The effort now is to 
port to be compatible with ManageabilityPkg.


Regards,
Nhi

On 5/17/2024 3:16 PM, Chang, Abner wrote:

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Nhi,
How much effort you think to have the SSIF ManageabilityPkg port?

Regards,
Abner


-Original Message-
From: Nhi Pham 
Sent: Friday, May 17, 2024 3:49 PM
To: Nickle Wang ; devel@edk2.groups.io
Cc: Chang, Abner ; Attar, AbdulLateef (Abdul
Lateef) ; Tinh Nguyen
; Thang Nguyen OS
; Mike Maslenkin

Subject: Re: [edk2-platforms][PATCH v2] ManageabilityPkg: add support for
the phosphor ipmi blob transfer protocol

Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.


Hi Nickle,

Please see my comments inline...

P/s: I just realized that I can not test this protocol without IPMI SSIF
to be compatible with ManageabilityPkg framework.

On 5/15/2024 10:06 PM, Nickle Wang wrote:

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

This change implements the blob transfer protocol used in OpenBmc
documented here: https://github.com/openbmc/phosphor-ipmi-blobs

Signed-off-by: Nick Ramirez 
Co-authored-by: Nickle Wang 
Cc: Abner Chang 
Cc: Abdul Lateef Attar 
Cc: Tinh Nguyen 
Cc: Nhi Pham 
Cc: Thang Nguyen OS 
Cc: Mike Maslenkin 
---
   .../ManageabilityPkg/ManageabilityPkg.dec |3 +
   .../Include/Manageability.dsc |2 +
   .../IpmiBlobTransferDxe.inf   |   39 +
   .../IpmiBlobTransferTestUnitTestsHost.inf |   40 +
   .../Include/Protocol/IpmiBlobTransfer.h   |  253 
   .../InternalIpmiBlobTransfer.h|  407 ++
   .../IpmiBlobTransferDxe/IpmiBlobTransferDxe.c |  872 +
   .../UnitTest/IpmiBlobTransferTestUnitTests.c  | 1113 +
   .../Universal/IpmiBlobTransferDxe/Readme.md   |   24 +
   9 files changed, 2753 insertions(+)
   create mode 100644

Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/IpmiBlobTransfer
Dxe.inf

   create mode 100644

Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/UnitTest/IpmiBlo
bTransferTestUnitTestsHost.inf

   create mode 100644

Features/ManageabilityPkg/Include/Protocol/IpmiBlobTransfer.h

   create mode 100644

Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/InternalIpmiBlob
Transfer.h

   create mode 100644

Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/IpmiBlobTransfer
Dxe.c

   create mode 100644

Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/UnitTest/IpmiBlo
bTransferTestUnitTests.c

   create mode 100644

Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/Readme.md


diff --git a/Features/ManageabilityPkg/ManageabilityPkg.dec

b/Features/ManageabilityPkg/ManageabilityPkg.dec

index eb0ee67cba..dc1d00162c 100644
--- a/Features/ManageabilityPkg/ManageabilityPkg.dec
+++ b/Features/ManageabilityPkg/ManageabilityPkg.dec
@@ -4,6 +4,7 @@
   # those are related to the platform management.
   #
   # Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+# Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES. All rights

reserved.

   # SPDX-License-Identifier: BSD-2-Clause-Patent
   #
   ##
@@ -58,6 +59,8 @@
 gEdkiiPldmProtocolGuid= { 0x60997616, 0xDB70, 0x4B5F, { 
0x86,

0xA4, 0x09, 0x58, 0xA3, 0x71, 0x47, 0xB4 } }

 gEdkiiPldmSmbiosTransferProtocolGuid  = { 0xFA431C3C, 0x816B, 0x4B32,

{ 0xA3, 0xE0, 0xAD, 0x9B, 0x7F, 0x64, 0x27, 0x2E } }

 gEdkiiMctpProtocolGuid= { 0xE93465C1, 0x9A31, 0x4C96, { 
0x92,

0x56, 0x22, 0x0A, 0xE1, 0x80, 0xB4, 0x1B } }

+  ## Include/Protocol/IpmiBlobTransfer.h
+  gEdkiiIpmiBlobTransferProtocolGuid= { 0x05837c75, 0x1d65, 0x468b,

{ 0xb1, 0xc2, 0x81, 0xaf, 0x9a, 0x31, 0x5b, 0x2c } }


   [PcdsFixedAtBuild]
 ## This value is the MCTP Interface source and destination endpoint ID for

transmiting MCTP message.

diff --git a/Features/ManageabilityPkg/Include/Manageability.dsc

b/Features/ManageabilityPkg/Include/Manageability.dsc

index 2e410df9ba..aae343a733 100644
--- a/Features/ManageabilityPkg/Include/Manageability.dsc
+++ b/Features/ManageabilityPkg/Include/Manageability.dsc
@@ -2,6 +2,7 @@
   # Common libraries for Manageabilty Package
   #
   # Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+# Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES. All rights

reserved.

   # SPDX-License-Identifier: BSD-2-Clause-Patent
   #
   ##
@@ -37,6 +38,7 @@
   [Components.X64, Components.AARCH64]
   !if gManageabilityPkgTokenSpaceGuid.PcdManageabilityDxeIpmiEnable ==

TRUE

 ManageabilityPkg/Universal/IpmiProtocol/Dxe/IpmiProtocolDxe.inf
+

Re: [edk2-devel] [edk2-platforms][PATCH v2] ManageabilityPkg: add support for the phosphor ipmi blob transfer protocol

[Nhi Pham via groups.io]

Hi Nickle,

Please see my comments inline...

P/s: I just realized that I can not test this protocol without IPMI SSIF 
to be compatible with ManageabilityPkg framework.


On 5/15/2024 10:06 PM, Nickle Wang wrote:

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

This change implements the blob transfer protocol used in OpenBmc
documented here: https://github.com/openbmc/phosphor-ipmi-blobs

Signed-off-by: Nick Ramirez 
Co-authored-by: Nickle Wang 
Cc: Abner Chang 
Cc: Abdul Lateef Attar 
Cc: Tinh Nguyen 
Cc: Nhi Pham 
Cc: Thang Nguyen OS 
Cc: Mike Maslenkin 
---
  .../ManageabilityPkg/ManageabilityPkg.dec |3 +
  .../Include/Manageability.dsc |2 +
  .../IpmiBlobTransferDxe.inf   |   39 +
  .../IpmiBlobTransferTestUnitTestsHost.inf |   40 +
  .../Include/Protocol/IpmiBlobTransfer.h   |  253 
  .../InternalIpmiBlobTransfer.h|  407 ++
  .../IpmiBlobTransferDxe/IpmiBlobTransferDxe.c |  872 +
  .../UnitTest/IpmiBlobTransferTestUnitTests.c  | 1113 +
  .../Universal/IpmiBlobTransferDxe/Readme.md   |   24 +
  9 files changed, 2753 insertions(+)
  create mode 100644 
Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/IpmiBlobTransferDxe.inf
  create mode 100644 
Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/UnitTest/IpmiBlobTransferTestUnitTestsHost.inf
  create mode 100644 
Features/ManageabilityPkg/Include/Protocol/IpmiBlobTransfer.h
  create mode 100644 
Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/InternalIpmiBlobTransfer.h
  create mode 100644 
Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/IpmiBlobTransferDxe.c
  create mode 100644 
Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/UnitTest/IpmiBlobTransferTestUnitTests.c
  create mode 100644 
Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/Readme.md

diff --git a/Features/ManageabilityPkg/ManageabilityPkg.dec 
b/Features/ManageabilityPkg/ManageabilityPkg.dec
index eb0ee67cba..dc1d00162c 100644
--- a/Features/ManageabilityPkg/ManageabilityPkg.dec
+++ b/Features/ManageabilityPkg/ManageabilityPkg.dec
@@ -4,6 +4,7 @@
  # those are related to the platform management.
  #
  # Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+# Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
  # SPDX-License-Identifier: BSD-2-Clause-Patent
  #
  ##
@@ -58,6 +59,8 @@
gEdkiiPldmProtocolGuid= { 0x60997616, 0xDB70, 0x4B5F, { 
0x86, 0xA4, 0x09, 0x58, 0xA3, 0x71, 0x47, 0xB4 } }
gEdkiiPldmSmbiosTransferProtocolGuid  = { 0xFA431C3C, 0x816B, 0x4B32, { 
0xA3, 0xE0, 0xAD, 0x9B, 0x7F, 0x64, 0x27, 0x2E } }
gEdkiiMctpProtocolGuid= { 0xE93465C1, 0x9A31, 0x4C96, { 
0x92, 0x56, 0x22, 0x0A, 0xE1, 0x80, 0xB4, 0x1B } }
+  ## Include/Protocol/IpmiBlobTransfer.h
+  gEdkiiIpmiBlobTransferProtocolGuid= { 0x05837c75, 0x1d65, 0x468b, { 
0xb1, 0xc2, 0x81, 0xaf, 0x9a, 0x31, 0x5b, 0x2c } }
  
  [PcdsFixedAtBuild]

## This value is the MCTP Interface source and destination endpoint ID for 
transmiting MCTP message.
diff --git a/Features/ManageabilityPkg/Include/Manageability.dsc 
b/Features/ManageabilityPkg/Include/Manageability.dsc
index 2e410df9ba..aae343a733 100644
--- a/Features/ManageabilityPkg/Include/Manageability.dsc
+++ b/Features/ManageabilityPkg/Include/Manageability.dsc
@@ -2,6 +2,7 @@
  # Common libraries for Manageabilty Package
  #
  # Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
+# Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
  # SPDX-License-Identifier: BSD-2-Clause-Patent
  #
  ##
@@ -37,6 +38,7 @@
  [Components.X64, Components.AARCH64]
  !if gManageabilityPkgTokenSpaceGuid.PcdManageabilityDxeIpmiEnable == TRUE
ManageabilityPkg/Universal/IpmiProtocol/Dxe/IpmiProtocolDxe.inf
+  ManageabilityPkg/Universal/IpmiBlobTransferDxe/IpmiBlobTransferDxe.inf
  !endif
  
  [Components.X64]

diff --git 
a/Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/IpmiBlobTransferDxe.inf
 
b/Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/IpmiBlobTransferDxe.inf
new file mode 100644
index 00..108f4bb5f8
--- /dev/null
+++ 
b/Features/ManageabilityPkg/Universal/IpmiBlobTransferDxe/IpmiBlobTransferDxe.inf
@@ -0,0 +1,39 @@
+## @file
+# IPMI Blob Transfer Protocol DXE Driver.
+#
+#  Copyright (c) 2022-2024, NVIDIA CORPORATION & AFFILIATES. All rights 
reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = IpmiBlobTransferDxe
+  FILE_GUID  = 6357c804-78bb-4b0c-abdf-c75df942f319
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= IpmiBlobTransferDxeDriverEntryPoint
+
+[Sources.common]
+  IpmiBlobTransferDxe.c
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  IpmiLib
+  

Re: [edk2-devel] [edk2-platforms][PATCH] ManageabilityPkg: add support for the phosphor ipmi blob transfer protocol

[Nhi Pham via groups.io]

On 5/16/2024 3:44 PM, Chang, Abner wrote:

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Nhi,
Are you using SSIF as the transport interface based on the ManabeabilityPkg 
framework? If yes, will you contribute that driver?



yes, we are. I will need to update the SSIF driver to be compatible with 
the ManabeabilityPkg and upstream it.


Regards,
Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118952): https://edk2.groups.io/g/devel/message/118952
Mute This Topic: https://groups.io/mt/98212643/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH] ManageabilityPkg: add support for the phosphor ipmi blob transfer protocol

[Nhi Pham via groups.io]

Thanks Nickle. I'm reviewing and testing it. Will get back to you soon.

On 5/15/2024 10:14 PM, Nickle Wang via groups.io wrote:

Hi Nhi,

Version 2 patch files are sent for review here: 
https://edk2.groups.io/g/devel/message/118914 and 
https://edk2.groups.io/g/devel/message/118922

For your convenience, below are two pull requests if you would like to test 
them.

1) https://github.com/tianocore/edk2/pull/5660
2) https://github.com/tianocore/edk2-platforms/pull/76

I had tried to address review comments as much as I can. Please feel free to 
let me know if you see any issue in this version of patch set.

Thanks,
Nickle


-Original Message-
From: Nhi Pham 
Sent: Tuesday, May 14, 2024 10:26 AM
To: Nickle Wang ; devel@edk2.groups.io;
abner.ch...@amd.com; Rebecca Cran 
Cc: Isaac Oram ; Attar, AbdulLateef (Abdul Lateef)
; Tinh Nguyen

Subject: Re: [edk2-devel] [edk2-platforms][PATCH] ManageabilityPkg: add
support for the phosphor ipmi blob transfer protocol

External email: Use caution opening links or attachments


Thanks Nickle. I will help review and verify your patch.

On 5/14/2024 8:56 AM, Nickle Wang wrote:

Hi Nhi,

This task is on my list but with lower priority. I will try to provide version 
2 patch

for review here by the end of this week.


Thanks,
Nickle


-Original Message-
From: Nhi Pham 
Sent: Monday, May 13, 2024 5:02 PM
To: devel@edk2.groups.io; abner.ch...@amd.com; Nickle Wang
; Rebecca Cran 
Cc: Isaac Oram ; Attar, AbdulLateef (Abdul
Lateef) ; Tinh Nguyen

Subject: Re: [edk2-devel] [edk2-platforms][PATCH] ManageabilityPkg:
add support for the phosphor ipmi blob transfer protocol

External email: Use caution opening links or attachments


On 2/9/2024 11:37 PM, Chang, Abner via groups.io wrote:

[AMD Official Use Only - General]

Yeah, I forget this patch set and seems we don't have any follow up
conversation

after below feedbacks from community.


https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fed


k2%2F=05%7C02%7Cnicklew%40nvidia.com%7Cdc53be8f0cf24ccfd35108d
c



73bd2d45%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C6385125035
6068



8708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
LCJ



BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=%2BCkaU%2FcdG1v
r6uPsA

7fqrvhvxg%2FX5FqcmJ6fizaa9fA%3D=0
.groups.io%2Fg%2Fdevel%2Fmessage%2F103116=05%7C02%7Cnickle

w

%40nvi





dia.com%7C8b9e1a8a8d044208f8d608dc732b678d%7C43083d15727340c1b7db

39efd





9ccc17a%7C0%7C0%7C638511877469561600%7CUnknown%7CTWFpbGZsb3d8

eyJWIjoiM





C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7

C%7C

=N4eDH668lBSFxq9r81QrhMgpULvht8isrrEI9lipVKc%3D=0
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fed


k2%2F=05%7C02%7Cnicklew%40nvidia.com%7Cdc53be8f0cf24ccfd35108d
c



73bd2d45%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C6385125035
6070



0897%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
LCJ



BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=KFd86NhmrQeGqEB
8%2FJy

0qnbMkb%2Furpo8YCsVbVsOxNk%3D=0
.groups.io%2Fg%2Fdevel%2Fmessage%2F103087=05%7C02%7Cnickle

w

%40nvi





dia.com%7C8b9e1a8a8d044208f8d608dc732b678d%7C43083d15727340c1b7db

39efd





9ccc17a%7C0%7C0%7C638511877469569817%7CUnknown%7CTWFpbGZsb3d8

eyJWIjoiM





C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7

C%7C





=7p0BHb8RFRapFyygr35u0hQBK2bQwKPSypBaUi6cMIQ%3D=0


So Nickle, does NV still has the plan to upstream IPMI blob edk2

implementation? We should keep driving upstream the implementation as
industry needs it to incorporate with OpenBMC.


Hi Rebessa,
As we are on Chinese New Year holidays now, please expect the delay

response.

Thanks
Abner



Hi Nickle and Abner,

May I know the status of upstreaming the IPMI Blob Transfer Protocol?
I'm planning to upstream the SMBIOS transfer to OpenBMC by leveraging
this protocol.

Thanks,
Nhi









-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118950): https://edk2.groups.io/g/devel/message/118950
Mute This Topic: https://groups.io/mt/98212643/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH] ManageabilityPkg: add support for the phosphor ipmi blob transfer protocol

[Nhi Pham via groups.io]

Thanks Nickle. I will help review and verify your patch.

On 5/14/2024 8:56 AM, Nickle Wang wrote:

Hi Nhi,

This task is on my list but with lower priority. I will try to provide version 
2 patch for review here by the end of this week.

Thanks,
Nickle


-Original Message-
From: Nhi Pham 
Sent: Monday, May 13, 2024 5:02 PM
To: devel@edk2.groups.io; abner.ch...@amd.com; Nickle Wang
; Rebecca Cran 
Cc: Isaac Oram ; Attar, AbdulLateef (Abdul Lateef)
; Tinh Nguyen

Subject: Re: [edk2-devel] [edk2-platforms][PATCH] ManageabilityPkg: add
support for the phosphor ipmi blob transfer protocol

External email: Use caution opening links or attachments


On 2/9/2024 11:37 PM, Chang, Abner via groups.io wrote:

[AMD Official Use Only - General]

Yeah, I forget this patch set and seems we don't have any follow up conversation

after below feedbacks from community.


https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2
.groups.io%2Fg%2Fdevel%2Fmessage%2F103116=05%7C02%7Cnicklew

%40nvi



dia.com%7C8b9e1a8a8d044208f8d608dc732b678d%7C43083d15727340c1b7db
39efd



9ccc17a%7C0%7C0%7C638511877469561600%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiM



C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7
C%7C

=N4eDH668lBSFxq9r81QrhMgpULvht8isrrEI9lipVKc%3D=0
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2
.groups.io%2Fg%2Fdevel%2Fmessage%2F103087=05%7C02%7Cnicklew

%40nvi



dia.com%7C8b9e1a8a8d044208f8d608dc732b678d%7C43083d15727340c1b7db
39efd



9ccc17a%7C0%7C0%7C638511877469569817%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiM



C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7
C%7C



=7p0BHb8RFRapFyygr35u0hQBK2bQwKPSypBaUi6cMIQ%3D=0


So Nickle, does NV still has the plan to upstream IPMI blob edk2

implementation? We should keep driving upstream the implementation as
industry needs it to incorporate with OpenBMC.


Hi Rebessa,
As we are on Chinese New Year holidays now, please expect the delay response.
Thanks
Abner



Hi Nickle and Abner,

May I know the status of upstreaming the IPMI Blob Transfer Protocol?
I'm planning to upstream the SMBIOS transfer to OpenBMC by leveraging this
protocol.

Thanks,
Nhi



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118879): https://edk2.groups.io/g/devel/message/118879
Mute This Topic: https://groups.io/mt/98212643/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH] ManageabilityPkg: add support for the phosphor ipmi blob transfer protocol

[Nhi Pham via groups.io]

On 2/9/2024 11:37 PM, Chang, Abner via groups.io wrote:

[AMD Official Use Only - General]

Yeah, I forget this patch set and seems we don't have any follow up 
conversation after below feedbacks from community.

https://edk2.groups.io/g/devel/message/103116
https://edk2.groups.io/g/devel/message/103087

So Nickle, does NV still has the plan to upstream IPMI blob edk2 
implementation? We should keep driving upstream the implementation as industry 
needs it to incorporate with OpenBMC.

Hi Rebessa,
As we are on Chinese New Year holidays now, please expect the delay response.
Thanks
Abner



Hi Nickle and Abner,

May I know the status of upstreaming the IPMI Blob Transfer Protocol? 
I'm planning to upstream the SMBIOS transfer to OpenBMC by leveraging 
this protocol.


Thanks,
Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118860): https://edk2.groups.io/g/devel/message/118860
Mute This Topic: https://groups.io/mt/98212643/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] StandaloneMmPkg/StandaloneMmHobLib: Remove HOB creation

[Nhi Pham via groups.io]

On 5/2/2024 4:31 AM, Oliver Smith-Denny via groups.io wrote:

Hi folks, returning to this thread because I noticed that HOB
creation still exists in StandaloneMmCore for ARM:

https://github.com/tianocore/edk2/blob/5d4c5253e8bbc0baa8837fcd868925212df85201/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c

As far as I can tell, there is only this one file that creates 6
HOBs from StandaloneMmCore. Per our earlier discussion that led to
disabling HOB creation in StandaloneMm, I think that this falls into
the case where StandaloneMm is a HOB consumer phase, not a producer
phase and so it should not be creating these HOBs. On the x64 side,
all of the StandaloneMm HOB creation functions ASSERT with the
comment that StandaloneMm is a HOB consumer phase and should not
be creating HOBs.


The HOB creation in StandaloneMmCoreEntryPoint is exclusively consumed 
by the MM_CORE_STANDALONE module 
(StandaloneMmPkg/Core/StandaloneMmCore.inf), not a MM_STANDALONE module. 
Per my understanding earlier, the MM_CORE_STANDALONE is a producer and 
other MM_STANDALONE modules are consumers. So we removed the HOB 
creation in the StandaloneMmHobLib which is consumed by MM_STANDALONE 
modules.


Also, we still retain the HOB creation in the 
StandaloneMmPkg/Library/StandaloneMmCoreHobLib library instance.


Regards,
Nhi



On ARM this is more complicated, as all of this information would
seem to originate from TF-A and so we would need TF-A to produce
these HOBs to tell StandaloneMm the information it needs to
operate. Today TF-A already has to communicate this information, the
HOBs are just created in StandaloneMmCore instead of in TF-A.

Curious to get other folks thoughts here on this paradigm.

Thanks,
Oliver

On 12/5/2023 5:47 AM, Nhi Pham wrote:

According to the discussion in "StandaloneMmPkg: Fix HOB space and
heap space conflicted issue" [1], Standalone MM modules should be HOB
consumers where HOB is read-only. Therefore, this patch removes the
supported functions for HOB creation in the StandaloneMmHobLib.

[1] https://edk2.groups.io/g/devel/message/108333

Cc: Ard Biesheuvel 
Cc: Ray Ni 
Cc: Sami Mujawar 
Cc: Oliver Smith-Denny 
Signed-off-by: Nhi Pham 
---
  StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c | 
171 ++--

  1 file changed, 51 insertions(+), 120 deletions(-)

diff --git 
a/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c 
b/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c

index ee61bdd227d0..bef66d167494 100644
--- a/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
+++ b/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
@@ -1,5 +1,5 @@
  /** @file

-  HOB Library implementation for Standalone MM Core.

+  HOB Library implementation for Standalone MM modules.


  Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.

  Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.

@@ -250,48 +250,13 @@ GetBootModeHob (
    return HandOffHob->BootMode;

  }


-VOID *

-CreateHob (

-  IN  UINT16  HobType,

-  IN  UINT16  HobLength

-  )

-{

-  EFI_HOB_HANDOFF_INFO_TABLE  *HandOffHob;

-  EFI_HOB_GENERIC_HEADER  *HobEnd;

-  EFI_PHYSICAL_ADDRESS    FreeMemory;

-  VOID    *Hob;

-

-  HandOffHob = GetHobList ();

-

-  HobLength = (UINT16)((HobLength + 0x7) & (~0x7));

-

-  FreeMemory = HandOffHob->EfiFreeMemoryTop - 
HandOffHob->EfiFreeMemoryBottom;


-

-  if (FreeMemory < HobLength) {

-    return NULL;

-  }

-

-  Hob    = (VOID 
*)(UINTN)HandOffHob->EfiEndOfHobList;


-  ((EFI_HOB_GENERIC_HEADER *)Hob)->HobType   = HobType;

-  ((EFI_HOB_GENERIC_HEADER *)Hob)->HobLength = HobLength;

-  ((EFI_HOB_GENERIC_HEADER *)Hob)->Reserved  = 0;

-

-  HobEnd  = (EFI_HOB_GENERIC_HEADER *)((UINTN)Hob 
+ HobLength);


-  HandOffHob->EfiEndOfHobList = (EFI_PHYSICAL_ADDRESS)(UINTN)HobEnd;

-

-  HobEnd->HobType   = EFI_HOB_TYPE_END_OF_HOB_LIST;

-  HobEnd->HobLength = sizeof (EFI_HOB_GENERIC_HEADER);

-  HobEnd->Reserved  = 0;

-  HobEnd++;

-  HandOffHob->EfiFreeMemoryBottom = (EFI_PHYSICAL_ADDRESS)(UINTN)HobEnd;

-

-  return Hob;

-}

-

  /**

    Builds a HOB for a loaded PE32 module.


    This function builds a HOB for a loaded PE32 module.

+  It can only be invoked by Standalone MM Core.

+  For Standalone MM drivers, it will ASSERT() since HOB is read only 
for Standalone MM drivers.


+

    If ModuleName is NULL, then ASSERT().

    If there is no additional space for HOB creation, then ASSERT().


@@ -310,33 +275,19 @@ BuildModuleHob (
    IN EFI_PHYSICAL_ADDRESS  EntryPoint

    )

  {

-  EFI_HOB_MEMORY_ALLOCATION_MODULE  *Hob;

-

-  ASSERT (

-    ((MemoryAllocationModule & (EFI_PAGE_SIZE - 1)) == 0) &&

-    ((ModuleLength & (EFI_PAGE_SIZE - 1)) == 0)

-    );

-

-  Hob = CreateHob (EFI_HOB_TYPE_MEMORY_ALLOCATION, sizeof 
(EFI_HOB_MEMORY_ALLOCATION_MODULE));


-

-  CopyGuid 

Re: [edk2-devel] [PATCH 1/1] CryptoPkg: Add new API to get PKCS7 Signature

[Nhi Pham via groups.io]

On 2/1/2024 9:09 AM, Yao, Jiewen via groups.io wrote:

Hi Nhi
Would you please:
1) File an issue in Bugzilla - https://bugzilla.tianocore.org/
2) Share with us the usage of this new API.

We are trying to understand why it is needed.


Hi Jiewen,

Sorry for late response. I've just been back from vacation. Happy Lunar 
New Year!


Let me try to explain the demand. This new API is consumed by Ampere 
Altra EDK2 [1] for enrolling platform UEFI boot/update keys managed by 
secure storage service in secure world. That is Ampere Trusted Firmware 
Secure Boot/Update Design [2] which provides platform firmware owners a 
way to generate the pair of keys, sign their UEFI firmware, and enroll 
their public key under the UEFI Secure Variable Format.


Any update (modify/append/delete) must be authenticated in secure world. 
Hence, that is the reason we have to extract the key and pass the 
signature to secure storage service.


I wonder whether it would be possible to have this API in the CryptLib 
before opening the Bugzilla ticket?


[1] 
https://github.com/AmpereComputing/edk2-platforms/blob/ampere/Silicon/Ampere/AmpereAltraPkg/Library/SecVarLib/SecVarLib.c#L613

[2] https://blog.cloudflare.com/armed-to-boot

Thanks,
Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115583): https://edk2.groups.io/g/devel/message/115583
Mute This Topic: https://groups.io/mt/104048629/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] StandaloneMmPkg/Core: Remove optimization for depex evaluation

[Nhi Pham via groups.io]

On 1/19/2024 6:51 PM, levi.yun wrote:

Except, 8bit transfer encoding.

Tested-by: levi.yun 
Reviewed-by: levi.yun 


Thanks Levi Yun for testing.

-Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114131): https://edk2.groups.io/g/devel/message/114131
Mute This Topic: https://groups.io/mt/103824815/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH RESEND 1/1] StandaloneMmPkg/Core: Remove optimization for depex evaluation

[Nhi Pham via groups.io]

From: Laszlo Ersek 

The current dependency evaluator violates the memory access permission
when patching depex grammar directly in the read-only depex memory area.

Laszlo pointed out the optimization issue in the thread (1) "Memory
Attribute for depex section" and provided suggested patch to remove the
perf optimization.

In my testing, removing the optimization does not make significant perf
reduction. That makes sense that StandaloneMM dispatcher only searches
in MM protocol database and does not depend on UEFI/DXE protocol
database. Also, we don't have many protocols in StandaloneMM like
UEFI/DXE.

>From Laszlo,

"The patch removes the EFI_DEP_REPLACE_TRUE handling altogether, plus it
CONST-ifies the Iterator pointer (which points into the DEPEX section),
so that the compiler catch any possible accesses at *build time* that
would write to the write-protected DEPEX memory area."

(1) https://edk2.groups.io/g/devel/message/113531

Signed-off-by: Nhi Pham 
Tested-by: levi.yun 
Reviewed-by: levi.yun 
---
 StandaloneMmPkg/Core/Dependency.c | 37 
 1 file changed, 7 insertions(+), 30 deletions(-)

diff --git a/StandaloneMmPkg/Core/Dependency.c 
b/StandaloneMmPkg/Core/Dependency.c
index 440fe3e45238..2bcb07d34666 100644
--- a/StandaloneMmPkg/Core/Dependency.c
+++ b/StandaloneMmPkg/Core/Dependency.c
@@ -13,16 +13,6 @@
 
 #include "StandaloneMmCore.h"
 
-///
-/// EFI_DEP_REPLACE_TRUE - Used to dynamically patch the dependency expression
-///to save time.  A EFI_DEP_PUSH is evaluated one an
-///replaced with EFI_DEP_REPLACE_TRUE. If PI spec's 
Vol 2
-///Driver Execution Environment Core Interface use 0xff
-///as new DEPEX opcode. EFI_DEP_REPLACE_TRUE should be
-///defined to a new value that is not conflicting with 
PI spec.
-///
-#define EFI_DEP_REPLACE_TRUE  0xff
-
 ///
 /// Define the initial size of the dependency expression evaluation stack
 ///
@@ -170,12 +160,12 @@ MmIsSchedulable (
   IN  EFI_MM_DRIVER_ENTRY  *DriverEntry
   )
 {
-  EFI_STATUS  Status;
-  UINT8   *Iterator;
-  BOOLEAN Operator;
-  BOOLEAN Operator2;
-  EFI_GUIDDriverGuid;
-  VOID*Interface;
+  EFI_STATUS   Status;
+  CONST UINT8  *Iterator;
+  BOOLEAN  Operator;
+  BOOLEAN  Operator2;
+  EFI_GUID DriverGuid;
+  VOID *Interface;
 
   Operator  = FALSE;
   Operator2 = FALSE;
@@ -253,8 +243,7 @@ MmIsSchedulable (
   Status = PushBool (FALSE);
 } else {
   DEBUG ((DEBUG_DISPATCH, "  PUSH GUID(%g) = TRUE\n", ));
-  *Iterator = EFI_DEP_REPLACE_TRUE;
-  Status= PushBool (TRUE);
+  Status = PushBool (TRUE);
 }
 
 if (EFI_ERROR (Status)) {
@@ -356,18 +345,6 @@ MmIsSchedulable (
 DEBUG ((DEBUG_DISPATCH, "  RESULT = %a\n", Operator ? "TRUE" : 
"FALSE"));
 return Operator;
 
-  case EFI_DEP_REPLACE_TRUE:
-CopyMem (, Iterator + 1, sizeof (EFI_GUID));
-DEBUG ((DEBUG_DISPATCH, "  PUSH GUID(%g) = TRUE\n", ));
-Status = PushBool (TRUE);
-if (EFI_ERROR (Status)) {
-  DEBUG ((DEBUG_DISPATCH, "  RESULT = FALSE (Unexpected error)\n"));
-  return FALSE;
-}
-
-Iterator += sizeof (EFI_GUID);
-break;
-
   default:
 DEBUG ((DEBUG_DISPATCH, "  RESULT = FALSE (Unknown opcode)\n"));
 goto Done;
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114130): https://edk2.groups.io/g/devel/message/114130
Mute This Topic: https://groups.io/mt/103879487/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] StandaloneMmPkg/Core: Remove optimization for depex evaluation

[Nhi Pham via groups.io]

On 1/19/2024 5:39 PM, Ard Biesheuvel wrote:


Thanks for the patch. This looks good to me in principle, only the
patch got mangled by your MTA

Please resend using 8bit transfer encoding. (You can use
BaseTools/Scripts/SetupGit.py to configure Git for you)



Thanks Ard, I will resend the patch with 8bit transfer encoding.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114129): https://edk2.groups.io/g/devel/message/114129
Mute This Topic: https://groups.io/mt/103824815/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] StandaloneMmPkg/Core: Remove optimization for depex evaluation

[Nhi Pham via groups.io]

From: Laszlo Ersek 

The current dependency evaluator violates the memory access permission
when patching depex grammar directly in the read-only depex memory area.

Laszlo pointed out the optimization issue in the thread (1) "Memory
Attribute for depex section" and provided suggested patch to remove the
perf optimization.

In my testing, removing the optimization does not make significant perf
reduction. That makes sense that StandaloneMM dispatcher only searches
in MM protocol database and does not depend on UEFI/DXE protocol
database. Also, we don't have many protocols in StandaloneMM like
UEFI/DXE.

>From Laszlo,

"The patch removes the EFI_DEP_REPLACE_TRUE handling altogether, plus it
CONST-ifies the Iterator pointer (which points into the DEPEX section),
so that the compiler catch any possible accesses at *build time* that
would write to the write-protected DEPEX memory area."

(1) https://edk2.groups.io/g/devel/message/113531

Signed-off-by: Nhi Pham 
---
 StandaloneMmPkg/Core/Dependency.c | 37 
 1 file changed, 7 insertions(+), 30 deletions(-)

diff --git a/StandaloneMmPkg/Core/Dependency.c 
b/StandaloneMmPkg/Core/Dependency.c
index 440fe3e45238..2bcb07d34666 100644
--- a/StandaloneMmPkg/Core/Dependency.c
+++ b/StandaloneMmPkg/Core/Dependency.c
@@ -13,16 +13,6 @@
 

 #include "StandaloneMmCore.h"

 

-///

-/// EFI_DEP_REPLACE_TRUE - Used to dynamically patch the dependency expression

-///to save time.  A EFI_DEP_PUSH is evaluated one an

-///replaced with EFI_DEP_REPLACE_TRUE. If PI spec's 
Vol 2

-///Driver Execution Environment Core Interface use 0xff

-///as new DEPEX opcode. EFI_DEP_REPLACE_TRUE should be

-///defined to a new value that is not conflicting with 
PI spec.

-///

-#define EFI_DEP_REPLACE_TRUE  0xff

-

 ///

 /// Define the initial size of the dependency expression evaluation stack

 ///

@@ -170,12 +160,12 @@ MmIsSchedulable (
   IN  EFI_MM_DRIVER_ENTRY  *DriverEntry

   )

 {

-  EFI_STATUS  Status;

-  UINT8   *Iterator;

-  BOOLEAN Operator;

-  BOOLEAN Operator2;

-  EFI_GUIDDriverGuid;

-  VOID*Interface;

+  EFI_STATUS   Status;

+  CONST UINT8  *Iterator;

+  BOOLEAN  Operator;

+  BOOLEAN  Operator2;

+  EFI_GUID DriverGuid;

+  VOID *Interface;

 

   Operator  = FALSE;

   Operator2 = FALSE;

@@ -253,8 +243,7 @@ MmIsSchedulable (
   Status = PushBool (FALSE);

 } else {

   DEBUG ((DEBUG_DISPATCH, "  PUSH GUID(%g) = TRUE\n", ));

-  *Iterator = EFI_DEP_REPLACE_TRUE;

-  Status= PushBool (TRUE);

+  Status = PushBool (TRUE);

 }

 

 if (EFI_ERROR (Status)) {

@@ -356,18 +345,6 @@ MmIsSchedulable (
 DEBUG ((DEBUG_DISPATCH, "  RESULT = %a\n", Operator ? "TRUE" : 
"FALSE"));

 return Operator;

 

-  case EFI_DEP_REPLACE_TRUE:

-CopyMem (, Iterator + 1, sizeof (EFI_GUID));

-DEBUG ((DEBUG_DISPATCH, "  PUSH GUID(%g) = TRUE\n", ));

-Status = PushBool (TRUE);

-if (EFI_ERROR (Status)) {

-  DEBUG ((DEBUG_DISPATCH, "  RESULT = FALSE (Unexpected error)\n"));

-  return FALSE;

-}

-

-Iterator += sizeof (EFI_GUID);

-break;

-

   default:

 DEBUG ((DEBUG_DISPATCH, "  RESULT = FALSE (Unknown opcode)\n"));

 goto Done;

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114025): https://edk2.groups.io/g/devel/message/114025
Mute This Topic: https://groups.io/mt/103824815/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Nhi Pham via groups.io]

On 1/18/2024 9:49 PM, Laszlo Ersek wrote:

but I'd prefer to just remove this
optimization from standalone MM, given that not only a) it shouldn't
have to deal with a large number of protocol GUIDs, but also b) the
driver dispatch is much more straight-forward. (Typically, StMM
drivers can be dispatched in the order they appear in the firmware
volume, in which case each DEPEX is evaluated only once anyway)


Sounds like a promising basis for removing the optimization indeed!



Your patch suggested earlier works for me. And I don't see significant
performance reduction compared with keeping optimization.

I don't have strong reason on removing the optimization, but I think it
would be simply good for now. Could you post your patch to edk2-devel
for review and merge?


That wouldn't be correct; I don't have any platform for testing StMM. I
proposed the patch purely based on code analysis. I prefer not to post
untested patches, if I can avoid it.


I got it, thanks!

I thought I could give Tested-by tag when you post the patch since I 
already verified the patch on a StMM platform




You can however post my patch; simply add your S-o-b at the bottom. You
can also preserve my authorship on the patch with --author=... on
git-commit; but even that is unnecessary for such a simple patch (you
don't even have to pick the patch up from the email, it's trivial to
reimplement from scratch, just reading the email).


I'm going to send the patch to edk2-devel and keep your authorship on 
the patch because there is no change compared with your suggestion in 
the email.


Thanks,
Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114024): https://edk2.groups.io/g/devel/message/114024
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Nhi Pham via groups.io]

Hi Laszlo,

On 1/16/2024 2:00 AM, Laszlo Ersek wrote:

On 1/15/24 15:04, Ard Biesheuvel wrote:

On Mon, 15 Jan 2024 at 14:07, Nhi Pham  wrote:


On 1/12/2024 4:45 PM, Laszlo Ersek wrote:

(Independently: I think that's a valid thing to do for *SMM* drivers,
because the entry point functions of those drivers are permitted to use
both SMM and DXE/UEFI protocols. But whether the same is valid for the
*standalone* MM drivers -- that looks questionable. Standalone MM
drivers should not depend on UEFI/DXE protocols ever, IIUC.)


3) The issue is patching the grammar in place, why can’t we just make a
copy for the dispatcher grammer, and operate on the copy. Maybe via a
copy on 1st update strategy?


Yes, copying the depex to the heap, and patching it there, was Nhi's #1
fix proposal. I think that could be made work. But I'm not sure if the
perf savings are worth the additional complexity. The heap allocation
(where the writeable depex would exist) would have to be permanently
associated with the loaded PE image -- because the dispatcher might need
to reevaluate the depex across multiple rounds of dispatching. So that's
a new field in some image-related structure, it also needs to be freed
upon unload (?), what if the memory allocation fails during depex eval
(just consider the depex to eval to FALSE?), etc. Doable, but hairy; not
sure if the perf is worth that effort.



Thanks so much, Laszlo for your valuable insights.

The approach #1 works for me. I will do further check for your concerns
above.

I'm trying your suggested patch and investigating the performance being
discussed here.



Not sure what approach #1 means,


(copying the depex to the heap, and maintaining it there, so that it can
be patched)


Thanks!




but I'd prefer to just remove this
optimization from standalone MM, given that not only a) it shouldn't
have to deal with a large number of protocol GUIDs, but also b) the
driver dispatch is much more straight-forward. (Typically, StMM
drivers can be dispatched in the order they appear in the firmware
volume, in which case each DEPEX is evaluated only once anyway)


Sounds like a promising basis for removing the optimization indeed!



Your patch suggested earlier works for me. And I don't see significant 
performance reduction compared with keeping optimization.


I don't have strong reason on removing the optimization, but I think it 
would be simply good for now. Could you post your patch to edk2-devel 
for review and merge?


Thanks,
Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113986): https://edk2.groups.io/g/devel/message/113986
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Nhi Pham via groups.io]

On 1/12/2024 4:45 PM, Laszlo Ersek wrote:
> (Independently: I think that's a valid thing to do for *SMM* drivers,
> because the entry point functions of those drivers are permitted to use
> both SMM and DXE/UEFI protocols. But whether the same is valid for the
> *standalone* MM drivers -- that looks questionable. Standalone MM
> drivers should not depend on UEFI/DXE protocols ever, IIUC.)
> 
>> 3) The issue is patching the grammar in place, why can’t we just make a
>> copy for the dispatcher grammer, and operate on the copy. Maybe via a
>> copy on 1st update strategy? 
> 
> Yes, copying the depex to the heap, and patching it there, was Nhi's #1
> fix proposal. I think that could be made work. But I'm not sure if the
> perf savings are worth the additional complexity. The heap allocation
> (where the writeable depex would exist) would have to be permanently
> associated with the loaded PE image -- because the dispatcher might need
> to reevaluate the depex across multiple rounds of dispatching. So that's
> a new field in some image-related structure, it also needs to be freed
> upon unload (?), what if the memory allocation fails during depex eval
> (just consider the depex to eval to FALSE?), etc. Doable, but hairy; not
> sure if the perf is worth that effort.
> 

Thanks so much, Laszlo for your valuable insights.

The approach #1 works for me. I will do further check for your concerns
above.

I'm trying your suggested patch and investigating the performance being
discussed here.

Regards,
Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113821): https://edk2.groups.io/g/devel/message/113821
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Memory Attribute for depex section

[Nhi Pham via groups.io]

++ disc...@edk2.groups.io

On 1/8/2024 5:11 PM, Nhi Pham wrote:
> Hi Ard, all,
> 
> Could you please help explain how the depex section in an image is
> mapped in terms of memory attribute?
> 
> As my observation, dispatcher locates[1] the depex section inside the
> module image and write[2] an evaluated data to the depex if necessary
> for scheduled boot order. The problem that the depex section is now in
> RO+X memory due to a part of the module image, so a writing to depex
> would cause data abort. I'm unsure whether this issue is generic in EDK2
> or not.
> 
> I think of two approaches:
> 
> #1 Relocate the depex section to heap memory for dependency evaluation?
> 
> #2 EDK2 build tool to support granting write permission for depex section.
> 
> [1] StandaloneMmPkg/Core/FwVol.c:236
> [2] StandaloneMmPkg/Core/Dependency.c:256
> 
> Thanks,
> Nhi



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113497): https://edk2.groups.io/g/devel/message/113497
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Memory Attribute for depex section

[Nhi Pham via groups.io]

Hi Ard, all,

Could you please help explain how the depex section in an image is 
mapped in terms of memory attribute?


As my observation, dispatcher locates[1] the depex section inside the 
module image and write[2] an evaluated data to the depex if necessary 
for scheduled boot order. The problem that the depex section is now in 
RO+X memory due to a part of the module image, so a writing to depex 
would cause data abort. I'm unsure whether this issue is generic in EDK2 
or not.


I think of two approaches:

#1 Relocate the depex section to heap memory for dependency evaluation?

#2 EDK2 build tool to support granting write permission for depex section.

[1] StandaloneMmPkg/Core/FwVol.c:236
[2] StandaloneMmPkg/Core/Dependency.c:256

Thanks,
Nhi


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113373): https://edk2.groups.io/g/devel/message/113373
Mute This Topic: https://groups.io/mt/103594587/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 16/17] Silicon/Ampere/AmpereAltraPkg: Add ImagePropertiesRecordLib Instance

[Nhi Pham via groups.io]

Thanks for update.

Reviewed-by: Nhi Pham 

On 12/1/2023 7:34 AM, Taylor Beebe wrote:

ImagePropertiesRecordLib is used by DxeMain and PiSmmCore, so it
needs to be added to most platforms.

Signed-off-by: Taylor Beebe 
Cc: Nhi Pham 
Cc: Chuong Tran 
Cc: Leif Lindholm 
Cc: Rebecca Cran 
---
  Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc 
b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
index 8cb2a3fe6422..eb6caf37a3c5 100644
--- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
+++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
@@ -46,6 +46,7 @@
HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf

UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
  
#

# Allow dynamic PCDs



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111963): https://edk2.groups.io/g/devel/message/111963
Mute This Topic: https://groups.io/mt/102906521/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue

[Nhi Pham via groups.io]

On 9/7/2023 10:38 PM, Nhi Pham wrote:
> On 9/6/2023 11:22 PM, Oliver Smith-Denny wrote:
>> On 9/6/2023 1:50 AM, Ard Biesheuvel wrote:
>>> On Wed, 6 Sept 2023 at 09:56, Nhi Pham
>>>  wrote:

 On 9/6/2023 1:33 PM, Ni, Ray wrote:
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender.
> Please be mindful of safe email handling and proprietary information
> protection practices.]
>
> I am a bit confused.
>
> The HOB list in standalone MM is read-only. Why could any module call
> BuildGuidHob() to modify the HOB.
>
> I saw Oliver mentioned something about StMM. I don't know what that
> is.
> But it seems that's ARM specific. Then, I don't think it's proper to
> modify code here for a specific arch ARM.

 The HOB creation is available in the
 StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf. If
 other architectures also use that instance, I think the issue is not
 specific to ARM.

>>>
>>> The question here is whether the implementation follows the PI spec,
>>> and whether HOB creation should be supported to begin with.
>>>
>>
>> My reading of the PI spec is that this implementation does not follow
>> it. However, the PI spec is not very explicit about Standalone MM in
>> general, but particularly in relation to HOBs.
>>
>> However, in the generic HOB section of PI spec v1.7, Vol. 3, section 4
>> (entitled HOB Design Discussion) it explicitly lays out that there are
>> HOB producer phases and HOB consumer phases. It uses PEI as a HOB
>> producer phase and DXE as a HOB consumer phase and explicitly says
>> that the HOB consumer phase must treat HOBs as read-only memory, per
>> Ray's comment.
>>
>> In vol. 4, section 2.2, in discussing the Standalone MM entry point,
>> the document talks about the HOB list being passed to Standalone MM
>> to consume, which per the reading of the above section would classify
>> Standalone MM as a HOB consumer phase, where HOBs should then be
>> read-only.
>>
>> So, I believe that we should not support HOB creation in Standalone MM
>> and instead rely on other mechanisms to pass information within the
>> phase. Per Nhi's other email in this thread, we should have the
>> discussion on how to solve that specific problem and that may well
>> lead to a discussion on whether HOBs are in fact the right mechanism
>> here, but I tend to lean towards leaving something as architectural as
>> HOBs to what the PI spec defines and using different mechanisms to
>> accomplish in-phase communication.
> Thanks Oliver so much for that. I agree. We should focus on my specific
> problem with UEFI Variable Flash Info in StandaloneMM in another thread.
>>
>> Does this reading of the spec align with others' expectations? As I
>> mentioned to Ray in another thread, Standalone MM feels like it could
>> have extra clarification in a few areas in the PI spec.
> 
> Thanks again. The HOB library should be updated to remove the HOB
> creation once we have the clarification.

I found that we can hook a platform NULL library class to the
StandaloneMmCore to create UEFI Variable Flash Info HOB. This way is
compliant to the spec as the HOB is created in MM_CORE_STANDALONE phase.

Should I write a patch to remove the HOB creation in StandaloneMmHobLib?

Regards,
Nhi



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111903): https://edk2.groups.io/g/devel/message/111903
Mute This Topic: https://groups.io/mt/89020085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Proposed Fix][PATCH v1 1/1] MdeModulePkg/DxeCapsuleLibFmp: Fix crash with VirtualAddressMap omitted

[Nhi Pham via groups.io]

On 11/23/2023 3:36 PM, Ard Biesheuvel wrote:

On Thu, 23 Nov 2023 at 05:49, Nhi Pham  wrote:


If the SetVirtualAddressMap() is not called, mIsVirtualAddrConverted
is FALSE and the kernel crash occurs in IsNestedFmpCapsule() when
executing gBS->LocateProtocol () in the else case.

To serve the omitted SetVirtualAddressMap() call, we could just check
mEsrtTable presence instead of relying on mIsVirtualAddrConverted.

Signed-off-by: Nhi Pham 


Agreed: SetVirtualAddressMap() is optional, so whether it has been
called or not should not be used as a proxy to decide whether or not
we are still running in the boot services context.

Reviewed-by: Ard Biesheuvel 


Thanks Ard for quick review. I created the PR with your Rb-tag at
https://github.com/tianocore/edk2/pull/5071

Regards,
Nhi




---
  MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 17 
+++--
  MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleRuntime.c |  2 --
  2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c 
b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
index 197af267aff3..2433c76a8c6f 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
@@ -41,8 +41,7 @@
  #include 
  #include 

-EFI_SYSTEM_RESOURCE_TABLE  *mEsrtTable = NULL;
-BOOLEANmIsVirtualAddrConverted = FALSE;
+EFI_SYSTEM_RESOURCE_TABLE  *mEsrtTable = NULL;

  BOOLEANmDxeCapsuleLibEndOfDxe  = FALSE;
  EFI_EVENT  mDxeCapsuleLibEndOfDxeEvent = NULL;
@@ -1394,14 +1393,12 @@ IsNestedFmpCapsule (
EFI_SYSTEM_RESOURCE_ENTRY  Entry;

EsrtGuidFound = FALSE;
-  if (mIsVirtualAddrConverted) {
-if (mEsrtTable != NULL) {
-  EsrtEntry = (EFI_SYSTEM_RESOURCE_ENTRY *)(mEsrtTable + 1);
-  for (Index = 0; Index < mEsrtTable->FwResourceCount; Index++, 
EsrtEntry++) {
-if (CompareGuid (>FwClass, >CapsuleGuid)) {
-  EsrtGuidFound = TRUE;
-  break;
-}
+  if (mEsrtTable != NULL) {
+EsrtEntry = (EFI_SYSTEM_RESOURCE_ENTRY *)(mEsrtTable + 1);
+for (Index = 0; Index < mEsrtTable->FwResourceCount; Index++, EsrtEntry++) 
{
+  if (CompareGuid (>FwClass, >CapsuleGuid)) {
+EsrtGuidFound = TRUE;
+break;
}
  }
} else {
diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleRuntime.c 
b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleRuntime.c
index 9ceb44fe4d79..44f30c16c284 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleRuntime.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleRuntime.c
@@ -21,7 +21,6 @@
  #include 

  extern EFI_SYSTEM_RESOURCE_TABLE  *mEsrtTable;
-extern BOOLEANmIsVirtualAddrConverted;
  EFI_EVENT 
mDxeRuntimeCapsuleLibVirtualAddressChangeEvent = NULL;
  EFI_EVENT mDxeRuntimeCapsuleLibReadyToBootEvent   
   = NULL;

@@ -40,7 +39,6 @@ DxeCapsuleLibVirtualAddressChangeEvent (
)
  {
gRT->ConvertPointer (EFI_OPTIONAL_PTR, (VOID **));
-  mIsVirtualAddrConverted = TRUE;
  }

  /**
--
2.25.1




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111668): https://edk2.groups.io/g/devel/message/111668
Mute This Topic: https://groups.io/mt/102762290/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Proposed Fix][PATCH v1 1/1] MdeModulePkg/DxeCapsuleLibFmp: Fix crash with VirtualAddressMap omitted

[Nhi Pham via groups.io]

If the SetVirtualAddressMap() is not called, mIsVirtualAddrConverted
is FALSE and the kernel crash occurs in IsNestedFmpCapsule() when
executing gBS->LocateProtocol () in the else case.

To serve the omitted SetVirtualAddressMap() call, we could just check
mEsrtTable presence instead of relying on mIsVirtualAddrConverted.

Signed-off-by: Nhi Pham 
---
 MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 17 
+++--
 MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleRuntime.c |  2 --
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c 
b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
index 197af267aff3..2433c76a8c6f 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
@@ -41,8 +41,7 @@
 #include 

 #include 

 

-EFI_SYSTEM_RESOURCE_TABLE  *mEsrtTable = NULL;

-BOOLEANmIsVirtualAddrConverted = FALSE;

+EFI_SYSTEM_RESOURCE_TABLE  *mEsrtTable = NULL;

 

 BOOLEANmDxeCapsuleLibEndOfDxe  = FALSE;

 EFI_EVENT  mDxeCapsuleLibEndOfDxeEvent = NULL;

@@ -1394,14 +1393,12 @@ IsNestedFmpCapsule (
   EFI_SYSTEM_RESOURCE_ENTRY  Entry;

 

   EsrtGuidFound = FALSE;

-  if (mIsVirtualAddrConverted) {

-if (mEsrtTable != NULL) {

-  EsrtEntry = (EFI_SYSTEM_RESOURCE_ENTRY *)(mEsrtTable + 1);

-  for (Index = 0; Index < mEsrtTable->FwResourceCount; Index++, 
EsrtEntry++) {

-if (CompareGuid (>FwClass, >CapsuleGuid)) {

-  EsrtGuidFound = TRUE;

-  break;

-}

+  if (mEsrtTable != NULL) {

+EsrtEntry = (EFI_SYSTEM_RESOURCE_ENTRY *)(mEsrtTable + 1);

+for (Index = 0; Index < mEsrtTable->FwResourceCount; Index++, EsrtEntry++) 
{

+  if (CompareGuid (>FwClass, >CapsuleGuid)) {

+EsrtGuidFound = TRUE;

+break;

   }

 }

   } else {

diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleRuntime.c 
b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleRuntime.c
index 9ceb44fe4d79..44f30c16c284 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleRuntime.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleRuntime.c
@@ -21,7 +21,6 @@
 #include 

 

 extern EFI_SYSTEM_RESOURCE_TABLE  *mEsrtTable;

-extern BOOLEANmIsVirtualAddrConverted;

 EFI_EVENT 
mDxeRuntimeCapsuleLibVirtualAddressChangeEvent = NULL;

 EFI_EVENT mDxeRuntimeCapsuleLibReadyToBootEvent
  = NULL;

 

@@ -40,7 +39,6 @@ DxeCapsuleLibVirtualAddressChangeEvent (
   )

 {

   gRT->ConvertPointer (EFI_OPTIONAL_PTR, (VOID **));

-  mIsVirtualAddrConverted = TRUE;

 }

 

 /**

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111647): https://edk2.groups.io/g/devel/message/111647
Mute This Topic: https://groups.io/mt/102762290/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdeModulePkg/RegularExpressinoDxe: Fix clang error

[Nhi Pham via groups.io]

Hi Liming,

Could you please help review and get this patch merged within the next
edk2-stable tag?

Thanks,
Nhi

On 10/23/2023 11:27 AM, Nhi Pham via groups.io wrote:
> This looks good to me. I also build-tested this patch.
> 
> Reviewed-by: Nhi Pham 
> Tested-by: Nhi Pham 
> 
> On 10/3/2023 10:04 PM, Jake Garver via groups.io wrote:
>> Ignore old style declaration warnings in oniguruma/src/st.c.  This was
>> already ignored for MSFT, but newer versions of clang complain as well.
>>
>> Signed-off-by: Jake Garver 
>> ---
>>   .../Universal/RegularExpressionDxe/RegularExpressionDxe.inf  | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git
>> a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>> b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>> index 84489c2942..0092531a67 100644
>> ---
>> a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>> +++
>> b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>> @@ -102,6 +102,7 @@
>>       # Oniguruma: old style declaration in st.c
>>     MSFT:*_*_*_CC_FLAGS = /wd4131
>> +  GCC:*_*_*_CC_FLAGS = -Wno-deprecated-non-prototype
>>       # Oniguruma: 'type cast' : truncation from 'OnigUChar *' to
>> 'unsigned int'
>>     MSFT:*_*_*_CC_FLAGS = /wd4305 /wd4306
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110677): https://edk2.groups.io/g/devel/message/110677
Mute This Topic: https://groups.io/mt/101735690/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdeModulePkg/RegularExpressinoDxe: Fix clang error

[Nhi Pham via groups.io]

This looks good to me. I also build-tested this patch.

Reviewed-by: Nhi Pham 
Tested-by: Nhi Pham 

On 10/3/2023 10:04 PM, Jake Garver via groups.io wrote:

Ignore old style declaration warnings in oniguruma/src/st.c.  This was
already ignored for MSFT, but newer versions of clang complain as well.

Signed-off-by: Jake Garver 
---
  .../Universal/RegularExpressionDxe/RegularExpressionDxe.inf  | 1 +
  1 file changed, 1 insertion(+)

diff --git 
a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf 
b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
index 84489c2942..0092531a67 100644
--- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
+++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
@@ -102,6 +102,7 @@
  
# Oniguruma: old style declaration in st.c

MSFT:*_*_*_CC_FLAGS = /wd4131
+  GCC:*_*_*_CC_FLAGS = -Wno-deprecated-non-prototype
  
# Oniguruma: 'type cast' : truncation from 'OnigUChar *' to 'unsigned int'

MSFT:*_*_*_CC_FLAGS = /wd4305 /wd4306



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109886): https://edk2.groups.io/g/devel/message/109886
Mute This Topic: https://groups.io/mt/101735690/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] RFC: SetVariable callbacks

[Nhi Pham via groups.io]

Hi Girish,

I missed your reply. Sorry if I chime in very late, and you started to 
develop toward option 1. There are some cases that we can leverage your 
work here.


Please see inline...

On 9/21/2023 10:58 PM, Girish Mahadevan wrote:

Hello Nhi,

On 9/21/2023 1:41 AM, Nhi Pham via groups.io wrote:

External email: Use caution opening links or attachments


Can we write a DXE_RUNTIME driver to override the pointers of UEFI
Runtime Get/SetVariable() services? Then, we can add platform specific
or custom implementation before/after calling the original
Get/SetVariable()?



Thanks for the suggestion. This doesn't work for us, we need the 
notifications in StMM, also we'd prefer to get these callbacks from
VariableServiceSetVariable() itself after the basic checks for the set 
var are done (similar to how VarCheckLib is called)


That makes sense. Thanks!



Best Regards
Girish


Regards,
Nhi

On 9/21/2023 3:27 AM, Girish Mahadevan via groups.io wrote:

Hello

We have a requirement to monitor setVariable calls, we'd like to get a
callback before and after the variable update.

Similar to VarCheckLib, except that VarCheckLib's set callbacks are
called after endOfDxe.

We were thinking of doing something like:

===

--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -2853,6 +2853,11 @@ VariableServiceSetVariable (
  return Status;
    }

+  Status = VarPreSetVariableCallback (VariableName, VendorGuid,
Attributes, PayloadSize, (VOID *)((UINTN)Data + DataSize - PayloadSize),
mRequestSource);^M
+  if (EFI_ERROR (Status)) {^M
+    return Status;^M
+  }^M
+^M
    AcquireLockOnlyAtBootTime
(>VariableGlobal.VariableServicesLock);

    //
@@ -2917,6 +2922,8 @@ Done:
    InterlockedDecrement
(>VariableGlobal.ReentrantState);
    ReleaseLockOnlyAtBootTime
(>VariableGlobal.VariableServicesLock);

+  Status = VarPostSetVariableCallback (VariableName, VendorGuid,
Attributes, PayloadSize, (VOID *)((UINTN)Data + DataSize - PayloadSize),
mRequestSource);^M
+^M

==


We were thinking of 4 options:
1. A new Library, platforms can include the Null implementation if they
don't need this.
2. A new protocol that is called from the Variable driver (similar to
the Fvb protocol, we let the Smm/Dxe Variable drivers get this protocol)


This option seems to be able to accommodate more scenarios. For example, 
a platform wants to hook their platform specific implementation based on 
the RT Get/Set Variable services. The feature can reuse the UEFI RT 
service as an interface for Operating System to communicate with UEFI or 
StandaloneMM.


Regards,
Nhi


3. Expand the existing VarCheckLib to include these new callbacks.
(which can be called before end of dxe)
4. Something we don't know about (please let us know)

We are leaning toward option 1. Let us know your thoughts.

Best Regards
Girish














-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109822): https://edk2.groups.io/g/devel/message/109822
Mute This Topic: https://groups.io/mt/101487036/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v4 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Nhi Pham via groups.io]

Acked-by: Nhi Pham 

Nit: I think you want to run uncrustify for Patch 3 as well :)

Regards,
Nhi

On 10/18/2023 5:07 PM, Marcin Juszkiewicz wrote:

We need platform version to be at least 0.3 to have XHCI
in virtual hardware. On older platforms there is non-working
EHCI which we ignore.

Set DSDT node to be disabled so operating system will not try
to initialize not-existing hardware.

Signed-off-by: Marcin Juszkiewicz 
---
  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 66 +++-
  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
  3 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 7c7e08e0fd3a..d5ded892d6ea 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -29,6 +29,7 @@ [Packages]
Silicon/Qemu/SbsaQemu/SbsaQemu.dec
  
  [LibraryClasses]

+  AcpiLib
ArmLib
BaseMemoryLib
BaseLib
@@ -50,6 +51,8 @@ [Pcd]
gArmTokenSpaceGuid.PcdGicRedistributorsBase
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdGicItsBase
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSmmuBase
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMajor
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMinor
  
  [Depex]

gEfiAcpiTableProtocolGuid   ## CONSUMES
@@ -59,6 +62,7 @@ [Guids]
  
  [Protocols]

gEfiAcpiTableProtocolGuid   ## CONSUMES
+  gEfiAcpiSdtProtocolGuid
  
  [FixedPcd]

gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index fd849ca1594b..4d8a57d5a8e4 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -10,6 +10,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -682,6 +683,69 @@ AddGtdtTable (
return Status;
  }
  
+EFI_STATUS

+DisableXhciOnOlderPlatVer (
+  VOID
+  )
+{
+  EFI_STATUSStatus;
+  EFI_ACPI_SDT_PROTOCOL   *AcpiSdtProtocol;
+  EFI_ACPI_DESCRIPTION_HEADER *Table;
+  UINTN   TableKey;
+  UINTN   TableIndex;
+  EFI_ACPI_HANDLE TableHandle;
+
+  Status = EFI_SUCCESS;
+
+  if ( PLATFORM_VERSION_LESS_THAN(0, 3) ) {
+DEBUG ((DEBUG_ERROR, "Platform Version < 0.3 - disabling XHCI\n"));
+Status = gBS->LocateProtocol (
+,
+NULL,
+(VOID **)
+);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Unable to locate ACPI table protocol\n"));
+  return Status;
+}
+
+TableIndex = 0;
+Status = AcpiLocateTableBySignature (
+   AcpiSdtProtocol,
+   EFI_ACPI_6_3_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
+   ,
+   ,
+   
+   );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "ACPI DSDT table not found!\n"));
+  ASSERT_EFI_ERROR (Status);
+  return Status;
+}
+
+Status = AcpiSdtProtocol->OpenSdt (TableKey, );
+if (EFI_ERROR (Status)) {
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+Status = AcpiAmlObjectUpdateInteger (AcpiSdtProtocol, TableHandle, 
"\\_SB.USB0.XHCI", 0x0);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Failed to disable XHCI!\n"));
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+AcpiSdtProtocol->Close (TableHandle);
+AcpiUpdateChecksum ((UINT8 *)Table, Table->Length);
+  }
+
+  return Status;
+}
+
+
  EFI_STATUS
  EFIAPI
  InitializeSbsaQemuAcpiDxe (
@@ -738,5 +802,5 @@ InitializeSbsaQemuAcpiDxe (
  DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
}
  
-  return EFI_SUCCESS;

+  return DisableXhciOnOlderPlatVer ();
  }
diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
index 543b5782580a..ba3eefc975a5 100644
--- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
+++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
@@ -73,8 +73,9 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
  Name (_HID, "PNP0D10")  // _HID: Hardware ID
  Name (_UID, 0x00)// _UID: Unique ID
  Name (_CCA, 0x01)// _CCA: Cache Coherency Attribute
+Name (XHCI, 0xF)// will be set using AcpiLib
  Method (_STA) {
-  Return (0xF)
+  Return (XHCI)
  }
  Method (_CRS, 

Re: [edk2-devel] [PATCH edk2-platforms v3 4/4] SbsaQemu: disable XHCI in DSDT if not present

[Nhi Pham via groups.io]

Hi Marcin,

There is a nitpicking below.

Other than, it looks good to me.

Acked-by: Nhi Pham 

Regards,
Nhi

On 10/17/2023 8:23 PM, Marcin Juszkiewicz wrote:

We need platform version to be at least 0.3 to have XHCI
in virtual hardware. On older platforms there is non-working
EHCI which we ignore.

Set DSDT node to be disabled so operating system will not try
to initialize not-existing hardware.

Signed-off-by: Marcin Juszkiewicz 
---
  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 60 
  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
  3 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 7c7e08e0fd3a..d5ded892d6ea 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -29,6 +29,7 @@ [Packages]
Silicon/Qemu/SbsaQemu/SbsaQemu.dec
  
  [LibraryClasses]

+  AcpiLib
ArmLib
BaseMemoryLib
BaseLib
@@ -50,6 +51,8 @@ [Pcd]
gArmTokenSpaceGuid.PcdGicRedistributorsBase
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdGicItsBase
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSmmuBase
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMajor
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformVersionMinor
  
  [Depex]

gEfiAcpiTableProtocolGuid   ## CONSUMES
@@ -59,6 +62,7 @@ [Guids]
  
  [Protocols]

gEfiAcpiTableProtocolGuid   ## CONSUMES
+  gEfiAcpiSdtProtocolGuid
  
  [FixedPcd]

gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index fd849ca1594b..cf6e534ca3a0 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -10,6 +10,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -682,6 +683,63 @@ AddGtdtTable (
return Status;
  }
  
+EFI_STATUS

+DisableXhciOnOlderPlatVer (
+  VOID
+  )
+{
+  EFI_STATUSStatus;
+  EFI_ACPI_SDT_PROTOCOL   *AcpiSdtProtocol;
+  EFI_ACPI_DESCRIPTION_HEADER *Table;
+  UINTN   TableKey;
+  UINTN   TableIndex;
+  EFI_ACPI_HANDLE TableHandle;
+
+  Status = EFI_SUCCESS;
+
+  if ( PLATFORM_VERSION_LESS_THAN(0, 3) ) {
+DEBUG ((DEBUG_ERROR, "Platform Version < 0.3 - disabling XHCI\n"));
+Status = gBS->LocateProtocol (
+,
+NULL,
+(VOID **)
+);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Unable to locate ACPI table protocol\n"));
+  return Status;
+}
+
+TableIndex = 0;
+Status = AcpiLocateTableBySignature (
+   AcpiSdtProtocol,
+   EFI_ACPI_6_3_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
+   ,
+   ,
+   
+   );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "ACPI DSDT table not found!\n"));
+  ASSERT_EFI_ERROR (Status);
+  return Status;
+}
+
+Status = AcpiSdtProtocol->OpenSdt (TableKey, );
+if (EFI_ERROR (Status)) {
+  ASSERT_EFI_ERROR (Status);
+  AcpiSdtProtocol->Close (TableHandle);
+  return Status;
+}
+
+AcpiAmlObjectUpdateInteger (AcpiSdtProtocol, TableHandle, 
"\\_SB.USB0.XHCI", 0x0);
+
+AcpiSdtProtocol->Close (TableHandle);
+AcpiUpdateChecksum ((UINT8 *)Table, Table->Length);
+  }
+
+  return Status;
+}
+
+
  EFI_STATUS
  EFIAPI
  InitializeSbsaQemuAcpiDxe (
@@ -738,5 +796,7 @@ InitializeSbsaQemuAcpiDxe (
  DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
}
  
+  Status = DisableXhciOnOlderPlatVer();


Nit: EDK2 Coding Style says that you need a space before (. Is it 
necessary to handle the result of Status?



+
return EFI_SUCCESS;
  }
diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
index 543b5782580a..ba3eefc975a5 100644
--- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
+++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
@@ -73,8 +73,9 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
  Name (_HID, "PNP0D10")  // _HID: Hardware ID
  Name (_UID, 0x00)// _UID: Unique ID
  Name (_CCA, 0x01)// _CCA: Cache Coherency Attribute
+Name (XHCI, 0xF)// will be set using AcpiLib
  Method (_STA) {
-  Return (0xF)
+  Return (XHCI)
  }
  Method (_CRS, 0x0, Serialized) {
  Name (RBUF, ResourceTemplate() {

Re: [edk2-devel] [PATCH edk2-platforms v2 0/4] Provide XHCI USB controller only for newer hardware

[Nhi Pham via groups.io]

Hi Marcin,

On 10/16/2023 5:06 PM, Marcin Juszkiewicz wrote:

Platform version 0.3 introduced XHCI USB controller instead of EHCI one.
But we did it in a way that there is no in-EDK2 check for platform
version (XHCI is always given).

This behaviour works with Linux as it complains about being unable to
initialize EHCI and goes on. Free/Net/Open BSD systems hang in such
situation.

Now we check are we on Platform Version 0.3 at least and then initialize
XHCI controller. Otherwise we disable it's node in DSDT table.

I checked several ways to handle the situation.

SSDT overlay enabling with LocateAndInstallAcpiFromFvConfitional() was
first one but this function had only DBG2 and FACP tables.

Then looked at trying to detect XHCI from _STA method. But this is
sysbus device which is there or not without way to discover it.

Next attempt was to have variable in DSDT and to use it in _STA. Too
much trouble.

Then looked again at code from
Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiDsdt.c and noticed
UpdateStatusMethodObject() function. Copied some code and it worked.


Could you please check whether we can replace the 
UpdateStatusMethodObject() function with the 
AcpiAmlObjectUpdateInteger() function provided by AcpiLib?


Regards,
Nhi


Booting OpenBSD reminded me to update table checksum.

---
Changes in v2:
- XHCI initialized only on PlatVer 0.3+
- XHCI disabled in DSDT for older platforms
- no SSDT overlays for EHCI/XHCI
- no EHCI at all (it does not work anyway)
- no Pcd renaming

---
Marcin Juszkiewicz (4):
   SbsaQemu: introduce macro to compare platform version
   SbsaQemu: add AcpiLib
   SbsaQemu: initialize XHCI only if it exists
   SbsaQemu: disable XHCI in DSDT if not present

  Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  2 +
  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 +
  .../IndustryStandard/SbsaQemuPlatformVersion.h   | 25 ++
  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 93 
  .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c| 47 +-
  5 files changed, 149 insertions(+), 22 deletions(-)
---
base-commit: 06f6274d56422084281886fad447ab117fd0e487
change-id: 20231013-ehci-xhci-fix-c529356a7a8f

Best regards,



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109675): https://edk2.groups.io/g/devel/message/109675
Mute This Topic: https://groups.io/mt/101992601/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH 1/1] AmpereAltraPkg/Ac01PcieLib: drop useless link status register read

[Nhi Pham via groups.io]

Thanks, Laszlo for this patch.

Reviewed-by: Nhi Pham 

Regards,
Nhi

On 10/17/2023 5:05 PM, Laszlo Ersek via groups.io wrote:

Nhi says that reading LINK_CONTROL_LINK_STATUS_REG is redundant; its only
use was debugging (before commit 380b4b40c60d). Thus, we can go farther
than commit 2e27c62ef000, and remove the MmioRead32() call altogether.

Build-tested with "Jade.dsc".

Cc: Chuong Tran 
Cc: Leif Lindholm 
Cc: Nhi Pham 
Cc: Rebecca Cran 
Suggested-by: Nhi Pham 
Signed-off-by: Laszlo Ersek 
---
  Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c 
b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
index fa00c1e36999..dea2e6406dfd 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
@@ -1744,7 +1744,6 @@ Ac01PcieCoreUpdateLink (
)
  {
AC01_PCIE_CONTROLLER  *Pcie;
-  PHYSICAL_ADDRESS  CfgBase;
UINT8 PcieIndex;
UINT32Index;
  
@@ -1761,12 +1760,10 @@ Ac01PcieCoreUpdateLink (

// Loop for all controllers
for (PcieIndex = 0; PcieIndex < RootComplex->MaxPcieController; 
PcieIndex++) {
  Pcie = >Pcie[PcieIndex];
-CfgBase = RootComplex->MmcfgBase + (RootComplex->Pcie[PcieIndex].DevNum << 
DEV_SHIFT);
  
  if (Pcie->Active && !Pcie->LinkUp) {

if (PcieLinkUpCheck (Pcie)) {
  Pcie->LinkUp = TRUE;
-(VOID)MmioRead32 (CfgBase + PCIE_CAPABILITY_BASE + 
LINK_CONTROL_LINK_STATUS_REG);
  
  // Doing link checking and recovery if needed

  Ac01PcieCoreQoSLinkCheckRecovery (RootComplex, PcieIndex);








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109673): https://edk2.groups.io/g/devel/message/109673
Mute This Topic: https://groups.io/mt/102014532/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH 12/19] AmpereAltraPkg/Ac01PcieLib: fix compilation error

[Nhi Pham via groups.io]

HI Lazslo,

I was not reviewing carefully. The MmioRead32 is redundant code. Can you 
help me get rid of that code?


Thanks,
Nhi

On 10/13/2023 9:20 AM, Nhi Pham wrote:

Thanks for fixing it.

Reviewed-by: Nhi Pham 

Regards,
Nhi

On 10/12/2023 4:09 PM, Laszlo Ersek wrote:
Commit 380b4b40c60d ("AmpereAltraPkg: Update Ampere specific platform 
PCIe

core", 2023-03-29) removed the DEBUG macro call from
Ac01PcieCoreUpdateLink() that was the only reader of "Val". Since then,
Val has only been set, but never read. This triggers
"-Werror=unused-but-set-variable".

Found when trying to build "Jade.dsc".

Keep the MmioRead32() call, so that the PCIe config space sees the same
behavior as before, but explicitly throw away the result.

Cc: Chuong Tran 
Cc: Leif Lindholm 
Cc: Nhi Pham 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564
Signed-off-by: Laszlo Ersek 
---
  Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git 
a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c 
b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c

index 3c1fe5e35ca2..fa00c1e36999 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
@@ -1747,7 +1747,6 @@ Ac01PcieCoreUpdateLink (
    PHYSICAL_ADDRESS  CfgBase;
    UINT8 PcieIndex;
    UINT32    Index;
-  UINT32    Val;
    *IsNextRoundNeeded = FALSE;
    *FailedPcieCount   = 0;
@@ -1767,7 +1766,7 @@ Ac01PcieCoreUpdateLink (
  if (Pcie->Active && !Pcie->LinkUp) {
    if (PcieLinkUpCheck (Pcie)) {
  Pcie->LinkUp = TRUE;
-    Val = MmioRead32 (CfgBase + PCIE_CAPABILITY_BASE + 
LINK_CONTROL_LINK_STATUS_REG);
+    (VOID)MmioRead32 (CfgBase + PCIE_CAPABILITY_BASE + 
LINK_CONTROL_LINK_STATUS_REG);

  // Doing link checking and recovery if needed
  Ac01PcieCoreQoSLinkCheckRecovery (RootComplex, PcieIndex);




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109581): https://edk2.groups.io/g/devel/message/109581
Mute This Topic: https://groups.io/mt/101914660/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH 13/19] JadePkg/PCF85063RealTimeClockLib: hide LibRtcVirtualNotifyEvent

[Nhi Pham via groups.io]

It looks good to me.

Reviewed-by: Nhi Pham 

Thanks,
Nhi

On 10/12/2023 4:09 PM, Laszlo Ersek wrote:

The RealTimeClockLib class header in edk2 mistakenly declares a function
called LibRtcVirtualNotifyEvent(). No component ever calls this function
crossing module boundaries; all RealTimeClockLib instances in edk2 and
edk2-platforms are supposed to register (and do register) their
SetVirtualAddressMap() notification functions.

Rename LibRtcVirtualNotifyEvent() to VirtualNotifyEvent(), and make it
static, in preparation for removing the LibRtcVirtualNotifyEvent()
declaration from the lib class header later.

Build-tested only (with "Jade.dsc").

Cc: Chuong Tran 
Cc: Leif Lindholm 
Cc: Nhi Pham 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564
Signed-off-by: Laszlo Ersek 
---
  
Platform/Ampere/JadePkg/Library/PCF85063RealTimeClockLib/PCF85063RealTimeClockLib.c
 | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/Platform/Ampere/JadePkg/Library/PCF85063RealTimeClockLib/PCF85063RealTimeClockLib.c
 
b/Platform/Ampere/JadePkg/Library/PCF85063RealTimeClockLib/PCF85063RealTimeClockLib.c
index ef8c71e92c18..1df781364bbc 100644
--- 
a/Platform/Ampere/JadePkg/Library/PCF85063RealTimeClockLib/PCF85063RealTimeClockLib.c
+++ 
b/Platform/Ampere/JadePkg/Library/PCF85063RealTimeClockLib/PCF85063RealTimeClockLib.c
@@ -201,9 +201,10 @@ LibSetWakeupTime (
@param[in]Event   The Event that is being processed
@param[in]Context Event Context
  **/
+STATIC
  VOID
  EFIAPI
-LibRtcVirtualNotifyEvent (
+VirtualNotifyEvent (
IN EFI_EVENTEvent,
IN VOID *Context
)
@@ -246,7 +247,7 @@ LibRtcInitialize (
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
TPL_NOTIFY,
-  LibRtcVirtualNotifyEvent,
+  VirtualNotifyEvent,
NULL,
,





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109580): https://edk2.groups.io/g/devel/message/109580
Mute This Topic: https://groups.io/mt/101914668/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH 12/19] AmpereAltraPkg/Ac01PcieLib: fix compilation error

[Nhi Pham via groups.io]

Thanks for fixing it.

Reviewed-by: Nhi Pham 

Regards,
Nhi

On 10/12/2023 4:09 PM, Laszlo Ersek wrote:

Commit 380b4b40c60d ("AmpereAltraPkg: Update Ampere specific platform PCIe
core", 2023-03-29) removed the DEBUG macro call from
Ac01PcieCoreUpdateLink() that was the only reader of "Val". Since then,
Val has only been set, but never read. This triggers
"-Werror=unused-but-set-variable".

Found when trying to build "Jade.dsc".

Keep the MmioRead32() call, so that the PCIe config space sees the same
behavior as before, but explicitly throw away the result.

Cc: Chuong Tran 
Cc: Leif Lindholm 
Cc: Nhi Pham 
Cc: Rebecca Cran 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4564
Signed-off-by: Laszlo Ersek 
---
  Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c 
b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
index 3c1fe5e35ca2..fa00c1e36999 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
@@ -1747,7 +1747,6 @@ Ac01PcieCoreUpdateLink (
PHYSICAL_ADDRESS  CfgBase;
UINT8 PcieIndex;
UINT32Index;
-  UINT32Val;
  
*IsNextRoundNeeded = FALSE;

*FailedPcieCount   = 0;
@@ -1767,7 +1766,7 @@ Ac01PcieCoreUpdateLink (
  if (Pcie->Active && !Pcie->LinkUp) {
if (PcieLinkUpCheck (Pcie)) {
  Pcie->LinkUp = TRUE;
-Val = MmioRead32 (CfgBase + PCIE_CAPABILITY_BASE + 
LINK_CONTROL_LINK_STATUS_REG);
+(VOID)MmioRead32 (CfgBase + PCIE_CAPABILITY_BASE + 
LINK_CONTROL_LINK_STATUS_REG);
  
  // Doing link checking and recovery if needed

  Ac01PcieCoreQoSLinkCheckRecovery (RootComplex, PcieIndex);




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109579): https://edk2.groups.io/g/devel/message/109579
Mute This Topic: https://groups.io/mt/101914660/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] RedfishPkg: Use base version SortLib for the specific modules

[Nhi Pham via groups.io]

Thanks for writing this patch.

Reviewed-by: Nhi Pham 
Tested-by: Nhi Pham 

Regards,
Nhi

On 10/11/2023 10:49 AM, Nickle Wang wrote:


Reviewed-by: Nickle Wang 

Regards,
Nickle


-Original Message-
From: abner.ch...@amd.com 
Sent: Wednesday, October 11, 2023 11:41 AM
To: devel@edk2.groups.io
Cc: Nickle Wang ; Igor Kulchytskyy ; Nhi
Pham 
Subject: [PATCH] RedfishPkg: Use base version SortLib for the specific modules

External email: Use caution opening links or attachments


From: Abner Chang 

BZ #: 4566

Update Redfish modules to use the small footprint version of base SortLib by the
means of module scoped subelement . With this the platform level
SortLib (full version) is not impacted if Redfish.dsc.inc is included in 
platform DSC.

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Igor Kulchytskyy 
Cc: Nhi Pham 
---
  RedfishPkg/RedfishComponents.dsc.inc | 10 --
  RedfishPkg/RedfishLibs.dsc.inc   |  1 -
  2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/RedfishPkg/RedfishComponents.dsc.inc
b/RedfishPkg/RedfishComponents.dsc.inc
index 1c4284d3ecf..464ffc86064 100644
--- a/RedfishPkg/RedfishComponents.dsc.inc
+++ b/RedfishPkg/RedfishComponents.dsc.inc
@@ -16,9 +16,15 @@
  !if $(REDFISH_ENABLE) == TRUE
RedfishPkg/RestJsonStructureDxe/RestJsonStructureDxe.inf
RedfishPkg/RedfishHostInterfaceDxe/RedfishHostInterfaceDxe.inf
-  RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf
+  RedfishPkg/RedfishRestExDxe/RedfishRestExDxe.inf  {
+
+  SortLib|MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
+  }
RedfishPkg/RedfishCredentialDxe/RedfishCredentialDxe.inf
-  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf
+  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.inf  {
+
+  SortLib|MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
+  }
RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.inf
RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigDxe.inf
MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
diff --git a/RedfishPkg/RedfishLibs.dsc.inc b/RedfishPkg/RedfishLibs.dsc.inc 
index
03b7ef6f328..5426957da87 100644
--- a/RedfishPkg/RedfishLibs.dsc.inc
+++ b/RedfishPkg/RedfishLibs.dsc.inc
@@ -14,7 +14,6 @@
  !if $(REDFISH_ENABLE) == TRUE
RestExLib|RedfishPkg/Library/DxeRestExLib/DxeRestExLib.inf
Ucs2Utf8Lib|RedfishPkg/Library/BaseUcs2Utf8Lib/BaseUcs2Utf8Lib.inf
-  SortLib|MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
RedfishCrtLib|RedfishPkg/PrivateLibrary/RedfishCrtLib/RedfishCrtLib.inf
JsonLib|RedfishPkg/Library/JsonLib/JsonLib.inf
RedfishLib|RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.inf
--
2.37.1.windows.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109514): https://edk2.groups.io/g/devel/message/109514
Mute This Topic: https://groups.io/mt/101890398/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] ArmPkg: Add Pcd to disable EFI_MEMORY_ATTRIBUTE_PROTOCOL

[Nhi Pham via groups.io]

Hi Ard, Oliver,

I'm investigating the crash on grub2/shim loader due to the added 
EFI_MEMORY_ATTRIBUTE_PROTOCOL when rebasing. I found this interesting 
patch and went through on the discussion, I am still not sure the 
conclusion on this patch.


This issue impacts many platforms, and any downstream edk2 has to clone 
this patch to disable the EFI_MEMORY_ATTRIBUTE_PROTOCOL until we have 
the loader fixed, maybe years. So, I wonder whether we can merge this 
patch with changing PcdEnableEfiMemoryAttributeProtocol to be disabled 
by default in DEC? This provides downstream platforms with the 
flexibility to enable/disable it as per their preference, rather than 
having to clone this path to their local repository. Furthermore, it 
does not impact the default installation of the 
EFI_MEMORY_ATTRIBUTE_PROTOCOL in the mainline.


Thanks,
Nhi

On 6/20/2023 11:03 PM, Gerd Hoffmann via groups.io wrote:

On Tue, Jun 20, 2023 at 04:16:40PM +0300, Ard Biesheuvel wrote:

On Tue, Jun 20, 2023, 12:33 Gerd Hoffmann  wrote:


On Mon, Jun 19, 2023 at 10:32:25PM +0200, Oliver Steffen wrote:

Recent versions of shim (15.6 and 15.7) crash when the newly added
EFI_MEMORY_ATTRIBUTE_PROTOCOL is provided by the firmware.  To allow
existing installations to boot, provide a workaround in form of a Pcd
that allows tuning it off at build time (defaults to 'enabled').


Background:  We have untested + broken code for
EFI_MEMORY_ATTRIBUTE_PROTOCOL support in the listed shim releases.

Now that firmware starts to actually provide that protocol the
time bomb explodes.


Fantastic.

This is kind of a big deal, really, and just turning it off for ArmVirtQemu
does not help at all with the fact that these shim builds will crash on any
platform that implements the protocol. (Including x86)


Sure.  This hits VM firmware first because we quickly rebase our builds
to new edk2 stable tags.  But yes, this is not limited to VMs and
likewise not limited to arm.


Given that secure boot is kind of pointless on this particular platform
anyway, maybe this is a good opportunity to make shim optional in the boot
chain? I understand that this does not fix existing builds but shim proves
to be such a problematic component that you really should not be using it
if there is no need.


I'd love to ditch shim.efi, even with secure boot.  For VMs one can
just enroll the distro signing certificate to 'db' and be done with
it.

Unfortunately shim has a solid position being *the* entry point for
linux efi systems due to being the only piece of software carrying a
microsoft signature.  Especially on install media you can't really have
more than one (such as different binaries depending on whenever secure
boot is on or off).  For installed systems and cloud images shim also
creates/restores Boot entries.

Additional problem is that shim is the piece of software which handles
sbat revocations, so even in case the distro cert is enrolled in 'db' so
the certificate handling implemented by shim is not needed I can't just
ignore shim.efi.


As for the protocol, this has its own set of problems, and the bug in
question can partly be blamed on the misdesigned api, which has separate
set and clear methods. Not only does this force the implementation to
traverse the page tables twice for the common case of switching between RO
and XP or vice versa, it also means we lose any transactional properties of
a RO <-> XP switch. I.e., if we could make it the implementation's
responsibility to ensure that such a transformation either completes
successfully, or otherwise, doesn't make any modifications at all, the risk
of ending up in a limbo state is reduced significantly.

So maybe there is still opportunity for specifying a MemoryAttributes2
protocol with a single method for set and clear? We could just drop the
current one in that case.


Sounds reasonable to me.


In any case, while i can see how this patch helps make all your ci status
icons turn green again, it does so by papering over the underlying issue so
I'm not a fan.


Yes.  It's not a solution, it's a workaround which we could use to turn
off EFI_MEMORY_ATTRIBUTE_PROTOCOL for a year or two, depending on how
quickly the shim / distro folks get their act together and updates
rolled out.

I'm not a fan either, but we need some temporary stopgap, and given that
others likely meet the very same problem too we figured sending it to
the list is a good idea, and here we are ;)

take care,
   Gerd









-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109343): https://edk2.groups.io/g/devel/message/109343
Mute This Topic: https://groups.io/mt/99631663/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] RFC: SetVariable callbacks

[Nhi Pham via groups.io]

Can we write a DXE_RUNTIME driver to override the pointers of UEFI 
Runtime Get/SetVariable() services? Then, we can add platform specific 
or custom implementation before/after calling the original 
Get/SetVariable()?


Regards,
Nhi

On 9/21/2023 3:27 AM, Girish Mahadevan via groups.io wrote:

Hello

We have a requirement to monitor setVariable calls, we'd like to get a 
callback before and after the variable update.


Similar to VarCheckLib, except that VarCheckLib's set callbacks are 
called after endOfDxe.


We were thinking of doing something like:

===

--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -2853,6 +2853,11 @@ VariableServiceSetVariable (
  return Status;
    }

+  Status = VarPreSetVariableCallback (VariableName, VendorGuid, 
Attributes, PayloadSize, (VOID *)((UINTN)Data + DataSize - PayloadSize), 
mRequestSource);^M

+  if (EFI_ERROR (Status)) {^M
+    return Status;^M
+  }^M
+^M
    AcquireLockOnlyAtBootTime 
(>VariableGlobal.VariableServicesLock);


    //
@@ -2917,6 +2922,8 @@ Done:
    InterlockedDecrement 
(>VariableGlobal.ReentrantState);
    ReleaseLockOnlyAtBootTime 
(>VariableGlobal.VariableServicesLock);


+  Status = VarPostSetVariableCallback (VariableName, VendorGuid, 
Attributes, PayloadSize, (VOID *)((UINTN)Data + DataSize - PayloadSize), 
mRequestSource);^M

+^M

==


We were thinking of 4 options:
1. A new Library, platforms can include the Null implementation if they 
don't need this.
2. A new protocol that is called from the Variable driver (similar to 
the Fvb protocol, we let the Smm/Dxe Variable drivers get this protocol)
3. Expand the existing VarCheckLib to include these new callbacks. 
(which can be called before end of dxe)

4. Something we don't know about (please let us know)

We are leaning toward option 1. Let us know your thoughts.

Best Regards
Girish








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108936): https://edk2.groups.io/g/devel/message/108936
Mute This Topic: https://groups.io/mt/101487036/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Platform/Ampere: Update Readme.md

[Nhi Pham via groups.io]

Reviewed-by: Nhi Pham 

Thanks,

Nhi

On 9/12/2023 12:44 AM, Rebecca Cran wrote:

Improve the Readme.md in Platform/Ampere:

- At this point eMAG is irrelevant, and most people are likely
   using Altra systems. Drop mention of it.
- Instead of mentioning the 'latest' versions of CentOS and Ubuntu
   (which will by definition change over time), specify Ubuntu 22.04
   and CentOS 7.
- Fix the link to the acpica download, since content has been moved from
   acpica.org to intel.com.
- Assuming the build is being done on Linux, acpica shouldn't be built
   with a CYGWIN definition.
- To avoid making people wait ages for acpica to build, add `-j8` as an
   example of building in parallel.

Signed-off-by: Rebecca Cran 
---
  Platform/Ampere/Readme.md | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Platform/Ampere/Readme.md b/Platform/Ampere/Readme.md
index 894bad3437b8..066876dab4b5 100644
--- a/Platform/Ampere/Readme.md
+++ b/Platform/Ampere/Readme.md
@@ -8,8 +8,8 @@ Silicon code is located under Silicon/Ampere/Ampere{SoC 
Name}Pkg.
  
  # Build machines
  
-- x86 Linux host machines running latest Ubuntu or CentOS releases.

-- Arm64 Linux host machines if native compiling. This has been tested on 
Ampere's eMAG and Altra hardware platforms with latest AArch64 CentOS or Ubuntu 
releases.
+- x86 Linux host machines running Ubuntu 22.04 or CentOS 7 releases.
+- Arm64 Linux host machines if native compiling. This has been tested on 
Ampere's Altra hardware platforms with AArch64 CentOS 7 or Ubuntu 22.04 
releases.
  
  # How to build (Linux Environment)
  
@@ -32,8 +32,8 @@ If you run into any build issue with the Intel ASL+ Optimizing Compiler/Disassem

  download and install the IASL compiler from https://acpica.org/. At the time 
of this write-up, we have tested with version 20200110.
  
  ```bash

-$ wget https://acpica.org/sites/acpica/files/acpica-unix2-20200110.tar.gz
+$ wget https://downloadmirror.intel.com/774850/acpica-unix2-20200110.tar.gz
  $ tar xzf acpica-unix2-20200110.tar.gz
  $ cd acpica-unix2-20200110
-$ make HOST=_CYGWIN && sudo make install
+$ make -j8 && sudo make install
  ```



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108512): https://edk2.groups.io/g/devel/message/108512
Mute This Topic: https://groups.io/mt/101298216/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 1/1] Maintainers.txt: Update maintainers for Ampere platforms

[Nhi Pham via groups.io]

This adds Rebecca Cran as reviewer, updates myself as maintainer, and
Leif as reviewer. Also, removes Vu Nguyen and Thang Nguyen due to no
longer working on EDK2.

Signed-off-by: Nhi Pham 
---
 Maintainers.txt | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index d1d7613ef48d..d77f0dd35ac4 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -99,11 +99,10 @@ M: Leif Lindholm 
 Ampere Computing
 F: Platform/Ampere
 F: Silicon/Ampere
-R: Nhi Pham 
-R: Vu Nguyen 
-R: Thang Nguyen 
+M: Nhi Pham 
 R: Chuong Tran 
-M: Leif Lindholm 
+R: Leif Lindholm 
+R: Rebecca Cran 
 
 ARM
 F: Platform/ARM/
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108404): https://edk2.groups.io/g/devel/message/108404
Mute This Topic: https://groups.io/mt/101217294/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue

[Nhi Pham via groups.io]

On 9/6/2023 11:22 PM, Oliver Smith-Denny wrote:

On 9/6/2023 1:50 AM, Ard Biesheuvel wrote:
On Wed, 6 Sept 2023 at 09:56, Nhi Pham 
 wrote:


On 9/6/2023 1:33 PM, Ni, Ray wrote:

[EXTERNAL EMAIL NOTICE: This email originated from an external sender.
Please be mindful of safe email handling and proprietary information
protection practices.]

I am a bit confused.

The HOB list in standalone MM is read-only. Why could any module call
BuildGuidHob() to modify the HOB.

I saw Oliver mentioned something about StMM. I don't know what that 
is.

But it seems that's ARM specific. Then, I don't think it's proper to
modify code here for a specific arch ARM.


The HOB creation is available in the
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf. If
other architectures also use that instance, I think the issue is not
specific to ARM.



The question here is whether the implementation follows the PI spec,
and whether HOB creation should be supported to begin with.



My reading of the PI spec is that this implementation does not follow
it. However, the PI spec is not very explicit about Standalone MM in
general, but particularly in relation to HOBs.

However, in the generic HOB section of PI spec v1.7, Vol. 3, section 4
(entitled HOB Design Discussion) it explicitly lays out that there are
HOB producer phases and HOB consumer phases. It uses PEI as a HOB
producer phase and DXE as a HOB consumer phase and explicitly says
that the HOB consumer phase must treat HOBs as read-only memory, per
Ray's comment.

In vol. 4, section 2.2, in discussing the Standalone MM entry point,
the document talks about the HOB list being passed to Standalone MM
to consume, which per the reading of the above section would classify
Standalone MM as a HOB consumer phase, where HOBs should then be
read-only.

So, I believe that we should not support HOB creation in Standalone MM
and instead rely on other mechanisms to pass information within the
phase. Per Nhi's other email in this thread, we should have the
discussion on how to solve that specific problem and that may well
lead to a discussion on whether HOBs are in fact the right mechanism
here, but I tend to lean towards leaving something as architectural as
HOBs to what the PI spec defines and using different mechanisms to
accomplish in-phase communication.
Thanks Oliver so much for that. I agree. We should focus on my specific 
problem with UEFI Variable Flash Info in StandaloneMM in another thread.


Does this reading of the spec align with others' expectations? As I
mentioned to Ray in another thread, Standalone MM feels like it could
have extra clarification in a few areas in the PI spec.


Thanks again. The HOB library should be updated to remove the HOB 
creation once we have the clarification.


Regards,

Nhi



Thanks,
Oliver



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108403): https://edk2.groups.io/g/devel/message/108403
Mute This Topic: https://groups.io/mt/89020085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue

[Nhi Pham via groups.io]

On 9/6/2023 1:33 PM, Ni, Ray wrote:
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. 
Please be mindful of safe email handling and proprietary information 
protection practices.]


I am a bit confused.

The HOB list in standalone MM is read-only. Why could any module call 
BuildGuidHob() to modify the HOB.


I saw Oliver mentioned something about StMM. I don't know what that is. 
But it seems that's ARM specific. Then, I don't think it's proper to 
modify code here for a specific arch ARM.


The HOB creation is available in the 
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf. If 
other architectures also use that instance, I think the issue is not 
specific to ARM.


Regards,
-Nhi


Thanks,
Ray

*From:* devel@edk2.groups.io  on behalf of Oliver 
Smith-Denny 

*Sent:* Wednesday, September 6, 2023 5:29 AM
*To:* Nhi Pham ; devel@edk2.groups.io 
; n...@os.amperecomputing.com 
; Ard Biesheuvel 
*Cc:* huangm...@linux.alibaba.com ; Sami 
Mujawar ; Ard Biesheuvel 
; Yao, Jiewen ; 
Supreeth Venkatesh ; ming.hua...@outlook.com 

*Subject:* Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB 
space and heap space conflicted issue

On 9/4/2023 7:20 PM, Nhi Pham wrote:

On 9/2/2023 3:43 AM, Oliver Smith-Denny wrote:

On 8/31/2023 1:20 AM, Nhi Pham via groups.io wrote:

If I am understanding this correctly, this is only an issue when
HOBs are created in StMM, i.e. not from HOBs that are passed in. Is this
correct?
Yes, the issue only occurs when HOB are created in StandaloneMM by the 
HOB library instance 
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf


If so, is HOB creation in StMM and supported use case? The only instance

I think it is intended to work as the CreateHob() function is implemented.


Well, that may just be a copy/paste sort of thing :).


a quick search turns up is the ARM StMM Core entry, where some
information from TF-A is converted to HOB format. Do we have any other
use cases (and curious more on this use case). My thought process would
be that StMM would not create any HOBs. Depending on FW configuration,
it may receive HOBs from PEI.


I have a use case when enabling the UEFI Variable driver running in 
StandaloneMM. Instead of using the PCDs, the in-memory NVRAM region is 
allocated **dynamically** at boot time in the StMM secure memory. Then, 
they will be passed into the gVariableFlashInfoHobGuid for being 
consumed by other variable MM drivers.




I do believe that per the PI spec, we should have HOB producer and HOB
consumer phases, where in this case PEI (if it was the launching entity
for StMM) is the HOB producer and StMM is the HOB producer. This is the
same pattern the PI spec details for PEI and DXE, where DXE is not
intended to create new HOBs, but just to consume information from the
previous phase.

As I mentioned, there are other interfaces for passing information
within a phase, such as protocols, dynamic PCDs, variables, etc. that
are built for this application. I think it is useful to adhere to the
model for HOBs (which are hand off blocks, one phase handing information
to another phase) and that we will create more issues if we rely on
HOB consumer phases producing HOBs.

My proposal would be to remove the HOB creation code from StMM
completely. I believe in your use case that you are describing a dynamic
PCD or a protocol could work to pass the information.

If we are saying that prior to your patch that HOB creation in StMM was
completely broken, anyway, it seems that folks were not relying on this
code?

Thanks,
Oliver








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108311): https://edk2.groups.io/g/devel/message/108311
Mute This Topic: https://groups.io/mt/89020085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue

[Nhi Pham via groups.io]

On 9/6/2023 4:29 AM, Oliver Smith-Denny wrote:


On 9/4/2023 7:20 PM, Nhi Pham wrote:

On 9/2/2023 3:43 AM, Oliver Smith-Denny wrote:

On 8/31/2023 1:20 AM, Nhi Pham via groups.io wrote:

If I am understanding this correctly, this is only an issue when
HOBs are created in StMM, i.e. not from HOBs that are passed in. Is 
this

correct?
Yes, the issue only occurs when HOB are created in StandaloneMM by 
the HOB library instance 
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf


If so, is HOB creation in StMM and supported use case? The only 
instance
I think it is intended to work as the CreateHob() function is 
implemented.


Well, that may just be a copy/paste sort of thing :).


a quick search turns up is the ARM StMM Core entry, where some
information from TF-A is converted to HOB format. Do we have any other
use cases (and curious more on this use case). My thought process would
be that StMM would not create any HOBs. Depending on FW configuration,
it may receive HOBs from PEI.


I have a use case when enabling the UEFI Variable driver running in 
StandaloneMM. Instead of using the PCDs, the in-memory NVRAM region 
is allocated **dynamically** at boot time in the StMM secure memory. 
Then, they will be passed into the gVariableFlashInfoHobGuid for 
being consumed by other variable MM drivers.




I do believe that per the PI spec, we should have HOB producer and HOB
consumer phases, where in this case PEI (if it was the launching entity
for StMM) is the HOB producer and StMM is the HOB producer. This is the
same pattern the PI spec details for PEI and DXE, where DXE is not
intended to create new HOBs, but just to consume information from the
previous phase.

As I mentioned, there are other interfaces for passing information
within a phase, such as protocols, dynamic PCDs, variables, etc. that
are built for this application. I think it is useful to adhere to the
model for HOBs (which are hand off blocks, one phase handing information
to another phase) and that we will create more issues if we rely on
HOB consumer phases producing HOBs.

Thanks Oliver for the explanation. That makes sense to me.


My proposal would be to remove the HOB creation code from StMM
completely. I believe in your use case that you are describing a dynamic
PCD or a protocol could work to pass the information.
I think the dynamic PCD is supposed to not being supported in 
StandaloneMM and protocol does not fit because the Variable Flash Info 
is created in PEI for UEFI variable non-MM flow and in StMM for UEFI 
variable MM flow.


If we are saying that prior to your patch that HOB creation in StMM was
completely broken, anyway, it seems that folks were not relying on this
code?


Right, it is just my curiosity that I don't see any showcase for 
Variable MM + Variable Flash Info HOB in StandaloneMM.


Adding Michael Kubacki as the owner of the Variable Flash Info HOB for 
getting further input.




Thanks,
Oliver



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108310): https://edk2.groups.io/g/devel/message/108310
Mute This Topic: https://groups.io/mt/89020085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue

[Nhi Pham via groups.io]

Hi Oliver, thank you for taking a look at this patch.

On 9/2/2023 3:43 AM, Oliver Smith-Denny wrote:

On 8/31/2023 1:20 AM, Nhi Pham via groups.io wrote:

Hi Ard,

Thanks for your response on this patch. Please see my reply inline...

On 8/30/2023 8:10 PM, Ard Biesheuvel wrote:
[EXTERNAL EMAIL NOTICE: This email originated from an external 
sender. Please be mindful of safe email handling and proprietary 
information protection practices.]



On Wed, 16 Aug 2023 at 10:56, Nhi Pham 
 wrote:

Hi Ard and Ming,

I have been seeing an issue with StandaloneMM HobLib that can be fixed
by this patch as well.

The function CreateHob() in the HobLib instance
StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf 


does not work at all. The HobList is early created by the
StandaloneMmCoreEntryPoint then it is relocated on the heap memory by
StandaloneMmCore. But the FreeMemoryTop and FreeMemoryBottom are not
updated accordingly and the HOB free memory top is overlapped with the
heap space. This causes the CreateHob() function to not work as
expected. Introducing the PcdMemoryHobSize is reasonable to fix 
this issue.


I tested this patch in my end.

Tested-by: Nhi Pham 


Thanks for reminding me.

So if the HOB creation is completely broken, are we sure this is the
correct fix? Wouldn't it be better to update FreeMemoryTop and
FreeMemoryBottom to the correct values?


Per your question, I had a deep dive into the HOB today. I think I 
need to clarify further the issue to make sure that we are on the 
same page.


1. When the base of the HOB list (HobStart) is reallocated in the MM 
heap memory, the Hob->EfiEndOfHobList must be adjusted accordingly 
compared to the new HOB base. Currently, we are missing that. That 
causes the CreateHob() function does not work. The GetNextHob() 
function always look up the old HOB list instead of the new HOB list.


2. The Memory Allocation StandaloneMmPkg/Core/Page.c does not update 
the Hob->EfiFreeMemoryTop, this may cause the MM heap space and HOB 
space to be overlapped at some points.


It sounds like the issue on the memory allocation in StandaloneMM. 
For #1, I think we should write a new patch for it. For #2, could you 
advise?




If I am understanding this correctly, this is only an issue when
HOBs are created in StMM, i.e. not from HOBs that are passed in. Is this
correct?
Yes, the issue only occurs when HOB are created in StandaloneMM by the 
HOB library instance 
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf


If so, is HOB creation in StMM and supported use case? The only instance

I think it is intended to work as the CreateHob() function is implemented.

a quick search turns up is the ARM StMM Core entry, where some
information from TF-A is converted to HOB format. Do we have any other
use cases (and curious more on this use case). My thought process would
be that StMM would not create any HOBs. Depending on FW configuration,
it may receive HOBs from PEI.


I have a use case when enabling the UEFI Variable driver running in 
StandaloneMM. Instead of using the PCDs, the in-memory NVRAM region is 
allocated **dynamically** at boot time in the StMM secure memory. Then, 
they will be passed into the gVariableFlashInfoHobGuid for being 
consumed by other variable MM drivers.




In PEI/DXE to StMM communication, we should be using the
MM_Communicate interface.

But in StMM to StMM communication, I would expect we would go through
interfaces like protocols, PCDs, or UEFI variables. Any reason for HOBs
that I'm not thinking of? I'm wondering if the answer here is to
address what seemingly is one (or a very small set) of use cases and
remove the HOB creation code in StMM altogether.

Thanks,
Oliver



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108269): https://edk2.groups.io/g/devel/message/108269
Mute This Topic: https://groups.io/mt/89020085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue

[Nhi Pham via groups.io]

Hi Ard,

Thanks for your response on this patch. Please see my reply inline...

On 8/30/2023 8:10 PM, Ard Biesheuvel wrote:

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, 16 Aug 2023 at 10:56, Nhi Pham  wrote:

Hi Ard and Ming,

I have been seeing an issue with StandaloneMM HobLib that can be fixed
by this patch as well.

The function CreateHob() in the HobLib instance
StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
does not work at all. The HobList is early created by the
StandaloneMmCoreEntryPoint then it is relocated on the heap memory by
StandaloneMmCore. But the FreeMemoryTop and FreeMemoryBottom are not
updated accordingly and the HOB free memory top is overlapped with the
heap space. This causes the CreateHob() function to not work as
expected. Introducing the PcdMemoryHobSize is reasonable to fix this issue.

I tested this patch in my end.

Tested-by: Nhi Pham 


Thanks for reminding me.

So if the HOB creation is completely broken, are we sure this is the
correct fix? Wouldn't it be better to update FreeMemoryTop and
FreeMemoryBottom to the correct values?


Per your question, I had a deep dive into the HOB today. I think I need 
to clarify further the issue to make sure that we are on the same page.


1. When the base of the HOB list (HobStart) is reallocated in the MM 
heap memory, the Hob->EfiEndOfHobList must be adjusted accordingly 
compared to the new HOB base. Currently, we are missing that. That 
causes the CreateHob() function does not work. The GetNextHob() function 
always look up the old HOB list instead of the new HOB list.


2. The Memory Allocation StandaloneMmPkg/Core/Page.c does not update the 
Hob->EfiFreeMemoryTop, this may cause the MM heap space and HOB space to 
be overlapped at some points.


It sounds like the issue on the memory allocation in StandaloneMM. For 
#1, I think we should write a new patch for it. For #2, could you advise?


Thanks,

-Nhi



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108185): https://edk2.groups.io/g/devel/message/108185
Mute This Topic: https://groups.io/mt/89020085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue

[Nhi Pham via groups.io]

Just a gentle ping!

Hi Ard, can you provide your feedback on this patch?

Thanks,

-Nhi

On 8/16/2023 3:55 PM, Nhi Pham via groups.io wrote:

Hi Ard and Ming,

I have been seeing an issue with StandaloneMM HobLib that can be fixed 
by this patch as well.


The function CreateHob() in the HobLib instance 
StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf 
does not work at all. The HobList is early created by the 
StandaloneMmCoreEntryPoint then it is relocated on the heap memory by 
StandaloneMmCore. But the FreeMemoryTop and FreeMemoryBottom are not 
updated accordingly and the HOB free memory top is overlapped with the 
heap space. This causes the CreateHob() function to not work as 
expected. Introducing the PcdMemoryHobSize is reasonable to fix this 
issue.


I tested this patch in my end.

Tested-by: Nhi Pham 

Thanks,

-Nhi

On 5/12/2022 5:09 PM, Ming Huang via groups.io wrote:


在 5/3/22 5:10 PM, Ard Biesheuvel 写道:
On Wed, 9 Feb 2022 at 13:26, Ming Huang 
 wrote:

The heap space will be rewrote if a StandloneMmPkg module create HOB
by BuildGuidHob() interface and write data to HOB space.

Can you elaborate? What is supposed to happen and why, and what is
happening instead?

I tried my best to explain the issue:

-<--HandOffHob->EfiFreeMemoryTop
|   |
|   |
|   |
|   |
|   |
|   |
|  mMmMemoryMap |
|---|<--HandOffHob->EfiFreeMemoryBottom
|  HobEnd   |
|---|<--HandOffHob->EfiEndOfHobList
|   |
|  Hob #1   |
-<--MmHobStart
1 The mMmMemoryMap which use for free page is on above the HobEnd.
2 Create a hob by BuildGuidHob(), the HobEnd will move up and cover
   the structure or list using by free page.

After this patch, there is a pre-allocation space for creating hob.

-<--HandOffHob->EfiFreeMemoryTop
|   |
|   |
|   |
|   |
| mMmMemoryMap  |
|---|<--HandOffHob->EfiFreeMemoryBottom
|  Hob free space   | by PcdMemoryHobSize
|---|
|  HobEnd   |
|---|<--HandOffHob->EfiEndOfHobList
|   |
|  Hob #1   |
-<--MmHobStart


Add a PCD PcdMemoryHobSize for pre-allocation a space to create HOB to
fix this issue.

Signed-off-by: Ming Huang 
---
  StandaloneMmPkg/Core/StandaloneMmCore.c   | 17 -
  StandaloneMmPkg/Core/StandaloneMmCore.inf |  3 +++
  StandaloneMmPkg/StandaloneMmPkg.dec   |  2 ++
  3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.c 
b/StandaloneMmPkg/Core/StandaloneMmCore.c

index d221f1d111..1cf259d946 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.c
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.c
@@ -512,6 +512,9 @@ StandaloneMmMain (
    EFI_MMRAM_DESCRIPTOR    *MmramRanges;
    UINTN   MmramRangeCount;
    EFI_HOB_FIRMWARE_VOLUME *BfvHob;
+  EFI_HOB_HANDOFF_INFO_TABLE  *HandOffHobNew;
+  EFI_HOB_HANDOFF_INFO_TABLE  *HandOffHobOrg;
+  UINT64  MaxHobSize = PcdGet64 
(PcdMemoryHobSize);


    ProcessLibraryConstructorList (HobStart, );

@@ -619,10 +622,22 @@ StandaloneMmMain (
    //
    HobSize = GetHobListSize (HobStart);
    DEBUG ((DEBUG_INFO, "HobSize - 0x%x\n", HobSize));
-  MmHobStart = AllocatePool (HobSize);
+  ASSERT (HobSize <= MaxHobSize);
+  MmHobStart = AllocatePool (MaxHobSize);
    DEBUG ((DEBUG_INFO, "MmHobStart - 0x%x\n", MmHobStart));
    ASSERT (MmHobStart != NULL);
    CopyMem (MmHobStart, HobStart, HobSize);
+  //
+  // Initlialize the new HOB table
+  //
+  HandOffHobOrg = (EFI_HOB_HANDOFF_INFO_TABLE *)HobStart;
+  HandOffHobNew = (EFI_HOB_HANDOFF_INFO_TABLE *)MmHobStart;
+  HandOffHobNew->EfiEndOfHobList = (EFI_PHYSICAL_ADDRESS)MmHobStart +
+    (HandOffHobOrg->EfiEndOfHobList - 
(EFI_PHYSICAL_ADDRESS)HobStart);
+  HandOffHobNew->EfiFreeMemoryBottom = 
HandOffHobNew->EfiEndOfHobList +
+   sizeof 
(EFI_HOB_GENERIC_HEADER);
+  HandOffHobNew->EfiFreeMemoryTop = 
(EFI_PHYSICAL_ADDRESS)MmHobStart + MaxHobSize;

+
    Status = MmInstallConfigurationTable (, 
, MmHobStart, HobSize);

    ASSERT_EFI_ERROR (Status);

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf 
b/StandaloneMmPkg/Core/StandaloneMmCore.inf

index c44b9ff333..37e6135d73 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
@@ -76,6 +76

Re: [edk2-devel] [PATCH 1/1] ShellPkg/SmbiosView: Update display of PCIe system slot ID

[Nhi Pham via groups.io]

Thanks Zhichao, I updated the commit message and also created a PR at 
https://github.com/tianocore/edk2/pull/4767


Please help check.

Regards,

-Nhi

On 8/21/2023 2:01 PM, Gao, Zhichao wrote:

Better to update the commit message with specific SMBIOS version.
Others looks good to me.

Thanks,
Zhichao


-Original Message-
From: Nhi Pham 
Sent: Friday, August 18, 2023 2:54 PM
To: devel@edk2.groups.io
Cc: Nhi Pham ; Gao, Zhichao

Subject: [PATCH 1/1] ShellPkg/SmbiosView: Update display of PCIe system
slot ID

This updates the system slot ID up to SlotTypePCIExpressGen6andBeyond
(0xC4) to cover modern PCIe Gen.

Cc: Zhichao Gao 
Signed-off-by: Nhi Pham 
---
  ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c | 2
+-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
index f55d5f953c04..b6968cb36acb 100644
---
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
+++
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
@@ -3105,7 +3105,7 @@ DisplaySystemSlotId (
break;



  default:

-  if (((SlotType >= 0x0E) && (SlotType <= 0x12)) || ((SlotType >= 0xA6) &&
(SlotType <= 0xB6))) {

+  if (((SlotType >= 0x0E) && (SlotType <= 0x12)) || ((SlotType >= 0xA6) &&
(SlotType <= 0xC4))) {

  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
(STR_SMBIOSVIEW_PRINTINFO_VALUE_PRESENT), gShellDebug1HiiHandle,
SlotId);

} else {

  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
(STR_SMBIOSVIEW_PRINTINFO_UNDEFINED_SLOT_ID),
gShellDebug1HiiHandle);

--
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108074): https://edk2.groups.io/g/devel/message/108074
Mute This Topic: https://groups.io/mt/100816049/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RESEND][PATCH 1/1] MdeModulePkg/PciBusDxe: Fix boot hang with faulty PCI Option ROM

[Nhi Pham via groups.io]

A faulty PCI device has the Option ROM image size set to 0. UEFI reads
two headers PCI_EXPANSION_ROM_HEADER and PCI_DATA_STRUCTURE to get the
Option ROM information. Because the image size is 0, the Option ROM
header address never changes. As a result, UEFI keeps reading the same
two headers definitely. This patch is intended to fix it.

Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Hao A Wu 
Cc: Ray Ni 
Signed-off-by: Nhi Pham 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
index 89f5f64101a5..bd5ace18f6e4 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
@@ -506,13 +506,13 @@ LoadOpRomImage (
 Indicator= RomPcir->Indicator;

 RomImageSize = RomImageSize + RomPcir->ImageLength * 512;

 RomBarOffset = RomBarOffset + RomPcir->ImageLength * 512;

-  } while (((Indicator & 0x80) == 0x00) && ((RomBarOffset - RomBar) < 
RomSize));

+  } while (((Indicator & 0x80) == 0x00) && ((RomBarOffset - RomBar) < RomSize) 
&& (RomImageSize > 0));

 

   //

   // Some Legacy Cards do not report the correct ImageLength so used the 
maximum

   // of the legacy length and the PCIR Image Length

   //

-  if (CodeType == PCI_CODE_TYPE_PCAT_IMAGE) {

+  if ((RomImageSize > 0) && (CodeType == PCI_CODE_TYPE_PCAT_IMAGE)) {

 RomImageSize = MAX (RomImageSize, LegacyImageLength);

   }

 

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107909): https://edk2.groups.io/g/devel/message/107909
Mute This Topic: https://groups.io/mt/100867193/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] MdeModulePkg/PciBusDxe: Fix boot hang with faulty PCI Option ROM

[Nhi Pham via groups.io]

A faulty PCI device has the Option ROM image size set to 0. UEFI reads
two headers PCI_EXPANSION_ROM_HEADER and PCI_DATA_STRUCTURE to get the
Option ROM information. Because the image size is 0, the Option ROM
header address never changes. As a result, UEFI keeps reading the same
two headers definitely. This patch is intended to fix it.

Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Hao A Wu 
Signed-off-by: Nhi Pham 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
index 89f5f64101a5..bd5ace18f6e4 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciOptionRomSupport.c
@@ -506,13 +506,13 @@ LoadOpRomImage (
 Indicator= RomPcir->Indicator;

 RomImageSize = RomImageSize + RomPcir->ImageLength * 512;

 RomBarOffset = RomBarOffset + RomPcir->ImageLength * 512;

-  } while (((Indicator & 0x80) == 0x00) && ((RomBarOffset - RomBar) < 
RomSize));

+  } while (((Indicator & 0x80) == 0x00) && ((RomBarOffset - RomBar) < RomSize) 
&& (RomImageSize > 0));

 

   //

   // Some Legacy Cards do not report the correct ImageLength so used the 
maximum

   // of the legacy length and the PCIR Image Length

   //

-  if (CodeType == PCI_CODE_TYPE_PCAT_IMAGE) {

+  if ((RomImageSize > 0) && (CodeType == PCI_CODE_TYPE_PCAT_IMAGE)) {

 RomImageSize = MAX (RomImageSize, LegacyImageLength);

   }

 

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107907): https://edk2.groups.io/g/devel/message/107907
Mute This Topic: https://groups.io/mt/100867107/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] ShellPkg/SmbiosView: Update display of PCIe system slot ID

[Nhi Pham via groups.io]

This updates the system slot ID up to SlotTypePCIExpressGen6andBeyond
(0xC4) to cover modern PCIe Gen.

Cc: Zhichao Gao 
Signed-off-by: Nhi Pham 
---
 ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
index f55d5f953c04..b6968cb36acb 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
@@ -3105,7 +3105,7 @@ DisplaySystemSlotId (
   break;

 

 default:

-  if (((SlotType >= 0x0E) && (SlotType <= 0x12)) || ((SlotType >= 0xA6) && 
(SlotType <= 0xB6))) {

+  if (((SlotType >= 0x0E) && (SlotType <= 0x12)) || ((SlotType >= 0xA6) && 
(SlotType <= 0xC4))) {

 ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_SMBIOSVIEW_PRINTINFO_VALUE_PRESENT), gShellDebug1HiiHandle, SlotId);

   } else {

 ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
(STR_SMBIOSVIEW_PRINTINFO_UNDEFINED_SLOT_ID), gShellDebug1HiiHandle);

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107843): https://edk2.groups.io/g/devel/message/107843
Mute This Topic: https://groups.io/mt/100816049/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue

[Nhi Pham via groups.io]

Hi Ard and Ming,

I have been seeing an issue with StandaloneMM HobLib that can be fixed 
by this patch as well.


The function CreateHob() in the HobLib instance 
StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf 
does not work at all. The HobList is early created by the 
StandaloneMmCoreEntryPoint then it is relocated on the heap memory by 
StandaloneMmCore. But the FreeMemoryTop and FreeMemoryBottom are not 
updated accordingly and the HOB free memory top is overlapped with the 
heap space. This causes the CreateHob() function to not work as 
expected. Introducing the PcdMemoryHobSize is reasonable to fix this issue.


I tested this patch in my end.

Tested-by: Nhi Pham 

Thanks,

-Nhi

On 5/12/2022 5:09 PM, Ming Huang via groups.io wrote:


在 5/3/22 5:10 PM, Ard Biesheuvel 写道:

On Wed, 9 Feb 2022 at 13:26, Ming Huang  wrote:

The heap space will be rewrote if a StandloneMmPkg module create HOB
by BuildGuidHob() interface and write data to HOB space.

Can you elaborate? What is supposed to happen and why, and what is
happening instead?

I tried my best to explain the issue:

-<--HandOffHob->EfiFreeMemoryTop
|   |
|   |
|   |
|   |
|   |
|   |
|  mMmMemoryMap |
|---|<--HandOffHob->EfiFreeMemoryBottom
|  HobEnd   |
|---|<--HandOffHob->EfiEndOfHobList
|   |
|  Hob #1   |
-<--MmHobStart
1 The mMmMemoryMap which use for free page is on above the HobEnd.
2 Create a hob by BuildGuidHob(), the HobEnd will move up and cover
   the structure or list using by free page.

After this patch, there is a pre-allocation space for creating hob.

-<--HandOffHob->EfiFreeMemoryTop
|   |
|   |
|   |
|   |
| mMmMemoryMap  |
|---|<--HandOffHob->EfiFreeMemoryBottom
|  Hob free space   | by PcdMemoryHobSize
|---|
|  HobEnd   |
|---|<--HandOffHob->EfiEndOfHobList
|   |
|  Hob #1   |
-<--MmHobStart


Add a PCD PcdMemoryHobSize for pre-allocation a space to create HOB to
fix this issue.

Signed-off-by: Ming Huang 
---
  StandaloneMmPkg/Core/StandaloneMmCore.c   | 17 -
  StandaloneMmPkg/Core/StandaloneMmCore.inf |  3 +++
  StandaloneMmPkg/StandaloneMmPkg.dec   |  2 ++
  3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.c 
b/StandaloneMmPkg/Core/StandaloneMmCore.c
index d221f1d111..1cf259d946 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.c
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.c
@@ -512,6 +512,9 @@ StandaloneMmMain (
EFI_MMRAM_DESCRIPTOR*MmramRanges;
UINTN   MmramRangeCount;
EFI_HOB_FIRMWARE_VOLUME *BfvHob;
+  EFI_HOB_HANDOFF_INFO_TABLE  *HandOffHobNew;
+  EFI_HOB_HANDOFF_INFO_TABLE  *HandOffHobOrg;
+  UINT64  MaxHobSize = PcdGet64 (PcdMemoryHobSize);

ProcessLibraryConstructorList (HobStart, );

@@ -619,10 +622,22 @@ StandaloneMmMain (
//
HobSize = GetHobListSize (HobStart);
DEBUG ((DEBUG_INFO, "HobSize - 0x%x\n", HobSize));
-  MmHobStart = AllocatePool (HobSize);
+  ASSERT (HobSize <= MaxHobSize);
+  MmHobStart = AllocatePool (MaxHobSize);
DEBUG ((DEBUG_INFO, "MmHobStart - 0x%x\n", MmHobStart));
ASSERT (MmHobStart != NULL);
CopyMem (MmHobStart, HobStart, HobSize);
+  //
+  // Initlialize the new HOB table
+  //
+  HandOffHobOrg = (EFI_HOB_HANDOFF_INFO_TABLE *)HobStart;
+  HandOffHobNew = (EFI_HOB_HANDOFF_INFO_TABLE *)MmHobStart;
+  HandOffHobNew->EfiEndOfHobList = (EFI_PHYSICAL_ADDRESS)MmHobStart +
+(HandOffHobOrg->EfiEndOfHobList - (EFI_PHYSICAL_ADDRESS)HobStart);
+  HandOffHobNew->EfiFreeMemoryBottom = HandOffHobNew->EfiEndOfHobList +
+   sizeof (EFI_HOB_GENERIC_HEADER);
+  HandOffHobNew->EfiFreeMemoryTop = (EFI_PHYSICAL_ADDRESS)MmHobStart + 
MaxHobSize;
+
Status = MmInstallConfigurationTable (, , 
MmHobStart, HobSize);
ASSERT_EFI_ERROR (Status);

diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.inf 
b/StandaloneMmPkg/Core/StandaloneMmCore.inf
index c44b9ff333..37e6135d73 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.inf
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.inf
@@ -76,6 +76,9 @@
gEfiEventExitBootServicesGuid
gEfiEventReadyToBootGuid

+[FixedPcd]
+  gStandaloneMmPkgTokenSpaceGuid.PcdMemoryHobSize
+
  #
  # This configuration fails for CLANGPDB, which does not support PIE in the GCC
  # sense. Such however is required for ARM family 

[edk2-devel] [PATCH 1/1] RedfishPkg/RedfishPlatformConfigDxe: Fix unused variable

[Nhi Pham via groups.io]

This fixes an unused variable 'Index' error in release build.

Cc: Nickle Wang 
Cc: Abner Chang 
Cc: Igor Kulchytskyy 
Cc: Nick Ramirez 
Signed-off-by: Nhi Pham 
---

PR: https://github.com/tianocore/edk2/pull/4742

 RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigImpl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigImpl.c 
b/RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigImpl.c
index e4a905aec44e..47d35abc0885 100644
--- a/RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigImpl.c
+++ b/RedfishPkg/RedfishPlatformConfigDxe/RedfishPlatformConfigImpl.c
@@ -671,7 +671,8 @@ GetStatementPrivateByConfigureLang (

 DEBUG_CODE (
   STATIC UINTN Index = 0;
-  DEBUG ((REDFISH_PLATFORM_CONFIG_DEBUG, "%a: [%d] search %s in QID: 
0x%x form: 0x%x formset: %g\n", __func__, ++Index, ConfigureLang, 
HiiStatementPrivate->QuestionId, HiiFormPrivate->Id, >Guid));
+  Index++;
+  DEBUG ((REDFISH_PLATFORM_CONFIG_DEBUG, "%a: [%d] search %s in QID: 
0x%x form: 0x%x formset: %g\n", __func__, Index, ConfigureLang, 
HiiStatementPrivate->QuestionId, HiiFormPrivate->Id, >Guid));
   );

 if (HiiStatementPrivate->Description != 0) {
--
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107786): https://edk2.groups.io/g/devel/message/107786
Mute This Topic: https://groups.io/mt/100773733/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 0/4] Add support new SMBIOS Tables and refactor to adapt with ArmPkg/SMBIOS

[Nhi Pham via groups.io]

Hi Ard,

The error is created by this commit 
https://github.com/tianocore/edk2/commit/e6447d2a08f5ca585816d093e79a01dad3781f98. 
We are investigating and will get back to you soon.


Thanks for merging our patches.

-Nhi

On 6/2/2023 7:48 PM, Ard Biesheuvel wrote:

On Wed, 24 May 2023 at 02:41, Minh Nguyen
 wrote:

These patches helps to add new SMBIOS Tables (Type 16, 17, 19) and refactor 
SmbiosPlatformDxe.

Minh Nguyen (4):
   JadePkg: Correct PCD names for SMBIOS Type 0
   JadePkg: Leverage ArmPkg/Smbios (Type 0, 1, 2, 3, 13, 32)
   JadePkg: Refactor SmbiosPlatformDxe
   JadePkg: Add support SMBIOS Table Type 16, 17, 19


Pushed as 38170a4175a6..6fe5a2309118

I tried to do a build test of Jade.dsc but I got an error related to
PcdValueInit. Any idea what is going on here?


  Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec  
  |   14 +-
  Platform/Ampere/JadePkg/Jade.dsc  
  |7 +-
  Platform/Ampere/JadePkg/Jade.fdf  
  |1 +
  Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf   
  |   43 +-
  Platform/Ampere/JadePkg/Library/OemMiscLib/OemMiscLib.inf 
  |   15 +-
  Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.h 
  |  201 +++
  Silicon/Ampere/AmpereAltraPkg/Include/Library/AmpereCpuLib.h  
  |   46 +
  Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
  | 1553 ++--
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxeDataTable.c  
|   96 ++
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type08/PlatformPortConnectorData.c
|  142 ++
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type08/PlatformPortConnectorFunction.c
|   57 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type09/PlatformSystemSlotData.c
   |  268 
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type09/PlatformSystemSlotFunction.c
   |   58 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type11/PlatformOemStringData.c
|   42 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type11/PlatformOemStringFunction.c
|   57 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type16/PlatformPhysicalMemoryArrayData.c
  |   48 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type16/PlatformPhysicalMemoryArrayFunction.c
  |   44 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type17/PlatformMemoryDeviceData.c
 |   63 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type17/PlatformMemoryDeviceFunction.c
 |  475 ++
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type19/PlatformMemoryArrayMappedAddressData.c
 |   47 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type19/PlatformMemoryArrayMappedAddressFunction.c
 |  150 ++
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type24/PlatformHardwareSecurityData.c
 |   42 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type24/PlatformHardwareSecurityFunction.c
 |   57 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type38/PlatformIpmiDeviceData.c
   |   46 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type38/PlatformIpmiDeviceFunction.c
   |   39 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type41/PlatformOnboardDevicesExtendedData.c
   |   47 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type41/PlatformOnboardDevicesExtendedFunction.c
   |   57 +
  Platform/Ampere/JadePkg/Library/OemMiscLib/OemMiscLib.c   
  |  246 +++-
  Silicon/Ampere/AmpereAltraPkg/Library/AmpereCpuLib/AmpereCpuLibCommon.c   
  |   84 ++
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxeStrings.uni  
|   22 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type08/PlatformPortConnector.uni
  |   22 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type09/PlatformSystemSlot.uni 
|   20 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type11/PlatformOemString.uni  
|   11 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type17/PlatformMemoryDevice.uni
   |   16 +
  
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/Type41/PlatformOnboardDevicesExtended.uni
 |   10 +
  35 files changed, 3005 insertions(+), 1141 deletions(-)
  mode change 100644 => 100755 
Platform/Ampere/JadePkg/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
  create mode 100644 

Re: [edk2-devel] [PATCH 0/2] Fix an issue in SmbiosMiscDxe module

[Nhi Pham via groups.io]

This patch series looks good to me.

Reviewed-by: Nhi Pham 

Thanks,

Nhi

On 5/16/2023 2:08 PM, Minh Nguyen wrote:

These patches help to fix an issue in SmbiosMiscDxe and remove redundant asign 
for SmbiosHandle.

Minh Nguyen (2):
   ArmPkg/SmbiosMiscDxe: Fix procedure to get handle of SMBIOS records
   ArmPkg/SmbiosMiscDxe: Remove redundant assign for SmbiosHandle

  ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscEntryPoint.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105169): https://edk2.groups.io/g/devel/message/105169
Mute This Topic: https://groups.io/mt/98948706/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 0/3] Add necessary changes for PCIe core and remove unnecessary checks for PCIe Devmap mode

[Nhi Pham via groups.io]

Hi Minh,

Thanks for this patchset. It looks good to me.

Reviewed-by: Nhi Pham 

Hi Leif, Ard - Could you please help merge this series?

Thanks,

Nhi

On 5/11/2023 2:51 PM, Minh Nguyen wrote:

These patches help to improve PCIe core for Link training sequence and
add logic to check PCIe card is present or not. One patch also removes
unnecessary checks for PCIe Devmap mode.

Minh Nguyen (2):
   AmpereAltraPkg: Remove PCIe "DevMapModeAuto" case in retrieving Devmap
 mode
   AmpereAltraPkg: Fix PCIe link training sequence

Tinh Nguyen (1):
   AmpereAltraPkg: Add retry logic when PCIe card is present

  Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/RootComplexNVParam.c |  2 +-
  Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c   | 12 

  2 files changed, 9 insertions(+), 5 deletions(-)




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104742): https://edk2.groups.io/g/devel/message/104742
Mute This Topic: https://groups.io/mt/98831762/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel][edk2-platforms][PATCH 0/2] Support for PCIe Auto Bifurcation feature

[Nhi Pham via groups.io]

Thanks Minh for this series. It looks good to me.

Reviewed-by: Nhi Pham 

Hi Leif, Ard - Could you please help merge this series?

Thanks,

Nhi

On 5/5/2023 9:49 AM, Minh Nguyen wrote:

These patches support for PCIe Auto Bifurcation feature of Ampere
silicon (Altra and Altra Max).

Vu Nguyen (2):
   AmpereAltraPkg: Add support for PCIe Auto Bifurcation
   AmpereAltraPkg: Enable auto bifurcation via BoardSetting

  Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/RootComplexNVParam.h
  |   4 +-
  Silicon/Ampere/AmpereAltraPkg/Include/Guid/RootComplexInfoHob.h   
  |   5 +-
  Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.h  
  |   5 +
  Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/RootComplexNVParam.c
  |  14 +-
  
Silicon/Ampere/AmpereAltraPkg/Drivers/RootComplexConfigDxe/RootComplexConfigDxe.c
   |  19 +-
  Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c  
  | 344 +++-
  
Silicon/Ampere/AmpereAltraPkg/Drivers/RootComplexConfigDxe/RootComplexConfigDxe.uni
 |   3 +-
  7 files changed, 383 insertions(+), 11 deletions(-)




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104489): https://edk2.groups.io/g/devel/message/104489
Mute This Topic: https://groups.io/mt/98698192/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Add AUTH_SIG_NOT_FOUND Action

[Nhi Pham via groups.io]

Thanks Yao Jiewen for reviewing. I will make further investigation for 
other cases based on your findings.


In the meantime, could you help merge my patch?

-Nhi

On 4/27/2023 3:19 PM, Yao, Jiewen wrote:

Thanks Nhi, to provide the fix.

The UEFI specification 
(https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html) 
defines below error code.

#define EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED 0x0001
#define EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED 0x0002
#define EFI_IMAGE_EXECUTION_AUTH_SIG_NOT_FOUND  0x0003
#define EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND  0x0004

1) EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED means
An image certificate is in the forbidden database, or
A digest of an image certifcate is in the forbidden database, or
The image signature check failed.

However, the code only contains below as forbidden database check:

 if (IsForbiddenByDbx (AuthData, AuthDataSize)) {
   Action = EFI_IMAGE_EXECUTION_AUTH_SIG_FAILED;
   IsVerified = FALSE;
   break;
 }

The image signature check fail missed the Action. (remaining issue ?)

2) EFI_IMAGE_EXECUTION_AUTH_SIG_PASSED means
An image certifcate is in authroized database. (or)
The image digest is in the authorized database.

However, I cannot find the code to set the value in the code. (remaining issue 
?)

3) EFI_IMAGE_EXECUTION_AUTH_SIG_NOT_FOUND means
the image certificate is not found in the authorized database, and
the image digest is not in the authorized database.

It is fixed in this patch. Thank you!

4) EFI_IMAGE_EXECUTION_AUTH_SIG_FOUND means
The image has at least one certificate, and the image digest is in the 
forbidden database.

The code is there.


Would you please double check, if we have the remaining issue in 1) and 2)?





-Original Message-
From: Nhi Pham 
Sent: Wednesday, April 12, 2023 5:22 PM
To: devel@edk2.groups.io; Yao, Jiewen ; Wang,
Jian J ; Xu, Min M 
Cc: patc...@amperecomputing.com; Nhi Pham

Subject: [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Add
AUTH_SIG_NOT_FOUND Action

Add the AUTH_SIG_NOT_FOUND Action to the Image Execution Info Table
when the Image is signed but signature is not allowed by DB and the
hash of image is not found in DB/DBX.

This is documented in the UEFI spec 2.10, table 32.5.

This issue is found by the SIE SCT with the error message as follows:
SecureBoot - TestImage1.bin in Image Execution Info Table with
SIG_NOT_FOUND. --FAILURE
B3A670AA-0FBA-48CA-9D01-0EE9700965A9
SctPkg/TestCase/UEFI/EFI/RuntimeServices/SecureBoot/BlackBoxTest/
ImageLoadingBBTest.c:1079:Status Success

Signed-off-by: Nhi Pham 
---
  SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c | 1
+
  1 file changed, 1 insertion(+)

diff --git
a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
index b3d40c21e975..5d8dbd546879 100644
---
a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
+++
b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
@@ -1993,6 +1993,7 @@ DxeImageVerificationHandler (
if (!EFI_ERROR (DbStatus) && IsFound) {

  IsVerified = TRUE;

} else {

+Action = EFI_IMAGE_EXECUTION_AUTH_SIG_NOT_FOUND;

  DEBUG ((DEBUG_INFO, "DxeImageVerificationLib: Image is signed but
signature is not allowed by DB and %s hash of image is not found in
DB/DBX.\n", mHashTypeStr));

}

  }

--
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#103735): https://edk2.groups.io/g/devel/message/103735
Mute This Topic: https://groups.io/mt/98215665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Add AUTH_SIG_NOT_FOUND Action

[Nhi Pham via groups.io]

Thanks Min.

Could you help merge this patch to edk2?

Regards,

Nhi

On 4/26/2023 2:54 PM, Xu, Min M wrote:

It's good to me.
Reviewed-by: Min Xu 

Thanks


-Original Message-
From: Nhi Pham 
Sent: Thursday, April 20, 2023 11:49 AM
To: Xu, Min M ; devel@edk2.groups.io;
n...@os.amperecomputing.com; Yao, Jiewen ; Wang,
Jian J 
Cc: patc...@amperecomputing.com
Subject: Re: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib:
Add AUTH_SIG_NOT_FOUND Action

Hi Min,

This SEI test passes:

SecureBoot - TestImage2.bin in Image Execution Info Table with
SIG_NOT_FOUND. -- PASS
00C3C2F2-39D5-4D35-B7E7-587CA0F3CB75
SctPkg/TestCase/UEFI/EFI/RuntimeServices/SecureBoot/BlackBoxTest/ImageLoa
dingBBTest.c:1103:Status
- Success

The test image binary is different to the one in the commit message due to some
bug fixes in the SEI test suite. The right test case to catch this bug is 
00C3C2F2-
39D5-4D35-B7E7-587CA0F3CB75

You can check the test code at
https://github.com/ARM-software/bbr-acs/blob/main/bbsr/sct-
tests/SecureBoot/BlackBoxTest/ImageLoadingBBTest.c

Thanks,

Nhi

On 4/19/2023 6:20 AM, Xu, Min M wrote:

On Friday, April 14, 2023 1:18 PM, Nhi Pham wrote:

Hi,

Ping for reviewing.

Let me know if I need anything for this patch.

Do you test the change and what's the test result? Can you provide the

validation result?

Thanks
Min



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#103693): https://edk2.groups.io/g/devel/message/103693
Mute This Topic: https://groups.io/mt/98215665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Add AUTH_SIG_NOT_FOUND Action

[Nhi Pham via groups.io]

Hi Min,

This SEI test passes:

SecureBoot - TestImage2.bin in Image Execution Info Table with 
SIG_NOT_FOUND. -- PASS

00C3C2F2-39D5-4D35-B7E7-587CA0F3CB75
SctPkg/TestCase/UEFI/EFI/RuntimeServices/SecureBoot/BlackBoxTest/ImageLoadingBBTest.c:1103:Status 
- Success


The test image binary is different to the one in the commit message due 
to some bug fixes in the SEI test suite. The right test case to catch 
this bug is 00C3C2F2-39D5-4D35-B7E7-587CA0F3CB75


You can check the test code at 
https://github.com/ARM-software/bbr-acs/blob/main/bbsr/sct-tests/SecureBoot/BlackBoxTest/ImageLoadingBBTest.c


Thanks,

Nhi

On 4/19/2023 6:20 AM, Xu, Min M wrote:

On Friday, April 14, 2023 1:18 PM, Nhi Pham wrote:

Hi,

Ping for reviewing.

Let me know if I need anything for this patch.

Do you test the change and what's the test result? Can you provide the 
validation result?

Thanks
Min



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#103271): https://edk2.groups.io/g/devel/message/103271
Mute This Topic: https://groups.io/mt/98215665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Add AUTH_SIG_NOT_FOUND Action

[Nhi Pham via groups.io]

Hi,

Ping for reviewing.

Let me know if I need anything for this patch.

Thanks,

Nhi

On 4/12/2023 4:21 PM, Nhi Pham wrote:

Add the AUTH_SIG_NOT_FOUND Action to the Image Execution Info Table
when the Image is signed but signature is not allowed by DB and the
hash of image is not found in DB/DBX.

This is documented in the UEFI spec 2.10, table 32.5.

This issue is found by the SIE SCT with the error message as follows:
SecureBoot - TestImage1.bin in Image Execution Info Table with
SIG_NOT_FOUND. --FAILURE
B3A670AA-0FBA-48CA-9D01-0EE9700965A9
SctPkg/TestCase/UEFI/EFI/RuntimeServices/SecureBoot/BlackBoxTest/
ImageLoadingBBTest.c:1079:Status Success

Signed-off-by: Nhi Pham 
---
  SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c | 1 +
  1 file changed, 1 insertion(+)

diff --git 
a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c 
b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
index b3d40c21e975..5d8dbd546879 100644
--- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
+++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
@@ -1993,6 +1993,7 @@ DxeImageVerificationHandler (
if (!EFI_ERROR (DbStatus) && IsFound) {

  IsVerified = TRUE;

} else {

+Action = EFI_IMAGE_EXECUTION_AUTH_SIG_NOT_FOUND;

  DEBUG ((DEBUG_INFO, "DxeImageVerificationLib: Image is signed but 
signature is not allowed by DB and %s hash of image is not found in DB/DBX.\n", 
mHashTypeStr));

}

  }




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102965): https://edk2.groups.io/g/devel/message/102965
Mute This Topic: https://groups.io/mt/98215665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Add AUTH_SIG_NOT_FOUND Action

[Nhi Pham via groups.io]

Add the AUTH_SIG_NOT_FOUND Action to the Image Execution Info Table
when the Image is signed but signature is not allowed by DB and the
hash of image is not found in DB/DBX.

This is documented in the UEFI spec 2.10, table 32.5.

This issue is found by the SIE SCT with the error message as follows:
SecureBoot - TestImage1.bin in Image Execution Info Table with
SIG_NOT_FOUND. --FAILURE
B3A670AA-0FBA-48CA-9D01-0EE9700965A9
SctPkg/TestCase/UEFI/EFI/RuntimeServices/SecureBoot/BlackBoxTest/
ImageLoadingBBTest.c:1079:Status Success

Signed-off-by: Nhi Pham 
---
 SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c 
b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
index b3d40c21e975..5d8dbd546879 100644
--- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
+++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
@@ -1993,6 +1993,7 @@ DxeImageVerificationHandler (
   if (!EFI_ERROR (DbStatus) && IsFound) {

 IsVerified = TRUE;

   } else {

+Action = EFI_IMAGE_EXECUTION_AUTH_SIG_NOT_FOUND;

 DEBUG ((DEBUG_INFO, "DxeImageVerificationLib: Image is signed but 
signature is not allowed by DB and %s hash of image is not found in DB/DBX.\n", 
mHashTypeStr));

   }

 }

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102885): https://edk2.groups.io/g/devel/message/102885
Mute This Topic: https://groups.io/mt/98215665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v2 0/9] Support Ampere Altra Max processor

[Nhi Pham via groups.io]

Thanks a lot Leif for the quick review and merging.

Best regards,

Nhi

On 3/29/2023 11:07 PM, Leif Lindholm wrote:

Hi Nhi,

Thanks - this was a lot easier to review.
For the series:
Reviewed-by: Leif Lindholm 
Pushed as 4811c37ae347..d8d167f11ac5.

/
 Leif

On Wed, Mar 29, 2023 at 11:32:37 +0700, Nhi Pham wrote:

This patchset adds support for Ampere Altra Max processor and updates for some
bugfixes.

Changes since v1:
   + Improved readability per Leif's feedback, such as: Add helper functions.
   split out the supports, bugfixes, and code refactor.

Tinh Nguyen (1):
   JadePkg: ACPI: Support ACPI tables for Ampere Altra Max

Vu Nguyen (8):
   AmpereAltraPkg: Correct PCIe Devmap
   AmpereAltraPkg: Correct PCIe memory attribute
   JadePkg: PCIe: Add delay after releasing PERST
   AmpereAltraPkg: Update Ampere specific platform PCIe core
   AmpereAltraPkg: Update Ampere Core/Cluster profile
   Ampere: PCIe: Add PHY preset NVParams for Ampere Altra Max
   Ampere: PCIe: Add support for Ampere Altra Max
   AmpereAltraPkg: Support get SubNUMA node region for Ampere silicons

  .../AmpereAltraPkg/AmpereAltraPkg.dsc.inc |6 +-
  Platform/Ampere/JadePkg/Jade.dsc  |3 +-
  Platform/Ampere/JadePkg/Jade.fdf  |3 +-
  .../JadePkg/Ac02AcpiTables/Ac02AcpiTables.inf |   20 +
  .../Include/Library/AmpereCpuLib.h|   31 +-
  .../AmpereAltraPkg/Include/NVParamDef.h   |   36 +-
  .../AmpereAltraPkg/Include/Platform/Ac01.h|7 +-
  .../Library/Ac01PcieLib/PcieCore.h|8 +-
  .../Drivers/AcpiPlatformDxe/AcpiMadt.c|  105 +-
  .../Drivers/AcpiPlatformDxe/AcpiPlatformDxe.c |   10 +-
  .../Library/BoardPcieLib/BoardPcieLib.c   |   83 +-
  .../Drivers/PcieInitPei/PcieInitPei.c |  133 +-
  .../Drivers/PcieInitPei/RootComplexNVParam.c  |  344 +-
  .../Library/Ac01PcieLib/PcieCore.c|  150 +-
  .../Library/AmpereCpuLib/AmpereCpuLibCommon.c |  243 +-
  .../Ampere/JadePkg/Ac02AcpiTables/CPU-S0.asi  | 6345 +
  .../Ampere/JadePkg/Ac02AcpiTables/CPU-S1.asi  | 6345 +
  .../Ampere/JadePkg/Ac02AcpiTables/CPU.asi |  152 +
  .../JadePkg/Ac02AcpiTables/CommonDevices.asi  |  513 ++
  .../Ampere/JadePkg/Ac02AcpiTables/Dsdt.asl|   26 +
  .../JadePkg/Ac02AcpiTables/PCI-PDRC.asi   |  217 +
  .../JadePkg/Ac02AcpiTables/PCI-S0.Rca01.asi   |  669 ++
  .../Ampere/JadePkg/Ac02AcpiTables/PCI-S0.asi  | 2041 ++
  .../Ampere/JadePkg/Ac02AcpiTables/PCI-S1.asi  | 2051 ++
  .../Ampere/JadePkg/Ac02AcpiTables/PMU-S0.asi  | 1292 
  .../Ampere/JadePkg/Ac02AcpiTables/PMU-S1.asi  | 1292 
  .../Ampere/JadePkg/Ac02AcpiTables/PMU.asi |   10 +
  27 files changed, 21731 insertions(+), 404 deletions(-)
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/Ac02AcpiTables.inf
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU-S0.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU-S1.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CommonDevices.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/Dsdt.asl
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-PDRC.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S0.Rca01.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S0.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S1.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU-S0.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU-S1.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU.asi

--
2.25.1




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102128): https://edk2.groups.io/g/devel/message/102128
Mute This Topic: https://groups.io/mt/97922247/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 0/2] Support Ampere Altra Max processor

[Nhi Pham via groups.io]

Hi Leif,

Sorry to have kept you waiting. I was not able to send the v2 out sooner 
than I wanted as the large refactor changes has been well-tested. I have 
just sent the v2. I hope all your comments are addressed.


Thanks so much.

Nhi

On 1/13/2023 11:25 AM, Nhi Pham wrote:

This patchset adds support for Ampere Altra Max processor.

Tinh Nguyen (1):
   JadePkg: ACPI: Support ACPI tables for Ampere Altra Max

Vu Nguyen (1):
   Ampere: PCIe: Add support for Ampere Altra Max

  .../AmpereAltraPkg/AmpereAltraPkg.dsc.inc |6 +-
  Platform/Ampere/JadePkg/Jade.dsc  |3 +-
  Platform/Ampere/JadePkg/Jade.fdf  |3 +-
  .../JadePkg/Ac02AcpiTables/Ac02AcpiTables.inf |   20 +
  .../Include/Library/AmpereCpuLib.h|   31 +-
  .../AmpereAltraPkg/Include/NVParamDef.h   |   64 +-
  .../AmpereAltraPkg/Include/Platform/Ac01.h|5 +-
  .../Library/Ac01PcieLib/PcieCore.h|8 +-
  .../Drivers/AcpiPlatformDxe/AcpiMadt.c|  103 +-
  .../Drivers/AcpiPlatformDxe/AcpiPlatformDxe.c |   10 +-
  .../Library/BoardPcieLib/BoardPcieLib.c   |   63 +-
  .../Drivers/PcieInitPei/PcieInitPei.c |   16 +-
  .../Drivers/PcieInitPei/RootComplexNVParam.c  |  101 +-
  .../Library/Ac01PcieLib/PcieCore.c|  150 +-
  .../Library/AmpereCpuLib/AmpereCpuLibCommon.c |  243 +-
  .../Ampere/JadePkg/Ac02AcpiTables/CPU-S0.asi  | 6345 +
  .../Ampere/JadePkg/Ac02AcpiTables/CPU-S1.asi  | 6345 +
  .../Ampere/JadePkg/Ac02AcpiTables/CPU.asi |  152 +
  .../JadePkg/Ac02AcpiTables/CommonDevices.asi  |  670 ++
  .../Ampere/JadePkg/Ac02AcpiTables/Dsdt.asl|   39 +
  .../JadePkg/Ac02AcpiTables/PCI-PDRC.asi   |  217 +
  .../JadePkg/Ac02AcpiTables/PCI-S0.Rca01.asi   |  669 ++
  .../Ampere/JadePkg/Ac02AcpiTables/PCI-S0.asi  | 2041 ++
  .../Ampere/JadePkg/Ac02AcpiTables/PCI-S1.asi  | 2051 ++
  .../Ampere/JadePkg/Ac02AcpiTables/PMU-S0.asi  | 1292 
  .../Ampere/JadePkg/Ac02AcpiTables/PMU-S1.asi  | 1292 
  .../Ampere/JadePkg/Ac02AcpiTables/PMU.asi |   10 +
  27 files changed, 21699 insertions(+), 250 deletions(-)
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/Ac02AcpiTables.inf
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU-S0.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU-S1.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CommonDevices.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/Dsdt.asl
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-PDRC.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S0.Rca01.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S0.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S1.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU-S0.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU-S1.asi
  create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU.asi




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102097): https://edk2.groups.io/g/devel/message/102097
Mute This Topic: https://groups.io/mt/96240126/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 8/9] AmpereAltraPkg: Support get SubNUMA node region for Ampere silicons

[Nhi Pham via groups.io]

From: Vu Nguyen 

This change helps to update the following:
- Add logic to get SubNUMA node region for Ampere silicons
  (Altra and Altra Max processor) as a common API in AmpereCpuLibCommon.
- Leverage the added API of AmpereCpuLibCommon accordingly.

Signed-off-by: Nhi Pham 
---
 .../Include/Library/AmpereCpuLib.h|  31 +--
 .../Drivers/AcpiPlatformDxe/AcpiMadt.c| 105 ++--
 .../Library/AmpereCpuLib/AmpereCpuLibCommon.c | 243 --
 3 files changed, 205 insertions(+), 174 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Include/Library/AmpereCpuLib.h 
b/Silicon/Ampere/AmpereAltraPkg/Include/Library/AmpereCpuLib.h
index 9355e6cc7c62..94944cbe3abe 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Include/Library/AmpereCpuLib.h
+++ b/Silicon/Ampere/AmpereAltraPkg/Include/Library/AmpereCpuLib.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -16,11 +16,6 @@
 #define MONOLITIC_NUM_OF_REGION1
 #define HEMISPHERE_NUM_OF_REGION   2
 #define QUADRANT_NUM_OF_REGION 4
-#define SUBNUMA_CPM_REGION_SIZE4
-#define NUM_OF_CPM_PER_MESH_ROW8
-
-#define CPM_PER_ROW_OFFSET(CpmId)  ((CpmId) % NUM_OF_CPM_PER_MESH_ROW)
-#define CPM_ROW_NUMBER(CpmId)  ((CpmId) / NUM_OF_CPM_PER_MESH_ROW)
 
 #define SOCKET_ID(CpuId)   ((CpuId) / (PLATFORM_CPU_MAX_CPM * 
PLATFORM_CPU_NUM_CORES_PER_CPM))
 #define CLUSTER_ID(CpuId)  (((CpuId) / 
PLATFORM_CPU_NUM_CORES_PER_CPM) % PLATFORM_CPU_MAX_CPM)
@@ -65,6 +60,17 @@ CpuGetVoltage (
   UINT8 Socket
   );
 
+/**
+  Get CPU Core order number.
+
+  @return   UINT8  The order number.
+
+**/
+UINT32 *
+CpuGetCoreOrder (
+  VOID
+  );
+
 /**
   Get the SubNUMA mode.
 
@@ -183,19 +189,6 @@ GetMaximumNumberOfCores (
   VOID
   );
 
-/**
-  Get the maximum number of CPM per socket. This number
-  should be the same for all sockets.
-
-  @return   UINT32  Maximum number of CPM.
-
-**/
-UINT16
-EFIAPI
-GetMaximumNumberOfCPMs (
-  VOID
-  );
-
 /**
   Get the number of active cores of a sockets.
 
diff --git a/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiMadt.c 
b/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiMadt.c
index 419ce578e452..db1f96029f46 100644
--- a/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiMadt.c
+++ b/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiMadt.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -65,74 +65,8 @@ EFI_ACPI_6_3_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER 
MADTTableHeaderTemplate = {
 ),
 };
 
-UINT32 Ac01CoreOrderMonolithic[PLATFORM_CPU_MAX_CPM * 
PLATFORM_CPU_NUM_CORES_PER_CPM] = {
-  36, 52, 40, 56, 32, 48, 44, 60,
-  20, 68, 24, 72, 16, 64, 28, 76,
-  4, 8, 0, 12, 38, 54, 42, 58,
-  34, 50, 46, 62, 22, 70, 26, 74,
-  18, 66, 30, 78, 6, 10, 2, 14,
-  37, 53, 41, 57, 33, 49, 45, 61,
-  21, 69, 25, 73, 17, 65, 29, 77,
-  5, 9, 1, 13, 39, 55, 43, 59,
-  35, 51, 47, 63, 23, 71, 27, 75,
-  19, 67, 31, 79, 7, 11, 3, 15,
-};
-
-UINT32 Ac01CoreOrderHemisphere[PLATFORM_CPU_MAX_CPM * 
PLATFORM_CPU_NUM_CORES_PER_CPM] = {
-  32, 48, 16, 64, 36, 52, 0, 20,
-  68, 4, 34, 50, 18, 66, 38, 54,
-  2, 22, 70, 6, 33, 49, 17, 65,
-  37, 53, 1, 21, 69, 5, 35, 51,
-  19, 67, 39, 55, 3, 23, 71, 7,
-  44, 60, 28, 76, 40, 56, 12, 24,
-  72, 8, 46, 62, 30, 78, 42, 58,
-  14, 26, 74, 10, 45, 61, 29, 77,
-  41, 57, 13, 25, 73, 9, 47, 63,
-  31, 79, 43, 59, 15, 27, 75, 11,
-};
-
-UINT32 Ac01CoreOrderQuadrant[PLATFORM_CPU_MAX_CPM * 
PLATFORM_CPU_NUM_CORES_PER_CPM] = {
-  16, 32, 0, 20, 4, 18, 34, 2,
-  22, 6, 17, 33, 1, 21, 5, 19,
-  35, 3, 23, 7, 48, 64, 52, 68,
-  36, 50, 66, 54, 70, 38, 49, 65,
-  53, 69, 37, 51, 67, 55, 71, 39,
-  28, 44, 12, 24, 8, 30, 46, 14,
-  26, 10, 29, 45, 13, 25, 9, 31,
-  47, 15, 27, 11, 60, 76, 56, 72,
-  40, 62, 78, 58, 74, 42, 61, 77,
-  57, 73, 41, 63, 79, 59, 75, 43,
-};
-
 EFI_ACPI_6_3_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER *MadtTablePointer;
 
-UINT32 *
-CpuGetCoreOrder (
-  VOID
-  )
-{
-  UINT8  SubNumaMode;
-
-  SubNumaMode = CpuGetSubNumaMode ();
-  switch (SubNumaMode) {
-  case SUBNUMA_MODE_MONOLITHIC:
-return (UINT32 *)
-
-  case SUBNUMA_MODE_HEMISPHERE:
-return (UINT32 *)
-
-  case SUBNUMA_MODE_QUADRANT:
-return (UINT32 *)
-
-  default:
-// Should never reach here
-ASSERT (FALSE);
-return NULL;
-  }
-
-  return NULL;
-}
-
 UINT32
 AcpiInstallMadtProcessorNode (
   VOID   *EntryPointer,
@@ -245,6 +179,7 @@ AcpiInstallMadtTable (
   INTN   Index;
   EFI_STATUS Status;
   UINTN  Size;
+  UINTN  Length;
   UINT32 *CoreOrder;
   UINT32   

[edk2-devel] [edk2-platforms][PATCH v2 7/9] Ampere: PCIe: Add support for Ampere Altra Max

[Nhi Pham via groups.io]

From: Vu Nguyen 

This updates the platform specific PCIe modules to
add support for Ampere Altra Max processor which
features 128 PCIe Gen4 lanes (distributed across
eight x16 RCAs) using 32 controllers.

Signed-off-by: Nhi Pham 
---
 .../Library/BoardPcieLib/BoardPcieLib.c   |  75 +++-
 .../Drivers/PcieInitPei/PcieInitPei.c | 131 ---
 .../Drivers/PcieInitPei/RootComplexNVParam.c  | 344 +++---
 3 files changed, 364 insertions(+), 186 deletions(-)

diff --git a/Platform/Ampere/JadePkg/Library/BoardPcieLib/BoardPcieLib.c 
b/Platform/Ampere/JadePkg/Library/BoardPcieLib/BoardPcieLib.c
index 5041eb726288..bb69587db54f 100644
--- a/Platform/Ampere/JadePkg/Library/BoardPcieLib/BoardPcieLib.c
+++ b/Platform/Ampere/JadePkg/Library/BoardPcieLib/BoardPcieLib.c
@@ -38,6 +38,54 @@ BoardPcieReleaseAllPerst (
   MicroSecondDelay (PCIE_PERST_DELAY);
 }
 
+EFI_STATUS
+GetGpioGroup (
+  IN  UINT8 RootComplexId,
+  IN  UINT8 PcieIndex,
+  OUT UINT32 *GpioGroupVal
+  )
+{
+  /* Ampere Altra Max RootComplex->ID: 4:7 */
+  if (PcieIndex < 2) {
+switch (RootComplexId) {
+  case 4:
+*GpioGroupVal = 34 - (PcieIndex * 2);
+break;
+  case 5:
+*GpioGroupVal = 38 - (PcieIndex * 2);
+break;
+  case 6:
+*GpioGroupVal = 30 - (PcieIndex * 2);
+break;
+  case 7:
+*GpioGroupVal = 26 - (PcieIndex * 2);
+break;
+  default:
+return EFI_INVALID_PARAMETER;
+}
+  } else {
+/* Ampere Altra Max RootComplex->ID: 4:7 */
+switch (RootComplexId) {
+  case 4:
+*GpioGroupVal = 46 - ((PcieIndex - 2) * 2);
+break;
+  case 5:
+*GpioGroupVal = 42 - ((PcieIndex - 2) * 2);
+break;
+  case 6:
+*GpioGroupVal = 18 - ((PcieIndex - 2) * 2);
+break;
+  case 7:
+*GpioGroupVal = 22 - ((PcieIndex - 2) * 2);
+break;
+  default:
+return EFI_INVALID_PARAMETER;
+}
+  }
+
+  return EFI_SUCCESS;
+}
+
 /**
   Assert PERST of PCIe controller
 
@@ -56,15 +104,28 @@ BoardPcieAssertPerst (
   IN BOOLEAN   IsPullToHigh
   )
 {
-  UINT32 GpioGroupVal, Val, GpioIndex, GpioPin;
+  UINT32 GpioGroupVal;
+  UINT32 Val;
+  UINT32 GpioIndex;
+  UINT32 GpioPin;
+  EFI_STATUS Status;
 
   if (!IsPullToHigh) {
 if (RootComplex->Type == RootComplexTypeA) {
-  //
-  // RootComplexTypeA: RootComplex->ID: 0->3 ; PcieIndex: 0->3
-  //
-  GpioGroupVal = RCA_MAX_PERST_GROUPVAL - PcieIndex
- - RootComplex->ID * MaxPcieControllerOfRootComplexA;
+  if (RootComplex->ID < MaxPcieControllerOfRootComplexA) {
+/* Ampere Altra: 4 */
+//
+// RootComplexTypeA: RootComplex->ID: 0->3 ; PcieIndex: 0->3
+//
+GpioGroupVal = RCA_MAX_PERST_GROUPVAL - PcieIndex
+   - RootComplex->ID * MaxPcieControllerOfRootComplexA;
+  } else {
+Status = GetGpioGroup (RootComplex->ID, PcieIndex, );
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Invalid Root Complex ID %d\n", 
RootComplex->ID));
+  return Status;
+}
+  }
 } else {
   //
   // RootComplexTypeB: RootComplex->ID: 4->7 ; PcieIndex: 0->7
@@ -117,5 +178,5 @@ BoardPcieGetSegmentNumber (
 return Ac01BoardSegment[RootComplex->Socket][RootComplex->ID];
   }
 
-  return DEFAULT_SEGMENT_NUMBER;
+  return (RootComplex->ID - 2);
 }
diff --git a/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/PcieInitPei.c 
b/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/PcieInitPei.c
index 76d3f90aa833..598a2e64d02f 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/PcieInitPei.c
+++ b/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/PcieInitPei.c
@@ -40,61 +40,33 @@ STATIC UINT64   
mMmio32Size1P[AC01_PCIE_MAX_ROOT_COMPLEX]= {
 STATIC UINT64   mMmioBase[AC01_PCIE_MAX_ROOT_COMPLEX]= 
{ AC01_PCIE_MMIO_BASE_LIST };
 STATIC UINT64   mMmioSize[AC01_PCIE_MAX_ROOT_COMPLEX]= 
{ AC01_PCIE_MMIO_SIZE_LIST };
 
+AC01_ROOT_COMPLEX_TYPE
+GetRootComplexType (
+  UINT8 RootComplexId
+  )
+{
+  if (IsAc01Processor ()) {
+return (RootComplexId < MaxRootComplexA) ? RootComplexTypeA : 
RootComplexTypeB;
+  }
+
+  return RootComplexTypeA;
+}
+
 VOID
-BuildRootComplexData (
-  VOID
+ConfigureRootComplex (
+  BOOLEAN   IsConfigFound,
+  ROOT_COMPLEX_CONFIG_VARSTORE_DATA RootComplexConfig
   )
 {
-  AC01_ROOT_COMPLEX*RootComplex;
-  BOOLEAN  ConfigFound;
-  EFI_PEI_READ_ONLY_VARIABLE2_PPI  *VariablePpi;
-  EFI_STATUS   Status;
-  ROOT_COMPLEX_CONFIG_VARSTORE_DATARootComplexConfig;
-  UINT8RCIndex;
-  UINT8PcieIndex;
-  UINTNDataSize;
-
-  ConfigFound = FALSE;
-
-  //
-  // Get the Root Complex config from NVRAM

[edk2-devel] [edk2-platforms][PATCH v2 6/9] Ampere: PCIe: Add PHY preset NVParams for Ampere Altra Max

[Nhi Pham via groups.io]

From: Vu Nguyen 

This adds PHY preset NVParams definition for each Root complex
to support Ampere Altra Max platform.

Signed-off-by: Nhi Pham 
---
 .../AmpereAltraPkg/Include/NVParamDef.h   | 36 +--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h 
b/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h
index 3259fa1ea45c..4326fddfe977 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h
+++ b/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h
@@ -29,7 +29,7 @@
   As each non-volatile parameter requires 8 bytes, there is a total of 8K
   parameters.
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -523,7 +523,39 @@
 #define NV_SI_RO_BOARD_RAS_DDR_CE_TH1 ((205 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x01F4 */
 #define NV_SI_RO_BOARD_RAS_DDR_CE_TH2 ((206 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x1388 */
 #define NV_SI_RO_BOARD_RAS_DDR_CE_THC ((207 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
-#define NV_PMPRO_REGION4_LOAD_END 
(NV_SI_RO_BOARD_RAS_DDR_CE_THC)
+#define NV_SI_RO_BOARD_MQ_SX_RCA0_TXRX_20GPRESET  ((208 * 8) + 
NV_BOARD_PARAM_START)
+#define NV_SI_RO_BOARD_MQ_SX_RCA1_TXRX_20GPRESET  ((209 * 8) + 
NV_BOARD_PARAM_START)
+#define NV_SI_RO_BOARD_MQ_SX_RCA0_TXRX_25GPRESET  ((210 * 8) + 
NV_BOARD_PARAM_START)
+#define NV_SI_RO_BOARD_MQ_SX_RCA1_TXRX_25GPRESET  ((211 * 8) + 
NV_BOARD_PARAM_START)
+#define NV_SI_RO_BOARD_MQ_S0_RCA0_TXRX_G3PRESET   ((212 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S0_RCA1_TXRX_G3PRESET   ((213 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S0_RCA2_TXRX_G3PRESET   ((214 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S0_RCA3_TXRX_G3PRESET   ((215 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S0_RCA4_TXRX_G3PRESET   ((216 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S0_RCA5_TXRX_G3PRESET   ((217 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S0_RCA6_TXRX_G3PRESET   ((218 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S0_RCA7_TXRX_G3PRESET   ((219 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S1_RCA2_TXRX_G3PRESET   ((220 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S1_RCA3_TXRX_G3PRESET   ((221 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S1_RCA4_TXRX_G3PRESET   ((222 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S1_RCA5_TXRX_G3PRESET   ((223 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S1_RCA6_TXRX_G3PRESET   ((224 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S1_RCA7_TXRX_G3PRESET   ((225 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_MQ_S0_RCA0_TXRX_G4PRESET   ((226 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S0_RCA1_TXRX_G4PRESET   ((227 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S0_RCA2_TXRX_G4PRESET   ((228 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S0_RCA3_TXRX_G4PRESET   ((229 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S0_RCA4_TXRX_G4PRESET   ((230 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S0_RCA5_TXRX_G4PRESET   ((231 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S0_RCA6_TXRX_G4PRESET   ((232 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S0_RCA7_TXRX_G4PRESET   ((233 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S1_RCA2_TXRX_G4PRESET   ((234 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S1_RCA3_TXRX_G4PRESET   ((235 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S1_RCA4_TXRX_G4PRESET   ((236 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S1_RCA5_TXRX_G4PRESET   ((237 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define NV_SI_RO_BOARD_MQ_S1_RCA6_TXRX_G4PRESET   ((238 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
+#define 

[edk2-devel] [edk2-platforms][PATCH v2 5/9] AmpereAltraPkg: Update Ampere Core/Cluster profile

[Nhi Pham via groups.io]

From: Vu Nguyen 

This updates the number of cores and clusters to add support
for the Ampere Altra Max processor.

Signed-off-by: Nhi Pham 
---
 Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc  | 6 +++---
 Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h | 5 -
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc 
b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
index bf23edc50349..9275e0053af6 100644
--- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
+++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
@@ -1,6 +1,6 @@
 ## @file
 #
-# Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+# Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -410,8 +410,8 @@ [PcdsFixedAtBuild.common]
   #
   # Ampere Altra Core-Cluster profile
   #
-  gArmPlatformTokenSpaceGuid.PcdCoreCount|80
-  gArmPlatformTokenSpaceGuid.PcdClusterCount|40
+  gArmPlatformTokenSpaceGuid.PcdCoreCount|128
+  gArmPlatformTokenSpaceGuid.PcdClusterCount|64
 
   #
   # PL011 - Serial Terminal
diff --git a/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h 
b/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
index 0db3bfb62018..4bea14d7d2b6 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
+++ b/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -29,6 +29,9 @@
 //
 #define PLATFORM_CPU_MAX_NUM_CORES(PLATFORM_CPU_MAX_SOCKET * 
PLATFORM_CPU_MAX_CPM * PLATFORM_CPU_NUM_CORES_PER_CPM)
 
+#define MAX_AMPERE_ALTRA_CORES80
+#define MAX_AMPERE_ALTRA_MAX_CORES128
+
 //
 // Maximum number of memory region
 //
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102092): https://edk2.groups.io/g/devel/message/102092
Mute This Topic: https://groups.io/mt/97922252/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 4/9] AmpereAltraPkg: Update Ampere specific platform PCIe core

[Nhi Pham via groups.io]

From: Vu Nguyen 

This patch updates the following:
- Check End Point configuration space is accessible or
  not before getting its capability.
- Add new function to check PCIe card is present or not.
- Set CRS (Configuration Request Retry Status) to follow
  PCIe specifications.

Signed-off-by: Nhi Pham 
---
 .../Library/Ac01PcieLib/PcieCore.h|   8 +-
 .../Library/Ac01PcieLib/PcieCore.c| 150 ++
 2 files changed, 128 insertions(+), 30 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.h 
b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.h
index 1db8a68b3df4..a18fff7dbb75 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.h
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -39,6 +39,7 @@
 #define PIPE_CLOCK_TIMEOUT   2   // 20,000 us
 #define LTSSM_TRANSITION_TIMEOUT 10  // 100 ms in total
 #define EP_LINKUP_TIMEOUT(10 * 1000) // 10ms
+#define EP_LINKUP_EXTRA_TIMEOUT  (500 * 1000) // 500ms
 #define LINK_WAIT_INTERVAL_US50
 
 #define PFA_MODE_ENABLE  0
@@ -80,6 +81,7 @@
 #define AC01_PCIE_CORE_IRQ_ENABLE_REG   0x30
 #define AC01_PCIE_CORE_IRQ_EVENT_STAT_REG   0x38
 #define AC01_PCIE_CORE_BLOCK_EVENT_STAT_REG 0x3C
+#define AC01_PCIE_CORE_BUS_CONTROL_REG  0x40
 #define AC01_PCIE_CORE_RESET_REG0xC000
 #define AC01_PCIE_CORE_CLOCK_REG0xC004
 #define AC01_PCIE_CORE_MEM_READY_REG0xC104
@@ -87,6 +89,7 @@
 
 // AC01_PCIE_CORE_LINK_CTRL_REG
 #define LTSSMENB_SET(dst, src)  (((dst) & ~0x1) | (((UINT32) 
(src)) & 0x1))
+#define LTSSMENB_GET(dst)   ((dst) & (BIT0))
 #define   HOLD_LINK_TRAINING0
 #define   START_LINK_TRAINING   1
 #define DEVICETYPE_SET(dst, src)(((dst) & ~0xF0) | (((UINT32) 
(src) << 4) & 0xF0))
@@ -120,6 +123,9 @@
 // AC01_PCIE_CORE_BLOCK_EVENT_STAT_REG
 #define LINKUP_MASK  0x1
 
+// AC01_PCIE_CORE_BUS_CONTROL_REG
+#define BUS_CTL_CFG_UR_MASK  0x8
+
 // AC01_PCIE_CORE_RESET_REG
 #define DWC_PCIE_SET(dst, src)   (((dst) & ~0x1) | (((UINT32) (src)) & 0x1))
 #define   RESET_MASK 0x1
diff --git a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c 
b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
index ad648b1b9efd..855b094f7948 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -10,8 +10,10 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,6 +24,25 @@
 
 #include "PcieCore.h"
 
+VOID
+EnableDbiAccess (
+  AC01_ROOT_COMPLEX *RootComplex,
+  UINT32PcieIndex,
+  BOOLEAN   EnableDbi
+  );
+
+BOOLEAN
+EndpointCfgReady (
+  IN AC01_ROOT_COMPLEX  *RootComplex,
+  IN UINT8  PcieIndex,
+  IN UINT32 Timeout
+  );
+
+BOOLEAN
+PcieLinkUpCheck (
+  IN AC01_PCIE_CONTROLLER *Pcie
+  );
+
 /**
   Return the next extended capability base address
 
@@ -41,14 +62,38 @@ GetCapabilityBase (
 {
   BOOLEANIsExtCapability = FALSE;
   PHYSICAL_ADDRESS   CfgBase;
+  PHYSICAL_ADDRESS   Ret = 0;
+  PHYSICAL_ADDRESS   RootComplexCfgBase;
   UINT32 CapabilityId;
   UINT32 NextCapabilityPtr;
   UINT32 Val;
+  UINT32 RestoreVal;
 
-  if (IsRootComplex) {
-CfgBase = RootComplex->MmcfgBase + (RootComplex->Pcie[PcieIndex].DevNum << 
DEV_SHIFT);
-  } else {
+  RootComplexCfgBase = RootComplex->MmcfgBase + 
(RootComplex->Pcie[PcieIndex].DevNum << DEV_SHIFT);
+  if (!IsRootComplex) {
+// Allow programming to config space
+EnableDbiAccess (RootComplex, PcieIndex, TRUE);
+
+Val= MmioRead32 (RootComplexCfgBase + 
SEC_LAT_TIMER_SUB_BUS_SEC_BUS_PRI_BUS_REG);
+RestoreVal = Val;
+Val= SUB_BUS_SET (Val, DEFAULT_SUB_BUS);
+Val= SEC_BUS_SET (Val, RootComplex->Pcie[PcieIndex].DevNum);
+Val= PRIM_BUS_SET (Val, 0x0);
+MmioWrite32 (RootComplexCfgBase + 
SEC_LAT_TIMER_SUB_BUS_SEC_BUS_PRI_BUS_REG, Val);
 CfgBase = RootComplex->MmcfgBase + (RootComplex->Pcie[PcieIndex].DevNum << 
BUS_SHIFT);
+
+if (!EndpointCfgReady (RootComplex, PcieIndex, EP_LINKUP_TIMEOUT)) {
+  goto _CheckCapEnd;
+}
+  } else {
+CfgBase = RootComplexCfgBase;
+  }
+
+  // 

[edk2-devel] [edk2-platforms][PATCH v2 2/9] AmpereAltraPkg: Correct PCIe memory attribute

[Nhi Pham via groups.io]

From: Vu Nguyen 

This fixes the memory attribute of the first
RC Type B (RCB0).

Signed-off-by: Nhi Pham 
---
 Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h 
b/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
index d45688f88401..0db3bfb62018 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
+++ b/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
@@ -292,7 +292,7 @@
 //
 // DSDT RCB0 PCIe MMIO32 Attribute
 //
-#define AC01_PCIE_RCB0_QMEM_LIST 0x, 
0x0100, 0x0FFF, 0x, 0x0F00
+#define AC01_PCIE_RCB0_QMEM_LIST 0x, 
0x0800, 0x0FFF, 0x, 0x0800
 
 //
 // DSDT RCB1 PCIe MMIO32 Attribute
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102089): https://edk2.groups.io/g/devel/message/102089
Mute This Topic: https://groups.io/mt/97922249/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 3/9] JadePkg: PCIe: Add delay after releasing PERST

[Nhi Pham via groups.io]

From: Vu Nguyen 

According to PCIe specification, following exit from a Conventional Reset,
some devices may require additional time before they are able to respond
to Requests they receive, so this patch adds a delay after releasing the
PERST signal.

Signed-off-by: Nhi Pham 
---
 .../Ampere/JadePkg/Library/BoardPcieLib/BoardPcieLib.c| 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Platform/Ampere/JadePkg/Library/BoardPcieLib/BoardPcieLib.c 
b/Platform/Ampere/JadePkg/Library/BoardPcieLib/BoardPcieLib.c
index f49764097219..5041eb726288 100644
--- a/Platform/Ampere/JadePkg/Library/BoardPcieLib/BoardPcieLib.c
+++ b/Platform/Ampere/JadePkg/Library/BoardPcieLib/BoardPcieLib.c
@@ -2,7 +2,7 @@
   Pcie board specific driver to handle asserting PERST signal to Endpoint
   card. PERST asserting is via group of GPIO pins to CPLD as Platform 
Specification.
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -20,6 +20,8 @@
 #define RCB_MAX_PERST_GROUPVAL  46
 #define DEFAULT_SEGMENT_NUMBER  0x0F
 
+#define PCIE_PERST_DELAY  (100 * 1000)   // 100ms
+
 VOID
 BoardPcieReleaseAllPerst (
   IN UINT8 SocketId
@@ -32,6 +34,8 @@ BoardPcieReleaseAllPerst (
   for (GpioIndex = 0; GpioIndex < 6; GpioIndex++) {
 GpioModeConfig (GpioPin + GpioIndex, GpioConfigOutHigh);
   }
+
+  MicroSecondDelay (PCIE_PERST_DELAY);
 }
 
 /**
@@ -81,7 +85,7 @@ BoardPcieAssertPerst (
 }
 
 // Keep reset as low as 100 ms as specification
-MicroSecondDelay (100 * 1000);
+MicroSecondDelay (PCIE_PERST_DELAY);
   } else {
 BoardPcieReleaseAllPerst (RootComplex->Socket);
   }
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102090): https://edk2.groups.io/g/devel/message/102090
Mute This Topic: https://groups.io/mt/97922250/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 1/9] AmpereAltraPkg: Correct PCIe Devmap

[Nhi Pham via groups.io]

From: Vu Nguyen 

This corrects the high devmap of Root Complex (RC)
that should be fetched from a high bifurcation.

Signed-off-by: Nhi Pham 
---
 .../Ampere/AmpereAltraPkg/Drivers/PcieInitPei/PcieInitPei.c   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/PcieInitPei.c 
b/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/PcieInitPei.c
index 17f6112ea207..76d3f90aa833 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/PcieInitPei.c
+++ b/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/PcieInitPei.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -94,7 +94,7 @@ BuildRootComplexData (
 RootComplex = [RCIndex];
 RootComplex->Active = ConfigFound ? RootComplexConfig.RCStatus[RCIndex] : 
TRUE;
 RootComplex->DevMapLow = ConfigFound ? 
RootComplexConfig.RCBifurcationLow[RCIndex] : 0;
-RootComplex->DevMapHigh = ConfigFound ? 
RootComplexConfig.RCBifurcationLow[RCIndex] : 0;
+RootComplex->DevMapHigh = ConfigFound ? 
RootComplexConfig.RCBifurcationHigh[RCIndex] : 0;
 RootComplex->Socket = RCIndex / AC01_PCIE_MAX_RCS_PER_SOCKET;
 RootComplex->ID = RCIndex % AC01_PCIE_MAX_RCS_PER_SOCKET;
 RootComplex->CsrBase = mCsrBase[RCIndex];
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102088): https://edk2.groups.io/g/devel/message/102088
Mute This Topic: https://groups.io/mt/97922248/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 0/9] Support Ampere Altra Max processor

[Nhi Pham via groups.io]

This patchset adds support for Ampere Altra Max processor and updates for some
bugfixes.

Changes since v1:
  + Improved readability per Leif's feedback, such as: Add helper functions.
  split out the supports, bugfixes, and code refactor.

Tinh Nguyen (1):
  JadePkg: ACPI: Support ACPI tables for Ampere Altra Max

Vu Nguyen (8):
  AmpereAltraPkg: Correct PCIe Devmap
  AmpereAltraPkg: Correct PCIe memory attribute
  JadePkg: PCIe: Add delay after releasing PERST
  AmpereAltraPkg: Update Ampere specific platform PCIe core
  AmpereAltraPkg: Update Ampere Core/Cluster profile
  Ampere: PCIe: Add PHY preset NVParams for Ampere Altra Max
  Ampere: PCIe: Add support for Ampere Altra Max
  AmpereAltraPkg: Support get SubNUMA node region for Ampere silicons

 .../AmpereAltraPkg/AmpereAltraPkg.dsc.inc |6 +-
 Platform/Ampere/JadePkg/Jade.dsc  |3 +-
 Platform/Ampere/JadePkg/Jade.fdf  |3 +-
 .../JadePkg/Ac02AcpiTables/Ac02AcpiTables.inf |   20 +
 .../Include/Library/AmpereCpuLib.h|   31 +-
 .../AmpereAltraPkg/Include/NVParamDef.h   |   36 +-
 .../AmpereAltraPkg/Include/Platform/Ac01.h|7 +-
 .../Library/Ac01PcieLib/PcieCore.h|8 +-
 .../Drivers/AcpiPlatformDxe/AcpiMadt.c|  105 +-
 .../Drivers/AcpiPlatformDxe/AcpiPlatformDxe.c |   10 +-
 .../Library/BoardPcieLib/BoardPcieLib.c   |   83 +-
 .../Drivers/PcieInitPei/PcieInitPei.c |  133 +-
 .../Drivers/PcieInitPei/RootComplexNVParam.c  |  344 +-
 .../Library/Ac01PcieLib/PcieCore.c|  150 +-
 .../Library/AmpereCpuLib/AmpereCpuLibCommon.c |  243 +-
 .../Ampere/JadePkg/Ac02AcpiTables/CPU-S0.asi  | 6345 +
 .../Ampere/JadePkg/Ac02AcpiTables/CPU-S1.asi  | 6345 +
 .../Ampere/JadePkg/Ac02AcpiTables/CPU.asi |  152 +
 .../JadePkg/Ac02AcpiTables/CommonDevices.asi  |  513 ++
 .../Ampere/JadePkg/Ac02AcpiTables/Dsdt.asl|   26 +
 .../JadePkg/Ac02AcpiTables/PCI-PDRC.asi   |  217 +
 .../JadePkg/Ac02AcpiTables/PCI-S0.Rca01.asi   |  669 ++
 .../Ampere/JadePkg/Ac02AcpiTables/PCI-S0.asi  | 2041 ++
 .../Ampere/JadePkg/Ac02AcpiTables/PCI-S1.asi  | 2051 ++
 .../Ampere/JadePkg/Ac02AcpiTables/PMU-S0.asi  | 1292 
 .../Ampere/JadePkg/Ac02AcpiTables/PMU-S1.asi  | 1292 
 .../Ampere/JadePkg/Ac02AcpiTables/PMU.asi |   10 +
 27 files changed, 21731 insertions(+), 404 deletions(-)
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/Ac02AcpiTables.inf
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU-S0.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU-S1.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CommonDevices.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/Dsdt.asl
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-PDRC.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S0.Rca01.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S0.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S1.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU-S0.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU-S1.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU.asi

--
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102087): https://edk2.groups.io/g/devel/message/102087
Mute This Topic: https://groups.io/mt/97922247/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 2/2] JadePkg: ACPI: Support ACPI tables for Ampere Altra Max

[Nhi Pham via groups.io]

Hi Leif,

On 2/15/2023 7:03 PM, Leif Lindholm via groups.io wrote:

On Fri, Jan 13, 2023 at 11:25:17 +0700, Nhi Pham via groups.io wrote:

From: Tinh Nguyen 

This adds ACPI DSDT tables and updates ACPI MADT table
to support Ampere Altra Max processor.

Signed-off-by: Nhi Pham 

Ideally, I would like to see the refactoring of existing support split
up from the additions of new support.

/
 Leif


Thanks, Leif. I will try to split it out.

Best regards,

Nhi



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100482): https://edk2.groups.io/g/devel/message/100482
Mute This Topic: https://groups.io/mt/96240133/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/2] Ampere: PCIe: Add support for Ampere Altra Max

[Nhi Pham via groups.io]

Hi Leif,

Thanks for your reviewing. Most of your feedback is valid. I will fix 
them. There is a comment that need your more explanation.


Please see the inline reply for more details.

On 2/15/2023 6:59 PM, Leif Lindholm wrote:

On Fri, Jan 13, 2023 at 11:25:16 +0700, Nhi Pham wrote:

From: Vu Nguyen 

This updates the PCIe modules to add support for
Ampere Altra Max processor which features 128 PCIe
Gen4 lanes (distributed across eight x16 RCAs) using
32 controllers.

Signed-off-by: Nhi Pham 
---
  .../AmpereAltraPkg/Include/NVParamDef.h   |  64 ++--
  .../Library/Ac01PcieLib/PcieCore.h|   8 +-
  .../Library/BoardPcieLib/BoardPcieLib.c   |  63 +++-
  .../Drivers/PcieInitPei/PcieInitPei.c |  16 +-
  .../Drivers/PcieInitPei/RootComplexNVParam.c  | 101 +---
  .../Library/Ac01PcieLib/PcieCore.c| 150 +++---
  6 files changed, 333 insertions(+), 69 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h 
b/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h
index 3259fa1ea45c..4dfc353d2340 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h
+++ b/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h
@@ -29,7 +29,7 @@
As each non-volatile parameter requires 8 bytes, there is a total of 8K
parameters.
  
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.

+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
  
SPDX-License-Identifier: BSD-2-Clause-Patent
  
@@ -425,10 +425,10 @@

  #define NV_SI_RO_BOARD_S0_RCA5_CFG((107 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x02020202 */
  #define NV_SI_RO_BOARD_S0_RCA6_CFG((108 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x02020202 */
  #define NV_SI_RO_BOARD_S0_RCA7_CFG((109 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x02020003 */
-#define NV_SI_RO_BOARD_S0_RCA0_TXRX_G3PRESET  ((110 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA1_TXRX_G3PRESET  ((111 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA2_TXRX_G3PRESET  ((112 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA3_TXRX_G3PRESET  ((113 * 8) + 
NV_BOARD_PARAM_START)
+#define NV_SI_RO_BOARD_S0_RCA0_TXRX_G3PRESET  ((110 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA1_TXRX_G3PRESET  ((111 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA2_TXRX_G3PRESET  ((112 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA3_TXRX_G3PRESET  ((113 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */

Could you split the comment additions into a separate patch?
I think there are no functional changes to this file, but that is very
hard to determine.

Thanks, I will split it out.



  #define NV_SI_RO_BOARD_S0_RCB0A_TXRX_G3PRESET ((114 * 8) + 
NV_BOARD_PARAM_START)
  #define NV_SI_RO_BOARD_S0_RCB0B_TXRX_G3PRESET ((115 * 8) + 
NV_BOARD_PARAM_START)
  #define NV_SI_RO_BOARD_S0_RCB1A_TXRX_G3PRESET ((116 * 8) + 
NV_BOARD_PARAM_START)
@@ -437,10 +437,10 @@
  #define NV_SI_RO_BOARD_S0_RCB2B_TXRX_G3PRESET ((119 * 8) + 
NV_BOARD_PARAM_START)
  #define NV_SI_RO_BOARD_S0_RCB3A_TXRX_G3PRESET ((120 * 8) + 
NV_BOARD_PARAM_START)
  #define NV_SI_RO_BOARD_S0_RCB3B_TXRX_G3PRESET ((121 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA4_TXRX_G3PRESET  ((122 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA5_TXRX_G3PRESET  ((123 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA6_TXRX_G3PRESET  ((124 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA7_TXRX_G3PRESET  ((125 * 8) + 
NV_BOARD_PARAM_START)
+#define NV_SI_RO_BOARD_S0_RCA4_TXRX_G3PRESET  ((122 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA5_TXRX_G3PRESET  ((123 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA6_TXRX_G3PRESET  ((124 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA7_TXRX_G3PRESET  ((125 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
  #define NV_SI_RO_BOARD_S0_RCA0_TXRX_G4PRESET  ((126 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
  #define NV_SI_RO_BOARD_S0_RCA1_TXRX_G4PRESET  ((127 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
  #define NV_SI_RO_BOARD_S0_RCA2_TXRX_G4PRESET  ((128 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
@@ -462,8 +462,8 @@
  #define NV_SI_RO_BOARD_S1_RCA5_CFG((144 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x02020202 */
  #define NV_SI_RO_BOARD_S1_RCA6_CFG

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] AmpereAltraPkg: Remove MemoryAllocationLib in ArmPlatformLib

[Nhi Pham via groups.io]

Sorry, just a gentle ping Leif as you may have missed my previous email :)

On 1/17/2023 5:09 PM, Nhi Pham wrote:

Hi Ard and Leif,

Just a friendly ping on the patches recently posted.

Below are links to the patches including the new introduction to the 
Ampere Altra Max support that we need you to review and merge them in 
order:


1/ https://edk2.groups.io/g/devel/message/97671

2/ https://edk2.groups.io/g/devel/message/97670

3/ https://edk2.groups.io/g/devel/message/98277

4/ https://edk2.groups.io/g/devel/message/98435

5/ https://edk2.groups.io/g/devel/message/98436

Thanks,

Nhi

On 12/23/2022 9:37 PM, Ard Biesheuvel wrote:
On Wed, 21 Dec 2022 at 06:01, Nhi Pham  
wrote:

From: Tinh Nguyen 

PrePeiCore's Arm module just added a requirement to run all library
constructors that PrePeiCore uses. One of them is included in the
constructor of the ExtractGuidedSectionLib. This constructor will build
a HOB that is not supported "at this time" and causes an error.
We don't need to use this constructor because PrePeiCore doesn't
really need this library.

This is a workaround to avoid PrePeiCore module calling
ExtractGuidedSectionLib's constructor.

Signed-off-by: Nhi Pham 
---
.../AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf | 1 -
  1 file changed, 1 deletion(-)

diff --git 
a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf 
b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf 


index a4d29379198d..a61da278c705 100644
--- 
a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
+++ 
b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf

@@ -25,7 +25,6 @@ [LibraryClasses]
    ArmSmcLib
    HobLib
    IoLib
-  MemoryAllocationLib
    PL011UartLib
    PcdLib
    SerialPortLib

Hi,

Thanks for these patches - I will merge them shortly.

As an aside, do you have any news on the issue I reported recently
regarding SetTime() on Altra which crashes the system if
SetVirtualAddressMap() was not called?

https://lore.kernel.org/all/Y2o1hdZK9GGDVJsS@monolith.localdoman/



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99434): https://edk2.groups.io/g/devel/message/99434
Mute This Topic: https://groups.io/mt/95801452/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] AmpereAltraPkg: Update ArmPlatformLib to work with changed ARM_CORE_INFO

[Nhi Pham via groups.io]

Hi Rebecca,

++ Harb who can give more insights on this. FYI, the original concern is 
https://edk2.groups.io/g/devel/message/98482


On 1/18/2023 1:21 AM, Rebecca Cran wrote:

On 1/17/23 09:40, Ard Biesheuvel wrote:

On Tue, 17 Jan 2023 at 13:55, Rebecca Cran  wrote:

I was under the impression that this is becoming a more standard format?


If this is not defined in an ARM spec somewhere, we shouldn't add it
to ArmPkg at this point.


From what I've found, the ARM specs such as the Arm Architecture 
Reference Manual for A-profile architecture don't define the meaning 
of the affinity fields? That appears to be left up to the individual 
Arm core TRMs.



I think so. This might be silicon specific implementation.

Per Arm Armv8-A Architecture Registers 
(https://developer.arm.com/documentation/ddi0595/2021-12/AArch64-Registers/MPIDR-EL1--Multiprocessor-Affinity-Register), 
if I interpret correctly, the AFF0 will give core ID or thread ID based 
on the MT bit in the MPIDR register.


I think we should remove the following definitions particularly for 
getting core id and cluster in ArmPkg/Include/Library/ArmLib.h to avoid 
the confusion to others


#define ARM_CORE_MASK ARM_CORE_AFF0
#define ARM_CLUSTER_MASK  ARM_CORE_AFF1
#define GET_CORE_ID(MpId) ((MpId) & ARM_CORE_MASK)
#define GET_CLUSTER_ID(MpId)  (((MpId) & ARM_CLUSTER_MASK) >> 8)
#define GET_MPID(ClusterId, CoreId)   (((ClusterId) << 8) | (CoreId))
#define PRIMARY_CORE_ID   (PcdGet32(PcdArmPrimaryCore) & ARM_CORE_MASK)

And, should support GET_AFFx like

#define ARM_MPIDR_GET_AFF0(Mpid) ((Mpid) & ARM_CORE_AFF0)

For silicon specific usage, it can abstract them to proper IDs like

#define XXX_GET_CORE_ID(Mpid) ARM_MPIDR_GET_AFF0(Mpid)

Thanks,

Nhi


For example, the Cortex-X2 TRM says:

Affinity level 0. This is the affinity level that is most significant 
for determining PE behavior. Higher affinity
levels are increasingly less significant in determining PE behavior. 
The assigned value of the MPIDR.{Aff2,
Aff1, Aff0} or AArch64-MPIDR_EL1.{Aff3, Aff2, Aff1, Aff0} set of 
fields of each PE must be unique within the

system as a whole.
0b
Only one thread.


Affinity level 1. See the description of Aff0 for more information.
Value read from the CPUID configuration pins. Identification number 
for each CPU in an cluster counting from

zero.


Affinity level 2. See the description of Aff0 for more information.
The value will be determined by the CLUSTERIDAFF2 configuration pins.


Affinity level 3. See the description of Aff0 for more information.
The value will be determined by the CLUSTERIDAFF3 configuration pins.





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99342): https://edk2.groups.io/g/devel/message/99342
Mute This Topic: https://groups.io/mt/96240088/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] AmpereAltraPkg: Remove MemoryAllocationLib in ArmPlatformLib

[Nhi Pham via groups.io]

Hi Ard and Leif,

Just a friendly ping on the patches recently posted.

Below are links to the patches including the new introduction to the 
Ampere Altra Max support that we need you to review and merge them in order:


1/ https://edk2.groups.io/g/devel/message/97671

2/ https://edk2.groups.io/g/devel/message/97670

3/ https://edk2.groups.io/g/devel/message/98277

4/ https://edk2.groups.io/g/devel/message/98435

5/ https://edk2.groups.io/g/devel/message/98436

Thanks,

Nhi

On 12/23/2022 9:37 PM, Ard Biesheuvel wrote:

On Wed, 21 Dec 2022 at 06:01, Nhi Pham  wrote:

From: Tinh Nguyen 

PrePeiCore's Arm module just added a requirement to run all library
constructors that PrePeiCore uses. One of them is included in the
constructor of the ExtractGuidedSectionLib. This constructor will build
a HOB that is not supported "at this time" and causes an error.
We don't need to use this constructor because PrePeiCore doesn't
really need this library.

This is a workaround to avoid PrePeiCore module calling
ExtractGuidedSectionLib's constructor.

Signed-off-by: Nhi Pham 
---
  .../AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf | 1 -
  1 file changed, 1 deletion(-)

diff --git 
a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf 
b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
index a4d29379198d..a61da278c705 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
@@ -25,7 +25,6 @@ [LibraryClasses]
ArmSmcLib
HobLib
IoLib
-  MemoryAllocationLib
PL011UartLib
PcdLib
SerialPortLib

Hi,

Thanks for these patches - I will merge them shortly.

As an aside, do you have any news on the issue I reported recently
regarding SetTime() on Altra which crashes the system if
SetVirtualAddressMap() was not called?

https://lore.kernel.org/all/Y2o1hdZK9GGDVJsS@monolith.localdoman/



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98662): https://edk2.groups.io/g/devel/message/98662
Mute This Topic: https://groups.io/mt/95801452/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] AmpereAltraPkg: Update ArmPlatformLib to work with changed ARM_CORE_INFO

[Nhi Pham via groups.io]

Hi Rebecca,

That's Ampere Altra Family specific MPIDR encoding. So, we could not 
leverage the definitions in the ArmPkg/Include/Library/ArmLib.h.


-Nhi

On 1/13/2023 9:40 PM, Rebecca Cran wrote:

On 1/12/23 21:21, Nhi Pham via groups.io wrote:


+//
+// MPIDR manipulation
+//
+#define AC01_GET_MPIDR(SocketId, ClusterId, CoreId) \
+  (((SocketId) << 32) | ((ClusterId) << 16) | ((CoreId) << 8))
+#define AC01_GET_SOCKET_ID(Mpidr)  (((Mpidr) & ARM_CORE_AFF3) >> 32)
+#define AC01_GET_CLUSTER_ID(Mpidr) (((Mpidr) & ARM_CORE_AFF2) >> 16)
+#define AC01_GET_CORE_ID(Mpidr)    (((Mpidr) & ARM_CORE_AFF1) >> 8)
+


Ideally, this should go in ArmPkg/Include/Library/ArmLib.h, but I'm 
not sure how we should handle the older format where the the core was 
in the first 8 bits.





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98661): https://edk2.groups.io/g/devel/message/98661
Mute This Topic: https://groups.io/mt/96240088/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 1/2] Ampere: PCIe: Add support for Ampere Altra Max

[Nhi Pham via groups.io]

From: Vu Nguyen 

This updates the PCIe modules to add support for
Ampere Altra Max processor which features 128 PCIe
Gen4 lanes (distributed across eight x16 RCAs) using
32 controllers.

Signed-off-by: Nhi Pham 
---
 .../AmpereAltraPkg/Include/NVParamDef.h   |  64 ++--
 .../Library/Ac01PcieLib/PcieCore.h|   8 +-
 .../Library/BoardPcieLib/BoardPcieLib.c   |  63 +++-
 .../Drivers/PcieInitPei/PcieInitPei.c |  16 +-
 .../Drivers/PcieInitPei/RootComplexNVParam.c  | 101 +---
 .../Library/Ac01PcieLib/PcieCore.c| 150 +++---
 6 files changed, 333 insertions(+), 69 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h 
b/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h
index 3259fa1ea45c..4dfc353d2340 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h
+++ b/Silicon/Ampere/AmpereAltraPkg/Include/NVParamDef.h
@@ -29,7 +29,7 @@
   As each non-volatile parameter requires 8 bytes, there is a total of 8K
   parameters.
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -425,10 +425,10 @@
 #define NV_SI_RO_BOARD_S0_RCA5_CFG((107 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x02020202 */
 #define NV_SI_RO_BOARD_S0_RCA6_CFG((108 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x02020202 */
 #define NV_SI_RO_BOARD_S0_RCA7_CFG((109 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x02020003 */
-#define NV_SI_RO_BOARD_S0_RCA0_TXRX_G3PRESET  ((110 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA1_TXRX_G3PRESET  ((111 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA2_TXRX_G3PRESET  ((112 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA3_TXRX_G3PRESET  ((113 * 8) + 
NV_BOARD_PARAM_START)
+#define NV_SI_RO_BOARD_S0_RCA0_TXRX_G3PRESET  ((110 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA1_TXRX_G3PRESET  ((111 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA2_TXRX_G3PRESET  ((112 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA3_TXRX_G3PRESET  ((113 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
 #define NV_SI_RO_BOARD_S0_RCB0A_TXRX_G3PRESET ((114 * 8) + 
NV_BOARD_PARAM_START)
 #define NV_SI_RO_BOARD_S0_RCB0B_TXRX_G3PRESET ((115 * 8) + 
NV_BOARD_PARAM_START)
 #define NV_SI_RO_BOARD_S0_RCB1A_TXRX_G3PRESET ((116 * 8) + 
NV_BOARD_PARAM_START)
@@ -437,10 +437,10 @@
 #define NV_SI_RO_BOARD_S0_RCB2B_TXRX_G3PRESET ((119 * 8) + 
NV_BOARD_PARAM_START)
 #define NV_SI_RO_BOARD_S0_RCB3A_TXRX_G3PRESET ((120 * 8) + 
NV_BOARD_PARAM_START)
 #define NV_SI_RO_BOARD_S0_RCB3B_TXRX_G3PRESET ((121 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA4_TXRX_G3PRESET  ((122 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA5_TXRX_G3PRESET  ((123 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA6_TXRX_G3PRESET  ((124 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S0_RCA7_TXRX_G3PRESET  ((125 * 8) + 
NV_BOARD_PARAM_START)
+#define NV_SI_RO_BOARD_S0_RCA4_TXRX_G3PRESET  ((122 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA5_TXRX_G3PRESET  ((123 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA6_TXRX_G3PRESET  ((124 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define NV_SI_RO_BOARD_S0_RCA7_TXRX_G3PRESET  ((125 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
 #define NV_SI_RO_BOARD_S0_RCA0_TXRX_G4PRESET  ((126 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
 #define NV_SI_RO_BOARD_S0_RCA1_TXRX_G4PRESET  ((127 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
 #define NV_SI_RO_BOARD_S0_RCA2_TXRX_G4PRESET  ((128 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x57575757 */
@@ -462,8 +462,8 @@
 #define NV_SI_RO_BOARD_S1_RCA5_CFG((144 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x02020202 */
 #define NV_SI_RO_BOARD_S1_RCA6_CFG((145 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x02020202 */
 #define NV_SI_RO_BOARD_S1_RCA7_CFG((146 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x02020003 */
-#define NV_SI_RO_BOARD_S1_RCA2_TXRX_G3PRESET  ((147 * 8) + 
NV_BOARD_PARAM_START)
-#define NV_SI_RO_BOARD_S1_RCA3_TXRX_G3PRESET  ((148 * 8) + 
NV_BOARD_PARAM_START)
+#define NV_SI_RO_BOARD_S1_RCA2_TXRX_G3PRESET  ((147 * 8) + 
NV_BOARD_PARAM_START) /* Default: 0x */
+#define 

[edk2-devel] [edk2-platforms][PATCH 0/2] Support Ampere Altra Max processor

[Nhi Pham via groups.io]

This patchset adds support for Ampere Altra Max processor.

Tinh Nguyen (1):
  JadePkg: ACPI: Support ACPI tables for Ampere Altra Max

Vu Nguyen (1):
  Ampere: PCIe: Add support for Ampere Altra Max

 .../AmpereAltraPkg/AmpereAltraPkg.dsc.inc |6 +-
 Platform/Ampere/JadePkg/Jade.dsc  |3 +-
 Platform/Ampere/JadePkg/Jade.fdf  |3 +-
 .../JadePkg/Ac02AcpiTables/Ac02AcpiTables.inf |   20 +
 .../Include/Library/AmpereCpuLib.h|   31 +-
 .../AmpereAltraPkg/Include/NVParamDef.h   |   64 +-
 .../AmpereAltraPkg/Include/Platform/Ac01.h|5 +-
 .../Library/Ac01PcieLib/PcieCore.h|8 +-
 .../Drivers/AcpiPlatformDxe/AcpiMadt.c|  103 +-
 .../Drivers/AcpiPlatformDxe/AcpiPlatformDxe.c |   10 +-
 .../Library/BoardPcieLib/BoardPcieLib.c   |   63 +-
 .../Drivers/PcieInitPei/PcieInitPei.c |   16 +-
 .../Drivers/PcieInitPei/RootComplexNVParam.c  |  101 +-
 .../Library/Ac01PcieLib/PcieCore.c|  150 +-
 .../Library/AmpereCpuLib/AmpereCpuLibCommon.c |  243 +-
 .../Ampere/JadePkg/Ac02AcpiTables/CPU-S0.asi  | 6345 +
 .../Ampere/JadePkg/Ac02AcpiTables/CPU-S1.asi  | 6345 +
 .../Ampere/JadePkg/Ac02AcpiTables/CPU.asi |  152 +
 .../JadePkg/Ac02AcpiTables/CommonDevices.asi  |  670 ++
 .../Ampere/JadePkg/Ac02AcpiTables/Dsdt.asl|   39 +
 .../JadePkg/Ac02AcpiTables/PCI-PDRC.asi   |  217 +
 .../JadePkg/Ac02AcpiTables/PCI-S0.Rca01.asi   |  669 ++
 .../Ampere/JadePkg/Ac02AcpiTables/PCI-S0.asi  | 2041 ++
 .../Ampere/JadePkg/Ac02AcpiTables/PCI-S1.asi  | 2051 ++
 .../Ampere/JadePkg/Ac02AcpiTables/PMU-S0.asi  | 1292 
 .../Ampere/JadePkg/Ac02AcpiTables/PMU-S1.asi  | 1292 
 .../Ampere/JadePkg/Ac02AcpiTables/PMU.asi |   10 +
 27 files changed, 21699 insertions(+), 250 deletions(-)
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/Ac02AcpiTables.inf
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU-S0.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU-S1.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CPU.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/CommonDevices.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/Dsdt.asl
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-PDRC.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S0.Rca01.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S0.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PCI-S1.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU-S0.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU-S1.asi
 create mode 100644 Platform/Ampere/JadePkg/Ac02AcpiTables/PMU.asi

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98436): https://edk2.groups.io/g/devel/message/98436
Mute This Topic: https://groups.io/mt/96240126/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 1/1] AmpereAltraPkg: Update ArmPlatformLib to work with changed ARM_CORE_INFO

[Nhi Pham via groups.io]

From: Tinh Nguyen 

Since the commit 103fa647d159e3d76be2634d2653c2d215dd0d46 instead
("ArmPkg: Replace CoreId and ClusterId with Mpidr in ARM_CORE_INFO
struct") has updated the ARM_CORE_INFO structure so the MPIDR is now a
single field instead of separate cluster/core fields. This patch
updates the ArmPlatformLib to work with the changed ARM_CORE_INFO.

Signed-off-by: Nhi Pham 
---
 .../Ampere/AmpereAltraPkg/Include/Platform/Ac01.h  | 11 ++-
 .../JadePkg/Drivers/AcpiPlatformDxe/AcpiMadt.c |  5 ++---
 .../JadePkg/Drivers/AcpiPlatformDxe/AcpiSrat.c | 14 --
 .../Library/ArmPlatformLib/ArmPlatformLib.c|  8 +---
 4 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h 
b/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
index d45688f88401..563dd5ef242d 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
+++ b/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -229,6 +229,15 @@
 //
 #define PLATFORM_CPM_UID_BIT_OFFSET  8
 
+//
+// MPIDR manipulation
+//
+#define AC01_GET_MPIDR(SocketId, ClusterId, CoreId) \
+  (((SocketId) << 32) | ((ClusterId) << 16) | ((CoreId) << 8))
+#define AC01_GET_SOCKET_ID(Mpidr)  (((Mpidr) & ARM_CORE_AFF3) >> 32)
+#define AC01_GET_CLUSTER_ID(Mpidr) (((Mpidr) & ARM_CORE_AFF2) >> 16)
+#define AC01_GET_CORE_ID(Mpidr)(((Mpidr) & ARM_CORE_AFF1) >> 8)
+
 //
 // Max number for AC01 PCIE Root Complexes
 //
diff --git a/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiMadt.c 
b/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiMadt.c
index 419ce578e452..4db1f9a383a9 100644
--- a/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiMadt.c
+++ b/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiMadt.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -160,8 +160,7 @@ AcpiInstallMadtProcessorNode (
 (ClusterId << 8) + (CpuId  % PLATFORM_CPU_NUM_CORES_PER_CPM);
   MadtProcessorEntryPointer->Flags = 1;
   MadtProcessorEntryPointer->MPIDR =
-(((ClusterId << 8) + (CpuId  % PLATFORM_CPU_NUM_CORES_PER_CPM)) << 8);
-  MadtProcessorEntryPointer->MPIDR += (((UINT64)SocketId) << 32);
+AC01_GET_MPIDR ((UINT64)SocketId, ClusterId, CpuId  % 
PLATFORM_CPU_NUM_CORES_PER_CPM);
 
   return Size;
 }
diff --git a/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiSrat.c 
b/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiSrat.c
index f4df60bc2593..3a89014f41f1 100644
--- a/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiSrat.c
+++ b/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiSrat.c
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2020 - 2021, Ampere Computing LLC. All rights reserved.
+  Copyright (c) 2020 - 2023, Ampere Computing LLC. All rights reserved.
   Copyright (c) 2022, ARM Ltd. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -122,7 +122,6 @@ SratAddGiccAffinity (
   UINTN   Count, NumNode, Idx;
   UINT32  AcpiProcessorUid;
   UINT8   Socket;
-  UINT8   Core;
   UINT8   Cpm;
 
   Hob = GetFirstGuidHob ();
@@ -141,14 +140,17 @@ SratAddGiccAffinity (
   NumNode = 0;
   while (Count != NumberOfEntries) {
 for (Idx = 0; Idx < NumberOfEntries; Idx++ ) {
-  Socket = GET_MPIDR_AFF1 (ArmCoreInfoTable[Idx].Mpidr);
-  Core   = GET_MPIDR_AFF0 (ArmCoreInfoTable[Idx].Mpidr);
-  Cpm = Core >> PLATFORM_CPM_UID_BIT_OFFSET;
+  Socket  = AC01_GET_SOCKET_ID (ArmCoreInfoTable[Idx].Mpidr);
+  Cpm = AC01_GET_CLUSTER_ID (ArmCoreInfoTable[Idx].Mpidr);
   if (CpuGetSubNumNode (Socket, Cpm) != NumNode) {
 /* We add nodes based on ProximityDomain order */
 continue;
   }
-  AcpiProcessorUid = (Socket << PLATFORM_SOCKET_UID_BIT_OFFSET) + Core;
+
+  AcpiProcessorUid =
+(AC01_GET_SOCKET_ID (ArmCoreInfoTable[Idx].Mpidr) << 
PLATFORM_SOCKET_UID_BIT_OFFSET)
++ (AC01_GET_CLUSTER_ID (ArmCoreInfoTable[Idx].Mpidr) << 
PLATFORM_CPM_UID_BIT_OFFSET)
++  AC01_GET_CORE_ID (ArmCoreInfoTable[Idx].Mpidr);
   ZeroMem ((VOID *)[Count], sizeof 
(SratGiccAffinity[Count]));
   SratGiccAffinity[Count].AcpiProcessorUid = AcpiProcessorUid;
   SratGiccAffinity[Count].Flags = 1;
diff --git 
a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.c 
b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.c
index f2ec923d6f8d..18023df92880 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.c
+++ 

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] AmpereAltraPkg: Remove MemoryAllocationLib in ArmPlatformLib

[Nhi Pham via groups.io]

Thanks Ard for reviewing them.

Sorry, I'm not aware of the SetTime() issue since I have not setup my 
mailbox for receiving the Linux kernel mails. Let me forward this issue 
to appropriate UEFI team and Linux kernel team to investigate.


Thanks,

-Nhi

On 12/23/2022 9:37 PM, Ard Biesheuvel wrote:

On Wed, 21 Dec 2022 at 06:01, Nhi Pham  wrote:

From: Tinh Nguyen 

PrePeiCore's Arm module just added a requirement to run all library
constructors that PrePeiCore uses. One of them is included in the
constructor of the ExtractGuidedSectionLib. This constructor will build
a HOB that is not supported "at this time" and causes an error.
We don't need to use this constructor because PrePeiCore doesn't
really need this library.

This is a workaround to avoid PrePeiCore module calling
ExtractGuidedSectionLib's constructor.

Signed-off-by: Nhi Pham 
---
  .../AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf | 1 -
  1 file changed, 1 deletion(-)

diff --git 
a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf 
b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
index a4d29379198d..a61da278c705 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
@@ -25,7 +25,6 @@ [LibraryClasses]
ArmSmcLib
HobLib
IoLib
-  MemoryAllocationLib
PL011UartLib
PcdLib
SerialPortLib

Hi,

Thanks for these patches - I will merge them shortly.

As an aside, do you have any news on the issue I reported recently
regarding SetTime() on Altra which crashes the system if
SetVirtualAddressMap() was not called?

https://lore.kernel.org/all/Y2o1hdZK9GGDVJsS@monolith.localdoman/



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97747): https://edk2.groups.io/g/devel/message/97747
Mute This Topic: https://groups.io/mt/95801452/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 1/1] AmpereAltraPkg: Update Memory Type Information hob

[Nhi Pham via groups.io]

From: Vu Nguyen 

The hob was built but wasn't consumed yet. This change will let the DXE
Main shift the memory space consumed by DXE modules to the region
specified by the PcdSystemMemoryBase and PcdSystemMemorySize.

Signed-off-by: Nhi Pham 
---
 .../Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 16 
 .../Library/MemoryInitPeiLib/MemoryInitPeiLib.c  | 10 ++
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc 
b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
index 1e378e37e2b8..bf23edc50349 100644
--- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
+++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
@@ -371,14 +371,14 @@ [PcdsFixedAtBuild.common]
   # (the memory used, and the free memory that was prereserved
   # but not used).
   #
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|80
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|65
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|400
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesData|2
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x60
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x30
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x20
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x30
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|0
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesData|0
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|0
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0
 
   gArmTokenSpaceGuid.PcdVFPEnabled|1
diff --git 
a/Silicon/Ampere/AmpereAltraPkg/Library/MemoryInitPeiLib/MemoryInitPeiLib.c 
b/Silicon/Ampere/AmpereAltraPkg/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
index 98aa1e77b3b4..cdefa521dab3 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
@@ -15,6 +15,11 @@
 #include 
 #include 
 
+VOID
+BuildMemoryTypeInformationHob (
+  VOID
+  );
+
 STATIC
 VOID
 InitMmu (
@@ -89,5 +94,10 @@ MemoryPeim (
 
   InitMmu (MemoryTable);
 
+  if (FeaturePcdGet (PcdPrePiProduceMemoryTypeInformationHob)) {
+// Optional feature that helps prevent EFI memory map fragmentation.
+BuildMemoryTypeInformationHob ();
+  }
+
   return EFI_SUCCESS;
 }
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97671): https://edk2.groups.io/g/devel/message/97671
Mute This Topic: https://groups.io/mt/95801510/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 1/1] AmpereAltraPkg: Remove MemoryAllocationLib in ArmPlatformLib

[Nhi Pham via groups.io]

From: Tinh Nguyen 

PrePeiCore's Arm module just added a requirement to run all library
constructors that PrePeiCore uses. One of them is included in the
constructor of the ExtractGuidedSectionLib. This constructor will build
a HOB that is not supported "at this time" and causes an error.
We don't need to use this constructor because PrePeiCore doesn't
really need this library.

This is a workaround to avoid PrePeiCore module calling
ExtractGuidedSectionLib's constructor.

Signed-off-by: Nhi Pham 
---
 .../AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf 
b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
index a4d29379198d..a61da278c705 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
@@ -25,7 +25,6 @@ [LibraryClasses]
   ArmSmcLib
   HobLib
   IoLib
-  MemoryAllocationLib
   PL011UartLib
   PcdLib
   SerialPortLib
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97670): https://edk2.groups.io/g/devel/message/97670
Mute This Topic: https://groups.io/mt/95801452/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 6/6] ArmPkg/SmbiosMiscDxe: Get SMBIOS information from OemMiscLib

[Nhi Pham via groups.io]

From: Minh Nguyen 

In some scenarios, the information of Bios Version, Bios Release
and Embedded Controller Firmware Release are fetched during UEFI
booting. This patch supports updating those fields dynamically
when the PCDs are empty.

Signed-off-by: Nhi Pham 
Reviewed-by: Rebecca Cran 
Reviewed-by: Sami Mujawar 
Acked-by: Ard Biesheuvel 
---
 ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf |  5 
 ArmPkg/Include/Library/OemMiscLib.h   | 21 
++
 ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c   | 29 

 ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c | 22 
+++
 4 files changed, 66 insertions(+), 11 deletions(-)

diff --git a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf 
b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf
index 8653f57720d1..7286ed61142a 100644
--- a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf
+++ b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf
@@ -30,6 +30,11 @@ [Packages]
 [LibraryClasses]

   BaseMemoryLib

   DebugLib

+  PcdLib

 

 [Guids]

   gZeroGuid

+

+[Pcd]

+  gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease

+  gArmTokenSpaceGuid.PcdSystemBiosRelease

diff --git a/ArmPkg/Include/Library/OemMiscLib.h 
b/ArmPkg/Include/Library/OemMiscLib.h
index 1936619d9b5b..541274999e5c 100644
--- a/ArmPkg/Include/Library/OemMiscLib.h
+++ b/ArmPkg/Include/Library/OemMiscLib.h
@@ -37,6 +37,7 @@ typedef struct {
 } OEM_MISC_PROCESSOR_DATA;

 

 typedef enum {

+  BiosVersionType00,

   ProductNameType01,

   SerialNumType01,

   UuidType01,

@@ -247,4 +248,24 @@ OemGetSystemUuid (
   OUT GUID  *SystemUuid

   );

 

+/** Fetches the BIOS release.

+

+  @return The BIOS release.

+**/

+UINT16

+EFIAPI

+OemGetBiosRelease (

+  VOID

+  );

+

+/** Fetches the embedded controller firmware release.

+

+  @return The embedded controller firmware release.

+**/

+UINT16

+EFIAPI

+OemGetEmbeddedControllerFirmwareRelease (

+  VOID

+  );

+

 #endif // OEM_MISC_LIB_H_

diff --git a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c 
b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
index 32f6d55c1a9a..a5d635da9e11 100644
--- a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
+++ b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
@@ -16,6 +16,7 @@
 #include 

 #include 

 #include 

+#include 

 

 /** Gets the CPU frequency of the specified processor.

 

@@ -254,3 +255,31 @@ OemGetSystemUuid (
   ASSERT (FALSE);

   CopyGuid (SystemUuid, );

 }

+

+/** Fetches the BIOS release.

+

+  @return The BIOS release.

+**/

+UINT16

+EFIAPI

+OemGetBiosRelease (

+  VOID

+  )

+{

+  ASSERT (FALSE);

+  return PcdGet16 (PcdSystemBiosRelease);

+}

+

+/** Fetches the embedded controller firmware release.

+

+  @return The embedded controller firmware release.

+**/

+UINT16

+EFIAPI

+OemGetEmbeddedControllerFirmwareRelease (

+  VOID

+  )

+{

+  ASSERT (FALSE);

+  return PcdGet16 (PcdEmbeddedControllerFirmwareRelease);

+}

diff --git 
a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c 
b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
index b49c4b754cab..e1310f331009 100644
--- a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
+++ b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
@@ -1,5 +1,6 @@
 /** @file

 

+  Copyright (c) 2022, Ampere Computing LLC. All rights reserved.

   Copyright (c) 2021, NUVIA Inc. All rights reserved.

   Copyright (c) 2009, Intel Corporation. All rights reserved.

   Copyright (c) 2015, Hisilicon Limited. All rights reserved.

@@ -13,6 +14,7 @@
 #include 

 #include 

 #include 

+#include 

 #include 

 #include 

 

@@ -191,11 +193,11 @@ SMBIOS_MISC_TABLE_FUNCTION (MiscBiosVendor) {
 TokenToUpdate = STRING_TOKEN (STR_MISC_BIOS_VERSION);

 HiiSetString (mSmbiosMiscHiiHandle, TokenToUpdate, Version, NULL);

   } else {

-Version = (CHAR16 *)PcdGetPtr (PcdFirmwareVersionString);

-if (StrLen (Version) > 0) {

-  TokenToUpdate = STRING_TOKEN (STR_MISC_BIOS_VERSION);

-  HiiSetString (mSmbiosMiscHiiHandle, TokenToUpdate, Version, NULL);

-}

+  OemUpdateSmbiosInfo (

+mSmbiosMiscHiiHandle,

+STRING_TOKEN (STR_MISC_BIOS_VERSION),

+BiosVersionType00

+);

   }

 

   Char16String = GetBiosReleaseDate ();

@@ -251,13 +253,11 @@ SMBIOS_MISC_TABLE_FUNCTION (MiscBiosVendor) {
 }

   }

 

-  SmbiosRecord->SystemBiosMajorRelease = (UINT8)(PcdGet16 
(PcdSystemBiosRelease) >> 8);

-  SmbiosRecord->SystemBiosMinorRelease = (UINT8)(PcdGet16 
(PcdSystemBiosRelease) & 0xFF);

+  SmbiosRecord->SystemBiosMajorRelease = (UINT8)(OemGetBiosRelease () >> 8);

+  SmbiosRecord->SystemBiosMinorRelease = (UINT8)(OemGetBiosRelease () & 0xFF);

 

-  SmbiosRecord->EmbeddedControllerFirmwareMajorRelease = (UINT16)

-  

[edk2-devel] [PATCH v4 5/6] ArmPkg/SmbiosMiscDxe: Remove redundant updates in SMBIOS Type 2

[Nhi Pham via groups.io]

From: Minh Nguyen 

This patch removes redundant updates of "BoardManufacturerType02"
and "SerialNumberType02".

Signed-off-by: Nhi Pham 
Reviewed-by: Rebecca Cran 
Reviewed-by: Sami Mujawar 
Acked-by: Ard Biesheuvel 
Acked-by: Leif Lindholm 
---
 
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
 | 10 --
 1 file changed, 10 deletions(-)

diff --git 
a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
 
b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
index f61546955f12..3441e7798860 100644
--- 
a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
+++ 
b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
@@ -120,16 +120,6 @@ SMBIOS_MISC_TABLE_FUNCTION (MiscBaseBoardManufacturer) {
 STRING_TOKEN (STR_MISC_BASE_BOARD_SERIAL_NUMBER),

 SerialNumberType02

 );

-  OemUpdateSmbiosInfo (

-mSmbiosMiscHiiHandle,

-STRING_TOKEN (STR_MISC_BASE_BOARD_MANUFACTURER),

-BoardManufacturerType02

-);

-  OemUpdateSmbiosInfo (

-mSmbiosMiscHiiHandle,

-STRING_TOKEN (STR_MISC_BASE_BOARD_SERIAL_NUMBER),

-SerialNumberType02

-);

   OemUpdateSmbiosInfo (

 mSmbiosMiscHiiHandle,

 STRING_TOKEN (STR_MISC_BASE_BOARD_SKU_NUMBER),

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93931): https://edk2.groups.io/g/devel/message/93931
Mute This Topic: https://groups.io/mt/93773966/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 4/6] ArmPkg/SmbiosMiscDxe: Fix typo of "AssetTagType02"

[Nhi Pham via groups.io]

From: Minh Nguyen 

This patch fixes typo from "AssertTagType02"
to "AssetTagType02".

Signed-off-by: Nhi Pham 
Reviewed-by: Rebecca Cran 
Reviewed-by: Sami Mujawar 
Acked-by: Ard Biesheuvel 
Acked-by: Leif Lindholm 
---
 ArmPkg/Include/Library/OemMiscLib.h
  | 2 +-
 
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
 | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Include/Library/OemMiscLib.h 
b/ArmPkg/Include/Library/OemMiscLib.h
index d87737db9c2b..1936619d9b5b 100644
--- a/ArmPkg/Include/Library/OemMiscLib.h
+++ b/ArmPkg/Include/Library/OemMiscLib.h
@@ -44,7 +44,7 @@ typedef enum {
   VersionType01,

   SkuNumberType01,

   FamilyType01,

-  AssertTagType02,

+  AssetTagType02,

   SerialNumberType02,

   BoardManufacturerType02,

   ProductNameType02,

diff --git 
a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
 
b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
index 870610b17243..f61546955f12 100644
--- 
a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
+++ 
b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
@@ -4,6 +4,7 @@
 

   Based on files under Nt32Pkg/MiscSubClassPlatformDxe/

 

+  Copyright (c) 2022, Ampere Computing LLC. All rights reserved.

   Copyright (c) 2021, NUVIA Inc. All rights reserved.

   Copyright (c) 2009 - 2011, Intel Corporation. All rights reserved.

   Copyright (c) 2015, Hisilicon Limited. All rights reserved.

@@ -112,7 +113,7 @@ SMBIOS_MISC_TABLE_FUNCTION (MiscBaseBoardManufacturer) {
   OemUpdateSmbiosInfo (

 mSmbiosMiscHiiHandle,

 STRING_TOKEN (STR_MISC_BASE_BOARD_ASSET_TAG),

-AssertTagType02

+AssetTagType02

 );

   OemUpdateSmbiosInfo (

 mSmbiosMiscHiiHandle,

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93930): https://edk2.groups.io/g/devel/message/93930
Mute This Topic: https://groups.io/mt/93773965/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 3/6] ArmPkg/SmbiosMiscDxe: Support fetching System UUID

[Nhi Pham via groups.io]

This adds an API to OemMiscLib for fetching the system UUID according to
the platform.

Signed-off-by: Nhi Pham 
Reviewed-by: Rebecca Cran 
Reviewed-by: Sami Mujawar 
Acked-by: Ard Biesheuvel 
Acked-by: Leif Lindholm 
---
 ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf 
|  4 
 ArmPkg/Include/Library/OemMiscLib.h   
| 12 
 ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c   
| 18 ++
 ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type01/MiscSystemManufacturerFunction.c 
|  3 ++-
 4 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf 
b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf
index 5c4268f68b4a..8653f57720d1 100644
--- a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf
+++ b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf
@@ -1,6 +1,7 @@
 #/** @file

 #OemMiscLib.inf

 #

+#Copyright (c) 2022, Ampere Computing LLC. All rights reserved.

 #Copyright (c) 2021, NUVIA Inc. All rights reserved.

 #Copyright (c) 2018, Hisilicon Limited. All rights reserved.

 #Copyright (c) 2018, Linaro Limited. All rights reserved.

@@ -29,3 +30,6 @@ [Packages]
 [LibraryClasses]

   BaseMemoryLib

   DebugLib

+

+[Guids]

+  gZeroGuid

diff --git a/ArmPkg/Include/Library/OemMiscLib.h 
b/ArmPkg/Include/Library/OemMiscLib.h
index 330bb4b014de..d87737db9c2b 100644
--- a/ArmPkg/Include/Library/OemMiscLib.h
+++ b/ArmPkg/Include/Library/OemMiscLib.h
@@ -235,4 +235,16 @@ OemGetChassisNumPowerCords (
   VOID

   );

 

+/**

+  Fetches the system UUID.

+

+  @param[out] SystemUuid The pointer to the buffer to store the System 
UUID.

+

+**/

+VOID

+EFIAPI

+OemGetSystemUuid (

+  OUT GUID  *SystemUuid

+  );

+

 #endif // OEM_MISC_LIB_H_

diff --git a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c 
b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
index 98970407a65e..32f6d55c1a9a 100644
--- a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
+++ b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
@@ -1,6 +1,7 @@
 /** @file

 *  OemMiscLib.c

 *

+*  Copyright (c) 2022, Ampere Computing LLC. All rights reserved.

 *  Copyright (c) 2021, NUVIA Inc. All rights reserved.

 *  Copyright (c) 2018, Hisilicon Limited. All rights reserved.

 *  Copyright (c) 2018, Linaro Limited. All rights reserved.

@@ -10,6 +11,7 @@
 **/

 

 #include 

+#include 

 #include 

 #include 

 #include 

@@ -236,3 +238,19 @@ OemGetChassisNumPowerCords (
   ASSERT (FALSE);

   return 1;

 }

+

+/**

+  Fetches the system UUID.

+

+  @param[out] SystemUuid The pointer to the buffer to store the System 
UUID.

+

+**/

+VOID

+EFIAPI

+OemGetSystemUuid (

+  OUT GUID  *SystemUuid

+  )

+{

+  ASSERT (FALSE);

+  CopyGuid (SystemUuid, );

+}

diff --git 
a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type01/MiscSystemManufacturerFunction.c 
b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type01/MiscSystemManufacturerFunction.c
index 5cf72644d0b2..22fb5eccaa63 100644
--- 
a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type01/MiscSystemManufacturerFunction.c
+++ 
b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type01/MiscSystemManufacturerFunction.c
@@ -4,6 +4,7 @@
 

   Based on files under Nt32Pkg/MiscSubClassPlatformDxe/

 

+  Copyright (c) 2022, Ampere Computing LLC. All rights reserved.

   Copyright (c) 2021, NUVIA Inc. All rights reserved.

   Copyright (c) 2006 - 2011, Intel Corporation. All rights reserved.

   Copyright (c) 2015, Hisilicon Limited. All rights reserved.

@@ -160,7 +161,7 @@ SMBIOS_MISC_TABLE_FUNCTION (MiscSystemManufacturer) {
 

   SmbiosRecord->Hdr.Length = sizeof (SMBIOS_TABLE_TYPE1);

 

-  CopyGuid (>Uuid, >Uuid);

+  OemGetSystemUuid (>Uuid);

 

   OptionalStrStart = (CHAR8 *)(SmbiosRecord + 1);

   UnicodeStrToAsciiStrS (Manufacturer, OptionalStrStart, ManuStrLen + 1);

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93929): https://edk2.groups.io/g/devel/message/93929
Mute This Topic: https://groups.io/mt/93773961/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 2/6] ArmPkg: Correct return value of "SMCCC_ARCH_SOC_ID" Function ID call

[Nhi Pham via groups.io]

From: Minh Nguyen 

According to "SMC Calling Convention" specification, section 7.4,
return value of Arm Architecture Calls is stored at first argument of
SMC aguments (ARM_SMC_ARGS). This value can be negative values indicating
error or positive values (including zero) indicating success. Positive
value would contain information of respective Function ID (Section 7.3.4
and 7.4.4).

For that reason, "SMCCC_VERSION" and "SMCCC_ARCH_FEATURES"
Function ID calls read return value from "SmcCallStatus" variable
(Args.Arg0 - first argument of SMC call). But "SMCCC_ARCH_SOC_ID"
Function ID call is reading return value from "SmcParam" variable
(Args.Arg1 - second argument of SMC call) so it leads to unexpected
results of "Jep106Code" and "SocRevision". This patch is to correct it.

Signed-off-by: Nhi Pham 
Reviewed-by: Rebecca Cran 
Reviewed-by: Sami Mujawar 
Acked-by: Ard Biesheuvel 
Acked-by: Leif Lindholm 
---
 ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArmCommon.c | 6 
+++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArmCommon.c 
b/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArmCommon.c
index e0010a40e489..b961be213358 100644
--- a/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArmCommon.c
+++ b/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArmCommon.c
@@ -2,7 +2,7 @@
   Functions for processor information common to ARM and AARCH64.

 

   Copyright (c) 2021, NUVIA Inc. All rights reserved.

-  Copyright (c) 2021, Ampere Computing LLC. All rights reserved.

+  Copyright (c) 2021 - 2022, Ampere Computing LLC. All rights reserved.

 

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

 

@@ -131,7 +131,7 @@ SmbiosGetSmcArm64SocId (
   SmcCallStatus = ArmCallSmc1 (SMCCC_ARCH_SOC_ID, , NULL, NULL);

 

   if (SmcCallStatus >= 0) {

-*Jep106Code = (INT32)SmcParam;

+*Jep106Code = SmcCallStatus;

   } else {

 Status = EFI_UNSUPPORTED;

   }

@@ -140,7 +140,7 @@ SmbiosGetSmcArm64SocId (
   SmcCallStatus = ArmCallSmc1 (SMCCC_ARCH_SOC_ID, , NULL, NULL);

 

   if (SmcCallStatus >= 0) {

-*SocRevision = (INT32)SmcParam;

+*SocRevision = SmcCallStatus;

   } else {

 Status = EFI_UNSUPPORTED;

   }

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93928): https://edk2.groups.io/g/devel/message/93928
Mute This Topic: https://groups.io/mt/93773959/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 1/6] ArmPkg/ProcessorSubClassDxe: Get processor version from OemMiscLib

[Nhi Pham via groups.io]

From: Minh Nguyen 

In some scenarios, the processor version may be updated dynamically
from pre-UEFI firmware during booting. But the processor version is
fixed with PCD (PcdProcessorVersion), so it can not be updated it
dynamically. This patch will support setting that value both
statically and dynamically.

Signed-off-by: Nhi Pham 
Reviewed-by: Rebecca Cran 
Reviewed-by: Sami Mujawar 
Acked-by: Ard Biesheuvel 
Acked-by: Leif Lindholm 
---
 ArmPkg/Include/Library/OemMiscLib.h  | 2 ++
 ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c | 8 +++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Include/Library/OemMiscLib.h 
b/ArmPkg/Include/Library/OemMiscLib.h
index 47cb30d84a62..330bb4b014de 100644
--- a/ArmPkg/Include/Library/OemMiscLib.h
+++ b/ArmPkg/Include/Library/OemMiscLib.h
@@ -1,5 +1,6 @@
 /** @file

 *

+*  Copyright (c) 2022, Ampere Computing LLC. All rights reserved.

 *  Copyright (c) 2021, NUVIA Inc. All rights reserved.

 *  Copyright (c) 2015, Hisilicon Limited. All rights reserved.

 *  Copyright (c) 2015, Linaro Limited. All rights reserved.

@@ -58,6 +59,7 @@ typedef enum {
   SkuNumberType03,

   ProcessorPartNumType04,

   ProcessorSerialNumType04,

+  ProcessorVersionType04,

   SmbiosHiiStringFieldMax

 } OEM_MISC_SMBIOS_HII_STRING_FIELD;

 

diff --git a/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c 
b/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c
index 0b9af9bd7e1c..3b12e26abf6e 100644
--- a/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c
+++ b/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c
@@ -1,6 +1,7 @@
 /** @file

   ProcessorSubClass.c

 

+  Copyright (c) 2022, Ampere Computing LLC. All rights reserved.

   Copyright (c) 2021, NUVIA Inc. All rights reserved.

   Copyright (c) 2015, Hisilicon Limited. All rights reserved.

   Copyright (c) 2015, Linaro Limited. All rights reserved.

@@ -512,7 +513,6 @@ AllocateType4AndSetProcessorInformationStrings (
   PartNumber   = STRING_TOKEN (STR_PROCESSOR_PART_NUMBER);

 

   SET_HII_STRING_IF_PCD_NOT_EMPTY (PcdProcessorManufacturer, ProcessorManu);

-  SET_HII_STRING_IF_PCD_NOT_EMPTY (PcdProcessorVersion, ProcessorVersion);

   SET_HII_STRING_IF_PCD_NOT_EMPTY (PcdProcessorAssetTag, AssetTag);

 

   if (StrLen ((CHAR16 *)FixedPcdGetPtr (PcdProcessorSerialNumber)) > 0) {

@@ -527,6 +527,12 @@ AllocateType4AndSetProcessorInformationStrings (
 OemUpdateSmbiosInfo (mHiiHandle, PartNumber, ProcessorPartNumType04);

   }

 

+  if (StrLen ((CHAR16 *)FixedPcdGetPtr (PcdProcessorVersion)) > 0) {

+HiiSetString (mHiiHandle, ProcessorVersion, (CHAR16 *)FixedPcdGetPtr 
(PcdProcessorVersion), NULL);

+  } else {

+OemUpdateSmbiosInfo (mHiiHandle, ProcessorVersion, ProcessorVersionType04);

+  }

+

   // Processor Designation

   StringBufferSize = sizeof (CHAR16) * SMBIOS_STRING_MAX_LENGTH;

   ProcessorStr = AllocateZeroPool (StringBufferSize);

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93927): https://edk2.groups.io/g/devel/message/93927
Mute This Topic: https://groups.io/mt/93773958/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 0/6] ArmPkg/SMBIOS fixes and improvements

[Nhi Pham via groups.io]

This patchset is to update the ArmPkg/SMBIOS for fixes and improvements.

Changes since v3:
+ Update for OemGetBiosRelease and
OemGetEmbeddedControllerFirmwareRelease functions [Leif, Sami]

Changes since v2:
+ Add tags from Ard and Sami
+ Fix patch 3 for compilation error with OemMiscLibNull due to lack
of gZeroGuid in the INF file.

Changes since v1:
+ Change PartNumber to ProcessorVersion [Sami]

Minh Nguyen (5):
  ArmPkg/ProcessorSubClassDxe: Get processor version from OemMiscLib
  ArmPkg: Correct return value of "SMCCC_ARCH_SOC_ID" Function ID call
  ArmPkg/SmbiosMiscDxe: Fix typo of "AssetTagType02"
  ArmPkg/SmbiosMiscDxe: Remove redundant updates in SMBIOS Type 2
  ArmPkg/SmbiosMiscDxe: Get SMBIOS information from OemMiscLib

Nhi Pham (1):
  ArmPkg/SmbiosMiscDxe: Support fetching System UUID

 ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLibNull.inf  
  |  9 
 ArmPkg/Include/Library/OemMiscLib.h
  | 37 ++-
 ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
  | 47 
 ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClass.c   
  |  8 +++-
 ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArmCommon.c
  |  6 +--
 ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c  
  | 22 -
 ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type01/MiscSystemManufacturerFunction.c  
  |  3 +-
 
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type02/MiscBaseBoardManufacturerFunction.c
 | 13 +-
 8 files changed, 117 insertions(+), 28 deletions(-)

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93926): https://edk2.groups.io/g/devel/message/93926
Mute This Topic: https://groups.io/mt/93773954/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 2/2] SbsaQemu/OemMiscLib: Fix typo of "AssetTagType02"

[Nhi Pham via groups.io]

This fixes the typo of AssetTagType02 according to the recent changes
from OemMiscLib.h in the edk2.

Signed-off-by: Nhi Pham 
Reviewed-by: Leif Lindholm 
---
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
index 3ccf22bf282d..c38f2851904f 100644
--- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
+++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
@@ -201,7 +201,7 @@ OemUpdateSmbiosInfo (
 case FamilyType01:
   String = (CHAR16*)PcdGetPtr (PcdSystemFamily);
   break;
-case AssertTagType02:
+case AssetTagType02:
   String = (CHAR16*)PcdGetPtr (PcdBaseBoardAssetTag);
   break;
 case SerialNumberType02:
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93925): https://edk2.groups.io/g/devel/message/93925
Mute This Topic: https://groups.io/mt/93773951/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 1/2] SbsaQemu/OemMiscLib: Update for new OemMiscLib APIs

[Nhi Pham via groups.io]

This is to reflect the new APIs added to edk2/OemMiscLib library.

Signed-off-by: Nhi Pham 
---
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf |  5 +++
 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c   | 42 
 2 files changed, 47 insertions(+)

diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf 
b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
index 04a07a55cee9..a34f54d431d4 100644
--- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
+++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
@@ -34,7 +34,12 @@ [LibraryClasses]
   IoLib
   PcdLib
 
+[Guids]
+  gZeroGuid
+
 [Pcd]
+  gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease
+  gArmTokenSpaceGuid.PcdSystemBiosRelease
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
 
   gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemManufacturer
diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
index 326bb56bcfa3..3ccf22bf282d 100644
--- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
+++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
@@ -9,6 +9,7 @@
 **/
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -330,3 +331,44 @@ OemGetChassisNumPowerCords (
 {
   return 1;
 }
+
+/**
+  Fetches the system UUID.
+
+  @param[out] SystemUuid The pointer to the buffer to store the System 
UUID.
+
+**/
+VOID
+EFIAPI
+OemGetSystemUuid (
+  OUT GUID  *SystemUuid
+  )
+{
+  CopyGuid (SystemUuid, );
+}
+
+/** Fetches the BIOS release.
+
+  @return The BIOS release.
+**/
+UINT16
+EFIAPI
+OemGetBiosRelease (
+  VOID
+  )
+{
+  return PcdGet16 (PcdSystemBiosRelease);
+}
+
+/** Fetches the embedded controller firmware release.
+
+  @return The embedded controller firmware release.
+**/
+UINT16
+EFIAPI
+OemGetEmbeddedControllerFirmwareRelease (
+  VOID
+  )
+{
+  return PcdGet16 (PcdEmbeddedControllerFirmwareRelease);
+}
-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93924): https://edk2.groups.io/g/devel/message/93924
Mute This Topic: https://groups.io/mt/93773950/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-