summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* pip: update edk2-pytool-extensions requirementdependabot/pip/edk2-pytool-extensions-approx-eq-0.28.0dependabot[bot]9 days1-1/+1
| | | | | | | | | | | | | Updates the requirements on [edk2-pytool-extensions](https://github.com/tianocore/edk2-pytool-extensions) to permit the latest version. - [Release notes](https://github.com/tianocore/edk2-pytool-extensions/releases) - [Commits](https://github.com/tianocore/edk2-pytool-extensions/compare/v0.27.10...v0.28.0) --- updated-dependencies: - dependency-name: edk2-pytool-extensions dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
* Maintainers.txt: update Leif's email addressLeif Lindholm9 days2-9/+10
| | | | | | | | Qualcomm is (finally) migrating its email infrastructure for open source developers. Update Maintainers.txt (and .mailmap) to reflect. Github username remains unchanged. Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
* ArmPlatformPkg: Honour RES1 fields in CPTR_EL2Jessica Clarke9 days1-1/+2
| | | | | | | | | | | | | | | | | | | | | | | Unlike CPACR_EL1 whose reserved bits are solely RES0, CPTR_EL2 has some RES1 bits, and so we should not clear them unless we know what they mean. For example, when SVE was introduced, CPACR_EL1.ZEN occupied a RES0 field and thus 0 means trap (which is what we get at EL1), but CPTR_EL2.TZ occupied a RES1 field and thus 1 means trap, but we set it to 0, so the environment is inconsistent between EDK2 and EL1 and EL2. Another concrete case is for Morello, where the CEN/TC fields similarly gate access to capability register state, but also alter exception delivery and return, such that VBAR_ELx and ELR_ELx become capabilities. So long as software adheres to RES0/1 this is backwards-compatible, but since EDK2 does not do so here it inadvertently enables capability-based exception delivery and return and thus, when run at EL2, gets stuck in a trap loop when taking its first interrupt, but works just fine at EL1. Fix this by setting all the RES1 fields in CPTR_EL2, following the pattern for CPACR_EL1's non-zero initial value (due to setting FPEN so as to not trap on SIMD/FP use), tested by running ArmVirtQemu-AARCH64 (DEBUG) on Morello QEMU with EL2 enabled. Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
* MdePkg: Define AARCH64_CPTR_RES1 and AARCH64_CPTR_DEFAULTJessica Clarke9 days1-1/+3
| | | | | | | | | | These constants give the set of RES1 bits in CPTR_EL2, as 1s, and the default value to use for CPTR_EL2 in order to enable all known (or harmless) features but no unknown ones that require EL2 knowledge. This will be used by ArmPlatformPkg in the following commit, separated due to being different packages, even though the combined change is tiny. Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
* ArmPlatformPkg,MdePkg: Rename AARCH64 CPACR_CP_FULL_ACCESSJessica Clarke9 days2-7/+7
| | | | | | | | | | | | | | CP_FULL_ACCESS is a misnomer, we only enable access to SIMD/FP state, and although the register's mnemonic is CPACR_EL1, its full name is "Architectural Feature Access Control Register", with AArch64 having no coprocessors like AArch32 did, so the "CP" is also not appropriate. Rename it to show it's the default value we use on entry, and define it in terms of the existing CPACR_FPEN_FULL rather than a magic constant with the same value to more clearly document that fact. Also update comments to reflect all this (including the CPTR_EL2 case). Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
* ArmPlatformPkg: Document that we don't support HCR_EL2.E2H being setJessica Clarke9 days1-0/+2
| | | | | | | | | | | The existing code here predates its existence as it's assuming that CPTR_EL2 has the traditional layout rather than being like CPACR_EL1 (likely also true elsewhere for other registers), and the UEFI spec has nothing to say on the matter. One assumes the intent is that if you're in EL2 you're in EL2 proper, and it would be very strange to enter EDK2 with E2H set. Document this existing assumption. Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
* EmulatorPkg WinThunk: Use Win32 API to get Performance Frequency and CountYang Gang9 days1-4/+15
| | | | | | | | | | Then we can use correct TimerLib in another code, such as dpDynamicCommand(PerformanceLib). These API are from profileapi.h header and can refer to the link: https://learn.microsoft.com/en-us/windows/win32/api/profileapi/ Signed-off-by: Yang Gang <yanggang@byosoft.com.cn>
* FatPkg/FatPei: Simplify the GPT Header CheckJason1 Lin9 days1-36/+4
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4860 - The condition of GPT header checking is mismatched between PEI FatPei module in FatPkg and DXE PartitionDxe module in MdeModulePkg. - This patch is intended to simplify the checking condition within FatPei module to align with PartitionDxe module to reduce code flow gap between both of them. - Below of condition would be checked on GPT header, 1. GPT header signature value 2. GPT header CRC value 3. GPT header LBA value 4. GPT header size of partition entry Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
* MdePkg: MdeLibs.dsc.inc: Apply StackCheckLibNull to All Module TypesOliver Smith-Denny10 days34-118/+10
| | | | | | | | | | | | | | | Now that the ResetVectors are USER_DEFINED modules, they will not be linked against StackCheckLibNull, which were the only modules causing issues. So, we can now remove the kludge we had before and the requirement for every DSC to include StackCheckLibNull for SEC modules and just apply StackCheckLibNull globally. This also changes every DSC to drop the SEC definition of StackCheckLibNull. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* OvmfPkg: Make ResetVector USER_DEFINEDOliver Smith-Denny10 days12-12/+12
| | | | | | | | | | Following the change in UefiCpuPkg, this moves OvmfPkg's ResetVectors to USER_DEFINED modules to prevent any NULL libraries from being linked against them, allowing for expected behavior from the ResetVector and for simpler implementation of NULL libraries applied globally. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* UefiCpuPkg: Make the ResetVector USER_DEFINEDOliver Smith-Denny10 days2-2/+2
| | | | | | | | | | | | | | | | | | | | | | | The x86 reset vector is the initial FW code to run on an AP. It should not link to any libraries and is implemented entirely in assembly. This module is currently labled as SEC, because it runs during the SEC phase, but by having it SEC, it will be linked to all NULL libraries linked globally. This causes issue with StackCheckLib (though any NULL library being applied globally has the same issue) because BaseTools will attempt to link the library and add an extern to _ModuleEntryPoint, which does not exist for this module. Moving this module to USER_DEFINED instructs BaseTools to not link any NULL libraries to it, which is the desired behavior, and leads to a much cleaner global NULL library implementation, in this case for StackCheckLib. This change was tested on OVMF IA32/X64 and proved to work as before. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* Maintainers.txt: add Linus Liu as a UefiPayloadPkg maintainerLinus Liu10 days1-0/+1
| | | | | | | I intend to assist with the maintenance of the UefiPayloadPkg directories. Signed-off-by: Linus Liu <linus.liu@intel.com>
* PcAtChipsetPkg: Write RTC time in PcRtcInit() only when it is neededChen Lin Z10 days1-37/+81
| | | | | | | | | | | | | | | In PcRtcInit(), it always read RTC time and then write it back. It could potentially cause two issues: 1) There is time gap between read RTC and write RTC, writing RTC time on every boot could cause RTC time drift after many reboot cycles 2) Writing RTC registers on every boot could cause some unnecessary delay, slightly impact the boot performance. The change is only writing RTC time when 1) the current RTC time is not valid or 2) the RegisterB value is changed. Signed-off-by: Chen Lin Z <lin.z.chen@intel.com>
* PcAtChipsetPkg: Use DV bit to stop the RTC first when changing the timeChen Lin Z10 days2-0/+11
| | | | | | | | | | Legacy BIOS design sets only the Update Cycle Inhibit (SET) bit when changing the RTC time. Update Cycle Inhibit Bit may not be supported by the backend device (Common I2C RTC device). It could add Division Chain Select (DV) bit to stop the RTC first (Write to 0x07), Changing the RTC time and then Set the DV bit back. Signed-off-by: Di Zhang <di.zhang@intel.com>
* UefiCpuPkg: SmmProfile: Use public Architectural MSRs from MdePkgVivian Nowka-Keane11 days2-24/+35
| | | | | | Replaced local Msr defines with inclusion of Register/Amd/Msr.h. Signed-off-by: Vivian Nowka-Keane <vnowkakeane@linux.microsoft.com>
* UefiCpuPkg: Use public Architectural MSRs from MdePkgVivian Nowka-Keane11 days5-24/+31
| | | | | | | Replaced local Msr defines with inclusion of Register/Amd/Msr.h in Amd libraries. Signed-off-by: Vivian Nowka-Keane <vnowkakeane@linux.microsoft.com>
* MdePkg: Added definition of AMD specific public MSRsKun Qin11 days2-0/+56
| | | | | | | | | Added definition of AMD specific public MSRs: 1. SMBASE 2. SMM_ADDR 3. SMM_MASK Signed-off-by: Kun Qin <kuqin@microsoft.com>
* EmbeddedPkg/PrePiHobLib: Remove Non-RT Types from Mem Type Info HOBMichael Kubacki12 days2-16/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Removes the following types from the memory type information HOB produced: - `EfiBootServicesCode` - `EfiBootServicesData` - `EfiLoaderCode` - `EfiLoaderData` This follows the guidance in the whitepaper "A Tour Beyond BIOS Memory Map and Practices in UEFI BIOS". https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf "NOTE: We recommend a platform only define the ReservedMemory, ACPINvs, ACPIReclaim, RuntimeCode, RuntimeData in Memory Type Information table, because OSes only request these regions to be consistent. There is no need to add BootServicesCode, BootServicesData, LoaderCode, LoaderData in memory type information table, because these regions will not be reserved during S4 resume." Since these memory types are not tracked in memory type information any longer it also reduces the number of resets that may need to occur to update memory type buckets that are not needed. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
* ArmVirtPkg/MemoryInitPei: Remove Non-RT Types from Mem Type Info HOBMichael Kubacki12 days2-16/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removes the following types from the memory type information HOBs produced in the MemoryInitPei PEIM: - `EfiBootServicesCode` - `EfiBootServicesData` - `EfiLoaderCode` - `EfiLoaderData` Our platform has a memory type information validation routine that currently expects those types to be excluded as they would not impact the UEFI memory map since they are not runtime memory types. This follows the guidance in the whitepaper "A Tour Beyond BIOS Memory Map and Practices in UEFI BIOS". https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf "NOTE: We recommend a platform only define the ReservedMemory, ACPINvs, ACPIReclaim, RuntimeCode, RuntimeData in Memory Type Information table, because OSes only request these regions to be consistent. There is no need to add BootServicesCode, BootServicesData, LoaderCode, LoaderData in memory type information table, because these regions will not be reserved during S4 resume." Since these memory types are not tracked in memory type information any longer it also reduces the number of resets that may need to occur to update memory type buckets that are not needed. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
* ArmPlatformPkg/MemoryInitPei: Remove Non-RT Types from Mem Type Info HOBMichael Kubacki12 days3-20/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removes the following types from the memory type information HOBs produced in the MemoryInitPei code: - `EfiBootServicesCode` - `EfiBootServicesData` - `EfiLoaderCode` - `EfiLoaderData` Our platform has a memory type information validation routine that currently expects those types to be excluded as they would not impact the UEFI memory map since they are not runtime memory types. This follows the guidance in the whitepaper "A Tour Beyond BIOS Memory Map and Practices in UEFI BIOS". https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf "NOTE: We recommend a platform only define the ReservedMemory, ACPINvs, ACPIReclaim, RuntimeCode, RuntimeData in Memory Type Information table, because OSes only request these regions to be consistent. There is no need to add BootServicesCode, BootServicesData, LoaderCode, LoaderData in memory type information table, because these regions will not be reserved during S4 resume." Since these memory types are not tracked in memory type information any longer it also reduces the number of resets that may need to occur to update memory type buckets that are not needed. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
* ArmVirtPkg: mark fixed network PCDsAleksandr Goncharov12 days2-2/+2
| | | | | | | | | | Rename `NetworkPcds` to `NetworkFixedPcds` to avoid confusion with dynamic PCDs. Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
* OvmfPkg: mark fixed network PCDsAleksandr Goncharov12 days8-8/+8
| | | | | | | | | | | | | | | | Rename `NetworkPcds` to `NetworkFixedPcds` to avoid confusion with dynamic PCDs Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Anatol Belski <anbelski@linux.microsoft.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Chao Li <lichao@loongson.cn> Cc: Bibo Mao <maobibo@loongson.cn> Cc: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
* NetworkPkg: mark fixed network PCDsAleksandr Goncharov12 days2-4/+4
| | | | | | | | | | Rename `NetworkPcds` to `NetworkFixedPcds` to avoid confusion with dynamic PCDs. The next patches in the chain will update all references across the codebase to use the new name. Cc: Saloni Kasbekar <saloni.kasbekar@intel.com> Cc: Zachary Clark-williams <zachary.clark-williams@intel.com> Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
* ArmVirtPkg: use NetworkDynamicPcds include fileAleksandr Goncharov12 days2-14/+2
| | | | | | | | | | | | | | Start using the include file in the ArmVirtPkg package to manage dynamic network-related PCDs. This change removes the manual addition of `PcdIPv4PXESupport` and `PcdIPv6PXESupport` from the DSC file, relying instead on the centralized include file introduced in NetworkPkg. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
* OvmfPkg: use NetworkDynamicPcds include fileAleksandr Goncharov12 days7-39/+7
| | | | | | | | | | | | | | | | | | | | Start using the include file in the OvmfPkg package to manage dynamic network-related PCDs. This change removes the manual addition of `PcdIPv4PXESupport` and `PcdIPv6PXESupport` from the DSC file, relying instead on the centralized include file introduced in NetworkPkg. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Anatol Belski <anbelski@linux.microsoft.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Chao Li <lichao@loongson.cn> Cc: Bibo Mao <maobibo@loongson.cn> Cc: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
* NetworkPkg: introduce include file for dynamic PCDsAleksandr Goncharov12 days2-0/+23
| | | | | | | | | | | | | | Introduce an include file with dynamic PCDs to simplify the usage of the network stage. This allows us to stop manually adding `PcdIPv4PXESupport` and `PcdIPv6PXESupport` to the DSC file. `NETWORK_IP4_ENABLE` and `NETWORK_IP6_ENABLE` are not used because PXEv4 and PXEv6 boot support can be controlled from the QEMU command line. Cc: Saloni Kasbekar <saloni.kasbekar@intel.com> Cc: Zachary Clark-williams <zachary.clark-williams@intel.com> Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
* NetworkPkg/Dhcp6Dxe: Fix sanitizer issuesMichael D Kinney12 days1-3/+3
| | | | | | | | | | | | | | * EFI_DHCP6_DUID structure declares Duid[1], so the size of that structure is not large enough to hold an entire Duid. Instead, compute the correct size to allocate an EFI_DHCP6_DUID structure. * Dhcp6AppendOption() takes a length parameter that in network order. Update test cases to make sure a network order length is passed in. A value of 0x0004 was being passed in and was then converted to 0x0400 length and buffer overflow was detected. Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* UefiCpuPkg/MtrrLib: Fix unit test read overflowMichael D Kinney12 days1-1/+1
| | | | | | | Change conditional check to check the array index before reading the array member to prevent read past end of buffer. Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* MdePkg/Test/DevicePathLib: Remove FreePool(NULL)Michael D Kinney2024-11-081-2/+0
| | | | | | | | Unit test checks if AppendDevicePathInstance() returns NULL. In those cases, AppendDevicePathInstance() does not allocate a device path, so the call to FreePool() must not be performed. Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* CryptoPkg/BaseCryptLib: Fix serial number read overrunMichael D Kinney2024-11-081-1/+1
| | | | Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* UefiCpuPkg/SecCore: Consume PcdMaxMappingAddressBeforeTempRamExitJiaxin Wu2024-11-073-81/+126
| | | | | | | | | | | Consume PcdMaxMappingAddressBeforeTempRamExit for page table creation in permanent memory before Temp Ram Exit. This patch will create the full page table in two steps: Step 1: Create the max address in page table before the Temporary RAM exit. Step 2: Create the full range page table after the Temporary RAM exit. Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
* UefiCpuPkg/UefiCpuPkg.dec: Add PcdMaxMappingAddressBeforeTempRamExitJiaxin Wu2024-11-071-0/+8
| | | | | | | | | | | | | | | This change is made for boot performance considerations. Before the Temporary RAM is disabled, the permanent memory is in UC state, causing the creation of the page table in permanent memory to take more time with larger page table sizes. Therefore, this patch adds the PcdMaxMappingAddressBeforeTempRamExit to provide the platform with the capability to control the max mapping address in page table before Temp Ram Exit. The value of 0xFFFFFFFFFFFFFFFF, then firmware will map entire physical address space. Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
* StandaloneMmPkg/MemLib: remove unnecessary checkDun Tan2024-11-055-162/+1
| | | | | | | | | | | | | | | Remove unnecessary check in API MmIsBufferOutsideMmValid of StandaloneMmMemLib. The API is used to check if a input buffer is outside MMRAM and inside a valid non-MMRAM range. Previously, the API only checks if the input buffer is overlapped with MMRAM range. In the last commit, we add logic to check if the input buffer is inside valid non-MMRAM ranges reported by the resource HOB. Since the resource HOB only covers valid non-MMRAM ranges, we doesn't need to check if the input buffer is inside the MMRAM anymore. Signed-off-by: Dun Tan <dun.tan@intel.com>
* StandaloneMmPkg/Core: Check Resource HOB and Mmram rangesDun Tan2024-11-051-4/+36
| | | | | | | | | Check if the all the resource HOB in the input HOB list of MmCore entry only covers non-Mmram ranges. The Resource HOB is to describe the accessible non-Mmram range. All Resource HOB should not overlap with any Mmram range. Signed-off-by: Dun Tan <dun.tan@intel.com>
* StandaloneMmPkg/Core: add a new InitializeMmHobList()Dun Tan2024-11-051-20/+27
| | | | | | | | Separate a function called InitializeMmHobList() to gather all the operations related to initializing HOB. It doesn't change any code logic. Signed-off-by: Dun Tan <dun.tan@intel.com>
* StandaloneMmPkg/MemLib: Check if the non-MMRAM buffer is validDun Tan2024-11-054-1/+284
| | | | | | | | | | | | | | | Check if the non-MMRAM buffer is inside valid non-mmram range in API MmIsBufferOutsideMmValid of StandaloneMmMemLib. Previously, the API only checks if the input buffer is overlapped with MMRAM range. Currently, in the new standalone MM infrastructure, we limit the non-MMRAM access to the ranges reported by the resource HOB. To meet the new design, in this API, we cache all the memory ranges reported by the resource HOB and check if the input buffer is inside valid non-MMRAM ranges reported by the resource HOB. Signed-off-by: Dun Tan <dun.tan@intel.com>
* StandaloneMmPkg/MemLib: Add an internal header fileDun Tan2024-11-055-48/+59
| | | | | | | | Add a internal header file for StandaloneMmMemLib. Move some common reference and declaration into StandaloneMmMemLibInternal.h. Signed-off-by: Dun Tan <dun.tan@intel.com>
* StandaloneMmPkg/Core: Remove unneeded checkDun Tan2024-11-051-7/+1
| | | | | | | | | | | | | | | | | | | | Remove unneeded check MmIsBufferOutsideMmValid() when StandaloneMmCore checks if the BS data memory described by a memory allocation HOB needs to be migrated to Mmram. Currently, the API MmIsBufferOutsideMmValid() return TRUE when input memory range belongs to non-Mmram memory. Now the API will be changed in following 5 commits to return TRUE when a memory range belongs to non-Mmram memroy and the memory is inside a range described by resource HOB. This may cause PF when some SMI handler access the memory from a memory allocation HOB that is not migrated. To solve this issue, we can directly remove the check MmIsBufferOutsideMmValid() and always migrate the BS data memory described by a memory allocation HOB to Mmram. Signed-off-by: Dun Tan <dun.tan@intel.com>
* StandaloneMmPkg/MmIpl: Optimize hob pointer check flowHongbin1 Zhang2024-11-051-7/+6
| | | | | | | | | | | | | | | | Clang compile will optimize undefined behavior (UB) like a pointer with NULL + size, so it is better to check the pointer before using it. Signed-off-by: Hongbin1 Zhang <hongbin1.zhang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Wei6 Xu <wei6.xu@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
* CryptoPkg: Added MM_STANDALONE support in CryptoPkg.INDIA\kanagavels2024-11-055-0/+283
| | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4867 Added MM_STANDALONE support in Driver and BaseCryptLibOnProtocolPpi. Signed-off-by: Kanagavel S <kanagavels@ami.com>
* CryptoPkg: Increase ScratchMemory buffer for openssl 3.0.15Jorge Ramirez-Ortiz2024-11-041-1/+1
| | | | | | | | | | | | | | | | Openssl 3.0.15 has a larger memory footprint. Updating from EDK 2022.2 (openssl 1.1.j) to 2024.2 (openssl 3.0.15) causes our EFI provisioning application[1] to fail due to an out of memory condition. On inspection, at the time of that fault, 2022.2 had an additional 900 pages. This is why this patch proposes the increase of the ScratchMemory buffer by that same ammount. [1] https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
* UnitTestFrameworkPkg: Use TianoCore mirror of subhook submoduleMichael D Kinney2024-11-043-11/+11
| | | | | | | | | | Change subhook url from https://github.com/Zeex/subhook to https://github.com/tianocore/edk2-subhook because old url is no longer available. Also align .gitmodules file to use consistent LF line endings. Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* CryptoPkg: Updated the missed architectures.INDIA\kanagavels2024-11-011-1/+1
| | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4838 Updated the missed architectures in PeiCryptLib.inf file. Signed-off-by: Kanagavel S <kanagavels@ami.com>
* UefiCpuPkg: Remove AMD 32-bit SMRAM save state mapPhil Noh2024-11-013-157/+101
| | | | | | | | | | Per AMD64 Architecture Programmer's Manual Volume 2: System Programming - 10.2.3 SMRAM State-Save Area (Rev 24593), the AMD64 architecture does not use the legacy SMM state-save area format (Table 10-2) for 32-bit SMRAM save state map. Clean up codes for the invalid save state map. Signed-off-by: Phil Noh <Phil.Noh@amd.com>
* MdePkg: CodeQL Fixes.Michael Kubacki2024-11-0111-196/+460
| | | | | | | | | | | | | Includes changes across the repo for the following CodeQL rules: - cpp/comparison-with-wider-type - cpp/overflow-buffer - cpp/redundant-null-check-param - cpp/uselesstest Co-authored-by: Taylor Beebe <tabeebe@microsoft.com> Co-authored-by: kenlautner <85201046+kenlautner@users.noreply.github.com> Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
* MdeModulePkg: SataControllerSupported checks DevicePath ProtocolPaul Chang2024-11-013-3/+31
| | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4858 Ph52a PCIE to SATA card inserted on Intel MTL/ARL causes system hanged. Root cause of this issue is because Ph52a's driver only uses DevicePath protocol alone and EDK2 driver only uses PciIo protocol alone. Both drivers start and try to manage SATA controller. Signed-off-by: Paul Chang <paulchang@ami.com>
* UefiPayloadPkg ：ACPI memory nodeLinus Liu2024-10-311-1/+22
| | | | | | | | | There are couples of gUniversalPayloadAcpiTableGuid in payload , only build one gUniversalPayloadAcpiTableGuid hob and acpi memory hob. when the reserved memory address matched the rsdp. Signed-off-by: Linus Liu <linus.liu@intel.com>
* UefiPayloadPkg：Add SMBIOS node.Linus Liu2024-10-314-25/+54
| | | | | | | Per other platform request , need to add SMBIOS device node into FDT. In the current phase(1) , only supporting SM3EntryPoint structure. Signed-off-by: Linus Liu <linus.liu@intel.com>
* UefiPayloadPkg: Modify PCI root reg .Linus Liu2024-10-311-4/+14
| | | | | | | Per Spec updated , update DMA Reg property filed with each root bridge bus base and its bus limit. Signed-off-by: Linus Liu <linus.liu@intel.com>
* StandaloneMmPkg/MmIpl: Max physical address bits if disable 5 page levelHongbin1 Zhang2024-10-311-0/+55
| | | | | | | | | | | | | | | | | | | 4-level paging supports translating 48-bit linear addresses to 52-bit physical addresses. Since linear addresses are sign-extended, the linear-address space of 4-level paging is: [0, 2^47-1] and [0xffff8000_00000000, 0xffffffff_ffffffff]. So only [0, 2^47-1] linear-address range maps to the identical physical-address range when 5-Level paging is disabled. Signed-off-by: Hongbin1 Zhang <hongbin1.zhang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Wei6 Xu <wei6.xu@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-23 09:38:36 +0000