Re: [edk2-devel] [RFC] [staging/CryptoLibrary] Openssl1.1 replacement proposal
Hi All I have created staging branch - https://github.com/tianocore/edk2-staging/tree/OpenSSL11_EOL based upon latest trunk today. Let's use this branch to collaborate the work on openssl 1.1 deprecation and continue improving, before we can merge back to trunk. The process is defined at https://github.com/tianocore/edk2-staging/. Feature missing or size increasing won't be a blocking issue for this staging branch. Any feedback is welcome. Hi Gerd If you don't mind, please submit your latest openssl-3.0 patch to the staging for broader evaluation and improvement. Thank you Yao, Jiewen > -Original Message- > From: devel@edk2.groups.io On Behalf Of Yao, Jiewen > Sent: Thursday, February 9, 2023 11:21 AM > To: devel@edk2.groups.io; kra...@redhat.com > Subject: Re: [edk2-devel] [RFC] [staging/CryptoLibrary] Openssl1.1 replacement > proposal > > If you are asking how to do that best *at this moment*, I suggest we create a > branch in https://github.com/tianocore/edk2-staging and continue the research > work. Before September 2023, we need community's help to resolve openssl-3 > size issue, before check in. > > If you are asking how to do that best after September 2023, we have no choice > but put to edk2 main branch. We have to remove openssl-11. > > If we have either openssl-30 and mbedtls work (size/feature), we can replace > openssl-11 with either openssl-30 or mbedtls. > > Worst case, if we have to support dual-crypto module, I think to: > 1) replace openssl-11 with openssl-30 directly. > 2) add mbedtls as another cryptolib instance. > > Thank you > Yao, Jiewen > > > -Original Message- > > From: devel@edk2.groups.io On Behalf Of Gerd > > Hoffmann > > Sent: Wednesday, February 8, 2023 7:45 PM > > To: devel@edk2.groups.io; Yao, Jiewen > > Subject: Re: [edk2-devel] [RFC] [staging/CryptoLibrary] Openssl1.1 > replacement > > proposal > > > > Hi, > > > > > 3. If 1 or 2 can success, we can replace openssl 1.1 with one crypto lib. > > > If both 1 and 2 fail, we may use *dual-crypto module*. For example: > > > mbedtls > > for PEI and openssl3.0 for DXE. > > > The source code size will become larger, more time to download the tree. > > > > Suggestions how to do that best, ideally without duplicating CryptoPkg > > for that? > > > > A while back I've tried to add openssl-3 in parallel to openssl-11, > > with the idea to allow projects picking the one or the other, and quicky > > ran into problems because apparently libraries can't add include > > directories. Only packages can do that (see Includes.Common.Private in > > CryptoPkg/CryptoPkg.dec which adds Library/OpensslLib/openssl/include). > > > > take care, > > Gerd > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100040): https://edk2.groups.io/g/devel/message/100040 Mute This Topic: https://groups.io/mt/96741156/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 00/11] ArmPkg: implement EFI memory attributes protocol
Hey Ard, Once the Memory Attribute Protocol is made available, Windows will have some expectations about its functionality. Can you run this test app created by me and Jiewen to ensure it meets the Windows requirements? Part of the test needed an AARCH64 implementation which I just added - let me know if it doesn't work. Thanks :) https://github.com/TaylorBeebe/mu_basecore/tree/update_map_test_app/MdePkg/Test/ShellTest/MemoryAttributeProtocolFuncTestApp On 2/9/2023 5:59 AM, Ard Biesheuvel wrote: v4: - major cleanup of the 32-bit ARM code - add support for EFI_MEMORY_RP using the access flag - enable stack guard in ArmVirtPkg (which uses EFI_MEMORY_RP) - incorporate optimization from other series [0] to avoid splitting block entries unnecessarily v3: - fix ARM32 bug in attribute conversion - add Liming's ack to patch #1 - include draft patch (NOT FOR MERGE) used to test the changes v2: - drop patch to bump exposed UEFI revision to v2.10 - add missing permitted return values to protocol definition [0] https://edk2.groups.io/g/devel/message/99801 Cc: Michael Kinney Cc: Liming Gao Cc: Jiewen Yao Cc: Michael Kubacki Cc: Sean Brogan Cc: Rebecca Cran Cc: Leif Lindholm Cc: Sami Mujawar Cc: Taylor Beebe Ard Biesheuvel (11): ArmPkg/ArmMmuLib ARM: Remove half baked large page support ArmPkg/ArmMmuLib ARM: Split off XN page descriptor bit from type field ArmPkg/CpuDxe ARM: Fix page-to-section attribute conversion ArmPkg/ArmMmuLib ARM: Isolate the access flag from AP mask ArmPkg/ArmMmuLib ARM: Clear individual permission bits ArmPkg/ArmMmuLib: Implement EFI_MEMORY_RP using access flag ArmVirtPkg: Enable stack guard ArmPkg/ArmMmuLib: Avoid splitting block entries if possible ArmPkg/CpuDxe: Expose unified region-to-EFI attribute conversion MdePkg: Add Memory Attribute Protocol definition ArmPkg/CpuDxe: Implement EFI memory attributes protocol ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c | 25 +- ArmPkg/Drivers/CpuDxe/Arm/Mmu.c | 96 +-- ArmPkg/Drivers/CpuDxe/CpuDxe.c | 2 + ArmPkg/Drivers/CpuDxe/CpuDxe.h | 17 ++ ArmPkg/Drivers/CpuDxe/CpuDxe.inf | 2 + ArmPkg/Drivers/CpuDxe/MemoryAttribute.c | 271 ArmPkg/Include/Chipset/ArmV7Mmu.h| 88 +++ ArmPkg/Include/Library/ArmMmuLib.h | 34 +++ ArmPkg/Library/ArmLib/Arm/ArmV7Support.S | 2 + ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 68 - ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibConvert.c | 8 +- ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibCore.c | 2 +- ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibUpdate.c | 173 +++-- ArmVirtPkg/ArmVirt.dsc.inc | 2 + MdePkg/Include/Protocol/MemoryAttribute.h| 142 ++ MdePkg/MdePkg.dec| 3 + 16 files changed, 833 insertions(+), 102 deletions(-) create mode 100644 ArmPkg/Drivers/CpuDxe/MemoryAttribute.c create mode 100644 MdePkg/Include/Protocol/MemoryAttribute.h -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100039): https://edk2.groups.io/g/devel/message/100039 Mute This Topic: https://groups.io/mt/96853149/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH] RedfishPkg/RedfishConfigHandler: fix FreePool issue
gRedfishDiscoveredToken buffer is allocated as one piece
during protocol installed process, but deleted by parts
during driver unload process.
Cc: Abner Chang
Cc: Nickle Wang
Cc: Igor Kulchytskyy
Signed-off-by: Igor Kulchytskyy
---
RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.c
b/RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.c
index 96ac70f418..64b7fb7841 100644
--- a/RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.c
+++ b/RedfishPkg/RedfishConfigHandler/RedfishConfigHandlerDriver.c
@@ -481,6 +481,7 @@ RedfishDiscoverProtocolInstalled (
ErrorReturn:
if (gRedfishDiscoveredToken != NULL) {
FreePool (gRedfishDiscoveredToken);
+gRedfishDiscoveredToken = NULL;
}
}
@@ -511,10 +512,10 @@ RedfishConfigHandlerDriverUnload (
gBS->CloseEvent (ThisRedfishDiscoveredToken->Event);
}
- FreePool (ThisRedfishDiscoveredToken);
ThisRedfishDiscoveredToken++;
}
+FreePool (gRedfishDiscoveredToken);
gRedfishDiscoveredToken = NULL;
}
--
2.37.1.windows.1
-The information contained in this message may be confidential and proprietary
to American Megatrends (AMI). This communication is intended to be read only by
the individual or entity to whom it is addressed or by their designee. If the
reader of this message is not the intended recipient, you are on notice that
any distribution of this message, in any form, is strictly prohibited. Please
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and
then delete or destroy all copies of the transmission.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#100038): https://edk2.groups.io/g/devel/message/100038
Mute This Topic: https://groups.io/mt/96886534/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] MdeModulePkg/EsrtFmpDxe: Support multiple devices with 0 HardwareInstance
This is unclear in my opinion. The spec does have This number must be unique within the namespace of the ImageTypeId GUID and ImageIndex. And For implementations that will never have more than one instance a zero can be used. But it also states the parameter is optional and states that zero can be used when if it is not able to determine a unique hardware instance number or a hardware instance number is not needed. I could see reasonable arguments on both sides. -Jeff > -Original Message- > From: Kinney, Michael D > Sent: Friday, February 10, 2023 2:17 PM > To: devel@edk2.groups.io; Jeff Brasen ; Demeter, > Miki > Cc: Kinney, Michael D > Subject: RE: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support > multiple devices with 0 HardwareInstance > > External email: Use caution opening links or attachments > > > Based on UEFI Spec, would you consider those option roms to be non- > conformant? > > Mike > > > -Original Message- > > From: devel@edk2.groups.io On Behalf Of Jeff > > Brasen via groups.io > > Sent: Friday, February 10, 2023 12:43 PM > > To: Kinney, Michael D ; > > devel@edk2.groups.io; Demeter, Miki > > Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: > Support > > multiple devices with 0 HardwareInstance > > > > It was not as we were seeing devices expose FMP via an option rom > > driver with Version == 3 and HardwareInstance = 0. If there are multiple of > these device it would hit the error in the EsrtCode. The patch included does > resolve the issues we were seeing. > > > > -Jeff > > > > > > > -Original Message- > > > From: Kinney, Michael D > > > Sent: Friday, February 10, 2023 12:48 PM > > > To: devel@edk2.groups.io; Jeff Brasen ; Demeter, > > > Miki > > > Cc: Kinney, Michael D > > > Subject: RE: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: > > > Support multiple devices with 0 HardwareInstance > > > > > > External email: Use caution opening links or attachments > > > > > > > > > Did your original approach work for all your use cases? > > > > > > Mike > > > > > > > -Original Message- > > > > From: devel@edk2.groups.io On Behalf Of > > > > Jeff Brasen via groups.io > > > > Sent: Friday, February 10, 2023 8:45 AM > > > > To: Kinney, Michael D ; > > > > devel@edk2.groups.io; Demeter, Miki > > > > Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: > > > Support > > > > multiple devices with 0 HardwareInstance > > > > > > > > That was my original approach when I saw this but I was seeing > > > > this occur on a device with FmpVersion == 3. The UEFI spec isn't > > > > completely > > > clear but could be read that 0 is legal if this part isn't being used. > > > > > > > > > > > > https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.ht > > > m > > > l > > > > #efi-firmware-management-protocol-getimageinfo > > > > > > > > It does state that this is Optional, and has a statement "A zero > > > > means the FMP provider is not able to determine a unique hardware > > > > instance > > > number or a hardware instance number is not needed." > > > > > > > > Also, our ESRT implementation just merges all instances to one > > > > anyways so it doesn't currently consume the hardware instance > > > > except for this > > > check. > > > > > > > > Thanks, > > > > Jeff > > > > > > > > > -Original Message- > > > > > From: Kinney, Michael D > > > > > Sent: Thursday, February 9, 2023 8:43 PM > > > > > To: devel@edk2.groups.io; Jeff Brasen ; > > > > > Demeter, Miki > > > > > Cc: Kinney, Michael D > > > > > Subject: RE: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support > > > > > multiple devices with 0 HardwareInstance > > > > > > > > > > External email: Use caution opening links or attachments > > > > > > > > > > > > > > > Hi Jeff, > > > > > > > > > > Thank you for the reminder. > > > > > > > > > > I am wondering if the check should be for FmpVersion < 3 and not > > > > > FmpHardwareInstance != 0. > > > > > > > > > > It is possible for an FmpInfoBuffer to have an FmpVersion >= 3 > > > > > and a HardwareInstance of 0. If more than one of these it > > > > > found, then that would be an EFI_UNSUPPORTED condition. > > > > > > > > > > If FmpVersion >= 3, then the HardwareInstance must be filled in > > > > > with a unique value. 0 can be used if there is at most 1 > > > > > instance, so the duplicate check would never be triggered. If > > > > > FmpVersion >= 3 and there can be more then one instance, then > > > > > the HardwareInstance must be a non-zero unique value. > > > > > > > > > > Thanks, > > > > > > > > > > Mike > > > > > > > > > > > -Original Message- > > > > > > From: devel@edk2.groups.io On Behalf Of > > > > > > Jeff Brasen via groups.io > > > > > > Sent: Thursday, February 9, 2023 2:03 PM > > > > > > To: Demeter, Miki > > > > > > Cc: devel@edk2.groups.io > > > > > > Subject: [edk2-devel] FW: [PATCH v2] > MdeModulePkg/EsrtFmpDxe: > > > > > Support > > > > > > multiple devices with 0 HardwareInstance > >
Re: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple devices with 0 HardwareInstance
Based on UEFI Spec, would you consider those option roms to be non-conformant? Mike > -Original Message- > From: devel@edk2.groups.io On Behalf Of Jeff Brasen > via groups.io > Sent: Friday, February 10, 2023 12:43 PM > To: Kinney, Michael D ; devel@edk2.groups.io; > Demeter, Miki > Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support > multiple devices with 0 HardwareInstance > > It was not as we were seeing devices expose FMP via an option rom driver with > Version == 3 and HardwareInstance = 0. If there > are multiple of these device it would hit the error in the EsrtCode. The > patch included does resolve the issues we were seeing. > > -Jeff > > > > -Original Message- > > From: Kinney, Michael D > > Sent: Friday, February 10, 2023 12:48 PM > > To: devel@edk2.groups.io; Jeff Brasen ; Demeter, > > Miki > > Cc: Kinney, Michael D > > Subject: RE: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support > > multiple devices with 0 HardwareInstance > > > > External email: Use caution opening links or attachments > > > > > > Did your original approach work for all your use cases? > > > > Mike > > > > > -Original Message- > > > From: devel@edk2.groups.io On Behalf Of Jeff > > > Brasen via groups.io > > > Sent: Friday, February 10, 2023 8:45 AM > > > To: Kinney, Michael D ; > > > devel@edk2.groups.io; Demeter, Miki > > > Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: > > Support > > > multiple devices with 0 HardwareInstance > > > > > > That was my original approach when I saw this but I was seeing this > > > occur on a device with FmpVersion == 3. The UEFI spec isn't completely > > clear but could be read that 0 is legal if this part isn't being used. > > > > > > > > https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.htm > > l > > > #efi-firmware-management-protocol-getimageinfo > > > > > > It does state that this is Optional, and has a statement "A zero means > > > the FMP provider is not able to determine a unique hardware instance > > number or a hardware instance number is not needed." > > > > > > Also, our ESRT implementation just merges all instances to one anyways > > > so it doesn't currently consume the hardware instance except for this > > check. > > > > > > Thanks, > > > Jeff > > > > > > > -Original Message- > > > > From: Kinney, Michael D > > > > Sent: Thursday, February 9, 2023 8:43 PM > > > > To: devel@edk2.groups.io; Jeff Brasen ; Demeter, > > > > Miki > > > > Cc: Kinney, Michael D > > > > Subject: RE: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple > > > > devices with 0 HardwareInstance > > > > > > > > External email: Use caution opening links or attachments > > > > > > > > > > > > Hi Jeff, > > > > > > > > Thank you for the reminder. > > > > > > > > I am wondering if the check should be for FmpVersion < 3 and not > > > > FmpHardwareInstance != 0. > > > > > > > > It is possible for an FmpInfoBuffer to have an FmpVersion >= 3 and a > > > > HardwareInstance of 0. If more than one of these it found, then > > > > that would be an EFI_UNSUPPORTED condition. > > > > > > > > If FmpVersion >= 3, then the HardwareInstance must be filled in with > > > > a unique value. 0 can be used if there is at most 1 instance, so > > > > the duplicate check would never be triggered. If FmpVersion >= 3 > > > > and there can be more then one instance, then the HardwareInstance > > > > must be a non-zero unique value. > > > > > > > > Thanks, > > > > > > > > Mike > > > > > > > > > -Original Message- > > > > > From: devel@edk2.groups.io On Behalf Of > > > > > Jeff Brasen via groups.io > > > > > Sent: Thursday, February 9, 2023 2:03 PM > > > > > To: Demeter, Miki > > > > > Cc: devel@edk2.groups.io > > > > > Subject: [edk2-devel] FW: [PATCH v2] MdeModulePkg/EsrtFmpDxe: > > > > Support > > > > > multiple devices with 0 HardwareInstance > > > > > > > > > > Here is a patch that has been pending for a bit > > > > > > > > > > Thanks, > > > > > Jeff > > > > > > > > > > -Original Message- > > > > > From: Jeff Brasen > > > > > Sent: Wednesday, February 1, 2023 9:21 AM > > > > > To: devel@edk2.groups.io > > > > > Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn; > > > > > guomin.ji...@intel.com > > > > > Subject: RE: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple > > > > > devices with 0 HardwareInstance > > > > > > > > > > Any updates on this would be great to get this in for the next > > > > > stable release > > > > if possible. > > > > > > > > > > > -Original Message- > > > > > > From: Jeff Brasen > > > > > > Sent: Monday, December 12, 2022 12:27 PM > > > > > > To: devel@edk2.groups.io > > > > > > Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn; > > > > > > guomin.ji...@intel.com; Jeff Brasen > > > > > > Subject: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple > > > > > > devices with 0 HardwareInstance > > > > > > > > > > > > Skip error check if HardwareInstance is 0 as this ei
Re: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple devices with 0 HardwareInstance
It was not as we were seeing devices expose FMP via an option rom driver with Version == 3 and HardwareInstance = 0. If there are multiple of these device it would hit the error in the EsrtCode. The patch included does resolve the issues we were seeing. -Jeff > -Original Message- > From: Kinney, Michael D > Sent: Friday, February 10, 2023 12:48 PM > To: devel@edk2.groups.io; Jeff Brasen ; Demeter, > Miki > Cc: Kinney, Michael D > Subject: RE: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support > multiple devices with 0 HardwareInstance > > External email: Use caution opening links or attachments > > > Did your original approach work for all your use cases? > > Mike > > > -Original Message- > > From: devel@edk2.groups.io On Behalf Of Jeff > > Brasen via groups.io > > Sent: Friday, February 10, 2023 8:45 AM > > To: Kinney, Michael D ; > > devel@edk2.groups.io; Demeter, Miki > > Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: > Support > > multiple devices with 0 HardwareInstance > > > > That was my original approach when I saw this but I was seeing this > > occur on a device with FmpVersion == 3. The UEFI spec isn't completely > clear but could be read that 0 is legal if this part isn't being used. > > > > > https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.htm > l > > #efi-firmware-management-protocol-getimageinfo > > > > It does state that this is Optional, and has a statement "A zero means > > the FMP provider is not able to determine a unique hardware instance > number or a hardware instance number is not needed." > > > > Also, our ESRT implementation just merges all instances to one anyways > > so it doesn't currently consume the hardware instance except for this > check. > > > > Thanks, > > Jeff > > > > > -Original Message- > > > From: Kinney, Michael D > > > Sent: Thursday, February 9, 2023 8:43 PM > > > To: devel@edk2.groups.io; Jeff Brasen ; Demeter, > > > Miki > > > Cc: Kinney, Michael D > > > Subject: RE: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple > > > devices with 0 HardwareInstance > > > > > > External email: Use caution opening links or attachments > > > > > > > > > Hi Jeff, > > > > > > Thank you for the reminder. > > > > > > I am wondering if the check should be for FmpVersion < 3 and not > > > FmpHardwareInstance != 0. > > > > > > It is possible for an FmpInfoBuffer to have an FmpVersion >= 3 and a > > > HardwareInstance of 0. If more than one of these it found, then > > > that would be an EFI_UNSUPPORTED condition. > > > > > > If FmpVersion >= 3, then the HardwareInstance must be filled in with > > > a unique value. 0 can be used if there is at most 1 instance, so > > > the duplicate check would never be triggered. If FmpVersion >= 3 > > > and there can be more then one instance, then the HardwareInstance > > > must be a non-zero unique value. > > > > > > Thanks, > > > > > > Mike > > > > > > > -Original Message- > > > > From: devel@edk2.groups.io On Behalf Of > > > > Jeff Brasen via groups.io > > > > Sent: Thursday, February 9, 2023 2:03 PM > > > > To: Demeter, Miki > > > > Cc: devel@edk2.groups.io > > > > Subject: [edk2-devel] FW: [PATCH v2] MdeModulePkg/EsrtFmpDxe: > > > Support > > > > multiple devices with 0 HardwareInstance > > > > > > > > Here is a patch that has been pending for a bit > > > > > > > > Thanks, > > > > Jeff > > > > > > > > -Original Message- > > > > From: Jeff Brasen > > > > Sent: Wednesday, February 1, 2023 9:21 AM > > > > To: devel@edk2.groups.io > > > > Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn; > > > > guomin.ji...@intel.com > > > > Subject: RE: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple > > > > devices with 0 HardwareInstance > > > > > > > > Any updates on this would be great to get this in for the next > > > > stable release > > > if possible. > > > > > > > > > -Original Message- > > > > > From: Jeff Brasen > > > > > Sent: Monday, December 12, 2022 12:27 PM > > > > > To: devel@edk2.groups.io > > > > > Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn; > > > > > guomin.ji...@intel.com; Jeff Brasen > > > > > Subject: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple > > > > > devices with 0 HardwareInstance > > > > > > > > > > Skip error check if HardwareInstance is 0 as this either means > > > > > that FmpVersion < 3 and not supported or, "A zero means the FMP > > > > > provider is not able to determine a unique hardware instance > > > > > number or a hardware instance number is not needed." per UEFI > specification. > > > > > > > > > > As the FmpInstances are merged and HardwareInstance is not used > > > > > remove error check in this case. > > > > > > > > > > > > > > > Signed-off-by: Jeff Brasen > > > > > --- > > > > > MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c | 22 > -- > > > > > > > > --- > > > > > 1 file changed, 13 insertions(+), 9 deletions(-) > > > > > > > > > > diff --git a/MdeModulePkg/Univers
Re: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple devices with 0 HardwareInstance
Did your original approach work for all your use cases?
Mike
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Jeff Brasen
> via groups.io
> Sent: Friday, February 10, 2023 8:45 AM
> To: Kinney, Michael D ; devel@edk2.groups.io;
> Demeter, Miki
> Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support
> multiple devices with 0 HardwareInstance
>
> That was my original approach when I saw this but I was seeing this occur on
> a device with FmpVersion == 3. The UEFI spec isn't
> completely clear but could be read that 0 is legal if this part isn't being
> used.
>
> https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.html#efi-firmware-management-protocol-getimageinfo
>
> It does state that this is Optional, and has a statement "A zero means the
> FMP provider is not able to determine a unique
> hardware instance number or a hardware instance number is not needed."
>
> Also, our ESRT implementation just merges all instances to one anyways so it
> doesn't currently consume the hardware instance
> except for this check.
>
> Thanks,
> Jeff
>
> > -Original Message-
> > From: Kinney, Michael D
> > Sent: Thursday, February 9, 2023 8:43 PM
> > To: devel@edk2.groups.io; Jeff Brasen ; Demeter,
> > Miki
> > Cc: Kinney, Michael D
> > Subject: RE: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple
> > devices with 0 HardwareInstance
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Hi Jeff,
> >
> > Thank you for the reminder.
> >
> > I am wondering if the check should be for FmpVersion < 3 and not
> > FmpHardwareInstance != 0.
> >
> > It is possible for an FmpInfoBuffer to have an FmpVersion >= 3 and a
> > HardwareInstance of 0. If more than one of these it found, then that would
> > be an EFI_UNSUPPORTED condition.
> >
> > If FmpVersion >= 3, then the HardwareInstance must be filled in with a
> > unique value. 0 can be used if there is at most 1 instance, so the
> > duplicate
> > check would never be triggered. If FmpVersion >= 3 and there can be more
> > then one instance, then the HardwareInstance must be a non-zero unique
> > value.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io On Behalf Of Jeff
> > > Brasen via groups.io
> > > Sent: Thursday, February 9, 2023 2:03 PM
> > > To: Demeter, Miki
> > > Cc: devel@edk2.groups.io
> > > Subject: [edk2-devel] FW: [PATCH v2] MdeModulePkg/EsrtFmpDxe:
> > Support
> > > multiple devices with 0 HardwareInstance
> > >
> > > Here is a patch that has been pending for a bit
> > >
> > > Thanks,
> > > Jeff
> > >
> > > -Original Message-
> > > From: Jeff Brasen
> > > Sent: Wednesday, February 1, 2023 9:21 AM
> > > To: devel@edk2.groups.io
> > > Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn;
> > > guomin.ji...@intel.com
> > > Subject: RE: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple
> > > devices with 0 HardwareInstance
> > >
> > > Any updates on this would be great to get this in for the next stable
> > > release
> > if possible.
> > >
> > > > -Original Message-
> > > > From: Jeff Brasen
> > > > Sent: Monday, December 12, 2022 12:27 PM
> > > > To: devel@edk2.groups.io
> > > > Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn;
> > > > guomin.ji...@intel.com; Jeff Brasen
> > > > Subject: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple
> > > > devices with 0 HardwareInstance
> > > >
> > > > Skip error check if HardwareInstance is 0 as this either means that
> > > > FmpVersion < 3 and not supported or, "A zero means the FMP provider
> > > > is not able to determine a unique hardware instance number or a
> > > > hardware instance number is not needed." per UEFI specification.
> > > >
> > > > As the FmpInstances are merged and HardwareInstance is not used
> > > > remove error check in this case.
> > > >
> > > >
> > > > Signed-off-by: Jeff Brasen
> > > > ---
> > > > MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c | 22 --
> >
> > > > ---
> > > > 1 file changed, 13 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> > > > b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> > > > index 4f47c55cce..5bc627461d 100644
> > > > --- a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> > > > +++ b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> > > > @@ -153,16 +153,20 @@ CreateEsrtEntry (
> > > >
> > > >//
> > > >// Check to see of FmpImageInfoBuf GUID/HardwareInstance is
> > > > unique
> > > > + // Skip if HardwareInstance is 0 as this is the case if
> > > > + FmpVersion <
> > > > + 3 // or the device can not create a unique ID per UEFI
> > > > + specification
> > > >//
> > > > - for (Index = 0; Index < *NumberOfDescriptors; Index++) {
> > > > -if (CompareGuid (&HardwareInstances[Index].ImageTypeGuid,
> > > > &FmpImageInfoBuf->ImageTypeId)) {
> > > > - if (HardwareInstances[Index].HardwareInstance ==
> > > > FmpHardwareIns
Re: [edk2-devel] [edk2-platforms][PATCH v1 1/1] SpiFvbServiceStandaloneMm: Add changes for rewrite varstore header
Thanks Michael! Patch has been merged: https://github.com/tianocore/edk2-platforms/commit/e2353ad640d55dafb7315eae2a93b318809ccbe3 > -Original Message- > From: mikub...@linux.microsoft.com > Sent: Thursday, February 9, 2023 4:52 PM > To: devel@edk2.groups.io > Cc: S, Ashraf Ali ; Oram, Isaac W > ; Chaganty, Rangasai V > ; Ni, Ray ; Chiu, Chasel > > Subject: [edk2-platforms][PATCH v1 1/1] SpiFvbServiceStandaloneMm: Add > changes for rewrite varstore header > > From: Michael Kubacki > > Updates the Standalone MM module to have the necessary INF changes to build > with the following two recent commits made to rewrite the the variable store > header in the MM SPI FVB service. > > - e95c798 > - 88d44c5 > > Cc: Ashraf Ali S > Cc: Isaac Oram > Cc: Rangasai V Chaganty > Cc: Ray Ni > Cc: Chasel Chiu > Signed-off-by: Michael Kubacki > --- > > Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceStandalo > neMm.inf | 4 > Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec >| 4 +++- > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git > a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceStandal > oneMm.inf > b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceStandal > oneMm.inf > index 152cf0036fdb..717b6fc00cc6 100644 > --- > a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceStandal > oneMm.inf > +++ b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbSe > +++ rviceStandaloneMm.inf > @@ -44,6 +44,8 @@ [Packages] > [Pcd] >gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvBase ## > CONSUMES >gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvSize ## CONSUMES > + gIntelSiliconPkgTokenSpaceGuid.PcdFlashVariableStoreType ## > SOMETIMES_CONSUMES > + gIntelSiliconPkgTokenSpaceGuid.PcdFlashNvStorageAdditionalSize ## > + CONSUMES > > [Sources] >FvbInfo.c > @@ -60,6 +62,8 @@ [Protocols] > [Guids] >gEfiFirmwareFileSystem2Guid ## CONSUMES >gEfiSystemNvDataFvGuid## CONSUMES > + gEfiVariableGuid ## SOMETIMES_CONSUMES > + gEfiAuthenticatedVariableGuid ## SOMETIMES_CONSUMES > > [Depex] >TRUE > diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec > b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec > index d73a51ca5235..cad22acda496 100644 > --- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec > +++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec > @@ -188,7 +188,8 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, > PcdsDynamic, PcdsDynamicEx] > >## Define Flash Variable Store type. ># When Flash Variable Store corruption happened, the SpiFvbService will > recreate Variable Store > - # with valid header information provided by this PCD value. > + # with valid header information provided by this PCD value. > + # Note: This PCD must be FixedAtBuild when using Standalone MM. ># 0: Variable Store is gEfiVariableGuid type. ># 1: Variable Store is gEfiAuthenticatedVariableGuid type. ># Other value: reserved for future use. @@ -199,6 +200,7 @@ > [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] ># Platform may implement a Regular variable region and an additional > region, > which will require this PCD ># to tell SpiFvbService to include both regions. ># Note: This PCD is for compatible with legacy usages that should be > deprecated. > + # Note: This PCD must be FixedAtBuild when using Standalone MM. ># The new usage model should define separate regions without implicit > connections to UEFI Variable or FTW regions. ># Example legacy usage is to set this PCD equal to platform > PcdFlashFvNvStorageEventLogSize. ># 0: No additional NVS region. > -- > 2.28.0.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100033): https://edk2.groups.io/g/devel/message/100033 Mute This Topic: https://groups.io/mt/96867025/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 03/19] MdePkg: Add BaseRiscVSbiLib Library for RISC-V
Reviewed-by: Michael D Kinney
> -Original Message-
> From: Sunil V L
> Sent: Friday, February 10, 2023 4:30 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang
> ; Abner Chang ; Warkentin,
> Andrei
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V8 03/19] MdePkg: Add
> BaseRiscVSbiLib Library for RISC-V
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
>
> This library is required to make SBI ecalls from the S-mode EDK2.
> This is mostly copied from
> edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Zhiguang Liu
> Signed-off-by: Sunil V L
> Acked-by: Abner Chang
> Reviewed-by: Andrei Warkentin
> ---
> MdePkg/MdePkg.dec | 4 +
> MdePkg/MdePkg.dsc | 3 +
> MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf | 26 +++
> MdePkg/Include/Library/BaseRiscVSbiLib.h | 154 +
> MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.c | 231
> MdePkg/Library/BaseRiscVSbiLib/RiscVSbiEcall.S | 42
> 6 files changed, 460 insertions(+)
>
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index 3d08f20d15b0..ca2e4dcf815c 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -316,6 +316,10 @@ [LibraryClasses.IA32, LibraryClasses.X64]
>## @libraryclass Provides function to support TDX processing.
>TdxLib|Include/Library/TdxLib.h
>
> +[LibraryClasses.RISCV64]
> + ## @libraryclass Provides function to make ecalls to SBI
> + BaseRiscVSbiLib|Include/Library/BaseRiscVSbiLib.h
> +
> [Guids]
>#
># GUID defined in UEFI2.1/UEFI2.0/EFI1.1
> diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
> index 32a852dc466e..0ac7618b4623 100644
> --- a/MdePkg/MdePkg.dsc
> +++ b/MdePkg/MdePkg.dsc
> @@ -190,4 +190,7 @@ [Components.ARM, Components.AARCH64]
>MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf
>MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
>
> +[Components.RISCV64]
> + MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
> +
> [BuildOptions]
> diff --git a/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
> b/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
> new file mode 100644
> index ..d6fd3f663af1
> --- /dev/null
> +++ b/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
> @@ -0,0 +1,26 @@
> +## @file
> +# RISC-V Library to call SBI ecalls
> +#
> +# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
> reserved.
> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> + INF_VERSION = 0x0001001b
> + BASE_NAME = BaseRiscVSbiLib
> + FILE_GUID = D742CF3D-E600-4009-8FB5-318073008508
> + MODULE_TYPE = BASE
> + VERSION_STRING = 1.0
> + LIBRARY_CLASS = RiscVSbiLib
> +
> +[Sources]
> + BaseRiscVSbiLib.c
> + RiscVSbiEcall.S
> +
> +[Packages]
> + MdePkg/MdePkg.dec
> +
> +[LibraryClasses]
> + BaseLib
> diff --git a/MdePkg/Include/Library/BaseRiscVSbiLib.h
> b/MdePkg/Include/Library/BaseRiscVSbiLib.h
> new file mode 100644
> index ..e75520b4b888
> --- /dev/null
> +++ b/MdePkg/Include/Library/BaseRiscVSbiLib.h
> @@ -0,0 +1,154 @@
> +/** @file
> + Library to call the RISC-V SBI ecalls
> +
> + Copyright (c) 2021-2022, Hewlett Packard Development LP. All rights
> reserved.
> +
> + SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> + @par Glossary:
> +- Hart - Hardware Thread, similar to a CPU core
> +
> + Currently, EDK2 needs to call SBI only to set the time and to do system
> reset.
> +
> +**/
> +
> +#ifndef RISCV_SBI_LIB_H_
> +#define RISCV_SBI_LIB_H_
> +
> +#include
> +
> +/* SBI Extension IDs */
> +#define SBI_EXT_TIME 0x54494D45
> +#define SBI_EXT_SRST 0x53525354
> +
> +/* SBI function IDs for TIME extension*/
> +#define SBI_EXT_TIME_SET_TIMER 0x0
> +
> +/* SBI function IDs for SRST extension */
> +#define SBI_EXT_SRST_RESET 0x0
> +
> +#define SBI_SRST_RESET_TYPE_SHUTDOWN 0x0
> +#define SBI_SRST_RESET_TYPE_COLD_REBOOT 0x1
> +#define SBI_SRST_RESET_TYPE_WARM_REBOOT 0x2
> +
> +#define SBI_SRST_RESET_REASON_NONE 0x0
> +#define SBI_SRST_RESET_REASON_SYSFAIL 0x1
> +
> +/* SBI return error codes */
> +#define SBI_SUCCESS0
> +#define SBI_ERR_FAILED -1
> +#define SBI_ERR_NOT_SUPPORTED -2
> +#define SBI_ERR_INVALID_PARAM -3
> +#define SBI_ERR_DENIED -4
> +#define SBI_ERR_INVALID_ADDRESS-5
> +#define SBI_ERR_ALREADY_AVAILABLE -6
> +#define SBI_ERR_ALREADY_STARTED-7
> +#define SBI_ERR_ALREADY_STOPPED-8
> +
> +#define SBI_LAST_ERR SBI_ERR_ALREADY_STOPPED
> +
> +typedef struct {
> + UINT64BootHartId;
> + VOID *PeiServiceTable;// PEI Service table
> + VOID *PrePiHobList; // Pre PI Hob List
> + UINT64FlattenedDeviceTree; // Pointer to Flattened Device tree
> +} EFI_RISCV_FIRMWARE_CON
Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 02/19] MdePkg/BaseLib: RISC-V: Add few more helper functions
Reviewed-by: Michael D Kinney
> -Original Message-
> From: Sunil V L
> Sent: Friday, February 10, 2023 4:30 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang
> ; Daniel Schaefer ; Abner
> Chang ; Warkentin, Andrei
>
> Subject: [edk2-staging/RiscV64QemuVirt PATCH V8 02/19] MdePkg/BaseLib:
> RISC-V: Add few more helper functions
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
>
> Few of the basic helper functions required for any
> RISC-V CPU were added in edk2-platforms. To support
> qemu virt, they need to be added in BaseLib.
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Zhiguang Liu
> Cc: Daniel Schaefer
> Signed-off-by: Sunil V L
> Acked-by: Abner Chang
> Reviewed-by: Andrei Warkentin
> ---
> MdePkg/Library/BaseLib/BaseLib.inf | 3 ++
> MdePkg/Include/Library/BaseLib.h| 50 ++
> MdePkg/Library/BaseLib/RiscV64/CpuScratch.S | 31
> MdePkg/Library/BaseLib/RiscV64/ReadTimer.S | 23 +
> MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S | 53 ++--
> MdePkg/Library/BaseLib/RiscV64/RiscVMmu.S | 23 +
> 6 files changed, 179 insertions(+), 4 deletions(-)
>
> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
> b/MdePkg/Library/BaseLib/BaseLib.inf
> index 9ed46a584a14..3a48492b1a01 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -401,6 +401,9 @@ [Sources.RISCV64]
>RiscV64/RiscVCpuPause.S | GCC
>RiscV64/RiscVInterrupt.S | GCC
>RiscV64/FlushCache.S | GCC
> + RiscV64/CpuScratch.S | GCC
> + RiscV64/ReadTimer.S | GCC
> + RiscV64/RiscVMmu.S| GCC
>
> [Sources.LOONGARCH64]
>Math64.c
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index f3f59f21c2ea..8f2df76c29a3 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -151,6 +151,56 @@ typedef struct {
>
> #define BASE_LIBRARY_JUMP_BUFFER_ALIGNMENT 8
>
> +VOID
> +RiscVSetSupervisorScratch (
> + IN UINT64
> + );
> +
> +UINT64
> +RiscVGetSupervisorScratch (
> + VOID
> + );
> +
> +VOID
> +RiscVSetSupervisorStvec (
> + IN UINT64
> + );
> +
> +UINT64
> +RiscVGetSupervisorStvec (
> + VOID
> + );
> +
> +UINT64
> +RiscVGetSupervisorTrapCause (
> + VOID
> + );
> +
> +VOID
> +RiscVSetSupervisorAddressTranslationRegister (
> + IN UINT64
> + );
> +
> +UINT64
> +RiscVReadTimer (
> + VOID
> + );
> +
> +VOID
> +RiscVEnableTimerInterrupt (
> + VOID
> + );
> +
> +VOID
> +RiscVDisableTimerInterrupt (
> + VOID
> + );
> +
> +VOID
> +RiscVClearPendingTimerInterrupt (
> + VOID
> + );
> +
> #endif // defined (MDE_CPU_RISCV64)
>
> #if defined (MDE_CPU_LOONGARCH64)
> diff --git a/MdePkg/Library/BaseLib/RiscV64/CpuScratch.S
> b/MdePkg/Library/BaseLib/RiscV64/CpuScratch.S
> new file mode 100644
> index ..5492a500eb5e
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/RiscV64/CpuScratch.S
> @@ -0,0 +1,31 @@
> +//--
> +//
> +// CPU scratch register related functions for RISC-V
> +//
> +// Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
> reserved.
> +//
> +// SPDX-License-Identifier: BSD-2-Clause-Patent
> +//
> +//--
> +
> +#include
> +
> +.data
> +.align 3
> +.section .text
> +
> +//
> +// Set Supervisor mode scratch.
> +// @param a0 : Value set to Supervisor mode scratch
> +//
> +ASM_FUNC (RiscVSetSupervisorScratch)
> +csrw CSR_SSCRATCH, a0
> +ret
> +
> +//
> +// Get Supervisor mode scratch.
> +// @retval a0 : Value in Supervisor mode scratch
> +//
> +ASM_FUNC (RiscVGetSupervisorScratch)
> +csrr a0, CSR_SSCRATCH
> +ret
> diff --git a/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
> b/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
> new file mode 100644
> index ..39a06efa51ef
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
> @@ -0,0 +1,23 @@
> +//--
> +//
> +// Read CPU timer
> +//
> +// Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
> reserved.
> +//
> +// SPDX-License-Identifier: BSD-2-Clause-Patent
> +//
> +//--
> +
> +#include
> +
> +.data
> +.align 3
> +.section .text
> +
> +//
> +// Read TIME CSR.
> +// @retval a0 : 64-bit timer.
> +//
> +ASM_FUNC (RiscVReadTimer)
> +csrr a0, CSR_TIME
> +ret
> diff --git a/MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S
> b/MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S
> index 87b3468fc7fd..6a1b90a7e45c 100644
> --- a/MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S
> +++ b/MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S
> @@
Re: [edk2-devel] [PATCH 2/2] MdePkg: Update code to be more C11 compliant by using __func__
I would like to propose removing EBC support from edk2 and BaseTools after edk2-stable202302. Anyone requiring EBC can use edk2-stable202302 or older releases. Mike > -Original Message- > From: Leif Lindholm > Sent: Friday, February 10, 2023 7:20 AM > To: devel@edk2.groups.io; a...@kernel.org; rebe...@bsdio.com > Cc: Kinney, Michael D ; Gao, Liming > ; Liu, Zhiguang > > Subject: Re: [edk2-devel] [PATCH 2/2] MdePkg: Update code to be more C11 > compliant by using __func__ > > On 2023-02-10 11:45, Ard Biesheuvel wrote: > >> I wasn't sure if we cared about EBC builds these days. Given the link on > >> https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage- > general-technology.html > >> to the compiler goes to a generic page that doesn't mention it, is it > >> possible to get a copy if I want to verify if changes I'm making are > >> compatible? > > > > We tried to get access to this at Linaro, but I don't think it is > > still available. Leif may remember better. > > After asking around, some shady character in a café passed me a very > long and customized URL on a note in a brown paper bag, and I was able > to procure a single license for ARM. I don't think we succeeded for Linaro. > > > I wonder whether we should simply drop EBC support? It is unlikely > > that all the changes that went into EDK2 over the years have not > > caused a single EBC regression in the library components that are > > needed to build UEFI drivers that target EBC. > > The appearance of RISC-V and Loongarch since those days highlight why > architecture independent drivers would be a good thing, but EBC is > pining for the fjords. > > If we don't drop EBC now, we should start drafting a timeline for when > we will. > > / > Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100030): https://edk2.groups.io/g/devel/message/100030 Mute This Topic: https://groups.io/mt/96855618/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms][PATCH v1 1/1] SpiFvbServiceStandaloneMm: Add changes for rewrite varstore header
Reviewed-by: Chasel Chiu Thanks, Chasel > -Original Message- > From: mikub...@linux.microsoft.com > Sent: Thursday, February 9, 2023 4:52 PM > To: devel@edk2.groups.io > Cc: S, Ashraf Ali ; Oram, Isaac W > ; Chaganty, Rangasai V > ; Ni, Ray ; Chiu, Chasel > > Subject: [edk2-platforms][PATCH v1 1/1] SpiFvbServiceStandaloneMm: Add > changes for rewrite varstore header > > From: Michael Kubacki > > Updates the Standalone MM module to have the necessary INF changes to build > with the following two recent commits made to rewrite the the variable store > header in the MM SPI FVB service. > > - e95c798 > - 88d44c5 > > Cc: Ashraf Ali S > Cc: Isaac Oram > Cc: Rangasai V Chaganty > Cc: Ray Ni > Cc: Chasel Chiu > Signed-off-by: Michael Kubacki > --- > > Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceStandalo > neMm.inf | 4 > Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec >| 4 +++- > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git > a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceStandal > oneMm.inf > b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceStandal > oneMm.inf > index 152cf0036fdb..717b6fc00cc6 100644 > --- > a/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbServiceStandal > oneMm.inf > +++ b/Silicon/Intel/IntelSiliconPkg/Feature/Flash/SpiFvbService/SpiFvbSe > +++ rviceStandaloneMm.inf > @@ -44,6 +44,8 @@ [Packages] > [Pcd] >gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvBase ## > CONSUMES >gIntelSiliconPkgTokenSpaceGuid.PcdFlashMicrocodeFvSize ## CONSUMES > + gIntelSiliconPkgTokenSpaceGuid.PcdFlashVariableStoreType ## > SOMETIMES_CONSUMES > + gIntelSiliconPkgTokenSpaceGuid.PcdFlashNvStorageAdditionalSize ## > + CONSUMES > > [Sources] >FvbInfo.c > @@ -60,6 +62,8 @@ [Protocols] > [Guids] >gEfiFirmwareFileSystem2Guid ## CONSUMES >gEfiSystemNvDataFvGuid## CONSUMES > + gEfiVariableGuid ## SOMETIMES_CONSUMES > + gEfiAuthenticatedVariableGuid ## SOMETIMES_CONSUMES > > [Depex] >TRUE > diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec > b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec > index d73a51ca5235..cad22acda496 100644 > --- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec > +++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec > @@ -188,7 +188,8 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, > PcdsDynamic, PcdsDynamicEx] > >## Define Flash Variable Store type. ># When Flash Variable Store corruption happened, the SpiFvbService will > recreate Variable Store > - # with valid header information provided by this PCD value. > + # with valid header information provided by this PCD value. > + # Note: This PCD must be FixedAtBuild when using Standalone MM. ># 0: Variable Store is gEfiVariableGuid type. ># 1: Variable Store is gEfiAuthenticatedVariableGuid type. ># Other value: reserved for future use. @@ -199,6 +200,7 @@ > [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] ># Platform may implement a Regular variable region and an additional > region, > which will require this PCD ># to tell SpiFvbService to include both regions. ># Note: This PCD is for compatible with legacy usages that should be > deprecated. > + # Note: This PCD must be FixedAtBuild when using Standalone MM. ># The new usage model should define separate regions without implicit > connections to UEFI Variable or FTW regions. ># Example legacy usage is to set this PCD equal to platform > PcdFlashFvNvStorageEventLogSize. ># 0: No additional NVS region. > -- > 2.28.0.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100029): https://edk2.groups.io/g/devel/message/100029 Mute This Topic: https://groups.io/mt/96867025/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/1] MdePkg: Add DDR5 SPD defs to IndustryStandard per JESD400-5A.01
We usually do not include basetype includes from .h files in
Protocol/PPI/GUID/IndustryStandard.
This is because we always get base types from AutoGen.h and from C/H files in
modules/libs
That have to include top level include files for their module type. Base.h,
PiPei.h, PiDxe,h, Uefi.h.
Also UINT8 is available from Base.h that does not assume UEFI or PI env.
Mike
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Rebecca Cran
> Sent: Friday, February 10, 2023 3:05 AM
> To: devel@edk2.groups.io; Gao, Liming
> Cc: 'Liming Gao' ; Kinney, Michael D
> ; Liu, Zhiguang
> Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: Add DDR5 SPD defs to
> IndustryStandard per JESD400-5A.01
>
> Yes I’ve verified locally that this file builds. It doesn’t pass CI though
> since like the DDR4 header it has fields that begin
> with a lower-case letter.
>
> I added the include of Uefi/UefiBaseType.h because the UEFI type UINT8 is
> used.
>
> —
> Rebecca
>
> On Thu, Feb 9, 2023, at 10:23 PM, gaoliming via groups.io wrote:
> > Rebecca:
> > Have you verified this header file with build? For example, include this
> > new header file into module, and make sure this module pass build.
> >
> >> -邮件原件-
> >> 发件人: devel@edk2.groups.io 代表 Rebecca Cran
> >> 发送时间: 2023年2月9日 1:48
> >> 收件人: devel@edk2.groups.io
> >> 抄送: Rebecca Cran ; Liming Gao
> >> ; Michael D Kinney ;
> >> Zhiguang Liu
> >> 主题: [edk2-devel] [PATCH 1/1] MdePkg: Add DDR5 SPD defs to
> >> IndustryStandard per JESD400-5A.01
> >>
> >> Copying the style of SdramSpdDdr4.h, add DDR5 SPD definitions to
> >> SpdDdr5.h per JEDEC JESD400-5A.01 specification
> >> (https://www.jedec.org/standards-documents/docs/jesd400-5a01).
> >>
> >> Signed-off-by: Rebecca Cran
> >> Cc: Liming Gao
> >> Cc: Michael D Kinney
> >> Cc: Zhiguang Liu
> >> ---
> >> MdePkg/Include/IndustryStandard/SpdDdr5.h | 541
> >>
> >> 1 file changed, 541 insertions(+)
> >>
> >> diff --git a/MdePkg/Include/IndustryStandard/SpdDdr5.h
> >> b/MdePkg/Include/IndustryStandard/SpdDdr5.h
> >> new file mode 100644
> >> index ..305ab69af852
> >> --- /dev/null
> >> +++ b/MdePkg/Include/IndustryStandard/SpdDdr5.h
> >> @@ -0,0 +1,541 @@
> >> +/** @file
> >> + This file contains definitions for DDR5 SPD.
> >> +
> >> + Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights
> >> reserved.
> >> + Copyright (c) 2016, Intel Corporation. All rights reserved.
> >> + SPDX-License-Identifier: BSD-2-Clause-Patent
> >> +
> >> + @par Revision Reference:
> >> +- DDR5 Serial Presence Detect (SPD), Document Release 1.1 (Jan 2023)
> >> + https://www.jedec.org/standards-documents/docs/jesd400-5a01
> >> +**/
> >> +
> >> +#ifndef SPD_DDR5_H_
> >> +#define SPD_DDR5_H_
> >> +
> >> +#include
> >
> > Is there any uefi definition used in this header file? If no, this include
> > can be removed.
> >
> > Thanks
> > Liming
> >
> >> +
> >> +#pragma pack (push, 1)
> >> +
> >> +typedef union {
> >> + struct {
> >> +UINT8BetaLevel3_0 : 4;///< Bits
> >> 3:0
> >> +UINT8BytesTotal : 3;///< Bits
> >> 6:4
> >> +UINT8BetaLevel4 : 1;///< Bits
> >> 7:7
> >> + } Bits;
> >> + UINT8Data;
> >> +} SPD5_DEVICE_DESCRIPTION_STRUCT;
> >> +
> >> +typedef union {
> >> + struct {
> >> +UINT8Minor : 4; ///< Bits
> >> 3:0
> >> +UINT8Major : 4; ///< Bits
> >> 7:4
> >> + } Bits;
> >> + UINT8Data;
> >> +} SPD5_REVISION_STRUCT;
> >> +
> >> +typedef union {
> >> + struct {
> >> +UINT8Type : 8;///< Bits
> >> 7:0
> >> + } Bits;
> >> + UINT8Data;
> >> +} SPD5_DEVICE_TYPE_STRUCT;
> >> +
> >> +typedef union {
> >> + struct {
> >> +UINT8ModuleType : 4; ///< Bits
> >> 3:0
> >> +UINT8HybridMedia : 3; ///< Bits
> >> 6:4
> >> +UINT8Hybrid : 1; ///< Bits
> >> 7:7
> >> + } Bits;
> >> + UINT8Data;
> >> +} SPD5_MODULE_TYPE_STRUCT;
> >> +
> >> +typedef union {
> >> + struct {
> >> +UINT8Density : 5; ///< Bits
> >> 4:0
> >> +UINT8Die : 3; ///< Bits
> >> 7:5
> >> + } Bits;
> >> + UINT8Data;
> >> +} SPD5_SDRAM_DENSITY_PACKAGE_STRUCT;
> >> +
> >> +typedef union {
> >> + struct {
> >> +UINT8RowAddress: 5; ///< Bits
> >> 4:0
> >> +UINT8ColumnAddress : 3; ///< Bits
> >> 7:5
> >> + } Bits;
> >> + UINT8Data;
> >> +} SPD5_SDRAM_ADDRESSING_STRUCT;
> >> +
> >> +typedef union {
> >> + struct {
> >> +UINT8Reserved : 5; ///< Bits
> >> 4:0
> >> +UINT8IoWidth : 3; ///< Bits
> >> 7:5
> >> + } Bits;
> >> + UINT8Data;
> >> +} SPD5_SDRAM_IO
Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe
On Fri, Feb 10, 2023 at 5:56 AM Gupta, Pankaj wrote: > > On 2/9/2023 10:27 PM, Dionna Amalie Glaze wrote: > > On Thu, Feb 9, 2023 at 8:52 AM Dionna Amalie Glaze > > wrote: > >> > >>> With this patch I observe an issue where my Linux (6.2.0-rc7) guest > >>> recur to Bootloader menu again. I am testing this with SEV SNP (w/o > >>> UPM). Also, guest don't have lazy memory acceptance support. > >>> > >> > >> Thanks for the report. I'll try to reproduce it on our UEFI and if I'm > >> unable, then we'll discuss next steps. > >> > > > > I don't see this in our test Ubuntu 22.04 image from Canonical. Do you > > Ubuntu 22.04 guest by default run 5.15 kernel? But SEV SNP got > merged in 5.19. I don't know currently how we are handling accepting > the memory on "ExitBootServices" with or w/o guest supporting SNP. > It does, but I used the Qemu kernel injection pathway in Ovmf to run a build of 6.2.0-rc7. Our testing setup doesn't give the user a boot menu to select a kernel, so I wasn't aware that this return to bootmenu could happen. >This looks to me like it is entering the 'accept' path twice, and so > ExitBootServices() is failing twice, resulting in a failed boot. The double log is expected behavior because I didn't add a check for whether accepting all memory would be a no-op. The "Accepting all memory" message occurs twice if the guest does not have support for unaccepted memory following this control flow: 1. EBS 2. [...] Log "Accepting all memory" 3. Loop through all memory spaces 3a. If the memory space is unaccepted, accept it. 3b. Remove the unaccepted memory space. 3c. Add a conventional memory space back with the same range and capabilities. 4. EBS returns an error since the map key is different. 5. OS calls GetMemoryMap to get the updated key. 6. OS calls EBS with the updated key. 7. [...] Log "Accepting all memory" 8. Loop through all memory spaces 8a. There are no unaccepted memory spaces left, so nothing happens. 9. Return successfully (one would hope) >Accepting all memory^M >Accepting all memory^M >EFI stub: ERROR: exit_boot() failed!^M >EFI stub: ERROR: efi_main() failed!^M This now does suggest that EBS is failing twice, since after the supposed no-op of the second log, the EFI stub's exit_boot claims failure. I can't reproduce this part. Would you try adding a log within the acceptance loop inside the if that checks for unaccepted memory? I'd be curious if the loop is indeed changing the map again, despite my claims at idempotency. -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100027): https://edk2.groups.io/g/devel/message/100027 Mute This Topic: https://groups.io/mt/96534752/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] MdeModulePkg/EsrtFmpDxe: Support multiple devices with 0 HardwareInstance
That was my original approach when I saw this but I was seeing this occur on a
device with FmpVersion == 3. The UEFI spec isn't completely clear but could be
read that 0 is legal if this part isn't being used.
https://uefi.org/specs/UEFI/2.10/23_Firmware_Update_and_Reporting.html#efi-firmware-management-protocol-getimageinfo
It does state that this is Optional, and has a statement "A zero means the FMP
provider is not able to determine a unique hardware instance number or a
hardware instance number is not needed."
Also, our ESRT implementation just merges all instances to one anyways so it
doesn't currently consume the hardware instance except for this check.
Thanks,
Jeff
> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, February 9, 2023 8:43 PM
> To: devel@edk2.groups.io; Jeff Brasen ; Demeter,
> Miki
> Cc: Kinney, Michael D
> Subject: RE: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple
> devices with 0 HardwareInstance
>
> External email: Use caution opening links or attachments
>
>
> Hi Jeff,
>
> Thank you for the reminder.
>
> I am wondering if the check should be for FmpVersion < 3 and not
> FmpHardwareInstance != 0.
>
> It is possible for an FmpInfoBuffer to have an FmpVersion >= 3 and a
> HardwareInstance of 0. If more than one of these it found, then that would
> be an EFI_UNSUPPORTED condition.
>
> If FmpVersion >= 3, then the HardwareInstance must be filled in with a
> unique value. 0 can be used if there is at most 1 instance, so the duplicate
> check would never be triggered. If FmpVersion >= 3 and there can be more
> then one instance, then the HardwareInstance must be a non-zero unique
> value.
>
> Thanks,
>
> Mike
>
> > -Original Message-
> > From: devel@edk2.groups.io On Behalf Of Jeff
> > Brasen via groups.io
> > Sent: Thursday, February 9, 2023 2:03 PM
> > To: Demeter, Miki
> > Cc: devel@edk2.groups.io
> > Subject: [edk2-devel] FW: [PATCH v2] MdeModulePkg/EsrtFmpDxe:
> Support
> > multiple devices with 0 HardwareInstance
> >
> > Here is a patch that has been pending for a bit
> >
> > Thanks,
> > Jeff
> >
> > -Original Message-
> > From: Jeff Brasen
> > Sent: Wednesday, February 1, 2023 9:21 AM
> > To: devel@edk2.groups.io
> > Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn;
> > guomin.ji...@intel.com
> > Subject: RE: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple
> > devices with 0 HardwareInstance
> >
> > Any updates on this would be great to get this in for the next stable
> > release
> if possible.
> >
> > > -Original Message-
> > > From: Jeff Brasen
> > > Sent: Monday, December 12, 2022 12:27 PM
> > > To: devel@edk2.groups.io
> > > Cc: jian.j.w...@intel.com; gaolim...@byosoft.com.cn;
> > > guomin.ji...@intel.com; Jeff Brasen
> > > Subject: [PATCH v2] MdeModulePkg/EsrtFmpDxe: Support multiple
> > > devices with 0 HardwareInstance
> > >
> > > Skip error check if HardwareInstance is 0 as this either means that
> > > FmpVersion < 3 and not supported or, "A zero means the FMP provider
> > > is not able to determine a unique hardware instance number or a
> > > hardware instance number is not needed." per UEFI specification.
> > >
> > > As the FmpInstances are merged and HardwareInstance is not used
> > > remove error check in this case.
> > >
> > >
> > > Signed-off-by: Jeff Brasen
> > > ---
> > > MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c | 22 --
>
> > > ---
> > > 1 file changed, 13 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> > > b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> > > index 4f47c55cce..5bc627461d 100644
> > > --- a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> > > +++ b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
> > > @@ -153,16 +153,20 @@ CreateEsrtEntry (
> > >
> > >//
> > >// Check to see of FmpImageInfoBuf GUID/HardwareInstance is
> > > unique
> > > + // Skip if HardwareInstance is 0 as this is the case if
> > > + FmpVersion <
> > > + 3 // or the device can not create a unique ID per UEFI
> > > + specification
> > >//
> > > - for (Index = 0; Index < *NumberOfDescriptors; Index++) {
> > > -if (CompareGuid (&HardwareInstances[Index].ImageTypeGuid,
> > > &FmpImageInfoBuf->ImageTypeId)) {
> > > - if (HardwareInstances[Index].HardwareInstance ==
> > > FmpHardwareInstance) {
> > > -DEBUG ((DEBUG_ERROR, "EsrtFmpDxe: Duplicate firmware image
> > > descriptor with GUID %g HardwareInstance:0x%x\n",
> &FmpImageInfoBuf-
> > > >ImageTypeId, FmpHardwareInstance));
> > > -ASSERT (
> > > - !CompareGuid (&HardwareInstances[Index].ImageTypeGuid,
> > > &FmpImageInfoBuf->ImageTypeId) ||
> > > - HardwareInstances[Index].HardwareInstance !=
> > > FmpHardwareInstance
> > > - );
> > > -return EFI_UNSUPPORTED;
> > > + if (FmpHardwareInstance != 0) {
> > > +for (Index = 0; Index < *NumberOfDescriptors; Index++) {
> > > + if (CompareGuid (&Hardware
Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 00/19] Add support for RISC-V virt machine
On Fri, Feb 10, 2023 at 02:49:18PM +0100, Ard Biesheuvel wrote: > Acked-by: Ard Biesheuvel > > I can go and merge this if desired: what is the situation wrt the stable tag? > Thanks! Ard. I updated the branch with latest ACKs and fixed one minor comment from Ray. It has completed the CI tests (https://github.com/tianocore/edk2/pull/4023) I would like to get this merged but I will let Ray and Mike to provide the recommendation regarding stable tag. Thanks, Sunil -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100025): https://edk2.groups.io/g/devel/message/100025 Mute This Topic: https://groups.io/mt/96874977/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 07/19] UefiCpuPkg: Add CpuTimerDxeRiscV64 module
On Fri, Feb 10, 2023 at 12:55:29PM +, Ni, Ray wrote: > > UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimer.uni | 14 + > > UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerExtra.uni | 12 + > > For the above two file name, better to use the same base name as that of INF > file. > Thanks! Ray. I have fixed it in the same branch which is going through the CI tests currently. But since entire series is ready, let me not send the revision again, which will spam people just for this. Thanks! Sunil -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100024): https://edk2.groups.io/g/devel/message/100024 Mute This Topic: https://groups.io/mt/96874987/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] Getting DDR5 SPD test data
I'm working on adding a new library to edk2 that will parse an SPD byte array and use it to construct an SMBIOS Type 17 table. As part of the work, I'm adding a new unit test to MdePkg/Test/UnitTest/Library and would like to get test data to verify correct operation of the library. I have DDR4 SPD data I've collected from machines I have access to, but I don't have any DDR5 systems. I was wondering if someone might have some test data for DDR5 I could use? -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100023): https://edk2.groups.io/g/devel/message/100023 Mute This Topic: https://groups.io/mt/96878412/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 V1 1/1] Platform/ARM/N1sdp: Add support to parse NT_FW_CONFIG
Hi Sahil, Thank you for pointing me to the V2 patch at https://edk2.groups.io/g/devel/message/99391 I will review this soon. Regards, Sami Mujawar From: on behalf of "Sami Mujawar via groups.io" Reply to: "devel@edk2.groups.io" , Sami Mujawar Date: Friday, 10 February 2023 at 15:19 To: Sahil , "devel@edk2.groups.io" Subject: Re: [edk2-devel] [edk2-platforms][PATCH V1 1/1] Platform/ARM/N1sdp: Add support to parse NT_FW_CONFIG Hi Sahil, Thomas is referring to my feedback at https://edk2.groups.io/g/devel/topic/87497028#84347 Can you check your patch once again to see those issues are fixed, please? Regards, Sami Mujawar -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100022): https://edk2.groups.io/g/devel/message/100022 Mute This Topic: https://groups.io/mt/96088980/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/2] MdePkg: Update code to be more C11 compliant by using __func__
On 2023-02-10 11:45, Ard Biesheuvel wrote: I wasn't sure if we cared about EBC builds these days. Given the link on https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html to the compiler goes to a generic page that doesn't mention it, is it possible to get a copy if I want to verify if changes I'm making are compatible? We tried to get access to this at Linaro, but I don't think it is still available. Leif may remember better. After asking around, some shady character in a café passed me a very long and customized URL on a note in a brown paper bag, and I was able to procure a single license for ARM. I don't think we succeeded for Linaro. I wonder whether we should simply drop EBC support? It is unlikely that all the changes that went into EDK2 over the years have not caused a single EBC regression in the library components that are needed to build UEFI drivers that target EBC. The appearance of RISC-V and Loongarch since those days highlight why architecture independent drivers would be a good thing, but EBC is pining for the fjords. If we don't drop EBC now, we should start drafting a timeline for when we will. / Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100021): https://edk2.groups.io/g/devel/message/100021 Mute This Topic: https://groups.io/mt/96855618/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms][PATCH V1 1/1] Platform/ARM/N1sdp: Add support to parse NT_FW_CONFIG
Hi Sahil, Thomas is referring to my feedback at https://edk2.groups.io/g/devel/topic/87497028#84347 Can you check your patch once again to see those issues are fixed, please? Regards, Sami Mujawar -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100020): https://edk2.groups.io/g/devel/message/100020 Mute This Topic: https://groups.io/mt/96088980/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe
On 2/9/2023 10:27 PM, Dionna Amalie Glaze wrote: On Thu, Feb 9, 2023 at 8:52 AM Dionna Amalie Glaze wrote: With this patch I observe an issue where my Linux (6.2.0-rc7) guest recur to Bootloader menu again. I am testing this with SEV SNP (w/o UPM). Also, guest don't have lazy memory acceptance support. Thanks for the report. I'll try to reproduce it on our UEFI and if I'm unable, then we'll discuss next steps. I don't see this in our test Ubuntu 22.04 image from Canonical. Do you Ubuntu 22.04 guest by default run 5.15 kernel? But SEV SNP got merged in 5.19. I don't know currently how we are handling accepting the memory on "ExitBootServices" with or w/o guest supporting SNP. Thanks, Pankaj have a boot log you could send me? I'm not sure I understand what you mean by recurring to the Bootloader menu. On ExitBootServices, the memory key will end up changing and the caller will need to call GetMemoryMap and try EBS again, but I don't know why that would send you to a bootmenu. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100019): https://edk2.groups.io/g/devel/message/100019 Mute This Topic: https://groups.io/mt/96534752/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 00/19] Add support for RISC-V virt machine
Acked-by: Ard Biesheuvel I can go and merge this if desired: what is the situation wrt the stable tag? On Fri, 10 Feb 2023 at 14:21, Yao, Jiewen wrote: > > OvmfPkg: Acked-by: Jiewen Yao > > > -Original Message- > > From: Sunil V L > > Sent: Friday, February 10, 2023 8:30 PM > > To: devel@edk2.groups.io > > Cc: Abner Chang ; Daniel Schaefer > > ; Kinney, Michael D ; > > Gao, Liming ; Ard Biesheuvel > > ; Yao, Jiewen ; Justen, > > Jordan L ; Gerd Hoffmann ; > > Sami Mujawar ; Leif Lindholm > > ; Dong, Eric ; Ni, Ray > > ; Kumar, Rahul R ; Liu, Zhiguang > > ; Anup Patel ; Heinrich > > Schuchardt ; Warkentin, Andrei > > > > Subject: [edk2-staging/RiscV64QemuVirt PATCH V8 00/19] Add support for RISC- > > V virt machine > > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 > > > > Add support for RISC-V qemu virt machine. Most of the changes are migrated > > from > > edk2-platforms repo and added qemu specific libraries under OvmfPkg. > > > > The series has passed CI tests (https://github.com/tianocore/edk2/pull/4023) > > > > These changes are available at: > > https://github.com/vlsunil/edk2/tree/RiscV64QemuVirt_V8 > > > > The series can be tested as per instructions @ > > https://github.com/vlsunil/riscv-uefi-edk2-docs/wiki/RISC-V-Qemu-Virt-support > > > > Changes since V7: > > 1) Addressed feedbacks from Mike and Ray. > > 2) Added Anrdrei as another reviewer for RiscVVirt > > 3) Rebased > > 4) Added RB and ACK tags > > > > Changes since V6: > > 1) Took inspiration from IntelTdx and added all RISC-V qemu related > > libraries and > > modules in OvmfPkg/RiscVVirt instead of directly under > > OvmfPkg/Library. Hoping for > > quicker review since now it shouldn't affect the existing OvmfPkg > > libraries/modules. > > 2) Dropped migration of NvVarStoreFormattedLib for now to avoid > > MdeModulePkg changes. > > Currently RISC-V Qemu doesn't support separate variable flash. So, > > it > > can be taken > > as a separate activity in future when required. > > 3) Rebased and new CI test request passed > > > > Changes since V5: > > 1) Avoided editing the existing INF files (as per feedback from Ray > > Ni). > > This reduced > > several refactor patches. > > 2) Moved to PEI less design (as per suggestion from Andrei Warkentin) > > 3) Added PciCpuIO2Dxe driver in OvmfPkg. > > 4) Removed APRIORI requirement in DSC/FDF infrastructure files. Now > > they > > are very similar to ArmVirtQemu. > > 5) Addressed Heinrich's feedback. > > 6) Rebased and added ack tags > > > > Changes since V4: > > 1) Rebased and added ACKs > > 2) Dropped few patches related to VirtNorFlashDxe since they are > > already taken care by Ard. > > > > Changes since V3: > > 1) Addressed Abner's comments > > 2) Changed folder name from Ia32_X64 to Ia32X64 as per latest > > guidelines. > > 2) Rebased > > > > Changes since V2: > > 1) Fixed issues detected by CI > > 2) Added an extra patch to fix up the consumers of > > NvVarStoreFormattedLib > > > > Changes since V1: > > 1) Added couple of patches from Ard to optimize the NorFlashDxe in > > Ovmf. > > Note: There will be a separate patch series in future to update > > existing > > consumers of NorFlashDxe driver. > > 2) Migrated NvVarStoreFormattedLib from EmbeddedPkg to > > MdeModulePkg > > 3) Created Null instance of the NorFlashPlatformLib library class > > 4) Moved NorFlashPlatformLib.h from ArmPlatformPkg > > > > > > Cc: Abner Chang > > Cc: Daniel Schaefer > > Cc: Michael D Kinney > > Cc: Liming Gao > > Cc: Ard Biesheuvel > > Cc: Jiewen Yao > > Cc: Jordan Justen > > Cc: Gerd Hoffmann > > Cc: Sami Mujawar > > Cc: Leif Lindholm > > Cc: Eric Dong > > Cc: Ray Ni > > Cc: Rahul Kumar > > Cc: Zhiguang Liu > > Cc: Anup Patel > > Cc: Heinrich Schuchardt > > Cc: Andrei Warkentin > > > > Sunil V L (19): > > MdePkg/Register: Add register definition header files for RISC-V > > MdePkg/BaseLib: RISC-V: Add few more helper functions > > MdePkg: Add BaseRiscVSbiLib Library for RISC-V > > UefiCpuPkg: Add RISCV_EFI_BOOT_PROTOCOL related definitions > > UefiCpuPkg: Add BaseRiscV64CpuExceptionHandlerLib > > UefiCpuPkg: Add BaseRiscV64CpuTimerLib library > > UefiCpuPkg: Add CpuTimerDxeRiscV64 module > > UefiCpuPkg: Add CpuDxeRiscV64 module > > UefiCpuPkg/UefiCpuPkg.ci.yaml: Ignore RISC-V file > > ArmVirtPkg/PlatformHasAcpiDtDxe: Move to OvmfPkg > > ArmVirtPkg: Fix up the location of PlatformHasAcpiDtDxe > > OvmfPkg/RiscVVirt: Add PlatformBootManagerLib library > > OvmfPkg/RiscVVirt: Add PrePiHobListPointerLib library > > OvmfPkg/RiscVVirt: Add ResetSystemLib library > > OvmfPkg/RiscVVirt: Add VirtNorFlashPlatformLib library > > OvmfPkg/RiscVVirt: Add PciCpuIo2Dxe module > > OvmfPkg/RiscVVirt: Add SEC module > > OvmfPkg/RiscVVirt: Add
Re: [edk2-devel] [PATCH v2 00/10] OvmfPkg: add Crypto Driver support
On Fri, 10 Feb 2023 at 14:42, Ard Biesheuvel wrote: > > On Fri, 10 Feb 2023 at 09:42, Gerd Hoffmann wrote: > > > > On Thu, Feb 09, 2023 at 05:46:15PM +0100, Ard Biesheuvel wrote: > > > On Thu, 9 Feb 2023 at 11:27, Gerd Hoffmann wrote: > > > > > > > > Known problem: the NOOPT builds fail due to PEI becoming too big. > > > > > > > > What is the reason for doing these NOOPT builds? > > > > > > They are very useful for doing single step debugging with GDB. On ARM, > > > I use the NOOPT builds fairly regularly. > > > > Can LTO be enabled for the NOOPT build? Or depends that on > > optimizations being turned on? > > > With the hunk below applied: FV Space Information SECFV [63%Full] 212992 (0x34000) total, 135824 (0x21290) used, 77168 (0x12d70) free PEIFV [59%Full] 917504 (0xe) total, 544744 (0x84fe8) used, 372760 (0x5b018) free DXEFV [53%Full] 13631488 (0xd0) total, 7300712 (0x6f6668) used, 6330776 (0x609998) free FVMAIN_COMPACT [40%Full] 3440640 (0x348000) total, 1383832 (0x151d98) used, 2056808 (0x1f6268) free Without: FV Space Information SECFV [49%Full] 212992 (0x34000) total, 105936 (0x19dd0) used, 107056 (0x1a230) free PEIFV [62%Full] 917504 (0xe) total, 575656 (0x8c8a8) used, 341848 (0x53758) free DXEFV [56%Full] 13631488 (0xd0) total, 7652840 (0x74c5e8) used, 5978648 (0x5b3a18) free FVMAIN_COMPACT [40%Full] 3440640 (0x348000) total, 1376272 (0x150010) used, 2064368 (0x1f7ff0) free (without any -D options turned on) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index f77e936c0453..48319fc2e9b4 100755 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -2342,8 +2342,8 @@ RELEASE_GCC5_IA32_DLINK_FLAGS= DEF(GCC5_IA32_X64_DLINK_FLAGS) -flto -Os -Wl, RELEASE_GCC5_X64_CC_FLAGS= DEF(GCC5_X64_CC_FLAGS) -flto -DUSING_LTO -Wno-unused-but-set-variable -Wno-unused-const-variable RELEASE_GCC5_X64_DLINK_FLAGS = DEF(GCC5_X64_DLINK_FLAGS) -flto -Os - NOOPT_GCC5_X64_CC_FLAGS= DEF(GCC5_X64_CC_FLAGS) -O0 - NOOPT_GCC5_X64_DLINK_FLAGS = DEF(GCC5_X64_DLINK_FLAGS) -O0 + NOOPT_GCC5_X64_CC_FLAGS= DEF(GCC5_X64_CC_FLAGS) -O0 -flto -DUSING_LTO + NOOPT_GCC5_X64_DLINK_FLAGS = DEF(GCC5_X64_DLINK_FLAGS) -O0 -flto ## # GCC5 ARM definitions -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100017): https://edk2.groups.io/g/devel/message/100017 Mute This Topic: https://groups.io/mt/96850388/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 00/10] OvmfPkg: add Crypto Driver support
On Fri, 10 Feb 2023 at 09:42, Gerd Hoffmann wrote: > > On Thu, Feb 09, 2023 at 05:46:15PM +0100, Ard Biesheuvel wrote: > > On Thu, 9 Feb 2023 at 11:27, Gerd Hoffmann wrote: > > > > > > Known problem: the NOOPT builds fail due to PEI becoming too big. > > > > > > What is the reason for doing these NOOPT builds? > > > > They are very useful for doing single step debugging with GDB. On ARM, > > I use the NOOPT builds fairly regularly. > > Can LTO be enabled for the NOOPT build? Or depends that on > optimizations being turned on? > With the hunk below applied: -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100016): https://edk2.groups.io/g/devel/message/100016 Mute This Topic: https://groups.io/mt/96850388/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 00/19] Add support for RISC-V virt machine
OvmfPkg: Acked-by: Jiewen Yao > -Original Message- > From: Sunil V L > Sent: Friday, February 10, 2023 8:30 PM > To: devel@edk2.groups.io > Cc: Abner Chang ; Daniel Schaefer > ; Kinney, Michael D ; > Gao, Liming ; Ard Biesheuvel > ; Yao, Jiewen ; Justen, > Jordan L ; Gerd Hoffmann ; > Sami Mujawar ; Leif Lindholm > ; Dong, Eric ; Ni, Ray > ; Kumar, Rahul R ; Liu, Zhiguang > ; Anup Patel ; Heinrich > Schuchardt ; Warkentin, Andrei > > Subject: [edk2-staging/RiscV64QemuVirt PATCH V8 00/19] Add support for RISC- > V virt machine > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 > > Add support for RISC-V qemu virt machine. Most of the changes are migrated > from > edk2-platforms repo and added qemu specific libraries under OvmfPkg. > > The series has passed CI tests (https://github.com/tianocore/edk2/pull/4023) > > These changes are available at: > https://github.com/vlsunil/edk2/tree/RiscV64QemuVirt_V8 > > The series can be tested as per instructions @ > https://github.com/vlsunil/riscv-uefi-edk2-docs/wiki/RISC-V-Qemu-Virt-support > > Changes since V7: > 1) Addressed feedbacks from Mike and Ray. > 2) Added Anrdrei as another reviewer for RiscVVirt > 3) Rebased > 4) Added RB and ACK tags > > Changes since V6: > 1) Took inspiration from IntelTdx and added all RISC-V qemu related > libraries and > modules in OvmfPkg/RiscVVirt instead of directly under > OvmfPkg/Library. Hoping for > quicker review since now it shouldn't affect the existing OvmfPkg > libraries/modules. > 2) Dropped migration of NvVarStoreFormattedLib for now to avoid > MdeModulePkg changes. > Currently RISC-V Qemu doesn't support separate variable flash. So, it > can be taken > as a separate activity in future when required. > 3) Rebased and new CI test request passed > > Changes since V5: > 1) Avoided editing the existing INF files (as per feedback from Ray Ni). > This reduced > several refactor patches. > 2) Moved to PEI less design (as per suggestion from Andrei Warkentin) > 3) Added PciCpuIO2Dxe driver in OvmfPkg. > 4) Removed APRIORI requirement in DSC/FDF infrastructure files. Now > they > are very similar to ArmVirtQemu. > 5) Addressed Heinrich's feedback. > 6) Rebased and added ack tags > > Changes since V4: > 1) Rebased and added ACKs > 2) Dropped few patches related to VirtNorFlashDxe since they are > already taken care by Ard. > > Changes since V3: > 1) Addressed Abner's comments > 2) Changed folder name from Ia32_X64 to Ia32X64 as per latest > guidelines. > 2) Rebased > > Changes since V2: > 1) Fixed issues detected by CI > 2) Added an extra patch to fix up the consumers of > NvVarStoreFormattedLib > > Changes since V1: > 1) Added couple of patches from Ard to optimize the NorFlashDxe in > Ovmf. > Note: There will be a separate patch series in future to update > existing > consumers of NorFlashDxe driver. > 2) Migrated NvVarStoreFormattedLib from EmbeddedPkg to > MdeModulePkg > 3) Created Null instance of the NorFlashPlatformLib library class > 4) Moved NorFlashPlatformLib.h from ArmPlatformPkg > > > Cc: Abner Chang > Cc: Daniel Schaefer > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Ard Biesheuvel > Cc: Jiewen Yao > Cc: Jordan Justen > Cc: Gerd Hoffmann > Cc: Sami Mujawar > Cc: Leif Lindholm > Cc: Eric Dong > Cc: Ray Ni > Cc: Rahul Kumar > Cc: Zhiguang Liu > Cc: Anup Patel > Cc: Heinrich Schuchardt > Cc: Andrei Warkentin > > Sunil V L (19): > MdePkg/Register: Add register definition header files for RISC-V > MdePkg/BaseLib: RISC-V: Add few more helper functions > MdePkg: Add BaseRiscVSbiLib Library for RISC-V > UefiCpuPkg: Add RISCV_EFI_BOOT_PROTOCOL related definitions > UefiCpuPkg: Add BaseRiscV64CpuExceptionHandlerLib > UefiCpuPkg: Add BaseRiscV64CpuTimerLib library > UefiCpuPkg: Add CpuTimerDxeRiscV64 module > UefiCpuPkg: Add CpuDxeRiscV64 module > UefiCpuPkg/UefiCpuPkg.ci.yaml: Ignore RISC-V file > ArmVirtPkg/PlatformHasAcpiDtDxe: Move to OvmfPkg > ArmVirtPkg: Fix up the location of PlatformHasAcpiDtDxe > OvmfPkg/RiscVVirt: Add PlatformBootManagerLib library > OvmfPkg/RiscVVirt: Add PrePiHobListPointerLib library > OvmfPkg/RiscVVirt: Add ResetSystemLib library > OvmfPkg/RiscVVirt: Add VirtNorFlashPlatformLib library > OvmfPkg/RiscVVirt: Add PciCpuIo2Dxe module > OvmfPkg/RiscVVirt: Add SEC module > OvmfPkg/RiscVVirt: Add build files for Qemu Virt platform > Maintainers.txt: Add entry for OvmfPkg/RiscVVirt > > ArmVirtPkg/ArmVirtPkg.dec > |9 - > MdePkg/MdePkg.dec > |4 + > OvmfPkg/OvmfPkg.dec > |7 + > Ue
Re: [edk2-devel] [PATCH v4 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data
Gerd, Firstly, chunk idea allows to split the >64K hob to multiple one without using domain knowledge, that means the split can happen in byte level. It will hurt debuggability a lot: When I exam the HOB list during debugging, it's hard to combine/group the chunk hobs with the same GUID into >64K big hobs. Secondly, Code-First process requires the code be created in edk2-staging repo. It means the code cannot be merged in edk2 trunk. I would like to collect more use cases for >64K hobs and if more such hobs are needed from different domains (not just CPU), I will consider to use the chunk idea. Thanks, Ray > -Original Message- > From: Gerd Hoffmann > Sent: Friday, February 10, 2023 8:32 PM > To: Ni, Ray > Cc: Wu, Jiaxin ; devel@edk2.groups.io; Dong, Eric > ; Zeng, Star ; Laszlo Ersek > ; Kumar, Rahul R > Subject: Re: [PATCH v4 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB > Data > > On Fri, Feb 10, 2023 at 11:56:01AM +, Ni, Ray wrote: > > Gerd, > > That requires changing PI spec > > Yes, but we have > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First- > Process > > > and all HOB consuming logic. > > There is no need to change the existing logic. Code to handle > chunked HOBs can go to new helper functions in HobLib. > > take care, > Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100014): https://edk2.groups.io/g/devel/message/100014 Mute This Topic: https://groups.io/mt/96871372/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v4 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info
On Fri, Feb 10, 2023 at 12:37:23PM +, Ni, Ray wrote: > Gerd, > All the 4 are needed to make sure SMM still works. The new way (HOB present) of handling SMM init will surely require the whole patch series being applied. For the old way (HOB not present) of handling SMM init should be possible to split up into smaller pieces, which each step being individually testable. Specifically the SMI handler reorganization should be possible to split out, and I think the tiling changes too. These are preparing changes reorganizing the code, once they are in place the final patch adding the new code paths to handle the new SMM init should be relatively small. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100013): https://edk2.groups.io/g/devel/message/100013 Mute This Topic: https://groups.io/mt/96871374/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 0/5] Simplify SMM Relocation Process
Jiaxin, I provide separate review comments for each patch. Can you please make sure the copy right year is updated for every file change? I may not emphasize this for each patch. > -Original Message- > From: devel@edk2.groups.io On Behalf Of Wu, Jiaxin > Sent: Friday, February 10, 2023 2:05 PM > To: devel@edk2.groups.io > Subject: [edk2-devel] [PATCH v4 0/5] Simplify SMM Relocation Process > > Existing SMBASE Relocation is in the PiSmmCpuDxeSmm driver, which > will relocate the SMBASE of each processor by setting the SMBASE > field in the saved state map (at offset 7EF8h) to a new value. > The RSM instruction reloads the internal SMBASE register with the > value in SMBASE field when each time it exits SMM. All subsequent > SMI requests will use the new SMBASE to find the starting address > for the SMI handler (at SMBASE + 8000h). > > Due to the default SMBASE for all x86 processors is 0x3, the > APs' 1st SMI for rebase has to be executed one by one to avoid > the CPUs over-writing each other's SMM Save State Area (see > existing SmmRelocateBases() function), which means the next AP has > to wait for the previous AP to finish its 1st SMI, then it can call > into its 1st SMI for rebase via Smi Ipi command, thus leading the > existing SMBASE Relocation has to be running in series. Besides, it > needs very complex code to handle the AP exit semaphore > (mRebased[Index]), which will hook return address of SMM Save State > so that semaphore code can be executed immediately after AP exits > SMM for SMBASE relocation (see existing SemaphoreHook() function). > > This series is to add the new SMM Base HOB for any PEI module to do > the SmBase relocation ahead of PiSmmCpuDxeSmm driver and store the > relocated SmBase address in array for each Processors. When the > SMBASE relocation happens in a PEI module, the PEI module shall > produce the SMM_BASE_HOB in HOB database which tells the > PiSmmCpuDxeSmm driver (runs at a later phase) about the new SMBASE > for each CPU thread. PiSmmCpuDxeSmm driver installs the SMI handler > at the SMM_BASE_HOB.SmBase[Index]+0x8000 for CPU thread Index. When > the HOB doesn't exist, PiSmmCpuDxeSmm driver shall relocate and > program the new SMBASE itself (keep existing SMBASE Relocation way). > > With SMM Base Hob support, PiSmmCpuDxeSmm does not need the RSM > instruction to do the SMBASE Relocation. SMBASE Register for each > processors have already been programmed and all SMBASE address have > recorded in SMM Base Hob. So the same default SMBASE Address > (0x3) will not be used, thus the CPUs over-writing each other's > SMM Save State Area will not happen in PiSmmCpuDxeSmm driver. This > way makes the first SMI init can be executed in parallel and save > boot time on multi-core system. Besides, Semaphore Hook code logic > is also not required, which will greatly simplify the SMBASE > Relocation flow. > > Note: > This is the new way that firmware can program the SMBASE > independently of the RSM instruction. The PEI code performing > this logic will not be open sourced, similarly to other things > that are kept binary-only in the FSP. Due to the register > difference in different vender, and it has not been documented > in the Intel SDM yet, we need a new binary-only interface for > SMM Base HOB. > > Jiaxin Wu (5): > UefiCpuPkg/PiSmmCpuDxeSmm: Fix invalid InitializeMpSyncData call > UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data > UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info > UefiCpuPkg/SmmCpuFeaturesLib: Skip SMBASE configuration > OvmfPkg/SmmCpuFeaturesLib: Check SmBase relocation supported or not > > .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 8 + > .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf| 4 + > UefiCpuPkg/Include/Guid/SmmBaseHob.h | 64 +++ > .../Library/SmmCpuFeaturesLib/CpuFeaturesLib.h | 2 + > .../SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c | 23 ++- > .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf| 4 + > .../SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf | 1 + > UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c | 1 - > .../StandaloneMmCpuFeaturesLib.inf | 4 + > UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 29 +++- > UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 23 +++ > UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c | 191 > - > UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 24 +++ > UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 1 + > UefiCpuPkg/UefiCpuPkg.dec | 3 + > 15 files changed, 332 insertions(+), 50 deletions(-) > create mode 100644 UefiCpuPkg/Include/Guid/SmmBaseHob.h > > -- > 2.16.2.windows.1 > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#100012): https://edk2.groups.io/g/devel/message/100012 Mute This Topic: https://groups.io/mt/96871371/21656 Group Owner
Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 07/19] UefiCpuPkg: Add CpuTimerDxeRiscV64 module
> UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimer.uni | 14 + > UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerExtra.uni | 12 + For the above two file name, better to use the same base name as that of INF file. > -Original Message- > From: devel@edk2.groups.io On Behalf Of Ni, Ray > Sent: Friday, February 10, 2023 8:46 PM > To: Sunil V L ; devel@edk2.groups.io > Cc: Dong, Eric ; Kumar, Rahul R > ; Daniel Schaefer ; Gerd > Hoffmann ; Abner Chang ; > Warkentin, Andrei > Subject: Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 07/19] > UefiCpuPkg: Add CpuTimerDxeRiscV64 module > > Acked-by: Ray Ni > > > -Original Message- > > From: Sunil V L > > Sent: Friday, February 10, 2023 8:30 PM > > To: devel@edk2.groups.io > > Cc: Dong, Eric ; Ni, Ray ; Kumar, > > Rahul R ; Daniel Schaefer > ; > > Gerd Hoffmann ; Abner Chang > ; > > Warkentin, Andrei > > Subject: [edk2-staging/RiscV64QemuVirt PATCH V8 07/19] UefiCpuPkg: Add > > CpuTimerDxeRiscV64 module > > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 > > > > This DXE module initializes the timer interrupt handler > > and installs the Arch Timer protocol. > > > > Cc: Eric Dong > > Cc: Ray Ni > > Cc: Rahul Kumar > > Cc: Daniel Schaefer > > Cc: Gerd Hoffmann > > Signed-off-by: Sunil V L > > Acked-by: Abner Chang > > Reviewed-by: Andrei Warkentin > > --- > > UefiCpuPkg/UefiCpuPkg.dsc| 1 + > > UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf | 51 > > UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h| 177 > > UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c| 294 > > > > UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimer.uni | 14 + > > UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerExtra.uni | 12 + > > 6 files changed, 549 insertions(+) > > > > diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc > > index c511403842b8..aba5ae927586 100644 > > --- a/UefiCpuPkg/UefiCpuPkg.dsc > > +++ b/UefiCpuPkg/UefiCpuPkg.dsc > > @@ -198,6 +198,7 @@ [Components.X64] > > [Components.RISCV64] > > > > > UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExce > > ptionHandlerLib.inf > >UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf > > + UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > > > > [BuildOptions] > >*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES > > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > > b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > > new file mode 100644 > > index ..2c1f9f10e165 > > --- /dev/null > > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > > @@ -0,0 +1,51 @@ > > +## @file > > +# Timer Arch protocol module > > +# > > +# Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights > > reserved. > > +# > > +# SPDX-License-Identifier: BSD-2-Clause-Patent > > +# > > +## > > + > > +[Defines] > > + INF_VERSION= 0x0001001b > > + BASE_NAME = RiscVTimerDxe > > + MODULE_UNI_FILE= RiscVTimer.uni > > + FILE_GUID = 055DDAC6-9142-4013-BF20-FC2E5BC325C9 > > + MODULE_TYPE= DXE_DRIVER > > + VERSION_STRING = 1.0 > > + ENTRY_POINT= TimerDriverInitialize > > +# > > +# The following information is for reference only and not required by the > build > > +# tools. > > +# > > +# VALID_ARCHITECTURES = RISCV64 > > +# > > +[Packages] > > + MdePkg/MdePkg.dec > > + UefiCpuPkg/UefiCpuPkg.dec > > + > > +[LibraryClasses] > > + BaseLib > > + DebugLib > > + IoLib > > + CpuLib > > + UefiBootServicesTableLib > > + UefiDriverEntryPoint > > + > > +[LibraryClasses.RISCV64] > > + RiscVSbiLib > > + > > +[Sources.RISCV64] > > + Timer.h > > + Timer.c > > + > > +[Protocols] > > + gEfiCpuArchProtocolGuid ## CONSUMES > > + gEfiTimerArchProtocolGuid ## PRODUCES > > + > > +[Depex] > > + gEfiCpuArchProtocolGuid > > + > > +[UserExtensions.TianoCore."ExtraFiles"] > > + RiscVTimerExtra.uni > > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h > > b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h > > new file mode 100644 > > index ..586eb0cfadb4 > > --- /dev/null > > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h > > @@ -0,0 +1,177 @@ > > +/** @file > > + RISC-V Timer Architectural Protocol definitions > > + > > + Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights > > reserved. > > + > > + SPDX-License-Identifier: BSD-2-Clause-Patent > > + > > +**/ > > + > > +#ifndef TIMER_H_ > > +#define TIMER_H_ > > + > > +#include > > + > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > + > > +// > > +// RISC-V use 100us timer. > > +// The default timer tick duration is set to 10 ms = 10 * 1000 * 10 100 ns > > units > > +// > > +#define DEFAULT_TIMER_TICK_DURATION 10 > > + > > +extern VOID > > +
Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 05/19] UefiCpuPkg: Add BaseRiscV64CpuExceptionHandlerLib
Acked-by: Ray Ni > -Original Message- > From: devel@edk2.groups.io On Behalf Of Sunil V L > Sent: Friday, February 10, 2023 8:30 PM > To: devel@edk2.groups.io > Cc: Dong, Eric ; Ni, Ray ; Kumar, > Rahul R ; Daniel Schaefer ; > Abner Chang ; Gerd Hoffmann ; > Warkentin, Andrei > Subject: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 05/19] > UefiCpuPkg: Add BaseRiscV64CpuExceptionHandlerLib > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 > > Add Cpu Exception Handler library for RISC-V. This is copied > from edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVExceptionLib > > Cc: Eric Dong > Cc: Ray Ni > Cc: Rahul Kumar > Cc: Daniel Schaefer > Cc: Abner Chang > Cc: Gerd Hoffmann > Signed-off-by: Sunil V L > Acked-by: Abner Chang > Reviewed-by: Andrei Warkentin > --- > UefiCpuPkg/UefiCpuPkg.dsc > | 3 + > > UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExce > ptionHandlerLib.inf | 42 +++ > > UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandler > Lib.h | 116 + > > UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandler > Lib.c | 133 > > UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExce > ptionHandlerLib.uni | 13 ++ > > UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/SupervisorTrapHandle > r.S | 105 > 6 files changed, 412 insertions(+) > > diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc > index f9a46089d2c7..35e66d93efa6 100644 > --- a/UefiCpuPkg/UefiCpuPkg.dsc > +++ b/UefiCpuPkg/UefiCpuPkg.dsc > @@ -195,5 +195,8 @@ [Components.IA32, Components.X64] > [Components.X64] > > UefiCpuPkg/Library/CpuExceptionHandlerLib/UnitTest/DxeCpuExceptionHandler > LibUnitTest.inf > > +[Components.RISCV64] > + > UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExce > ptionHandlerLib.inf > + > [BuildOptions] >*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES > diff --git > a/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExc > eptionHandlerLib.inf > b/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExc > eptionHandlerLib.inf > new file mode 100644 > index ..d80462943645 > --- /dev/null > +++ > b/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExc > eptionHandlerLib.inf > @@ -0,0 +1,42 @@ > +## @file > +# RISC-V CPU Exception Handler Library > +# > +# Copyright (c) 2022-2023, Ventana Micro Systems Inc. All rights > reserved. > +# > +# SPDX-License-Identifier: BSD-2-Clause-Patent > +# > +## > + > +[Defines] > + INF_VERSION= 0x0001001B > + BASE_NAME = BaseRiscV64CpuExceptionHandlerLib > + MODULE_UNI_FILE= BaseRiscV64CpuExceptionHandlerLib.uni > + FILE_GUID = 6AB0D5FD-E615-45A3-9374-E284FB061FC9 > + MODULE_TYPE= BASE > + VERSION_STRING = 1.0 > + LIBRARY_CLASS = CpuExceptionHandlerLib > + > +# > +# The following information is for reference only and not required by the > build > tools. > +# > +# VALID_ARCHITECTURES = RISCV64 > +# > + > +[Sources] > + SupervisorTrapHandler.S > + CpuExceptionHandlerLib.c > + CpuExceptionHandlerLib.h > + > +[Packages] > + MdePkg/MdePkg.dec > + MdeModulePkg/MdeModulePkg.dec > + UefiCpuPkg/UefiCpuPkg.dec > + > +[LibraryClasses] > + BaseLib > + SerialPortLib > + PrintLib > + SynchronizationLib > + PeCoffGetEntryPointLib > + MemoryAllocationLib > + DebugLib > diff --git > a/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandl > erLib.h > b/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandl > erLib.h > new file mode 100644 > index ..30f47e87552b > --- /dev/null > +++ > b/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandl > erLib.h > @@ -0,0 +1,116 @@ > +/** @file > + > + RISC-V Exception Handler library definition file. > + > + Copyright (c) 2019-2022, Hewlett Packard Enterprise Development LP. All > rights reserved. > + > + SPDX-License-Identifier: BSD-2-Clause-Patent > + > +**/ > + > +#ifndef RISCV_CPU_EXECPTION_HANDLER_LIB_H_ > +#define RISCV_CPU_EXECPTION_HANDLER_LIB_H_ > + > +#include > + > +/** > + Trap Handler for S-mode > + > +**/ > +VOID > +SupervisorModeTrap ( > + VOID > + ); > + > +// > +// Index of SMode trap register > +// > +#define SMODE_TRAP_REGS_zero 0 > +#define SMODE_TRAP_REGS_ra 1 > +#define SMODE_TRAP_REGS_sp 2 > +#define SMODE_TRAP_REGS_gp 3 > +#define SMODE_TRAP_REGS_tp 4 > +#define SMODE_TRAP_REGS_t0 5 > +#define SMODE_TRAP_REGS_t1 6 > +#define SMODE_TRAP_REGS_t2 7 > +#define SMODE_TRAP_REGS_s0 8 > +#define SMODE_TRAP_REGS_s1 9 > +#define SMODE_TRAP_REGS_a0 10 > +#defi
Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg: Contiguous memory allocation and code clean-up.
> > Hi, > > > 3) The special case you have to handle is not running on a AMD > > Processor, but AmdSev being active (i.e. UseSevEsAPMethod == True). > > Otherwise it should be just standard Ia32 and X64, there should be no > > need to check whenever you are running on a AMD processor. > > > > I understand your point, but for both cases (check AmdSev, standard > > Ia32 and X64), AMD related code will be changed. We would like to keep > > the original implementation as much as possible. > > Well, the original implementation never checks for an AMD Processor, it > only checks whenever SEV-ES is active (and sets UseSevEsAPMethod in that > case). So why you are adding that check? Gerd, I understand that the patch tries to keep AMD flow as the original to avoid breaking in AMD environment, no matter with or without SEV-ES. Yuanhao, I suggest you work with Tom later in a separate patch to put AMD64 non-SEV CPU in 64bit paging mode as well, if Tom can help to test. Thanks, Ray -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#19): https://edk2.groups.io/g/devel/message/19 Mute This Topic: https://groups.io/mt/96807120/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 06/19] UefiCpuPkg: Add BaseRiscV64CpuTimerLib library
Acked-by: Ray Ni
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Sunil V L
> Sent: Friday, February 10, 2023 8:30 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Kumar,
> Rahul R ; Daniel Schaefer ;
> Abner Chang ; Gerd Hoffmann ;
> Warkentin, Andrei
> Subject: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 06/19]
> UefiCpuPkg: Add BaseRiscV64CpuTimerLib library
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
>
> Add the RISC-V instance of the TimerLib.
>
> This is mostly copied from
> edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVTimerLib
>
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Rahul Kumar
> Cc: Daniel Schaefer
> Cc: Abner Chang
> Cc: Gerd Hoffmann
> Signed-off-by: Sunil V L
> Acked-by: Abner Chang
> Reviewed-by: Andrei Warkentin
> ---
> UefiCpuPkg/UefiCpuPkg.dsc| 1 +
> UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf | 33
>
> UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/CpuTimerLib.c | 199
>
> UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.uni |
> 14 ++
> 4 files changed, 247 insertions(+)
>
> diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
> index 35e66d93efa6..c511403842b8 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dsc
> +++ b/UefiCpuPkg/UefiCpuPkg.dsc
> @@ -197,6 +197,7 @@ [Components.X64]
>
> [Components.RISCV64]
>
> UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExce
> ptionHandlerLib.inf
> + UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
>
> [BuildOptions]
>*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
> diff --git
> a/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
> b/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
> new file mode 100644
> index ..3d5eaa41716d
> --- /dev/null
> +++
> b/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
> @@ -0,0 +1,33 @@
> +## @file
> +# RISC-V Base CPU Timer Library Instance
> +#
> +# Copyright (c) 2016 - 2019, Hewlett Packard Enterprise Development LP. All
> rights reserved.
> +# Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved.
> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> + INF_VERSION= 0x0001001B
> + BASE_NAME = BaseRisV64CpuTimerLib
> + FILE_GUID = B635A600-EA24-4199-88E8-5761EEA96A51
> + MODULE_TYPE= BASE
> + VERSION_STRING = 1.0
> + LIBRARY_CLASS = TimerLib
> + MODULE_UNI_FILE= BaseRisV64CpuTimerLib.uni
> +
> +[Sources]
> + CpuTimerLib.c
> +
> +[Packages]
> + MdePkg/MdePkg.dec
> + UefiCpuPkg/UefiCpuPkg.dec
> +
> +[LibraryClasses]
> + BaseLib
> + PcdLib
> + DebugLib
> +
> +[Pcd]
> + gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency ##
> CONSUMES
> diff --git a/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/CpuTimerLib.c
> b/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/CpuTimerLib.c
> new file mode 100644
> index ..9c8efc0f3530
> --- /dev/null
> +++ b/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/CpuTimerLib.c
> @@ -0,0 +1,199 @@
> +/** @file
> + RISC-V instance of Timer Library.
> +
> + Copyright (c) 2016 - 2022, Hewlett Packard Enterprise Development LP. All
> rights reserved.
> +
> + SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + Stalls the CPU for at least the given number of ticks.
> +
> + Stalls the CPU for at least the given number of ticks. It's invoked by
> + MicroSecondDelay() and NanoSecondDelay().
> +
> + @param Delay A period of time to delay in ticks.
> +
> +**/
> +VOID
> +InternalRiscVTimerDelay (
> + IN UINT32 Delay
> + )
> +{
> + UINT32 Ticks;
> + UINT32 Times;
> +
> + Times = Delay >> (RISCV_TIMER_COMPARE_BITS - 2);
> + Delay &= ((1 << (RISCV_TIMER_COMPARE_BITS - 2)) - 1);
> + do {
> +//
> +// The target timer count is calculated here
> +//
> +Ticks = RiscVReadTimer () + Delay;
> +Delay = 1 << (RISCV_TIMER_COMPARE_BITS - 2);
> +while (((Ticks - RiscVReadTimer ()) & (1 << (RISCV_TIMER_COMPARE_BITS -
> 1))) == 0) {
> + CpuPause ();
> +}
> + } while (Times-- > 0);
> +}
> +
> +/**
> + Stalls the CPU for at least the given number of microseconds.
> +
> + Stalls the CPU for the number of microseconds specified by MicroSeconds.
> +
> + @param MicroSeconds The minimum number of microseconds to delay.
> +
> + @return MicroSeconds
> +
> +**/
> +UINTN
> +EFIAPI
> +MicroSecondDelay (
> + IN UINTN MicroSeconds
> + )
> +{
> + InternalRiscVTimerDelay (
> +(UINT32)DivU64x32 (
> + MultU64x32 (
> +MicroSeconds,
> +PcdGet64 (PcdCpuCoreCrystalClockFrequency)
> +),
> + 10
Re: [edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 07/19] UefiCpuPkg: Add CpuTimerDxeRiscV64 module
Acked-by: Ray Ni > -Original Message- > From: Sunil V L > Sent: Friday, February 10, 2023 8:30 PM > To: devel@edk2.groups.io > Cc: Dong, Eric ; Ni, Ray ; Kumar, > Rahul R ; Daniel Schaefer ; > Gerd Hoffmann ; Abner Chang ; > Warkentin, Andrei > Subject: [edk2-staging/RiscV64QemuVirt PATCH V8 07/19] UefiCpuPkg: Add > CpuTimerDxeRiscV64 module > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 > > This DXE module initializes the timer interrupt handler > and installs the Arch Timer protocol. > > Cc: Eric Dong > Cc: Ray Ni > Cc: Rahul Kumar > Cc: Daniel Schaefer > Cc: Gerd Hoffmann > Signed-off-by: Sunil V L > Acked-by: Abner Chang > Reviewed-by: Andrei Warkentin > --- > UefiCpuPkg/UefiCpuPkg.dsc| 1 + > UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf | 51 > UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h| 177 > UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c| 294 > > UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimer.uni | 14 + > UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerExtra.uni | 12 + > 6 files changed, 549 insertions(+) > > diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc > index c511403842b8..aba5ae927586 100644 > --- a/UefiCpuPkg/UefiCpuPkg.dsc > +++ b/UefiCpuPkg/UefiCpuPkg.dsc > @@ -198,6 +198,7 @@ [Components.X64] > [Components.RISCV64] > > UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExce > ptionHandlerLib.inf >UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf > + UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > > [BuildOptions] >*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > new file mode 100644 > index ..2c1f9f10e165 > --- /dev/null > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf > @@ -0,0 +1,51 @@ > +## @file > +# Timer Arch protocol module > +# > +# Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights > reserved. > +# > +# SPDX-License-Identifier: BSD-2-Clause-Patent > +# > +## > + > +[Defines] > + INF_VERSION= 0x0001001b > + BASE_NAME = RiscVTimerDxe > + MODULE_UNI_FILE= RiscVTimer.uni > + FILE_GUID = 055DDAC6-9142-4013-BF20-FC2E5BC325C9 > + MODULE_TYPE= DXE_DRIVER > + VERSION_STRING = 1.0 > + ENTRY_POINT= TimerDriverInitialize > +# > +# The following information is for reference only and not required by the > build > +# tools. > +# > +# VALID_ARCHITECTURES = RISCV64 > +# > +[Packages] > + MdePkg/MdePkg.dec > + UefiCpuPkg/UefiCpuPkg.dec > + > +[LibraryClasses] > + BaseLib > + DebugLib > + IoLib > + CpuLib > + UefiBootServicesTableLib > + UefiDriverEntryPoint > + > +[LibraryClasses.RISCV64] > + RiscVSbiLib > + > +[Sources.RISCV64] > + Timer.h > + Timer.c > + > +[Protocols] > + gEfiCpuArchProtocolGuid ## CONSUMES > + gEfiTimerArchProtocolGuid ## PRODUCES > + > +[Depex] > + gEfiCpuArchProtocolGuid > + > +[UserExtensions.TianoCore."ExtraFiles"] > + RiscVTimerExtra.uni > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h > b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h > new file mode 100644 > index ..586eb0cfadb4 > --- /dev/null > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h > @@ -0,0 +1,177 @@ > +/** @file > + RISC-V Timer Architectural Protocol definitions > + > + Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights > reserved. > + > + SPDX-License-Identifier: BSD-2-Clause-Patent > + > +**/ > + > +#ifndef TIMER_H_ > +#define TIMER_H_ > + > +#include > + > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +// > +// RISC-V use 100us timer. > +// The default timer tick duration is set to 10 ms = 10 * 1000 * 10 100 ns > units > +// > +#define DEFAULT_TIMER_TICK_DURATION 10 > + > +extern VOID > +RiscvSetTimerPeriod ( > + UINT32 TimerPeriod > + ); > + > +// > +// Function Prototypes > +// > + > +/** > + Initialize the Timer Architectural Protocol driver > + > + @param ImageHandle ImageHandle of the loaded driver > + @param SystemTable Pointer to the System Table > + > + @retval EFI_SUCCESSTimer Architectural Protocol created > + @retval EFI_OUT_OF_RESOURCES Not enough resources available to > initialize driver. > + @retval EFI_DEVICE_ERROR A device error occured attempting to > initialize > the driver. > + > +**/ > +EFI_STATUS > +EFIAPI > +TimerDriverInitialize ( > + IN EFI_HANDLEImageHandle, > + IN EFI_SYSTEM_TABLE *SystemTable > + ) > +; > + > +/** > + > + This function adjusts the period of timer interrupts to the value specified > + by TimerPeriod. If the timer period is updated, then the selected timer > + period is store
Re: [edk2-devel] [PATCH v4 4/5] UefiCpuPkg/SmmCpuFeaturesLib: Skip SMBASE configuration
Reviewed-by: Ray Ni
-- but please update the copyright year.
> -Original Message-
> From: Wu, Jiaxin
> Sent: Friday, February 10, 2023 2:05 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Zeng, Star
> ; Laszlo Ersek ; Gerd Hoffmann
> ; Kumar, Rahul R
> Subject: [PATCH v4 4/5] UefiCpuPkg/SmmCpuFeaturesLib: Skip SMBASE
> configuration
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337
>
> This patch is to avoid configure SMBASE if SmBase relocation has been
> done. If gSmmBaseHobGuid found, means SmBase info has been relocated
> and recorded in the SmBase array. No need to do the relocation in
> SmmCpuFeaturesInitializeProcessor().
>
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Zeng Star
> Cc: Laszlo Ersek
> Cc: Gerd Hoffmann
> Cc: Rahul Kumar
> Signed-off-by: Jiaxin Wu
> ---
> .../Library/SmmCpuFeaturesLib/CpuFeaturesLib.h | 2 ++
> .../SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c | 23
> +++---
> .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf| 4
> .../SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf | 1 +
> UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmStm.c | 1 -
> .../StandaloneMmCpuFeaturesLib.inf | 4
> 6 files changed, 31 insertions(+), 4 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/CpuFeaturesLib.h
> b/UefiCpuPkg/Library/SmmCpuFeaturesLib/CpuFeaturesLib.h
> index fd3e902547..c2e4fbe96b 100644
> --- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/CpuFeaturesLib.h
> +++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/CpuFeaturesLib.h
> @@ -7,15 +7,17 @@
> **/
>
> #ifndef CPU_FEATURES_LIB_H_
> #define CPU_FEATURES_LIB_H_
>
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
>
> /**
>Performs library initialization.
>
>This initialization function contains common functionality shared betwen
> all
> diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c
> b/UefiCpuPkg/Library/SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c
> index d5eaaa7a99..7c3836286b 100644
> --- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c
> +++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/IntelSmmCpuFeaturesLib.c
> @@ -36,10 +36,16 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> // Set default value to assume IA-32 Architectural MSRs are used
> //
> UINT32 mSmrrPhysBaseMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE;
> UINT32 mSmrrPhysMaskMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK;
>
> +//
> +// Indicate SmBase for each Processors has been relocated or not. If TRUE,
> +// means no need to do the relocation in SmmCpuFeaturesInitializeProcessor().
> +//
> +BOOLEAN mSmmCpuFeaturesSmmRelocated;
> +
> //
> // Set default value to assume MTRRs need to be configured on each SMI
> //
> BOOLEAN mNeedConfigureMtrrs = TRUE;
>
> @@ -142,10 +148,16 @@ CpuFeaturesLibInitialization (
>//
>// Allocate array for state of SMRR enable on all CPUs
>//
>mSmrrEnabled = (BOOLEAN *)AllocatePool (sizeof (BOOLEAN) *
> GetCpuMaxLogicalProcessorNumber ());
>ASSERT (mSmrrEnabled != NULL);
> +
> + //
> + // If gSmmBaseHobGuid found, means SmBase info has been relocated and
> recorded
> + // in the SmBase array.
> + //
> + mSmmCpuFeaturesSmmRelocated = (BOOLEAN)(GetFirstGuidHob
> (&gSmmBaseHobGuid) != NULL);
> }
>
> /**
>Called during the very first SMI into System Management Mode to initialize
>CPU features, including SMBASE, for the currently executing CPU. Since
> this
> @@ -185,14 +197,19 @@ SmmCpuFeaturesInitializeProcessor (
>UINT32RegEdx;
>UINTN FamilyId;
>UINTN ModelId;
>
>//
> - // Configure SMBASE.
> + // No need to configure SMBASE if SmBase relocation has been done.
>//
> - CpuState = (SMRAM_SAVE_STATE_MAP
> *)(UINTN)(SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET);
> - CpuState->x86.SMBASE = (UINT32)CpuHotPlugData->SmBase[CpuIndex];
> + if (!mSmmCpuFeaturesSmmRelocated) {
> +//
> +// Configure SMBASE.
> +//
> +CpuState = (SMRAM_SAVE_STATE_MAP
> *)(UINTN)(SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET);
> +CpuState->x86.SMBASE = (UINT32)CpuHotPlugData->SmBase[CpuIndex];
> + }
>
>//
>// Intel(R) 64 and IA-32 Architectures Software Developer's Manual
>// Volume 3C, Section 35.2 MSRs in the Intel(R) Core(TM) 2 Processor Family
>//
> diff --git a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> index 9ac7dde78f..280a4b8b39 100644
> --- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> +++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> @@ -31,10 +31,14 @@
> [LibraryClasses]
>BaseLib
>PcdLib
>MemoryAllocationLib
>DebugLib
> + HobLib
> +
> +[Guids]
> + gSmmBaseHobGuid## CONSUMES
>
> [Pcd]
>gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
Re: [edk2-devel] [PATCH v4 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info
Gerd, All the 4 are needed to make sure SMM still works. Only having one will cause system hang. I think Jiaxin's commit message is to describe what has been done to enable the single feature: Early SMM rebase. Thanks, Ray > -Original Message- > From: devel@edk2.groups.io On Behalf Of Gerd > Hoffmann > Sent: Friday, February 10, 2023 7:27 PM > To: Wu, Jiaxin > Cc: devel@edk2.groups.io; Dong, Eric ; Ni, Ray > ; Zeng, Star ; Laszlo Ersek > ; Kumar, Rahul R > Subject: Re: [edk2-devel] [PATCH v4 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: > Consume SMM Base Hob for SmBase info > > > Mainly changes as below: > > * Assume the biggest possibility of tile size is 8k. > > * Combine 2 SMIs (gcSmmInitTemplate & gcSmiHandlerTemplate) into one > > (gcSmiHandlerTemplate), the new SMI handler needs to run to 2 paths: > > one to SmmCpuFeaturesInitializeProcessor(), the other to SMM Core > > Entry Point. > > * Issue SMI IPI (All Excluding Self SMM IPI + BSP SMM IPI) for first > > SMI init before normal SMI sources happen. > > * Call SmmCpuFeaturesInitializeProcessor() in parallel. > > Four changes in a single patch. Please split them up. > > thanks, > Gerd > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#15): https://edk2.groups.io/g/devel/message/15 Mute This Topic: https://groups.io/mt/96871374/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v4 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info
> + ZeroMem (mSmmInitialized, sizeof (BOOLEAN) * mMaxNumberOfCpus);
> ...
> + for (Index = 0; Index < mNumberOfCpus; Index++) {
> +while (mSmmInitialized[Index] == FALSE) {
> +}
Above code sets the BOOLEAN array to all FALSE.
Then polling on the array to be all TRUE.
We need to add "volatile" to the mSmmInitialized to tell
the compiler not to optimize the code but always check the
memory content.
A better way is to use compiler barrier but there is no
edk2 lib API to wrap it for different compilers
Let's just use "volatile" for now.
Thanks,
Ray
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#14): https://edk2.groups.io/g/devel/message/14
Mute This Topic: https://groups.io/mt/96871374/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 2/2] NetworkPkg/HttpDxe: fix driver binding start issue.
When failure happens in HttpDxeStart, the error handling code
release the memory buffer but it does not uninstall HTTP service
bindnig protocol. As the result, application can still locate
this protocol and invoke service binding fucntions in released
memory pool.
Signed-off-by: Nickle Wang
Cc: Maciej Rabeda
Cc: Siyuan Fu
Cc: Abner Chang
Cc: Igor Kulchytskyy
Cc: Nick Ramirez
---
NetworkPkg/HttpDxe/HttpDriver.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/NetworkPkg/HttpDxe/HttpDriver.c b/NetworkPkg/HttpDxe/HttpDriver.c
index 5d918d3c4d..f6d1263cad 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.c
+++ b/NetworkPkg/HttpDxe/HttpDriver.c
@@ -3,6 +3,7 @@
Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
(C) Copyright 2016 Hewlett Packard Enterprise Development LP
+ Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -464,8 +465,16 @@ ON_ERROR:
if (HttpService != NULL) {
HttpCleanService (HttpService, UsingIpv6);
-if ((HttpService->Tcp4ChildHandle == NULL) &&
(HttpService->Tcp6ChildHandle == NULL)) {
- FreePool (HttpService);
+Status = gBS->UninstallMultipleProtocolInterfaces (
+&ControllerHandle,
+&gEfiHttpServiceBindingProtocolGuid,
+&HttpService->ServiceBinding,
+NULL
+);
+if (!EFI_ERROR (Status)) {
+ if ((HttpService->Tcp4ChildHandle == NULL) &&
(HttpService->Tcp6ChildHandle == NULL)) {
+FreePool (HttpService);
+ }
}
}
--
2.39.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#13): https://edk2.groups.io/g/devel/message/13
Mute This Topic: https://groups.io/mt/96875048/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH 1/2] RedfishPkg/RedfishRestExDxe: fix driver binding stop issue.
RedfishRestExDriverBindingStop() does not uninstall service
binding protocol and release resource because:
- RestExDestroyChildEntryInHandleBuffer() does not remove entry
when NetIsInHandleBuffer() return false. So the linked list
is not empty.
- When NumberOfChildrenis 0, binding stop function return in the
NetLibGetNicHandle() condition check and never reach to the reset
of code in driver binding stop.
Signed-off-by: Nickle Wang
Cc: Abner Chang
Cc: Igor Kulchytskyy
Cc: Nick Ramirez
---
RedfishPkg/RedfishRestExDxe/RedfishRestExDriver.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/RedfishPkg/RedfishRestExDxe/RedfishRestExDriver.c
b/RedfishPkg/RedfishRestExDxe/RedfishRestExDriver.c
index ad65ae213a..7036aed426 100644
--- a/RedfishPkg/RedfishRestExDxe/RedfishRestExDriver.c
+++ b/RedfishPkg/RedfishRestExDxe/RedfishRestExDriver.c
@@ -3,6 +3,7 @@
Copyright (c) 2019, Intel Corporation. All rights reserved.
(C) Copyright 2020 Hewlett Packard Enterprise Development LP
+ Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -57,6 +58,7 @@ RestExDestroyChildEntryInHandleBuffer (
ChildHandleBuffer = ((RESTEX_DESTROY_CHILD_IN_HANDLE_BUF_CONTEXT
*)Context)->ChildHandleBuffer;
if (!NetIsInHandleBuffer (Instance->ChildHandle, NumberOfChildren,
ChildHandleBuffer)) {
+RemoveEntryList (&Instance->Link);
return EFI_SUCCESS;
}
@@ -563,7 +565,7 @@ RedfishRestExDriverBindingStop (
);
}
- if ((NumberOfChildren == 0) && IsListEmpty (&RestExSb->RestExChildrenList)) {
+ if (IsListEmpty (&RestExSb->RestExChildrenList)) {
gBS->UninstallProtocolInterface (
NicHandle,
&gEfiRestExServiceBindingProtocolGuid,
--
2.39.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#12): https://edk2.groups.io/g/devel/message/12
Mute This Topic: https://groups.io/mt/96875045/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 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data
On Fri, Feb 10, 2023 at 11:56:01AM +, Ni, Ray wrote: > Gerd, > That requires changing PI spec Yes, but we have https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First-Process > and all HOB consuming logic. There is no need to change the existing logic. Code to handle chunked HOBs can go to new helper functions in HobLib. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#11): https://edk2.groups.io/g/devel/message/11 Mute This Topic: https://groups.io/mt/96871372/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 18/19] OvmfPkg/RiscVVirt: Add build files for Qemu Virt platform
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 Add infrastructure files to build edk2 for RISC-V qemu virt machine. - It follows PEI less design. - EDK2 for qemu virt is booted in S-mode as a payload for M-mode FW - Leveraged from ArmVirtQemu Cc: Ard Biesheuvel Cc: Jiewen Yao Cc: Jordan Justen Cc: Gerd Hoffmann Signed-off-by: Sunil V L Acked-by: Abner Chang Reviewed-by: Andrei Warkentin --- OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 336 + OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 504 OvmfPkg/RiscVVirt/RiscVVirtQemu.fdf | 306 OvmfPkg/RiscVVirt/RiscVVirt.fdf.inc | 41 ++ OvmfPkg/RiscVVirt/VarStore.fdf.inc | 79 +++ 5 files changed, 1266 insertions(+) diff --git a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc new file mode 100644 index ..731f54f73f81 --- /dev/null +++ b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc @@ -0,0 +1,336 @@ +# +# Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved. +# Copyright (c) 2011 - 2022, ARM Limited. All rights reserved. +# Copyright (c) 2014, Linaro Limited. All rights reserved. +# Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved. +# Copyright (c) Microsoft Corporation. +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +# + +[Defines] + DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x8047 + +[LibraryClasses.common] +!ifdef $(SOURCE_DEBUG_ENABLE) + PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf + DebugCommunicationLib|SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommunicationLibSerialPort.inf +!else + PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf + DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf + DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf +!endif +!if $(DEBUG_ON_SERIAL_PORT) == TRUE + DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf +!else + DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf +!endif + DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf + PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf + BaseLib|MdePkg/Library/BaseLib/BaseLib.inf + SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf + BmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf + SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf + PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf + PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf + PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf + IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf + UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf + CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf + CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf + UefiLib|MdePkg/Library/UefiLib/UefiLib.inf + HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf + UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf + DevicePathLib|MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf + UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf + DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf + DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf + UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf + UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf + HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf + UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf + SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf + ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf + ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf + PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf + UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf + OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf + OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf + PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf + + # + # Ramdisk Requirements + # + FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf + + # Allow dynamic PCDs + # + + BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf + + # Networking Requirements +!include NetworkPkg/NetworkLibs.dsc.inc +!if $(NETWORK_TLS_ENABLE) == TRUE + TlsLib|Cry
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 19/19] Maintainers.txt: Add entry for OvmfPkg/RiscVVirt
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 RiscVVirt is created to support EDK2 for RISC-V qemu virt machine platform. Add maintainer entries. Cc: Andrew Fish Cc: Leif Lindholm Cc: Michael D Kinney Signed-off-by: Sunil V L Reviewed-by: Andrei Warkentin Reviewed-by: Jiewen Yao Reviewed-by: Michael D Kinney --- Maintainers.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Maintainers.txt b/Maintainers.txt index 68f603b48398..af723cfaadc8 100644 --- a/Maintainers.txt +++ b/Maintainers.txt @@ -539,6 +539,11 @@ F: OvmfPkg/XenResetVector/ R: Anthony Perard [tperard] R: Julien Grall [jgrall] +OvmfPkg: RISC-V Qemu Virt Platform +F: OvmfPkg/RiscVVirt +R: Sunil V L [vlsunil] +R: Andrei Warkentin [andreiw] + PcAtChipsetPkg F: PcAtChipsetPkg/ W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#10): https://edk2.groups.io/g/devel/message/10 Mute This Topic: https://groups.io/mt/96875003/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 17/19] OvmfPkg/RiscVVirt: Add SEC module
Add the SEC module for RISC-V Qemu virt machine support. It uses the PEI less design. Cc: Ard Biesheuvel Cc: Jiewen Yao Cc: Jordan Justen Cc: Gerd Hoffmann Signed-off-by: Sunil V L Acked-by: Abner Chang Reviewed-by: Andrei Warkentin --- OvmfPkg/RiscVVirt/Sec/SecMain.inf | 66 + OvmfPkg/RiscVVirt/Sec/SecMain.h | 102 OvmfPkg/RiscVVirt/Sec/Cpu.c | 33 +++ OvmfPkg/RiscVVirt/Sec/Memory.c| 263 OvmfPkg/RiscVVirt/Sec/Platform.c | 84 +++ OvmfPkg/RiscVVirt/Sec/SecMain.c | 104 OvmfPkg/RiscVVirt/Sec/SecEntry.S | 21 ++ 7 files changed, 673 insertions(+) diff --git a/OvmfPkg/RiscVVirt/Sec/SecMain.inf b/OvmfPkg/RiscVVirt/Sec/SecMain.inf new file mode 100644 index ..aed35d3af596 --- /dev/null +++ b/OvmfPkg/RiscVVirt/Sec/SecMain.inf @@ -0,0 +1,66 @@ +## @file +# SEC Driver for RISC-V +# +# Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved. +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +[Defines] + INF_VERSION= 0x0001001B + BASE_NAME = SecMainRiscV64 + FILE_GUID = 16740C0A-AA84-4F62-A06D-AE328057AE07 + MODULE_TYPE= SEC + VERSION_STRING = 1.0 + ENTRY_POINT= SecMain + +# +# The following information is for reference only and not required by the build tools. +# +# VALID_ARCHITECTURES = RISCV64 +# + +[Sources] + SecEntry.S + SecMain.c + SecMain.h + Cpu.c + Memory.c + Platform.c + +[Packages] + MdePkg/MdePkg.dec + MdeModulePkg/MdeModulePkg.dec + UefiCpuPkg/UefiCpuPkg.dec + OvmfPkg/OvmfPkg.dec + EmbeddedPkg/EmbeddedPkg.dec + +[LibraryClasses] + BaseLib + DebugLib + PcdLib + IoLib + PeCoffLib + LzmaDecompressLib + RiscVSbiLib + PrePiLib + FdtLib + MemoryAllocationLib + HobLib + +[Ppis] + gEfiTemporaryRamSupportPpiGuid# PPI ALWAYS_PRODUCED + gEfiTemporaryRamDonePpiGuid ## PRODUCES + +[Pcd] + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress + +[Guids] + gFdtHobGuid diff --git a/OvmfPkg/RiscVVirt/Sec/SecMain.h b/OvmfPkg/RiscVVirt/Sec/SecMain.h new file mode 100644 index ..83a8058efe40 --- /dev/null +++ b/OvmfPkg/RiscVVirt/Sec/SecMain.h @@ -0,0 +1,102 @@ +/** @file + Master header file for SecCore. + + Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved. + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#ifndef SEC_MAIN_H_ +#define SEC_MAIN_H_ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/** + Entry point to the C language phase of SEC. After the SEC assembly + code has initialized some temporary memory and set up the stack, + the control is transferred to this function. + + @param SizeOfRam Size of the temporary memory available for use. + @param TempRamBase Base address of temporary ram + @param BootFirmwareVolume Base address of the Boot Firmware Volume. +**/ +VOID +NORETURN +EFIAPI +SecStartup ( + IN UINTN BootHartId, + IN VOID *DeviceTreeAddress + ); + +/** + Auto-generated function that calls the library constructors for all of the module's + dependent libraries. This function must be called by the SEC Core once a stack has + been established. + +**/ +VOID +EFIAPI +ProcessLibraryConstructorList ( + VOID + ); + +/** + Perform Platform PEIM initialization. + + @return EFI_SUCCESS The platform initialized successfully. + @retval Others- As the error code indicates + +**/ +EFI_STATUS +EFIAPI +PlatformPeimInitialization ( + VOID + ); + +/** + Perform Memory PEIM initialization. + + @return EFI_SUCCESS The platform initialized successfully. + @retval Others- As the error code indicates + +**/ +EFI_STATUS +EFIAPI +MemoryPeimInitialization ( + VOID + ); + +/** + Perform CPU PEIM initialization. + + @return EFI_SUCCESS The platform initialized successfully. + @retval Others- As the error code indicates + +**/ +EFI_STATUS +EFIAPI +CpuPeimInitialization ( + VOID + ); + +#endif diff --git a/OvmfPkg/RiscVVirt/Sec/Cpu.c b/OvmfPkg/RiscVVirt/Sec/Cpu.c new file mode 100644 index ..2c16df697e37 --- /dev/null +++ b/OvmfPkg/RiscVVirt/Sec/Cpu.c @@ -0,0 +1,33 @@ +/** @file +The library call to pass the device tree to DXE via HOB. + +Copyright (c) 2021, Hewlett Packard Enterprise Development LP. All rights reserved. + +SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +// + The package level
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 16/19] OvmfPkg/RiscVVirt: Add PciCpuIo2Dxe module
Add PciCpuIo2Dxe driver to implement EFI_CPU_IO2_PROTOCOL
to add the translation for IO access. This is copied from
ArmPciCpuIo2Dxe driver.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
Signed-off-by: Sunil V L
Acked-by: Abner Chang
Reviewed-by: Andrei Warkentin
---
OvmfPkg/RiscVVirt/PciCpuIo2Dxe/PciCpuIo2Dxe.inf | 48 ++
OvmfPkg/RiscVVirt/PciCpuIo2Dxe/PciCpuIo2Dxe.c | 557
2 files changed, 605 insertions(+)
diff --git a/OvmfPkg/RiscVVirt/PciCpuIo2Dxe/PciCpuIo2Dxe.inf
b/OvmfPkg/RiscVVirt/PciCpuIo2Dxe/PciCpuIo2Dxe.inf
new file mode 100644
index ..4f78cfa4067b
--- /dev/null
+++ b/OvmfPkg/RiscVVirt/PciCpuIo2Dxe/PciCpuIo2Dxe.inf
@@ -0,0 +1,48 @@
+## @file
+# Produces the CPU I/O 2 Protocol by using the services of the I/O Library.
+#
+# Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2016, Linaro Ltd. All rights reserved.
+# Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION= 0x0001001B
+ BASE_NAME = PciCpuIo2Dxe
+ FILE_GUID = 9BD3C765-2579-4CF0-9349-D77205565030
+ MODULE_TYPE= DXE_DRIVER
+ VERSION_STRING = 1.0
+ ENTRY_POINT= PciCpuIo2Initialize
+
+#
+# The following information is for reference only and not required by the
build tools.
+#
+# VALID_ARCHITECTURES = RISCV64
+#
+
+[Sources]
+ PciCpuIo2Dxe.c
+
+[Packages]
+ OvmfPkg/OvmfPkg.dec
+ MdePkg/MdePkg.dec
+
+[LibraryClasses]
+ UefiDriverEntryPoint
+ BaseLib
+ DebugLib
+ IoLib
+ PcdLib
+ UefiBootServicesTableLib
+
+[Pcd]
+ gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation
+
+[Protocols]
+ gEfiCpuIo2ProtocolGuid ## PRODUCES
+
+[Depex]
+ TRUE
diff --git a/OvmfPkg/RiscVVirt/PciCpuIo2Dxe/PciCpuIo2Dxe.c
b/OvmfPkg/RiscVVirt/PciCpuIo2Dxe/PciCpuIo2Dxe.c
new file mode 100644
index ..f3bf07e63141
--- /dev/null
+++ b/OvmfPkg/RiscVVirt/PciCpuIo2Dxe/PciCpuIo2Dxe.c
@@ -0,0 +1,557 @@
+/** @file
+ Produces the CPU I/O 2 Protocol.
+
+Copyright (c) 2009 - 2012, Intel Corporation. All rights reserved.
+Copyright (c) 2016, Linaro Ltd. All rights reserved.
+Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define MAX_IO_PORT_ADDRESS 0x
+
+//
+// Handle for the CPU I/O 2 Protocol
+//
+STATIC EFI_HANDLE mHandle = NULL;
+
+//
+// Lookup table for increment values based on transfer widths
+//
+STATIC CONST UINT8 mInStride[] = {
+ 1, // EfiCpuIoWidthUint8
+ 2, // EfiCpuIoWidthUint16
+ 4, // EfiCpuIoWidthUint32
+ 8, // EfiCpuIoWidthUint64
+ 0, // EfiCpuIoWidthFifoUint8
+ 0, // EfiCpuIoWidthFifoUint16
+ 0, // EfiCpuIoWidthFifoUint32
+ 0, // EfiCpuIoWidthFifoUint64
+ 1, // EfiCpuIoWidthFillUint8
+ 2, // EfiCpuIoWidthFillUint16
+ 4, // EfiCpuIoWidthFillUint32
+ 8 // EfiCpuIoWidthFillUint64
+};
+
+//
+// Lookup table for increment values based on transfer widths
+//
+STATIC CONST UINT8 mOutStride[] = {
+ 1, // EfiCpuIoWidthUint8
+ 2, // EfiCpuIoWidthUint16
+ 4, // EfiCpuIoWidthUint32
+ 8, // EfiCpuIoWidthUint64
+ 1, // EfiCpuIoWidthFifoUint8
+ 2, // EfiCpuIoWidthFifoUint16
+ 4, // EfiCpuIoWidthFifoUint32
+ 8, // EfiCpuIoWidthFifoUint64
+ 0, // EfiCpuIoWidthFillUint8
+ 0, // EfiCpuIoWidthFillUint16
+ 0, // EfiCpuIoWidthFillUint32
+ 0 // EfiCpuIoWidthFillUint64
+};
+
+/**
+ Check parameters to a CPU I/O 2 Protocol service request.
+
+ The I/O operations are carried out exactly as requested. The caller is
responsible
+ for satisfying any alignment and I/O width restrictions that a PI System on a
+ platform might require. For example on some platforms, width requests of
+ EfiCpuIoWidthUint64 do not work. Misaligned buffers, on the other hand, will
+ be handled by the driver.
+
+ @param[in] MmioOperation TRUE for an MMIO operation, FALSE for I/O Port
operation.
+ @param[in] Width Signifies the width of the I/O or Memory operation.
+ @param[in] AddressThe base address of the I/O operation.
+ @param[in] Count The number of I/O operations to perform. The
number of
+bytes moved is Width size * Count, starting at
Address.
+ @param[in] Buffer For read operations, the destination buffer to
store the results.
+For write operations, the source buffer from which
to write data.
+
+ @retval EFI_SUCCESSThe parameters for this request pass the
checks.
+ @retval EFI_INVALID_PARAMETER Width is invalid for this PI system.
+ @retval EFI_INVALID_PARAMETER Buffer is NULL.
+ @retval EFI_UNSUPPORTEDThe Buffer is not aligned for the given Width.
+ @retval EFI_UNSUPPORTEDThe address range specified by
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 15/19] OvmfPkg/RiscVVirt: Add VirtNorFlashPlatformLib library
Qemu NOR flash driver needs this library. Add this
library for RISC-V leveraged from SbsaQemu.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
Signed-off-by: Sunil V L
Acked-by: Abner Chang
Reviewed-by: Andrei Warkentin
---
OvmfPkg/RiscVVirt/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.inf |
30 +++
OvmfPkg/RiscVVirt/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.c |
40
2 files changed, 70 insertions(+)
diff --git
a/OvmfPkg/RiscVVirt/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.inf
b/OvmfPkg/RiscVVirt/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.inf
new file mode 100644
index ..4e87bd437380
--- /dev/null
+++
b/OvmfPkg/RiscVVirt/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.inf
@@ -0,0 +1,30 @@
+#/** @file
+#
+# Component description file for VirtNorFlashStaticLib module
+#
+# Copyright (c) 2014, Linaro Ltd. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#**/
+
+[Defines]
+ INF_VERSION= 0x00010005
+ BASE_NAME = VirtNorFlashStaticLib
+ FILE_GUID = 064742F1-E531-4D7D-A154-22315889CC23
+ MODULE_TYPE= DXE_DRIVER
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = VirtNorFlashPlatformLib
+
+[Sources.common]
+ VirtNorFlashStaticLib.c
+
+[Packages]
+ MdePkg/MdePkg.dec
+ MdeModulePkg/MdeModulePkg.dec
+ OvmfPkg/OvmfPkg.dec
+
+[Pcd]
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
diff --git
a/OvmfPkg/RiscVVirt/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.c
b/OvmfPkg/RiscVVirt/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.c
new file mode 100644
index ..fdc2ccb6294e
--- /dev/null
+++ b/OvmfPkg/RiscVVirt/Library/VirtNorFlashPlatformLib/VirtNorFlashStaticLib.c
@@ -0,0 +1,40 @@
+/** @file
+
+ Copyright (c) 2019, Linaro Ltd. All rights reserved
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ **/
+
+#include
+#include
+#include
+
+#define QEMU_NOR_BLOCK_SIZE SIZE_256KB
+
+EFI_STATUS
+VirtNorFlashPlatformInitialization (
+ VOID
+ )
+{
+ return EFI_SUCCESS;
+}
+
+VIRT_NOR_FLASH_DESCRIPTION mNorFlashDevice =
+{
+ FixedPcdGet32 (PcdOvmfFdBaseAddress),
+ FixedPcdGet64 (PcdFlashNvStorageVariableBase),
+ FixedPcdGet32 (PcdOvmfFirmwareFdSize),
+ QEMU_NOR_BLOCK_SIZE
+};
+
+EFI_STATUS
+VirtNorFlashPlatformGetDevices (
+ OUT VIRT_NOR_FLASH_DESCRIPTION **NorFlashDescriptions,
+ OUT UINT32 *Count
+ )
+{
+ *NorFlashDescriptions = &mNorFlashDevice;
+ *Count= 1;
+ return EFI_SUCCESS;
+}
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#6): https://edk2.groups.io/g/devel/message/6
Mute This Topic: https://groups.io/mt/96874998/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 14/19] OvmfPkg/RiscVVirt: Add ResetSystemLib library
RISC-V Qemu virt uses SBI calls to implement the reset.
Add the base class library.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
Signed-off-by: Sunil V L
Acked-by: Abner Chang
Reviewed-by: Andrei Warkentin
---
OvmfPkg/RiscVVirt/Library/ResetSystemLib/BaseResetSystemLib.inf | 38 ++
OvmfPkg/RiscVVirt/Library/ResetSystemLib/ResetSystemLib.c | 128
2 files changed, 166 insertions(+)
diff --git a/OvmfPkg/RiscVVirt/Library/ResetSystemLib/BaseResetSystemLib.inf
b/OvmfPkg/RiscVVirt/Library/ResetSystemLib/BaseResetSystemLib.inf
new file mode 100644
index ..c3fa6bd99b52
--- /dev/null
+++ b/OvmfPkg/RiscVVirt/Library/ResetSystemLib/BaseResetSystemLib.inf
@@ -0,0 +1,38 @@
+## @file
+# Base library instance for ResetSystem library class for RISC-V
+#
+# Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION= 0x0001001B
+ BASE_NAME = BaseResetSystemLib
+ FILE_GUID = AB45A200-769D-4C10-B0D6-5E1FF5EEBF31
+ MODULE_TYPE= BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = ResetSystemLib
+
+#
+# The following information is for reference only and not required by the build
+# tools.
+#
+# VALID_ARCHITECTURES = RISCV64
+#
+
+[Sources]
+ ResetSystemLib.c
+
+[Packages]
+ MdeModulePkg/MdeModulePkg.dec
+ MdePkg/MdePkg.dec
+ OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+ BaseLib
+ DebugLib
+ IoLib
+ TimerLib
+ RiscVSbiLib
diff --git a/OvmfPkg/RiscVVirt/Library/ResetSystemLib/ResetSystemLib.c
b/OvmfPkg/RiscVVirt/Library/ResetSystemLib/ResetSystemLib.c
new file mode 100644
index ..14f7653aa8de
--- /dev/null
+++ b/OvmfPkg/RiscVVirt/Library/ResetSystemLib/ResetSystemLib.c
@@ -0,0 +1,128 @@
+/** @file
+ Reset System Library functions for RISC-V
+
+ Copyright (c) 2021, Hewlett Packard Development LP. All rights reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+#include
+#include
+
+/**
+ This function causes a system-wide reset (cold reset), in which
+ all circuitry within the system returns to its initial state. This type of
reset
+ is asynchronous to system operation and operates without regard to
+ cycle boundaries.
+
+ If this function returns, it means that the system does not support cold
reset.
+**/
+VOID
+EFIAPI
+ResetCold (
+ VOID
+ )
+{
+ // Warm Reset via SBI ecall
+ SbiSystemReset (SBI_SRST_RESET_TYPE_COLD_REBOOT, SBI_SRST_RESET_REASON_NONE);
+}
+
+/**
+ This function causes a system-wide initialization (warm reset), in which all
processors
+ are set to their initial state. Pending cycles are not corrupted.
+
+ If this function returns, it means that the system does not support warm
reset.
+**/
+VOID
+EFIAPI
+ResetWarm (
+ VOID
+ )
+{
+ // Warm Reset via SBI ecall
+ SbiSystemReset (SBI_SRST_RESET_TYPE_WARM_REBOOT, SBI_SRST_RESET_REASON_NONE);
+}
+
+/**
+ This function causes the system to enter a power state equivalent
+ to the ACPI G2/S5 or G3 states.
+
+ If this function returns, it means that the system does not support shutdown
reset.
+**/
+VOID
+EFIAPI
+ResetShutdown (
+ VOID
+ )
+{
+ // Shut down via SBI ecall
+ SbiSystemReset (SBI_SRST_RESET_TYPE_SHUTDOWN, SBI_SRST_RESET_REASON_NONE);
+}
+
+/**
+ This function causes a systemwide reset. The exact type of the reset is
+ defined by the EFI_GUID that follows the Null-terminated Unicode string
passed
+ into ResetData. If the platform does not recognize the EFI_GUID in ResetData
+ the platform must pick a supported reset type to perform. The platform may
+ optionally log the parameters from any non-normal reset that occurs.
+
+ @param[in] DataSize The size, in bytes, of ResetData.
+ @param[in] ResetData The data buffer starts with a Null-terminated string,
+ followed by the EFI_GUID.
+**/
+VOID
+EFIAPI
+ResetPlatformSpecific (
+ IN UINTN DataSize,
+ IN VOID *ResetData
+ )
+{
+ //
+ // Can map to OpenSBI vendor or platform specific reset type.
+ //
+ return;
+}
+
+/**
+ The ResetSystem function resets the entire platform.
+
+ @param[in] ResetType The type of reset to perform.
+ @param[in] ResetStatusThe status code for the reset.
+ @param[in] DataSize The size, in bytes, of ResetData.
+ @param[in] ResetData For a ResetType of EfiResetCold, EfiResetWarm, or
EfiResetShutdown
+the data buffer starts with a Null-terminated
string, optionally
+followed by additional binary data. The string is
a description
+that the caller may use to further indicate the
reason for the
+system reset.
+**/
+VOID
+EFIAPI
+ResetSystem (
+ IN EFI_RESET_TYPE ResetType,
+ IN EFI_STATUS ResetStatus,
+ IN UINTN DataSize,
+
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 13/19] OvmfPkg/RiscVVirt: Add PrePiHobListPointerLib library
Add the PrePiHobListPointerLib required for RISC-V Qemu Virt machine
since it follows PEIless design.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
Signed-off-by: Sunil V L
Acked-by: Abner Chang
Reviewed-by: Andrei Warkentin
---
OvmfPkg/RiscVVirt/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf |
23 +++
OvmfPkg/RiscVVirt/Library/PrePiHobListPointerLib/PrePiHobListPointer.c |
65
2 files changed, 88 insertions(+)
diff --git
a/OvmfPkg/RiscVVirt/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
b/OvmfPkg/RiscVVirt/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
new file mode 100644
index ..c539682e8d0b
--- /dev/null
+++
b/OvmfPkg/RiscVVirt/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
@@ -0,0 +1,23 @@
+#/** @file
+#
+# Copyright (c) 2021, Intel Corporation. All rights reserved.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#**/
+
+[Defines]
+ INF_VERSION= 0x0001001B
+ BASE_NAME = PrePiHobListPointerLib
+ FILE_GUID = E3FAFC60-758C-471B-A333-FE704A4C11B4
+ MODULE_TYPE= BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = PrePiHobListPointerLib
+
+[Sources.RISCV64]
+ PrePiHobListPointer.c
+
+[Packages]
+ MdePkg/MdePkg.dec
+ OvmfPkg/OvmfPkg.dec
+ EmbeddedPkg/EmbeddedPkg.dec
+ UefiCpuPkg/UefiCpuPkg.dec
diff --git
a/OvmfPkg/RiscVVirt/Library/PrePiHobListPointerLib/PrePiHobListPointer.c
b/OvmfPkg/RiscVVirt/Library/PrePiHobListPointerLib/PrePiHobListPointer.c
new file mode 100644
index ..a58b7aae6bee
--- /dev/null
+++ b/OvmfPkg/RiscVVirt/Library/PrePiHobListPointerLib/PrePiHobListPointer.c
@@ -0,0 +1,65 @@
+/** @file
+*
+* Copyright (c) 2021, Intel Corporation. All rights reserved.
+* SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ Returns the pointer to the HOB list.
+
+ This function returns the pointer to first HOB in the list.
+
+ @return The pointer to the HOB list.
+
+**/
+VOID *
+EFIAPI
+PrePeiGetHobList (
+ VOID
+ )
+{
+ EFI_RISCV_FIRMWARE_CONTEXT *FirmwareContext;
+
+ FirmwareContext = NULL;
+ GetFirmwareContextPointer (&FirmwareContext);
+
+ if (FirmwareContext == NULL) {
+DEBUG ((DEBUG_ERROR, "%a: Firmware Context is NULL\n", __FUNCTION__));
+return NULL;
+ }
+
+ return (VOID *)FirmwareContext->PrePiHobList;
+}
+
+/**
+ Updates the pointer to the HOB list.
+
+ @param HobList Hob list pointer to store
+
+**/
+EFI_STATUS
+EFIAPI
+PrePeiSetHobList (
+ IN VOID *HobList
+ )
+{
+ EFI_RISCV_FIRMWARE_CONTEXT *FirmwareContext;
+
+ FirmwareContext = NULL;
+ GetFirmwareContextPointer (&FirmwareContext);
+
+ if (FirmwareContext == NULL) {
+DEBUG ((DEBUG_ERROR, "%a: Firmware Context is NULL\n", __FUNCTION__));
+return EFI_NOT_READY;
+ }
+
+ FirmwareContext->PrePiHobList = HobList;
+ return EFI_SUCCESS;
+}
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#4): https://edk2.groups.io/g/devel/message/4
Mute This Topic: https://groups.io/mt/96874996/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 12/19] OvmfPkg/RiscVVirt: Add PlatformBootManagerLib library
RISC-V Qemu Virt platfform needs the PlatformBootManagerLib similar to the one in ArmVirtPlatform. Add the library in OvmfPkg/RiscVVirt leveraging the one from Arm. Cc: Ard Biesheuvel Cc: Jiewen Yao Cc: Jordan Justen Cc: Gerd Hoffmann Signed-off-by: Sunil V L Acked-by: Abner Chang Reviewed-by: Andrei Warkentin --- OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 75 ++ OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBm.h | 45 + OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBm.c | 1078 OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/QemuKernel.c | 77 ++ 4 files changed, 1275 insertions(+) diff --git a/OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf b/OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf new file mode 100644 index ..9d66c8110c53 --- /dev/null +++ b/OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf @@ -0,0 +1,75 @@ +## @file +# Implementation for PlatformBootManagerLib library class interfaces for RISC-V. +# +# Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved. +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +[Defines] + INF_VERSION= 0x0001001B + BASE_NAME = DxeRiscV64PlatformBootManagerLib + FILE_GUID = 4FC87DC9-2666-49BB-9023-B5FAA1E9E732 + MODULE_TYPE= DXE_DRIVER + VERSION_STRING = 1.0 + LIBRARY_CLASS = PlatformBootManagerLib|DXE_DRIVER + +# +# The following information is for reference only and not required by the build tools. +# +# VALID_ARCHITECTURES = RISCV64 +# + +[Sources] + PlatformBm.c + PlatformBm.h + QemuKernel.c + +[Packages] + MdeModulePkg/MdeModulePkg.dec + MdePkg/MdePkg.dec + OvmfPkg/OvmfPkg.dec + SecurityPkg/SecurityPkg.dec + ShellPkg/ShellPkg.dec + +[LibraryClasses] + BaseLib + BaseMemoryLib + BootLogoLib + DebugLib + DevicePathLib + MemoryAllocationLib + PcdLib + PlatformBmPrintScLib + QemuBootOrderLib + QemuLoadImageLib + ReportStatusCodeLib + TpmPlatformHierarchyLib + UefiBootManagerLib + UefiBootServicesTableLib + UefiLib + UefiRuntimeServicesTableLib + +[FixedPcd] + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity + gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits + +[Pcd] + gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut + gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString + +[Guids] + gEfiEndOfDxeEventGroupGuid + gEfiGlobalVariableGuid + gRootBridgesConnectedEventGroupGuid + gUefiShellFileGuid + gEfiTtyTermGuid + +[Protocols] + gEfiFirmwareVolume2ProtocolGuid + gEfiGraphicsOutputProtocolGuid + gEfiPciRootBridgeIoProtocolGuid + gVirtioDeviceProtocolGuid diff --git a/OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBm.h b/OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBm.h new file mode 100644 index ..70c52d9832ca --- /dev/null +++ b/OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBm.h @@ -0,0 +1,45 @@ +/** @file + Head file for BDS Platform specific code + + Copyright (C) 2015-2016, Red Hat, Inc. + Copyright (c) 2004 - 2008, Intel Corporation. All rights reserved. + + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#ifndef _PLATFORM_BM_H_ +#define _PLATFORM_BM_H_ + +#include +#include +#include +#include +#include +#include +#include +#include + +/** + Download the kernel, the initial ramdisk, and the kernel command line from + QEMU's fw_cfg. Construct a minimal SimpleFileSystem that contains the two + image files, and load and start the kernel from it. + + The kernel will be instructed via its command line to load the initrd from + the same Simple FileSystem. + + @retval EFI_NOT_FOUND Kernel image was not found. + @retval EFI_OUT_OF_RESOURCES Memory allocation failed. + @retval EFI_PROTOCOL_ERRORUnterminated kernel command line. + + @return Error codes from any of the underlying +functions. On success, the function doesn't +return. +**/ +EFI_STATUS +EFIAPI +TryRunningQemuKernel ( + VOID + ); + +#endif // _PLATFORM_BM_H_ diff --git a/OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBm.c b/OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBm.c new file mode 100644 index ..2559889638ad --- /dev/null +++ b/OvmfPkg/RiscVVirt/Library/PlatformBootManagerLib/PlatformBm.c @@ -0,0 +1,1078 @@ +/** @file + Implementation for PlatformBootManagerLib library class interfaces. + + Copyright (C) 2015-2016, Red Hat, Inc. + Copyright (c) 2014, ARM Ltd. All rights reserved. + Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved. + + SPDX-License-Identif
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 11/19] ArmVirtPkg: Fix up the location of PlatformHasAcpiDtDxe
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
PlatformHasAcpiDtDxe is required by other architectures also.
Hence, it is moved to OvmfPkg. So, update the consumers of this
module with the new location.
Cc: Ard Biesheuvel
Cc: Leif Lindholm
Cc: Sami Mujawar
Cc: Gerd Hoffmann
Signed-off-by: Sunil V L
Reviewed-by: Andrei Warkentin
---
ArmVirtPkg/ArmVirtCloudHv.dsc | 2 +-
ArmVirtPkg/ArmVirtQemu.dsc | 4 ++--
ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 +-
ArmVirtPkg/CloudHvPlatformHasAcpiDtDxe/CloudHvHasAcpiDtDxe.inf | 2 +-
ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf | 4 ++--
ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 2 +-
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/ArmVirtPkg/ArmVirtCloudHv.dsc b/ArmVirtPkg/ArmVirtCloudHv.dsc
index 7ca7a391d9cf..c975e139a216 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.dsc
+++ b/ArmVirtPkg/ArmVirtCloudHv.dsc
@@ -198,7 +198,7 @@ [PcdsDynamicDefault.common]
gEfiSecurityPkgTokenSpaceGuid.PcdTpmBaseAddress|0x0
[PcdsDynamicHii]
-
gArmVirtTokenSpaceGuid.PcdForceNoAcpi|L"ForceNoAcpi"|gArmVirtVariableGuid|0x0|FALSE|NV,BS
+
gUefiOvmfPkgTokenSpaceGuid.PcdForceNoAcpi|L"ForceNoAcpi"|gOvmfVariableGuid|0x0|FALSE|NV,BS
#
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 0f1c6395488a..72a0cacab4a8 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -305,7 +305,7 @@ [PcdsPatchableInModule]
!endif
[PcdsDynamicHii]
-
gArmVirtTokenSpaceGuid.PcdForceNoAcpi|L"ForceNoAcpi"|gArmVirtVariableGuid|0x0|FALSE|NV,BS
+
gUefiOvmfPkgTokenSpaceGuid.PcdForceNoAcpi|L"ForceNoAcpi"|gOvmfVariableGuid|0x0|FALSE|NV,BS
!if $(TPM2_CONFIG_ENABLE) == TRUE
gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer|L"TCG2_VERSION"|gTcg2ConfigFormSetGuid|0x0|"1.3"|NV,BS
@@ -578,7 +578,7 @@ [Components.common]
#
# ACPI Support
#
- ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
+ OvmfPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
[Components.AARCH64]
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf {
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 807c85d48285..3cb9120e4e10 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -461,7 +461,7 @@ [Components.common]
#
# ACPI Support
#
- ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
+ OvmfPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
[Components.AARCH64]
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf {
diff --git a/ArmVirtPkg/CloudHvPlatformHasAcpiDtDxe/CloudHvHasAcpiDtDxe.inf
b/ArmVirtPkg/CloudHvPlatformHasAcpiDtDxe/CloudHvHasAcpiDtDxe.inf
index 4af06b2a6746..7cad40e11f33 100644
--- a/ArmVirtPkg/CloudHvPlatformHasAcpiDtDxe/CloudHvHasAcpiDtDxe.inf
+++ b/ArmVirtPkg/CloudHvPlatformHasAcpiDtDxe/CloudHvHasAcpiDtDxe.inf
@@ -36,7 +36,7 @@ [Guids]
gEdkiiPlatformHasDeviceTreeGuid ## SOMETIMES_PRODUCES ## PROTOCOL
[Pcd]
- gArmVirtTokenSpaceGuid.PcdForceNoAcpi
+ gUefiOvmfPkgTokenSpaceGuid.PcdForceNoAcpi
[Depex]
gEfiVariableArchProtocolGuid
diff --git a/ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
b/ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
index 1cf25780f830..c5bf798c3b2b 100644
--- a/ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
+++ b/ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.inf
@@ -21,7 +21,7 @@ [Sources]
KvmtoolPlatformDxe.c
[Packages]
- ArmVirtPkg/ArmVirtPkg.dec
+ OvmfPkg/OvmfPkg.dec
EmbeddedPkg/EmbeddedPkg.dec
MdePkg/MdePkg.dec
MdeModulePkg/MdeModulePkg.dec
@@ -37,7 +37,7 @@ [Guids]
gEdkiiPlatformHasDeviceTreeGuid ## SOMETIMES_PRODUCES ## PROTOCOL
[Pcd]
- gArmVirtTokenSpaceGuid.PcdForceNoAcpi
+ gUefiOvmfPkgTokenSpaceGuid.PcdForceNoAcpi
[Depex]
TRUE
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index e06ca7424476..8a063bac04ac 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -141,7 +141,7 @@ [FV.FvMain]
#
# ACPI Support
#
- INF ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
+ INF OvmfPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
!if $(ARCH) == AARCH64
INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
INF
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#2): https://edk2.groups.io/g/devel/message/2
Mute This Topic: https://groups.io/mt/96874992/21656
Group Owner: devel+ow...
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 10/19] ArmVirtPkg/PlatformHasAcpiDtDxe: Move to OvmfPkg
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
This module is required by other architectures like RISC-V.
Hence, move this to OvmfPkg.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
Signed-off-by: Sunil V L
Acked-by: Ard Biesheuvel
Reviewed-by: Andrei Warkentin
---
ArmVirtPkg/ArmVirtPkg.dec | 9
-
OvmfPkg/OvmfPkg.dec | 7
+++
{ArmVirtPkg => OvmfPkg}/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 3 +--
{ArmVirtPkg => OvmfPkg}/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 0
4 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
index 89d21ec3a364..4645c91a8375 100644
--- a/ArmVirtPkg/ArmVirtPkg.dec
+++ b/ArmVirtPkg/ArmVirtPkg.dec
@@ -34,8 +34,6 @@ [Guids.common]
gEarly16550UartBaseAddressGuid = { 0xea67ca3e, 0x1f54, 0x436b, { 0x97,
0x88, 0xd4, 0xeb, 0x29, 0xc3, 0x42, 0x67 } }
gArmVirtSystemMemorySizeGuid = { 0x504eccb9, 0x1bf0, 0x4420, { 0x86,
0x5d, 0xdc, 0x66, 0x06, 0xd4, 0x13, 0xbf } }
- gArmVirtVariableGuid = { 0x50bea1e5, 0xa2c5, 0x46e9, { 0x9b, 0x3a, 0x59,
0x59, 0x65, 0x16, 0xb0, 0x0a } }
-
[PcdsFeatureFlag]
#
# Feature Flag PCD that defines whether TPM2 support is enabled
@@ -69,10 +67,3 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
# Cloud Hypervisor has no other way to pass Rsdp address to the guest except
use a PCD.
#
gArmVirtTokenSpaceGuid.PcdCloudHvAcpiRsdpBaseAddress|0x0|UINT64|0x0005
-
-[PcdsDynamic]
- #
- # Whether to force disable ACPI, regardless of the fw_cfg settings
- # exposed by QEMU
- #
- gArmVirtTokenSpaceGuid.PcdForceNoAcpi|0x0|BOOLEAN|0x0003
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index be30547474ae..749fbd3b6bf4 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -161,6 +161,7 @@ [Guids]
gVMMBootOrderGuid = {0x668f4529, 0x63d0, 0x4bb5, {0xb6,
0x5d, 0x6f, 0xbb, 0x9d, 0x36, 0xa4, 0x4a}}
gUefiOvmfPkgTdxAcpiHobGuid= {0x6a0c5870, 0xd4ed, 0x44f4, {0xa1,
0x35, 0xdd, 0x23, 0x8b, 0x6f, 0x0c, 0x8d}}
gEfiNonCcFvGuid = {0xae047c6d, 0xbce9, 0x426c, {0xae,
0x03, 0xa6, 0x8e, 0x3b, 0x8a, 0x04, 0x88}}
+ gOvmfVariableGuid = {0x50bea1e5, 0xa2c5, 0x46e9, {0x9b,
0x3a, 0x59, 0x59, 0x65, 0x16, 0xb0, 0x0a}}
[Ppis]
# PPI whose presence in the PPI database signals that the TPM base address
@@ -467,6 +468,12 @@ [PcdsDynamic, PcdsDynamicEx]
#2 - set by GOP Driver.
gUefiOvmfPkgTokenSpaceGuid.PcdVideoResolutionSource|0|UINT8|0x64
+ #
+ # Whether to force disable ACPI, regardless of the fw_cfg settings
+ # exposed by QEMU
+ #
+ gUefiOvmfPkgTokenSpaceGuid.PcdForceNoAcpi|0x0|BOOLEAN|0x69
+
[PcdsFeatureFlag]
gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation|TRUE|BOOLEAN|0x1c
gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderMmioTranslation|FALSE|BOOLEAN|0x1d
diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
b/OvmfPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
similarity index 89%
rename from ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
rename to OvmfPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
index e900aa992661..85873f73b2eb 100644
--- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
+++ b/OvmfPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
@@ -19,7 +19,6 @@ [Sources]
PlatformHasAcpiDtDxe.c
[Packages]
- ArmVirtPkg/ArmVirtPkg.dec
EmbeddedPkg/EmbeddedPkg.dec
MdeModulePkg/MdeModulePkg.dec
MdePkg/MdePkg.dec
@@ -38,7 +37,7 @@ [Guids]
gEdkiiPlatformHasDeviceTreeGuid ## SOMETIMES_PRODUCES ## PROTOCOL
[Pcd]
- gArmVirtTokenSpaceGuid.PcdForceNoAcpi
+ gUefiOvmfPkgTokenSpaceGuid.PcdForceNoAcpi
[Depex]
gEfiVariableArchProtocolGuid
diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
b/OvmfPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
similarity index 100%
rename from ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
rename to OvmfPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#1): https://edk2.groups.io/g/devel/message/1
Mute This Topic: https://groups.io/mt/96874991/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 09/19] UefiCpuPkg/UefiCpuPkg.ci.yaml: Ignore RISC-V file
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
RISC-V register names do not follow the EDK2 formatting.
So, add it to ignore list for now.
Cc: Eric Dong
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Gerd Hoffmann
Signed-off-by: Sunil V L
Acked-by: Abner Chang
Reviewed-by: Andrei Warkentin
Reviewed-by: Michael D Kinney
Acked-by: Ray Ni
---
UefiCpuPkg/UefiCpuPkg.ci.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/UefiCpuPkg/UefiCpuPkg.ci.yaml b/UefiCpuPkg/UefiCpuPkg.ci.yaml
index a377366798b0..c2280aedf5ce 100644
--- a/UefiCpuPkg/UefiCpuPkg.ci.yaml
+++ b/UefiCpuPkg/UefiCpuPkg.ci.yaml
@@ -27,6 +27,7 @@
],
## Both file path and directory path are accepted.
"IgnoreFiles": [
+ "Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.h"
]
},
"CompilerPlugin": {
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#0): https://edk2.groups.io/g/devel/message/0
Mute This Topic: https://groups.io/mt/96874990/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 08/19] UefiCpuPkg: Add CpuDxeRiscV64 module
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 This is copied from edk2-platforms/Silicon/RISC-V/ProcessorPkg/Universal/CpuDxe and added the RISCV_EFI_BOOT_PROTOCOL support. Cc: Eric Dong Cc: Ray Ni Cc: Rahul Kumar Cc: Daniel Schaefer Cc: Gerd Hoffmann Signed-off-by: Sunil V L Acked-by: Abner Chang Reviewed-by: Andrei Warkentin --- UefiCpuPkg/UefiCpuPkg.dsc | 1 + UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf | 68 UefiCpuPkg/CpuDxeRiscV64/CpuDxe.h | 199 +++ UefiCpuPkg/CpuDxeRiscV64/CpuDxe.c | 365 UefiCpuPkg/CpuDxeRiscV64/CpuDxe.uni| 13 + UefiCpuPkg/CpuDxeRiscV64/CpuDxeExtra.uni | 14 + 6 files changed, 660 insertions(+) diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc index aba5ae927586..a7318d3fe9db 100644 --- a/UefiCpuPkg/UefiCpuPkg.dsc +++ b/UefiCpuPkg/UefiCpuPkg.dsc @@ -199,6 +199,7 @@ [Components.RISCV64] UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHandlerLib.inf UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf + UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf [BuildOptions] *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES diff --git a/UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf b/UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf new file mode 100644 index ..befe23384c1a --- /dev/null +++ b/UefiCpuPkg/CpuDxeRiscV64/CpuDxeRiscV64.inf @@ -0,0 +1,68 @@ +## @file +# RISC-V CPU DXE module. +# +# Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved. +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +[Defines] + INF_VERSION= 0x0001001B + BASE_NAME = CpuDxeRiscV64 + MODULE_UNI_FILE= CpuDxe.uni + FILE_GUID = BDEA19E2-778F-473C-BF82-5E38D6A27765 + MODULE_TYPE= DXE_DRIVER + VERSION_STRING = 1.0 + ENTRY_POINT= InitializeCpu + +[Packages] + MdePkg/MdePkg.dec + MdeModulePkg/MdeModulePkg.dec + UefiCpuPkg/UefiCpuPkg.dec + +[LibraryClasses] + BaseLib + BaseMemoryLib + CpuLib + DebugLib + DxeServicesTableLib + MemoryAllocationLib + UefiBootServicesTableLib + UefiDriverEntryPoint + UefiLib + CpuExceptionHandlerLib + HobLib + ReportStatusCodeLib + TimerLib + PeCoffGetEntryPointLib + RiscVSbiLib + +[Sources] + CpuDxe.c + CpuDxe.h + +[Protocols] + gEfiCpuArchProtocolGuid ## PRODUCES + gRiscVEfiBootProtocolGuid ## PRODUCES + +[Guids] + gIdleLoopEventGuid## CONSUMES ## Event + +[Ppis] + gEfiSecPlatformInformation2PpiGuid## UNDEFINED # HOB + gEfiSecPlatformInformationPpiGuid ## UNDEFINED # HOB + +[Pcd] + gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard ## CONSUMES + gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask ## CONSUMES + gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## CONSUMES + gUefiCpuPkgTokenSpaceGuid.PcdCpuStackSwitchExceptionList ## CONSUMES + gUefiCpuPkgTokenSpaceGuid.PcdCpuKnownGoodStackSize## CONSUMES + gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency ## CONSUMES + +[Depex] + TRUE + +[UserExtensions.TianoCore."ExtraFiles"] + CpuDxeExtra.uni diff --git a/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.h b/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.h new file mode 100644 index ..49f4e119665a --- /dev/null +++ b/UefiCpuPkg/CpuDxeRiscV64/CpuDxe.h @@ -0,0 +1,199 @@ +/** @file + RISC-V CPU DXE module header file. + + Copyright (c) 2016 - 2022, Hewlett Packard Enterprise Development LP. All rights reserved. + + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#ifndef CPU_DXE_H_ +#define CPU_DXE_H_ + +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +/** + Flush CPU data cache. If the instruction cache is fully coherent + with all DMA operations then function can just return EFI_SUCCESS. + + @param This Protocol instance structure + @param Start Physical address to start flushing from. + @param LengthNumber of bytes to flush. Round up to chipset +granularity. + @param FlushType Specifies the type of flush operation to perform. + + @retval EFI_SUCCESS If cache was flushed + @retval EFI_UNSUPPORTED If flush type is not supported. + @retval EFI_DEVICE_ERROR If requested range could not be flushed. + +**/ +EFI_STATUS +EFIAPI +CpuFlushCpuDataCache ( + IN EFI_CPU_ARCH_PROTOCOL *This, + IN EFI_PHYSICAL_ADDRESS Start, + IN UINT64 Length, + IN EFI_CPU_FLUSH_TYPE FlushType + ); + +/** + Enables CPU interrupts. + + @param This Protocol instance structure + + @retval EFI_SUC
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 07/19] UefiCpuPkg: Add CpuTimerDxeRiscV64 module
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 This DXE module initializes the timer interrupt handler and installs the Arch Timer protocol. Cc: Eric Dong Cc: Ray Ni Cc: Rahul Kumar Cc: Daniel Schaefer Cc: Gerd Hoffmann Signed-off-by: Sunil V L Acked-by: Abner Chang Reviewed-by: Andrei Warkentin --- UefiCpuPkg/UefiCpuPkg.dsc| 1 + UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf | 51 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h| 177 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c| 294 UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimer.uni | 14 + UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerExtra.uni | 12 + 6 files changed, 549 insertions(+) diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc index c511403842b8..aba5ae927586 100644 --- a/UefiCpuPkg/UefiCpuPkg.dsc +++ b/UefiCpuPkg/UefiCpuPkg.dsc @@ -198,6 +198,7 @@ [Components.X64] [Components.RISCV64] UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHandlerLib.inf UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf + UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf [BuildOptions] *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf new file mode 100644 index ..2c1f9f10e165 --- /dev/null +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf @@ -0,0 +1,51 @@ +## @file +# Timer Arch protocol module +# +# Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights reserved. +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +[Defines] + INF_VERSION= 0x0001001b + BASE_NAME = RiscVTimerDxe + MODULE_UNI_FILE= RiscVTimer.uni + FILE_GUID = 055DDAC6-9142-4013-BF20-FC2E5BC325C9 + MODULE_TYPE= DXE_DRIVER + VERSION_STRING = 1.0 + ENTRY_POINT= TimerDriverInitialize +# +# The following information is for reference only and not required by the build +# tools. +# +# VALID_ARCHITECTURES = RISCV64 +# +[Packages] + MdePkg/MdePkg.dec + UefiCpuPkg/UefiCpuPkg.dec + +[LibraryClasses] + BaseLib + DebugLib + IoLib + CpuLib + UefiBootServicesTableLib + UefiDriverEntryPoint + +[LibraryClasses.RISCV64] + RiscVSbiLib + +[Sources.RISCV64] + Timer.h + Timer.c + +[Protocols] + gEfiCpuArchProtocolGuid ## CONSUMES + gEfiTimerArchProtocolGuid ## PRODUCES + +[Depex] + gEfiCpuArchProtocolGuid + +[UserExtensions.TianoCore."ExtraFiles"] + RiscVTimerExtra.uni diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h new file mode 100644 index ..586eb0cfadb4 --- /dev/null +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h @@ -0,0 +1,177 @@ +/** @file + RISC-V Timer Architectural Protocol definitions + + Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All rights reserved. + + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#ifndef TIMER_H_ +#define TIMER_H_ + +#include + +#include +#include + +#include +#include +#include +#include + +// +// RISC-V use 100us timer. +// The default timer tick duration is set to 10 ms = 10 * 1000 * 10 100 ns units +// +#define DEFAULT_TIMER_TICK_DURATION 10 + +extern VOID +RiscvSetTimerPeriod ( + UINT32 TimerPeriod + ); + +// +// Function Prototypes +// + +/** + Initialize the Timer Architectural Protocol driver + + @param ImageHandle ImageHandle of the loaded driver + @param SystemTable Pointer to the System Table + + @retval EFI_SUCCESSTimer Architectural Protocol created + @retval EFI_OUT_OF_RESOURCES Not enough resources available to initialize driver. + @retval EFI_DEVICE_ERROR A device error occured attempting to initialize the driver. + +**/ +EFI_STATUS +EFIAPI +TimerDriverInitialize ( + IN EFI_HANDLEImageHandle, + IN EFI_SYSTEM_TABLE *SystemTable + ) +; + +/** + + This function adjusts the period of timer interrupts to the value specified + by TimerPeriod. If the timer period is updated, then the selected timer + period is stored in EFI_TIMER.TimerPeriod, and EFI_SUCCESS is returned. If + the timer hardware is not programmable, then EFI_UNSUPPORTED is returned. + If an error occurs while attempting to update the timer period, then the + timer hardware will be put back in its state prior to this call, and + EFI_DEVICE_ERROR is returned. If TimerPeriod is 0, then the timer interrupt + is disabled. This is not the same as disabling the CPU's interrupts. + Instead, it must either turn off the timer hardware, or it must adjust the + interrupt controller so that a CPU interrupt is not generated when the timer + interrupt fires. + + + @param ThisThe EFI_TIMER_ARCH_PROTOCOL instance. + @par
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 06/19] UefiCpuPkg: Add BaseRiscV64CpuTimerLib library
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
Add the RISC-V instance of the TimerLib.
This is mostly copied from
edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVTimerLib
Cc: Eric Dong
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Daniel Schaefer
Cc: Abner Chang
Cc: Gerd Hoffmann
Signed-off-by: Sunil V L
Acked-by: Abner Chang
Reviewed-by: Andrei Warkentin
---
UefiCpuPkg/UefiCpuPkg.dsc| 1 +
UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf | 33
UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/CpuTimerLib.c | 199
UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.uni | 14 ++
4 files changed, 247 insertions(+)
diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
index 35e66d93efa6..c511403842b8 100644
--- a/UefiCpuPkg/UefiCpuPkg.dsc
+++ b/UefiCpuPkg/UefiCpuPkg.dsc
@@ -197,6 +197,7 @@ [Components.X64]
[Components.RISCV64]
UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHandlerLib.inf
+ UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
[BuildOptions]
*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
diff --git
a/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
b/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
new file mode 100644
index ..3d5eaa41716d
--- /dev/null
+++ b/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/BaseRiscV64CpuTimerLib.inf
@@ -0,0 +1,33 @@
+## @file
+# RISC-V Base CPU Timer Library Instance
+#
+# Copyright (c) 2016 - 2019, Hewlett Packard Enterprise Development LP. All
rights reserved.
+# Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION= 0x0001001B
+ BASE_NAME = BaseRisV64CpuTimerLib
+ FILE_GUID = B635A600-EA24-4199-88E8-5761EEA96A51
+ MODULE_TYPE= BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = TimerLib
+ MODULE_UNI_FILE= BaseRisV64CpuTimerLib.uni
+
+[Sources]
+ CpuTimerLib.c
+
+[Packages]
+ MdePkg/MdePkg.dec
+ UefiCpuPkg/UefiCpuPkg.dec
+
+[LibraryClasses]
+ BaseLib
+ PcdLib
+ DebugLib
+
+[Pcd]
+ gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency ## CONSUMES
diff --git a/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/CpuTimerLib.c
b/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/CpuTimerLib.c
new file mode 100644
index ..9c8efc0f3530
--- /dev/null
+++ b/UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/CpuTimerLib.c
@@ -0,0 +1,199 @@
+/** @file
+ RISC-V instance of Timer Library.
+
+ Copyright (c) 2016 - 2022, Hewlett Packard Enterprise Development LP. All
rights reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ Stalls the CPU for at least the given number of ticks.
+
+ Stalls the CPU for at least the given number of ticks. It's invoked by
+ MicroSecondDelay() and NanoSecondDelay().
+
+ @param Delay A period of time to delay in ticks.
+
+**/
+VOID
+InternalRiscVTimerDelay (
+ IN UINT32 Delay
+ )
+{
+ UINT32 Ticks;
+ UINT32 Times;
+
+ Times = Delay >> (RISCV_TIMER_COMPARE_BITS - 2);
+ Delay &= ((1 << (RISCV_TIMER_COMPARE_BITS - 2)) - 1);
+ do {
+//
+// The target timer count is calculated here
+//
+Ticks = RiscVReadTimer () + Delay;
+Delay = 1 << (RISCV_TIMER_COMPARE_BITS - 2);
+while (((Ticks - RiscVReadTimer ()) & (1 << (RISCV_TIMER_COMPARE_BITS -
1))) == 0) {
+ CpuPause ();
+}
+ } while (Times-- > 0);
+}
+
+/**
+ Stalls the CPU for at least the given number of microseconds.
+
+ Stalls the CPU for the number of microseconds specified by MicroSeconds.
+
+ @param MicroSeconds The minimum number of microseconds to delay.
+
+ @return MicroSeconds
+
+**/
+UINTN
+EFIAPI
+MicroSecondDelay (
+ IN UINTN MicroSeconds
+ )
+{
+ InternalRiscVTimerDelay (
+(UINT32)DivU64x32 (
+ MultU64x32 (
+MicroSeconds,
+PcdGet64 (PcdCpuCoreCrystalClockFrequency)
+),
+ 100u
+ )
+);
+ return MicroSeconds;
+}
+
+/**
+ Stalls the CPU for at least the given number of nanoseconds.
+
+ Stalls the CPU for the number of nanoseconds specified by NanoSeconds.
+
+ @param NanoSeconds The minimum number of nanoseconds to delay.
+
+ @return NanoSeconds
+
+**/
+UINTN
+EFIAPI
+NanoSecondDelay (
+ IN UINTN NanoSeconds
+ )
+{
+ InternalRiscVTimerDelay (
+(UINT32)DivU64x32 (
+ MultU64x32 (
+NanoSeconds,
+PcdGet64 (PcdCpuCoreCrystalClockFrequency)
+),
+ 10u
+ )
+);
+ return NanoSeconds;
+}
+
+/**
+ Retrieves the current value of a 64-bit free running performance counter.
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 05/19] UefiCpuPkg: Add BaseRiscV64CpuExceptionHandlerLib
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 Add Cpu Exception Handler library for RISC-V. This is copied from edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVExceptionLib Cc: Eric Dong Cc: Ray Ni Cc: Rahul Kumar Cc: Daniel Schaefer Cc: Abner Chang Cc: Gerd Hoffmann Signed-off-by: Sunil V L Acked-by: Abner Chang Reviewed-by: Andrei Warkentin --- UefiCpuPkg/UefiCpuPkg.dsc | 3 + UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHandlerLib.inf | 42 +++ UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.h | 116 + UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.c | 133 UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHandlerLib.uni | 13 ++ UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/SupervisorTrapHandler.S | 105 6 files changed, 412 insertions(+) diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc index f9a46089d2c7..35e66d93efa6 100644 --- a/UefiCpuPkg/UefiCpuPkg.dsc +++ b/UefiCpuPkg/UefiCpuPkg.dsc @@ -195,5 +195,8 @@ [Components.IA32, Components.X64] [Components.X64] UefiCpuPkg/Library/CpuExceptionHandlerLib/UnitTest/DxeCpuExceptionHandlerLibUnitTest.inf +[Components.RISCV64] + UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHandlerLib.inf + [BuildOptions] *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES diff --git a/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHandlerLib.inf b/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHandlerLib.inf new file mode 100644 index ..d80462943645 --- /dev/null +++ b/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/BaseRiscV64CpuExceptionHandlerLib.inf @@ -0,0 +1,42 @@ +## @file +# RISC-V CPU Exception Handler Library +# +# Copyright (c) 2022-2023, Ventana Micro Systems Inc. All rights reserved. +# +# SPDX-License-Identifier: BSD-2-Clause-Patent +# +## + +[Defines] + INF_VERSION= 0x0001001B + BASE_NAME = BaseRiscV64CpuExceptionHandlerLib + MODULE_UNI_FILE= BaseRiscV64CpuExceptionHandlerLib.uni + FILE_GUID = 6AB0D5FD-E615-45A3-9374-E284FB061FC9 + MODULE_TYPE= BASE + VERSION_STRING = 1.0 + LIBRARY_CLASS = CpuExceptionHandlerLib + +# +# The following information is for reference only and not required by the build tools. +# +# VALID_ARCHITECTURES = RISCV64 +# + +[Sources] + SupervisorTrapHandler.S + CpuExceptionHandlerLib.c + CpuExceptionHandlerLib.h + +[Packages] + MdePkg/MdePkg.dec + MdeModulePkg/MdeModulePkg.dec + UefiCpuPkg/UefiCpuPkg.dec + +[LibraryClasses] + BaseLib + SerialPortLib + PrintLib + SynchronizationLib + PeCoffGetEntryPointLib + MemoryAllocationLib + DebugLib diff --git a/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.h b/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.h new file mode 100644 index ..30f47e87552b --- /dev/null +++ b/UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/CpuExceptionHandlerLib.h @@ -0,0 +1,116 @@ +/** @file + + RISC-V Exception Handler library definition file. + + Copyright (c) 2019-2022, Hewlett Packard Enterprise Development LP. All rights reserved. + + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#ifndef RISCV_CPU_EXECPTION_HANDLER_LIB_H_ +#define RISCV_CPU_EXECPTION_HANDLER_LIB_H_ + +#include + +/** + Trap Handler for S-mode + +**/ +VOID +SupervisorModeTrap ( + VOID + ); + +// +// Index of SMode trap register +// +#define SMODE_TRAP_REGS_zero 0 +#define SMODE_TRAP_REGS_ra 1 +#define SMODE_TRAP_REGS_sp 2 +#define SMODE_TRAP_REGS_gp 3 +#define SMODE_TRAP_REGS_tp 4 +#define SMODE_TRAP_REGS_t0 5 +#define SMODE_TRAP_REGS_t1 6 +#define SMODE_TRAP_REGS_t2 7 +#define SMODE_TRAP_REGS_s0 8 +#define SMODE_TRAP_REGS_s1 9 +#define SMODE_TRAP_REGS_a0 10 +#define SMODE_TRAP_REGS_a1 11 +#define SMODE_TRAP_REGS_a2 12 +#define SMODE_TRAP_REGS_a3 13 +#define SMODE_TRAP_REGS_a4 14 +#define SMODE_TRAP_REGS_a5 15 +#define SMODE_TRAP_REGS_a6 16 +#define SMODE_TRAP_REGS_a7 17 +#define SMODE_TRAP_REGS_s2 18 +#define SMODE_TRAP_REGS_s3 19 +#define SMODE_TRAP_REGS_s4 20 +#define SMODE_TRAP_REGS_s5 21 +#define SMODE_TRAP_REGS_s6 22 +#define SMODE_TRAP_REGS_s7 23 +#define SMODE_TRAP_REGS_s8 24 +#define SMODE_TRAP_REGS_s9 25 +#define SMODE_TRAP_REGS_s10 26 +#define SMODE_TRAP_REGS_s11 27 +#define SMODE_TRAP_REGS_t3 28 +#define SMODE_TRAP_REGS_t4 29 +#define SMODE_TRAP_REGS_t5
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 04/19] UefiCpuPkg: Add RISCV_EFI_BOOT_PROTOCOL related definitions
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
RISC-V UEFI based platforms need to support RISCV_EFI_BOOT_PROTOCOL.
Add this protocol GUID definition and the header file required.
Cc: Eric Dong
Cc: Ray Ni
Cc: Rahul Kumar
Cc: Daniel Schaefer
Cc: Gerd Hoffmann
Signed-off-by: Sunil V L
Acked-by: Abner Chang
Reviewed-by: Heinrich Schuchardt
Reviewed-by: Andrei Warkentin
Acked-by: Ray Ni
---
UefiCpuPkg/UefiCpuPkg.dec | 7
UefiCpuPkg/Include/Protocol/RiscVBootProtocol.h | 34
2 files changed, 41 insertions(+)
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index cff239d5283e..903ad52da91b 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -86,6 +86,13 @@ [Protocols]
## Include/Protocol/SmMonitorInit.h
gEfiSmMonitorInitProtocolGuid = { 0x228f344d, 0xb3de, 0x43bb, { 0xa4, 0xd7,
0xea, 0x20, 0xb, 0x1b, 0x14, 0x82 }}
+[Protocols.RISCV64]
+ #
+ # Protocols defined for RISC-V systems
+ #
+ ## Include/Protocol/RiscVBootProtocol.h
+ gRiscVEfiBootProtocolGuid = { 0xccd15fec, 0x6f73, 0x4eec, { 0x83, 0x95,
0x3e, 0x69, 0xe4, 0xb9, 0x40, 0xbf }}
+
#
# [Error.gUefiCpuPkgTokenSpaceGuid]
# 0x8001 | Invalid value provided.
diff --git a/UefiCpuPkg/Include/Protocol/RiscVBootProtocol.h
b/UefiCpuPkg/Include/Protocol/RiscVBootProtocol.h
new file mode 100644
index ..ed223b852d34
--- /dev/null
+++ b/UefiCpuPkg/Include/Protocol/RiscVBootProtocol.h
@@ -0,0 +1,34 @@
+/** @file
+ RISC-V Boot Protocol mandatory for RISC-V UEFI platforms.
+
+ @par Revision Reference:
+ The protocol specification can be found at
+ https://github.com/riscv-non-isa/riscv-uefi
+
+ Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved.
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef RISCV_BOOT_PROTOCOL_H_
+#define RISCV_BOOT_PROTOCOL_H_
+
+typedef struct _RISCV_EFI_BOOT_PROTOCOL RISCV_EFI_BOOT_PROTOCOL;
+
+#define RISCV_EFI_BOOT_PROTOCOL_REVISION 0x0001
+#define RISCV_EFI_BOOT_PROTOCOL_LATEST_VERSION \
+RISCV_EFI_BOOT_PROTOCOL_REVISION
+
+typedef
+EFI_STATUS
+(EFIAPI *EFI_GET_BOOT_HARTID)(
+ IN RISCV_EFI_BOOT_PROTOCOL *This,
+ OUT UINTN*BootHartId
+ );
+
+typedef struct _RISCV_EFI_BOOT_PROTOCOL {
+ UINT64 Revision;
+ EFI_GET_BOOT_HARTIDGetBootHartId;
+} RISCV_EFI_BOOT_PROTOCOL;
+
+#endif
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99985): https://edk2.groups.io/g/devel/message/99985
Mute This Topic: https://groups.io/mt/96874984/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 03/19] MdePkg: Add BaseRiscVSbiLib Library for RISC-V
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
This library is required to make SBI ecalls from the S-mode EDK2.
This is mostly copied from
edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Sunil V L
Acked-by: Abner Chang
Reviewed-by: Andrei Warkentin
---
MdePkg/MdePkg.dec | 4 +
MdePkg/MdePkg.dsc | 3 +
MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf | 26 +++
MdePkg/Include/Library/BaseRiscVSbiLib.h | 154 +
MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.c | 231
MdePkg/Library/BaseRiscVSbiLib/RiscVSbiEcall.S | 42
6 files changed, 460 insertions(+)
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 3d08f20d15b0..ca2e4dcf815c 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -316,6 +316,10 @@ [LibraryClasses.IA32, LibraryClasses.X64]
## @libraryclass Provides function to support TDX processing.
TdxLib|Include/Library/TdxLib.h
+[LibraryClasses.RISCV64]
+ ## @libraryclass Provides function to make ecalls to SBI
+ BaseRiscVSbiLib|Include/Library/BaseRiscVSbiLib.h
+
[Guids]
#
# GUID defined in UEFI2.1/UEFI2.0/EFI1.1
diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
index 32a852dc466e..0ac7618b4623 100644
--- a/MdePkg/MdePkg.dsc
+++ b/MdePkg/MdePkg.dsc
@@ -190,4 +190,7 @@ [Components.ARM, Components.AARCH64]
MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicArmVirt.inf
MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
+[Components.RISCV64]
+ MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
+
[BuildOptions]
diff --git a/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
b/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
new file mode 100644
index ..d6fd3f663af1
--- /dev/null
+++ b/MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
@@ -0,0 +1,26 @@
+## @file
+# RISC-V Library to call SBI ecalls
+#
+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+ INF_VERSION = 0x0001001b
+ BASE_NAME = BaseRiscVSbiLib
+ FILE_GUID = D742CF3D-E600-4009-8FB5-318073008508
+ MODULE_TYPE = BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = RiscVSbiLib
+
+[Sources]
+ BaseRiscVSbiLib.c
+ RiscVSbiEcall.S
+
+[Packages]
+ MdePkg/MdePkg.dec
+
+[LibraryClasses]
+ BaseLib
diff --git a/MdePkg/Include/Library/BaseRiscVSbiLib.h
b/MdePkg/Include/Library/BaseRiscVSbiLib.h
new file mode 100644
index ..e75520b4b888
--- /dev/null
+++ b/MdePkg/Include/Library/BaseRiscVSbiLib.h
@@ -0,0 +1,154 @@
+/** @file
+ Library to call the RISC-V SBI ecalls
+
+ Copyright (c) 2021-2022, Hewlett Packard Development LP. All rights
reserved.
+
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ @par Glossary:
+- Hart - Hardware Thread, similar to a CPU core
+
+ Currently, EDK2 needs to call SBI only to set the time and to do system
reset.
+
+**/
+
+#ifndef RISCV_SBI_LIB_H_
+#define RISCV_SBI_LIB_H_
+
+#include
+
+/* SBI Extension IDs */
+#define SBI_EXT_TIME 0x54494D45
+#define SBI_EXT_SRST 0x53525354
+
+/* SBI function IDs for TIME extension*/
+#define SBI_EXT_TIME_SET_TIMER 0x0
+
+/* SBI function IDs for SRST extension */
+#define SBI_EXT_SRST_RESET 0x0
+
+#define SBI_SRST_RESET_TYPE_SHUTDOWN 0x0
+#define SBI_SRST_RESET_TYPE_COLD_REBOOT 0x1
+#define SBI_SRST_RESET_TYPE_WARM_REBOOT 0x2
+
+#define SBI_SRST_RESET_REASON_NONE 0x0
+#define SBI_SRST_RESET_REASON_SYSFAIL 0x1
+
+/* SBI return error codes */
+#define SBI_SUCCESS0
+#define SBI_ERR_FAILED -1
+#define SBI_ERR_NOT_SUPPORTED -2
+#define SBI_ERR_INVALID_PARAM -3
+#define SBI_ERR_DENIED -4
+#define SBI_ERR_INVALID_ADDRESS-5
+#define SBI_ERR_ALREADY_AVAILABLE -6
+#define SBI_ERR_ALREADY_STARTED-7
+#define SBI_ERR_ALREADY_STOPPED-8
+
+#define SBI_LAST_ERR SBI_ERR_ALREADY_STOPPED
+
+typedef struct {
+ UINT64BootHartId;
+ VOID *PeiServiceTable;// PEI Service table
+ VOID *PrePiHobList; // Pre PI Hob List
+ UINT64FlattenedDeviceTree; // Pointer to Flattened Device tree
+} EFI_RISCV_FIRMWARE_CONTEXT;
+
+//
+// EDK2 OpenSBI firmware extension return status.
+//
+typedef struct {
+ UINTNError; ///< SBI status code
+ UINTNValue; ///< Value returned
+} SBI_RET;
+
+VOID
+EFIAPI
+SbiSetTimer (
+ IN UINT64 Time
+ );
+
+EFI_STATUS
+EFIAPI
+SbiSystemReset (
+ IN UINTN ResetType,
+ IN UINTN ResetReason
+ );
+
+/**
+ Get firmware context of the calling hart.
+
+ @param[out] FirmwareContext The firmware context pointer.
+**/
+VOID
+EFIAPI
+GetFirmwareContext (
+ OUT EFI_RISCV_FIRMWARE_CONTEXT **FirmwareContext
+ );
+
+/**
+ Set firmware context of the calling hart.
+
+ @param[in] FirmwareContext The fi
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 02/19] MdePkg/BaseLib: RISC-V: Add few more helper functions
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
Few of the basic helper functions required for any
RISC-V CPU were added in edk2-platforms. To support
qemu virt, they need to be added in BaseLib.
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Cc: Daniel Schaefer
Signed-off-by: Sunil V L
Acked-by: Abner Chang
Reviewed-by: Andrei Warkentin
---
MdePkg/Library/BaseLib/BaseLib.inf | 3 ++
MdePkg/Include/Library/BaseLib.h| 50 ++
MdePkg/Library/BaseLib/RiscV64/CpuScratch.S | 31
MdePkg/Library/BaseLib/RiscV64/ReadTimer.S | 23 +
MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S | 53 ++--
MdePkg/Library/BaseLib/RiscV64/RiscVMmu.S | 23 +
6 files changed, 179 insertions(+), 4 deletions(-)
diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
b/MdePkg/Library/BaseLib/BaseLib.inf
index 9ed46a584a14..3a48492b1a01 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -401,6 +401,9 @@ [Sources.RISCV64]
RiscV64/RiscVCpuPause.S | GCC
RiscV64/RiscVInterrupt.S | GCC
RiscV64/FlushCache.S | GCC
+ RiscV64/CpuScratch.S | GCC
+ RiscV64/ReadTimer.S | GCC
+ RiscV64/RiscVMmu.S| GCC
[Sources.LOONGARCH64]
Math64.c
diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index f3f59f21c2ea..8f2df76c29a3 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -151,6 +151,56 @@ typedef struct {
#define BASE_LIBRARY_JUMP_BUFFER_ALIGNMENT 8
+VOID
+RiscVSetSupervisorScratch (
+ IN UINT64
+ );
+
+UINT64
+RiscVGetSupervisorScratch (
+ VOID
+ );
+
+VOID
+RiscVSetSupervisorStvec (
+ IN UINT64
+ );
+
+UINT64
+RiscVGetSupervisorStvec (
+ VOID
+ );
+
+UINT64
+RiscVGetSupervisorTrapCause (
+ VOID
+ );
+
+VOID
+RiscVSetSupervisorAddressTranslationRegister (
+ IN UINT64
+ );
+
+UINT64
+RiscVReadTimer (
+ VOID
+ );
+
+VOID
+RiscVEnableTimerInterrupt (
+ VOID
+ );
+
+VOID
+RiscVDisableTimerInterrupt (
+ VOID
+ );
+
+VOID
+RiscVClearPendingTimerInterrupt (
+ VOID
+ );
+
#endif // defined (MDE_CPU_RISCV64)
#if defined (MDE_CPU_LOONGARCH64)
diff --git a/MdePkg/Library/BaseLib/RiscV64/CpuScratch.S
b/MdePkg/Library/BaseLib/RiscV64/CpuScratch.S
new file mode 100644
index ..5492a500eb5e
--- /dev/null
+++ b/MdePkg/Library/BaseLib/RiscV64/CpuScratch.S
@@ -0,0 +1,31 @@
+//--
+//
+// CPU scratch register related functions for RISC-V
+//
+// Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
reserved.
+//
+// SPDX-License-Identifier: BSD-2-Clause-Patent
+//
+//--
+
+#include
+
+.data
+.align 3
+.section .text
+
+//
+// Set Supervisor mode scratch.
+// @param a0 : Value set to Supervisor mode scratch
+//
+ASM_FUNC (RiscVSetSupervisorScratch)
+csrw CSR_SSCRATCH, a0
+ret
+
+//
+// Get Supervisor mode scratch.
+// @retval a0 : Value in Supervisor mode scratch
+//
+ASM_FUNC (RiscVGetSupervisorScratch)
+csrr a0, CSR_SSCRATCH
+ret
diff --git a/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
b/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
new file mode 100644
index ..39a06efa51ef
--- /dev/null
+++ b/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
@@ -0,0 +1,23 @@
+//--
+//
+// Read CPU timer
+//
+// Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
reserved.
+//
+// SPDX-License-Identifier: BSD-2-Clause-Patent
+//
+//--
+
+#include
+
+.data
+.align 3
+.section .text
+
+//
+// Read TIME CSR.
+// @retval a0 : 64-bit timer.
+//
+ASM_FUNC (RiscVReadTimer)
+csrr a0, CSR_TIME
+ret
diff --git a/MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S
b/MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S
index 87b3468fc7fd..6a1b90a7e45c 100644
--- a/MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S
+++ b/MdePkg/Library/BaseLib/RiscV64/RiscVInterrupt.S
@@ -8,13 +8,13 @@
//
//--
+#include
+
ASM_GLOBAL ASM_PFX(RiscVDisableSupervisorModeInterrupts)
ASM_GLOBAL ASM_PFX(RiscVEnableSupervisorModeInterrupt)
ASM_GLOBAL ASM_PFX(RiscVGetSupervisorModeInterrupts)
-#define SSTATUS_SIE 0x0002
-#define CSR_SSTATUS 0x100
- #define SSTATUS_SPP_BIT_POSITION 8
+#define SSTATUS_SPP_BIT_POSITION 8
//
// This routine disables supervisor mode interrupt
@@ -53,11 +53,56 @@ InTrap:
ret
//
+// Set Supervisor mode trap vector.
+// @param a0 : Value set to Supervisor mode trap vector
+//
+ASM_FUNC (RiscVSetSupervisorStvec)
+csrrw a1, CSR_STVEC, a0
+ret
+
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 01/19] MdePkg/Register: Add register definition header files for RISC-V
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 Add register definitions and access routines for RISC-V. These headers are leveraged from opensbi repo. Cc: Daniel Schaefer Cc: Michael D Kinney Cc: Liming Gao Cc: Zhiguang Liu Signed-off-by: Sunil V L Acked-by: Abner Chang Reviewed-by: Andrei Warkentin Reviewed-by: Michael D Kinney --- MdePkg/Include/Register/RiscV64/RiscVEncoding.h | 119 MdePkg/Include/Register/RiscV64/RiscVImpl.h | 25 2 files changed, 144 insertions(+) diff --git a/MdePkg/Include/Register/RiscV64/RiscVEncoding.h b/MdePkg/Include/Register/RiscV64/RiscVEncoding.h new file mode 100644 index ..5c2989b797bf --- /dev/null +++ b/MdePkg/Include/Register/RiscV64/RiscVEncoding.h @@ -0,0 +1,119 @@ +/** @file + RISC-V CSR encodings + + Copyright (c) 2019, Western Digital Corporation or its affiliates. All rights reserved. + Copyright (c) 2022, Ventana Micro Systems Inc. All rights reserved. + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#ifndef RISCV_ENCODING_H_ +#define RISCV_ENCODING_H_ + +#define MSTATUS_SIE 0x0002UL +#define MSTATUS_MIE 0x0008UL +#define MSTATUS_SPIE_SHIFT 5 +#define MSTATUS_SPIE(1UL << MSTATUS_SPIE_SHIFT) +#define MSTATUS_UBE 0x0040UL +#define MSTATUS_MPIE0x0080UL +#define MSTATUS_SPP_SHIFT 8 +#define MSTATUS_SPP (1UL << MSTATUS_SPP_SHIFT) +#define MSTATUS_MPP_SHIFT 11 +#define MSTATUS_MPP (3UL << MSTATUS_MPP_SHIFT) + +#define SSTATUS_SIE MSTATUS_SIE +#define SSTATUS_SPIE_SHIFT MSTATUS_SPIE_SHIFT +#define SSTATUS_SPIEMSTATUS_SPIE +#define SSTATUS_SPP_SHIFT MSTATUS_SPP_SHIFT +#define SSTATUS_SPP MSTATUS_SPP + +#define IRQ_S_SOFT1 +#define IRQ_VS_SOFT 2 +#define IRQ_M_SOFT3 +#define IRQ_S_TIMER 5 +#define IRQ_VS_TIMER 6 +#define IRQ_M_TIMER 7 +#define IRQ_S_EXT 9 +#define IRQ_VS_EXT10 +#define IRQ_M_EXT 11 +#define IRQ_S_GEXT12 +#define IRQ_PMU_OVF 13 + +#define MIP_SSIP(1UL << IRQ_S_SOFT) +#define MIP_VSSIP (1UL << IRQ_VS_SOFT) +#define MIP_MSIP(1UL << IRQ_M_SOFT) +#define MIP_STIP(1UL << IRQ_S_TIMER) +#define MIP_VSTIP (1UL << IRQ_VS_TIMER) +#define MIP_MTIP(1UL << IRQ_M_TIMER) +#define MIP_SEIP(1UL << IRQ_S_EXT) +#define MIP_VSEIP (1UL << IRQ_VS_EXT) +#define MIP_MEIP(1UL << IRQ_M_EXT) +#define MIP_SGEIP (1UL << IRQ_S_GEXT) +#define MIP_LCOFIP (1UL << IRQ_PMU_OVF) + +#define SIP_SSIP MIP_SSIP +#define SIP_STIP MIP_STIP + +#define PRV_U 0UL +#define PRV_S 1UL +#define PRV_M 3UL + +#define SATP64_MODE 0xF000ULL +#define SATP64_ASID 0x0000ULL +#define SATP64_PPN 0x0FFFULL + +#define SATP_MODE_OFF 0UL +#define SATP_MODE_SV32 1UL +#define SATP_MODE_SV39 8UL +#define SATP_MODE_SV48 9UL +#define SATP_MODE_SV57 10UL +#define SATP_MODE_SV64 11UL + +#define SATP_MODE SATP64_MODE + +/* User Counters/Timers */ +#define CSR_CYCLE 0xc00 +#define CSR_TIME 0xc01 + +/* Supervisor Trap Setup */ +#define CSR_SSTATUS 0x100 +#define CSR_SEDELEG 0x102 +#define CSR_SIDELEG 0x103 +#define CSR_SIE 0x104 +#define CSR_STVEC0x105 + +/* Supervisor Configuration */ +#define CSR_SENVCFG 0x10a + +/* Supervisor Trap Handling */ +#define CSR_SSCRATCH 0x140 +#define CSR_SEPC 0x141 +#define CSR_SCAUSE0x142 +#define CSR_STVAL 0x143 +#define CSR_SIP 0x144 + +/* Supervisor Protection and Translation */ +#define CSR_SATP 0x180 + +/* Trap/Exception Causes */ +#define CAUSE_MISALIGNED_FETCH 0x0 +#define CAUSE_FETCH_ACCESS 0x1 +#define CAUSE_ILLEGAL_INSTRUCTION 0x2 +#define CAUSE_BREAKPOINT0x3 +#define CAUSE_MISALIGNED_LOAD 0x4 +#define CAUSE_LOAD_ACCESS 0x5 +#define CAUSE_MISALIGNED_STORE 0x6 +#define CAUSE_STORE_ACCESS 0x7 +#define CAUSE_USER_ECALL0x8 +#define CAUSE_SUPERVISOR_ECALL 0x9 +#define CAUSE_VIRTUAL_SUPERVISOR_ECALL 0xa +#define CAUSE_MACHINE_ECALL 0xb +#define CAUSE_FETCH_PAGE_FAULT 0xc +#define CAUSE_LOAD_PAGE_FAULT 0xd +#define CAUSE_STORE_PAGE_FAULT 0xf +#define CAUSE_FETCH_GUEST_PAGE_FAULT0x14 +#define CAUSE_LOAD_GUEST_PAGE_FAULT 0x15 +#define CAUSE_VIRTUAL_INST_FAULT0x16 +#define CAUSE_STORE_GUEST_PAGE_FAULT0x17 + +#endif diff --git a/MdePkg/Include/Register/RiscV64/RiscVImpl.h b/MdePkg/Include/Register/RiscV64/RiscVImpl.h new file mode 100644 index ..ee5c2ba60377 --- /dev/null +++ b/MdePkg/Include/Register/RiscV64/RiscVImpl.h @@ -0,0 +1,25 @@ +/** @file + RISC-V package definitions. + + Copyright (c) 2016 - 2022, Hewlett Packard Enterprise Development LP. All rights reserved. + + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#ifndef RISCV_IMPL_H_ +#define RISCV_IMPL_H_ + +#include + +#define _ASM_FUNC(Name, Section)\ + .global Name ; \ + .sect
[edk2-devel] [edk2-staging/RiscV64QemuVirt PATCH V8 00/19] Add support for RISC-V virt machine
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076 Add support for RISC-V qemu virt machine. Most of the changes are migrated from edk2-platforms repo and added qemu specific libraries under OvmfPkg. The series has passed CI tests (https://github.com/tianocore/edk2/pull/4023) These changes are available at: https://github.com/vlsunil/edk2/tree/RiscV64QemuVirt_V8 The series can be tested as per instructions @ https://github.com/vlsunil/riscv-uefi-edk2-docs/wiki/RISC-V-Qemu-Virt-support Changes since V7: 1) Addressed feedbacks from Mike and Ray. 2) Added Anrdrei as another reviewer for RiscVVirt 3) Rebased 4) Added RB and ACK tags Changes since V6: 1) Took inspiration from IntelTdx and added all RISC-V qemu related libraries and modules in OvmfPkg/RiscVVirt instead of directly under OvmfPkg/Library. Hoping for quicker review since now it shouldn't affect the existing OvmfPkg libraries/modules. 2) Dropped migration of NvVarStoreFormattedLib for now to avoid MdeModulePkg changes. Currently RISC-V Qemu doesn't support separate variable flash. So, it can be taken as a separate activity in future when required. 3) Rebased and new CI test request passed Changes since V5: 1) Avoided editing the existing INF files (as per feedback from Ray Ni). This reduced several refactor patches. 2) Moved to PEI less design (as per suggestion from Andrei Warkentin) 3) Added PciCpuIO2Dxe driver in OvmfPkg. 4) Removed APRIORI requirement in DSC/FDF infrastructure files. Now they are very similar to ArmVirtQemu. 5) Addressed Heinrich's feedback. 6) Rebased and added ack tags Changes since V4: 1) Rebased and added ACKs 2) Dropped few patches related to VirtNorFlashDxe since they are already taken care by Ard. Changes since V3: 1) Addressed Abner's comments 2) Changed folder name from Ia32_X64 to Ia32X64 as per latest guidelines. 2) Rebased Changes since V2: 1) Fixed issues detected by CI 2) Added an extra patch to fix up the consumers of NvVarStoreFormattedLib Changes since V1: 1) Added couple of patches from Ard to optimize the NorFlashDxe in Ovmf. Note: There will be a separate patch series in future to update existing consumers of NorFlashDxe driver. 2) Migrated NvVarStoreFormattedLib from EmbeddedPkg to MdeModulePkg 3) Created Null instance of the NorFlashPlatformLib library class 4) Moved NorFlashPlatformLib.h from ArmPlatformPkg Cc: Abner Chang Cc: Daniel Schaefer Cc: Michael D Kinney Cc: Liming Gao Cc: Ard Biesheuvel Cc: Jiewen Yao Cc: Jordan Justen Cc: Gerd Hoffmann Cc: Sami Mujawar Cc: Leif Lindholm Cc: Eric Dong Cc: Ray Ni Cc: Rahul Kumar Cc: Zhiguang Liu Cc: Anup Patel Cc: Heinrich Schuchardt Cc: Andrei Warkentin Sunil V L (19): MdePkg/Register: Add register definition header files for RISC-V MdePkg/BaseLib: RISC-V: Add few more helper functions MdePkg: Add BaseRiscVSbiLib Library for RISC-V UefiCpuPkg: Add RISCV_EFI_BOOT_PROTOCOL related definitions UefiCpuPkg: Add BaseRiscV64CpuExceptionHandlerLib UefiCpuPkg: Add BaseRiscV64CpuTimerLib library UefiCpuPkg: Add CpuTimerDxeRiscV64 module UefiCpuPkg: Add CpuDxeRiscV64 module UefiCpuPkg/UefiCpuPkg.ci.yaml: Ignore RISC-V file ArmVirtPkg/PlatformHasAcpiDtDxe: Move to OvmfPkg ArmVirtPkg: Fix up the location of PlatformHasAcpiDtDxe OvmfPkg/RiscVVirt: Add PlatformBootManagerLib library OvmfPkg/RiscVVirt: Add PrePiHobListPointerLib library OvmfPkg/RiscVVirt: Add ResetSystemLib library OvmfPkg/RiscVVirt: Add VirtNorFlashPlatformLib library OvmfPkg/RiscVVirt: Add PciCpuIo2Dxe module OvmfPkg/RiscVVirt: Add SEC module OvmfPkg/RiscVVirt: Add build files for Qemu Virt platform Maintainers.txt: Add entry for OvmfPkg/RiscVVirt ArmVirtPkg/ArmVirtPkg.dec |9 - MdePkg/MdePkg.dec |4 + OvmfPkg/OvmfPkg.dec |7 + UefiCpuPkg/UefiCpuPkg.dec |7 + OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 336 ++ ArmVirtPkg/ArmVirtCloudHv.dsc |2 +- ArmVirtPkg/ArmVirtQemu.dsc |4 +- ArmVirtPkg/ArmVirtQemuKernel.dsc |2 +- MdePkg/MdePkg.dsc |3 + ArmVirtPkg/ArmVirtQemu.dsc => OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc
Re: [edk2-devel] [PATCH v4 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data
Gerd,
That requires changing PI spec and all HOB consuming logic.
But if you have a simple idea, please advise.
Thanks,
Ray
> -Original Message-
> From: Gerd Hoffmann
> Sent: Friday, February 10, 2023 7:24 PM
> To: Wu, Jiaxin
> Cc: devel@edk2.groups.io; Dong, Eric ; Ni, Ray
> ; Zeng, Star ; Laszlo Ersek
> ; Kumar, Rahul R
> Subject: Re: [PATCH v4 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB
> Data
>
> Hi,
>
> > +#pragma pack(1)
> > +typedef struct {
> > + ///
> > + /// CpuIndex tells which CPU range this specific HOB instance described.
> > + /// If CpuIndex is set to 0, it indicats the HOB describes the CPU from
> > 0 to
> > + /// NumberOfCpus - 1. The HOB list may contains multiple this HOB
> instances.
> > + /// Each HOB instances describe the information for CPU from CpuIndex to
> > + /// CpuIndex + NumberOfCpus - 1. The instance order in the HOB list is
> random
> > + /// so consumer can not assume the CpuIndex of first instance is 0.
> > + ///
> > + UINT32CpuIndex;
> > + ///
> > + /// Describes the Number of all max supported processors.
> > + ///
> > + UINT32NumberOfProcessors;
> > + ///
> > + /// Pointer to SmBase address for each Processors.
> > + ///
> > + UINT64SmBase[1];
> > +} SMM_BASE_HOB_DATA;
> > +#pragma pack()
>
> No generic chunked hobs as suggested/discussed on v3 of this series?
> Why not?
>
> take care,
> Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99980): https://edk2.groups.io/g/devel/message/99980
Mute This Topic: https://groups.io/mt/96871372/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/2] MdePkg: Update code to be more C11 compliant by using __func__
On Fri, 10 Feb 2023 at 02:21, Rebecca Cran wrote: > > Mike, > > Yes, it passed CI - see https://github.com/tianocore/edk2/pull/4022 . > > I wasn't sure if we cared about EBC builds these days. Given the link on > https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html > to the compiler goes to a generic page that doesn't mention it, is it > possible to get a copy if I want to verify if changes I'm making are > compatible? > We tried to get access to this at Linaro, but I don't think it is still available. Leif may remember better. > I know there was a project to add support for building EBC using LLVM, > but I'm not sure if anything came of it. > No that never went anywhere afaik. The problem was that, in EBC, sizeof() is not a compile time constant, and this breaks too many assumptions in the existing frontends, so this would only be feasible if we restricted ourselves to a specialized version of EBC that targets 64-bit architectures only, but this seems like a lot of effort for questionable benefits. Given that X64 code can run on arm64 under emulation without too many problems [0], and that the 32-bit ARM procedure call standard is fundamentally incompatible with EBC, the issue lost its urgency somewhat, at least from the side of ARM at the time. [0] https://github.com/ardbiesheuvel/X86EmulatorPkg I wonder whether we should simply drop EBC support? It is unlikely that all the changes that went into EDK2 over the years have not caused a single EBC regression in the library components that are needed to build UEFI drivers that target EBC. Or is this still being used/tested internally at Intel? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99979): https://edk2.groups.io/g/devel/message/99979 Mute This Topic: https://groups.io/mt/96855618/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe
[1] ConvertPages: range 100 - 41AEFFF covers multiple entries^M Accepting all memory^M Accepting all memory^M This looks to me like it is entering the 'accept' path twice, and so ExitBootServices() is failing twice, resulting in a failed boot. Thanks for having a look. Yes, I was also wondering why its calling "Accepting all memory" twice. I tried to put some printf in error path of "accept" but does seem hitting any. Also, accepting memory which is already accepted (pvalidate in case of SEV SNP) can be problematic. Thanks, Pankaj -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99978): https://edk2.groups.io/g/devel/message/99978 Mute This Topic: https://groups.io/mt/96534752/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 5/5] OvmfPkg/SmmCpuFeaturesLib: Check SmBase relocation supported or not
On Fri, Feb 10, 2023 at 02:05:19PM +0800, Jiaxin Wu wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337 > > This patch is to check SmBase relocation supported or not. > If gSmmBaseHobGuid found, means SmBase info has been relocated > and recorded in the SmBase array. ASSERT it's not supported in OVMF. > > Cc: Eric Dong > Cc: Ray Ni > Cc: Zeng Star > Cc: Laszlo Ersek > Cc: Gerd Hoffmann > Cc: Rahul Kumar > Signed-off-by: Jiaxin Wu Reviewed-by: Gerd Hoffmann take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99977): https://edk2.groups.io/g/devel/message/99977 Mute This Topic: https://groups.io/mt/96871375/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 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info
> Mainly changes as below: > * Assume the biggest possibility of tile size is 8k. > * Combine 2 SMIs (gcSmmInitTemplate & gcSmiHandlerTemplate) into one > (gcSmiHandlerTemplate), the new SMI handler needs to run to 2 paths: > one to SmmCpuFeaturesInitializeProcessor(), the other to SMM Core > Entry Point. > * Issue SMI IPI (All Excluding Self SMM IPI + BSP SMM IPI) for first > SMI init before normal SMI sources happen. > * Call SmmCpuFeaturesInitializeProcessor() in parallel. Four changes in a single patch. Please split them up. thanks, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99976): https://edk2.groups.io/g/devel/message/99976 Mute This Topic: https://groups.io/mt/96871374/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 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data
Hi,
> +#pragma pack(1)
> +typedef struct {
> + ///
> + /// CpuIndex tells which CPU range this specific HOB instance described.
> + /// If CpuIndex is set to 0, it indicats the HOB describes the CPU from 0
> to
> + /// NumberOfCpus - 1. The HOB list may contains multiple this HOB
> instances.
> + /// Each HOB instances describe the information for CPU from CpuIndex to
> + /// CpuIndex + NumberOfCpus - 1. The instance order in the HOB list is
> random
> + /// so consumer can not assume the CpuIndex of first instance is 0.
> + ///
> + UINT32CpuIndex;
> + ///
> + /// Describes the Number of all max supported processors.
> + ///
> + UINT32NumberOfProcessors;
> + ///
> + /// Pointer to SmBase address for each Processors.
> + ///
> + UINT64SmBase[1];
> +} SMM_BASE_HOB_DATA;
> +#pragma pack()
No generic chunked hobs as suggested/discussed on v3 of this series?
Why not?
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99975): https://edk2.groups.io/g/devel/message/99975
Mute This Topic: https://groups.io/mt/96871372/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe
On Fri, 10 Feb 2023 at 09:00, Gupta, Pankaj wrote: > > > >>> With this patch I observe an issue where my Linux (6.2.0-rc7) guest > >>> recur to Bootloader menu again. I am testing this with SEV SNP (w/o > >>> UPM). Also, guest don't have lazy memory acceptance support. > >>> > >> > >> Thanks for the report. I'll try to reproduce it on our UEFI and if I'm > >> unable, then we'll discuss next steps. > >> > > > > I don't see this in our test Ubuntu 22.04 image from Canonical. Do you > > have a boot log you could send me? I'm not sure I understand what you > > mean by recurring to the Bootloader menu. On ExitBootServices, the > > Thank you for looking into it. > > Its going again to bootloader menu after I slecet the booting OS. > > > memory key will end up changing and the caller will need to call > > GetMemoryMap and try EBS again, but I don't know why that would send > > you to a bootmenu. > > Sorry, could not understand this. As I am not very familiar with the efi > code flow. Could you please elaborate a bit. > > I see these[1] errors: Also attached the complete log. > > Thanks, > Pankaj > > [1] > ConvertPages: range 100 - 41AEFFF covers multiple entries^M > Accepting all memory^M > Accepting all memory^M This looks to me like it is entering the 'accept' path twice, and so ExitBootServices() is failing twice, resulting in a failed boot. > EFI stub: ERROR: exit_boot() failed!^M > EFI stub: ERROR: efi_main() failed!^M > Image Return Status = Invalid Parameter^M > BdsDxe: failed to start Boot0006 "ubuntu" from > HD(1,GPT,0482E38B-B35F-4359-A017-F7B0E924FECD,0x800,0x10)/\EFI\ubuntu-hdd2\shimx64.efi: > Invalid Parameter^M -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99974): https://edk2.groups.io/g/devel/message/99974 Mute This Topic: https://groups.io/mt/96534752/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg: Contiguous memory allocation and code clean-up.
Hi, > 3) The special case you have to handle is not running on a AMD > Processor, but AmdSev being active (i.e. UseSevEsAPMethod == True). > Otherwise it should be just standard Ia32 and X64, there should be no > need to check whenever you are running on a AMD processor. > > I understand your point, but for both cases (check AmdSev, standard > Ia32 and X64), AMD related code will be changed. We would like to keep > the original implementation as much as possible. Well, the original implementation never checks for an AMD Processor, it only checks whenever SEV-ES is active (and sets UseSevEsAPMethod in that case). So why you are adding that check? take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99973): https://edk2.groups.io/g/devel/message/99973 Mute This Topic: https://groups.io/mt/96807120/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 1/1] MdePkg: Add DDR5 SPD defs to IndustryStandard per JESD400-5A.01
Yes I’ve verified locally that this file builds. It doesn’t pass CI though
since like the DDR4 header it has fields that begin with a lower-case letter.
I added the include of Uefi/UefiBaseType.h because the UEFI type UINT8 is used.
—
Rebecca
On Thu, Feb 9, 2023, at 10:23 PM, gaoliming via groups.io wrote:
> Rebecca:
> Have you verified this header file with build? For example, include this
> new header file into module, and make sure this module pass build.
>
>> -邮件原件-
>> 发件人: devel@edk2.groups.io 代表 Rebecca Cran
>> 发送时间: 2023年2月9日 1:48
>> 收件人: devel@edk2.groups.io
>> 抄送: Rebecca Cran ; Liming Gao
>> ; Michael D Kinney ;
>> Zhiguang Liu
>> 主题: [edk2-devel] [PATCH 1/1] MdePkg: Add DDR5 SPD defs to
>> IndustryStandard per JESD400-5A.01
>>
>> Copying the style of SdramSpdDdr4.h, add DDR5 SPD definitions to
>> SpdDdr5.h per JEDEC JESD400-5A.01 specification
>> (https://www.jedec.org/standards-documents/docs/jesd400-5a01).
>>
>> Signed-off-by: Rebecca Cran
>> Cc: Liming Gao
>> Cc: Michael D Kinney
>> Cc: Zhiguang Liu
>> ---
>> MdePkg/Include/IndustryStandard/SpdDdr5.h | 541
>>
>> 1 file changed, 541 insertions(+)
>>
>> diff --git a/MdePkg/Include/IndustryStandard/SpdDdr5.h
>> b/MdePkg/Include/IndustryStandard/SpdDdr5.h
>> new file mode 100644
>> index ..305ab69af852
>> --- /dev/null
>> +++ b/MdePkg/Include/IndustryStandard/SpdDdr5.h
>> @@ -0,0 +1,541 @@
>> +/** @file
>> + This file contains definitions for DDR5 SPD.
>> +
>> + Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights
>> reserved.
>> + Copyright (c) 2016, Intel Corporation. All rights reserved.
>> + SPDX-License-Identifier: BSD-2-Clause-Patent
>> +
>> + @par Revision Reference:
>> +- DDR5 Serial Presence Detect (SPD), Document Release 1.1 (Jan 2023)
>> + https://www.jedec.org/standards-documents/docs/jesd400-5a01
>> +**/
>> +
>> +#ifndef SPD_DDR5_H_
>> +#define SPD_DDR5_H_
>> +
>> +#include
>
> Is there any uefi definition used in this header file? If no, this include
> can be removed.
>
> Thanks
> Liming
>
>> +
>> +#pragma pack (push, 1)
>> +
>> +typedef union {
>> + struct {
>> +UINT8BetaLevel3_0 : 4;///< Bits
>> 3:0
>> +UINT8BytesTotal : 3;///< Bits
>> 6:4
>> +UINT8BetaLevel4 : 1;///< Bits
>> 7:7
>> + } Bits;
>> + UINT8Data;
>> +} SPD5_DEVICE_DESCRIPTION_STRUCT;
>> +
>> +typedef union {
>> + struct {
>> +UINT8Minor : 4; ///< Bits
>> 3:0
>> +UINT8Major : 4; ///< Bits
>> 7:4
>> + } Bits;
>> + UINT8Data;
>> +} SPD5_REVISION_STRUCT;
>> +
>> +typedef union {
>> + struct {
>> +UINT8Type : 8;///< Bits
>> 7:0
>> + } Bits;
>> + UINT8Data;
>> +} SPD5_DEVICE_TYPE_STRUCT;
>> +
>> +typedef union {
>> + struct {
>> +UINT8ModuleType : 4; ///< Bits
>> 3:0
>> +UINT8HybridMedia : 3; ///< Bits
>> 6:4
>> +UINT8Hybrid : 1; ///< Bits
>> 7:7
>> + } Bits;
>> + UINT8Data;
>> +} SPD5_MODULE_TYPE_STRUCT;
>> +
>> +typedef union {
>> + struct {
>> +UINT8Density : 5; ///< Bits
>> 4:0
>> +UINT8Die : 3; ///< Bits
>> 7:5
>> + } Bits;
>> + UINT8Data;
>> +} SPD5_SDRAM_DENSITY_PACKAGE_STRUCT;
>> +
>> +typedef union {
>> + struct {
>> +UINT8RowAddress: 5; ///< Bits
>> 4:0
>> +UINT8ColumnAddress : 3; ///< Bits
>> 7:5
>> + } Bits;
>> + UINT8Data;
>> +} SPD5_SDRAM_ADDRESSING_STRUCT;
>> +
>> +typedef union {
>> + struct {
>> +UINT8Reserved : 5; ///< Bits
>> 4:0
>> +UINT8IoWidth : 3; ///< Bits
>> 7:5
>> + } Bits;
>> + UINT8Data;
>> +} SPD5_SDRAM_IO_WIDTH_STRUCT;
>> +
>> +typedef union {
>> + struct {
>> +UINT8BanksPerBankGroup : 3;///< Bits
>> 2:0
>> +UINT8Reserved : 2;///< Bits
>> 4:3
>> +UINT8BankGroups: 3;///< Bits
>> 7:5
>> + } Bits;
>> + UINT8Data;
>> +} SPD5_SDRAM_BANKS_STRUCT;
>> +
>> +typedef union {
>> + struct {
>> +UINT8Reserved0 : 1; ///< Bits
>> 0:0
>> +UINT8Mbist_mPpr : 1; ///< Bits
>> 1:1
>> +UINT8Reserved1 : 2; ///< Bits
>> 3:2
>> +UINT8BL32: 1; ///< Bits
>> 4:4
>> +UINT8SPprUndo_Lock : 1; ///< Bits
>> 5:5
>> +UINT8Reserved2 : 1; ///< Bits
>> 6:6
>> +UINT8SPprGranularity : 1; ///< Bits 7:7
>> + } Bits;
>> + UINT8Data;
>> +} SPD5_SDRAM_BL32_POST_PACKAGE_REPAIR
Re: [edk2-devel] [PATCH v4 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info
Hi Jiaxin, 1) mSmmInitialized *must* be volatile. Your current code may cause anything, from skipping waiting entirely (the loop is optimized away as the compiler considers it free from side effects) to stalling (the memory access is optimized away as the compiler considers it locally-immutable). 2) ASSERTs on memory allocation failures are one of the most terrible edk2 "paradigms". 3) Comparisons against boolean constants are not allowed by the code style spec. Best regards, Marvin -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99971): https://edk2.groups.io/g/devel/message/99971 Mute This Topic: https://groups.io/mt/96871374/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v3 0/4] ArmPkg/SecurityPkg: Fixes for ArmTrngLib/RngDxe
Hello Jiewen, Jian, Just a reminder in case this was forgotten, Regards, Pierre On 1/9/23 13:26, Pierre Gondois wrote: Hello, I was wondering if I should re-arrange the patch in any way/there was any concern with the patch set. The first patch of serie was taken, but the other ones are pending, Regards, Pierre On 11/28/22 14:34, PierreGondois via groups.io wrote: Hello Ard, On 11/26/22 15:33, Ard Biesheuvel wrote: On Thu, 24 Nov 2022 at 17:18, wrote: From: Pierre Gondois v1: - https://edk2.groups.io/g/devel/message/96356 v2: - https://edk2.groups.io/g/devel/message/96434 - Reformulate commit message. - Do not warn if no algorithm is found as the message would be printed on non-Arm platforms. v3: - Add the following patches: 1. ArmPkg/ArmTrngLib: Remove ASSERTs in ArmTrngLibConstructor() Requested by Ard. Cf https://edk2.groups.io/g/devel/message/96495 2. SecurityPkg/RngDxe: Conditionally install EFI_RNG_PROTOCOL Do not install EFI_RNG_PROTOCOL if no RNG algorithm is available. Cf. https://edk2.groups.io/g/devel/message/96494 3. SecurityPkg/RngDxe: Fix Rng algo selection for Arm Coming from v2 patch being split. Some issues were found by Ard/Sami on the RngDxe/ArmTrngLib after recent patches were merged. This patch serie intends to fix them. Pierre Gondois (4): ArmPkg/ArmTrngLib: Remove ASSERTs in ArmTrngLibConstructor() Thanks for the fixed Reviewed-by: Ard Biesheuvel I pushed this one as #3663 (pending CI verification atm) SecurityPkg/RngDxe: Correctly update mAvailableAlgoArrayCount SecurityPkg/RngDxe: Conditionally install EFI_RNG_PROTOCOL SecurityPkg/RngDxe: Fix Rng algo selection for Arm The remaining code still looks a bit clunky to me. Can't we just return an error from the library constructor of the library cannot initialize due to a missing prerequisite? In RngDriverEntry(), GetAvailableAlgorithms() probe the available RNG algorithms. If there are none, then we return an error code. Otherwise we install EFI_RNG_PROTOCOL. I assume the prerequisite you a referring to is 'checking there is at least one available RNG algorithm that RngDxe can use', so if ArmTrngLib's constructor fails, we should not prevent RngDxe to be loaded (as the RngLib could be used for instance). Does it answer your question, or did I understand it incorrectly ? Regards, Pierre ArmPkg/Library/ArmTrngLib/ArmTrngLib.c| 5 - .../RandomNumberGenerator/RngDxe/ArmRngDxe.c | 18 +- .../RngDxe/Rand/RngDxe.c | 9 - .../RandomNumberGenerator/RngDxe/RngDxe.c | 19 ++- 4 files changed, 27 insertions(+), 24 deletions(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99970): https://edk2.groups.io/g/devel/message/99970 Mute This Topic: https://groups.io/mt/95240503/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg: Contiguous memory allocation and code clean-up.
Hi Gerd,
1) You convert size to pages, pages to size, size to pages again.
Agree. I will update it.
2) Also you don't want stack and code being on the same page
Patch 5 ensures that stack and code are in different pages and also ensure
alignment. I will update it patch2 as well in v2.
3) The special case you have to handle is not running on a AMD Processor, but
AmdSev being active (i.e. UseSevEsAPMethod == True). Otherwise it should be
just standard
Ia32 and X64, there should be no need to check whenever you are running on a
AMD processor.
I understand your point, but for both cases (check AmdSev, standard Ia32 and
X64), AMD related code will be changed. We would like to keep the original
implementation as much as possible.
Best regards,
Yuanhao
-Original Message-
From: Gerd Hoffmann
Sent: Wednesday, February 8, 2023 7:10 PM
To: devel@edk2.groups.io; Xie, Yuanhao
Cc: Dong, Guo ; Ni, Ray ; Rhodes, Sean
; Lu, James ; Guo, Gua
Subject: Re: [edk2-devel] [PATCH 2/5] UefiCpuPkg: Contiguous memory allocation
and code clean-up.
> + AllocSize = EFI_PAGES_TO_SIZE (
> +EFI_SIZE_TO_PAGES (
> + CpuMpData->CpuCount * AP_SAFE_STACK_SIZE + ApLoopFuncSize
> + )
> +);
> + Status = gBS->AllocatePages (
> + AllocateMaxAddress,
> + EfiReservedMemoryType,
> + EFI_SIZE_TO_PAGES (AllocSize),
> + &Address
> + );
Hmm? You convert size to pages, pages to size, size to pages again.
Also you don't want stack and code being on the same page, so I guess the logic
you actually need is this:
StackPages = EFI_SIZE_TO_PAGES(CpuMpData->CpuCount * AP_SAFE_STACK_SIZE);
FuncPages = EFI_SIZE_TO_PAGES(ApLoopFuncSize)
gBS->AllocatePages(..., StackPages + FuncPages, ...);
> +//
> +// Union holds the relocate APs loop entries for different cases //
> +typedef union {
> + VOID *Data;
> + ASM_RELOCATE_AP_LOOP_AMD64Amd64Entry; // 64-bit AMD Processor
> + ASM_RELOCATE_AP_LOOP GenericEntry; // Intel Processor (32-bit or
> 64-bit), or 32-bit AMD Processor
> +} RELOCATE_AP_LOOP_ENTRY;
I'm sure I've mentioned this before. The special case you have to handle is
not running on a AMD Processor, but AmdSev being active (i.e. UseSevEsAPMethod
== True). Otherwise it should be just standard
Ia32 and X64, there should be no need to check whenever you are running on a
AMD processor.
take care,
Gerd
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99969): https://edk2.groups.io/g/devel/message/99969
Mute This Topic: https://groups.io/mt/96807120/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 2/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data
Hi Ray and Jiaxin, Quick reminder that [1] invokes undefined behaviour and [0] is not legal C, but a compiler extension. The canonical way is a flexible array member using []. Off-topic and nitpicking, but I started wondering why so many structures are packed. For UEFI, packing would only help saving RAM when there‘s actual padding (unlike this case, where there isn‘t). All architectures require natural data alignment („unless specifies otherwise“), so there should be no compatibility concerns for structures specific to UEFI and UEFI PI ever. When considering ABIs outside UEFI, even then natural alignment is the strictest realistically possible outside super niche platforms, as even executable formats don‘t pack their structures (this structure also is inherently naturally aligned). Best regards, Marvin -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99968): https://edk2.groups.io/g/devel/message/99968 Mute This Topic: https://groups.io/mt/96871372/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 00/10] OvmfPkg: add Crypto Driver support
On Thu, Feb 09, 2023 at 05:46:15PM +0100, Ard Biesheuvel wrote: > On Thu, 9 Feb 2023 at 11:27, Gerd Hoffmann wrote: > > > > Known problem: the NOOPT builds fail due to PEI becoming too big. > > > > What is the reason for doing these NOOPT builds? > > They are very useful for doing single step debugging with GDB. On ARM, > I use the NOOPT builds fairly regularly. Can LTO be enabled for the NOOPT build? Or depends that on optimizations being turned on? take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99967): https://edk2.groups.io/g/devel/message/99967 Mute This Topic: https://groups.io/mt/96850388/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
