Re: [edk2-devel] MicrovmX64, "Did not find any '.text' section"

[Leif Lindholm via groups.io]

Hi Oliver, Gerd,

On Mon, 4 Nov 2024 at 21:17, Oliver Smith-Denny
 wrote:
> >> While working on the FdtLib migration to the submodule variant, I decided 
> >> to
> >> at least try to test build MicrovmX64 ... but I'm failing.
> >>
> >> Both clang and gcc builds bail out at a GenFw invocation to generate
> >> ResetVector.efi due to "Did not find any '.text' section". (Assert on line
> >> 938 of Elf64Convert.c.)
>
> So I was hitting this also when doing dynamic stack cookies and trying
> different ways to make ResetVector be okay being linked to the
> null stack cookie lib. There is something that BaseTools doesn't do well
> when ResetVector is linked against libraries, are you adding a library
> linkage here (say a NULL lib applied globally)?

No, I mean I'm building current edk2 HEAD unmodified, with current
in-tree BaseTools.
With GCC 14.2.0 using GCC profile, and clang 16.0.2 using CLANGDWARF profile.
(On Debian "testing".)

> To fix this for stack cookies, my PR converts ResetVector to be
> USER_DEFINED so that BaseTools will not link NULL libs against it.
>
> Worth a shot seeing if making that change (you need to change the
> RESETVECTOR rule in the FDF from SEC to USER_DEFINED also) makes
> a difference. If this is not being caused by a null library
> linkage, then I have no idea what is happening :).

I can confirm the above workaround fixes the build for both toolchain profiles.
Thanks a lot, that means I can get back to verifying my actual changes :)

Best Regards,

Leif


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

Re: [edk2-devel] Removal of VS2015 (and maybe VS2017) and deprecated toolchains (GCC48, GCC49, GCC5)

[Leif Lindholm via groups.io]

On Tue, 22 Oct 2024 at 12:19, Rebecca Cran  wrote:
> In addition, since GCC48, GCC49 and GCC5 have been marked deprecated for
> over a year, I'd like to proceed with removing them as well.
>
> Please provide feedback by Thursday October 31st. In the absence of
> feedback I'll plan to proceed with removing VS2015, GCC48, GCC49 and GCC5.

No comment on the VS ones, but for the GCC ones, I'm all for it.

We might also want to raise an issue on deleting workarounds put into
place for ancient toolchains.
For gcc48/49 that was redundant initialization due to broken
use-uninitialized detection.
e.g. 
https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c#L346

/
Leif


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

[edk2-devel] likely upcoming change of my email address at Qualcomm

[Leif Lindholm]

Hi all,

Qualcomm is (finally) trialling some sane infrastructure for open source 
email communications. As a result, I have a new account I will start a 
soft migration across to.
If everything seems to be working fine, I will send out an update for 
Maintainers.txt in a couple of weeks.


This will be completely transparent on github, but don't be surprised if 
you get a reply from leif.lindh...@oss.qualcomm.com on the mailing lists.


/
Leif


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

[edk2-devel] MicrovmX64, "Did not find any '.text' section"

[Leif Lindholm]

Hi Gerd, others,

While working on the FdtLib migration to the submodule variant, I 
decided to at least try to test build MicrovmX64 ... but I'm failing.


Both clang and gcc builds bail out at a GenFw invocation to generate 
ResetVector.efi due to "Did not find any '.text' section". (Assert on 
line 938 of Elf64Convert.c.)

OvmfPkgX64 builds without issue.

Is there something I'm missing?
Can anyone else build MicrovmX64 on current HEAD?

/
Leif



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

Re: [edk2-devel] Retire EmbeddedPkg/Library/FdtLib

[Leif Lindholm]

On 2024-09-19 10:57, Nhi Pham via groups.io wrote:

Hi,

It appears that the EmbeddedPkg/Library/FdtLib could be replaced by 
MdePkg/Library/BaseFdtLib. Should we remove the old one in EmbeddedPkg 
and transition to the new one?


Yes, but the new one does not (yet) implement all the functionality 
exposed by the old one, and some platforms use those additional interfaces.


And I'm sad to see additional users have been added more than a year 
after BaseFdtLib was added.


I've started that work, but have had a shortage of time to complete it.

Migrating away from the legacy one is absolutely the right thing to do.

/
Leif



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

Re: [edk2-devel] RFC - Tools & CI Meeting European friendly time

[Leif Lindholm]

Thanks Ard,

Sure, that slot works for me.

Regards,

Leif

On 2024-09-10 09:13, Ard Biesheuvel wrote:

(cc Leif)

That would work for me - thanks.


On Tue, 10 Sept 2024 at 02:22, Sean > wrote:


__

Hi,

In the Tools and CI meeting it was brought up that there may be a
few developers from the European region interested in joining the
discussion on some recurring basis.  Finding a time that works that
isn't already booked can be difficult.

Is there still interest in joining?

Would the last Monday of the month make sense as a recurring event?

Moving to 8AM Pacific time would give the most reasonable overlap
but does that work for those interested?




https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024&month=9&day=30&hour=15&min=0&sec=0&p1=234&p2=179&p3=136&p4=195
 



Thanks

Sean


Attachments:

  * a8ZmcH7B0qhjUk1q.png








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120540): https://edk2.groups.io/g/devel/message/120540
Mute This Topic: https://groups.io/mt/108366828/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/3] SbsaQemu: Move from ArmSmcLib to ArmMonitorLib

[Leif Lindholm]

On 2024-08-08 15:20, Marcin Juszkiewicz wrote:

During last weeks Ard updated ArmMonitorLib to current SMCCC
specification. This allows to use 18 registers as both arguments and
return values.

We already have one SMC call with 5 return values (GetCpuTopology) so
let move all calls to use of ArmMonitorLib to simplify code.

First patch also moves all SMC calls we use into HardwareInfoLib to have
all hardware related queries in one place.

Signed-off-by: Marcin Juszkiewicz 


For the series:
Leif Lindholm 

Thanks!


---
Marcin Juszkiewicz (3):
   SbsaQemu: move SMC calls to HardwareInfoLib
   SbsaQemu: move from ArmSmcLib to ArmMonitorLib
   SbsaQemu: drop not needed packages

  .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.inf |   4 +-
  .../SbsaQemuHardwareInfoLib.inf |   8 +-
  .../Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h |  31 +
  .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c   |  57 +++--
  .../SbsaQemuHardwareInfoLib.c   | 132 ++--
  5 files changed, 145 insertions(+), 87 deletions(-)
---
base-commit: a8344967ba17584c13620a639fb24990be020878
change-id: 20240808-move-from-armsmclib-to-armmonitorlib-7ce6c2456c95

Best regards,




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120299): https://edk2.groups.io/g/devel/message/120299
Mute This Topic: https://groups.io/mt/107790445/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 v6 0/6] SbsaQemu: Align the PPTT tables with QEMU

[Leif Lindholm]

On Wed, Aug 07, 2024 at 13:34:38 +0200, Marcin Juszkiewicz wrote:
> We want to make sure that CPU topology information given to QEMU would
> be provided to the operating system. So we use SMC call to ask TF-A for
> amount of sockets, clusters, cores and threads set in QEMU config.
> 
> The TF-A part is already merged:
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/27189
> 
> Signed-off-by: Xiong Yining 
> Signed-off-by: Marcin Juszkiewicz 

For the series:
Reviewed-by: Leif Lindholm 
Thanks!

/
Leif

> To: devel@edk2.groups.io
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Graeme Gregory 
> Cc: Chen Baozi 
> Cc: Xiong Yining 
> Cc: Jonathan Cameron 
> 
> Changes in v6:
> - use ArmMonitorLib for GetCpuTopology() as we need 5 return values
> - Link to v5: 
> https://openfw.io/edk2-devel/20240711-acpi65-v5-0-a30180b74...@linaro.org
> 
> Changes in v5:
> - added support for cache sizes on cores with FEAT_CCIDX (Neoverse V1+)
> - Link to v4: 
> https://openfw.io/edk2-devel/20240710-acpi65-v4-0-bc32224e4...@linaro.org
> 
> Changes in v4:
> - renamed all *Index variables to *Offset ones for clarity
> - renamed static CpuId/CacheId variable to mCpuId/mCacheId
> - moved above variables outside of pragma pack
> - moved all variables definitions to start of functions
> - added reading cpu cache size from CCIDR registers
> - changed wording in SbsaHardwareInfoLib header
> - changed wording in 3rd patch commit message
> - Link to v3: 
> https://openfw.io/edk2-devel/20240709-acpi65-v3-0-ee93ba536...@linaro.org
> 
> Changes in v3:
> - split ACPI 6.5 changes into separate patch
> - moved adding cores/threads to separate function
> - fixed cache offsets
> - Link to v2: 
> https://openfw.io/edk2-devel/20240702-acpi65-v2-0-3cb18a892...@linaro.org/T/#t
> 
> Changes in v2 (Marcin Juszkiewicz):
> - use ACPI 6.5 structures (instead of 6.3)
> - add patch to move cache data to cores (instead of clusters)
>   - this is for future MPAM support
> - reformatted sources using uncrustify
> - changed debug output to allow singular values (s/are/:/)
> 
> ---
> Marcin Juszkiewicz (5):
>   SbsaQemu: get the information of CPU topology via SMC calls
>   SbsaQemu: update PPTT to ACPI 6.5
>   SbsaQemu: provide cache info per core in PPTT
>   SbsaQemu: introduce helper in PPTT generation
>   SbsaQemu: export proper cache values in PPTT
> 
> Xiong Yining (1):
>   SbsaQemu: align the PPTT tables with QEMU
> 
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h   |  11 +
>  .../Include/IndustryStandard/SbsaQemuAcpi.h | 110 +++-
>  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h |   1 +
>  .../Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h |  26 ++
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   | 274 
> +---
>  .../SbsaQemuHardwareInfoLib.c   |  35 +++
>  6 files changed, 341 insertions(+), 116 deletions(-)
> ---
> base-commit: a3c898956a4d48dc5980336fa6ce6eeb23c4f72b
> change-id: 20240702-acpi65-1bfdb20bde1a
> 
> Best regards,
> -- 
> Marcin Juszkiewicz 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120283): https://edk2.groups.io/g/devel/message/120283
Mute This Topic: https://groups.io/mt/107767179/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/5] Add IPMI SSIF support

[Leif Lindholm]

I'm honestly not too fussed, but maybe hold off on telling people we've 
switched until Rebecca's set is actually merged, so that the PR 
assignment is working?


Regards,

Leif

On 2024-08-07 11:45, Chang, Abner via groups.io wrote:

[AMD Official Use Only - AMD Internal Distribution Only]


So Leif, what's your preference? AMD already switched to use PR on 
edk2-platforms, shall we get back to the email review?


Thanks
Abner

Get Outlook for Android <https://aka.ms/AAb9ysg>
----
*From:* Leif Lindholm 
*Sent:* Wednesday, August 7, 2024 6:23:46 PM
*To:* Chang, Abner ; devel@edk2.groups.io 
; n...@os.amperecomputing.com 

*Cc:* chu...@os.amperecomputing.com ; 
rebe...@os.amperecomputing.com 
*Subject:* Re: [edk2-devel] [edk2-platforms][PATCH v2 0/5] Add IPMI SSIF 
support
Caution: This message originated from an External Source. Use proper 
caution when opening attachments, clicking links, or responding.



Err, no we haven't.

Although we're in the process of doing that.

/
  Leif

On 2024-08-07 08:16, Chang, Abner wrote:

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Pham,
We already move edk2-platforms review through GitHub PR. Could you please send 
the PR against edk2-platforms?

Thanks
Abner


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Nhi Pham
via groups.io
Sent: Wednesday, August 7, 2024 2:47 PM
To: devel@edk2.groups.io
Cc: quic_llind...@quicinc.com; chu...@os.amperecomputing.com;
rebe...@os.amperecomputing.com; n...@os.amperecomputing.com
Subject: [edk2-devel] [edk2-platforms][PATCH v2 0/5] Add IPMI SSIF support

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


This updates the I2C library and implements SMBUS PEI/DXE drivers to
support IPMI SSIF in the Mt. Jade platform.

v2:
- Refine the changes of the DwI2cLib per Leif's comments and update the
    commit message accordingly.
- Remove the additional PCD PcdBmcSlaveAddr since it's is unused.

NOTE: Regarding the controller/target terminology, the function
prototype and comment are derived from edk2/MdePkg. In this patch set, I
am trying to avoid misusing the terms in the implementation instead of
altering the function prototype and comment with the PPI and Protocol.

Nhi Pham (5):
    AmpereAltraPkg/DwI2cLib: Add support for SMBUS+PEC operation
    AmpereSiliconPkg: Define PCDs for SMBUS and BMC
    AmpereAltraPkg: Add SmbusHc PEI and DXE drivers
    JadePkg: Add PlatformBmcReadyLib to support BMC ready check
    Ampere/Jade: Enable IPMI SSIF

   Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec    
|  15 +-
   Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc    
|  23 ++
   Platform/Ampere/JadePkg/Jade.dsc    
|   2 +
   Platform/Ampere/JadePkg/Jade.fdf    
|  17 ++

Platform/Ampere/JadePkg/Library/PlatformBmcReadyLib/PlatformBmcReady
Lib.inf |  29 ++
   Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcDxe.inf    |
43 +++
   Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcPei.inf    |
43 +++
   Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcCommon.h
|  95 +++
   Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h  
|  11 +-
   Platform/Ampere/JadePkg/Library/PCF85063RealTimeClockLib/PCF85063.c
|   6 +-

Platform/Ampere/JadePkg/Library/PlatformBmcReadyLib/PlatformBmcReady
Lib.c   |  30 +++
   Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcCommon.c
| 261 ++
   Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcDxe.c  |
277 
   Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcPei.c  |
263 +++
   Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c   
| 129
-
   15 files changed, 1227 insertions(+), 17 deletions(-)
   create mode 100755
Platform/Ampere/JadePkg/Library/PlatformBmcReadyLib/PlatformBmcReady
Lib.inf
   create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcDxe.inf
   create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcPei.inf
   create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcCommon.h
   create mode 100644
Platform/Ampere/JadePkg/Library/PlatformBmcReadyLib/PlatformBmcReady
Lib.c
   create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcCommon.c
   create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcDxe.c
   create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcPei.c

--
2.25.1














-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120273): https://edk2.groups.io/g/devel/message/120273
Mute This Topic: ht

Re: [edk2-devel] [edk2-platforms][PATCH v2 0/5] Add IPMI SSIF support

[Leif Lindholm]

Err, no we haven't.

Although we're in the process of doing that.

/
Leif

On 2024-08-07 08:16, Chang, Abner wrote:

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Pham,
We already move edk2-platforms review through GitHub PR. Could you please send 
the PR against edk2-platforms?

Thanks
Abner


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Nhi Pham
via groups.io
Sent: Wednesday, August 7, 2024 2:47 PM
To: devel@edk2.groups.io
Cc: quic_llind...@quicinc.com; chu...@os.amperecomputing.com;
rebe...@os.amperecomputing.com; n...@os.amperecomputing.com
Subject: [edk2-devel] [edk2-platforms][PATCH v2 0/5] Add IPMI SSIF support

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


This updates the I2C library and implements SMBUS PEI/DXE drivers to
support IPMI SSIF in the Mt. Jade platform.

v2:
- Refine the changes of the DwI2cLib per Leif's comments and update the
   commit message accordingly.
- Remove the additional PCD PcdBmcSlaveAddr since it's is unused.

NOTE: Regarding the controller/target terminology, the function
prototype and comment are derived from edk2/MdePkg. In this patch set, I
am trying to avoid misusing the terms in the implementation instead of
altering the function prototype and comment with the PPI and Protocol.

Nhi Pham (5):
   AmpereAltraPkg/DwI2cLib: Add support for SMBUS+PEC operation
   AmpereSiliconPkg: Define PCDs for SMBUS and BMC
   AmpereAltraPkg: Add SmbusHc PEI and DXE drivers
   JadePkg: Add PlatformBmcReadyLib to support BMC ready check
   Ampere/Jade: Enable IPMI SSIF

  Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec| 
 15 +-
  Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc| 
 23 ++
  Platform/Ampere/JadePkg/Jade.dsc| 
  2 +
  Platform/Ampere/JadePkg/Jade.fdf| 
 17 ++

Platform/Ampere/JadePkg/Library/PlatformBmcReadyLib/PlatformBmcReady
Lib.inf |  29 ++
  Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcDxe.inf|
43 +++
  Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcPei.inf|
43 +++
  Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcCommon.h
|  95 +++
  Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h  | 
 11 +-
  Platform/Ampere/JadePkg/Library/PCF85063RealTimeClockLib/PCF85063.c
|   6 +-

Platform/Ampere/JadePkg/Library/PlatformBmcReadyLib/PlatformBmcReady
Lib.c   |  30 +++
  Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcCommon.c
| 261 ++
  Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcDxe.c  |
277 
  Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcPei.c  |
263 +++
  Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c   | 
129
-
  15 files changed, 1227 insertions(+), 17 deletions(-)
  create mode 100755
Platform/Ampere/JadePkg/Library/PlatformBmcReadyLib/PlatformBmcReady
Lib.inf
  create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcDxe.inf
  create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcPei.inf
  create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcCommon.h
  create mode 100644
Platform/Ampere/JadePkg/Library/PlatformBmcReadyLib/PlatformBmcReady
Lib.c
  create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcCommon.c
  create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcDxe.c
  create mode 100644
Silicon/Ampere/AmpereAltraPkg/Drivers/SmbusHc/SmbusHcPei.c

--
2.25.1











-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120271): https://edk2.groups.io/g/devel/message/120271
Mute This Topic: https://groups.io/mt/107765352/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/2] Switch all platforms to [Peiless]Sec

[Leif Lindholm]

On Thu, Aug 01, 2024 at 10:19:50 -0500, Jeremy Linton wrote:
> Hi,
> 
> 
> On 8/1/24 09:44, Ard Biesheuvel wrote:
> > On Thu, 1 Aug 2024 at 16:11, Ard Biesheuvel  wrote:
> > > 
> > > On Thu, 1 Aug 2024 at 15:49, Jeremy Linton  wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > On 7/31/24 11:33, Ard Biesheuvel wrote:
> > > > > Switch all ARM platforms that use the SEC drivers in 
> > > > > edk2/ArmPlatformPkg
> > > > > to the new versions called Sec or PeilessSec - these have been cleaned
> > > > > up and stripped of obsolete functionality related to multicore boot,
> > > > > which is not something UEFI should concern itself with.
> > > > > 
> > > > > This series can be merged once Tianocore/edk2 PR #5997 is merged 
> > > > > first.
> > > > > After that, ArmPlatformStackLib and the old PrePi / PrePeiCore drivers
> > > > > can be retired.
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > Thanks for cleaning this up, but the rpi4 fails with:
> > > > 
> > > > Decompress GetInfo Failed - Invalid Parameter
> > > > 
> > > > ASSERT_EFI_ERROR (Status = Not Found)
> > > > ASSERT [PeilessSec]
> > > > /home/jlinton/rpi2/edk2/ArmPlatformPkg/PeilessSec/PeilessSec.c(158):
> > > > !(((INTN)(RETURN_STATUS)(Status)) < 0)
> > > > 
> > > 
> > > Weird. I actually tried RPi4 myself. Maybe I should have tried a clean 
> > > rebuild.
> > > 
> > > I'll look into it.
> > 
> > The below should fix it - I'll update all DSCs with this if it works
> > for you as well.
> 
> That fixes the problem above. Thanks!

Can I take that as an R-b on the Rpi changes in this set?

Regards,

Leif


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120252): https://edk2.groups.io/g/devel/message/120252
Mute This Topic: https://groups.io/mt/107649429/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/2] Platform AARCH64: Move PrePeiCore users to Sec.inf

[Leif Lindholm]

On Mon, Aug 05, 2024 at 21:14:33 +0200, Marcin Juszkiewicz wrote:
> On 31.07.2024 18:33, Ard Biesheuvel wrote:
> > PrePeiCore has been superseded by Sec.inf, which is a more common naming
> > for the SEC module, aligned with other architectures. No functional
> > changes intended.
> > 
> > Switch all users to Sec.inf so the old implementation can be retired
> > from EDK2.
> > 
> > Signed-off-by: Ard Biesheuvel
> 
> For Qemu/SbsaQemu:
> 
> Reviewed-by: Marcin Juszkiewicz 

Thanks!

> SbsaQemu does not boot without this patch applied:
> 
> UEFI firmware (version 1.0 built at 21:12:07 on Aug  5 2024)
> add-symbol-file 
> /home/marcin/devel/linaro/sbsa-qemu/code/Build/SbsaQemu/DEBUG_CLANGDWARF/AARCH64/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore/DEBUG/ArmPlatformPrePeiCore.dll
> 0x1800
> add-symbol-file 
> /home/marcin/devel/linaro/sbsa-qemu/code/Build/SbsaQemu/DEBUG_CLANGDWARF/AARCH64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll
> 0x10007240
> Synchronous Exception at 0x0

Because of this breakage, I've pushed 1/2 separately as a3c898956a4d.

/
Leif


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

Re: [edk2-devel] [RFC] Move CompilerIntrinsicsLib and ArmSoftFloatLib to MdePkg

[Leif Lindholm]

Hi Oliver,

On 2024-08-01 23:39, Oliver Smith-Denny wrote:

CompilerIntrinsicsLib and ArmSoftFloatLib add ARM/AARCH64 compiler
intrinsics and floating point functions required by OpenSSL,
respectively. CompilerIntrinsicsLib is used almost in every DSC that
builds ARM/AARCH64 and ArmSoftFloatLib is used by every DSC that builds
logic from OpenSSL. Together these make almost every DSC have a
dependency on ArmPkg, which is odd and for a handful, MdeModulePkg,
EmbeddedPkg, and ShellPkg, namely, it is a circular dependency.

There have been previous mailing list suggestions to move
CompilerIntrinsicsLib to MdePkg (possibly combining with other arch
intrinsics). I am not sure the end status of those conversations. By
moving these two libraries to MdePkg package, we accomplish a few
things:

   - Removing the circular dependency from MdeModulePkg and ShellPkg
     (EmbeddedPkg has other ArmPkg dependencies)

   - Aligning MdePkg as the base package where baseline build and spec
     dependencies are found with other industry standard behavior

   - Detangling ArmPkg and making ARM/AARCH64 more of a first class
     citizen in edk2 instead of bolted onto the side

There is no functional change here and the amount of work is light, but
I think it moves edk2 in the direction it wants to go, so I'm happy to
put up a PR for this, but I wanted to get feedback before I did so. This
aligns with similar efforts, such as moving more ARM/AARCH64 chipset
definitions to MdePkg from ArmPkg [1][2][3]. This also aligns to the
overall goal of deleting ArmPkg:
https://bugzilla.tianocore.org/show_bug.cgi?id=4121


As you might expect, I'm a big fan of this.

Of course, there is still bikeshedding to be done.

For example, if we move ArmSoftFloatLib out of ArmPkg, Should it become 
SoftFloatLib? It's a pretty thin wrapper on the berkley softfloat library.


So yes, please, create the PR :)

Regards,

Leif


Thanks,
Oliver

[1] 
https://github.com/tianocore/edk2/commit/f2b9d5417dccf763bcbb68cd0effed0e25890aab
[2] 
https://github.com/tianocore/edk2/commit/cf323e2839ce260fde43487baae205527dee1b2f
[3] 
https://github.com/tianocore/edk2/commit/c68fb69dfefa7a76ebad33674a49632c4f8c6926




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

Re: [edk2-devel] Can we do something about libspdm?

[Leif Lindholm]

Yes, all better now. Cloning the repo in 7 seconds.

Thanks!

/
Leif

On Thu, Aug 01, 2024 at 09:48:24 +, Yao, Jiewen wrote:
> Thanks Leif. I saw the issue is closed.
> 
> Please evaluate again, to see if the problem is resolved.
> If not, you may reopen the issue at libspdm project.
> 
> Please feel free to submit issue if you see anything could be improved.
> 
> Thank you
> Yao, Jiewen
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Leif Lindholm
> > Sent: Wednesday, July 31, 2024 10:10 PM
> > To: devel@edk2.groups.io; Yao, Jiewen 
> > Cc: Kinney, Michael D ; Andrew Fish
> > 
> > Subject: Re: [edk2-devel] Can we do something about libspdm?
> > 
> > OK, I've raised https://github.com/DMTF/libspdm/issues/2787.
> > 
> > On Wed, Jul 31, 2024 at 12:47:25 +, Yao, Jiewen wrote:
> > > i recommend submitting issue directly to libspdm project github.
> > >
> > > thank you
> > > jiewen yao
> > > 
> > > 发件人: Leif Lindholm 
> > > 发送时间: Wednesday, July 31, 2024 6:34:32 PM
> > > 收件人: devel@edk2.groups.io 
> > > 抄送: Yao, Jiewen ; Kinney, Michael D
> > ; Andrew Fish 
> > > 主题: Can we do something about libspdm?
> > >
> > > Hi,
> > >
> > > The libspdm submodule is 1.1GB of (compressed) data to clone, but only
> > > 18MB once checked out.
> > >
> > > This is by some margin the majority of the time it takes to clone edk2
> > > and submodules. (It takes me 5m44s, and I don't think it's my Internet
> > > connection slowing it down.)
> > >
> > > Having become curious as to how it managed to get that bad, I had a
> > > dig. And found that nearly all of the data comes from a branch (that
> > > is not a branch of the codebase at all) called github_pages.
> > > If I run
> > >   $ git branch -r -d github_pages
> > >   $ git gc --prune=now
> > > the size of my cloned directory shrinks from 1.1GB down to a more
> > > reasonable 27MB.
> > >
> > > Does anyone have any connections at DTMF that we can try to get in
> > > touch with to discuss how to improve their repository setup?
> > >
> > > /
> > > Leif
> > >
> > >
> > >
> > >
> > >
> > 
> > 
> > 
> > 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120185): https://edk2.groups.io/g/devel/message/120185
Mute This Topic: https://groups.io/mt/107643637/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/ ARM AARCH64: Remove ArmPlatformLib MPCore boilerplate

[Leif Lindholm]

On Thu, Aug 01, 2024 at 13:03:48 +0200, Ard Biesheuvel wrote:
> Remove all the ArmPlatformLib routines that are no longer used now that
> the MPCore SEC drivers have been retired. The prototypes will be removed
> from the ArmPlatformLib library class in a subsequent EDK2 change.
> 
> Cc: Leif Lindholm 
> Cc: Abdul Lateef Attar 
> Cc: Abner Chang 
> Cc: Chuong Tran 
> Cc: Graeme Gregory 
> Cc: Marcin Juszkiewicz 
> Cc: Marcin Wojtas 
> Cc: Meenakshi Aggarwal 
> Cc: Narinder Dhillon 
> Cc: Nhi Pham 
> Cc: Paul Grimes 
> Cc: Rebecca Cran 
> Cc: Sami Mujawar 
> Cc: Thomas Abraham 
> Cc: Wenyi Xie 
> Cc: Jeremy Linton 
> Cc: Ling Jia 
> Cc: Peng Xie 
> Cc: Sami Mujawar 
> Cc: Thomas Abraham 
> Cc: Wenyi Xie 
> Cc: Yiqi Shu 
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 
Thanks!

/
Leif

