Re: [edk2-devel] [PATCH edk2-platforms 2/5] Platform,Silicon: drop redundant uses of PcdArmArchTimerFreqInHz
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
++ 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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"
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
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]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-platforms][PATCH v2 0/2] Update SbsaQemu/OemMiscLib
This patchset is to update SbsaQemu/OemMiscLib to reflect the recent changes in edk2/OemMiscLib. Changes since v1: + Update OemGetBiosRelease and OemGetEmbeddedControllerFirmwareRelease functions [Leif, Sami] Nhi Pham (2): SbsaQemu/OemMiscLib: Update for new OemMiscLib APIs SbsaQemu/OemMiscLib: Fix typo of "AssetTagType02" Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf | 5 +++ Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c | 44 +++- 2 files changed, 48 insertions(+), 1 deletion(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#93923): https://edk2.groups.io/g/devel/message/93923 Mute This Topic: https://groups.io/mt/93773949/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 6/6] ArmPkg/SmbiosMiscDxe: Get SMBIOS information from OemMiscLib
Hi Sami,
On 9/16/2022 2:32 PM, Sami Mujawar wrote:
Hi Nhi,
Please see my response inline marked [SAMI].
Regards,
Sami Mujawar
On 15/09/2022, 19:23, "Nhi Pham" wrote:
Thanks Leif. I will fix as your suggestion.
-Nhi
On 9/15/2022 5:54 PM, Leif Lindholm wrote:
> On Tue, Sep 13, 2022 at 13:19:47 +0700, Nhi Pham wrote:
>> 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/Include/Library/OemMiscLib.h
| 21 +
>> ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
| 28 +
>> ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
| 32 +---
>> 3 files changed, 70 insertions(+), 11 deletions(-)
>>
>> 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..788ccab9e8c1 100644
>> --- a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
>> +++ b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
>> @@ -254,3 +254,31 @@ OemGetSystemUuid (
>> ASSERT (FALSE);
>> CopyGuid (SystemUuid, );
>> }
>> +
>> +/** Fetches the BIOS release.
>> +
>> + @return The BIOS release.
>> +**/
>> +UINT16
>> +EFIAPI
>> +OemGetBiosRelease (
>> + VOID
>> + )
>> +{
>> + ASSERT (FALSE);
>> + return 0x;
> This is a change in behaviour.
> The pre-existing behaviour would be preserved by returning the value
> of PcdGet16 (PcdSystemBiosRelease), which defaults to 0x.
>
>> +}
>> +
>> +/** Fetches the embedded controller firmware release.
>> +
>> + @return The embedded controller firmware release.
>> +**/
>> +UINT16
>> +EFIAPI
>> +OemGetEmbeddedControllerFirmwareRelease (
>> + VOID
>> + )
>> +{
>> + ASSERT (FALSE);
>> + return 0x;
> Same as above, but PcdEmbeddedControllerFirmwareRelease.
>
> No other comments on this set.
> (Feel free to see that as Acked-by: Leif Lindholm
> for 1-5/6, but you already have the tags you need for those.)
>
> /
> Leif
>
>> +}
>> diff --git
a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
>> index b49c4b754cab..e9106a8a2fec 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) {
Re: [edk2-devel] [PATCH v3 6/6] ArmPkg/SmbiosMiscDxe: Get SMBIOS information from OemMiscLib
Thanks Leif. I will fix as your suggestion.
-Nhi
On 9/15/2022 5:54 PM, Leif Lindholm wrote:
On Tue, Sep 13, 2022 at 13:19:47 +0700, Nhi Pham wrote:
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/Include/Library/OemMiscLib.h | 21
+
ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c | 28
+
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c | 32
+---
3 files changed, 70 insertions(+), 11 deletions(-)
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..788ccab9e8c1 100644
--- a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
+++ b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
@@ -254,3 +254,31 @@ OemGetSystemUuid (
ASSERT (FALSE);
CopyGuid (SystemUuid, );
}
+
+/** Fetches the BIOS release.
+
+ @return The BIOS release.
+**/
+UINT16
+EFIAPI
+OemGetBiosRelease (
+ VOID
+ )
+{
+ ASSERT (FALSE);
+ return 0x;
This is a change in behaviour.
The pre-existing behaviour would be preserved by returning the value
of PcdGet16 (PcdSystemBiosRelease), which defaults to 0x.
+}
+
+/** Fetches the embedded controller firmware release.
+
+ @return The embedded controller firmware release.
+**/
+UINT16
+EFIAPI
+OemGetEmbeddedControllerFirmwareRelease (
+ VOID
+ )
+{
+ ASSERT (FALSE);
+ return 0x;
Same as above, but PcdEmbeddedControllerFirmwareRelease.
No other comments on this set.
(Feel free to see that as Acked-by: Leif Lindholm
for 1-5/6, but you already have the tags you need for those.)
/
Leif
+}
diff --git
a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
index b49c4b754cab..e9106a8a2fec 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,21 @@ SMBIOS_MISC_TABLE_FUNCTION (MiscBiosVendor) {
}
}
- SmbiosRecord->SystemBiosMajorRelease = (UINT8)(PcdGet16 (PcdSystemBiosRelease) >> 8);
- SmbiosRecord->SystemBiosMinorRelease = (UINT8)(PcdGet16 (PcdSystemBiosRelease)
& 0xFF);
+ if (PcdGet16 (PcdSystemBiosRelease) != 0x) {
+SmbiosRecord->SystemBiosMajorRelease = (UINT8)(PcdGet16 (PcdSystemBiosRelease)
>> 8);
+SmbiosRecord->SystemBiosMinorRelease = (UINT8)(PcdGet16 (PcdSystemBiosRelease)
& 0xFF);
+ } else {
+SmbiosRecord->SystemBiosMajorRelease = (UINT8)(OemGetBiosRelease () >> 8);
+SmbiosRecord->SystemBiosMinorRelease = (UINT8)(OemGetBiosRelease () &
0xFF);
+ }
- SmbiosRecord->EmbeddedControllerFirmwareMajorRelease = (UINT16)
- (PcdGet16
[edk2-devel] [PATCH v3 6/6] ArmPkg/SmbiosMiscDxe: Get SMBIOS information from OemMiscLib
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/Include/Library/OemMiscLib.h | 21
+
ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c | 28
+
ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c | 32
+---
3 files changed, 70 insertions(+), 11 deletions(-)
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..788ccab9e8c1 100644
--- a/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
+++ b/ArmPkg/Universal/Smbios/OemMiscLibNull/OemMiscLib.c
@@ -254,3 +254,31 @@ OemGetSystemUuid (
ASSERT (FALSE);
CopyGuid (SystemUuid, );
}
+
+/** Fetches the BIOS release.
+
+ @return The BIOS release.
+**/
+UINT16
+EFIAPI
+OemGetBiosRelease (
+ VOID
+ )
+{
+ ASSERT (FALSE);
+ return 0x;
+}
+
+/** Fetches the embedded controller firmware release.
+
+ @return The embedded controller firmware release.
+**/
+UINT16
+EFIAPI
+OemGetEmbeddedControllerFirmwareRelease (
+ VOID
+ )
+{
+ ASSERT (FALSE);
+ return 0x;
+}
diff --git
a/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
b/ArmPkg/Universal/Smbios/SmbiosMiscDxe/Type00/MiscBiosVendorFunction.c
index b49c4b754cab..e9106a8a2fec 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,21 @@ SMBIOS_MISC_TABLE_FUNCTION (MiscBiosVendor) {
}
}
- SmbiosRecord->SystemBiosMajorRelease = (UINT8)(PcdGet16
(PcdSystemBiosRelease) >> 8);
- SmbiosRecord->SystemBiosMinorRelease = (UINT8)(PcdGet16
(PcdSystemBiosRelease) & 0xFF);
+ if (PcdGet16 (PcdSystemBiosRelease) != 0x) {
+SmbiosRecord->SystemBiosMajorRelease = (UINT8)(PcdGet16
(PcdSystemBiosRelease) >> 8);
+SmbiosRecord->SystemBiosMinorRelease = (UINT8)(PcdGet16
(PcdSystemBiosRelease) & 0xFF);
+ } else {
+SmbiosRecord->SystemBiosMajorRelease = (UINT8)(OemGetBiosRelease () >> 8);
+SmbiosRecord->SystemBiosMinorRelease = (UINT8)(OemGetBiosRelease () &
0xFF);
+ }
- SmbiosRecord->EmbeddedControllerFirmwareMajorRelease = (UINT16)
- (PcdGet16
(PcdEmbeddedControllerFirmwareRelease) >> 8);
- SmbiosRecord->EmbeddedControllerFirmwareMinorRelease = (UINT16)
- (PcdGet16
(PcdEmbeddedControllerFirmwareRelease) & 0xFF);
+ if (PcdGet16 (PcdEmbeddedControllerFirmwareRelease) != 0x) {
+SmbiosRecord->EmbeddedControllerFirmwareMajorRelease = (UINT16)(PcdGet16
(PcdEmbeddedControllerFirmwareRelease) >> 8);
+SmbiosRecord->EmbeddedControllerFirmwareMinorRelease =
