Tianocore/edk2.git/ArmPlatformPkg/Sec, branch dependabot/github_actions/actions/setup-python-7

ArmPlatformPkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

MdePkg, ArmPkg, ArmPlatformPkg: Create VECTOR_TABLE Macro

2026-01-15T17:10:46+00:00

Currently, there exists VECTOR_BASE, VECTOR_ENTRY, and VECTOR_END macros for defining things such as exception vectors. They are intended to be used as follows: VECTOR_BASE() VECTOR_ENTRY() VECTOR_END() This creates a non-enforceable requirement to do this, if VECTOR_END isn't used, the vector size isn't enforced and the image section won't be restored to .text. This commit removes VECTOR_BASE and VECTOR_END and creates a VECTOR_TABLE macro that encapsulates the behavior of the two macros, sandwiching the developer provided VECTOR_ENTRY and code pairings inbetween. This enforces that VECTOR_BASE and VECTOR_END are used together and correctly set up/tear down the vector area. This commit also updates the only users of these macros at the same time to avoid a build breakage. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny

ArmPlatformPkg: Remove ARM32 Support from Sec

2025-09-25T22:04:10+00:00

edk2 is dropping support for the ARM32 architecture. This commit removes ARM32 files from Sec. Signed-off-by: Oliver Smith-Denny

ArmPlatformPkg: Introduce gArmTransferListPpiGuid

2025-07-24T05:59:45+00:00

Populate the gArmTransferListPpiGuid with the TransferList base address. Place the Ppi at the end of the PpiList For platforms with no TransferList support, boot continues without any errors. https://firmwarehandoff.github.io/firmware_handoff Signed-off-by: Prachotan Bathi

ArmPlatformPkg: Capture TransferList Information for SEC

2025-07-24T05:59:45+00:00

Capture TransferList address from register x3 Refer to section 3 of the FW Handoff Specification https://firmwarehandoff.github.io/firmware_handoff The TransferList header is present at the base address captured by this variable. For platforms with no TransferList support, boot continues without any errors. Signed-off-by: Prachotan Bathi

ArmPlatformPkg/Sec: Re-use SetupExceptionLevel1 when running VHE at EL2

2025-05-28T19:09:22+00:00

Given that CPACR_EL1 is aliased to CPTR_EL2 when running at EL2 with VHE enabled, we can just fall back to SetupExceptionLevel1() instead of fiddling with the init values for CPTR_EL2. While at it, use the existing define to refer to the E2H bit in HCR_EL2. Signed-off-by: Ard Biesheuvel

ArmPlatformPkg/Sec: Simplify SetupExceptionLevel1() using a tail call

2025-05-28T19:09:22+00:00

Avoid a call and use a jump instead, so that the LR value does not need to be recorded in a different register. This is generally neater, but it also avoids potential confusion in the debugger, given that no frame record is created for this call. Signed-off-by: Ard Biesheuvel

ArmPlatformPkg/Sec: Remove EL1 timer setup when booting at EL2

2025-05-28T19:09:22+00:00

Even though the UEFI spec mentions that the EL1PCTEN and EL1PCEN bits in CNTHCTL_EL2 must be set, this is not a requirement that applies to the UEFI implementation, but a requirement that applies to the firmware running at EL2 in cases where UEFI executes at EL1. (Note that the same paragraphs mentions that CNTFRQ must be programmed with the timer frequency, and this is only permitted at EL3). Setting these bits has no effect when executing at EL2, and it is the OS's job to reason about how to configure lower exception levels. So drop the initialization of CNTHCTL_EL2. Signed-off-by: Ard Biesheuvel

ArmPlatformPkg/Sec: Deal with entry at EL2 with VHE enabled

2025-05-27T15:12:31+00:00

The architecture now permits HCR_EL2.E2H to be RES1, and so even though the UEFI spec is silent on the matter, entering at EL2 with VHE enabled is a condition that needs to be dealt with. In particular, virtual machines running under nested virtualization on Apple M2 or newer will enter in this manner In this case, the CPTR_EL2 system register needs to be treated as if its layout is identical to CPACR_EL1. Not doing so may result in all kinds of surprises, but the most noticeable is an early crash on the use of FP/SIMD registers, which get disabled inadvertently by this code. Signed-off-by: Ard Biesheuvel

ArmPlatformPkg/Sec: clean up FP enabling code

2025-04-11T12:48:56+00:00

UEFI defines that FP support is required on AArch64, whereas many platforms enable it anyway on Arm. But when it's enabled, C code can generate instructions targeting FP registers, so: - move ArmEnableVFP call to asm - make it unconditional on AArch64 Signed-off-by: Leif Lindholm