> ---
>  Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c   
>|  4 --
>  Silicon/AMD/Styx/Library/AmdStyxLib/Styx.c   
>|  6 --
>  Platform/ARM/JunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S  
>| 39 
>  Platform/ARM/JunoPkg/Library/ArmJunoLib/Arm/ArmJunoHelper.S  
>| 65 
>  Platform/ARM/Morello/Library/PlatformLib/AArch64/Helper.S
>| 56 -
>  Platform/ARM/SgiPkg/Library/PlatformLib/AArch64/Helper.S 
>| 34 --
>  Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/AArch64/RTSMHelper.S 
>| 41 
>  
> Platform/BeagleBoard/BeagleBoardPkg/Library/BeagleBoardLib/BeagleBoardHelper.S
>   | 22 ---
>  Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKeyHelper.S  
>| 31 --
>  Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960Helper.S 
>| 31 --
>  
> Platform/NXP/LS1043aRdbPkg/Library/ArmPlatformLib/AArch64/ArmPlatformHelper.S 
>   | 33 --
>  
> Platform/NXP/LS1046aFrwyPkg/Library/ArmPlatformLib/AArch64/ArmPlatformHelper.S
>   | 33 --
>  
> Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/AArch64/ArmPlatformHelper.S 
>   | 33 --
>  Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S 
>| 27 
>  Silicon/AMD/Styx/Library/AmdStyxLib/AArch64/Helper.S 
>| 42 -
>  Silicon/ARM/NeoverseN1Soc/Library/PlatformLib/AArch64/Helper.S   
>| 59 --
>  Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformHelper.S 
>| 26 
>  Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/AArch64/Helper.S   
>| 31 --
>  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/AArch64/ArmPlatformHelper.S 
>| 31 --
>  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S 
>| 32 --
>  
> Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S
>  | 47 --
>  Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuHelper.S   
>| 42 -
>  22 files changed, 765 deletions(-)
> 
> diff --git a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c 
> b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
> index eed1a98324b5..24275254815a 100644
> --- a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
> +++ b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSM.c
> @@ -139,10 +139,6 @@ ArmPlatformInitialize (
>IN  UINTN MpId
>)
>  {
> -  if (!ArmPlatformIsPrimaryCore (MpId)) {
> -return RETURN_SUCCESS;
> -  }
> -
>// Disable memory remapping and return to normal mapping
>MmioOr32 (SP810_CTRL_BASE, BIT8);
>  
> diff --git a/Silicon/AMD/Styx/Library/AmdStyxLib/Styx.c 
> b/Silicon/AMD/Styx/Library/AmdStyxLib/Styx.c
> index 6627cecc826a..96bc8b3a2063 100644
> --- a/Silicon/AMD/Styx/Library/AmdStyxLib/Styx.c
> +++ b/Silicon/AMD/Styx/Library/AmdStyxLib/Styx.c
> @@ -68,12 +68,6 @@ ArmPlatformInitialize (
>IN  UINTN MpId
>)
>  {
> -  if (!ArmPlatformIsPrimaryCore (MpId)) {
> -return RETURN_SUCCESS;
> -  }
> -
> -  // XXX Place holder XXX ...
> -
>return RETURN_SUCCESS;
>  }
>  
> diff --git a/Platform/ARM/JunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S 
> b/Platform/ARM/JunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S
> index e8f7d195b2bd..6a73fde3afe5 100644
> --- a/Platform/ARM/JunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S
> +++ b/Platform/ARM/JunoPkg/Library/ArmJunoLib/AArch64/ArmJunoHelper.S
> @@ -9,44 +9,5 @@
>  #include 
>  #

Re: [edk2-devel] [edk2-platforms][PATCH 1/5] AmpereAltraPkg/DwI2cLib: Add SmbusRead() function

[Leif Lindholm]

On Thu, Aug 01, 2024 at 16:36:14 +0700, Nhi Pham via groups.io wrote:
> This adds the SmbusRead() function designed for SMBUS transaction to
> support the extraction of the data lenth byte from the initial byte of
> the SMBUS Block Read, allowing the I2C master to accurately read the
> SMBUS response with the exact data length. This addresses the issue
> where the SmbusLib:SmBusReadBlock() function consistently reads a
> 32-byte block of data.

This change also changes the API to pass the PecCheck parameter,
without actuaklly using it for anyone. Regardless of my previous
comment, I don't think that's very useful.
So if you can't move it to the struct, can you move it to the later
patch instead?

/
Leif

> Signed-off-by: Nhi Pham 
> ---
>  Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h|  31 +
>  Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c | 137 
> +++-
>  2 files changed, 163 insertions(+), 5 deletions(-)
> 
> diff --git a/Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h 
> b/Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h
> index f13794171029..d460f49efccb 100644
> --- a/Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h
> +++ b/Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h
> @@ -65,6 +65,37 @@ I2cRead (
>IN OUT UINT32 *ReadLength
>);
>  
> +/**
> +  SMBUS block read.
> +
> +  @param[in] Bus  I2C bus Id.
> +  @param[in] SlaveAddrThe address of slave device on the bus.
> +  @param[in] BufCmd   Buffer where to send the command.
> +  @param[in] CmdLengthLength of BufCmd.
> +  @param[in,out] Buf  Buffer where to put the read data to.
> +  @param[in,out] ReadLength   Pointer to length of buffer.
> +  @param[in] PecCheck If Packet Error Code (PEC) checking is 
> required for this operation.
> +
> +  @retval EFI_SUCCESSRead successfully.
> +  @retval EFI_INVALID_PARAMETER  A parameter is invalid.
> +  @retval EFI_UNSUPPORTEDThe bus is not supported.
> +  @retval EFI_NOT_READY  The device/bus is not ready.
> +  @retval EFI_TIMEOUTTimeout when transferring data.
> +  @retval EFI_CRC_ERROR  There are errors on receiving data.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +SmbusRead (
> +  IN UINT32  Bus,
> +  IN UINT32  SlaveAddr,
> +  IN UINT8   *BufCmd,
> +  IN UINT32  CmdLength,
> +  IN OUT UINT8   *Buf,
> +  IN OUT UINT32  *ReadLength,
> +  IN BOOLEAN PecCheck
> +  );
> +
>  /**
>   Setup new transaction with I2C slave device.
>  
> diff --git a/Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c 
> b/Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c
> index 669ba2ea98a4..9e52ae69e7cd 100644
> --- a/Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c
> +++ b/Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c
> @@ -337,6 +337,11 @@ I2cWaitTxData (
>DEBUG ((DEBUG_ERROR, "%a: Timeout waiting for TX buffer available\n", 
> __FUNCTION__));
>return EFI_TIMEOUT;
>  }
> +
> +if ((I2cCheckErrors (Bus) & DW_IC_INTR_TX_ABRT) != 0) {
> +  return EFI_ABORTED;
> +}
> +
>  MicroSecondDelay (mI2cBusList[Bus].PollingTime);
>}
>  
> @@ -542,13 +547,61 @@ InternalI2cWrite (
>return Status;
>  }
>  
> +EFI_STATUS
> +InternalSmbusReadDataLength (
> +  UINT32  Bus,
> +  UINT32 *Length
> +  )
> +{
> +  EFI_STATUS Status;
> +  UINTN  Base;
> +  UINT32 CmdSend;
> +
> +  Base = mI2cBusList[Bus].Base;
> +
> +  CmdSend = DW_IC_DATA_CMD_CMD;
> +  MmioWrite32 (Base + DW_IC_DATA_CMD, CmdSend);
> +  I2cSync ();
> +
> +  if (I2cCheckErrors (Bus) != 0) {
> +DEBUG ((DEBUG_ERROR, "%a: Sending reading command error\n", __func__));
> +return EFI_CRC_ERROR;
> +  }
> +
> +  Status = I2cWaitRxData (Bus);
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR,
> +  "%a: Reading Smbus data length failed to wait data\n",
> +  __func__
> +  ));
> +
> +if (Status != EFI_ABORTED) {
> +  MmioWrite32 (Base + DW_IC_DATA_CMD, DW_IC_DATA_CMD_STOP);
> +  I2cSync ();
> +}
> +
> +return Status;
> +  }
> +
> +  *Length = MmioRead32 (Base + DW_IC_DATA_CMD) & DW_IC_DATA_CMD_DAT_MASK;
> +  I2cSync ();
> +
> +  if (I2cCheckErrors (Bus) != 0) {
> +DEBUG ((DEBUG_ERROR, "%a: Sending reading command error\n", __func__));
> +return EFI_CRC_ERROR;
> +  }
> +  return EFI_SUCCESS;
> +}
> +
>  EFI_STATUS
>  InternalI2cRead (
>UINT32  Bus,
> -  UINT8  *BufCmd,
> -  UINT32 CmdLength,
> -  UINT8  *Buf,
> -  UINT32 *Length
> +  UINT8   *BufCmd,
> +  UINT32  CmdLength,
> +  UINT8   *Buf,
> +  UINT32  *Length,
> +  BOOLEAN IsSmbus,
> +  BOOLEAN PecCheck
>)
>  {
>EFI_STATUS Status;
> @@ -559,6 +612,7 @@ InternalI2cRead (
>UINTN  Count;
>UINTN  ReadCount;
>UINTN  WriteCount;
> +  UINT32 ResponseLen;
>  
>Status = EFI_SUCCESS;
>Base = mI2cBusList[Bus].Base;
> @@ -601,6 +655,36 @@ InternalI2cRead (
>}
>  
>WriteCou

Re: [edk2-devel] [edk2-platforms][PATCH 1/5] AmpereAltraPkg/DwI2cLib: Add SmbusRead() function

[Leif Lindholm]

On Thu, Aug 01, 2024 at 16:36:14 +0700, Nhi Pham via groups.io wrote:
> This adds the SmbusRead() function designed for SMBUS transaction to
> support the extraction of the data lenth byte from the initial byte of

length

> the SMBUS Block Read, allowing the I2C master to accurately read the
> SMBUS response with the exact data length. This addresses the issue
> where the SmbusLib:SmBusReadBlock() function consistently reads a
> 32-byte block of data.

Doh, I managed to start reviewing on 2/5 instead 1/5.
Regardless, since this is new code, please update to controller/target
terminology to match current versions of protocol specifications,
throughout the set.

> Signed-off-by: Nhi Pham 
> ---
>  Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h|  31 +
>  Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c | 137 
> +++-
>  2 files changed, 163 insertions(+), 5 deletions(-)
> 
> diff --git a/Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h 
> b/Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h
> index f13794171029..d460f49efccb 100644
> --- a/Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h
> +++ b/Silicon/Ampere/AmpereAltraPkg/Include/Library/I2cLib.h
> @@ -65,6 +65,37 @@ I2cRead (
>IN OUT UINT32 *ReadLength
>);
>  
> +/**
> +  SMBUS block read.
> +
> +  @param[in] Bus  I2C bus Id.
> +  @param[in] SlaveAddrThe address of slave device on the bus.
> +  @param[in] BufCmd   Buffer where to send the command.
> +  @param[in] CmdLengthLength of BufCmd.
> +  @param[in,out] Buf  Buffer where to put the read data to.
> +  @param[in,out] ReadLength   Pointer to length of buffer.
> +  @param[in] PecCheck If Packet Error Code (PEC) checking is 
> required for this operation.
> +
> +  @retval EFI_SUCCESSRead successfully.
> +  @retval EFI_INVALID_PARAMETER  A parameter is invalid.
> +  @retval EFI_UNSUPPORTEDThe bus is not supported.
> +  @retval EFI_NOT_READY  The device/bus is not ready.
> +  @retval EFI_TIMEOUTTimeout when transferring data.
> +  @retval EFI_CRC_ERROR  There are errors on receiving data.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +SmbusRead (
> +  IN UINT32  Bus,
> +  IN UINT32  SlaveAddr,
> +  IN UINT8   *BufCmd,
> +  IN UINT32  CmdLength,
> +  IN OUT UINT8   *Buf,
> +  IN OUT UINT32  *ReadLength,
> +  IN BOOLEAN PecCheck
> +  );
> +
>  /**
>   Setup new transaction with I2C slave device.
>  
> diff --git a/Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c 
> b/Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c
> index 669ba2ea98a4..9e52ae69e7cd 100644
> --- a/Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c
> +++ b/Silicon/Ampere/AmpereAltraPkg/Library/DwI2cLib/DwI2cLib.c
> @@ -337,6 +337,11 @@ I2cWaitTxData (
>DEBUG ((DEBUG_ERROR, "%a: Timeout waiting for TX buffer available\n", 
> __FUNCTION__));
>return EFI_TIMEOUT;
>  }
> +
> +if ((I2cCheckErrors (Bus) & DW_IC_INTR_TX_ABRT) != 0) {
> +  return EFI_ABORTED;
> +}
> +
>  MicroSecondDelay (mI2cBusList[Bus].PollingTime);
>}
>  
> @@ -542,13 +547,61 @@ InternalI2cWrite (
>return Status;
>  }
>  
> +EFI_STATUS
> +InternalSmbusReadDataLength (
> +  UINT32  Bus,
> +  UINT32 *Length
> +  )
> +{
> +  EFI_STATUS Status;
> +  UINTN  Base;
> +  UINT32 CmdSend;
> +
> +  Base = mI2cBusList[Bus].Base;
> +
> +  CmdSend = DW_IC_DATA_CMD_CMD;
> +  MmioWrite32 (Base + DW_IC_DATA_CMD, CmdSend);
> +  I2cSync ();
> +
> +  if (I2cCheckErrors (Bus) != 0) {
> +DEBUG ((DEBUG_ERROR, "%a: Sending reading command error\n", __func__));
> +return EFI_CRC_ERROR;
> +  }
> +
> +  Status = I2cWaitRxData (Bus);
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR,
> +  "%a: Reading Smbus data length failed to wait data\n",
> +  __func__
> +  ));
> +
> +if (Status != EFI_ABORTED) {
> +  MmioWrite32 (Base + DW_IC_DATA_CMD, DW_IC_DATA_CMD_STOP);
> +  I2cSync ();
> +}
> +
> +return Status;
> +  }
> +
> +  *Length = MmioRead32 (Base + DW_IC_DATA_CMD) & DW_IC_DATA_CMD_DAT_MASK;
> +  I2cSync ();
> +
> +  if (I2cCheckErrors (Bus) != 0) {
> +DEBUG ((DEBUG_ERROR, "%a: Sending reading command error\n", __func__));
> +return EFI_CRC_ERROR;
> +  }
> +  return EFI_SUCCESS;
> +}
> +
>  EFI_STATUS
>  InternalI2cRead (
>UINT32  Bus,
> -  UINT8  *BufCmd,
> -  UINT32 CmdLength,
> -  UINT8  *Buf,
> -  UINT32 *Length
> +  UINT8   *BufCmd,
> +  UINT32  CmdLength,
> +  UINT8   *Buf,
> +  UINT32  *Length,
> +  BOOLEAN IsSmbus,

Can this really change on a per-transaction basis?
If not, can it move to a state held in DW_I2C_CONTEXT_T?

> +  BOOLEAN PecCheck

I guess the same question as above really.

/
Leif

>)
>  {
>EFI_STATUS Status;
> @@ -559,6 +612,7 @@ InternalI2cRead (
>UINTN  Count;
>UINTN  ReadCount;
>UINTN  WriteCount;
> +  UINT32 ResponseLen;
>  
>Sta

Re: [edk2-devel] [edk2-platforms][PATCH 2/5] AmpereSiliconPkg: Define PCDs for SMBUS and BMC

[Leif Lindholm]

On Thu, Aug 01, 2024 at 16:36:15 +0700, Nhi Pham wrote:
> This introduces fixed PCDs for SMBUS and BMC as specified to Ampere.
> 
> Signed-off-by: Nhi Pham 
> ---
>  Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec 
> b/Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec
> index 56e8b2fd2f11..5c5015c1bf21 100644
> --- a/Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec
> +++ b/Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec
> @@ -69,6 +69,18 @@ [PcdsFixedAtBuild]
>gAmpereTokenSpaceGuid.PcdSmbiosTables0MajorVersion|0xFF|UINT8|0x0005
>gAmpereTokenSpaceGuid.PcdSmbiosTables0MinorVersion|0xFF|UINT8|0x0006
>  
> +  #
> +  # SMBUS
> +  #
> +  gAmpereTokenSpaceGuid.PcdSmbusI2cBusNumber|0x00|UINT8|0x0007
> +  gAmpereTokenSpaceGuid.PcdSmbusI2cBusSpeed|10|UINT32|0x0008 # Hz
> +
> +  #
> +  # BMC
> +  #
> +  gAmpereTokenSpaceGuid.PcdBmcSlaveAddr|0x10|UINT8|0x0009

Current Smbus specification uses controller/target terminology.

/
Leif

> +  gAmpereTokenSpaceGuid.PcdBmcReadyGpio|0x18|UINT8|0x000A
> +
>  [PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx]
>#
># Firmware Volume Pcds
> -- 
> 2.25.1
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120180): https://edk2.groups.io/g/devel/message/120180
Mute This Topic: https://groups.io/mt/107662236/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 v2 1/1] Move to the GitHub Pull Request workflow

[Leif Lindholm]

On 2024-08-01 13:49, Rebecca Cran wrote:

Replies inline.

On 8/1/24 3:45 AM, Leif Lindholm wrote:

On Sat, Jul 27, 2024 at 14:31:56 -0600, Rebecca Cran wrote:

Migrate data from Maintainers.txt to the GitHub standard CODEOWNERS
files plus REVIEWERS and CONTRIBUTORS.md. The latter file contains
mappings from name to email address and GitHub usernames, which will
help people who want to email maintainers instead of using GitHub.

Add .github/workflows/AssignReviewers.yml which adds reviewers to a
Pull Request based on the content of the REVIEWERS file.

Signed-off-by: Rebecca Cran 
---
  .github/workflows/AssignReviewers.yml |  28 ++
  CODEOWNERS    | 146 +++
  CONTRIBUTORS.md   |  68 +++
  Maintainers.txt   | 445 
  REVIEWERS |  92 
  Readme.md |  32 +-
  6 files changed, 361 insertions(+), 450 deletions(-)

diff --git a/.github/workflows/AssignReviewers.yml 
b/.github/workflows/AssignReviewers.yml

new file mode 100644
index ..8ee95edbb2c1
--- /dev/null
+++ b/.github/workflows/AssignReviewers.yml
@@ -0,0 +1,28 @@
+## @file
+# Assign reviewers from a REVIEWERS file using CODEOWNERS syntax

If we're starting to do manual copying around of files between
repositories, can we add a manual audit trail?

I.e., full URL of repository, path inside repository, and commit hash?

I think my preference would be in this file header.


I'm not sure I understand. This file came from 
https://github.com/mdkinney/github-action-assign-reviewers/blob/main/.github/workflows/AssignReviewers.yml.


Would you like me to add a note to .github/workflows/AssignReviewers.yml 
to say that's where it came from?


I'd like to see it added *somewhere*. Where it came from and the (short) 
commit hash at the version you picked.


If we add it here, then it becomes immediately visible as something to 
update if someone later on copies a newer version on top of it.


Ultimately we might want to add things like this to a common repository 
either directly referenced by CI/codeforge or imported as submodules, so 
that we aren't needing to copy code arounbd between repositories.

But that's not for this patch to resolve.


diff --git a/CODEOWNERS b/CODEOWNERS
new file mode 100644
index ..bc86dd113398
--- /dev/null
+++ b/CODEOWNERS
@@ -0,0 +1,146 @@
...
+# Sophgo platforms and silicon
+/Platform/Sophgo/** @vlsunil
+/Silicon/Sophgo/SG2042Pkg/** @vlsunil

Not super important, but if we're doing this change it would be an
opportunity to re-sort the areas alphabetically, since that broke
somewhere along the way.


Fixed.


Thanks!


diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md
new file mode 100644
index ..84882bcab2fa
--- /dev/null
+++ b/CONTRIBUTORS.md
@@ -0,0 +1,68 @@
+EDK II Platforms Maintainers and Reviewers
+=
+
+This file provides information about the people who maintain and review
+code for EDK II Platforms. For information about who from this file
+maintains (i.e. owns and can commit changes) and who reviews changes in
+various parts of the repo, see the CODEOWNERS and REVIEWERS files.
+
+| Name   | e-mail address   | Github 
username  |

+||--|--|
+| Leif Lindholm  | quic_llind...@quicinc.com    | 
[@leiflindholm](https://github.com/leiflindholm) |

...
+| Marvin H??user  | mhaeu...@posteo.de   | 
[@mhaeuser](https://github.com/mhaeuser) |

Is this charset corruption only in the email?

>
Yes. See 
https://github.com/bcran/edk2-platforms/blob/github-pr/CONTRIBUTORS.md .


Cool, no issue then.

+| Sai Chaganty   | rangasai.v.chaga...@intel.com    | 

...
+| USER0FISH  | libing1...@outlook.com   | 
[@USER0FISH](https://github.com/USER0FISH)   |

Likewise, could we sort this alphabetically by name string?
(If that's annoying, can you push it to a branch where I could pull it
down and sort it?)


Done. Took about 30 seconds (column select mode, copy lines to a file, 
run through `sort`) :)


Excellent, thanks!


diff --git a/Maintainers.txt b/Maintainers.txt
deleted file mode 100644
index 824838486072..
--- a/Maintainers.txt
+++ /dev/null
@@ -1,445 +0,0 @@
,,,
-Any contributions to this branch should be submitted via email to the
-edk2-devel mailing list with a subject prefix of `[platforms]`. See
-[Laszlo's excellent 
guide](https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers) for details

-on how to do this successfully.
+Any contributions to this branch should be submitted via GitHub Pull 
Request,
+or email to

Re: [edk2-devel] [PATCH edk2-platforms v2 1/1] Move to the GitHub Pull Request workflow

[Leif Lindholm]

ntel/** @nate-desimone @SaiChaganty
> +/Platform/Intel/QuarkPlatformPkg/** @mdkinney @nate-desimone @SaiChaganty
> +/Platform/Intel/Vlv2TbltDevicePkg/** @zailiangsun @yqian4 @nate-desimone 
> @SaiChaganty
> +/Platform/Intel/BoardModulePkg/** @ydong10 @nate-desimone @SaiChaganty
> +/Platform/Intel/KabylakeOpenBoardPkg/** @ChaselChiu @nate-desimone 
> @SaiChaganty
> +/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/** @benjamindoron 
> @nate-desimone @SaiChaganty
> +/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/** @jackpot51
> +/Platform/Intel/MinPlatformPkg/** @ChaselChiu @nate-desimone @SaiChaganty
> +/Platform/Intel/PurleyOpenBoardPkg/** @nate-desimone @ChaselChiu @SaiChaganty
> +/Platform/Intel/WhiskeylakeOpenBoardPkg/** @nate-desimone @SaiChaganty 
> @ChaselChiu
> +/Platform/Intel/CometlakeOpenBoardPkg/** @ChaselChiu @nate-desimone 
> @SaiChaganty
> +/Platform/Intel/TigerlakeOpenBoardPkg/** @SaiChaganty @nate-desimone
> +/Platform/Intel/AlderlakeOpenBoardPkg/** @nate-desimone @SaiChaganty
> +/Platform/Intel/WhitleyOpenBoardPkg/** @ChaselChiu  @nate-desimone 
> @SaiChaganty
> +/Platform/Intel/SimicsOpenBoardPkg/** @nate-desimone @SaiChaganty
> +/Platform/Intel/Tools/** @BobCF @lgao4 @nate-desimone @SaiChaganty
> +
> +/Platform/RISC-V/PlatformPkg/** @vlsunil
> +
> +/Platform/SiFive/U5SeriesPkg/** @JohnAZoidberg
> +
> +/Silicon/Intel/** @nate-desimone @SaiChaganty
> +/Silicon/Intel/IntelSiliconPkg/** @niruiyu @nate-desimone @SaiChaganty
> +/Silicon/Intel/QuarkSocPkg/** @mdkinney @nate-desimone @SaiChaganty
> +/Silicon/Intel/Vlv2DeviceRefCodePkg/** @zailiangsun @yqian4 @nate-desimone 
> @SaiChaganty
> +/Silicon/Intel/CoffeelakeSiliconPkg/** @ChaselChiu @SaiChaganty 
> @nate-desimone
> +/Silicon/Intel/KabylakeSiliconPkg/** @ChaselChiu @SaiChaganty @nate-desimone
> +/Silicon/Intel/PurleyRefreshSiliconPkg/** @ChaselChiu @nate-desimone 
> @SaiChaganty
> +/Silicon/Intel/TigerlakeSiliconPkg/** @SaiChaganty @nate-desimone
> +/Silicon/Intel/AlderlakeSiliconPkg/** @SaiChaganty @nate-desimone
> +/Silicon/Intel/WhitleySiliconPkg/** @nate-desimone @ChaselChiu @SaiChaganty
> +/Silicon/Intel/SimicsX58SktPkg/** @nate-desimone @SaiChaganty
> +/Silicon/Intel/SimicsIch10Pkg/** @nate-desimone @SaiChaganty
> +/Silicon/Intel/Tools/** @BobCF @lgao4 @nate-desimone @SaiChaganty
> +
> +# Loongson platforms
> +# Add Bibo Mao, Xianglai li and Chao Li
> +# /Platform/Loongson/**
> + 
> +# Marvell platforms and silicon
> +/Platform/Marvell/** @wojtas-marcin @ndhillonm
> +/Platform/SolidRun/** @wojtas-marcin @ndhillonm
> +/Silicon/Marvell/** @wojtas-marcin @ndhillonm
> +
> +# Miscellaneous drivers
> +/Silicon/Atmel/** @leiflindholm
> +/Silicon/Openmoko/** @leiflindholm
> +/Silicon/Synopsys/DesignWare/** @leiflindholm
> +
> +# NXP platforms and silicon
> +/Platform/NXP/** @leiflindholm
> +/Silicon/NXP/** @leiflindholm
> +
> +# QEMU EDK II Minimum Platform Specification implementation
> +/Platform/Qemu/QemuOpenBoardPkg/** @heatd
> +
> +# QEMU sbsa-ref platform
> +/Platform/Qemu/SbsaQemu/** @ardbiesheuvel @leiflindholm @hrw
> +/Silicon/Qemu/SbsaQemu/** @ardbiesheuvel @leiflindholm @hrw
> +
> +# Raspberry Pi platforms and silicon
> +/Platform/RaspberryPi/** @ardbiesheuvel @leiflindholm
> +/Silicon/Broadcom/** @ardbiesheuvel @leiflindholm
> +
> +# RPMB driver for OP-TEE
> +/Drivers/OpTee/OpteeRpmbPkg/** @apalos @samimujawar
> +
> +# Socionext platforms and silicon
> +/Platform/Socionext/** @ardbiesheuvel @leiflindholm
> +/Silicon/NXP/Library/Pcf8563RealTimeClockLib/** @ardbiesheuvel @leiflindholm
> +/Silicon/Socionext/** @ardbiesheuvel @leiflindholm
> +
> +/Silicon/RISC-V/ProcessorPkg/** @vlsunil
> +
> +/Silicon/SiFive/** @JohnAZoidberg
> +
> +# Phytium platforms and silicon
> +/Platform/Phytium/** @leiflindholm
> +/Silicon/Phytium/** @leiflindholm
> +
> +# Sophgo platforms and silicon
> +/Platform/Sophgo/** @vlsunil
> +/Silicon/Sophgo/SG2042Pkg/** @vlsunil

Not super important, but if we're doing this change it would be an
opportunity to re-sort the areas alphabetically, since that broke
somewhere along the way.

> diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md
> new file mode 100644
> index ..84882bcab2fa
> --- /dev/null
> +++ b/CONTRIBUTORS.md
> @@ -0,0 +1,68 @@
> +EDK II Platforms Maintainers and Reviewers
> +=
> +
> +This file provides information about the people who maintain and review
> +code for EDK II Platforms. For information about who from this file
> +maintains (i.e. owns and can commit changes) and who reviews changes in
> +various parts of the repo, see the CODEOWNERS and REVIEWERS files.
> +
> +| Name   | e-mail address

Re: [edk2-devel] Can we do something about libspdm?

[Leif Lindholm]

OK, I've raised https://github.com/DMTF/libspdm/issues/2787.

On Wed, Jul 31, 2024 at 12:47:25 +, Yao, Jiewen wrote:
> i recommend submitting issue directly to libspdm project github.
> 
> thank you
> jiewen yao
> ____
> 发件人: Leif Lindholm 
> 发送时间: Wednesday, July 31, 2024 6:34:32 PM
> 收件人: devel@edk2.groups.io 
> 抄送: Yao, Jiewen ; Kinney, Michael D 
> ; Andrew Fish 
> 主题: Can we do something about libspdm?
> 
> Hi,
> 
> The libspdm submodule is 1.1GB of (compressed) data to clone, but only
> 18MB once checked out.
> 
> This is by some margin the majority of the time it takes to clone edk2
> and submodules. (It takes me 5m44s, and I don't think it's my Internet
> connection slowing it down.)
> 
> Having become curious as to how it managed to get that bad, I had a
> dig. And found that nearly all of the data comes from a branch (that
> is not a branch of the codebase at all) called github_pages.
> If I run
>   $ git branch -r -d github_pages
>   $ git gc --prune=now
> the size of my cloned directory shrinks from 1.1GB down to a more
> reasonable 27MB.
> 
> Does anyone have any connections at DTMF that we can try to get in
> touch with to discuss how to improve their repository setup?
> 
> /
> Leif
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120151): https://edk2.groups.io/g/devel/message/120151
Mute This Topic: https://groups.io/mt/107643637/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/Beagle/PrePi: Fix build after ArmLib refactor

[Leif Lindholm]

On Wed, Jul 31, 2024 at 12:59:40 +0200, Ard Biesheuvel wrote:
> The Chipset/ sub-directories no longer exist and the code has been moved
> into MdePkg. Update the includes accordingly.
> 
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 
Thanks!

> ---
>  Platform/BeagleBoard/BeagleBoardPkg/PrePi/Arm/ModuleEntryPoint.S | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Platform/BeagleBoard/BeagleBoardPkg/PrePi/Arm/ModuleEntryPoint.S 
> b/Platform/BeagleBoard/BeagleBoardPkg/PrePi/Arm/ModuleEntryPoint.S
> index 46c1498b969f..505ee0a5ce07 100644
> --- a/Platform/BeagleBoard/BeagleBoardPkg/PrePi/Arm/ModuleEntryPoint.S
> +++ b/Platform/BeagleBoard/BeagleBoardPkg/PrePi/Arm/ModuleEntryPoint.S
> @@ -7,7 +7,8 @@
>  
>  #include 
>  
> -#include 
> +#include 
> +#include 
>  
>  ASM_FUNC(_ModuleEntryPoint)
>// Do early platform specific actions
> -- 
> 2.46.0.rc1.232.g9752f9e123-goog
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120147): https://edk2.groups.io/g/devel/message/120147
Mute This Topic: https://groups.io/mt/107643974/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/2] Platform/Socionext: Fix line endings

[Leif Lindholm]

On Wed, Jul 31, 2024 at 12:52:27 +0200, Ard Biesheuvel wrote:
> Use CR-LF as required for DSC files.
> 
> Signed-off-by: Ard Biesheuvel 

For the series:
Reviewed-by: Leif Lindholm 
Thanks!

> ---
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc 
> b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
> index 02b5d6f41a4f..650c83d0e196 100644
> --- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
> +++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
> @@ -83,7 +83,7 @@ [LibraryClasses]
>SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
> -  
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
> +  
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
>  
># BDS Libraries
>
> UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> -- 
> 2.46.0.rc1.232.g9752f9e123-goog
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120145): https://edk2.groups.io/g/devel/message/120145
Mute This Topic: https://groups.io/mt/107643852/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/2] Platform/Beagle: Fix DSC line endings

[Leif Lindholm]

On Wed, Jul 31, 2024 at 12:42:03 +0200, Ard Biesheuvel wrote:
> Use CR-LF as required for DSC files.
> 
> Signed-off-by: Ard Biesheuvel 

For the series:
Reviewed-by: Leif Lindholm 
Thanks!

> ---
>  Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.dsc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.dsc 
> b/Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.dsc
> index 1ba4c3dc465e..a114c9b633d0 100644
> --- a/Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.dsc
> +++ b/Platform/BeagleBoard/BeagleBoardPkg/BeagleBoardPkg.dsc
> @@ -93,7 +93,7 @@ [LibraryClasses.common]
>
> UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
>DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
>
> UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
> -  
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
> +  
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
>  
>
> DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf
>
> UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
> -- 
> 2.46.0.rc1.232.g9752f9e123-goog
> 


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

[edk2-devel] Can we do something about libspdm?

[Leif Lindholm]

Hi,

The libspdm submodule is 1.1GB of (compressed) data to clone, but only
18MB once checked out.

This is by some margin the majority of the time it takes to clone edk2
and submodules. (It takes me 5m44s, and I don't think it's my Internet
connection slowing it down.)

Having become curious as to how it managed to get that bad, I had a
dig. And found that nearly all of the data comes from a branch (that
is not a branch of the codebase at all) called github_pages.
If I run
  $ git branch -r -d github_pages
  $ git gc --prune=now
the size of my cloned directory shrinks from 1.1GB down to a more
reasonable 27MB.

Does anyone have any connections at DTMF that we can try to get in
touch with to discuss how to improve their repository setup?

/
Leif


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

Re: [edk2-devel] [PATCH RFC edk2-platforms 0/5] Phase out MPCore SEC drivers

[Leif Lindholm]

On 2024-07-30 16:18, Ard Biesheuvel wrote:


Sure, that works for me.
I've released the stuck messages.


I probably need to subscribe ardb+...@google.com to the mailing list,
which is the from" address when I send patches from my google dev
machine.


To be clear though, in the moderation system every single one of your
emails of the last few days are stuck with a different, obnoxious, email
address as the sender. It's not ardb+...@google.com.



flex is an internal service to handle outgoing email, and I am using
the internal git send-email helper built on top of that. I am not
aware of any recent changes that would have provoked a change in
behavior, and I see the same type of return paths on outgoing emails
sent a year ago.


If that's true, then someone much more diligent than me has been 
manually releasing every patch you've sent, *or* something changed on 
the groups.io side recently.


/
Leif



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

Re: [edk2-devel] [PATCH RFC edk2-platforms 0/5] Phase out MPCore SEC drivers

[Leif Lindholm]

On 2024-07-30 16:00, Ard Biesheuvel wrote:

On Tue, 30 Jul 2024 at 16:49, Leif Lindholm  wrote:


On 2024-07-30 15:30, Rebecca Cran wrote:

Ard,


It looks like your original message didn't make it through to the list.

I don't see it on https://edk2.groups.io/g/devel/messages or in my
personal email client.


Huh, indeed.

groups.io seems upset that google's email setup has enabled some new
form of ... something... Everything gets stuck in moderation with unique
generated Return-Path ending in ardb.bounces.google.com
I.e. for this specific email:

Return-Path:
3gimnzggkdw0lcom+rterzzrwp.nzxbftn_wwtyoszwbftntyn@flex--ardb.bounces.google.com

Ard, can you look into what they're smoking over there?



*swizzling your response around*

> I am not going to bother with that, though, as we'll soon switch to
> github for edk2-platforms. In the mean time, I can use another machine
> to send out patches if needed.

Sure, that works for me.
I've released the stuck messages.


I probably need to subscribe ardb+...@google.com to the mailing list,
which is the from" address when I send patches from my google dev
machine.


To be clear though, in the moderation system every single one of your 
emails of the last few days are stuck with a different, obnoxious, email 
address as the sender. It's not ardb+...@google.com.


/
Leif










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

Re: [edk2-devel] [PATCH RFC edk2-platforms 0/5] Phase out MPCore SEC drivers

[Leif Lindholm]

On 2024-07-30 15:30, Rebecca Cran wrote:

Ard,


It looks like your original message didn't make it through to the list.

I don't see it on https://edk2.groups.io/g/devel/messages or in my 
personal email client.


Huh, indeed.

groups.io seems upset that google's email setup has enabled some new 
form of ... something... Everything gets stuck in moderation with unique 
generated Return-Path ending in ardb.bounces.google.com

I.e. for this specific email:

Return-Path: 
3gimnzggkdw0lcom+rterzzrwp.nzxbftn_wwtyoszwbftntyn@flex--ardb.bounces.google.com


Ard, can you look into what they're smoking over there?

/
Leif



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120080): https://edk2.groups.io/g/devel/message/120080
Mute This Topic: https://groups.io/mt/107626521/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 AARCH64: Drop bogus local copy of gArmMpCoreInfoPpiGuid GUID

[Leif Lindholm]

On Mon, Jul 29, 2024 at 15:16:00 +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> There is a pattern that has been copy-pasted a number of times where a
> missing references in the INFs [Ppis] section is 'fixed' by creating a
> local GUID variable.

Eew.

> Fix all of those.
> 
> This is just a janitorial patch with no functional changes so fixing all
> of these in one go.
> 
> Cc: Leif Lindholm 
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 
Thanks!

/
Leif

> ---
>  Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKeyLib.inf  | 3 
> +++
>  Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960Lib.inf | 3 
> +++
>  Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf | 3 
> +++
>  Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf| 3 
> +++
>  Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf | 3 
> +++
>  Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKey.c   | 4 
> +---
>  Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960.c  | 4 
> +---
>  Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.c   | 4 
> +---
>  Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.c  | 4 
> +---
>  Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c   | 7 
> +--
>  10 files changed, 20 insertions(+), 18 deletions(-)
> 
> diff --git a/Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKeyLib.inf 
> b/Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKeyLib.inf
> index 18b74bc42ef4..2a6ae8a4bb9f 100644
> --- a/Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKeyLib.inf
> +++ b/Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKeyLib.inf
> @@ -35,6 +35,9 @@ [Sources.common]
>  [Sources.AARCH64]
>HiKeyHelper.S
>  
> +[Ppis]
> +  gArmMpCoreInfoPpiGuid
> +
>  [FixedPcd]
>gArmTokenSpaceGuid.PcdArmPrimaryCore
>gArmTokenSpaceGuid.PcdArmPrimaryCoreMask
> diff --git a/Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960Lib.inf 
> b/Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960Lib.inf
> index 81167c76f95c..5ccf4a11d5e2 100644
> --- a/Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960Lib.inf
> +++ b/Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960Lib.inf
> @@ -31,6 +31,9 @@ [Sources.common]
>HiKey960Helper.S
>HiKey960Mem.c
>  
> +[Ppis]
> +  gArmMpCoreInfoPpiGuid
> +
>  [FixedPcd]
>gArmTokenSpaceGuid.PcdArmPrimaryCore
>gArmTokenSpaceGuid.PcdArmPrimaryCoreMask
> diff --git 
> a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf 
> b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
> index a61da278c705..ffeb28d8a901 100644
> --- a/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
> +++ b/Silicon/Ampere/AmpereAltraPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
> @@ -37,6 +37,9 @@ [Packages]
>Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dec
>Silicon/Ampere/AmpereSiliconPkg/AmpereSiliconPkg.dec
>  
> +[Ppis]
> +  gArmMpCoreInfoPpiGuid
> +
>  [Pcd]
>gArmTokenSpaceGuid.PcdMmBufferBase
>gArmTokenSpaceGuid.PcdMmBufferSize
> diff --git 
> a/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf 
> b/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf
> index 83c3f4bf193f..2ab649019aa0 100644
> --- a/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf
> +++ b/Silicon/Hisilicon/Library/ArmPlatformLibHisilicon/ArmPlatformLib.inf
> @@ -39,6 +39,9 @@ [Sources.common]
>  [Sources.AARCH64]
>AArch64/Helper.S
>  
> +[Ppis]
> +  gArmMpCoreInfoPpiGuid
> +
>  [FixedPcd]
>gArmTokenSpaceGuid.PcdSystemMemoryBase
>gArmTokenSpaceGuid.PcdSystemMemorySize
> diff --git a/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf 
> b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf
> index 11134b8fc497..c7b3368ac9e1 100644
> --- a/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf
> +++ b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf
> @@ -35,6 +35,9 @@ [Sources.AARCH64]
>  
>  [Guids]
>  
> +[Ppis]
> +  gArmMpCoreInfoPpiGuid
> +
>  [FixedPcd]
>gPhytiumPlatformTokenSpaceGuid.PcdSystemIoBase
>gPhytiumPlatformTokenSpaceGuid.PcdSystemIoSize
> diff --git a/Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKey.c 
> b/Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKey.c
> index 801d63398524..057d566bde67 100644
> --- a/Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKey.c
> +++ b/Platform/Hisilicon/HiKey/Library/HiKeyLib/HiKey.c
> @@ -117,14 +117,12 @@ PrePeiCoreGetMpCoreInfo (
>return EFI_

Re: [edk2-devel] [PATCH RFC edk2-platforms 0/5] Phase out MPCore SEC drivers

[Leif Lindholm]

On Mon, Jul 29, 2024 at 14:22:10 +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> The original EDK2 port to 32-bit ARM supported multi-core but on today's
> ARM systems, only a single CPU enters the non-secure firmware and the
> MPCore drivers are obsolete.
> 
> Stop using them in edk2-platforms so we can remove them entirely from
> edk2.
> 
> Cc: Leif Lindholm 
> Cc: Rebecca Cran 
> Cc: Nhi Pham 
> Cc: Chuong Tran 
> Cc: Wenyi Xie 
> Cc: Peng Xie 
> Cc: Ling Jia 
> Cc: Yiqi Shu 

For the series:
Reviewed-by: Leif Lindholm 
Thanks!

> Ard Biesheuvel (5):
>   Platform AARCH64: Drop leftover references to deleted timer PCD
>   Platform AARCH64: Remove bogus references to MPCore stack
>   Platform/Ampere: Switch to unicore SEC implementation
>   Platform/Durian: Switch to unicore SEC implementation
>   Platform/HiSilicon/D0x: Switch to unicore SEC implementation
> 
>  Platform/ARM/Morello/MorelloPlatform.dsc.inc|  2 --
>  Platform/ARM/SgiPkg/SgiPlatform.dsc.inc |  2 --
>  Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc|  6 +-
>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc   |  1 -
>  Platform/AMD/OverdriveBoard/OverdriveBoard.dsc  |  2 --
>  Platform/ARM/N1Sdp/N1SdpPlatform.dsc|  2 --
>  Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc|  2 --
>  Platform/Hisilicon/D03/D03.dsc  |  3 +--
>  Platform/Hisilicon/D05/D05.dsc  | 10 +-
>  Platform/Hisilicon/D06/D06.dsc  |  3 +--
>  Platform/LeMaker/CelloBoard/CelloBoard.dsc  |  2 --
>  Platform/Phytium/DurianPkg/DurianPkg.dsc|  2 +-
>  Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc |  2 --
>  Platform/Ampere/JadePkg/Jade.fdf|  2 +-
>  Platform/Hisilicon/D03/D03.fdf  |  2 +-
>  Platform/Hisilicon/D05/D05.fdf  |  2 +-
>  Platform/Hisilicon/D06/D06.fdf  |  2 +-
>  Platform/Phytium/DurianPkg/DurianPkg.fdf|  2 +-
>  18 files changed, 10 insertions(+), 39 deletions(-)
> 
> --
> 2.46.0.rc1.232.g9752f9e123-goog
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120076): https://edk2.groups.io/g/devel/message/120076
Mute This Topic: https://groups.io/mt/107626521/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 v2 0/8] RPi: Drop EmbeddedPkg reset runtime

[Leif Lindholm]

On Sun, Jul 28, 2024 at 22:44:27 +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> The EmbeddedPkg runtime DXE is being retired in favour of the generic
> one in MdeModulePkg which is actually being maintained.
> 
> RPi uses this driver and the associated EfiResetSystemLib, of which it
> has an implementation with value-add for reset notification. So this
> logic needs to be moved elsewhere and hooked up to the generic protocols
> that implement the same.
> 
> Changes since v1:
> - boot tested
> - add patch to fix pre-existing issue that causes a crash when DmaLib
>   attempts to set EFI_MEMORY_XP on allocated buffers
> - add a patch to force the correct dispatch order for the varstore
>   related drivers
> - fix line endings

For the added commits:
Reviewed-by: Leif Lindholm 


> Cc: Leif Lindholm 
> Cc: Jeremy Linton 
> 
> Ard Biesheuvel (8):
>   Platform/RaspberryPi: Mark RAM regions as write/execute protectable
>   Platform/RaspberryPi: Fix line endings in DSCs
>   Platform/RaspberryPi: Use depex based dispatch order for varstore
>   Platform/RaspberryPi/VarBlockServiceDxe: Refactor DumpVars event
> handler
>   Platform/RaspberryPi/VarBlockServiceDxe: Register for reset
> notification
>   Platform/RaspberryPi/PlatformBootManagerLib: Reimplement reset hook
>   Platform/RaspberryPi: Switch to generic reset runtime
>   Platform/RaspberryPi: Drop platform specific EfiResetSystemLib
> 
>  Platform/RaspberryPi/RaspberryPi.dec 
>   |   1 -
>  Platform/RaspberryPi/RPi3/RPi3.dsc   
>   |  15 +-
>  Platform/RaspberryPi/RPi4/RPi4.dsc   
>   |  15 +-
>  Platform/RaspberryPi/RPi3/RPi3.fdf   
>   |   2 +-
>  Platform/RaspberryPi/RPi4/RPi4.fdf   
>   |   2 +-
>  Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf   
>   |   6 +-
>  
> Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>  |   6 +
>  Platform/RaspberryPi/Library/ResetLib/ResetLib.inf   
>   |  45 --
>  Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c 
>   |  65 ++---
>  Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c 
>   |   2 +
>  Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c 
>   |  77 ++
>  Platform/RaspberryPi/Library/ResetLib/ResetLib.c 
>   | 151 
>  12 files changed, 156 insertions(+), 231 deletions(-)
>  delete mode 100644 Platform/RaspberryPi/Library/ResetLib/ResetLib.inf
>  delete mode 100644 Platform/RaspberryPi/Library/ResetLib/ResetLib.c
> 
> --
> 2.46.0.rc1.232.g9752f9e123-goog
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120075): https://edk2.groups.io/g/devel/message/120075
Mute This Topic: https://groups.io/mt/107626473/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 5/5] Platform/RaspberryPi: Drop platform specific EfiResetSystemLib

[Leif Lindholm]

On Thu, Jul 25, 2024 at 12:43:30 +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> Drop the now unused EfiResetSystemLib implementation, which has been
> superseded by the generic one from EDK2.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
>  Platform/RaspberryPi/RaspberryPi.dec   |   1 
> -
>  Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf |   1 
> -
>  Platform/RaspberryPi/Library/ResetLib/ResetLib.inf |  45 
> --
>  Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c   |  11 
> --
>  Platform/RaspberryPi/Library/ResetLib/ResetLib.c   | 151 
> 
>  5 files changed, 209 deletions(-)
> 
> diff --git a/Platform/RaspberryPi/RaspberryPi.dec 
> b/Platform/RaspberryPi/RaspberryPi.dec
> index 6bd16a5ae9fd..a5fa1fb00c48 100644
> --- a/Platform/RaspberryPi/RaspberryPi.dec
> +++ b/Platform/RaspberryPi/RaspberryPi.dec
> @@ -24,7 +24,6 @@ [Protocols]
>  
>  [Guids]
>gRaspberryPiTokenSpaceGuid = {0xCD7CC258, 0x31DB, 0x11E6, {0x9F, 0xD3, 
> 0x63, 0xB0, 0xB8, 0xEE, 0xD6, 0xB5}}
> -  gRaspberryPiEventResetGuid = {0xCD7CC258, 0x31DB, 0x11E6, {0x9F, 0xD3, 
> 0x63, 0xB4, 0xB4, 0xE4, 0xD4, 0xB4}}
>gConfigDxeFormSetGuid = {0xCD7CC258, 0x31DB, 0x22E6, {0x9F, 0x22, 0x63, 
> 0xB0, 0xB8, 0xEE, 0xD6, 0xB5}}

*loud sigh at looking those "GUIDs"*
But that's not this set's fault.

For the series:
Reviewed-by: Leif Lindholm 
Thanks!

/
Leif

>  [PcdsFixedAtBuild.common]
> diff --git 
> a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf 
> b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf
> index 6456153fd3ab..53391466a77b 100644
> --- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf
> +++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf
> @@ -52,7 +52,6 @@ [LibraryClasses]
>  
>  [Guids]
>gEfiEventVirtualAddressChangeGuid
> -  gRaspberryPiEventResetGuid
>gEfiEventReadyToBootGuid
>  
>  [Protocols]
> diff --git a/Platform/RaspberryPi/Library/ResetLib/ResetLib.inf 
> b/Platform/RaspberryPi/Library/ResetLib/ResetLib.inf
> deleted file mode 100644
> index 9bdb94a52ebf..
> --- a/Platform/RaspberryPi/Library/ResetLib/ResetLib.inf
> +++ /dev/null
> @@ -1,45 +0,0 @@
> -#/** @file
> -#
> -#  Reset System lib using PSCI hypervisor or secure monitor calls.
> -#  Signals the gRaspberryPiEventResetGuid event group on reset.
> -#
> -#  Copyright (c) 2018, Andrei Warkentin 
> -#  Copyright (c) 2014, Linaro Ltd. All rights reserved.
> -#  Copyright (c) 2014, ARM Ltd. All rights reserved.
> -#  Copyright (c) 2008, Apple Inc. All rights reserved.
> -#
> -#  SPDX-License-Identifier: BSD-2-Clause-Patent
> -#
> -#**/
> -
> -[Defines]
> -  INF_VERSION= 0x0001001A
> -  BASE_NAME  = ResetLib
> -  FILE_GUID  = B9F59B69-A105-41C7-8F5A-2C60DD7FD7AB
> -  MODULE_TYPE= BASE
> -  VERSION_STRING = 1.0
> -  LIBRARY_CLASS  = EfiResetSystemLib
> -
> -[Sources]
> -  ResetLib.c
> -
> -[Packages]
> -  ArmPkg/ArmPkg.dec
> -  MdePkg/MdePkg.dec
> -  EmbeddedPkg/EmbeddedPkg.dec
> -  Platform/RaspberryPi/RaspberryPi.dec
> -
> -[LibraryClasses]
> -  DebugLib
> -  BaseLib
> -  ArmSmcLib
> -  PcdLib
> -  TimerLib
> -  UefiLib
> -  UefiRuntimeLib
> -
> -[Guids]
> -  gRaspberryPiEventResetGuid
> -
> -[Pcd]
> -  gRaspberryPiTokenSpaceGuid.PcdPlatformResetDelay  ## CONSUMES
> diff --git 
> a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c 
> b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c
> index 81dfb95e323c..04414b142c7e 100644
> --- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c
> +++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c
> @@ -262,20 +262,9 @@ InstallDumpVarEventHandlers (
>)
>  {
>EFI_STATUS   Status;
> -  EFI_EVENTResetEvent;
>EFI_EVENTReadyToBootEvent;
>EFI_RESET_NOTIFICATION_PROTOCOL  *ResetNotify;
>  
> -  Status = gBS->CreateEventEx (
> -  EVT_NOTIFY_SIGNAL,
> -  TPL_CALLBACK,
> -  DumpVarsOnEvent,
> -  NULL,
> -  &gRaspberryPiEventResetGuid,
> -  &ResetEvent
> -);
> -  ASSERT_EFI_ERROR (Status);
> -
>Status = gBS->CreateEventEx (
>EVT_NOTIFY_SIGNAL,
>

Re: [edk2-devel] [PATCH edk2-platforms 00/11] Phase out ArmSmcPsciResetSystemLib

[Leif Lindholm]

On Thu, Jul 25, 2024 at 10:24:51 +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> ArmSmcPsciResetSystemLib is being replaced with a generic implementation
> that is shared between physical and virtual placement, executing at
> either EL2 or EL1.
> 
> So update all library class resolutions for ResetSystemLib and provide
> additional resolutions for its dependency on ArmMonitorLib. This series
> depends on [0] which removes dependencies on ArmHvcLib and ArmSmcLib
> from the generic version of ArmMonitorLib being used here, so no
> resolutions are provided for those.
> 
> Patches #1 and #2 are unrelated fixes.
> 
> Cc: Leif Lindholm 

For the series:
Reviewed-by: Leif Lindholm 

Thanks for this cleanup!

> Ard Biesheuvel (11):
>   Platform,Silicon: Fix line endings
>   Silicon/SynQuacer: Fix CLANGDWARF build
>   Platform/AMD/Styx: Switch to generic ArmPsciResetSystemLib
>   Platform/ARM: Switch to generic ArmPsciResetSystemLib
>   Platform/SbsaQemu: Switch to generic ArmPsciResetSystemLib
>   Platform/SynQuacer: Switch to generic ArmPsciResetSystemLib
>   Silicon/Ampere: Switch to generic ArmPsciResetSystemLib
>   Silicon/HiSilicon: Switch to generic ArmPsciResetSystemLib
>   Silicon/Armada7k8k: Switch to generic ArmPsciResetSystemLib
>   Silicon/NxpQoriqLs: Switch to generic ArmPsciResetSystemLib
>   Silicon/Phytium: Switch to generic ArmPsciResetSystemLib
> 
>  Platform/ARM/SgiPkg/SgiPlatform.dsc.inc  | 3 ++-
>  Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 3 ++-
>  Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 3 ++-
>  Silicon/Hisilicon/Hisilicon.dsc.inc  | 5 +++--
>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc| 3 ++-
>  Silicon/NXP/NxpQoriqLs.dsc.inc   | 3 ++-
>  Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc| 3 ++-
>  Platform/AMD/OverdriveBoard/OverdriveBoard.dsc   | 5 +++--
>  Platform/LeMaker/CelloBoard/CelloBoard.dsc   | 5 +++--
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc  | 3 ++-
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 5 +++--
>  Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 5 +++--
>  Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc  | 5 +++--
>  Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.inf| 3 +--
>  Silicon/Socionext/SynQuacer/Stage2Tables/Stage2Tables.S  | 4 ++--
>  15 files changed, 35 insertions(+), 23 deletions(-)
> 
> --
> 2.46.0.rc1.232.g9752f9e123-goog
> 


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

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

[Leif Lindholm]

On Sun, Jul 21, 2024 at 16:51:54 +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> The reset runtime DXE driver is deprecated and will be removed soon. It
> is superseded by a generic implementation in MdeModulePkg, which is
> shared between all architectures, and implements the notification
> protocols that the EFI spec describes. So move the Ampere Jade platform
> to this implementation the of ResetSystem EFI runtime service.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
>  Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 3 +--
>  Platform/Ampere/JadePkg/Jade.fdf | 2 +-
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc 
> b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
> index 1f705c68579a..fb170d436d00 100644
> --- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
> +++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
> @@ -259,7 +259,6 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>  !endif
>
> VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
>  
> -  
> EfiResetSystemLib|ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf

Would it make sense to move the existing ResetSystemLib mapping here?
Not for any particular reason other than it's not actually used
anywhere else.

Regardless, for the series:
Reviewed-by: Leif Lindholm 

Thanks!

>ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
>
> NVParamLib|Silicon/Ampere/AmpereAltraPkg/Library/NVParamLib/RuntimeNVParamLib.inf
>
> AmpereCpuLib|Silicon/Ampere/AmpereAltraPkg/Library/AmpereCpuLib/RuntimeAmpereCpuLib.inf
> @@ -588,7 +587,7 @@ [Components.common]
>  !endif
>MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
>
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
> -  EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
> +  MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
>ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
> diff --git a/Platform/Ampere/JadePkg/Jade.fdf 
> b/Platform/Ampere/JadePkg/Jade.fdf
> index 7795f0e5..127e4401f69b 100644
> --- a/Platform/Ampere/JadePkg/Jade.fdf
> +++ b/Platform/Ampere/JadePkg/Jade.fdf
> @@ -222,7 +222,7 @@ [FV.FvMain]
>INF 
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
>  !endif
>INF 
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
> -  INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
> +  INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
>INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> -- 
> 2.45.2.1089.g2a221341d9-goog
> 


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

[edk2-devel] Remove Deprecated ArmPsciResetSystemLib #5922

[Leif Lindholm]

Hi all,

Please see conversation in https://github.com/tianocore/edk2/pull/5922

Would Ampere and Phytium platforms be able to move off
EmbeddedPkg/ResetRuntimeDxe to
MdeModulePkg/Universal/ResetSystemRuntimeDxe so we can drop the
deprecated ArmPsciResetSystemLib?

Oh, and could you please provide patches for edk2-platforms
Maintainers.txt adding your github IDs in [] after your email addresses,
so I know how to loop everyone in on github conversations easily?

For example:
Leif Lindholm  [leiflindholm]

/
Leif


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

Re: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc: add .gitattributes to ensure right line endings in .sh .bat

[Leif Lindholm]

On 2024-07-18 07:47, Jayaprakash, N wrote:

Regarding the below comment from Lief.

Now, as for the suggestion: this isn't wrong, but can you explain what problem 
it is solving?

<> As a developer and also as a maintainer the lines endings have been
a consistent problem as I have seen patches coming with mixed line > endings some times it take quite a while to fix these simple line> 

ending issues.

I agree it's annoying, but if it takes a noticeable amount of time to 
fix, it sounds to me like you're manually editing things that tools can 
do for you. (Admittedly, git is one of those tools.) And as Mike says, 
there's the helper scripts and CI.



I want to start small through .gtiattributes usage for the .sh and
.bat scripts to normalize the line endings to LF so that irrespective
of the user environment the line endings are always stored as LF in
git repo but presented to the users in LF or CRLF as per their
environment. Thought of using this feature of github in a lower scale
to make it easy for the developers and maintainers of the edk2-libc project.

If there is a general alignment that this change need not go,
then I will close the BZ as won't fix.


Like I said, there's nothing actually *wrong* about doing what you 
propose. It's more a question of how we maintain (or not) consistency 
between, and within, the repos.


Do we keep edk2-libc as a special thing on the side?
If so I guess it could keep its own .gitattributes.
If not, it should use the one in edk2/BaseTools.
If so, that affects all the repos.

If it affects all the repos, why specifically .sh and .bat?
Yes, it doesn't break the build if it sneaks into a .c file, or a .inf, 
but it breaks CI. Sometimes. So should we specify .c, .h, .inf, .dsc, 
.dec, .py, .vfr as well?


As it stands, I'd prefer to leave this alone until do the CRLF->LF 
conversion and can migrate to core.autocrlf=auto. At that point, I 
expect most of these mixups will go away. And if they don't, we could 
always revisit then.


I do intend to get back to the CRLF->LF conversion work once the shock 
from the Github-PR switch has settled.


Regards,

Leif


Regards,
JP

-Original Message-
From: Leif Lindholm 
Sent: Wednesday, July 17, 2024 7:55 PM
To: devel@edk2.groups.io; Jayaprakash, N ; Kinney, Michael D 

Cc: Rebecca Cran 
Subject: Re: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc: add .gitattributes 
to ensure right line endings in .sh .bat

Hi,

The address I am replying from is the email address I use for tianocore work. 
Messages sent elsewhere are going to end up misfiled and likely lost.

On 2024-07-17 06:55, Jayaprakash, N wrote:

Hi Lefi,

Do you have any recommendations on this?

Regards,
JP

-Original Message-
From: Kinney, Michael D 
Sent: Friday, July 12, 2024 9:29 PM
To: Jayaprakash, N ; devel@edk2.groups.io;
Leif Lindholm 
Cc: Rebecca Cran ; Kinney, Michael D

Subject: RE: [edk2-libc Patch 1/1] edk2-libc: add .gitattributes to
ensure right line endings in .sh .bat

+ Leif

.gitattributes is not used in other TianoCore repos.


Technically sort of correct, but see below.


This feature changes the line endings locally when checked out.

Instead, the edk2 repo uses a CI check like PatchCheck.py to make sure files 
with specific extensions have the correct line endings when they are checked in 
and files are checked out unmodified.

I know Leif has been evaluating some line ending changes to TianoCore Repos.  
Don't know if this direction is in alignment with those ideas or not.

Mike


-Original Message-
From: Jayaprakash, N 
Sent: Friday, July 12, 2024 7:27 AM
To: devel@edk2.groups.io
Cc: Jayaprakash, N ; Rebecca Cran
; Kinney, Michael D 
Subject: [edk2-libc Patch 1/1] edk2-libc: add .gitattributes to
ensure right line endings in .sh .bat

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

This commit adds .gitattributes file with the right settings to
preserve the correct line endings for .sh and .bat files as per the
Linxu and Windows line ending conventions respectively.

  >>

Cc: Rebecca Cran 
Cc: Michael D Kinney 
Cc: Jayaprakash N 
Signed-off-by: Jayaprakash N 
---
   .gitattributes | 2 ++
   1 file changed, 2 insertions(+)
   create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes new file mode 100644
index 000..3fd9ec8
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,2 @@
+*.bat text eol=crlf
+*.sh text eol=lf
\ No newline at end of file


^ This is not a good look for any submission, but especially not one dealing 
with line endings. Please manually look at patches before sending them out.

Now, as for the suggestion: this isn't wrong, but can you explain what problem 
it is solving?

I had a look in edk2-libc and all the .sh files have LF line endings and all 
the .bat files have CRLF line endings.

Now, if we *did* want to do this, I would strongly prefer a patch to 
edk2/BaseTools/Conf/gitattribute

Re: [edk2-devel] [edk2-libc Patch 1/1] edk2-libc: add .gitattributes to ensure right line endings in .sh .bat

[Leif Lindholm]

Hi,

The address I am replying from is the email address I use for tianocore 
work. Messages sent elsewhere are going to end up misfiled and likely lost.


On 2024-07-17 06:55, Jayaprakash, N wrote:

Hi Lefi,

Do you have any recommendations on this?

Regards,
JP

-Original Message-
From: Kinney, Michael D 
Sent: Friday, July 12, 2024 9:29 PM
To: Jayaprakash, N ; devel@edk2.groups.io; Leif Lindholm 

Cc: Rebecca Cran ; Kinney, Michael D 

Subject: RE: [edk2-libc Patch 1/1] edk2-libc: add .gitattributes to ensure 
right line endings in .sh .bat

+ Leif

.gitattributes is not used in other TianoCore repos.


Technically sort of correct, but see below.


This feature changes the line endings locally when checked out.

Instead, the edk2 repo uses a CI check like PatchCheck.py to make sure files 
with specific extensions have the correct line endings when they are checked in 
and files are checked out unmodified.

I know Leif has been evaluating some line ending changes to TianoCore Repos.  
Don't know if this direction is in alignment with those ideas or not.

Mike


-Original Message-
From: Jayaprakash, N 
Sent: Friday, July 12, 2024 7:27 AM
To: devel@edk2.groups.io
Cc: Jayaprakash, N ; Rebecca Cran
; Kinney, Michael D 
Subject: [edk2-libc Patch 1/1] edk2-libc: add .gitattributes to ensure
right line endings in .sh .bat

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

This commit adds .gitattributes file with the right settings to
preserve the correct line endings for .sh and .bat files as per the
Linxu and Windows line ending conventions respectively.

>>

Cc: Rebecca Cran 
Cc: Michael D Kinney 
Cc: Jayaprakash N 
Signed-off-by: Jayaprakash N 
---
  .gitattributes | 2 ++
  1 file changed, 2 insertions(+)
  create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes new file mode 100644
index 000..3fd9ec8
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,2 @@
+*.bat text eol=crlf
+*.sh text eol=lf
\ No newline at end of file


^ This is not a good look for any submission, but especially not one 
dealing with line endings. Please manually look at patches before 
sending them out.


Now, as for the suggestion: this isn't wrong, but can you explain what 
problem it is solving?


I had a look in edk2-libc and all the .sh files have LF line endings and 
all the .bat files have CRLF line endings.


Now, if we *did* want to do this, I would strongly prefer a patch to 
edk2/BaseTools/Conf/gitattributes, which is applied in any repo 
SetupGit.py has been executed in.


But ultimately I want to convert the repos completely to LF line endings 
except for where special cases exist (which *should* be described in 
[.]gitattributes) and then move to enable core.autocrlf.


/
Leif


--
2.45.1.windows.1











-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119953): https://edk2.groups.io/g/devel/message/119953
Mute This Topic: https://groups.io/mt/107182920/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 v3 4/5] SbsaQemu: provide cache info per core in PPTT

[Leif Lindholm]

On Wed, Jul 10, 2024 at 14:58:52 +0100, Jonathan Cameron wrote:
> On Tue, 9 Jul 2024 14:01:53 +0100
> "Leif Lindholm"  wrote:
> 
> > On Tue, Jul 09, 2024 at 12:47:09 +0200, Marcin Juszkiewicz wrote:
> > > During Linaro Connect MAD24 I was asked to move cache information from
> > > being 'per cluster' to be 'per core'. This is a move for implementing
> > > MPAM support.
> > > 
> > > So topology moves from:
> > > 
> > > Socket -> Clusters -> Cores + Caches -> Threads (if exist)
> > > 
> > > to:
> > > 
> > > Socket -> Clusters -> Cores -> Caches + Threads (if exist)
> > > 
> > > Cache sizes are still 32+32+512KB (L1d, L1i, L2) as QEMU does not
> > > implement them at all so we can tell whatever.
> 
> They should match the system registers.
> CCSIDR etc which are provided by QEMU.

That's a good point. Thanks for bringing that up.

edk2-platforms/Platform/Ampere/JadePkg/Drivers/AcpiPlatformDxe/AcpiPptt.c
demonstrates how this can be done with existing edk2 interfaces and
definitions.

Ultimately, this will only ever be possible to runtime-generate in
edk2 for homogenous systems. Any big-little type setups need to get
the information from TF-A.

/
Leif

> Here's some old code for doing PPTT cache entry generation for arm-virt.
> 
> https://lore.kernel.org/qemu-devel/20230808115713.2613-2-jonathan.came...@huawei.com/
> 
> The numbers might happen to match what it has for the cpu you are using 
> though.
> https://elixir.bootlin.com/qemu/latest/source/target/arm/tcg/cpu64.c#L1051
> 
> For n2 that looks to be 64+64+512...
> 
> 
> 
> > > 
> > > Signed-off-by: Marcin Juszkiewicz   
> > 
> > Reviewed-by: Leif Lindholm 
> > 
> > /
> > Leif
> > 
> > > ---
> > >  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 47 
> > > +++-
> > >  1 file changed, 25 insertions(+), 22 deletions(-)
> > > 
> > > diff --git 
> > > a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> > > b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> > > index cf0102d11f1f..a7a9664abdcb 100644
> > > --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> > > +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> > > @@ -562,8 +562,8 @@ AddPpttTable (
> > >TableSize = sizeof (EFI_ACPI_DESCRIPTION_HEADER) +
> > >CpuTopo.Sockets * (sizeof 
> > > (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR) +
> > >   CpuTopo.Clusters * (sizeof 
> > > (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR) +
> > > - sizeof 
> > > (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE) * 3 +
> > >   CpuTopo.Cores * 
> > > (sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR) +
> > > +  
> > > sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE) * 3 +
> > >
> > > sizeof (UINT32) * 2)));
> > >  
> > >if (CpuTopo.Threads > 1) {
> > > @@ -609,10 +609,7 @@ AddPpttTable (
> > >  
> > >  ClusterIndex = SocketIndex + sizeof 
> > > (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
> > >  for (ClusterNum = 0; ClusterNum < CpuTopo.Clusters; ClusterNum++) {
> > > -  L1DCacheIndex = ClusterIndex + sizeof 
> > > (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
> > > -  L1ICacheIndex = L1DCacheIndex + sizeof 
> > > (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> > > -  L2CacheIndex  = L1ICacheIndex + sizeof 
> > > (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> > > -  CoreIndex = L2CacheIndex + sizeof 
> > > (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> > > +  CoreIndex = ClusterIndex + sizeof 
> > > (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
> > >  
> > >// Add the Cluster PPTT structure
> > >EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR  Cluster = 
> > > SBSAQEMU_ACPI_PROCESSOR_HIERARCHY_NODE_STRUCTURE_INIT (
> > > @@ -624,27 +621,15 @@ AddPpttTable (
> > >CopyMem (New, &Cluster, sizeof 
> > > (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR));
> > >New += sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
> > >  
> > > -  // Add L1 D Cache structure
> > > -  L1DCache.Ca

Re: [edk2-devel] github impact:breaking-change

[Leif Lindholm]

Hi Michael,

On Tue, Jul 09, 2024 at 10:44:46 -0400, Michael Kubacki wrote:
> Hi Leif,
> 
> Thanks for raising this. The label was intended to be set from the PR
> template which has an explanation:
> 
> https://github.com/tianocore/edk2/blob/master/.github/pull_request_template.md
> 
> If the breaking change box is checked, it will be added automatically.

Right, so it seems some people have misunderstood the description in
the template.

The current text is
"Breaking change - Will this cause a break in build or boot behavior?"

I raised https://github.com/tianocore/edk2/pull/5895 for some minor
language tweaks that hopefully reduce the risk of misinterpretation.

> I added a description in GitHub for the label as well:
> 
> https://github.com/tianocore/edk2/labels

Thanks!

Regards,

Leif

> 
> Thanks,
> Michael
> 
> On 7/8/2024 7:00 AM, Leif Lindholm wrote:
> > Hi,
> > 
> > I'm seeing something in several PRs in flight (and merged) that have
> > "impact:breaking-change" set, where the purpose of the PR is to fix said
> > breakage, not introduce API compatibilities.
> > 
> > Am I correct in my understanding that this is not the intended use, and
> > if so how do we address the misconception?
> > Can we start by adding a description for the label? It currently has none.
> > 
> > Mu uses "Requires integration attention", which matches my
> > understanding, but feels a bit abstract. How about
> > "This change breaks existing APIs"
> > or
> > "This change may require corresponding updates to code in other
> > repositories"?
> > 
> > /
> >      Leif
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119851): https://edk2.groups.io/g/devel/message/119851
Mute This Topic: https://groups.io/mt/107100295/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 v3 5/5] SbsaQemu: introduce helper in PPTT generation

[Leif Lindholm]

On Tue, Jul 09, 2024 at 15:12:37 +0200, Marcin Juszkiewicz wrote:
> Dnia wtorek, 9 lipca 2024 15:00:12 CEST Leif Lindholm via groups.io pisze:
> > On Tue, Jul 09, 2024 at 12:47:10 +0200, Marcin Juszkiewicz wrote:
> > > Function AddPpttTable() adding PPTT got too long. This change moves part
> > > of it into helper function AddCoresToPpttTable() which takes care of
> > > generating entries for Core and below (Cache, Thread).
> > > 
> > > Signed-off-by: Marcin Juszkiewicz 
> > > ---
> > > 
> > >  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   | 237
> > >  +++- 1 file changed, 133 insertions(+), 104 deletions(-)
> > > 
> > > diff --git
> > > a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> > > b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c index
> > > a7a9664abdcb..a4b2ee2fdcb0 100644
> > > --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> > > +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> > > @@ -29,6 +29,9 @@
> > > 
> > >  static UINTN  GicItsBase;
> > > 
> > > +static UINTN  CpuId;
> > > +static UINTN  CacheId;
> > > +
> > 
> > static variables are supposed to have g (global) or m (module) prefix.
> > This is local, so m.
> > (Yes, that means I missed that when reviewing the GitIts bits.)
> > 
> > Also, why are these in a #pragma pack(1) block?
> 
> Added right after GicItsBase. Moved out of block.

I don't think it makes any sense for GicItsBase either, but that's not
part of this review.

> > >  #pragma pack ()
>  
> > STATIC
> > 
> > > +UINT32
> > > +AddCoresToPpttTable (
> > > +  UINT8*New,
> > > +  UINT32   ClusterIndex,
> > > +  CpuTopology  CpuTopo
> > > +  )
> 
> done
> 
> > > -  ClusterIndex = CoreIndex;
> > > +  CoresPartSize = AddCoresToPpttTable (New, ClusterIndex, CpuTopo);
> > > +  ClusterIndex += CoresPartSize;
> > 
> > This sounds like ClisterIndex is no longer an Index after this patch.
> > Should it be renamed?
> 
> It is still an Index. CoresPartSize is a size taken by Core/Cache/Thread part 
> of this Cluster.

But doesn't that make it an offset instead of an index?

/
Leif

> 
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119844): https://edk2.groups.io/g/devel/message/119844
Mute This Topic: https://groups.io/mt/107120147/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 v3 4/5] SbsaQemu: provide cache info per core in PPTT

[Leif Lindholm]

On Tue, Jul 09, 2024 at 12:47:09 +0200, Marcin Juszkiewicz wrote:
> During Linaro Connect MAD24 I was asked to move cache information from
> being 'per cluster' to be 'per core'. This is a move for implementing
> MPAM support.
> 
> So topology moves from:
> 
> Socket -> Clusters -> Cores + Caches -> Threads (if exist)
> 
> to:
> 
> Socket -> Clusters -> Cores -> Caches + Threads (if exist)
> 
> Cache sizes are still 32+32+512KB (L1d, L1i, L2) as QEMU does not
> implement them at all so we can tell whatever.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 

/
Leif

> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 47 
> +++-
>  1 file changed, 25 insertions(+), 22 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index cf0102d11f1f..a7a9664abdcb 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -562,8 +562,8 @@ AddPpttTable (
>TableSize = sizeof (EFI_ACPI_DESCRIPTION_HEADER) +
>CpuTopo.Sockets * (sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR) +
>   CpuTopo.Clusters * (sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR) +
> - sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE) * 3 +
>   CpuTopo.Cores * (sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR) +
> +  sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE) * 3 +
>sizeof 
> (UINT32) * 2)));
>  
>if (CpuTopo.Threads > 1) {
> @@ -609,10 +609,7 @@ AddPpttTable (
>  
>  ClusterIndex = SocketIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
>  for (ClusterNum = 0; ClusterNum < CpuTopo.Clusters; ClusterNum++) {
> -  L1DCacheIndex = ClusterIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
> -  L1ICacheIndex = L1DCacheIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> -  L2CacheIndex  = L1ICacheIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> -  CoreIndex = L2CacheIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> +  CoreIndex = ClusterIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
>  
>// Add the Cluster PPTT structure
>EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR  Cluster = 
> SBSAQEMU_ACPI_PROCESSOR_HIERARCHY_NODE_STRUCTURE_INIT (
> @@ -624,27 +621,15 @@ AddPpttTable (
>CopyMem (New, &Cluster, sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR));
>New += sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
>  
> -  // Add L1 D Cache structure
> -  L1DCache.CacheId = CacheId++;
> -  CopyMem (New, &L1DCache, sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE));
> -  ((EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE *)New)->NextLevelOfCache = 
> L2CacheIndex;
> -  New += sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> -
> -  // Add L1 I Cache structure
> -  L1ICache.CacheId = CacheId++;
> -  CopyMem (New, &L1ICache, sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE));
> -  ((EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE *)New)->NextLevelOfCache = 
> L2CacheIndex;
> -  New += sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> -
> -  // Add L2 Cache structure
> -  L2Cache.CacheId = CacheId++;
> -  CopyMem (New, &L2Cache, sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE));
> -  New += sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> -
>for (CoreNum = 0; CoreNum < CpuTopo.Cores; CoreNum++) {
>  UINT32  *PrivateResourcePtr;
>  UINT32  CoreCpuId;
>  
> +// two UINT32s for PrivateResourcePtr data
> +L1DCacheIndex = CoreIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR) + sizeof (UINT32) * 2;
> +L1ICacheIndex = L1DCacheIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> +L2CacheIndex  = L1ICacheIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> +
>  if (CpuTopo.Threads == 1) {
>CoreCpuId = CpuId;
>  } else {
> @@ -665,6 +650,23 @@ AddPpttTable (
>  PrivateResourcePtr[1] = L1ICacheIndex;
>  New  += (2 * sizeof (UINT32));
>  
> +// Add L1 D Cache structure
> +L1DCache.C

Re: [edk2-devel] [PATCH edk2-platforms v3 5/5] SbsaQemu: introduce helper in PPTT generation

[Leif Lindholm]

On Tue, Jul 09, 2024 at 12:47:10 +0200, Marcin Juszkiewicz wrote:
> Function AddPpttTable() adding PPTT got too long. This change moves part
> of it into helper function AddCoresToPpttTable() which takes care of
> generating entries for Core and below (Cache, Thread).
> 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   | 237 
> +++-
>  1 file changed, 133 insertions(+), 104 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index a7a9664abdcb..a4b2ee2fdcb0 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -29,6 +29,9 @@
>  
>  static UINTN  GicItsBase;
>  
> +static UINTN  CpuId;
> +static UINTN  CacheId;
> +

static variables are supposed to have g (global) or m (module) prefix.
This is local, so m.
(Yes, that means I missed that when reviewing the GitIts bits.)

Also, why are these in a #pragma pack(1) block?

>  #pragma pack ()
>  
>  /*
> @@ -491,6 +494,126 @@ AddSsdtTable (
>return Status;
>  }
>  

STATIC

> +UINT32
> +AddCoresToPpttTable (
> +  UINT8*New,
> +  UINT32   ClusterIndex,
> +  CpuTopology  CpuTopo
> +  )
> +{
> +  UINT32  L1DCacheIndex;
> +  UINT32  L1ICacheIndex;
> +  UINT32  L2CacheIndex;
> +  UINT32  CoreIndex;
> +  UINT32  Index;
> +  UINT32  CoreCpuId;
> +  UINT32  CoreNum;
> +  UINT32  ThreadNum;
> +  UINT32  *PrivateResourcePtr;
> +
> +  EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR_FLAGS  CoreFlags = {
> +EFI_ACPI_6_5_PPTT_PACKAGE_NOT_PHYSICAL,
> +EFI_ACPI_6_5_PPTT_PROCESSOR_ID_VALID,
> +EFI_ACPI_6_5_PPTT_PROCESSOR_IS_NOT_THREAD,
> +EFI_ACPI_6_5_PPTT_NODE_IS_LEAF,
> +EFI_ACPI_6_5_PPTT_IMPLEMENTATION_IDENTICAL
> +  };
> +
> +  if (CpuTopo.Threads > 1) {
> +// The Thread structure is the leaf structure, adjust the value of 
> CoreFlags.
> +CoreFlags.AcpiProcessorIdValid = EFI_ACPI_6_5_PPTT_PROCESSOR_ID_INVALID;
> +CoreFlags.NodeIsALeaf  = EFI_ACPI_6_5_PPTT_NODE_IS_NOT_LEAF;
> +  }
> +
> +  EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR_FLAGS  ThreadFlags = {
> +EFI_ACPI_6_5_PPTT_PACKAGE_NOT_PHYSICAL,
> +EFI_ACPI_6_5_PPTT_PROCESSOR_ID_VALID,
> +EFI_ACPI_6_5_PPTT_PROCESSOR_IS_THREAD,
> +EFI_ACPI_6_5_PPTT_NODE_IS_LEAF,
> +EFI_ACPI_6_5_PPTT_IMPLEMENTATION_IDENTICAL
> +  };
> +
> +  EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE  L1DCache = 
> SBSAQEMU_ACPI_PPTT_L1_D_CACHE_STRUCT;
> +  EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE  L1ICache = 
> SBSAQEMU_ACPI_PPTT_L1_I_CACHE_STRUCT;
> +  EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE  L2Cache  = 
> SBSAQEMU_ACPI_PPTT_L2_CACHE_STRUCT;
> +
> +  CoreIndex = ClusterIndex + sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
> +  Index = CoreIndex;
> +
> +  for (CoreNum = 0; CoreNum < CpuTopo.Cores; CoreNum++) {
> +if (CpuTopo.Threads == 1) {
> +  CoreCpuId = CpuId;
> +} else {
> +  CoreCpuId = 0;
> +}
> +
> +// space for Core + PrivateResourcePtr
> +Index += sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
> +Index += sizeof (UINT32) * 2;
> +
> +L1DCacheIndex = Index;
> +L1ICacheIndex = L1DCacheIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> +L2CacheIndex  = L1ICacheIndex + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> +
> +EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR  Core = 
> SBSAQEMU_ACPI_PROCESSOR_HIERARCHY_NODE_STRUCTURE_INIT (
> +CoreFlags,
> +ClusterIndex,
> +CoreCpuId,
> +2
> +);
> +
> +CopyMem (New, &Core, sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR));
> +New += sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR);
> +
> +PrivateResourcePtr= (UINT32 *)New;
> +PrivateResourcePtr[0] = L1DCacheIndex;
> +PrivateResourcePtr[1] = L1ICacheIndex;
> +New  += (2 * sizeof (UINT32));
> +
> +// Add L1 D Cache structure
> +L1DCache.CacheId = CacheId++;
> +CopyMem (New, &L1DCache, sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE));
> +((EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE *)New)->NextLevelOfCache = 
> L2CacheIndex;
> +New += sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> +
> +// Add L1 I Cache structure
> +L1ICache.CacheId = CacheId++;
> +CopyMem (New, &L1ICache, sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE));
> +((EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE *)New)->NextLevelOfCache = 
> L2CacheIndex;
> +New += sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE);
> +
> +// Add L2 Cache structure
> +L2Cache.CacheId = CacheId++;
> +CopyMem (New, &L2Cache, sizeof (EFI

Re: [edk2-devel] [PATCH edk2-platforms v3 3/5] SbsaQemu: update PPTT to ACPI 6.5

[Leif Lindholm]

On Tue, Jul 09, 2024 at 12:47:08 +0200, Marcin Juszkiewicz wrote:
> ACPI 6.5 is the newest version of specification so far. The only change

"The only functional change..."

With that:
Reviewed-by: Leif Lindholm 

/
Leif

> to make is handling of CacheId (has to be unique and higher than zero).
> 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h   |   4 +-
>  .../Include/IndustryStandard/SbsaQemuAcpi.h |  46 ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   | 127 
> ++--
>  3 files changed, 94 insertions(+), 83 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> index 085c681ba55f..5aaf02e3ca30 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> @@ -90,8 +90,8 @@ typedef struct {
>  
>  #define SBSAQEMU_ACPI_PROCESSOR_HIERARCHY_NODE_STRUCTURE_INIT(Flags, Parent, 
> ACPIProcessorID, NumberOfPrivateResources) \
>{  
>\
> -EFI_ACPI_6_3_PPTT_TYPE_PROCESSOR,
> /* Type */ \
> -sizeof (EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR) + 
> NumberOfPrivateResources * sizeof (UINT32), /* Length */  
>  \
> +EFI_ACPI_6_5_PPTT_TYPE_PROCESSOR,
> /* Type */ \
> +sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR) + 
> NumberOfPrivateResources * sizeof (UINT32), /* Length */  
>  \
>  { EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE },  
> /* Reserved */ \
>  Flags,   
> /* Flags */\
>  Parent,  
> /* Parent */   \
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> index 2f87591e737a..fa2e2b30bb7d 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> @@ -87,13 +87,13 @@ typedef struct {
>  #define SBSAQEMU_L2_CACHE_ASSC  8
>  
>  #define CLUSTER_INDEX (sizeof (EFI_ACPI_DESCRIPTION_HEADER))
> -#define L1_D_CACHE_INDEX  (CLUSTER_INDEX + sizeof 
> (EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR))
> -#define L1_I_CACHE_INDEX  (L1_D_CACHE_INDEX + sizeof 
> (EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE))
> -#define L2_CACHE_INDEX(L1_I_CACHE_INDEX + sizeof 
> (EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE))
> +#define L1_D_CACHE_INDEX  (CLUSTER_INDEX + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR))
> +#define L1_I_CACHE_INDEX  (L1_D_CACHE_INDEX + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE))
> +#define L2_CACHE_INDEX(L1_I_CACHE_INDEX + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE))
>  
>  #define SBSAQEMU_ACPI_PPTT_L1_D_CACHE_STRUCT  {  
>   \
> -EFI_ACPI_6_3_PPTT_TYPE_CACHE,
>   \
> -sizeof (EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE),  
>   \
> +EFI_ACPI_6_5_PPTT_TYPE_CACHE,
>   \
> +sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_CACHE),  
>   \
>  { EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE },  
>   \
>  {
>   \
>1,   /* SizePropertyValid */   
>   \
> @@ -103,22 +103,24 @@ typedef struct {
>1,   /* CacheTypeValid */  
>   \
>1,   /* WritePolicyValid */
>   \
>1,   /* LineSizeValid */   
>   \
> +  1,   /* CacheIdValid */
>   \
>  },   
>   \
>  0, /* NextLevelOfCache */
>   \
>  SBSAQEMU_L1_D_CACHE_SIZE,  /* Size */
>   \
>  SBSAQEMU_L1_D_CACHE_SETS,  /

Re: [edk2-devel] [PATCH edk2-platforms v3 2/5] SbsaQemu: align the PPTT tables with QEMU

[Leif Lindholm]

On Tue, Jul 09, 2024 at 12:47:07 +0200, Marcin Juszkiewicz wrote:
> From: Xiong Yining 
> 
> To align the CPU topology information recognized by the operating system
> with the CPU topology information configured by QEMU, we need to make
> use of the CPU topology information to create complex PPTT tables
> setups.
> 
> We can get the CPU topology information via SMC.
> 
> Signed-off-by: Xiong Yining 
> Signed-off-by: Marcin Juszkiewicz 


Reviewed-by: Leif Lindholm 

/
Leif

> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h   |  11 ++
>  .../Include/IndustryStandard/SbsaQemuAcpi.h |  32 
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   | 187 
> +++-
>  3 files changed, 158 insertions(+), 72 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> index e5f0748bb16e..085c681ba55f 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> @@ -88,4 +88,15 @@ typedef struct {
>  ClockDomain /* Clock Domain */   
>  \
>}
>  
> +#define SBSAQEMU_ACPI_PROCESSOR_HIERARCHY_NODE_STRUCTURE_INIT(Flags, Parent, 
> ACPIProcessorID, NumberOfPrivateResources) \
> +  {  
>\
> +EFI_ACPI_6_3_PPTT_TYPE_PROCESSOR,
> /* Type */ \
> +sizeof (EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR) + 
> NumberOfPrivateResources * sizeof (UINT32), /* Length */  
>  \
> +{ EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE },  
> /* Reserved */ \
> +Flags,   
> /* Flags */\
> +Parent,  
> /* Parent */   \
> +ACPIProcessorID, 
> /* ACPI Processor ID */\
> +NumberOfPrivateResources 
> /* Number of private resources */  \
> +  }
> +
>  #endif
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> index ae151210c2c6..2f87591e737a 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> @@ -166,36 +166,4 @@ typedef struct {
>  64/* LineSize */ 
>   \
>}
>  
> -#define SBSAQEMU_ACPI_PPTT_CLUSTER_STRUCT  { 
>   \
> -EFI_ACPI_6_3_PPTT_TYPE_PROCESSOR,
>   \
> -sizeof (EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR),  
>   \
> -{ EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE },  
>   \
> -{
>   \
> -  EFI_ACPI_6_3_PPTT_PACKAGE_PHYSICAL, /* PhysicalPackage */  
>   \
> -  EFI_ACPI_6_3_PPTT_PROCESSOR_ID_INVALID, /* AcpiProcessorIdValid */ 
>   \
> -  EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD,  /* Is not a Thread */  
>   \
> -  EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF, /* Not Leaf */ 
>   \
> -  EFI_ACPI_6_3_PPTT_IMPLEMENTATION_IDENTICAL, /* Identical Cores */  
>   \
> -},   
>   \
> -0,/* Parent */   
>   \
> -0,/* AcpiProcessorId */  
>   \
> -0,/* NumberOfPrivateResources */ 
>   \
> -  }
> -
> -#define SBSAQEMU_ACPI_PPTT_CORE_STRUCT  {
>   \
> -EFI_ACPI_6_3_PPTT_TYPE_PROCESSOR,
>   \
> -(sizeof (EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR) + (2 * sizeof 
> (UINT32))),  \
> -{ EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE },  
>   \
> -{
>   \
> -  EFI_ACPI_

Re: [edk2-devel] [PATCH edk2-platforms v3 1/5] SbsaQemu: get the information of CPU topology via SMC calls

[Leif Lindholm]

On 2024-07-09 13:40, Leif Lindholm wrote:

On Tue, Jul 09, 2024 at 12:47:06 +0200, Marcin Juszkiewicz wrote:

Provide functions to check for CPU topology information:
  - the number of sockets on sbsa-ref platform.
  - the number of clusters in one socket.
  - the number of cores in one cluster.
  - the number of threads in one core.

As SMC calls can return up to 4 return values, the number of sockets,
clusters and cores are read from TF-A using platform specific SMC call.
Number of threads is caluculated using the cpu count and the number of
sockets, clusters and cores.

Signed-off-by: Xiong Yining 
Signed-off-by: Marcin Juszkiewicz 
---
  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  |  1 +
  .../Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h  | 26 ++
  .../SbsaQemuHardwareInfoLib.c| 36 
  3 files changed, 63 insertions(+)

diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
index af6b120561ad..b57573735ace 100644
--- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
+++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
@@ -16,6 +16,7 @@
  #define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
  #define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
  #define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
+#define SIP_SVC_GET_CPU_TOPOLOGY   SMC_SIP_FUNCTION_ID(202)
  #define SIP_SVC_GET_MEMORY_NODE_COUNT  SMC_SIP_FUNCTION_ID(300)
  #define SIP_SVC_GET_MEMORY_NODESMC_SIP_FUNCTION_ID(301)
  
diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h

index e5076274fa0a..cef6f6f58194 100644
--- a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
+++ b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
@@ -15,6 +15,19 @@ typedef struct {
UINT64AddressSize;
  } MemoryInfo;
  
+/**

+  Sockets: the number of sockets on sbsa-ref platform.
+  Clusters: the number of clusters in one socket.
+  Cores: the number of cores in one cluster.
+  Threads: the number of threads in one core.
+**/
+typedef struct {
+  UINT32Sockets;
+  UINT32Clusters;
+  UINT32Cores;
+  UINT32Threads;
+} CpuTopology;
+
  /**
Get CPU count from information passed by Qemu.
  
@@ -83,4 +96,17 @@ GetNumaNodeCount (

VOID
);
  
+/**

+  Get cpu topology(sockets, clusters, cores, threads) from device tree passed 
by Qemu.


We don't need to talk about qemu internals that will change in the
future. "Get cpu topology ... from Qemu.)


No, hang on, that's rubbish. "from TF-A".

/
Leif



Other than that:
Reviewed-by: Leif Lindholm 

/
 Leif


+
+  @param [out]  CpuTopo A pointer to the cpu topology.
+
+
+  @retval   the information of cpu topology.
+**/
+VOID
+GetCpuTopology (
+  OUT CpuTopology  *CpuTopo
+  );
+
  #endif /* HARDWARE_INFO_LIB */
diff --git 
a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
index 596a3453c70f..b17a2ae99b4e 100644
--- 
a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
+++ 
b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
@@ -181,3 +181,39 @@ GetNumaNodeCount (
  
return NumberNumaNodes;

  }
+
+/**
+  Get CPU topology.
+**/
+VOID
+GetCpuTopology (
+  OUT CpuTopology  *CpuTopo
+  )
+{
+  UINTN   SmcResult;
+  UINTN   Arg0;
+  UINTN   Arg1;
+  UINTN   Arg2;
+  UINT32  NumCores = GetCpuCount ();
+
+  SmcResult = ArmCallSmc0 (SIP_SVC_GET_CPU_TOPOLOGY, &Arg0, &Arg1, &Arg2);
+  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
+DEBUG ((DEBUG_ERROR, "%a: SIP_SVC_GET_CPU_TOPOLOGY call failed. We have no cpu 
topology information.\n", __FUNCTION__));
+ResetShutdown ();
+  } else {
+CpuTopo->Sockets  = Arg0;
+CpuTopo->Clusters = Arg1;
+CpuTopo->Cores= Arg2;
+CpuTopo->Threads  = NumCores / (CpuTopo->Sockets * CpuTopo->Clusters * 
CpuTopo->Cores);
+  }
+
+  DEBUG ((
+DEBUG_INFO,
+"%a: CPU Topology: sockets are %d, clusters are %d, cores are %d, threads are 
%d\n",
+__FUNCTION__,
+CpuTopo->Sockets,
+CpuTopo->Clusters,
+CpuTopo->Cores,
+CpuTopo->Threads
+));
+}

--
2.45.2











-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119837): https://edk2.groups.io/g/devel/message/119837
Mute This Topic: https://groups.io/mt/107120143/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 v3 1/5] SbsaQemu: get the information of CPU topology via SMC calls

[Leif Lindholm]

On Tue, Jul 09, 2024 at 12:47:06 +0200, Marcin Juszkiewicz wrote:
> Provide functions to check for CPU topology information:
>  - the number of sockets on sbsa-ref platform.
>  - the number of clusters in one socket.
>  - the number of cores in one cluster.
>  - the number of threads in one core.
> 
> As SMC calls can return up to 4 return values, the number of sockets,
> clusters and cores are read from TF-A using platform specific SMC call.
> Number of threads is caluculated using the cpu count and the number of
> sockets, clusters and cores.
> 
> Signed-off-by: Xiong Yining 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  |  1 +
>  .../Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h  | 26 ++
>  .../SbsaQemuHardwareInfoLib.c| 36 
> 
>  3 files changed, 63 insertions(+)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index af6b120561ad..b57573735ace 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -16,6 +16,7 @@
>  #define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
>  #define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
>  #define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
> +#define SIP_SVC_GET_CPU_TOPOLOGY   SMC_SIP_FUNCTION_ID(202)
>  #define SIP_SVC_GET_MEMORY_NODE_COUNT  SMC_SIP_FUNCTION_ID(300)
>  #define SIP_SVC_GET_MEMORY_NODESMC_SIP_FUNCTION_ID(301)
>  
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> index e5076274fa0a..cef6f6f58194 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> @@ -15,6 +15,19 @@ typedef struct {
>UINT64AddressSize;
>  } MemoryInfo;
>  
> +/**
> +  Sockets: the number of sockets on sbsa-ref platform.
> +  Clusters: the number of clusters in one socket.
> +  Cores: the number of cores in one cluster.
> +  Threads: the number of threads in one core.
> +**/
> +typedef struct {
> +  UINT32Sockets;
> +  UINT32Clusters;
> +  UINT32Cores;
> +  UINT32Threads;
> +} CpuTopology;
> +
>  /**
>Get CPU count from information passed by Qemu.
>  
> @@ -83,4 +96,17 @@ GetNumaNodeCount (
>VOID
>);
>  
> +/**
> +  Get cpu topology(sockets, clusters, cores, threads) from device tree 
> passed by Qemu.

We don't need to talk about qemu internals that will change in the
future. "Get cpu topology ... from Qemu.)

Other than that:
Reviewed-by: Leif Lindholm 

/
Leif

> +
> +  @param [out]  CpuTopo A pointer to the cpu topology.
> +
> +
> +  @retval   the information of cpu topology.
> +**/
> +VOID
> +GetCpuTopology (
> +  OUT CpuTopology  *CpuTopo
> +  );
> +
>  #endif /* HARDWARE_INFO_LIB */
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> index 596a3453c70f..b17a2ae99b4e 100644
> --- 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> @@ -181,3 +181,39 @@ GetNumaNodeCount (
>  
>return NumberNumaNodes;
>  }
> +
> +/**
> +  Get CPU topology.
> +**/
> +VOID
> +GetCpuTopology (
> +  OUT CpuTopology  *CpuTopo
> +  )
> +{
> +  UINTN   SmcResult;
> +  UINTN   Arg0;
> +  UINTN   Arg1;
> +  UINTN   Arg2;
> +  UINT32  NumCores = GetCpuCount ();
> +
> +  SmcResult = ArmCallSmc0 (SIP_SVC_GET_CPU_TOPOLOGY, &Arg0, &Arg1, &Arg2);
> +  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
> +DEBUG ((DEBUG_ERROR, "%a: SIP_SVC_GET_CPU_TOPOLOGY call failed. We have 
> no cpu topology information.\n", __FUNCTION__));
> +ResetShutdown ();
> +  } else {
> +CpuTopo->Sockets  = Arg0;
> +CpuTopo->Clusters = Arg1;
> +CpuTopo->Cores= Arg2;
> +CpuTopo->Threads  = NumCores / (CpuTopo->Sockets * CpuTopo->Clusters * 
> CpuTopo->Cores);
> +  }
> +
> +  DEBUG ((
> +DEBUG_INFO,
> +"%a: CPU Topology: sockets are %d, clusters are %d, cores are %d, 
> threads are %d\n",
> +__FUNCTION__,
> +CpuTopo->Sockets,
> +CpuTopo->Clusters,
> +CpuTopo->Cores,
> +CpuTopo->Threads
> +));
> +}
> 
> -- 
> 2.45.2
> 


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

[edk2-devel] github impact:breaking-change

[Leif Lindholm]

Hi,

I'm seeing something in several PRs in flight (and merged) that have 
"impact:breaking-change" set, where the purpose of the PR is to fix said 
breakage, not introduce API compatibilities.


Am I correct in my understanding that this is not the intended use, and 
if so how do we address the misconception?

Can we start by adding a description for the label? It currently has none.

Mu uses "Requires integration attention", which matches my 
understanding, but feels a bit abstract. How about

"This change breaks existing APIs"
or
"This change may require corresponding updates to code in other 
repositories"?


/
Leif


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119813): https://edk2.groups.io/g/devel/message/119813
Mute This Topic: https://groups.io/mt/107100295/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 v2 2/3] Silicon/SbsaQemu: align the PPTT tables with QEMU

[Leif Lindholm]

On Tue, Jul 02, 2024 at 18:33:03 +0200, Marcin Juszkiewicz wrote:
> From: Xiong Yining 
> 
> To align the CPU topology information recognized by the operating system
> with the CPU topology information configured by QEMU, we need to make
> use of the CPU topology information to create complex PPTT tables
> setups.
> 
> We get the CPU topology information via SMC.
> 
> Signed-off-by: Xiong Yining 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h   |  17 +-
>  .../Include/IndustryStandard/SbsaQemuAcpi.h |  78 +++-
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   | 190 
> +++-
>  3 files changed, 180 insertions(+), 105 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> index e5f0748bb16e..5e50749051c9 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> @@ -61,8 +61,7 @@ typedef struct {
>  
>  #define GTDT_WDTIMER_FLAGS  (GTDT_WDTIMER_ACTIVE_HIGH | 
> GTDT_WDTIMER_LEVEL_TRIGGERED)
>  
> -#define SBSAQEMU_ACPI_MEMORY_AFFINITY_STRUCTURE_INIT(
>  \
> - 
>  ProximityDomain, Base, Length, Flags)   \
> +#define SBSAQEMU_ACPI_MEMORY_AFFINITY_STRUCTURE_INIT(ProximityDomain, Base, 
> Length, Flags) \

Please separate functional and non-functional changes.

>{  
>  \
>  1,  /* Type */   
>  \
>  sizeof (EFI_ACPI_6_4_MEMORY_AFFINITY_STRUCTURE),/* Length */ 
>  \
> @@ -77,8 +76,7 @@ typedef struct {
>  0   /* Reserved */   
>  \
>}
>  
> -#define SBSAQEMU_ACPI_GICC_AFFINITY_STRUCTURE_INIT(  
>  \
> - 
>  ProximityDomain, ACPIProcessorUID, Flags, ClockDomain)  \
> +#define SBSAQEMU_ACPI_GICC_AFFINITY_STRUCTURE_INIT(ProximityDomain, 
> ACPIProcessorUID, Flags, ClockDomain) \

And again.

>{  
>  \
>  3,  /* Type */   
>  \
>  sizeof (EFI_ACPI_6_4_GICC_AFFINITY_STRUCTURE),  /* Length */ 
>  \
> @@ -88,4 +86,15 @@ typedef struct {
>  ClockDomain /* Clock Domain */   
>  \
>}
>  
> +#define SBSAQEMU_ACPI_PROCESSOR_HIERARCHY_NODE_STRUCTURE_INIT(Flags, Parent, 
> ACPIProcessorID, NumberOfPrivateResources) \
> +  {  
>\
> +EFI_ACPI_6_5_PPTT_TYPE_PROCESSOR,
> /* Type */ \
> +sizeof (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR) + 
> NumberOfPrivateResources * sizeof (UINT32), /* Length */  
>  \
> +{ EFI_ACPI_RESERVED_BYTE, EFI_ACPI_RESERVED_BYTE },  
> /* Reserved */ \
> +Flags,   
> /* Flags */\
> +Parent,  
> /* Parent */   \
> +ACPIProcessorID, 
> /* ACPI Processor ID */\
> +NumberOfPrivateResources 
> /* Number of private resources */  \
> +  }
> +
>  #endif
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> index ae151210c2c6..fa2e2b30bb7d 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> @@ -87,13 +87,13 @@ typedef struct {
>  #define SBSAQEMU_L2_CACHE_ASSC  8
>  
>  #define CLUSTER_INDEX (sizeof (EFI_ACPI_DESCRIPTION_HEADER))
> -#define L1_D_CACHE_INDEX  (CLUSTER_INDEX + sizeof 
> (EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR))
> -#define L1_I_CACHE_INDEX  (L1_D_CACHE_INDEX + sizeof 
> (EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE))
> -#define L2_CACHE_INDEX(L1_I_CACHE_INDEX + sizeof 
> (EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE))
> +#define L1_D_CACHE_INDEX  (CLUSTER_INDEX + sizeof 
> (EFI_ACPI_6_5_PPTT_STRUCTURE_PROCESSOR))
> +#define L1_I_CACHE_INDEX  (L1_D_CACHE_INDEX + sizeof 
> 

