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 <prachotan.bathi@arm.com>
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 <prachotan.bathi@arm.com>
ArmTransferListHobGuid holds TransferList base address
If there's no valid TransferList found, Guid HOB is not built,
boot progresses as usual.
Signed-off-by: Prachotan Bathi <prachotan.bathi@arm.com>
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 Reddy Bathi <Prachotan.Bathi@arm.com>
Convert UART configuration PCDs from FixedPcd to dynamic Pcd to enable
runtime modification of serial port parameters.
Changes made:
- Replace FixedPcdGet64/FixedPcdGet8 calls with PcdGet64/PcdGet8 for:
* PcdUartDefaultBaudRate
* PcdUartDefaultParity
* PcdUartDefaultDataBits
* PcdUartDefaultStopBits
- Update INF file to declare these PCDs under [Pcd].
Signed-off-by: Pranav V V <pranav.v.v@intel.com>
Move ArmMmuLib from ArmPkg to UefiCpuPkg for easy maintaining.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ajan Zhong <ajan.zhong@newfw.com>
Since ArmMmuLib.h has been moved to UefiCpuPkg, add corresponding dec
file to AcceptableDependencies to ArmPkg, ArmPlatformPkg and ArmVirtPkg.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ajan Zhong <ajan.zhong@newfw.com>
Move the ArmMmuLib interface definition to UefiCpuPkg, with this change,
MMU libraries for ARM, AARCH64, RiscV, LongArch64 architectures all
reside in UefiCpuPkg.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ajan Zhong <ajan.zhong@newfw.com>
When calling to initialize the PL011 Uart, Rx buffer is
not cleared. In a 16550 uart device, during initialization,
the 16550's Fifo control registers would be used to clear
the Rx buffer, but no such register exists on PL011.
Modify the PL011 SerialPortInitialize function
to clear anything that was in the Rx buffer
after initialization is completed. This will prevent
any stale data from being interpreted as valid data.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
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 <ardb@kernel.org>
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 <ardb@kernel.org>
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 <ardb@kernel.org>
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 <ardb@kernel.org>
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 <leif.lindholm@oss.qualcomm.com>
_SetSVCMode sits shortly after _ModuleEntryPoint, to switch into SVC mode
and mask FIQ and IRQ exceptions (making it badly named to boot).
But this should always be the state we start executing in, so most
likely this is another remnant of a time when the edk2 image also
contained Secure Monitor code, which has not been supported for some
time now.
Delete the whole stanza and see if anything breaks.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
This commit oves StackCheckLib from a NULL lib to an instance of
StackCheckLib. This requires every entry point to add a library
dependency on StackCheckLib. It also requires every SEC module
to have a dependency on StackCheckLib because there is no
standard SEC entry point.
It allows for greater flexibility for a platform to apply stack
cookies and simplifies DSC logic.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Retire all implementations of the ArmGicLib library class, which are no
longer used. For now, retain the library header and library class
declaration: the header file only contains pre-processor defines derived
from the GIC architecture spec, and so this code should probably move
into MdePkg at a later moment.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ArmGicArchLib is no longer use so remove all remaining references and
implementations.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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>
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>
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>
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>
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>
Makes changes to comply with alerts raised by CodeQL.
The issues here fall into the following category:
1. comparison-with-wider-type
Signed-off-by: Eeshan Londhe <eeshanlondhe@microsoft.com>
As per the emailed RFC in
https://edk2.groups.io/g/devel/topic/rfc_move/107675828,
this patch moves CompilerIntrinsicsLib from ArmPkg to
MdePkg as this library provides compiler intrinsics, which
are industry standard.
This aligns with the goal of integrating ArmPkg into existing
packages: https://bugzilla.tianocore.org/show_bug.cgi?id=4121.
The newly placed CompilerIntrinsicsLib is added to MdeLibs.dsc.inc
as every DSC that builds ARM/AARCH64 needs this library added. The
old location is removed from every DSC in edk2 in this commit also
to not break bisectability with minimal hoop jumping.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
AsmMacroIoLib.h and AsmMacroIoLibV8.h are used by the
CompilerIntrinsicsLib, which is moving to MdePkg. These
functions provide standard definitions for ARM/AARCH64
assembly code, respectively, and so are moved to the arch
directories in MdePkg to avoid MdePkg having a
dependency on ArmPkg.
Now that the files are in Arm/ and AArch64/ directories,
the filenames are changed to AsmMacroLib.h as we can
distinguish the architecture from the path.
AsmMacroIoLib.inc is unused and so is removed.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Adds an entry to the package's CI configuration file that enable policy
5 for stuart_pr_eval. With this Policy, all INFs used by the package are
extracted from the provided DSC file and compared against the list of
changed *.inf (INF) files in the PR. If there is a match, stuart_pr_eval
will specify that this package is affected by the PR and needs to be
tested.
Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com>
Some of the boilerplate in ArmPlatformLib is only relevant when entering
UEFI on multiple cores, and this is no longer supported. So retire the
associated helper routines.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
PrePeiCore and Sec directly write the firmware version to the serial port.
They relies on another component to initialize the serial port, however
in certain configurations (such as release builds that don't use a
DebugLib that initializes the serial port), the serial port can be
uninitialized at this point, causing a crash when SerialPortWrite
is called here.
This patch updates PrePeiCore and Sec to call SerialPortInitialize before
calling SerialPortWrite directly, which follows the pattern of
other serial port writes. It is accepted to call the initialization
routine multiple times, it is supposed to dump out if the serial
port is already initialized.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
When cspell is installed (via `npm install cspell`), CI checks for
spelling mistakes. There are currently a very large number of them: some
are genuine mistakes while others are words or acryonyms that cspell
doesn't know.
Fix a few of the misspellings in ArmPlatformPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
PrePeiUniCore was already named rather awkwardly, but now that the
UniCore bit has become redundant too, let's rename it in a way that
conveys its purpose a bit better: Sec. This also matches what other
architectures and platforms tend to provide.
A straight rename would break all out-of-tree users, so clone it into a
new module with a fresh GUID, giving users some time to update.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
PrePiUniCore was already spectacularly mis-named but now that the
UniCore bit has become redundant too, let's rename it in a way that
conveys its purpose a bit better: PeilessSec.
A straight rename would break all out-of-tree users, so clone it into a
new module with a fresh GUID, giving users some time to update.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Make some functions STATIC that are only called locally, and add some
function headers to placate the tools.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Drop the call to the TimerConstructor, which should not be called
explicitly, and does nothing useful to begin with.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This SEC driver is single CPU only now, so all of the secondary stack
handling is dead code, and can be removed.
This removes the last remaining user of the associated PCD, so drop that
as well.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This SEC driver is single CPU only now, so all of the secondary stack
handling is dead code, and can be removed.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The PrePeiCore SEC driver can be built in unicore and MPcore versions
from [mostly] the same source. The latter is obsolete, so remove it and
simplify the remaining code accordingly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The PrePi SEC driver can be built in unicore and MPcore versions
from [mostly] the same source. The latter is obsolete, so remove it and
simplyify the remaining code accordingly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
PL031RealTimeClockLib will clear EFI_MEMORY_XP if a platform
has set it for MMIO memory when it does not include that bit
in its SetMemoryAttributes call. This region is not intended
to be executed from and as such the lib should explicitly set
EFI_MEMORY_XP to this region.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Library previously returned EFI_SUCCESS which causes the platform to
continue initializing LCD HW. Should return EFI_NOT_FOUND.
Resolves TCBZ3351.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
ASSERT_EFI_ERROR would be removed in release build.
This means it would trigger wrong behavior when invalid pin number given
to Get(), Set() and GetMode().
Adding error check routine for invalid pin number and before check the
pin number, check first other argument given to each function.
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
