* changes:
fix(spe): invoke spe_disable during power domain off/suspend
feat(psci): add psci_do_manage_extensions API
fix(arm_fpga): halve number of PEs per core
spe_disable function, disables profiling and flushes all the buffers and
hence needs to be called on power-off/suspend path.
It needs to be invoked as SPE feature writes to memory as part of
regular operation and not disabling before exiting coherency
could potentially cause issues.
Currently, this is handled only for the FVP. Other platforms need
to replicate this behaviour and is covered as part of this patch.
Calling it from generic psci library code, before the platform specific
actions to turn off the CPUs, will make it applicable for all the
platforms which have ported the PSCI library.
Change-Id: I90b24c59480357e2ebfa3dfc356c719ca935c13d
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Adding a new API under PSCI library,for managing all the architectural
features, required during power off or suspend cases.
Change-Id: I1659560daa43b9344dd0cc0d9b311129b4e9a9c7
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
When creating the Arm FPGA platform, we had plenty of memory available,
so assigned a generous four PEs per core for the potential CPU topology.
In reality we barely see implementations with two PEs per core, and
didn't have four at all so far.
With some design changes we now include more data per CPU type, and
since the Arm FPGA build supports many cores (and determines the correct
one at runtime), we run out of memory with certain build options.
Since we don't really need four PEs per core, just halve that number, to
reduce our memory footprint without sacrificing functionality.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Change-Id: Ieb37ccc9f362b10ff0ce038f72efca21512a71cb
This setup helps to mimic an end-to-end RAS handling flow inspired
by real world design with a dedicated RAS secure partition managed
by SPMC.
The detailed steps are documented as comments in the relevant source
files introduced in this patch.
Change-Id: I97737c66649f6e49840fa0bdf2e0af4fb6b08fc7
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
SCR_EL3.EEL2 bit enabled denotes that the system has S-EL2 present and
enabled, Ideally this bit is constant throughout the lifetime and
should not be modified. Currently this bit is initialized in the context
mgmt code where each world copy of the SCR_EL3 register has this bit set
to 1, but for the time duration between the RESET and the first exit to
a lower EL this bit is zero.
Modifying SCR_EL3.EEL2 along with EA bit at RESET does also helps in
mitigating against ERRATA_V2_3099206.
For details on Neoverse V2 errata 3099206, refer the SDEN document
given below.
https://developer.arm.com/documentation/SDEN-2332927/latest
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: If8b2bdbb19bc65391a33dd34cc9824a0203ae4b1
Move RME to 9.2 optional features and add minor updates to comments.
Change-Id: I12a4940e82ca5df72af5421ddab43bc6a1628e95
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
All mandatory FEAT_* enabling is done from arch_features.mk.
Remove some old code which would enable some mandatory options based
on arch-features option passed to march appending.
This is now not needed anymore since if we are using correct
ARCH_MAJOR/MINOR the mandatory options will taken care from
arch_features.mk
Change-Id: I8565ac4ebb3ced29835be65ea5b043a08810872f
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Currently all march compiler option handling is moved to build
utility in march.mk.
We pass arch-features to build which appends to march options,
so this should be done once we decide march options and moving
it to march.mk file.
Change-Id: Ifaf99af5f371fd28db376a12657ccf4f363295c2
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Currently we enable all mandatory options for a current MAJOR.MINOR
number without considering architecturally to what version the current
arch should be compliant with.
For example Arch v9 should be compliant with 8.5 and shouldn't
consider being compliant with 8.9, so refactor FEAT_* handling to
ensure we capture and handle compliance correctly.
So refactor to use a list and add FEAT_* which are only compliant
with a given arch rather than relying on all the FEAT_* from previous
should be enabled for given arch version.
Change-Id: I8b0dd076c168a647de43b8618fbbe607412f7cab
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Fix [1] is introducing another problem in that memset is added twice to
the libc makefile when OVERRIDE_LIBC=1 (the C and asm implementations).
Correct by adding memset.c when OVERRIDE_LIBC=0 and memset.S when
OVERRIDE_LIBC=1.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/26091
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: Ie4b7e04880d4cd871e7b51cd8ff5bddcf8d0308c
The ChromeOS will use the SMC to pass some secrets from firmware to
optee.
Change-Id: Iaf3357d40a7ed22415926acd9d7979df24dd81f1
Signed-off-by: Yi Chou <yich@google.com>
Exception handling framework (EHF) changes the semantics of interrupts,
sync and async external aborts. As far as interrupts are concerned it
changes the routing model of foreign interrupts (FIQs) by changing
SCR_EL3.FIQ to 1 for both non-secure and secure except when SPMD is
used along with Hafnium/SPM at S-EL2 [1].
For NS world it means : G1S and G0 interrupts are routed to EL3
For Secure world it means : G1NS and G0 are routed to EL3
There is no upstream use case utilizing EHF and re-routing EL3
interrupts to the Secure world except when SPM_MM is present.
Modify the FIQ routing model during EHF init just for known use cases,
Always for NS world and for secure world only if SPM_MM is present.
[1]:https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16047
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ic292bbe8dd02d560aece5802d79569d868d8500f
Currently any arch FEAT_* can be enabled from:
- command line build options
- platform makefile
- from arch_features.mk
These are in order. However, mandatory features are enforced from
arch_features.mk and platform makefile can't override them.
Allow command line options or platforms makefile to disable any
mandatory features.
Change-Id: I6fdca1a3d0b405a88cd7a20309e0c1eecd57a650
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
When building TF-A (with SPMD support) with ARM_ARCH_MAJOR=8/
ARCH_ARCH_MINOR=8 options, this forces the -march=armv8.8-a compiler
option. In this condition, the compiler optimises statement [1] into
a store pair to an unaligned address resulting to a supposedly alignment
fault. With -march=armv8.7-a and earlier the compiler resolves with a
memcpy. Replacing this line by an explicit memcpy masks out the issue.
Prefer using the plain struct uuid in place of the uuid_helper union
for further clarity.
[1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/
plat/arm/common/fconf/arm_fconf_sp.c?h=v2.10#n77
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I509b7bc50c7c4a894885d24dc8279d0fe634e8f2
Change [1] introduced the memcpy_s function and added the source file to
lib/libc/libc.mk but omitted to update lib/libc/libc_asm.mk
Arm platforms (and platforms from one partner) use OVERRIDE_LIBC=1
option as a platform default hence consume libc_asm.mk
To prevent this confusion to happen again, create libc_common.mk for the
common set of C files to build.
libc_common.mk is included by both libc.mk and libc_asm.mk
The latter adds asm implementations of libc functions.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21450
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: Ibd36ea5c561e35f268048ccbefc8f47485f64bdf
* changes:
feat(arm): move GPT setup to common BL source
feat(arm): retrieve GPT related data from platform
refactor(arm): rename L0/L1 GPT base macros
- Warn contributors that they need to register their email address in
their Gerrit profile. Not doing so causes errors at patch submission
and is a recurrent question on the mailing list.
- Add some links where useful.
- Remove confusing CGit link to TF-A source code. In the context of
setting up a local copy of the repo for contributing patches,
developers should rather clone it through Gerrit and this is best
covered by the "Getting the TF-A Source" section of TF-A
documentation.
- Add references to the OpenCI documentation, which has a lot more
details on some of the topics we briefly cover in the contribution
guidelines.
- Encourage the user to use the 'git review' command for patch
submission, inline with OpenCI documentation instructions. This
automatically sorts out which Gerrit server to push to and against
which repo branch (thanks to the '.gitreview' configuration file in
TF-A root directory).
- Elaborate the Coverity Scan section.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: I1131662d8bc3502967b269a599869ea130897efb
This feature provides support to context save the
SCXTNUM_ELx register. FEAT_CSV2_3 implies the implementation
of FEAT_CSV2_2. FEAT_CSV2_3 is supported in AArch64 state only
and is an optional feature in Arm v8.0 implementations.
This patch adds feature detection for v8.9 feature FEAT_CSV2_3,
adds macros for ID_AA64PFR0_EL1.CSV2 bits [59:56] for detecting
FEAT_CSV2_3 and macro for ENABLE_FEAT_CSV2_3.
Change-Id: Ida9f31e832b5f11bd89eebd6cc9f10ddad755c14
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
TF-A aims to comply with MISRA C:2012 Guidelines. We maintain a list of
all rules and directives and whether the project aims to comply with
them or not. A rationale is given for each deviation.
This list used to be provided as an '.ods' spreadsheet file hosted on
developer.trustedfirmware.org. This raises the following issues:
- The list is not version-controlled under the same scheme as TF-A
source code. This could lead to synchronization issues between the
two.
- The file needs to be open in a separate program, which is not as
straightforward as reading it from TF-A documentation itself.
- developer.trustedfirmware.org is deprecated, thus the file cannot be
safely kept there for any longer.
To address these issues, convert the '.ods' file into a CSV (Comma
Separated Values) file, which we import into TF-A source tree itself.
Make use of Sphinx's ability to process and render CSV files as tables
to display that information directly into the Coding Guidelines
document.
Also make the following minor changes along the way:
- Remove dead link to MISRA C:2012 Guidelines page. Replace it with a
link to a Wikipedia page to give a bit of context to the reader.
- We no longer use Coverity for MISRA compliance checks. Instead, we
use ECLAIR nowadays. Reflect this in the document.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: I422fdd8246f4f9c2498c1be18115408a873b86ac
developer.trustedfirmware.org is deprecated so we cannot use its issues
tracker anymore. Instead, the project will now make use of the issues
tracker associated with the project's Github mirror at [1].
Reflect this change in TF-A documentation.
[1] https://github.com/TrustedFirmware-A/trusted-firmware-a/issues
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: I912f7dafc74368dba4e61ba4c9f358d5bf8346a9
In i.MX8MM/MQ it is possible to have two copies of bootloader in
SD/eMMC and switch between them. The switch is triggered either
by the BootROM in case the bootloader image is faulty OR can be
enforced by the user, and there is API introduced in
9ce232fe ("feat(plat/imx8m): add SiP call for secondary boot"),
which leverages this SoC feature.
However neither i.MX8MP nor i.MX8MN have a dedicated bit
which indicates what boot image set is currently booted.
According to AN12853 [1] "i.MX ROMs Log Events", it is
possible to determine whether fallback event occurred
by parsing the BootROM event log. In case ROM event ID 0x51 is
present,fallback event did occur and secondary boot image was booted.
Knowing which boot image was booted might be useful for reliable
bootloader A/B updates, detecting fallback event might be used for
making decision if boot firmware rollback is required.
This patche introduces implementation, that replicates the same
imx_src_handler() behaviour as on i.MX8MM/MQ SoCs.
The code is based on original U-Boot implementation [2].
[1]: https://www.nxp.com/webapp/Download?colCode=AN12853
[2]: a5ee05cf71
Change-Id: I9a4c5229aa0e53fa23b5261459da99cb3ce6bdbe
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
Cortex X3 erratum 2641945 is a Cat B erratum that applies to all
revisions <= r1p0 and is fixed in r1p1.
The workaround is to disable the affected L1 data cache prefetcher
by setting CPUACTLR6_EL1[41] to 1. Doing so will incur a performance
penalty of ~1%. Contact Arm for an alternate workaround that impacts
power.
SDEN documentation:
https://developer.arm.com/documentation/2055130/latest
Change-Id: Ia6d6ac8a66936c63b8aa8d7698b937f42ba8f044
Signed-off-by: Bipin Ravi <bipin.ravi@arm.com>
commit@0a33adc058080433f73bde73895266068990245c
Deprecated CTX_INCLUDE_MTE_REGS but missed its usage in
context save and restore path.
Change-Id: I30544abdff2cf92ff05d2d4df46ffc6ff10611de
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
As of now, GPT setup is being handled from BL2 for plat/arm platforms.
However, for platforms having a separate entity to load firmware images,
it is possible for BL31 to setup the GPT. In order to address this
concern, move the GPT setup implementation from arm_bl2_setup.c file to
arm_common.c. Additionally, rename the API from arm_bl2_gpt_setup to
arm_gpt_setup to make it boot stage agnostic.
Signed-off-by: Rohit Mathew <Rohit.Mathew@arm.com>
Change-Id: I35d17a179c8746945c69db37fd23d763a7774ddc
For RME-enabled platforms, initializing L0 and L1 tables and enabling
GPC checks is necessary. For systems using BL2 to load firmware images,
the GPT initialization has to be done in BL2 prior to the image load.
The common Arm platform code currently implements this in the
"arm_bl2_plat_gpt_setup" function, relying on the FVP platform's
specifications (PAS definitions, GPCCR_PPS, and GPCCR_PGS).
Different Arm platforms may have distinct PAS definitions, GPCCR_PPS,
GPCCR_PGS, L0/L1 base, and size. To accommodate these variations,
introduce the "plat_arm_get_gpt_info" API. Platforms must implement
this API to provide the necessary data for GPT setup on RME-enabled
platforms. It is essential to note that these additions are relevant to
platforms under the plat/arm hierarchy that will reuse the
"arm_bl2_plat_gpt_setup" function.
As a result of these new additions, migrate data related to the FVP
platform to its source and header files.
Signed-off-by: Rohit Mathew <Rohit.Mathew@arm.com>
Change-Id: I4f4c8894c1cda0adc1f83e7439eb372e923f6147
In accordance with common naming conventions, macros specifying the base
address of a region typically use the prefix "BASE" combined with the
region name, rather than "ADDR_BASE."
Currently, the macros defining the base addresses for L0 and L1 GPT
tables within `arm_def.h` are named "ARM_L0_GPT_ADDR_BASE" and
"ARM_L1_GPT_ADDR_BASE" respectively. To adhere to the established naming
convention, rename these macros as "ARM_L1_GPT_BASE" and
"ARM_L0_GPT_BASE" respectively.
Signed-off-by: Rohit Mathew <Rohit.Mathew@arm.com>
Change-Id: Ibd50a58a1f63ba97d2df141f41a21a89ef97d6fb