Re: [edk2-devel] [PATCH edk2-platforms v2] SbsaQemu: use FEAT_RNG for EFI_RNG_PROTOCOL

[Leif Lindholm]

On Wed, Jul 03, 2024 at 14:39:31 +0200, Marcin Juszkiewicz wrote:
> By default we have Neoverse-N2 cpu which supports FEAT_RNG feature. This
> allows us to add RngDxe to have EFI_RNG_PROTOCOL available on
> Neoverse-N2 and 'max' cpu cores.
> 
> Commit 5de5e230a80bed083360da95ba16a2c4a001620d (in EDK2) enabled that for
> ArmVirt platform.
> 
> RNDR is implemented by both Neoverse-N2 and 'max' cpu implemented by QEMU.
> Other cpu models lack it which prevents the RngDxe driver from running,
> resulting in the same situation as before.
> 
> TRNG is not implemented in TCG mode but is required by RngDxe to run.
> 
> On older cpu cores nothing changes.
> 
> Signed-off-by: Marcin Juszkiewicz 

Thanks!

Reviewed-by: Leif Lindholm 
With one niggle below:

> ---
> By default we have Neoverse-N2 cpu which supports FEAT_RNG feature. This
> allows us to add RngDxe to have EFI_RNG_PROTOCOL available on
> Neoverse-N2 and 'max' cpu cores.
> 
> When I boot with Neoverse-N2 or 'max' cpu then EFI_RNG_PROTOCOL gets
> reported by 'EFI stub' on Linux boot and KASLR gets enabled.
> 
> Commit 5de5e230a80bed083360da95ba16a2c4a001620d (in EDK2) enabled that for
> ArmVirt platform.
> 
> RNDR is implemented by both Neoverse-N2 and 'max' cpu implemented by QEMU.
> Other cpu models lack it which prevents the RngDxe driver from running,
> resulting in the same situation as before.
> 
> TRNG is not implemented in TCG mode but is required by RngDxe to run.
> 
> On older cpu cores nothing changes.
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 7 +++
>  Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 1 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 9306986bf7c0..72b6a6d9a8b8 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -660,6 +660,13 @@ [Components.common]
>OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
>Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
> +  SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf {
> +
> +  RngLib|MdePkg/Library/BaseRngLib/BaseRngLib.inf
> +  ArmTrngLib|ArmPkg/Library/ArmTrngLib/ArmTrngLib.inf
> +  ArmMonitorLib|ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
> +  }
> +

