Add support for tabulating static memory consumption data from ELF
binaries. This relies on static symbols, defined in the linker files,
that provide information about the memory ranges.
Change-Id: Ie19cd2b80a7b591607640feeb84c63266963ea4d
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Make the symbol table produced by the memory mapping script more
readable. Add a generic interface for interacting with ELF binaries.
This interface enables us to get symbols that provide some insights into
TF-A's memory usage.
Change-Id: I6646f817a1d38d6184b837b78039b7465a533c5c
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
The current usage of RAS_EXTENSION in TF-A codebase is to cater for two
things in TF-A :
1. Pull in necessary framework and platform hooks for Firmware first
handling(FFH) of RAS errors.
2. Manage the FEAT_RAS extension when switching the worlds.
FFH means that all the EAs from NS are trapped in EL3 first and signaled
to NS world later after the first handling is done in firmware. There is
an alternate way of handling RAS errors viz Kernel First handling(KFH).
Tying FEAT_RAS to RAS_EXTENSION build flag was not correct as the
feature is needed for proper handling KFH in as well.
This patch breaks down the RAS_EXTENSION flag into a flag to denote the
CPU architecture `ENABLE_FEAT_RAS` which is used in context management
during world switch and another flag `RAS_FFH_SUPPORT` to pull in
required framework and platform hooks for FFH.
Proper support for KFH will be added in future patches.
BREAKING CHANGE: The previous RAS_EXTENSION is now deprecated. The
equivalent functionality can be achieved by the following
2 options:
- ENABLE_FEAT_RAS
- RAS_FFH_SUPPORT
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: I1abb9ab6622b8f1b15712b12f17612804d48a6ec
Updating toolchain to the latest production release version
12.2.Rel1 publicly available on https://developer.arm.com/
We build TF-A in CI using:
AArch32 bare-metal target (arm-none-eabi)
AArch64 ELF bare-metal target (aarch64-none-elf)
Change-Id: Ib603cf7417e6878683a1100d5f55311188e36e8e
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Updated the documentation to include missing details about the
TZC secured DRAM mapping for the FVP and Juno platforms.
Change-Id: I10e59b9f9686fa2fef97f89864ebc272b10e5c0b
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Updated errata ABI feature enable flag and the errata non-arm
interconnect based flag, the default values for when the
feature is not enabled.
Change-Id: Ieb2144a1bc38f4ed684fda8280842a18964ba148
Signed-off-by: Sona Mathew <SonaRebecca.Mathew@arm.com>
The workarounds for these below mentioned errata are not implemented
in EL3, but the flags can be enabled/disabled at a platform level
based on arm/non-arm interconnect IP. The ABI helps assist the Kernel
in the process of mitigation for the following errata:
Cortex-A715: erratum 2701951
Neoverse V2: erratum 2719103
Cortex-A710: erratum 2701952
Cortex-X2: erratum 2701952
Neoverse N2: erratum 2728475
Neoverse V1: erratum 2701953
Cortex-A78: erratum 2712571
Cortex-A78AE: erratum 2712574
Cortex-A78C: erratum 2712575
EL3 provides an appropriate return value via errata ABI when the
kernel makes an SMC call using the EM_CPU_ERRATUM_FEATURES FID with the
appropriate erratum ID.
Change-Id: I35bd69d812dba37410dd8bc2bbde20d4955b0850
Signed-off-by: Sona Mathew <SonaRebecca.Mathew@arm.com>
Currently, enabling SME forces SVE off. However, the SME enablement
requires SVE to be enabled, which is reflected in code. This is the
opposite of what the build flags require.
Further, the few platforms that enable SME also explicitly enable SVE.
Their platform.mk runs after the defaults.mk file so this override never
materializes. As a result, the override is only present on the
commandline.
Change it to something sensible where if SME is on then code can rely on
SVE being on too. Do this with a check in the Makefile as it is the more
widely used pattern. This maintains all valid use cases but subtly
changes corner cases no one uses at the moment to require a slightly
different combination of flags.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: If7ca3972ebc3c321e554533d7bc81af49c2472be
* changes:
feat(allwinner): add support for Allwinner T507 SoC
feat(allwinner): add function to detect H616 die variant
feat(allwinner): add extra CPU control registers
refactor(allwinner): consolidate sunxi_cfg.h files
* changes:
docs(spm): support for handling Group0 interrupts
feat(spmd): introduce platform handler for Group0 interrupt
feat(spmd): add support for FFA_EL3_INTR_HANDLE_32 ABI
feat(spmd): register handler for group0 interrupt from NWd
This patch introduces support to handle traps from lower ELs for
IMPDEF system register accesses. The actual support is left to the
platforms to implement.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I623d5c432b4ce4328b68f238c15b1c83df97c1e5
The code was already removed as part of commit 4ac5b3949d
"refactor(auth): replace plat_convert_pk". The present commit just
removes it from the release documentation.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: I06b35f110c844267d69a865df55dd451ed2f08cd
FEAT_SME2 is an extension of FEAT_SME and an optional feature
from v9.2. Its an extension of SME, wherein it not only
processes matrix operations efficiently, but also provides
outer-product instructions to accelerate matrix operations.
It affords instructions for multi-vector operations.
Further, it adds an 512 bit architectural register ZT0.
This patch implements all the changes introduced with FEAT_SME2
to ensure that the instructions are allowed to access ZT0
register from Non-secure lower exception levels.
Additionally, it adds support to ensure FEAT_SME2 is aligned
with the existing FEATURE DETECTION mechanism, and documented.
Change-Id: Iee0f61943304a9cfc3db8f986047b1321d0a6463
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
As per recent changes to OPTEE's fvp.mk file, both options
"MEASURED_BOOT" and "MEASURED_BOOT_FTPM" are required for the fTPM
application to be built.
Change-Id: I621113c3fbd47e9f5be015ea65e9b8d0f218e4e8
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
The Allwinner T507 SoC is using the same die as the H616, but in a
different package. On top of this, there is at least one different die
revision out there, which uses a different CPU cluster control block.
The same die revision has been spotted in some, but not all, H313 SoCs.
Apart from that IP block, the rest of the SoC seems the same, so we can
support them using the existing H616 port. The die revision can be
auto-detected, so there is no extra build option or knowledge needed.
Provide the deviating CPU power up/down sequence for the die variant.
The new IP block uses per-core instead of per-cluster registers, but
follows the same pattern otherwise.
Since the CPU ops code is shared among all Allwinner SoCs, we need to
dummy-define the new register names for the older SoCs. The actual new
code is guarded by a predicate function, that is hard coded to return
true on the other SoCs. Since this is a static inline function in a
header file, the compiler will optimise away the unneeded branch there,
so the generated code for the other SoCs stays the same.
Change-Id: Ib5ade99d34b4ccb161ccde0e34f280ca6bd16ecd
Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This patch introduces the 'pwr_domain_off_early' hook for
platforms wanting to perform housekeeping steps before the
PSCI framework starts the CPU power off sequence. Platforms
might also want to use ths opportunity to ensure that the
CPU off sequence can proceed.
The PSCI framework expects a return code of PSCI_E_DENIED,
if the platform wants to halt the CPU off sequence.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Change-Id: I6980e84fc4d6cb80537a178d0d3d26fb28a13853
Some parts of the documentation referring to Poetry provides incorrect
build instructions and has some minor formatting errors. Reformat the
bits that require formatting, and fix the build instructions. These
were originally part of the patch stack that added Poetry support but
were accidentally reverted prior to merge.
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Change-Id: I336d3a7bbe99f75262430ae436f8ebc2cb050d2c
* changes:
refactor(auth)!: unify REGISTER_CRYPTO_LIB
refactor(auth): replace plat_convert_pk
docs(auth): add auth_decrypt in CM chapter
feat(auth): compare platform and certificate ROTPK for authentication
docs(auth): add 'calc_hash' function's details in CM
We plan to deprecate the CryptoCell-712 and CryptoCell-713 drivers in
TF-A release v2.9 and eventually remove the code from the tree in
release 3.0.
The only upstream platforms which use these drivers today are the Arm
Ltd developpment platforms, such as Juno.
Write this information down into the "Release Processes" document.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: Ib064292733a271ecbff0dde315911017e2c4da7e
Having a dedicated section for deprecated interfaces, and another one
for deprecated drivers, sounds cleaner.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: Iaf65e9f4dabff89b9e86c17062656edd8c344016
Our process documentation already mentions that if a platform is no
longer maintained, it is best to deprecate it to keep the project's
source tree clean and healthy.
The same argument stands for drivers or library interfaces so extend
this policy to those.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: Ieb235d6a1fb089343e0e1e3e5f36067552f2f8f0
Clarify that downstream platforms generally do not affect code
deprecation / removal decisions.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: I44b979c4e67ee03537852769e96544e19137bda3
Following discussions in the reviews of the patch that introduced
plat_convert_pk() function [1], it was decided to deprecate it to
avoid weak function declaration.
A new optional function pointer convert_pk is added to crypto_lib_desc_t.
A new function crypto_mod_convert_pk() will either call
crypto_lib_desc.convert_pk() if it is defined, or do the same
as what was done by the weak function otherwise.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17174
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Change-Id: I9358867f8bfd5e96b5ee238c066877da368e43c6
The call to REGISTER_CRYPTO_LIB requires auth_decrypt function to be
provided. Add its prototype and update REGISTER_CRYPTO_LIB call.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Change-Id: Id1f2a54867ffe5dec36e0bf22490d01858891585