Please drop the added blank line.

/
Leif

>  
>#
># FAT filesystem + GPT/MBR partitioning
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> index b35f42e11aa4..51a1ef8519f9 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> @@ -192,6 +192,7 @@ [FV.FvMain]
>INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
>INF OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
>INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
> +  INF SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
>  
>#
># FAT filesystem + GPT/MBR partitioning + UDF filesystem
> 
> ---
> base-commit: c7ed8deaa8c1d7ee83af994b2c90d4490ef27bdc
> change-id: 20240703-efi-rng-protocol-be991536709a
> 
> Best regards,
> -- 
> Marcin Juszkiewicz 
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119793): https://edk2.groups.io/g/devel/message/119793
Mute This Topic: https://groups.io/mt/107018350/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/4] Platform,Silicon: fix SiFive U540 and Opensbi builds

[Leif Lindholm]

On Mon, Jun 24, 2024 at 22:37:27 +0530, Sunil V L wrote:
> On Mon, Jun 24, 2024 at 02:32:33PM +0100, Leif Lindholm wrote:
> > Heinrich reported a build breakage of U540, due to it lacking a
> > mapping for RiscVMmuLib. While looking into that, I found that
> > 1) The Opensbi submodule version has been corrupted by a recent commit.
> > 2) The Maintainers.txt entry for this group of platforms is incorrect.
> > 
> The series LGTM.
> 
> Reviewed-by: Sunil V L 

Thanks!

Series pushed as c7ed8deaa8c1..ff6e91e106cc,
adding a reported-by for Heinrich that should have been
there in the original submission.

/
Leif

> Thanks!
> 
> 
> 
> 
> 


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

Re: [edk2-devel] How do debug tianocore.PatchCheck failed?

[Leif Lindholm]

Hi Joey,

On 2024-07-02 07:42, joeyli via groups.io wrote:

Hi EDK2 experts,

I was filed a submit request on github for
"[PATCH] EmbeddedPkg/VirtualRealTimeClockLib: Support SOURCE_DATE_EPOCH". But
I got a Azure Pipelines/tianocore.PatchCheck failed:

https://github.com/tianocore/edk2/pull/5550/checks?check_run_id=24185647984

Check failure on line 26 in Build log
@azure-pipelines azure-pipelines / tianocore.PatchCheck
Build log #L26
Bash exited with code '255'.


The CI system is a bit "beware of the leopard" with regards to finding 
the failures.


If I go to the link above, I see the message you're copying, but below 
that there is a link "View more details on Azure Pipelines". Clicking 
that takes me to a page that says "build not found" - since the logs 
have been purged since the test was run 2 months ago. Otherwise you'd be 
able to find logs there explaining the failure.



The patch only change one line as following bash script:

--- a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
+++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
@@ -34,4 +34,4 @@
  
  # Current usage of this library expects GCC in a UNIX-like shell environment with the date command

  [BuildOptions]
-  GCC:*_*_*_CC_FLAGS = -DBUILD_EPOCH=`date +%s`
+  GCC:*_*_*_CC_FLAGS = -DBUILD_EPOCH=`printenv SOURCE_DATE_EPOCH || date +%s`^M


This looks fine.

If I was to guess, from looking at the PR, I would say PatchCheck.py is 
unhappy over the merge commit that has been introduced.
If you rebase your change on top of current master branch and force push 
an update, that will trigger a new CI run, which I'm thinking would pass.


Best Regards,

Leif



This change works on openSUSE/SLE, and it also passed
PlatformCI_ArmVirtPkg_Ubuntu_GCC5_PR test.

My question is:
What's the platform of "Azure Pipelines/tianocore.PatchCheck" ? Is it a
virtual machine? Where can I find the platform for debugging my change?

Thank a lot!
Joey Lee









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

Re: [edk2-devel] Moving edk2-platforms reviews to GitHub Pull Requests

[Leif Lindholm]

(Dropping direct cc:s)

On 2024-07-01 20:16, Rebecca Cran wrote:
Now that edk2 has been using PRs for a few weeks, I'd like to propose 
enabling the same workflow for edk2-platfoms.


As maintainers or reviewers of platforms in the edk2-platforms repo, I'd 
like to get any feedback on moving from email-based reviews to GitHub 
Pull Requests and any concerns or issues people might have with it.


My only concern is wrt reviewer assignment.

There are a few ways we can consider that - for example:
- leave contribution workflow up to each maintainer (for now)
- switch fully and expect maintainers to dutifully trawl the PR queue
- Move to CODEOWNERS for edk2-platforms (which has less complex wildcard
  use than edk2)

Best Regards,

Leif



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119749): https://edk2.groups.io/g/devel/message/119749
Mute This Topic: https://groups.io/mt/106986207/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] SbsaQemu: use FEAT_RNG for EFI_RNG_PROTOCOL

[Leif Lindholm]

On 2024-07-01 14:35, Ard Biesheuvel wrote:

Ard: would you be opposed to putting a DEBUG print and/or an ASSERT in
BaseRngLibContructor if mRndrSupported == 0?

An alternative would be to place a test and noisy warning inside
SbsaQemuPlatformDxe.


I'm not sure I follow what we are trying to fix here. RngDxe will
simply not load if BaseRngLib does not find FEAT_RNG support.

If the issue is other, existing users of RngLib that are currently
served by BaseRngTimerLib, we could make the library class resolutions
introduced here local the RngDxe driver, using

SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf {
   
 RngLib|MdePkg/Library/BaseRngLib/BaseRngLib.inf
 ArmTrngLib|ArmPkg/Library/ArmTrngLib/ArmTrngLib.inf
 ArmMonitorLib|ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf
}


Good point.

I think Ard's example solves the original purpose (providing 
EFI_RNG_PROTOCOL to linux efi stub) while not breaking any potential 
usage before this point.


I'd still quite like to nudge existing users onto a more recent cpu,
with less cryptic console output. But if we do the above we can drop the 
conditional part and just put a test and a message in the PlatformDxe.


(And have the commit message be clear on RngDxe being added.)

/
Leif



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119741): https://edk2.groups.io/g/devel/message/119741
Mute This Topic: https://groups.io/mt/106909459/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] SbsaQemu: use FEAT_RNG for EFI_RNG_PROTOCOL

[Leif Lindholm]

On 2024-07-01 13:58, Marcin Juszkiewicz wrote:

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc

index 9306986bf7c0..3463e5c7a635 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -148,7 +148,9 @@ [LibraryClasses.common]
    #


Since sbsa-ref still supports processors without FEAT_RNG, this may 
cause unexpected breakages for some users.


That's why I sent it as more of RFC than changes for merging.


Could we first of all conditionalise this change:

[Defines]
...
   DEFINE_DEBUG_PRINT_ERROR_LEVEL = ...
   DEFINE FEATRNG_ENABLE = TRUE

so that someone who still wishes to run tests against older cpus can 
still do so through a rebuild with -D FEATRNG_ENABLE=FALSE


Is there a way to load both BaseRngLib and BaseRngLibTimerLib and switch
between them depending on availability of FEAT_RNG?


Not without severe hackery. The library is statically linked into RngDxe.

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf 
b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf

index b35f42e11aa4..51a1ef8519f9 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
@@ -192,6 +192,7 @@ [FV.FvMain]
    INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
    INF OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
    INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
+  INF SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf


Second:
What is the failure mode of running the BaseRngLib flavour on cpus 
that don't support FEAT_RNG? RngDxe itself seems to do the right 
thing, but do we get any warning messages or will certain operations 
now fail silently?


On FEAT_RNG cores we get:

InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 101FAD68798
ProtectUefiImageCommon - 0xFAD683C0
   - 0x0101FBBDB000 - 0x7000
ArmTrngLib could not be correctly initialized.
InstallProtocolInterface: 3152BCA5-EADE-433D-862E-C01CDC291F44 101FBBE0020
Loading driver B601F8C4-43B7-4784-95B1-F4226CB40CEE


On core without FEAT_RNG:

InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 101FAD68798
ProtectUefiImageCommon - 0xFAD683C0
   - 0x0101FBBDB000 - 0x7000
ArmTrngLib could not be correctly initialized.
Error: Image at 101FBBDB000 start failed: 0001
Loading driver B601F8C4-43B7-4784-95B1-F4226CB40CEE


But it still keeps booting correctly after that? With some missing 
functionality?



So there is some kind of information but you need to know what
to look for ;(


Ard: would you be opposed to putting a DEBUG print and/or an ASSERT in 
BaseRngLibContructor if mRndrSupported == 0?


An alternative would be to place a test and noisy warning inside 
SbsaQemuPlatformDxe.


/
Leif



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119737): https://edk2.groups.io/g/devel/message/119737
Mute This Topic: https://groups.io/mt/106909459/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] SbsaQemu: use FEAT_RNG for EFI_RNG_PROTOCOL

[Leif Lindholm]

On 2024-06-27 15:22, Marcin Juszkiewicz wrote:

By default we have Neoverse-N2 cpu which supports FEAT_RNG feature.

Commit 5de5e230a80bed083360da95ba16a2c4a001620d (in EDK2) enabled that for
ArmVirt platform.

RNDR is implemented by both Neoverse-N2 and 'max' cpu implemented by QEMU.
Other cpu models lack it which prevents the RngDxe driver from running,
resulting in the same situation as before.

TRNG is not implemented in TCG mode but is required by RngDxe to run.


This commit also adds RngDxe for this platform, which neither the short 
nor the long description mentions.



Signed-off-by: Marcin Juszkiewicz 
---
  Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 6 +-
  Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 1 +
  2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 9306986bf7c0..3463e5c7a635 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -148,7 +148,9 @@ [LibraryClasses.common]
#


Since sbsa-ref still supports processors without FEAT_RNG, this may 
cause unexpected breakages for some users.


Could we first of all conditionalise this change:

[Defines]
...
  DEFINE_DEBUG_PRINT_ERROR_LEVEL = ...
  DEFINE FEATRNG_ENABLE  = TRUE

so that someone who still wishes to run tests against older cpus can 
still do so through a rebuild with -D FEATRNG_ENABLE=FALSE



IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf


!if $(FEATRNG_ENABLE) == TRUE
  RngLib|MdePkg/Library/BaseRngLib/BaseRngLib.inf
!else
  RngLib|MdeModulePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
!endif
  ArmTrngLib|ArmPkg/Library/ArmTrngLib/ArmTrngLib.inf
  ArmMonitorLib|ArmPkg/Library/ArmMonitorLib/ArmMonitorLib.inf


BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
  
#

@@ -660,6 +662,8 @@ [Components.common]
OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
+  SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf
+


Spurious added newline.

  
#

# FAT filesystem + GPT/MBR partitioning
diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf 
b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
index b35f42e11aa4..51a1ef8519f9 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
@@ -192,6 +192,7 @@ [FV.FvMain]
INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
INF OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
+  INF SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf


Second:
What is the failure mode of running the BaseRngLib flavour on cpus that 
don't support FEAT_RNG? RngDxe itself seems to do the right thing, but 
do we get any warning messages or will certain operations now fail silently?


/
Leif

  
#

# FAT filesystem + GPT/MBR partitioning + UDF filesystem




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119735): https://edk2.groups.io/g/devel/message/119735
Mute This Topic: https://groups.io/mt/106909459/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] SbsaQemu: bump OemRevision to today

[Leif Lindholm]

Makes sense.

If you change the new version to 2024 instead of 2023 :)
Reviewed-by: Leif Lindholm 

On 2024-06-25 18:56, Marcin Juszkiewicz wrote:

Lot of time passed since 10th of August 2020 when this platform was
added to EDK2-platforms repository.

So let bump PcdAcpiDefaultOemRevision value to today. So everyone will
see during OS boot that things are changing.

Signed-off-by: Marcin Juszkiewicz 
---
  Silicon/Qemu/SbsaQemu/Acpi.dsc.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Silicon/Qemu/SbsaQemu/Acpi.dsc.inc 
b/Silicon/Qemu/SbsaQemu/Acpi.dsc.inc
index 54e5646e9249..db782afa2cea 100644
--- a/Silicon/Qemu/SbsaQemu/Acpi.dsc.inc
+++ b/Silicon/Qemu/SbsaQemu/Acpi.dsc.inc
@@ -16,7 +16,7 @@ [PcdsFeatureFlag]
  [PcdsFixedAtBuild.common]
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultOemId|"LINARO"
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultOemTableId|0x554D455141534253 
#SBSAQEMU
-  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultOemRevision|0x20200810
+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultOemRevision|0x20230625
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorId|0x4f524e4c #LNRO
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiDefaultCreatorRevision|1
  




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

[edk2-devel] [PATCH edk2-platforms 4/4] Silicon/RiscVOpensbiLib: fix submodule version

[Leif Lindholm]

Commit 4f32c34865de,
("Platform/AMD: Initial commit of cross platform/board interfaces")
presumably by accident reverts the opensbi submodule update done in
commmit 2d8289634ec9 ("ProcessorPkg/opensbi: Update opensbi library").

Correct this and restore the submodule version.

Cc: Daniel Schaefer 
Cc: Sunil V L 
Cc: Abner Chang 
Signed-off-by: Leif Lindholm 
---
 Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi 
b/Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi
index 937caee08331..a731c7e36988 16
--- a/Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi
+++ b/Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi
@@ -1 +1 @@
-Subproject commit 937caee0833115f69d697ca190001ba0aa5c7368
+Subproject commit a731c7e36988c3308e1978ecde491f2f6182d490
-- 
2.39.2



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

[edk2-devel] [PATCH edk2-platforms 3/4] Platform/SiFive: add RiscVMmuLib mapping for U540

[Leif Lindholm]

The freedom unleashed platform currently fails to build due to a
missing mapping for RiscVMmuLib, so add one.

Cc: Daniel Schaefer 
Cc: Sunil V L 
Cc: Abner Chang 
Signed-off-by: Leif Lindholm 
---
 Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc 
b/Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc
index a297702952a0..40bb790a485f 100644
--- a/Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc
+++ b/Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc
@@ -150,6 +150,7 @@ [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
 !endif
   RiscVCpuLib|Silicon/RISC-V/ProcessorPkg/Library/RiscVCpuLib/RiscVCpuLib.inf
+  RiscVMmuLib|UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.inf
   RiscVSbiLib|MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
   
RiscVPlatformTimerLib|Platform/SiFive/U5SeriesPkg/Library/RiscVPlatformTimerLib/RiscVPlatformTimerLib.inf
   
#MachineModeTimerLib|Silicon/RISC-V/ProcessorPkg/Library/RiscVReadMachineModeTimer/MachineModeTimerLib/MachineModeTimerLib.inf
-- 
2.39.2



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

[edk2-devel] [PATCH edk2-platforms 2/4] Platform/SiFive: CRLF fixup in U540.dsc

[Leif Lindholm]

Cc: Daniel Schaefer 
Cc: Sunil V L 
Cc: Abner Chang 
Signed-off-by: Leif Lindholm 
---
 Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc 
b/Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc
index 7f73065a5153..a297702952a0 100644
--- a/Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc
+++ b/Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc
@@ -103,7 +103,7 @@ [LibraryClasses]
   FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
   
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
-  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
 
 # RISC-V Platform Library
   TimeBaseLib|EmbeddedPkg//Library/TimeBaseLib/TimeBaseLib.inf
-- 
2.39.2



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

[edk2-devel] [PATCH edk2-platforms 0/4] Platform,Silicon: fix SiFive U540 and Opensbi builds

[Leif Lindholm]

Heinrich reported a build breakage of U540, due to it lacking a
mapping for RiscVMmuLib. While looking into that, I found that
1) The Opensbi submodule version has been corrupted by a recent commit.
2) The Maintainers.txt entry for this group of platforms is incorrect.

Reported-by: Heinrich Schuchardt 
Cc: Daniel Schaefer 
Cc: Sunil V L 
Cc: Abner Chang 

Leif Lindholm (4):
  Maintainers.txt: fix entry for SiFive U5SeriesPkg
  Platform/SiFive: CRLF fixup in U540.dsc
  Platform/SiFive: add RiscVMmuLib mapping for U540
  Silicon/RiscVOpensbiLib: fix submodule version

 Platform/SiFive/U5SeriesPkg/FreedomU540HiFiveUnleashedBoard/U540.dsc | 3 ++-
 Maintainers.txt  | 4 ++--
 Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi  | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

-- 
2.39.2


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

[edk2-devel] [PATCH edk2-platforms 1/4] Maintainers.txt: fix entry for SiFive U5SeriesPkg

[Leif Lindholm]

There was an error in the wildcard path described for U5SeriesPkg, so
it failed to match. Fix the mistake.

Cc: Michael D Kinney 
Cc: Daniel Schaefer 
Signed-off-by: Leif Lindholm 
---
 Maintainers.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index af688c3813f1..824838486072 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -285,8 +285,8 @@ F: Platform/RISC-V/PlatformPkg/
 M: Sunil V L 
 R: Daniel Schaefer 
 
-Platform/SiFive/U5Series
-F:Platform/SiFive/U5Series/
+Platform/SiFive/U5SeriesPkg
+F: Platform/SiFive/U5SeriesPkg/
 M: Daniel Schaefer 
 
 Silicon/Intel
-- 
2.39.2



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

Re: [edk2-devel] [PATCH edk2-platforms 3/5] Platform/ARM: drop use of PcdArmArchTimerFreqInHz

[Leif Lindholm]

On Sat, Jun 22, 2024 at 21:53:02 -0700, Sami Mujawar wrote:
> Hi Leif,
> 
> Thank you for this patch.
> 
> These changes look good to me.
> 
> Reviewed-by: Sami Mujawar 

Thanks!
3/5 pushed as d9bcbf86b03f.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119684): https://edk2.groups.io/g/devel/message/119684
Mute This Topic: https://groups.io/mt/106780878/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 v2 1/1] SbsaQemu: reformat all sources using uncrustify

[Leif Lindholm]

On Fri, Jun 21, 2024 at 16:04:07 +0200, Marcin Juszkiewicz wrote:
> uncrustify is required in EDK2 repository. SbsaQemu (and other platforms
> in edk2-platforms) code was free from using it IIRC.
> 
> Reformat all files to make new contributions easier. We can recommend
> formatting sources without generating extra work for developers.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 

Thanks!

/
Leif

> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h |  50 +-
>  .../Include/IndustryStandard/SbsaQemuAcpi.h   |  86 +--
>  .../SbsaQemuPlatformVersion.h |   2 +-
>  .../Include/IndustryStandard/SbsaQemuSmc.h|  14 +-
>  .../Include/Library/HardwareInfoLib.h |   8 +-
>  .../Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c |  78 +--
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 490 +-
>  .../SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c   |   8 +-
>  .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c |  88 ++--
>  .../SbsaQemuSmbiosDxe/SbsaQemuSmbiosDxe.c |  94 ++--
>  .../SbsaQemuHardwareInfoLib.c |  66 +--
>  .../Library/SbsaQemuLib/SbsaQemuLib.c |  23 +-
>  .../Library/SbsaQemuLib/SbsaQemuMem.c |  49 +-
>  .../SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.c |  14 +-
>  .../SbsaQemuPciHostBridgeLib.c|  90 ++--
>  15 files changed, 603 insertions(+), 557 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> index 83a085cd86f4..e5f0748bb16e 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> @@ -11,60 +11,58 @@
>  #define SBSAQEMU_ACPI_DXE_H
>  
>  typedef struct {
> -  EFI_ACPI_6_0_IO_REMAPPING_ITS_NODENode;
> -  UINT32Identifiers;
> +  EFI_ACPI_6_0_IO_REMAPPING_ITS_NODENode;
> +  UINT32Identifiers;
>  } SBSA_EFI_ACPI_6_0_IO_REMAPPING_ITS_NODE;
>  
> -typedef struct
> -{
> -  EFI_ACPI_6_0_IO_REMAPPING_SMMU3_NODE SmmuNode;
> -  EFI_ACPI_6_0_IO_REMAPPING_ID_TABLE   SmmuIdMap;
> +typedef struct {
> +  EFI_ACPI_6_0_IO_REMAPPING_SMMU3_NODESmmuNode;
> +  EFI_ACPI_6_0_IO_REMAPPING_ID_TABLE  SmmuIdMap;
>  } SBSA_EFI_ACPI_6_0_IO_REMAPPING_SMMU3_NODE;
>  
> -typedef struct
> -{
> -  EFI_ACPI_6_0_IO_REMAPPING_RC_NODERcNode;
> -  EFI_ACPI_6_0_IO_REMAPPING_ID_TABLE   RcIdMap;
> +typedef struct {
> +  EFI_ACPI_6_0_IO_REMAPPING_RC_NODE RcNode;
> +  EFI_ACPI_6_0_IO_REMAPPING_ID_TABLERcIdMap;
>  } SBSA_EFI_ACPI_6_0_IO_REMAPPING_RC_NODE;
>  
>  typedef struct {
> -  EFI_ACPI_6_0_IO_REMAPPING_TABLE   Iort;
> -  SBSA_EFI_ACPI_6_0_IO_REMAPPING_ITS_NODE   ItsNode;
> -  SBSA_EFI_ACPI_6_0_IO_REMAPPING_SMMU3_NODE SmmuNode;
> -  SBSA_EFI_ACPI_6_0_IO_REMAPPING_RC_NODERcNode;
> +  EFI_ACPI_6_0_IO_REMAPPING_TABLE  Iort;
> +  SBSA_EFI_ACPI_6_0_IO_REMAPPING_ITS_NODE  ItsNode;
> +  SBSA_EFI_ACPI_6_0_IO_REMAPPING_SMMU3_NODESmmuNode;
> +  SBSA_EFI_ACPI_6_0_IO_REMAPPING_RC_NODE   RcNode;
>  } SBSA_IO_REMAPPING_STRUCTURE;
>  
>  typedef struct {
> -  EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE  mGtdt;
> -  EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE mGwdt;
> +  EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE mGtdt;
> +  EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTUREmGwdt;
>  } GENERIC_TIMER_DESCRIPTION_TABLES;
>  
>  #ifndef SYSTEM_TIMER_BASE_ADDRESS
> -  #define SYSTEM_TIMER_BASE_ADDRESS MAX_ADDRESS
> +#define SYSTEM_TIMER_BASE_ADDRESS  MAX_ADDRESS
>  #endif
>  
>  #define GTDT_TIMER_LEVEL_TRIGGERED  0
>  #define GTDT_TIMER_ACTIVE_LOW   
> EFI_ACPI_6_3_GTDT_TIMER_FLAG_TIMER_INTERRUPT_POLARITY
>  #define GTDT_TIMER_ALWAYS_ON
> EFI_ACPI_6_3_GTDT_TIMER_FLAG_ALWAYS_ON_CAPABILITY
>  
> -#define GTDT_GTIMER_FLAGS   (GTDT_TIMER_ACTIVE_LOW | \
> +#define GTDT_GTIMER_FLAGS  (GTDT_TIMER_ACTIVE_LOW |  \
>   GTDT_TIMER_LEVEL_TRIGGERED | \
>   GTDT_TIMER_ALWAYS_ON)
>  
> -#define SBSA_PLATFORM_WATCHDOG_COUNT1
> -#define SBSA_PLATFORM_TIMER_COUNT   (SBSA_PLATFORM_WATCHDOG_COUNT)
> +#define SBSA_PLATFORM_WATCHDOG_COUNT  1
> +#define SBSA_PLATFORM_TIMER_COUNT (SBSA_PLATFORM_WATCHDOG_COUNT)
>  
> -#define SBSAQEMU_WDT_REFRESH_FRAME_BASE  0x5001
> -#define SBSAQEMU_WDT_CONTROL_FRAME_BASE  0x50011000
> -#define SBSAQEMU_WDT_IRQ 48
> +#define SBSAQEMU_WDT_REFRESH_FRAME_BASE  0x5001
> +#define SBSAQEMU_WDT_CONTROL_FRAME_BASE  0x

Re: [edk2-devel] [PATCH edk2-platforms 1/1] SbsaQemu: reformat all sources using uncrustify

[Leif Lindholm]

On Fri, Jun 21, 2024 at 15:39:01 +0200, Marcin Juszkiewicz wrote:
> uncrustify is required in EDK2 repository. SbsaQemu (and other platforms
> in edk2-platforms) code was free from using it IIRC.
> 
> Reformat all files to make new contributions easier. We can recommend
> formatting sources without generating extra work for developers.
> 
> Signed-off-by: Marcin Juszkiewicz 

Everything in here except one thing is improvement.

> ---
>  .../Include/Library/QemuOpenFwCfgLib.h|   7 +-
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h |  50 +-
>  .../Include/IndustryStandard/SbsaQemuAcpi.h   |  86 +--
>  .../SbsaQemuPlatformVersion.h |   2 +-
>  .../Include/IndustryStandard/SbsaQemuSmc.h|  14 +-
>  .../Include/Library/HardwareInfoLib.h |   8 +-
>  .../BoardBootManagerLib/BoardBootManager.c|  14 +-
>  .../Library/PeiReportFvLib/PeiReportFvLib.c   | 237 -
>  .../QemuOpenBoardPkg/PlatformInitPei/Memory.c |   4 +-
>  .../Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c |  78 +--
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 490 +-
>  .../SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c   |   8 +-
>  .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c |  88 ++--
>  .../SbsaQemuSmbiosDxe/SbsaQemuSmbiosDxe.c |  94 ++--
>  .../SbsaQemuHardwareInfoLib.c |  66 +--
>  .../Library/SbsaQemuLib/SbsaQemuLib.c |  23 +-
>  .../Library/SbsaQemuLib/SbsaQemuMem.c |  49 +-
>  .../SbsaQemuNorFlashLib/SbsaQemuNorFlashLib.c |  14 +-
>  .../SbsaQemuPciHostBridgeLib.c|  90 ++--
>  19 files changed, 735 insertions(+), 687 deletions(-)
> 


> --- a/Platform/Qemu/QemuOpenBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.c
> +++ b/Platform/Qemu/QemuOpenBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.c
> @@ -16,7 +16,7 @@
>  #include 
>  
>  // Use a FV pointer PCD to get a pointer to the FileSystemGuid in the FV 
> header
> -#define PCD_TO_FV_HEADER_FILE_SYSTEM_GUID(Pcd)   
> (&((EFI_FIRMWARE_VOLUME_HEADER *)(UINTN) PcdGet32 (Pcd))->FileSystemGuid)
> +#define PCD_TO_FV_HEADER_FILE_SYSTEM_GUID(Pcd)  
> (&((EFI_FIRMWARE_VOLUME_HEADER *)(UINTN) PcdGet32 (Pcd))->FileSystemGuid)
>  
>  /**
>Reports FVs necessary for MinPlarform pre-memory initialization
> @@ -38,13 +38,14 @@ ReportPreMemFv (
>  
>DEBUG_CODE (
>  for (Index = 0; Status == EFI_SUCCESS; Index++) {
> -  Status = PeiServicesLocatePpi (&gEfiPeiFirmwareVolumeInfo2PpiGuid, 
> Index, &Descriptor, (VOID**) &Ppi);
> -  if (!EFI_ERROR (Status)) {
> -FvHeader = (EFI_FIRMWARE_VOLUME_HEADER*) Ppi->FvInfo;
> -DEBUG ((DEBUG_INFO, "Found FV at 0x%x, size 0x%x\n", FvHeader, 
> FvHeader->FvLength));
> -  }
> +Status = PeiServicesLocatePpi (&gEfiPeiFirmwareVolumeInfo2PpiGuid, 
> Index, &Descriptor, (VOID **)&Ppi);
> +if (!EFI_ERROR (Status)) {
> +  FvHeader = (EFI_FIRMWARE_VOLUME_HEADER *)Ppi->FvInfo;
> +  DEBUG ((DEBUG_INFO, "Found FV at 0x%x, size 0x%x\n", FvHeader, 
> FvHeader->FvLength));

Uncrustify gets this hunk wrong.

>  }
> -  );
> +  }
> +
> +);

And this too.

Michael, do you have any known tweaks for this format?

Marcin, since the point was to clean up SbsaQemu, maybe you could
re-run this without including QemuOpenBoardPkg?

Regards,

Leif



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119672): https://edk2.groups.io/g/devel/message/119672
Mute This Topic: https://groups.io/mt/106798688/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/5] Platform,Silicon: drop use of PcdArmArchTimerFreqInHz

[Leif Lindholm]

On Thu, Jun 20, 2024 at 16:43:00 +0200, Ard Biesheuvel wrote:
> On Thu, 20 Jun 2024 at 16:33, Leif Lindholm  wrote:
> >
> > Related to https://github.com/tianocore/edk2/pull/5797
> >
> > PcdArmArchTimerFreqInHz is about to be removed, as it is now obsolete.
> > Its functionality has been partially broken, and mostly ignored, for
> > all AArch64 platforms since December 2020.
> >
> > This set cleans up some broken line endings in .dsc* files, then
> > drops all non-invasive references to the Pcd:
> > - .dsc* files setting it to 0 (which is the default in the definition,
> >   and means "just read it from the system register instead")
> > - .inf files declaring a dependency that is in fact not there in
> >   current code.
> >
> > Finally, it drops the setting of the Pcd for platforms that set it to
> > non-0. This has *never* done the right thing on these platforms since
> > they are all AArch64, but it may affect timer timeout, so deserves
> > deeper testing.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Chuong Tran 
> > Cc: Graeme Gregory 
> > Cc: Marcin Juszkiewicz 
> > Cc: Marcin Wojtas 
> > Cc: Meenakshi Aggarwal 
> > Cc: Narinder Dhillon 
> > Cc: Nhi Pham 
> > Cc: Rebecca Cran 
> > Cc: Sami Mujawar 
> > Cc: Thomas Abraham 
> > Cc: Wenyi Xie 
> >
> > Leif Lindholm (5):
> >   Platform/SbsaQemu: fix .dsc line endings
> >   Platform,Silicon: drop redundant uses of PcdArmArchTimerFreqInHz
> >   Platform/ARM: drop use of PcdArmArchTimerFreqInHz
> >   Platform/Hisilicon: drop D05 use of PcdArmArchTimerFreqInHz
> >   Silicon/Marvell: drop use of PcdArmArchTimerFreqInHz
> >
> 
> Looks fine to me
> 
> Reviewed-by: Ard Biesheuvel 

Thanks!

Since 1-2 are just cleanup, I have now pushed those two commits,
with R-b:s given, as 3f08401365d6..b29e69a688d6.

I am tempted to now merge https://github.com/tianocore/edk2/pull/5797,
at which point the platforms affected by 3-5 will break.

Any objection?

/
Leif


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119670): https://edk2.groups.io/g/devel/message/119670
Mute This Topic: https://groups.io/mt/106780872/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/5] Platform/SbsaQemu: fix .dsc line endings

[Leif Lindholm]

Obvs I forgot to update the subject when I squashed a bunch of line 
ending fixups. I'll do that before I push if anyone gives me an R-b on this.


/
Leif

On 2024-06-20 15:32, Leif Lindholm wrote:

A patch adding a mapping for ImagePropertiesRecordLib introduced a bunch of
LF line endings in otherwise CRLF files, so clean that up.

Cc: Ard Biesheuvel 
Cc: Chuong Tran 
Cc: Graeme Gregory 
Cc: Marcin Juszkiewicz 
Cc: Marcin Wojtas 
Cc: Meenakshi Aggarwal 
Cc: Narinder Dhillon 
Cc: Nhi Pham 
Cc: Rebecca Cran 
Cc: Sami Mujawar 
Cc: Thomas Abraham 
Signed-off-by: Leif Lindholm 
---
  Platform/ARM/Morello/MorelloPlatform.dsc.inc | 2 +-
  Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 2 +-
  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc| 2 +-
  Silicon/NXP/NxpQoriqLs.dsc.inc   | 2 +-
  Platform/Qemu/SbsaQemu/SbsaQemu.dsc  | 2 +-
  5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Platform/ARM/Morello/MorelloPlatform.dsc.inc 
b/Platform/ARM/Morello/MorelloPlatform.dsc.inc
index 660fd6cb2f17..e7f4b6d0dde8 100644
--- a/Platform/ARM/Morello/MorelloPlatform.dsc.inc
+++ b/Platform/ARM/Morello/MorelloPlatform.dsc.inc
@@ -13,7 +13,7 @@ [LibraryClasses.common]
BasePathLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
-  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
  
# Ramdisk Support

FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc 
b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
index 23579497661d..eb6caf37a3c5 100644
--- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
+++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
@@ -46,7 +46,7 @@ [LibraryClasses.common]
HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf

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

# Allow dynamic PCDs
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index a7a4f47ef3d5..ab719f360eda 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -71,7 +71,7 @@ [LibraryClasses.common]
UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf

VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf

VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
-  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
  
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
  
diff --git a/Silicon/NXP/NxpQoriqLs.dsc.inc b/Silicon/NXP/NxpQoriqLs.dsc.inc

index da76bd6b1de5..920d2f6c4ddf 100644
--- a/Silicon/NXP/NxpQoriqLs.dsc.inc
+++ b/Silicon/NXP/NxpQoriqLs.dsc.inc
@@ -98,7 +98,7 @@ [LibraryClasses.common]

NonDiscoverableDeviceRegistrationLib|MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/NonDiscoverableDeviceRegistrationLib.inf

ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf

UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
-  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
  
I2cLib|Silicon/NXP/Library/I2cLib/I2cLib.inf


ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 221322cca030..4fea9a0d6380 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -78,7 +78,7 @@ [LibraryClasses.common]
SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
-  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
  
UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf


OrderedCollectionLib|M

[edk2-devel] [PATCH edk2-platforms 1/5] Platform/SbsaQemu: fix .dsc line endings

[Leif Lindholm]

A patch adding a mapping for ImagePropertiesRecordLib introduced a bunch of
LF line endings in otherwise CRLF files, so clean that up.

Cc: Ard Biesheuvel 
Cc: Chuong Tran 
Cc: Graeme Gregory 
Cc: Marcin Juszkiewicz 
Cc: Marcin Wojtas 
Cc: Meenakshi Aggarwal 
Cc: Narinder Dhillon 
Cc: Nhi Pham 
Cc: Rebecca Cran 
Cc: Sami Mujawar 
Cc: Thomas Abraham 
Signed-off-by: Leif Lindholm 
---
 Platform/ARM/Morello/MorelloPlatform.dsc.inc | 2 +-
 Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc | 2 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc| 2 +-
 Silicon/NXP/NxpQoriqLs.dsc.inc   | 2 +-
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Platform/ARM/Morello/MorelloPlatform.dsc.inc 
b/Platform/ARM/Morello/MorelloPlatform.dsc.inc
index 660fd6cb2f17..e7f4b6d0dde8 100644
--- a/Platform/ARM/Morello/MorelloPlatform.dsc.inc
+++ b/Platform/ARM/Morello/MorelloPlatform.dsc.inc
@@ -13,7 +13,7 @@ [LibraryClasses.common]
   BasePathLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
-  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
 
   # Ramdisk Support
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc 
b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
index 23579497661d..eb6caf37a3c5 100644
--- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
+++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
@@ -46,7 +46,7 @@ [LibraryClasses.common]
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
   
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
   UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
-  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
 
   #
   # Allow dynamic PCDs
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index a7a4f47ef3d5..ab719f360eda 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -71,7 +71,7 @@ [LibraryClasses.common]
   UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
   
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
   
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
-  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
 
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
 
diff --git a/Silicon/NXP/NxpQoriqLs.dsc.inc b/Silicon/NXP/NxpQoriqLs.dsc.inc
index da76bd6b1de5..920d2f6c4ddf 100644
--- a/Silicon/NXP/NxpQoriqLs.dsc.inc
+++ b/Silicon/NXP/NxpQoriqLs.dsc.inc
@@ -98,7 +98,7 @@ [LibraryClasses.common]
   
NonDiscoverableDeviceRegistrationLib|MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/NonDiscoverableDeviceRegistrationLib.inf
   
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
   
UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
-  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
 
   I2cLib|Silicon/NXP/Library/I2cLib/I2cLib.inf
   
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 221322cca030..4fea9a0d6380 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -78,7 +78,7 @@ [LibraryClasses.common]
   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
   ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
   FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
-  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
+  
ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
 
   UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
-- 
2.39.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119654): https://edk2.groups.io/g/devel

[edk2-devel] [PATCH edk2-platforms 5/5] Silicon/Marvell: drop use of PcdArmArchTimerFreqInHz

[Leif Lindholm]

Armada7k8k.dsc.inc, used by several platforms, explicitly sets
PcdArmArchTimerFreqInHz, however the intended effect of that is not possible
from AArch64 EL2/1, and has never been performed unless built for ARM.

The Pcd is now being deleted, so drop the setting.

This has however affected timer timout calculations, so could lead to a
change in platform behaviour.

Cc: Marcin Wojtas 
Cc: Narinder Dhillon 
Signed-off-by: Leif Lindholm 
---
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index ab719f360eda..a7a19f5d4381 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -280,8 +280,6 @@ [PcdsFixedAtBuild.common]
   #
   gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0xF022F000
 
-  # ARM Architectural Timer Support
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|2500
   gEmbeddedTokenSpaceGuid.PcdMetronomeTickPeriod|1000
 
   # ARM SBSA Watchdog
-- 
2.39.2



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

[edk2-devel] [PATCH edk2-platforms 3/5] Platform/ARM: drop use of PcdArmArchTimerFreqInHz

[Leif Lindholm]

Some Arm ltd. platforms explicitly set PcdArmArchTimerFreqInHz, however
the intended effect of that is not possible from AArch64 EL2/1, and has
never been performed unless built for ARM.

The Pcd is now being deleted, so drop the setting.

This has however affected timer timout calculations, so could lead to a
change in platform behaviour.

Cc: Sami Mujawar 
Cc: Thomas Abraham 
Signed-off-by: Leif Lindholm 
---
 Platform/ARM/Morello/MorelloPlatform.dsc.inc | 2 --
 Platform/ARM/SgiPkg/SgiPlatform.dsc.inc  | 2 --
 Platform/ARM/N1Sdp/N1SdpPlatform.dsc | 2 --
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 6 --
 4 files changed, 12 deletions(-)

diff --git a/Platform/ARM/Morello/MorelloPlatform.dsc.inc 
b/Platform/ARM/Morello/MorelloPlatform.dsc.inc
index e7f4b6d0dde8..d2f885d1c10f 100644
--- a/Platform/ARM/Morello/MorelloPlatform.dsc.inc
+++ b/Platform/ARM/Morello/MorelloPlatform.dsc.inc
@@ -110,8 +110,6 @@ [PcdsFixedAtBuild.common]
   # PL031 RealTimeClock
   gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x1C10
 
-  # ARM Architectural Timer Frequency
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|5000
   gEmbeddedTokenSpaceGuid.PcdMetronomeTickPeriod|1000
   gEmbeddedTokenSpaceGuid.PcdTimerPeriod|1000
 
diff --git a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc 
b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
index 107a5311b666..1090fbe2a1fc 100644
--- a/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
@@ -178,8 +178,6 @@ [PcdsFixedAtBuild.common]
   # ARM OS Loader
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
 
-  # ARM Architectural Timer Frequency
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|1
   gEmbeddedTokenSpaceGuid.PcdMetronomeTickPeriod|1000
   gEmbeddedTokenSpaceGuid.PcdTimerPeriod|1000
 
diff --git a/Platform/ARM/N1Sdp/N1SdpPlatform.dsc 
b/Platform/ARM/N1Sdp/N1SdpPlatform.dsc
index 743c2e647b76..b14ece1b8f61 100644
--- a/Platform/ARM/N1Sdp/N1SdpPlatform.dsc
+++ b/Platform/ARM/N1Sdp/N1SdpPlatform.dsc
@@ -149,8 +149,6 @@ [PcdsFixedAtBuild.common]
   # ARM OS Loader
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
 
-  # ARM Architectural Timer Frequency
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|1
   gEmbeddedTokenSpaceGuid.PcdMetronomeTickPeriod|1000
   gEmbeddedTokenSpaceGuid.PcdTimerPeriod|1000
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
index c5fcf74b4e0a..60556f6661c4 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -213,12 +213,6 @@ [PcdsFixedAtBuild.common]
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0x4000
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0x1000
 
-  #
-  # ARM Architectural Timer Frequency
-  #
-  # Set tick frequency value to 100Mhz
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|1
-
   #
   # ACPI Table Version
   #
-- 
2.39.2



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

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

[Leif Lindholm]

PcdArmArchTimerFreqInHz is about to be removed, as it is now obsolete.
Some platforms already explicitly set it to 0, which is the default.
And some modules reference it in their .inf without actually ever
using it.

Drop these redundant uses first.

Cc: Ard Biesheuvel 
Cc: Chuong Tran 
Cc: Graeme Gregory 
Cc: Marcin Juszkiewicz 
Cc: Meenakshi Aggarwal 
Cc: Nhi Pham 
Cc: Rebecca Cran 
Cc: Sami Mujawar 
Cc: Thomas Abraham 
Cc: Wenyi Xie 
Signed-off-by: Leif Lindholm 
---
 Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc   
| 5 -
 Silicon/NXP/NxpQoriqLs.dsc.inc 
| 3 ---
 Platform/ARM/JunoPkg/ArmJuno.dsc   
| 6 --
 Platform/Hisilicon/D03/D03.dsc 
| 8 
 Platform/Hisilicon/D06/D06.dsc 
| 8 
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc
| 5 -
 Platform/Hisilicon/D03/Library/HisiOemMiscLib2P/HisiOemMiscLib2PHi1610.inf 
| 1 -
 Platform/Hisilicon/D05/Library/HisiOemMiscLibD05/HisiOemMiscLibD05.inf 
| 1 -
 Platform/Hisilicon/D06/Library/HisiOemMiscLibD06/HisiOemMiscLibD06.inf 
| 1 -
 Silicon/AMD/Styx/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.inf   
| 1 -
 Silicon/Hisilicon/Drivers/Smbios/ProcessorSubClassDxe/ProcessorSubClassDxe.inf 
| 1 -
 11 files changed, 40 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc 
b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
index eb6caf37a3c5..1f705c68579a 100644
--- a/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
+++ b/Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc
@@ -458,11 +458,6 @@ [PcdsFixedAtBuild.common]
   gArmTokenSpaceGuid.PcdGicDistributorBase|0x1001
   gArmTokenSpaceGuid.PcdGicRedistributorsBase|0x10010014
 
-  #
-  # ARM Architectural Timer Frequency
-  #
-  # Set it to 0 so that the code will read frequence from register
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|0
   gEmbeddedTokenSpaceGuid.PcdMetronomeTickPeriod|1000
 
   #
diff --git a/Silicon/NXP/NxpQoriqLs.dsc.inc b/Silicon/NXP/NxpQoriqLs.dsc.inc
index 920d2f6c4ddf..21549dc20aa7 100644
--- a/Silicon/NXP/NxpQoriqLs.dsc.inc
+++ b/Silicon/NXP/NxpQoriqLs.dsc.inc
@@ -290,9 +290,6 @@ [PcdsFixedAtBuild.common]
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
   gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
 
-  # Timer
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|0
-
   # We want to use the Shell Libraries but don't want it to initialise
   # automatically. We initialise the libraries when the command is called by 
the
   # Shell.
diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index 1ca43b9e7dba..93ec9f129972 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -191,12 +191,6 @@ [PcdsFixedAtBuild.common]
   # List of Device Paths that support BootMonFs
   
gArmBootMonFsTokenSpaceGuid.PcdBootMonFsSupportedDevicePaths|L"VenHw(DE6AE758-D662-4E17-A97C-4C5964DA4C41,00)"
 
-  #
-  # ARM Architectural Timer Frequency
-  #
-  # Set to 0 so ArmArchTimerLib will read its value from CNTFRQ_EL0
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|0
-
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
 
   #
diff --git a/Platform/Hisilicon/D03/D03.dsc b/Platform/Hisilicon/D03/D03.dsc
index 66c2bb31a5ef..e70dc97ee894 100644
--- a/Platform/Hisilicon/D03/D03.dsc
+++ b/Platform/Hisilicon/D03/D03.dsc
@@ -191,14 +191,6 @@ [PcdsFixedAtBuild.common]
   gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0xFE00
   gArmTokenSpaceGuid.PcdGicRedistributorsBase|0x4D10
 
-  #
-  # ARM Architectual Timer Frequency
-  #
-  # Set it to 0 so that the code will read frequence from register and be
-  # adapted to 66M and 50M boards
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|0
-
-
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
 
diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
index f8a8dad01a0e..6e0fcf633404 100644
--- a/Platform/Hisilicon/D06/D06.dsc
+++ b/Platform/Hisilicon/D06/D06.dsc
@@ -167,14 +167,6 @@ [PcdsFixedAtBuild.common]
   gArmTokenSpaceGuid.PcdGicRedistributorsBase|0xAE10
   gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x9B00
 
-
-
-  #
-  # ARM Architectual Timer Frequency
-  #
-  # Set it to 0 so that the code will read frequency from register and be
-  # adapted to 100M and 50M boards
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|0
   gEmbeddedTokenSpaceGuid.PcdTimerPeriod|1
 
 
diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 4fea9a0d6380..9306986bf7c0 100644
--- 

[edk2-devel] [PATCH edk2-platforms 4/5] Platform/Hisilicon: drop D05 use of PcdArmArchTimerFreqInHz

[Leif Lindholm]

The D05 platform explicitly sets PcdArmArchTimerFreqInHz, however the
intended effect of that is not possible from AArch64 EL2/1, and has
never been performed unless built for ARM.

The Pcd is now being deleted, so drop the setting.

This has however affected timer timout calculations, so could lead to a
change in platform behaviour.

Cc: Ard Biesheuvel 
Cc: Wenyi Xie 
Signed-off-by: Leif Lindholm 
---
 Platform/Hisilicon/D05/D05.dsc | 6 --
 1 file changed, 6 deletions(-)

diff --git a/Platform/Hisilicon/D05/D05.dsc b/Platform/Hisilicon/D05/D05.dsc
index d247e67e92fc..0cd98d54ddb3 100644
--- a/Platform/Hisilicon/D05/D05.dsc
+++ b/Platform/Hisilicon/D05/D05.dsc
@@ -198,12 +198,6 @@ [PcdsFixedAtBuild.common]
   gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0xFE00
 
 
-  #
-  # ARM Architectual Timer Frequency
-  #
-  gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|5000
-
-
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
-- 
2.39.2



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

[edk2-devel] [PATCH edk2-platforms 0/5] Platform,Silicon: drop use of PcdArmArchTimerFreqInHz

[Leif Lindholm]

Related to https://github.com/tianocore/edk2/pull/5797

PcdArmArchTimerFreqInHz is about to be removed, as it is now obsolete.
Its functionality has been partially broken, and mostly ignored, for
all AArch64 platforms since December 2020.

This set cleans up some broken line endings in .dsc* files, then
drops all non-invasive references to the Pcd:
- .dsc* files setting it to 0 (which is the default in the definition,
  and means "just read it from the system register instead")
- .inf files declaring a dependency that is in fact not there in
  current code.

Finally, it drops the setting of the Pcd for platforms that set it to
non-0. This has *never* done the right thing on these platforms since
they are all AArch64, but it may affect timer timeout, so deserves
deeper testing.

Cc: Ard Biesheuvel 
Cc: Chuong Tran 
Cc: Graeme Gregory 
Cc: Marcin Juszkiewicz 
Cc: Marcin Wojtas 
Cc: Meenakshi Aggarwal 
Cc: Narinder Dhillon 
Cc: Nhi Pham 
Cc: Rebecca Cran 
Cc: Sami Mujawar 
Cc: Thomas Abraham 
Cc: Wenyi Xie 

Leif Lindholm (5):
  Platform/SbsaQemu: fix .dsc line endings
  Platform,Silicon: drop redundant uses of PcdArmArchTimerFreqInHz
  Platform/ARM: drop use of PcdArmArchTimerFreqInHz
  Platform/Hisilicon: drop D05 use of PcdArmArchTimerFreqInHz
  Silicon/Marvell: drop use of PcdArmArchTimerFreqInHz

 Platform/ARM/Morello/MorelloPlatform.dsc.inc   
| 4 +---
 Platform/ARM/SgiPkg/SgiPlatform.dsc.inc
| 2 --
 Silicon/Ampere/AmpereAltraPkg/AmpereAltraPkg.dsc.inc   
| 7 +--
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc  
| 4 +---
 Silicon/NXP/NxpQoriqLs.dsc.inc 
| 5 +
 Platform/ARM/JunoPkg/ArmJuno.dsc   
| 6 --
 Platform/ARM/N1Sdp/N1SdpPlatform.dsc   
| 2 --
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc   
| 6 --
 Platform/Hisilicon/D03/D03.dsc 
| 8 
 Platform/Hisilicon/D05/D05.dsc 
| 6 --
 Platform/Hisilicon/D06/D06.dsc 
| 8 
 Platform/Qemu/SbsaQemu/SbsaQemu.dsc
| 7 +--
 Platform/Hisilicon/D03/Library/HisiOemMiscLib2P/HisiOemMiscLib2PHi1610.inf 
| 1 -
 Platform/Hisilicon/D05/Library/HisiOemMiscLibD05/HisiOemMiscLibD05.inf 
| 1 -
 Platform/Hisilicon/D06/Library/HisiOemMiscLibD06/HisiOemMiscLibD06.inf 
| 1 -
 Silicon/AMD/Styx/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.inf   
| 1 -
 Silicon/Hisilicon/Drivers/Smbios/ProcessorSubClassDxe/ProcessorSubClassDxe.inf 
| 1 -
 17 files changed, 5 insertions(+), 65 deletions(-)

-- 
2.39.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119653): https://edk2.groups.io/g/devel/message/119653
Mute This Topic: https://groups.io/mt/106780872/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

[Leif Lindholm]

Thank you.

Reviewed-by: Leif Lindholm 
Pushed as 4e36179c55f4.

/
Leif

On 2024-06-13 12:07, Tommy Huang via groups.io wrote:

Hi Leif,

Got it.
I have pushed my patch update into below .git.
You could clone it for further checked.

https://github.com/TommyHuang0527/Gop_test_repo.git

BR,

By Tommy


-Original Message-
From: Leif Lindholm 
Sent: Thursday, June 13, 2024 12:03 PM
To: Tommy Huang ; Nhi Pham
; devel@edk2.groups.io
Cc: a...@kernel.org; nathaniel.l.desim...@intel.com;
michael.d.kin...@intel.com; Ryan Chen ;
BMC-SW 
Subject: Re: [edk2-devel] [PATCH] ASpeed/ASpeedGopBinPkg: Update
X64/AArch64 Gop UEFI Driver

On 2024-06-13 09:04, Tommy Huang wrote:

Hi Leif,

Do we need to do more test for this commit?
Or include more people for this?


Hi Nhi,

Apologies, traveling and having patchy access to time to look at things.

Tommy, could you push this set to a public branch somwhere I could grab it
from?

Best Regards,

Leif


BR,

By Tommy


-Original Message-
From: Nhi Pham 
Sent: Friday, May 31, 2024 8:20 PM
To: Tommy Huang ;

devel@edk2.groups.io;

quic_llind...@quicinc.com
Cc: a...@kernel.org; nathaniel.l.desim...@intel.com;
michael.d.kin...@intel.com; Ryan Chen ;
BMC-SW 
Subject: 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 (#119566): https://edk2.groups.io/g/devel/message/119566
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

[Leif Lindholm]

On 2024-06-13 09:33, Leif Lindholm wrote:

On 2024-06-13 09:04, Tommy Huang wrote:

Hi Leif,

Do we need to do more test for this commit?
Or include more people for this?


Hi Nhi,

Apologies, traveling and having patchy access to time to look at things.


(As can also be seen by how I misread who sent the email...)

Tommy, could you push this set to a public branch somwhere I could grab 
it from?


Best Regards,

Leif


BR,

By Tommy


-Original Message-
From: Nhi Pham 
Sent: Friday, May 31, 2024 8:20 PM
To: Tommy Huang ; devel@edk2.groups.io;
quic_llind...@quicinc.com
Cc: a...@kernel.org; nathaniel.l.desim...@intel.com;
michael.d.kin...@intel.com; Ryan Chen ;
BMC-SW 
Subject: 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 (#119564): https://edk2.groups.io/g/devel/message/119564
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

[Leif Lindholm]

On 2024-06-13 09:04, Tommy Huang wrote:

Hi Leif,

Do we need to do more test for this commit?
Or include more people for this?


Hi Nhi,

Apologies, traveling and having patchy access to time to look at things.

Tommy, could you push this set to a public branch somwhere I could grab 
it from?


Best Regards,

Leif


BR,

By Tommy


-Original Message-
From: Nhi Pham 
Sent: Friday, May 31, 2024 8:20 PM
To: Tommy Huang ; devel@edk2.groups.io;
quic_llind...@quicinc.com
Cc: a...@kernel.org; nathaniel.l.desim...@intel.com;
michael.d.kin...@intel.com; Ryan Chen ;
BMC-SW 
Subject: 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 (#119563): https://edk2.groups.io/g/devel/message/119563
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 v2 0/2] ArmPkg/MdePkg: Move Chipset/* files to MdePkg

[Leif Lindholm]

On 2024-03-14 20:21, PierreGondois wrote:

v2:
- Move files to MdePkg/Include/Register/ instead of  MdePkg/Include/

This patch relies on [1].

Following the RFC v1: ArmPkg,MdePkg: move ArmLib.h to MdePkg [1],
move the Chipset/* files to the MdePkg as the Armlib.h relies on
them.

These patches span over multiple packages as these Chipset/* files
are relocated to a new directory and include paths must be updated.

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


For my part, for the series:
Reviewed-by: Leif Lindholm 


Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Leif Lindholm 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Cc: Zhiguang Liu 

Pierre Gondois (2):
   ArmPkg,MdePkg: Move ArmPkg/Chipset/AArch64[|Mmu].h to MdePkg
   ArmPkg,MdePkg: Move ArmPkg/Chipset/ArmV7[|Mmu].h to MdePkg

  ArmPkg/Library/ArmExceptionLib/AArch64/AArch64Exception.c | 2 +-
  ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S | 2 +-
  ArmPkg/Library/ArmExceptionLib/Arm/ArmException.c | 2 +-
  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c| 2 +-
  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S| 2 +-
  ArmPkg/Library/ArmLib/Arm/ArmV7Lib.c  | 2 +-
  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c  | 2 +-
  ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibConvert.c   | 2 +-
  ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibCore.c  | 2 +-
  ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibUpdate.c| 2 +-
  ArmPlatformPkg/PrePeiCore/AArch64/Exception.S | 2 +-
  ArmPlatformPkg/PrePeiCore/AArch64/Helper.S| 2 +-
  ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c  | 2 +-
  ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S   | 2 +-
  ArmVirtPkg/PrePi/AArch64/ArchPrePi.c  | 2 +-
  MdePkg/Include/Library/ArmLib.h   | 4 ++--
  .../Chipset => MdePkg/Include/Register/AArch64}/AArch64.h | 2 +-
  .../Chipset => MdePkg/Include/Register/AArch64}/AArch64Mmu.h  | 0
  .../Chipset/ArmV7.h => MdePkg/Include/Register/Arm/AArch32.h  | 2 +-
  .../ArmV7Mmu.h => MdePkg/Include/Register/Arm/AArch32Mmu.h| 0
  20 files changed, 19 insertions(+), 19 deletions(-)
  rename {ArmPkg/Include/Chipset => MdePkg/Include/Register/AArch64}/AArch64.h 
(94%)
  rename {ArmPkg/Include/Chipset => 
MdePkg/Include/Register/AArch64}/AArch64Mmu.h (100%)
  rename ArmPkg/Include/Chipset/ArmV7.h => 
MdePkg/Include/Register/Arm/AArch32.h (94%)
  rename ArmPkg/Include/Chipset/ArmV7Mmu.h => 
MdePkg/Include/Register/Arm/AArch32Mmu.h (100%)





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

Re: [edk2-devel] ArmCallSmc() and SMCCC specification

[Leif Lindholm]

Hi Marcin.

A few high-level thoughs below.

On 2024-05-31 08:14, Marcin Juszkiewicz wrote:

EDK2/ArmPkg/Library/ArmSmcLib has code to do SMC calls.

There are ArmCallSmc[0-3]() functions for up to 3 arguments/results and 
ArmCallSmc() function which can use 7 arguments and get 4 results back.


This implementation looks like version B (Nov 2016) of SMCCC 
specification [1] with one more register used.


1. https://developer.arm.com/documentation/den0028/b/

In 2020 we got version C of spec (and then D, E, F) which allows to use 
more registers:


 > Allow R4—R7 (SMC32/HVC32) to be used as result registers.
 > Allow X8—X17 to be used as parameter registers in SMC64/HVC64.
 > Allow X4—X17 to be used as result registers in SMC64/HVC64.

And I started to wonder how to update EDK2 to newer version of SMCCC 
spec as one of in-progress QemuSbsa SMC calls may return more than 4 
values.


Yes, definitely. This has been a wishlist item for some time, but in 
reality we've only ever updated these when we needed new functionality.


ARM_SMC_ARGS in ArmSmcLib.h can be expanded to handle up to Arg17 in an 
easy way and guarded by "#if defined(__aarch64__)" to not change it on 
Arm32.


Then ArmCallSmc() in {AArch64,Arm}/ArmSmc.S needs changes. But here it 
gets tricky.


On Arm we preserve r4-r8 and restore them after call like spec says. 
Which we do not do on AArch64 as version B of spec did not required that 
(and this changed in version C).


If we start handling more than 4 results then we need to know how many 
results are expected and restore rest of r4-r7/x4-x17 registers:


Yeah, it feels like we may want to add a version field or/and number of 
registers to save/restore to a new struct. And we should definitely 
align Arm/AArch64 behaviour.


 From what I saw in both edk2/ and edk2-platforms/ most of code uses 
ArmCallSmc() function with ARM_SMC_ARGS structure populared with 
arguments. ArmCallSmc[0-3]() are used by Smbios, Psci and QemuSbsa code 
only.


The ArmCallSmc[0-3] helpers were only added as shorthand for most common 
cases. I don't think we should worry about how those work for making any 
design decisions. Everything they do can be described by the main 
ArmCallSmc functions and a few lines of struct stuffing.



Now the question is: how to handle change?


It could be that it would be easiest to add a new call function, and 
maybe even ra new egister struct, than trying to adapt the existing ones 
in ways that doesn't break existing users?


That is if we care about existing users. We could always modify it to 
guarantee breakage and expect users to update their code. Since this is 
a library, and not a protocol, we *mostly* don't need to worry about 
users mixing prebuilt binaries using old structs with new functions.


We could add ArmCallSmc[4-17] but that name only tells how many 
arguments we pass to SMC call, not how many results we expect. Or should 
we add NumberOfResults argument to ArmCallSmc() to know which registers 
we should preserve and which are results? And how complicated this 
assembly function will become?


I don't think the assembly function needs to be that complicated. It'd 
be a bit tedious with a bunch of tests, but...


/
Leif



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

Re: [edk2-devel] SMBIOS BIOS ROM Size

[Leif Lindholm]

On 2024-05-30 12:58, Rebecca Cran wrote:

On 5/30/2024 4:06 AM, Leif Lindholm via groups.io wrote:
While reviewing https://github.com/tianocore/edk2/pull/5702, I found 
myself wondering "shouldn't this (doesn't apply to UEFI-based systems) 
be the case for the size field also?".


But the SMBIOS spec is quite clear that the size field refers to the 
size of the physical device the BIOS is stored on.


Currently, this field is hardwired to PcdFdSize in the smbios helper 
library. But that would only be accurate for platforms that use the 
edk2 build system to generate the final flashable image to a fixed size.


This isn't really true for SbsaQemu, and I don't think it is for Mt. 
Jade. And those are the only two upstream platforms using this 
SmbiosMiscDxe.


Do we need to solve this by adding another function for OemMiscLib?


I still need to update ArmVirtPkg to use it, but I have this commit 
waiting to be submitted:


Ah, excellent :)

/
Leif


commit e6d4d2a8cf995a7f4f60e7f55ff2ab494308f939
Author: Rebecca Cran 
Date:   Wed May 15 09:10:54 2024 -0600

     ArmPkg: Add new function OemGetPhysicalBiosSize to OemMiscLib

     The FD size often isn't the same as the physical size of the SPI-NOR
     EEPROM it gets written to, but is instead combined with other files 
and
     data to create the final image. Add a function 
`OemGetPhysicalBiosSize`

     which allows platforms to provide the actual size of the EEPROM for
     SMBIOS.





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

[edk2-devel] SMBIOS BIOS ROM Size

[Leif Lindholm]

Hi Rebecca,

While reviewing https://github.com/tianocore/edk2/pull/5702, I found 
myself wondering "shouldn't this (doesn't apply to UEFI-based systems) 
be the case for the size field also?".


But the SMBIOS spec is quite clear that the size field refers to the 
size of the physical device the BIOS is stored on.


Currently, this field is hardwired to PcdFdSize in the smbios helper 
library. But that would only be accurate for platforms that use the edk2 
build system to generate the final flashable image to a fixed size.


This isn't really true for SbsaQemu, and I don't think it is for Mt. 
Jade. And those are the only two upstream platforms using this 
SmbiosMiscDxe.


Do we need to solve this by adding another function for OemMiscLib?

/
Leif


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119385): https://edk2.groups.io/g/devel/message/119385
Mute This Topic: https://groups.io/mt/106385738/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-non-osi v2 1/1] Qemu/Sbsa: update to TF-A 2.11.0

[Leif Lindholm]

On 2024-05-29 14:29, Marcin Juszkiewicz wrote:

Update TF-A binaries to the same version as QEMU CI uses.

Signed-off-by: Marcin Juszkiewicz 


Reviewed-by: Leif Lindholm 


---
  Platform/Qemu/Sbsa/Readme.md |  49 ---
  Platform/Qemu/Sbsa/bl1.bin   | Bin 23349 -> 2 bytes
  Platform/Qemu/Sbsa/fip.bin   | Bin 82722 -> 82722 bytes
  3 files changed, 5 insertions(+), 44 deletions(-)
  mode change 100755 => 100644 Platform/Qemu/Sbsa/bl1.bin

diff --git a/Platform/Qemu/Sbsa/Readme.md b/Platform/Qemu/Sbsa/Readme.md
index b1351043d2b4..ceef51b6a500 100644
--- a/Platform/Qemu/Sbsa/Readme.md
+++ b/Platform/Qemu/Sbsa/Readme.md
@@ -4,51 +4,12 @@ Qemu SBSA TF-A binaries
  These binaries have been created from the mainline TF-A
  code checked out at the following commit ID:
  
-commit 56b263cb2a25892038761acea8c2b57a638d19bf (HEAD -> integration, origin/integration, gerrit/integration)

-Merge: 09d3fd141 e769f830d
-Author: Yann Gautier 
-Date:   Tue Apr 23 10:42:01 2024 +0200
+commit f2735ebccf5173f74c0458736ec526276106097e (tag: v2.11.0, tag: v2.11)
+Merge: 6370f2cbb 669e2b159
+Author: Manish Pandey 
+Date:   Thu May 23 13:51:22 2024 +0200
  
-Merge "feat(qemu): allow ARM_ARCH_MAJOR/MINOR override" into integration

-
-
-This ensures that the following features for qemu_sbsa platform are
-merged upstream and included in the build:
-
-commit 5436047a0e1f32543042d6de9f1f6a3edcd47591
-Author: Marcin Juszkiewicz 
-Date:   Mon Apr 22 17:27:56 2024 +0200
-
-refactor(qemu): do not hardcode counter frequency
-
-From QEMU change:
-
-> In previous versions of the Arm architecture, the frequency of the
-> generic timers as reported in CNTFRQ_EL0 could be any IMPDEF value,
-> and for QEMU we picked 62.5MHz, giving a timer tick period of 16ns.
-> In Armv8.6, the architecture standardized this frequency to 1GHz.
-
-This change stops TF-A from hardcoding 62.5MHz frequency. Instead value
-stored in CNTFRQ_EL0 would be used. As a result we get 62.5MHz on older
-cores and 1GHz on newer ones.
-
-Change-Id: I7d414ce6d3708e598bbb5a6f79eb2d4ec8e15ac4
-Signed-off-by: Marcin Juszkiewicz 
-
-commit 1b694c77c497cb8272c97417ef1fa4f5f9c869c1
-Author: Jean-Philippe Brucker 
-Date:   Mon Apr 15 14:28:11 2024 +0100
-
-feat(qemu): enable FEAT_ECV when present
-
-QEMU supports FEAT_ECV since commit 2808d3b38a52 ("target/arm: Implement
-FEAT_ECV CNTPOFF_EL2 handling"), in the v9.0.0 release. Enable
-auto-detecting the feature on the QEMU platforms, in order to set
-SCR.ECVEN. Without this, EL2 gets undefined instruction exceptions when
-trying to access the new CNTPOFF register.
-
-Change-Id: I555a5f9a9a84fd23e64ca85219ed1599204c6bb2
-Signed-off-by: Jean-Philippe Brucker 
+Merge "docs(changelog): changelog for v2.11 release" into integration
  
  
  NOTE: No modifications to the source code have been done.

diff --git a/Platform/Qemu/Sbsa/bl1.bin b/Platform/Qemu/Sbsa/bl1.bin
old mode 100755
new mode 100644
index 
6ad39377a464050dcc714d1316ff8981ad637ded..9e0136efdf85b743d28b59bb46a66f09fe3a3557
GIT binary patch
delta 7483
zcmZ`+dw5jUwO{+3Gn12-WFE=Mn2?!C0!fBfAPI?xa54l<5R`;LP^nCW_$aiRg4KRN
z=LAzPx3QGN9vwfl5PW^f)b?5-)>x`R5a}0eVKkQ3R|Y6X2Wx;JImv{5zdf@jdeVE(
zA6c`0zqR&Wd#|>;{we_fd;tI6RIq|+K_9?RUjtKKUk|_bqxhJT>R9a^?%~&}S2NL@I33w?C3PJK
zDVKRZ=y+`1a1TJ&y~IA~27?N<*p24+eq#iGKW`28^Hf?~6$1DbP#W5e(0%1@cPHg8
zuc+=E+j6Ai_W;&>P#XSCh%~n4?anbC)DuSVk8L^J(Psqf*p@$cIsjgU{z)q3F0VkH
zWdN^kx-CP!VgYR*#O4UbR(issJ_|69P8tVFt!er4SspEAl?_$-Yu%XO7S4;)nV+hy$xkJNCHti8m=S0y8;=r549@FJvs
z$}m7sPO&dJ@KYbmfq#Y({EjhFkpf^nGfmbgza2qWKePEI2kCyrC~GZdxqDX<__0H<
zE^En>yVnAW`~|=h;=sRxSIl(8Egbj<2$8m%p*zfH2G6cT>N_0xukhfaBVUP<@?)`R
zGF{aEArAbX;5y+(&S=C>2yS!_{)^y11NbXpQSyLWs|L`x0X)}m3mU*bH@t@i@Xf}J
zld@HmCTooV2a!<;eSr@fZTM1BwpCIax$IaqWD2s@&+{&`5$B2a!fS5r%n?w%+#>By
z2>deZkXTaruAIeb&Hgg(P7lWV4=8oT?9pj{+HqQ@8nSz8Fa
zMt?7iaxs}dgx^ZOKC8e8ehSm`=BTaf1_A0FwfNu3#YnorTCrnN6~UT@48%M!>g{F
zmS$5aF~nuIwJ$%g^SWusQ>%o6w7Hn&ZvL1O;%-(#2y%bo&Uk#!<3_oA5oFAD!y~U1
zBvtkK(pF!R0X%NF>$Mhu3Y6ylV4(=j?Es#Z6j^g-$h#Ll02do^a)v#PT&|A9t=GSX
zi!*Z3G`u*&pFUt!KaP?>{TK-(3;29S-sGWC5(x8_@uS=Ry*~CecADN>42G&cd)n$t
zUI357D{BsOb{_~;eGq-@1H0(EL<4X>Z$0`)K<0onxUdT?kwR0R3{9
zH@HCAzDL_2bXtJx9pxc-?jh*jG_`Nf2ybz1T3Xf?en{?K%cBi$9z5H#z)EfV1@OFhjZ`2|b~_z?d)9*UtNj3;X8_7u%(CVz?AsF-psQt;
z-2J#k*75}bOxyAAq#T)@;t}F$
zjgs;+JOruFx+gd9rash{`aMlZ;ByWl5kjPv>*emVe71{nD+vjBInWNris?}7QlvTf
zmPf(lY`MD#WQ|^gPEpp57-fwUW$kJXXkif!p7Q|;Ugja#3Vg7~ENlCw%a^Lt!DENo
zivo0ngp8UIT8nl;zSxomo-2UbT)?+=8R3-20H+9KM(*9^8RJ9T!@N)zB!+ch-pO=E1K?!|e0KYe1*6fgpx7cR*-UYc+1ffkdz$qU<q8Kc3GpCM%;^Bu
zw>d-P1prSg7-DN9AVf+C@$BQ^<_Ld{czhs6I;7oR!y`m;3W|A{wnC(sza>O+w}bjeyzTl*^h4Zr{r{j|+>}$8Hk_$W9U+0|Mo7Se
zpUNr2uONrqioi-=Gl&Dv*p|0q)k3S|8$tp@JOrmg>}?Q4AZuU8DofUssi4tt=q>6

Re: [edk2-devel] [PATCH edk2-non-osi 1/1] Qemu/Sbsa: update to TF-A 2.11.0

[Leif Lindholm]

Can you update the hashes in Readme.md as well?

/
Leif

On 2024-05-29 14:18, Marcin Juszkiewicz wrote:

Update TF-A binaries to the same version as QEMU CI uses.

Signed-off-by: Marcin Juszkiewicz 
---
  Platform/Qemu/Sbsa/bl1.bin | Bin 23349 -> 2 bytes
  Platform/Qemu/Sbsa/fip.bin | Bin 82722 -> 82722 bytes
  2 files changed, 0 insertions(+), 0 deletions(-)
  mode change 100755 => 100644 Platform/Qemu/Sbsa/bl1.bin

diff --git a/Platform/Qemu/Sbsa/bl1.bin b/Platform/Qemu/Sbsa/bl1.bin
old mode 100755
new mode 100644
index 
6ad39377a464050dcc714d1316ff8981ad637ded..9e0136efdf85b743d28b59bb46a66f09fe3a3557
GIT binary patch
delta 7483
zcmZ`+dw5jUwO{+3Gn12-WFE=Mn2?!C0!fBfAPI?xa54l<5R`;LP^nCW_$aiRg4KRN
z=LAzPx3QGN9vwfl5PW^f)b?5-)>x`R5a}0eVKkQ3R|Y6X2Wx;JImv{5zdf@jdeVE(
zA6c`0zqR&Wd#|>;{we_fd;tI6RIq|+K_9?RUjtKKUk|_bqxhJT>R9a^?%~&}S2NL@I33w?C3PJK
zDVKRZ=y+`1a1TJ&y~IA~27?N<*p24+eq#iGKW`28^Hf?~6$1DbP#W5e(0%1@cPHg8
zuc+=E+j6Ai_W;&>P#XSCh%~n4?anbC)DuSVk8L^J(Psqf*p@$cIsjgU{z)q3F0VkH
zWdN^kx-CP!VgYR*#O4UbR(issJ_|69P8tVFt!er4SspEAl?_$-Yu%XO7S4;)nV+hy$xkJNCHti8m=S0y8;=r549@FJvs
z$}m7sPO&dJ@KYbmfq#Y({EjhFkpf^nGfmbgza2qWKePEI2kCyrC~GZdxqDX<__0H<
zE^En>yVnAW`~|=h;=sRxSIl(8Egbj<2$8m%p*zfH2G6cT>N_0xukhfaBVUP<@?)`R
zGF{aEArAbX;5y+(&S=C>2yS!_{)^y11NbXpQSyLWs|L`x0X)}m3mU*bH@t@i@Xf}J
zld@HmCTooV2a!<;eSr@fZTM1BwpCIax$IaqWD2s@&+{&`5$B2a!fS5r%n?w%+#>By
z2>deZkXTaruAIeb&Hgg(P7lWV4=8oT?9pj{+HqQ@8nSz8Fa
zMt?7iaxs}dgx^ZOKC8e8ehSm`=BTaf1_A0FwfNu3#YnorTCrnN6~UT@48%M!>g{F
zmS$5aF~nuIwJ$%g^SWusQ>%o6w7Hn&ZvL1O;%-(#2y%bo&Uk#!<3_oA5oFAD!y~U1
zBvtkK(pF!R0X%NF>$Mhu3Y6ylV4(=j?Es#Z6j^g-$h#Ll02do^a)v#PT&|A9t=GSX
zi!*Z3G`u*&pFUt!KaP?>{TK-(3;29S-sGWC5(x8_@uS=Ry*~CecADN>42G&cd)n$t
zUI357D{BsOb{_~;eGq-@1H0(EL<4X>Z$0`)K<0onxUdT?kwR0R3{9
zH@HCAzDL_2bXtJx9pxc-?jh*jG_`Nf2ybz1T3Xf?en{?K%cBi$9z5H#z)EfV1@OFhjZ`2|b~_z?d)9*UtNj3;X8_7u%(CVz?AsF-psQt;
z-2J#k*75}bOxyAAq#T)@;t}F$
zjgs;+JOruFx+gd9rash{`aMlZ;ByWl5kjPv>*emVe71{nD+vjBInWNris?}7QlvTf
zmPf(lY`MD#WQ|^gPEpp57-fwUW$kJXXkif!p7Q|;Ugja#3Vg7~ENlCw%a^Lt!DENo
zivo0ngp8UIT8nl;zSxomo-2UbT)?+=8R3-20H+9KM(*9^8RJ9T!@N)zB!+ch-pO=E1K?!|e0KYe1*6fgpx7cR*-UYc+1ffkdz$qUd-P1prSg7-DN9AVf+C@$BQ^<_Ld{czhs6I;7oR!y`m;3W|A{wnC(sza>O+w}bjeyzTl*^h4Zr{r{j|+>}$8Hk_$W9U+0|Mo7Se
zpUNr2uONrqioi-=Gl&Dv*p|0q)k3S|8$tp@JOrmg>}?Q4AZuU8DofUssi4tt=q>6
zyOkb_%cCSfIr_$>x9WVHo>xBo=^E_=MmP{uv_Jiw!^aaG3h|HfO4d$MkBpGOCSpJ7
zeWy@$j*@`#e2qpMV(byzU#Px1N&?FH|Wqa@I?6F+aChn~lu+NYs!aI&Ky
z`5X`a^E~*s;0njA%(h_?*w2IYET0!tta6nX;NS@UnPXP4BM_{eS%L*jCv7i?1z+DB?OxqDyWl%!&=J|%t3qFD`
z7OYBNhrl|>=LKVT3SL=gFIkPi>I5Zp2a_HIR>Ucxh6(;l@NWt?7|SRN*f=E*PoGk5
zoJ^fKe9x4u%xX>vWzsk}C1gQhZRC`Y39C~crF%AYt?y$1D-x8@KbZVGm7Egd1SRwt
zfYm7|p%CLvGD*3ZouGtzzlSC4jxp>g^M8lwJxspE@IwHm*aUAf;0*vPesa14{TADb
z9x`A6tBfxemEoSE$Iv=_L-DGtdN#)GOfI9+i1!xT9ikFiL^V+fRmV^zlrJiwS~|F>
zgy!Ra6&IjcIJsmMdImR^OtTsQ24C_Ps{l$!02plb=BfvtDcNp7*W;X7x1$2QVU`!|
z!Y5|!Fcn6L)CjMHmPCoVpiZN)d0)tBW4!-Pm4G+g=UOi-h|)phmK
zw%uM%?(Q;z$u~q>Os?xPF9qKtM0zeCO#ATRvLY14UzQaa;(BJe-S&ea`cAS22MLj^
z+;HXA1)z@dR@ZZQS-JDZ9G8Rsv&82HyEsUFnh@#Pd@%WVX#N#|huS`OdE4%92$7<^
zC1^QP-gbcy=}aYPGVUy&j^-ZtsQl-sq=%DlfF7vla>2Z|5SovNiN}qUhL4P(UgfwP
z+F)tey?EQ)`}uvq;VDhfK|DW30s~`lVD}Azcx;RWjx!xA
zHwfa(VaZ)1%h~A
zlms3~7%UXTo1-L9J8rO05T`~-pqK%^CyfyMI>fk4e13*MlaxT>UkAg_CH#`(_;Thy
zKP9evne;PxkjbjlI6oNI8{jx265nd3*D%?`9EQ^37AKhWGr5#WVDb}uN|s#5nb-R(
z<6eJfGR$Oz$tx?dv(k28TD1YWinVJCsrAWQ;y$f;aaqOiukVQKxp~-GndeTxpN_+N
z^Y{NBeA_sF;IR9Cgi9-vT#2#%JkIII`rSBAr#2_dfAfFCzxqCW-?(++i^YH2IQ*mU
zTW2K`wlfGjDue3CEp3gcK5{D!NgdF@iC3>>c`Ax__LqsN1M;^
z>PhL;aeS52Spr8y~+{YeMZY8{opqA!G-Ho`
zrJubY*VjpP1B~_WH|ypaWcV}|L(P=f+_0X>_$1%$+eZ9{I?1+~u^S%L@4!|Zu9Ix7
zjJ@s0`bZ98(-O&cl(F~h)w3sX^%BYUA!8qVUeA7lo0mwobBulak9zh3-oHfh4KcPk
z-x^zEl<65$<7--x1rSa`D4Xdrla<#2oJm5cmg#GleC7uL=aar$`%#Afy*_q6#`ph3
z9LJTnnrt63o7(sEHlN_eTP52-g1z6a&jMC&m3+gDtvR7*g`#-;qXCD`D~;igzpKZy
z8Qycssk3)5ygQJu!;9m%3x58go+xDwmT&d=XMa`IWty61H%%?W
zA72ow?{WL(48OlAj<06=MkXhw;anWYUo17%U0^ovIpZlGV!BvNr-t#A7c+f1lZlkC
zX8J~4y-c!QVA@e{hA#3U+`LTkMH$<)SAT?r*fIg`on_H^r7`@v8a-}hc=2LAp3Cro
z&3e2rj{9KE9XYxQrZb1i?YTO_!zU(U4Z|O`&|)k2ZUfgd!t&qxM*c7k-!9cX#@LDJXk~aJ9Zxd7
zoym#mh@HB+HPd684xjJTH<-B
z>}?ZRKSuSE?K#GJEA`#sMLfG+vc1CCiud*GLEKm`*$y#w@f)!_b-WahVzpkfonUN!
z{DvH7Kg5UYCEF*AJ^xRA8K1)!>!rF2jD7UMcsChhx;P`gZxeTQ2g7?`%hpxpE?nOr
z*`8tS$_YoW9k(<{whqQ_y;pzGUd4ZCkZgw-n*sWa9LM1X$##;lKYUTY^QWPbnZ{*
z%$z-YW@+(Hnl?5yZfYu-#{h6Y^5DkJj(LvRRr6+-&nv5(?pW6NGsm1N$DGnR&52kO5&*mInu`W-<6U;7;Fh}%{x4{3?>Ybg

delta 7441
zcmZ`*dw5e-wqN_4lQew*Nt^aGv@}T{v<=VFmhw<~8jDgzpe2YP+Ll(4kwFngbU<^8
z%>B?Z%3(+2;De%gr;U7b5hz2v+@T0c=c_1WijNsblY+`;e3X~;(3E|@eX>&x-h2MY
z%KH7*+I#J_*Is+Sc@T9TL?+O;1lltH^CB2?&U{(PpGi_oBDzy4p6~u589WUD<)LKo
zj5L7f2dWcmKY&hYB-VaAj8*IaJxdK5ehL7nzSrJWq%0@aQ%I01T|Gl1ua1ZTRE
z!BYj`nGN9CoD60#%{l|{*gi1joay50KaP%>q1f(j80g~bm8L>-+yY@wsawQE^4BA{iZN!kX{Z1@JYP|??|wkKX7j4-jkrIUamnh8lkZKv@Hl
zQ)#eG#M++=a_S0V?f!Xp}a1DN{jVfL!uw9
zlk(+#JAB07i{C6pGvjlgq`5RtAhqD}gac2cg~!*!^6
zpguvY{pEQgK4QpCVrhb)6Ne3jI#Icrk&ea0V$_4H5=HbLUXob7s7L2NqX+c@AtF8R
zAV_LukW=aZ%Fm-Rx7Vp6kW^YCEeKrnbRtd;(1oVx!9#87DYY4D{2)NB&44c^7NHEB
zm2`(mROEr#en3!O0CL?Q26T9R(h6QwdT=PI0xidu

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

[Leif Lindholm]

+Nhi,

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

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?3F-mtJ91%+~28
zKnStm2mf|w(IOp3?OJ%%Lum3=0%?i$9q9);eT)E8?+bW^yzXZSLcPVjk#w}KhK4|n
zApxDGYp+oRB^LaO=qwHAT8PFS
zqQl6E+bMu2$>esHKs^_PNct?@@MQtFOd6;zu4P2s4g~r*E`8hDnMj}sn~Bb~EHR-b
zXh2tN#rLJs4O{KdL5(lc2s?zX+X5c@kDcc`cHZTb;|=zTU0F3^al3XLAvi%&tL
zMuunkBNDxOfe>z30Szi}!x%YDrPL;bw5LBwH`w$>Su7ZA6GBJ22%kHOV}=2*2anpj5&dQ08B=lHXaHGew3b6Kp-+!5gOr1{X0*AuL|&}i
z<*=7u=Ly3#G>lvfKs{uLyN+=M&Sd76H((k)cu^fM`EQZ^scIk(+(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&PyC0E8H+h?>n)DTCC-<$CdY>UCw#Z`(x6{@E
z<_`R@83M=K_wxBf-~r7#d6NAwuZK;nCPA;+FLMVD~QOkhMY&N7k2ft}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=%dsqg@f8=aPYjE4JZK&V2L0JsKIpL~;v*f>4gR_)(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&YS$??nE2H)H*{YkUzZ6fjWXCTH#%gowhmAmlp+y39r9mnDNyry!3@
zuLS{a_XFaM470++sYb;Tko3WayqhKY!^#jcFZ4&|uXf{Q#RH@rOWOsxcujeXZtMWZ
z&Q}b2g)fSzN5)#!7~8_FZUS}*GkKkHy^(%g#=PTn4T;Sd7KPcQ#pTP;J`UPNlc+E*G5T0su3or(qm3`dWr(RX0Q#Rt8*k#KE{6
zV;G_wYXdG5WAvP0XQGBK2{!jMD@VY}23QF?q!BTgO=7gKZK99A4TPI*7^bg6z)EhDDTgT1=v9F1J@wFfwAk1GL{WnuluJvw)iOFL2SCu_0454BbH*4!7BzT5IX1vlRu)3p4a(cWU1jx*q6QJy
ze6aHX0Gk;m&O)`K23+9;W&Hf~PP(D>tJKtF(WZua>@zU?LM<*wq{iiJOJx)b81$Us
zeZ2})k(V;g5Z`mFYe*ucNd-l0vj#)h&aI9EGd_~Xv_xPKak)m8D3=kwoxU-=KY8IR
z{dM>(-X?5$z?{~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+oA1h-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_;&Egqbaj6!MQwJ8{4YPV%#G)O;ZTr$ddm47X^=jSi
zR{
z(xs7o$#*UErATM%Xqfq}B(s%}N+Tqi+<7)El-UTO4aa|$0c|jTkQR7Sktqv2Lu5ox
z7$0o!4Ncm?Yh<`O#&yJPe=6(KHRG+Q{m}om8C*_4k2x#D7@sS1A3FuU9WaSC?Bq0^
zyz5^t?=lxLrZwPlN_%zB(I$)qK!EOnt;HC)W^4~^b&GWHhHWt60X@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&nn*t&zDx&C
zv>|if(laLZr{wYVI*zYjU@`ir!_;{_
ztU}ZbqVvdTlVS<1G_czW_joJa5Dget4IM7o%&i8)DnbGzCX9$eEc8Z5IN&}^nW!2+
zX}w8YGVm?UpA=36&^srEuq)(81)>}$Q%WGsfsDAF&2YALD1s+oSQMQ4z{wQbT7tHj
z%(kxx2IW4%AmVo7tP7D(i1F(32Q+B>B0bvqhR&Mo=p7_KIUt;}kQj;Q!-y*#xt%zh
zq5_dF-jCa95A0)`kvI+^vFdJaCvc*#O}5Yn5Ilq7b~Czh8=lg9^&4LnAUbM_9W@4ZqA7xgrEfqxFjOx>
z&|r*O+8SX4hto64scnx7EbB}OD*KcjTn5c$DH{UX*~6g>&H&}yuhPT#)Pxr-d~%A;
zLuJtcNQ}=R0uU94F%?)so-jwa9D;LC
za(dPsIZp=Al3YOp@S}%M?L{@->Nu(tvh*=2t|O6{5hj-@TG6)l=Z>SB%+V176eKxK
ziXX$#j~fks6i3WMEWFbb@L8xLOL7!dOD>b*XE4DfKqrafcIE+Xv>)n(LsTb8pu>1h
zgrF2Ghs_E^bvSIt+hQcff@0^2QLJw@8%T~3*mW$dc{~NC2j%9s-2vtk%$(iY?!~zs
z$}%TqEs`z&@1R_(D=?6(COMMT0UX%(8`#VxGy56A&WHw#PE>%}C^HH6Ezux=1S+=C
z0UR%Iq9dC2V$85!TOPrVs3P$z+zBi#GNx@&zIds@ZAzho0O)`Vdq~_7uE%XLuV3HL
z$ER6Pm!K(WAnb|@=b+qdQqWbdhjPz#^8=JIYa!?W;}T$nSwrx0mf?y`3GSj6^HS*!
zw9jx`(4k~Q0LO-DkyWRT=-@ayFwdYXle=yAm6L+Y`(Ar7xFuVS$(q
zFx)k!iv@Z=z_1+>xe$96;yjxFZ4={lw0)Ghjyu#rZV65ZhUHdo=+Gz&$_b#JTZzq3
zu7}b0)XF-*lo~(`mUp-Itlcr4IYLH_aE@|nmv3ZazyO+{JOsi71tvQbo_JDmw|J8A
zl2E1pdd`wpi_D~$aiMI3olRzVT)N!Rg
z-gMD)qo6C$tB~j(Rh6Pl&b2ncm

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Leif Lindholm]

On 2024-05-02 04:08, Michael Kubacki wrote:
Thank you for this proposal. We've been anticipating this change for 
years and are excited to help support it.


Here's some items we'd like to raise for feedback that we could help 
implement. Many could likely be done in time for the transition.


1. Automate reviewers - We've discussed CODEOWNERS in the past. However, 
a simpler approach (in maintaining/syncing less files) would be to use 
Maintainers.txt directly with a GitHub workflow since the file already 
contains GitHub IDs.


That would be ideal. I know Mike worked on autogenerating CODEOWNERS 
from Maintainers.txt, but ultimately the latter supports more flexible 
use of wildcards (things like */AArch64/ currently requires reconciling 
against the repo contents).


2. Make PR completion contingent on a GitHub review from at least one 
package maintainer/reviewer for each package in the PR.


Yes.

3. Dependabot is already used today to automatically create PRs when 
dependencies like pip modules have updates. To allow this to more 
effectively keep dependencies up-to-date, allow dependabot PRs to be 
completed (after normal acceptance criteria like CI and review 
requirements) without a separate human creating a duplicate PR.


I am not sure what this means in practice :)
This doesn't sound like one we need to worry about before switchover though.

4. Potentially warn users (with an automated comment on the PR) if they 
add a push label to a PR that is less than 24 hours old.


That sounds good.
Is there any way to prevent force-pushes within 24h of previous push?
That would make setting up a transitional review-scraper less lossy.

5. Leave reminder comments on PRs with absolutely no activity after some 
agreed upon time so reviewers are notified to review the PR without the 
submitter having to watch it and send notifications.


Yes. But should take priority below 1, 2, and 4. Unless you have a 
pre-cooked thing to drop in of course.


6. Leave reminder comments on PRs that meet all requirements to be 
completed (all reviews accounted for and status checks pass) but are 
still open so those on the PR are notified to complete it without the 
submitter having to manually watch and send reminders.


Not a response to this, but triggered by reading this:
Is there any way to approve changes within a PR on a commit by commit basis?


7. We are happy to help with process documentation.


Always appreciated,thanks.

Regards,

Leif



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

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Leif Lindholm]

On 2024-05-02 07:33, Marcin Juszkiewicz wrote:

W dniu 1.05.2024 o 19:43, Michael D Kinney via groups.io pisze:

I would like to propose that TianoCore move all code review from email
based code reviews to GitHub Pull Requests based code reviews.

The proposed date to switch would be immediately after the next stable
tag which is currently scheduled for May 24, 2024.


O yes! Fully for it!

Does it mean edk2 only or edk2/edk2-platforms/edk2-non-osi and other 
tianocore/ repositories?


I don't see why we couldn't switch all of them. Other than we need to 
get all the Maintainers.txt updated with code forge usernames first.


We may want to do one at a time though.

/
Leif


* The Pull Request submitter is required to invite the required
   maintainers and reviewers to the pull request. This is the same
   set of maintainers and reviewers that are required to be listed in
   Cc: tags in today's process.


That can be done by github action started automatically after opening 
PR. May require changes to GetMaintainer.py script. Would be good to 
have in case someone forget to add one of maintainers.


Also would be nice to have a bot running PatchCheck and uncrustify on PR.









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

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Leif Lindholm]

On 2024-05-02 02:28, Rebecca Cran wrote:

On Wed, May 1, 2024, at 11:43 AM, Michael D Kinney wrote:

* The Pull Request submitter is required to invite the required
   maintainers and reviewers to the pull request. This is the same
   set of maintainers and reviewers that are required to be listed in
   Cc: tags in today's process.


This seems like something that could rather easily be automated by parsing the 
maintainers file.


Yes, I pushed an example update to GetMaintainer.py here:
https://github.com/leiflindholm/edk2/tree/getmaintainer-forgeusername

But I think the actual option name, and output behaviour, needs to be 
discussed.


/
Leif



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

Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

[Leif Lindholm]

On 2024-05-01 18:43, Michael D Kinney wrote:

Hello,

I would like to propose that TianoCore move all code review from email
based code reviews to GitHub Pull Requests based code reviews.

The proposed date to switch would be immediately after the next stable
tag which is currently scheduled for May 24, 2024.


Thanks Mike.

I'm in favour of this change, and the date.

I still want us to try to figure out how to retain review history beyond 
what github decides we need, but I don't think it justifies indefinitely 
delaying the switchover. And frankly, it will be easier to experiment 
with what works and not after the switch.


/
Leif


Updates to the following Wiki page would be required to describe the
required process when using GitHub Pull Requests for all code review
related activity.

 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

A couple examples of the changes that would need to be documented are:

* All contributors, maintainers, and reviewers must have GitHub IDs.
* The commit message would no longer require Cc:, Reviewed-by:, Acked-by:
   or Tested-by: tags.  The only required tag would be Signed-off-by.
* The Pull Request submitter is required to invite the required
   maintainers and reviewers to the pull request. This is the same
   set of maintainers and reviewers that are required to be listed in
   Cc: tags in today's process.
* Maintainers are responsible for verifying that all conversations in
   the code review are resolved and that all review approvals from the
   required set of maintainers are present before setting the 'push' label.


Please provide feedback
1) If you are not in favor of this change.
2) If you are not in favor of the proposed date of this change.
3) On the process changes you would like to see documented in the Wiki
pages related to using GitHub Pull Request based code reviews.

There is some prototype work to automate/simplify some of the PR based
code review process steps. Those could be added over time as resources
are available to finish and support them.

Best regards,

Mike









-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118469): https://edk2.groups.io/g/devel/message/118469
Mute This Topic: https://groups.io/mt/105847510/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 v2 0/2] SbsaQemu: some cleanups

[Leif Lindholm]

On Wed, Apr 24, 2024 at 13:32:33 +0200, Marcin Juszkiewicz wrote:
> I am working on some changes to SbsaQemu and got some cleanups in
> meantime.
> 
> First patch gets rid of setting Pcds for Timer interrupts. ArmPkg does
> it for us so we do not have to.
> 
> Second changes DSDT nodes so iasl does not complain.
> 
> Marcin Juszkiewicz (2):
>   SbsaQemu: do not set Timer interrupts
>   SbsaQemu: remove some methods from DSDT

For series:
Reviewed-by: Leif Lindholm 

Thanks!

/
Leif

>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc   | 10 --
>  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl | 23 ---
>  2 files changed, 8 insertions(+), 25 deletions(-)
> 
> -- 
> 2.44.0
> 
> 
> 
> 
> 
> 


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

[edk2-devel] [PATCH edk2-non-osi 1/1] Maintainers.txt: add maintainers for SbsaQemu platform

[Leif Lindholm]

Signed-off-by: Leif Lindholm 
---

p.s. Mike, could you add write access for Marcin in this repo as well?
 It was a pure oversight not to ask this at the same time as for
 edk2-platforms.

 Maintainers.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index eaf13fda6af0..2cdff26facaf 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -63,6 +63,11 @@ Platform/Intel/CometlakeSiliconBinPkg
 M: Kathappan Esakkithevar 
 M: Sai Chaganty 
 
+Platform/Qemu/SbsaQemu
+M: Ard Biesheuvel  [ardbiesheuvel]
+M: Leif Lindholm  [leiflindholm]
+M: Marcin Juszkiewicz  [hrw]
+
 Silicon/AMD
 M: Abner Chang 
 M: Abdul Lateef Attar 
-- 
2.30.2



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118144): https://edk2.groups.io/g/devel/message/118144
Mute This Topic: https://groups.io/mt/105690641/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-non-osi 1/1] Qemu/Sbsa: update TF-A binaries for QEMU v9.0+

[Leif Lindholm]

On Tue, Apr 23, 2024 at 12:25:55 +0200, Marcin Juszkiewicz wrote:
> QEMU v9 uses 1GHz frequency for generic timers as required for Arm v8.6+
> cpu cores. TF-A was hardcoding 62.5MHz value which is used for older
> designs. Now it will use value present in CNTFRQ_EL0 register (set by
> QEMU).
> 
> Enable FEAT_ECV for QEMU v9.0+ to get access to CNTPOFF register.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 
Thanks!

Can you push the change yourself?

/
Leif

> ---
>  Platform/Qemu/Sbsa/Readme.md |  55 ++-
>  Platform/Qemu/Sbsa/bl1.bin   | Bin 23365 -> 23349 bytes
>  Platform/Qemu/Sbsa/fip.bin   | Bin 82722 -> 82722 bytes
>  3 files changed, 28 insertions(+), 27 deletions(-)
> 
> diff --git a/Platform/Qemu/Sbsa/Readme.md b/Platform/Qemu/Sbsa/Readme.md
> index 5ed05f0f3021..b1351043d2b4 100644
> --- a/Platform/Qemu/Sbsa/Readme.md
> +++ b/Platform/Qemu/Sbsa/Readme.md
> @@ -4,50 +4,51 @@ Qemu SBSA TF-A binaries
>  These binaries have been created from the mainline TF-A
>  code checked out at the following commit ID:
>  
> -commit f36faa71578a14a8c9910aaa57e761f0256ccd52 (HEAD -> master, 
> origin/master, origin/integration, origin/HEAD)
> -Merge: 8dad296d6 57ab6d897
> -Author: Lauren Wehrmeister 
> -Date:   Tue Mar 12 19:17:49 2024 +0100
> +commit 56b263cb2a25892038761acea8c2b57a638d19bf (HEAD -> integration, 
> origin/integration, gerrit/integration)
> +Merge: 09d3fd141 e769f830d
> +Author: Yann Gautier 
> +Date:   Tue Apr 23 10:42:01 2024 +0200
>  
> -Merge "fix(cpus): fix a defect in Cortex-A715 erratum 2561034" into 
> integration
> +Merge "feat(qemu): allow ARM_ARCH_MAJOR/MINOR override" into integration
>  
>  
>  This ensures that the following features for qemu_sbsa platform are
>  merged upstream and included in the build:
>  
> -commit 42925c15bee09162c6dfc8c2204843ffac6201c1
> +commit 5436047a0e1f32543042d6de9f1f6a3edcd47591
>  Author: Marcin Juszkiewicz 
> -Date:   Tue Nov 21 14:53:26 2023 +0100
> +Date:   Mon Apr 22 17:27:56 2024 +0200
>  
> -feat(qemu-sbsa): handle CPU information
> +refactor(qemu): do not hardcode counter frequency
>  
> -We want to remove use of DeviceTree from EDK2. So we move
> -functions to TF-A:
> +From QEMU change:
>  
> -- counting cpu cores
> -- checking NUMA node id
> -- checking MPIDR
> +> In previous versions of the Arm architecture, the frequency of the
> +> generic timers as reported in CNTFRQ_EL0 could be any IMPDEF value,
> +> and for QEMU we picked 62.5MHz, giving a timer tick period of 16ns.
> +> In Armv8.6, the architecture standardized this frequency to 1GHz.
>  
> -And then it gets passed to EDK2 via SMC calls.
> +This change stops TF-A from hardcoding 62.5MHz frequency. Instead value
> +stored in CNTFRQ_EL0 would be used. As a result we get 62.5MHz on older
> +cores and 1GHz on newer ones.
>  
> -Change-Id: I1c7fc234ba90ba32433b6e4aa2cf127f26da00fd
> +Change-Id: I7d414ce6d3708e598bbb5a6f79eb2d4ec8e15ac4
>  Signed-off-by: Marcin Juszkiewicz 
>  
> -commit 8b7dd8397dd017b61ecda8447e8956a1d9d6d5d3
> -Author: Xiong Yining 
> -Date:   Fri Jan 12 10:47:03 2024 +
> +commit 1b694c77c497cb8272c97417ef1fa4f5f9c869c1
> +Author: Jean-Philippe Brucker 
> +Date:   Mon Apr 15 14:28:11 2024 +0100
>  
> -feat(qemu-sbsa): handle memory information
> +feat(qemu): enable FEAT_ECV when present
>  
> -As a part of removing DeviceTree from EDK2, we move functions to TF-A:
> +QEMU supports FEAT_ECV since commit 2808d3b38a52 ("target/arm: Implement
> +FEAT_ECV CNTPOFF_EL2 handling"), in the v9.0.0 release. Enable
> +auto-detecting the feature on the QEMU platforms, in order to set
> +SCR.ECVEN. Without this, EL2 gets undefined instruction exceptions when
> +trying to access the new CNTPOFF register.
>  
> -- counting the number of memory nodes
> -- checking NUMA node id
> -- checking the memory address
> -
> -Signed-off-by: Xiong Yining 
> -Signed-off-by: Chen Baozi 
> -Change-Id: Ib7bce3a65c817a5b3bef6c9e0a459c7ce76c7e35
> +Change-Id: I555a5f9a9a84fd23e64ca85219ed1599204c6bb2
> +Signed-off-by: Jean-Philippe Brucker 
>  
>  
>  NOTE: No modifications to the source code have been done.
> diff --git a/Platform/Qemu/Sbsa/bl1.bin b/Platform/Qemu/Sbsa/bl1.bin
> index 
> 8eac6204b64be03036c6aabe84618a7c979e78e0..6ad39377a464050dcc714d1316ff8981ad637ded
>  100755
> GIT binary patch
> delta 4429
> zcmZ{n4OCQR8poe^=7KXg&4Jm~vLHTho2gO`Bjw?y!*(?Xe
> zQ=M4#_He@8+5)pe^K?|K zd*0`L-p@Pp!Q1Sux0wk-YkQmGUb_s&Y5m{kY

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

[Leif Lindholm]

Thanks all, update pushed as 8b29c9255d44.

/
Leif

On Wed, Apr 03, 2024 at 14:28:45 +, Narinder Dhillon wrote:
> 
> 
> > -Original Message-
> > From: Marcin Wojtas 
> > Sent: Wednesday, April 3, 2024 6:36 AM
> > To: devel@edk2.groups.io; michael.d.kin...@intel.com
> > Cc: Leif Lindholm ; Narinder Dhillon
> > 
> > Subject: [EXTERNAL] Re: [edk2-devel] [PATCH edk2-platforms 1/1]
> > Maintainers.txt: Update maintainers for Marvell platforms
> > 
> > Prioritize security for external emails: Confirm sender and content safety
> > before clicking links or opening attachments
> > 
> > --
> > wt., 2 kwi 2024 o 17:59 Michael D Kinney 
> > napisał(a):
> > >
> > > Reviewed-by: Michael D Kinney 
> > >
> > > > -Original Message-
> > > > From: Leif Lindholm 
> > > > Sent: Tuesday, April 2, 2024 8:40 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: Marcin Wojtas ; Narinder Dhillon
> > > > ; Kinney, Michael D
> > > > 
> > > > Subject: [PATCH edk2-platforms 1/1] Maintainers.txt: Update
> > > > maintainers for Marvell platforms
> > > >
> > > > Marcin and Narinder are the people most familiar with the Marvell
> > > > platforms, so make them the maintainers.
> > > > I move myself down to Reviewer for now.
> > > >
> > > > Cc: Marcin Wojtas 
> > > > Cc: Narinder Dhillon 
> > > > Cc: Michael D Kinney 
> > > > Signed-off-by: Leif Lindholm 
> > > > ---
> > > >  Maintainers.txt | 5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/Maintainers.txt b/Maintainers.txt index
> > > > ca36aa679470..877620a1b02c 100644
> > > > --- a/Maintainers.txt
> > > > +++ b/Maintainers.txt
> > > > @@ -357,8 +357,9 @@ Marvell platforms and silicon
> > > >  F: Platform/Marvell/
> > > >  F: Platform/SolidRun/
> > > >  F: Silicon/Marvell/
> > > > -R: Marcin Wojtas 
> > > > -M: Leif Lindholm 
> > > > +M: Marcin Wojtas  [wojtas-marcin]
> > > > +M: Narinder Dhillon  [ndhillonm]
> > > > +R: Leif Lindholm  [leiflindholm]
> > > >
> > 
> > Reviewed-by: Marcin Wojtas 
> > 
> > Thanks,
> > Marcin
> > 
> 
> Reviewed-by: Narinder Dhillon 
> 
> Thanks,
> Narinder
> 
> > > >  Miscellaneous drivers
> > > >  F: Silicon/Atmel/
> > > > --
> > > > 2.30.2
> > >
> > >
> > >
> > > 
> > >
> > >


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

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

[Leif Lindholm]

Marcin and Narinder are the people most familiar with the Marvell
platforms, so make them the maintainers.
I move myself down to Reviewer for now.

Cc: Marcin Wojtas 
Cc: Narinder Dhillon 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
 Maintainers.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index ca36aa679470..877620a1b02c 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -357,8 +357,9 @@ Marvell platforms and silicon
 F: Platform/Marvell/
 F: Platform/SolidRun/
 F: Silicon/Marvell/
-R: Marcin Wojtas 
-M: Leif Lindholm 
+M: Marcin Wojtas  [wojtas-marcin]
+M: Narinder Dhillon  [ndhillonm]
+R: Leif Lindholm  [leiflindholm]
 
 Miscellaneous drivers
 F: Silicon/Atmel/
-- 
2.30.2



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

Re: [edk2-devel] [PATCH v4 1/1] SbsaQemu: AcpiDxe: Create SRAT table at runtime

[Leif Lindholm]

On Thu, Mar 28, 2024 at 06:19:35 +, Xiong Yining wrote:
> Add support to create SRAT(System resource affinity table) for
> sbsa platform at runtime.
> 
> Signed-off-by: Xiong Yining 
> Reviewed-by: Marcin Juszkiewicz 
> Reviewed-by: Leif Lindholm 

You are not supposed to add Reviewed-by: or Acked-by: tags unless
whoever is commenting on your code indicates so by posting (for me)
Reviewed-by: Leif Lindholm 

It is not an indicator of work in progress, it is a flag that the
patch has been Reviewed and is ready to merge.

This also means that if Reviewed-by: is given early in the process,
but then you need to do substantial rework, you should *drop* any
previously given Reviewed-by: tags.

Marcin has never given his Reviewed-by for this patch, so I have
dropped this before pushing. Pushed as 7c26299112f3.

Thanks!

/
Leif

> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h | 27 ++
>  .../Include/Library/HardwareInfoLib.h | 10 ++
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 92 +++
>  .../SbsaQemuHardwareInfoLib.c | 36 
>  4 files changed, 165 insertions(+)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> index 7595df4c8a2d..83a085cd86f4 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> @@ -63,4 +63,31 @@ typedef struct {
>  
>  #define GTDT_WDTIMER_FLAGS  (GTDT_WDTIMER_ACTIVE_HIGH | 
> GTDT_WDTIMER_LEVEL_TRIGGERED)
>  
> +#define SBSAQEMU_ACPI_MEMORY_AFFINITY_STRUCTURE_INIT(
>  \
> +  ProximityDomain, Base, Length, Flags)  
>  \
> +  {  
>  \
> +1,  /* Type */   
>  \
> +sizeof (EFI_ACPI_6_4_MEMORY_AFFINITY_STRUCTURE),/* Length */ 
>  \
> +ProximityDomain,/* Proximity Domain 
> */\
> +0,  /* Reserved */   
>  \
> +(Base) & 0x,/* Base Address Low 
> */\
> +((Base) >> 32) & 0x ,   /* Base Address High 
> */   \
> +(Length) & 0x,  /* Length Low */ 
>  \
> +((Length) >> 32) & 0x,  /* Length High */
>  \
> +0,  /* Reserved */   
>  \
> +Flags,  /* Flags */  
>  \
> +0   /* Reserved */   
>  \
> +  }
> +
> +#define SBSAQEMU_ACPI_GICC_AFFINITY_STRUCTURE_INIT(  
>  \
> +  ProximityDomain, ACPIProcessorUID, Flags, ClockDomain) 
>  \
> +  {  
>  \
> +3,  /* Type */   
>  \
> +sizeof (EFI_ACPI_6_4_GICC_AFFINITY_STRUCTURE),  /* Length */ 
>  \
> +ProximityDomain,/* Proximity Domain 
> */\
> +ACPIProcessorUID,   /* ACPI Processor 
> UID */  \
> +Flags,  /* Flags */  
>  \
> +ClockDomain /* Clock Domain */   
>  \
> +  }
> +
>  #endif
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> index 5db0eacc9d2d..46fdad45353c 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> @@ -73,4 +73,14 @@ GetMemInfo (
>OUT MemoryInfo  *MemInfo
>);
>  
> +/**
> +  Get the number of numa node from device tree passed by Qemu.
> +
> +  @retvalthe number of numa node.
> +**/
> +UINT64
> +GetNumaNodeCount (
> +  VOID
> +  );
> +
>  #endif /* HARDWARE_INFO_LIB */
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index 4ebe2a445344..30239e7dca0d 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -6

Re: [edk2-devel] [PATCH v4 1/1] SbsaQemu: add memory space for the high memory nodes

[Leif Lindholm]

On Wed, Mar 27, 2024 at 14:01:43 +, Xiong Yining wrote:
> To support more memory nodes, we refer to the implement of
> "OvmfPkg/Fdt/HighMemDxe" to add memory space for the high memory nodes
> except the first one.

"HighMem" doesn't really make sense outside x86.
But I also don't want to delay merging this any furtner because of
arguing about names.

There are a few stule things below that I will fix up before pushing
though:

> Signed-off-by: Xiong Yining 
> Signed-off-by: Chen Baozi 

Drop additional Signed-off-by, as discussed on other set.

> Tested-by: Marcin Juszkiewicz 
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |   1 +
>  Platform/Qemu/SbsaQemu/SbsaQemu.fdf   |   1 +
>  .../SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf |  45 ++
>  .../SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c   | 134 ++
>  4 files changed, 181 insertions(+)
>  create mode 100644 
> Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
>  create mode 100644 
> Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 3b936f6e6386..22017792bad2 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -671,6 +671,7 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
>ArmPkg/Drivers/TimerDxe/TimerDxe.inf
>OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
> +  Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
>  
>#
># FAT filesystem + GPT/MBR partitioning
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> index 6fcfd25faaeb..b35f42e11aa4 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> @@ -161,6 +161,7 @@ READ_LOCK_STATUS   = TRUE
>  
>INF MdeModulePkg/Core/Dxe/DxeMain.inf
>INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> +  INF Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
>  
>#
># PI DXE Drivers producing Architectural Protocols (EFI Services)
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
> new file mode 100644
> index ..304f47392298
> --- /dev/null
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
> @@ -0,0 +1,45 @@
> +## @file
> +#  High memory node enumeration DXE driver for SbsaQemu
> +#
> +#  Copyright (c) 2023, Linaro Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = SbsaQemuHighMemDxe
> +  FILE_GUID  = 9E749C5E-C282-32F8-7CC3-E5A3DDE15329
> +  MODULE_TYPE= DXE_DRIVER
> +  VERSION_STRING = 1.0
> +
> +  ENTRY_POINT= InitializeHighMemDxe
> +
> +[Sources]
> +  SbsaQemuHighMemDxe.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +  ArmPkg/ArmPkg.dec
> +  Silicon/Qemu/SbsaQemu/SbsaQemu.dec

Sort these alphabetically.

> +
> +[LibraryClasses]
> +  BaseLib
> +  DebugLib
> +  DxeServicesTableLib
> +  PcdLib
> +  UefiBootServicesTableLib
> +  UefiDriverEntryPoint
> +  HardwareInfoLib

Sort these alphabetically.

> +
> +[Protocols]
> +  gEfiCpuArchProtocolGuid ## CONSUMES
> +
> +[Pcd]
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy
> +  gArmTokenSpaceGuid.PcdSystemMemoryBase

Sort these alphabetically.

> +
> +[Depex]
> +  gEfiCpuArchProtocolGuid
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c
> new file mode 100644
> index ..004a8c0cf654
> --- /dev/null
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c
> @@ -0,0 +1,134 @@
> +/** @file
> +*  High memory node enumeration DXE driver for SbsaQemu
> +*  Virtual Machines
> +*
> +*  Copyright (c) 2023, Linaro Ltd. All rights reserved.
> +*
> +*  SPDX-License-Identifier: BSD-2-Clause-Patent
> +*
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +EFI_STATUS
> +EFIAPI
> +InitializeHighMemDxe (
> +  IN EFI_HANDLEImageHandle,
> +  IN EFI_SYSTEM_TABLE  *SystemTable
> +  )
> +{
> +  E

Re: [edk2-devel] [PATCH v11 2/4] Platform/SbsaQemu: use SbsaQemuHardwareInfoLib for cpu information

[Leif Lindholm]

On Thu, Mar 28, 2024 at 07:46:28 +, Xiong Yining wrote:
> From: Marcin Juszkiewicz 
> 
> We have SbsaQemuHardwareInfoLib to ask for hardware details. No need to
> parse DeviceTree anymore.
> 
> Signed-off-by: Marcin Juszkiewicz 
> Signed-off-by: Xiong Yining 
> Reviewed-by: Leif Lindholm 
> ---
>  .../Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf   |  6 ++
>  .../SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf   |  5 ++---
>  .../Library/SbsaQemuLib/SbsaQemuLib.inf   |  4 ++--
>  .../Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c | 11 +-
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 21 +++
>  5 files changed, 18 insertions(+), 29 deletions(-)
> 

Two mistakes in this file breaks bisect again, this time between 2/4
and 3/4.

> diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> index c067a80cc715..07e6bc4e9b11 100644
> --- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> +++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> @@ -1,6 +1,6 @@
>  #/* @file
>  #
> -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2019-2024, Linaro Limited. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -32,9 +32,9 @@
>ArmLib
>BaseMemoryLib
>DebugLib
> -  FdtLib

1) We don't update the memory discovery to use HardwareInfoLib until
the next commit.

>MemoryAllocationLib
>PcdLib
> +  SbsaQemuHardwareInfoLib

2) This is now just called HardwareInfoLib.

I really don't want to see a v12, so I have fixed this up locally and
pushed this set as 8e5981584663..4e77c070c070.

Thanks!

(But please be more careful with bisect breakage in future.)

/
Leif


>  
>  [Pcd]
>gArmTokenSpaceGuid.PcdSystemMemoryBase
> diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
> b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> index c38f2851904f..854f6f4072d5 100644
> --- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> +++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> @@ -2,7 +2,7 @@
>  *  OemMiscLib.c
>  *
>  *  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +*  Copyright (c) 2020-2024, Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -12,14 +12,13 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> -#include 
>  
>  /** Returns whether the specified processor is present or not.
>  
> @@ -33,7 +32,7 @@ OemIsProcessorPresent (
>UINTN ProcessorIndex
>)
>  {
> -  if (ProcessorIndex < FdtHelperCountCpus ()) {
> +  if (ProcessorIndex < GetCpuCount ()) {
>  return TRUE;
>}
>  
> @@ -76,7 +75,7 @@ OemGetProcessorInformation (
>  {
>UINT16 ProcessorCount;
>  
> -  ProcessorCount = FdtHelperCountCpus ();
> +  ProcessorCount = GetCpuCount ();
>  
>if (ProcessorIndex < ProcessorCount) {
>  ProcessorStatus->Bits.CpuStatus   = 1; // CPU enabled
> @@ -121,7 +120,7 @@ OemGetMaxProcessors (
>VOID
>)
>  {
> -  return FdtHelperCountCpus ();
> +  return GetCpuCount ();
>  }
>  
>  /** Gets information about the cache at the specified cache level.
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index 9fb17151d7b8..4ebe2a445344 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -1,7 +1,7 @@
>  /** @file
>  *  This file is an ACPI driver for the Qemu SBSA platform.
>  *
> -*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +*  Copyright (c) 2020-2024, Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -15,10 +15,10 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -255,8 +255,7 @@ AddMadtTable (
>   // Initialize GIC Redistributor Structure
>EFI_ACPI_6_0_GICR_STRUCTURE Gicr = SBSAQEMU_MADT_GICR_INIT();
>  
> -  // Get CoreCount which was determined eariler after parsing device tree
> -  NumCores = PcdGet32 (PcdCoreCount);
> +  NumCores = GetCpuCount ();
>  
>// Calculate the new table size based on the number of cores
>TableSize = sizeof (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER) +
> @@ -

Re: [edk2-devel] [PATCH v10 4/4] Platform/SbsaQemu: get the information of memory via SMC calls

[Leif Lindholm]

I think the patch ordering relative to 3/4 breaks bisect?

/
Leif

On Wed, Mar 27, 2024 at 14:03:05 +, Xiong Yining wrote:
> Provide functions to check for memory information:
> 
> - amount of memory nodes
> - memory address
> - NUMA node id for memory
> 
> Values are read from TF-A using platform specific SMC calls.
> 
> Signed-off-by: Xiong Yining 
> Signed-off-by: Chen Baozi 
> Signed-off-by: Marcin Juszkiewicz 
> Reviewed-by: Ard Biesheuvel 
> ---
>  .../Library/SbsaQemuLib/SbsaQemuLib.inf   |  3 +-
>  .../Include/IndustryStandard/SbsaQemuSmc.h|  2 +
>  .../Include/Library/HardwareInfoLib.h | 31 +++
>  .../SbsaQemuHardwareInfoLib.c | 49 +
>  .../Library/SbsaQemuLib/SbsaQemuMem.c | 54 +--
>  5 files changed, 96 insertions(+), 43 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> index 07e6bc4e9b11..384cbb349200 100644
> --- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> +++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> @@ -32,14 +32,13 @@
>ArmLib
>BaseMemoryLib
>DebugLib
> +  HardwareInfoLib
>MemoryAllocationLib
>PcdLib
> -  SbsaQemuHardwareInfoLib
>  
>  [Pcd]
>gArmTokenSpaceGuid.PcdSystemMemoryBase
>gArmTokenSpaceGuid.PcdSystemMemorySize
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
>  
>  [FixedPcd]
>gArmTokenSpaceGuid.PcdFdBaseAddress
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index 2317c1f0ae69..e3092007d27d 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -16,6 +16,8 @@
>  #define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
>  #define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
>  #define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
> +#define SIP_SVC_GET_MEMORY_NODE_COUNT SMC_SIP_FUNCTION_ID(300)
> +#define SIP_SVC_GET_MEMORY_NODE SMC_SIP_FUNCTION_ID(301)
>  
>  /*
>   *  SMCC does not define return codes for SiP functions.
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> index 8b1b5e5e1b93..5db0eacc9d2d 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> @@ -9,6 +9,12 @@
>  #ifndef HARDWARE_INFO_LIB
>  #define HARDWARE_INFO_LIB
>  
> +typedef struct{
> +  UINT32  NodeId;
> +  UINT64  AddressBase;
> +  UINT64  AddressSize;
> +} MemoryInfo;
> +
>  /**
>Get CPU count from information passed by Qemu.
>  
> @@ -42,4 +48,29 @@ GetCpuNumaNode (
>IN UINTN  CpuId
>);
>  
> +/**
> +  Get the number of memory node from device tree passed by Qemu.
> +
> +  @retval   the number of memory nodes.
> +**/
> +UINT32
> +GetMemNodeCount (
> +  VOID
> +  );
> +
> +/**
> +  Get memory information(node-id, addressbase, addresssize) for a given 
> memory node from device tree passed by Qemu.
> +
> +  @param [in]   MemoryIdIndex of memory to retrieve memory information.
> +  @param [out]  MemInfo A pointer to the memory information of given 
> memory-id.
> +
> +
> +  @retval   memory infomation for given memory node.
> +**/
> +VOID
> +GetMemInfo (
> +  IN  UINTN   MemoryId,
> +  OUT MemoryInfo  *MemInfo
> +  );
> +
>  #endif /* HARDWARE_INFO_LIB */
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> index e96328978a55..b178cf6c6c43 100644
> --- 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> @@ -94,3 +94,52 @@ GetCpuNumaNode (
>  
>return Arg0;
>  }
> +
> +UINT32
> +GetMemNodeCount (
> +  VOID
> +  )
> +{
> +  UINTNSmcResult;
> +  UINTNArg0;
> +
> +  SmcResult = ArmCallSmc0 (SIP_SVC_GET_MEMORY_NODE_COUNT, &Arg0, NULL, NULL);
> +  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
> +DEBUG ((DEBUG_ERROR, "%a: SIP_SVC_GET_MEMORY_NODE_COUNT call failed. We 
> have no memory information.\n", __FUNCTION__));
> +ResetShutdown ();
> +  }
> +
> +  DEBUG (( DEBUG_INFO, "%a: The number of the memory nodes is %ld\n", 
> __FUNCTION__, Arg0));
> +  return (UINT32)Arg0;
> +}
> +
> +VOID
> +GetMemInfo (
> +  IN  UINTN   MemoryId,
> +  OUT MemoryInfo  *MemInfo 
> +  )
> +{
> +  UINTN   SmcResult;
> +  UINTN   Arg0;
> +  UINTN   Arg1;
> +  UINTN   Arg2;
> +
> +  Arg0 = MemoryId;
> +
> +  SmcResult = ArmCallSmc1 (SIP_SVC_GET_MEMORY_NODE, &Arg0, &Arg1, &Arg2);
> +  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
> +DE

Re: [edk2-devel] [PATCH v10 1/4] Platform/SbsaQemu: add SbsaQemuHardwareInfoLib

[Leif Lindholm]

On Wed, Mar 27, 2024 at 14:03:02 +, Xiong Yining wrote:
> From: Marcin Juszkiewicz 
> 
> This library provides functions to check for hardware information.
> For now it covers CPU ones:
> 
> - amount of cpu cores
> - MPIDR value for cpu core
> - NUMA node id for cpu core
> 
> Values are read from TF-A using platform specific SMC calls.
> 
> Signed-off-by: Marcin Juszkiewicz 

This is fine, because you're re-submitting a patch already sent out
for review by Marcin. There is public record that he made this
statement.
But when resubmitting patches, you should also add your own
signed-off-by, to indicate that you, to the best of your
knowledge, complies with the statements in
https://github.com/tianocore/edk2?tab=readme-ov-file#developer-certificate-of-origin

/
Leif

> ---
>  Silicon/Qemu/SbsaQemu/SbsaQemu.dec|  2 +
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |  3 +-
>  .../SbsaQemuHardwareInfoLib.inf   | 29 ++
>  .../Include/IndustryStandard/SbsaQemuSmc.h| 17 +++-
>  .../Include/Library/HardwareInfoLib.h | 45 +
>  .../SbsaQemuHardwareInfoLib.c | 96 +++
>  6 files changed, 187 insertions(+), 5 deletions(-)
>  create mode 100644 
> Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  create mode 100644 Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
>  create mode 100644 
> Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> 
> diff --git a/Silicon/Qemu/SbsaQemu/SbsaQemu.dec 
> b/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> index 913d1d75ef29..427ff8b31aac 100644
> --- a/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> +++ b/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> @@ -12,6 +12,8 @@
>PACKAGE_GUID   = 8db32c5a-2821-43e2-b4ac-bc148e2b0b05
>PACKAGE_VERSION= 0.1
>  
> +[LibraryClasses]
> +HardwareInfoLib|Include/Library/HardwareInfoLib.h
>  
> 
>  #
>  # Include Section - list of Include Paths that are provided by this package.
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 378600050df9..3c3d2449bff4 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -1,6 +1,6 @@
>  #
>  #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2019-2024, Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -128,6 +128,7 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
>  
>FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
>OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> +  
> HardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
># Debug Support
>
> PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> new file mode 100644
> index ..2acb2a1e7c76
> --- /dev/null
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> @@ -0,0 +1,29 @@
> +#/* @file
> +#
> +#  Copyright (c) 2024, Linaro Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +#*/
> +
> +[Defines]
> +  INF_VERSION= 0x0001001c
> +  BASE_NAME  = SbsaQemuHardwareInfoLib
> +  FILE_GUID  = 6454006f-6502-46e2-9be4-4bba8d4b29fb
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = HardwareInfoLib
> +
> +[Sources]
> +  SbsaQemuHardwareInfoLib.c
> +
> +[Packages]
> +  ArmPkg/ArmPkg.dec
> +  EmbeddedPkg/EmbeddedPkg.dec
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> +
> +[LibraryClasses]
> +  ArmSmcLib
> +  ResetSystemLib
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index 7934875e4aba..2317c1f0ae69 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -1,6 +1,6 @@
>  /** @file
>  *
> -*  Copyright (c) 2023, Linaro Ltd. All rights reserved.
> +*  Copyright (c) 2023-2024, Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -11,8 +11,17 @@
>  
>  #include 
>  
> -#define SIP_SVC_VERSION  SMC_SIP_FUNCTION_ID(1)
> -#define SIP_SVC_GET_GIC  SMC_SIP_FUNCTION_ID(100)
> -#define SIP_SVC_GET_GIC_ITS  SMC_SIP_FUNCTION_ID(101)
> +#define SIP_SVC_VERSIONSMC_SIP_FUNCTION_ID(1)
> +#def

Re: [edk2-devel] [PATCH v3 1/1] SbsaQemu: AcpiDxe: Create SRAT table at runtime

[Leif Lindholm]

On Wed, Mar 27, 2024 at 13:59:34 +, Xiong Yining wrote:
> Add support to create SRAT(System resource affinity table) for
> sbsa platform at runtime.
> 
> Signed-off-by: Xiong Yining 
> Signed-off-by: Chen Baozi 

No one can sign off patches on behalf of someone else. Please only
include your own signed-off-by.

> Reviewed-by: Marcin Juszkiewicz 
> Change-Id: I4a65084e6ade66d87ea935adfa4be15a7030d3eb

We don't use gerrit. Please drop Change-Id:s before upstreaming.

> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h | 27 ++
>  .../Include/Library/HardwareInfoLib.h | 10 ++
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 92 +++
>  .../SbsaQemuHardwareInfoLib.c | 36 
>  4 files changed, 165 insertions(+)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> index 7595df4c8a2d..83a085cd86f4 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> @@ -63,4 +63,31 @@ typedef struct {
>  
>  #define GTDT_WDTIMER_FLAGS  (GTDT_WDTIMER_ACTIVE_HIGH | 
> GTDT_WDTIMER_LEVEL_TRIGGERED)
>  
> +#define SBSAQEMU_ACPI_MEMORY_AFFINITY_STRUCTURE_INIT(
>  \
> +  ProximityDomain, Base, Length, Flags)  
>  \
> +  {  
>  \
> +1,  /* Type */   
>  \
> +sizeof (EFI_ACPI_6_4_MEMORY_AFFINITY_STRUCTURE),/* Length */ 
>  \
> +ProximityDomain,/* Proximity Domain 
> */\
> +0,  /* Reserved */   
>  \
> +(Base) & 0x,/* Base Address Low 
> */\
> +((Base) >> 32) & 0x ,   /* Base Address High 
> */   \
> +(Length) & 0x,  /* Length Low */ 
>  \
> +((Length) >> 32) & 0x,  /* Length High */
>  \
> +0,  /* Reserved */   
>  \
> +Flags,  /* Flags */  
>  \
> +0   /* Reserved */   
>  \
> +  }
> +
> +#define SBSAQEMU_ACPI_GICC_AFFINITY_STRUCTURE_INIT(  
>  \
> +  ProximityDomain, ACPIProcessorUID, Flags, ClockDomain) 
>  \
> +  {  
>  \
> +3,  /* Type */   
>  \
> +sizeof (EFI_ACPI_6_4_GICC_AFFINITY_STRUCTURE),  /* Length */ 
>  \
> +ProximityDomain,/* Proximity Domain 
> */\
> +ACPIProcessorUID,   /* ACPI Processor 
> UID */  \
> +Flags,  /* Flags */  
>  \
> +ClockDomain /* Clock Domain */   
>  \
> +  }
> +
>  #endif
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> index 5db0eacc9d2d..46fdad45353c 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> @@ -73,4 +73,14 @@ GetMemInfo (
>OUT MemoryInfo  *MemInfo
>);
>  
> +/**
> +  Get the number of numa node from device tree passed by Qemu.
> +
> +  @retvalthe number of numa node.
> +**/
> +UINT64
> +GetNumaNodeCount (
> +  VOID
> +  );
> +
>  #endif /* HARDWARE_INFO_LIB */
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index 4ebe2a445344..30239e7dca0d 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -682,6 +682,91 @@ AddGtdtTable (
>return Status;
>  }
>  
> +/*
> + * A function that adds the SRAT ACPI table.
> + */
> +EFI_STATUS
> +AddSratTable (
> +  IN EFI_ACPI_TABLE_PROTOCOL   *AcpiTable
> +  )
> +{
> +  EFI_STATUSStatus;
> +  UINT8 *New;
> +  EFI_PHYSICAL_ADDRESS  PageAddress;
> +  UINTN TableHandle;
> +  UINT32TableSize;
> +  UINT32Index;
> +  UINT32NodeId;
> +  UINT32NumMemNodes;
> +  MemoryInfoMemInfo;
> +  UINT32NumCores = GetCpuCount ();
> +
> +  // Initialize SRAT ACPI Header
> +  EFI_ACPI_6_4_SYSTEM_RESOURCE_AFFINITY_TABLE_HEADER Header

Re: [edk2-devel] [PATCH edk2-platforms v2 1/1] Maintainers.txt: add myself as QemuSbsa maintainer

[Leif Lindholm]

On Tue, Mar 26, 2024 at 13:10:58 +0100, Marcin Juszkiewicz wrote:
> With all changes going around sbsa-ref/QemuSbsa platform Leif suggested
> that I should become maintainer as well.
> 
> My GitHub account name is "hrw".
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 
Tweaked subject line and pushed as 8e5981584663.

Thanks!

> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index e57c32f16a05..ca36aa679470 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -383,8 +383,8 @@ F: Platform/Qemu/SbsaQemu/
>  F: Silicon/Qemu/SbsaQemu/
>  M: Ard Biesheuvel 
>  M: Leif Lindholm 
> +M: Marcin Juszkiewicz  [hrw]
>  R: Graeme Gregory 
> -R: Marcin Juszkiewicz 
>  
>  Raspberry Pi platforms and silicon
>  F: Platform/RaspberryPi/
> -- 
> 2.44.0
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117116): https://edk2.groups.io/g/devel/message/117116
Mute This Topic: https://groups.io/mt/105156582/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] Maintainers.txt: add myself as QemuSbsa maintainer

[Leif Lindholm]

On Tue, Mar 26, 2024 at 12:24:10 +0100, Marcin Juszkiewicz wrote:
> With all changes going around sbsa-ref/QemuSbsa platform Leif suggested
> that I should become maintainer as well.
> 
> My GitHub account name is "hrw".
> 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index e57c32f16a05..a37fc9e60723 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -383,8 +383,8 @@ F: Platform/Qemu/SbsaQemu/
>  F: Silicon/Qemu/SbsaQemu/
>  M: Ard Biesheuvel 
>  M: Leif Lindholm 
> +M: Marcin Juszkiewicz 

Ah - could you add your github username in [] after the email?
I see now we haven't added that to other maintainers in this file, but
we need to info to give you the access privileges.

/
Leif

>  R: Graeme Gregory 
> -R: Marcin Juszkiewicz 
>  
>  Raspberry Pi platforms and silicon
>  F: Platform/RaspberryPi/
> -- 
> 2.44.0
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117108): https://edk2.groups.io/g/devel/message/117108
Mute This Topic: https://groups.io/mt/105155999/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 v9 4/4] Platform/SbsaQemu: get the information of memory via SMC calls

[Leif Lindholm]

On Fri, Mar 22, 2024 at 17:08:50 +0100, Marcin Juszkiewicz wrote:
> From: Xiong Yining 
> 
> Provide functions to check for memory information:
> 
> - amount of memory nodes
> - memory address
> - NUMA node id for memory
> 
> Values are read from TF-A using platform specific SMC calls.

Same namespace comments as on 1/4, but given I've dragged my heels
reviewing, I see no need to delay further for that. Current naming can
go in, and we can worry about appropriate naming if we promote this
the hwinfo library to a core interface later.

You did however say this one needs reworking, so won't give r-b on
this one yet.

/
Leif

> Signed-off-by: Xiong Yining 
> Signed-off-by: Chen Baozi 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  .../SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf |  3 +-
>  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  |  2 +
>  .../Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h  | 28 ++
>  .../SbsaQemuHardwareInfoLib.c| 50 ++
>  .../Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c  | 54 
> +---
>  5 files changed, 94 insertions(+), 43 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> index 07e6bc4e9b11..384cbb349200 100644
> --- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> +++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> @@ -32,14 +32,13 @@ [LibraryClasses]
>ArmLib
>BaseMemoryLib
>DebugLib
> +  HardwareInfoLib
>MemoryAllocationLib
>PcdLib
> -  SbsaQemuHardwareInfoLib
>  
>  [Pcd]
>gArmTokenSpaceGuid.PcdSystemMemoryBase
>gArmTokenSpaceGuid.PcdSystemMemorySize
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
>  
>  [FixedPcd]
>gArmTokenSpaceGuid.PcdFdBaseAddress
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index 2317c1f0ae69..e3092007d27d 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -16,6 +16,8 @@
>  #define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
>  #define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
>  #define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
> +#define SIP_SVC_GET_MEMORY_NODE_COUNT SMC_SIP_FUNCTION_ID(300)
> +#define SIP_SVC_GET_MEMORY_NODE SMC_SIP_FUNCTION_ID(301)
>  
>  /*
>   *  SMCC does not define return codes for SiP functions.
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> index 9c7281f123d2..c7d397c590a8 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> @@ -9,6 +9,12 @@
>  #ifndef HARDWARE_INFO_LIB
>  #define HARDWARE_INFO_LIB
>  
> +typedef struct{
> +  UINT32  NodeId;
> +  UINT64  AddressBase;
> +  UINT64  AddressSize;
> +} MemoryInfo;
> +
>  /**
>Get CPU count from information passed by Qemu.
>  
> @@ -42,4 +48,26 @@ GetCpuNumaNode (
>IN UINTN  CpuId
>);
>  
> +/**
> +  Get the number of memory node from device tree passed by Qemu.
> +
> +  @retval   the number of memory nodes.
> +**/
> +UINT32
> +GetMemNodeCount (
> +  VOID
> +  );
> +
> +/**
> +  Get memory infomation(node-id, addressbase, addresssize) for a given 
> memory node from device tree passed by Qemu.
> +
> +  @param [in]   MemoryIdIndex of memory to retrieve memory information.
> +
> +  @retval   memory infomation for given memory node.
> +**/
> +MemoryInfo
> +GetMemInfo (
> +  IN UINTN   MemoryId
> +  );
> +
>  #endif /* HARDWARE_INFO_LIB */
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> index e96328978a55..4f49ae7e1862 100644
> --- 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> @@ -94,3 +94,53 @@ GetCpuNumaNode (
>  
>return Arg0;
>  }
> +
> +UINT32
> +GetMemNodeCount (
> +  VOID
> +  )
> +{
> +  UINTNSmcResult;
> +  UINTNArg0;
> +
> +  SmcResult = ArmCallSmc0 (SIP_SVC_GET_MEMORY_NODE_COUNT, &Arg0, NULL, NULL);
> +  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
> +DEBUG ((DEBUG_ERROR, "%a: SIP_SVC_GET_MEMORY_NODE_COUNT call failed. We 
> have no memory information.\n", __FUNCTION__));
> +ResetShutdown ();
> +  }
> +
> +  DEBUG (( DEBUG_INFO, "%a: The number of the memory nodes is %ld\n", 
> __FUNCTION__, Arg0));
> +  return (UINT32)Arg0;
> +}
> +
> +MemoryInfo
> +GetMemInfo (
> +  IN UINTN   MemoryId
> +  )
> +{
> +  UINTN   SmcResult;
> +  UINTN   Arg0;
> +  UINTN   Arg1;
> +  UINTN