feat(fvp): define single Root region

For FVP model define single Root PAS which
includes EL3 DRAM data, L1 GPTs and SCP TZC.
This allows to decrease the number of PAS
regions passed to GPT library a

feat(fvp): define single Root region

For FVP model define single Root PAS which
includes EL3 DRAM data, L1 GPTs and SCP TZC.
This allows to decrease the number of PAS
regions passed to GPT library and use GPT
mapping with Contiguous descriptor of
larger block size.

Change-Id: I70f6babaebc14e5e0bce033783ec423c8a26c542
Signed-off-by: AlexeiFedorov <Alexei.Fedorov@arm.com>

show more ...

feat(arm): add a macro for SPMC manifest base address

In RESET_TO_BL31, the SPMC manifest base address that is utilized by
bl32_image_ep_info has to be statically defined as DT is not available.
Com

feat(arm): add a macro for SPMC manifest base address

In RESET_TO_BL31, the SPMC manifest base address that is utilized by
bl32_image_ep_info has to be statically defined as DT is not available.
Common arm code sets this to the top of SRAM using macros but it can be
different for some platforms. Hence, introduce the macro
PLAT_ARM_SPMC_MANIFEST_BASE that could be re-defined by platform as per
their use-case. Platforms that utilize arm_def.h would use the existing
value from arm common code.

Signed-off-by: Rakshit Goyal <rakshit.goyal@arm.com>
Change-Id: I4491749ad2b5794e06c9bd11ff61e2e64f21a948

show more ...

feat(arm): migrate heap info to fw handoff

Mbed-TLS requires platforms to allocate it a heap for it's own internal
usage. This heap is typically between shared by BL1 and BL2 to conserve
memory.The

feat(arm): migrate heap info to fw handoff

Mbed-TLS requires platforms to allocate it a heap for it's own internal
usage. This heap is typically between shared by BL1 and BL2 to conserve
memory.The base address and size of the heap are conveyed from BL1 to
BL2 through the config TB_FW_CONFIG.

This slightly awkward approach necessitates declaring a placeholder node
in the DTS. At runtime, this node is populated with the actual values of
the heap information. Instead, since this is dynamic information, and
simple to represent through C structures, transmit it to later stages
using the firmware handoff framework.

With this migration, remove references to TB_FW_CONFIG when firmware
handoff is enabled, as it is no longer needed. The setup code now relies
solely on TL structures to configure the TB firmware

Change-Id: Iff00dc742924a055b8bd304f15eec03ce3c6d1ef
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

show more ...

refactor(arm): refactor secure TL initialization

The initialization logic for the secure transfer list is currently
scattered and duplicated across platform setup code. This not only leads
to ineffi

refactor(arm): refactor secure TL initialization

The initialization logic for the secure transfer list is currently
scattered and duplicated across platform setup code. This not only leads
to inefficiency but also complicates access to transfer lists from other
parts of the code without invoking setup functions. For instance,
arm_bl2_setup_next_ep_info acts as a thin wrapper in arm_bl2_setup.c to
provide access to the secure transfer list.

To streamline the interface, all setup code has been consolidated into a
central location.

Change-Id: I99d2a567ff39df88baa57e7e08607fccb8af189c
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

show more ...

feat(arm): add support for loading CONFIG from BL2

This commit introduces a new ARM platform-specific build option called
`ARM_FW_CONFIG_LOAD_ENABLE`. This option enables the loading of the
`fw_conf

feat(arm): add support for loading CONFIG from BL2

This commit introduces a new ARM platform-specific build option called
`ARM_FW_CONFIG_LOAD_ENABLE`. This option enables the loading of the
`fw_config` device tree when resetting to the BL2 scenario.

Additionally, the FW_CONFIG image reference has been added to the
fdts/tbbr_cot_descriptors.dtsi file in order to use in the scenario of
RESET_TO_BL2.

Signed-off-by: Divin Raj <divin.raj@arm.com>
Change-Id: I11de497b7dbb1386ed84d939d6fd2a11856e9e1b

show more ...

feat(tc): setup ni-tower non-secure access for TC3

NI-Tower's component's registers are need to be accessed from
kernel NI-PMU driver so enable NS access to it.

Change-Id: I83a8b3a1d2778baf767ff932

feat(tc): setup ni-tower non-secure access for TC3

NI-Tower's component's registers are need to be accessed from
kernel NI-PMU driver so enable NS access to it.

Change-Id: I83a8b3a1d2778baf767ff93263e246d127ef8114
Signed-off-by: Jagdish Gediya <jagdish.gediya@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>

show more ...

fix(arm): move HW_CONFIG relocation into BL31

Refactor DT relocation logic from BL2 to BL31 for non-secure DRAM.
Previously, BL2 was responsible for copying the DT into SRAM and DRAM,
resulting in d

fix(arm): move HW_CONFIG relocation into BL31

Refactor DT relocation logic from BL2 to BL31 for non-secure DRAM.
Previously, BL2 was responsible for copying the DT into SRAM and DRAM,
resulting in duplicate code in BL31 to cater for the `RESET_TO_BL31`
case. By moving the re-location logic to BL31, we simplify handling of
the non-secure DT and TL.

Change-Id: Id239f9410669afe4b223fa8d8bb093084a0e5e1b
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

show more ...

fix(spm-mm): carve out NS buffer TZC400 region

SPM-MM defines AP TZC-400 regions as such:

1: 0xff000000 0xffffffff S
2: 0x80000000 0xfeffffff NS
3: 0x880000000 0xfffffffff NS
4: 0xff600000

fix(spm-mm): carve out NS buffer TZC400 region

SPM-MM defines AP TZC-400 regions as such:

1: 0xff000000 0xffffffff S
2: 0x80000000 0xfeffffff NS
3: 0x880000000 0xfffffffff NS
4: 0xff600000 0xff60ffff NS

Region 4 (using filter 0) defines the SPM NS shared buffer between
normal world and secure world.
However region 4 overlaps with region 1 (using filter 0) defined as
secure.
It is forbidden to define overlapping regions beyond region 0 for the
same filter. This is reported as a violation in the TZC-400 controller.

With FVP models < 11.25 the error is latent but not reported to the PE
(reason for this behavior is unclear).
With greater FVP model version the error is reported as an asynchronous
external abort (SError exception).

By carving out the SPM NS shared region (with regions as defined below),
the violation is no longer reported and test passed with recent FVP
models:

1: 0x80000000 0xfeffffff NS
2: 0xff000000 0xff5fffff S
3: 0xff600000 0xff60ffff NS
4: 0xff610000 0xffffffff S
5: 0x880000000 0xfffffffff NS

Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: Idc3370803ad204ac29efeded77305e52e17cc1c1

show more ...

feat(plat): add platform API that gets cluster ID

This patch adds an API(plat_cluster_id_by_mpidr)
that retrieves the cluster ID by looking at
the MPIDR_EL1 for platforms that have ARM_PLAT_MT set

feat(plat): add platform API that gets cluster ID

This patch adds an API(plat_cluster_id_by_mpidr)
that retrieves the cluster ID by looking at
the MPIDR_EL1 for platforms that have ARM_PLAT_MT set

Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Change-Id: I0266f2e49a3114d169a7708d7ddbd4f6229a7a41

show more ...

fix(psci): mask the Last in Level nibble in StateId

In the ARM recommended StateID Encoding, the index for the power
level where the calling core is last to go idle use the last niblle
of the StateI

fix(psci): mask the Last in Level nibble in StateId

In the ARM recommended StateID Encoding, the index for the power
level where the calling core is last to go idle use the last niblle
of the StateId.

Even if this nibble is necessary for OS-initiated mode, it can be
used by caller even when this OSI mode is not used.

In arm_validate_power_state() function, the StateId is compared with
content of arm_pm_idle_states[] build with the arm_make_pwrstate_lvl2
macro, without Last in Level information. So it is safe to mask this
nibble for ARM platform in all the cases, and that avoids issues with
caller with use the same StateId encoding with OSI mode activated or
not (in tftf tests for example, the input(power state) parameter =
(0x40001022) and the associated power state is 0x40000022).

Change-Id: I45e8e2b8f526fb61b94cf134d7d4aa3bac4c215d
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

show more ...

refactor(smccc): move pmf to vendor el3 calls

Move pmf support to vendor-specific EL3 Monitor Service Calls. Remove
pmf call count as it's not supported in vendor-specific el3 as per
SMCCC Documenta

refactor(smccc): move pmf to vendor el3 calls

Move pmf support to vendor-specific EL3 Monitor Service Calls. Remove
pmf call count as it's not supported in vendor-specific el3 as per
SMCCC Documentation 1.5:
https://developer.arm.com/documentation/den0028/latest

Add a deprecation notice to inform PMF is moved from arm-sip range to
vendor-specific EL3 range. PMF support from arm-sip range will be
removed and will not available after TF-A 2.12 release.

Change-Id: Ie1e14aa601d4fc3db352cd5621d842017a18e9ec
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

refactor(smccc): move debugfs to vendor el3 calls

Move debugfs to Vendor-Specific EL3 Monitor Service Calls.
Function Identifier for Vendor-Specific EL3 Monitor Service is '7' and
allocated subrange

refactor(smccc): move debugfs to vendor el3 calls

Move debugfs to Vendor-Specific EL3 Monitor Service Calls.
Function Identifier for Vendor-Specific EL3 Monitor Service is '7' and
allocated subranges of Function identifiers to different services are:

0x87000000-0x8700FFFF-SMC32: Vendor-Specific EL3 Monitor Service Calls
0xC7000000-0xC700FFFF-SMC64: Vendor-Specific EL3 Monitor Service Calls

Amend Debugfs FID's to use this range and id.

Add a deprecation notice to inform debugfs moved from arm-sip range to
Vendor-Specific EL3 range. Debugfs support from arm-sip range will be
removed and will not be available after TF-A 2.12 release.

Reference to debugfs component level documentation:
https://trustedfirmware-a.readthedocs.io/en/latest/components/debugfs-design.html#overview

Change-Id: I97a50170178f361f70c95ed0049bc4e278de59d7
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

feat(arm): support FW handoff b/w BL1 & BL2

Leverage the framework between BL1 and BL2. Migrate all handoff
structures to the TL.

Change-Id: I79ff3a319596b5656184cde10b5204b10a4d03bb
Signed-off-by:

feat(arm): support FW handoff b/w BL1 & BL2

Leverage the framework between BL1 and BL2. Migrate all handoff
structures to the TL.

Change-Id: I79ff3a319596b5656184cde10b5204b10a4d03bb
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

show more ...

feat(arm): support FW handoff b/w BL2 & BL31

Add support for the firmware handoff framework between BL2 and BL31.
Create a transfer list in trusted SRAM, leveraging the larger SRAM sizes
in recent m

feat(arm): support FW handoff b/w BL2 & BL31

Add support for the firmware handoff framework between BL2 and BL31.
Create a transfer list in trusted SRAM, leveraging the larger SRAM sizes
in recent models. Load the HW_CONFIG as a TE along with entry point
parameters for BL31 execution.

Change-Id: I7c4c6e8353ca978a13520fb3e15fb2803f0f1d0e
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

show more ...

fix(arm): only expose `arm_bl2_dyn_cfg_init` to BL2

The `arm_bl2_dyn_cfg_init` function is intended exclusively for BL2 - it
should not be compiled for any other bootloader image. This change hides

fix(arm): only expose `arm_bl2_dyn_cfg_init` to BL2

The `arm_bl2_dyn_cfg_init` function is intended exclusively for BL2 - it
should not be compiled for any other bootloader image. This change hides
it for all but BL2.

Change-Id: I9fa95094dcc30f9fa4cc7bc5b3119ceae82df1ea
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

feat(tc): add DPE context handle node to device tree

Child software components are inheriting their first valid
DPE context handle from their parent components (who loaded
and measured them). The co

feat(tc): add DPE context handle node to device tree

Child software components are inheriting their first valid
DPE context handle from their parent components (who loaded
and measured them). The context handle is shared through
the device tree object the following way:
- BL1 -> BL2 via TB_FW_CONFIG
- BL2 -> BL33 via NT_FW_CONFIG

Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: I9bf7808fb13a310ad7ca1895674a0c7e6725e08b

show more ...

fix(el3-spmc): add datastore linker script markers

Datastore symbol used by EL3 SPMC is not relocated at
boot time when using ENABLE_PIE=1.
Use linker script markers instead of symbol.

Signed-off-b

fix(el3-spmc): add datastore linker script markers

Datastore symbol used by EL3 SPMC is not relocated at
boot time when using ENABLE_PIE=1.
Use linker script markers instead of symbol.

Signed-off-by: Shruti Gupta <shruti.gupta@arm.com>
Change-Id: If22d2fc8deacc74c73d7dc51bb70093935d9fa2b

show more ...

feat(arm): add trusty_sp_fw_config build option

Also increase add PLAT_ARM_SP_MAX_SIZE to override the default
ARM_SP_MAX_SIZE to support Trusty image and move OPTEE_SP_FW_CONFIG
documentation to bu

feat(arm): add trusty_sp_fw_config build option

Also increase add PLAT_ARM_SP_MAX_SIZE to override the default
ARM_SP_MAX_SIZE to support Trusty image and move OPTEE_SP_FW_CONFIG
documentation to build-internals.rst as it's not externally set-able.

Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: Ief90ae9113d32265ee2200f35f3e517b7b9a4bea

show more ...

feat(fvp): added calls to unprotect/protect memory

Added SiP calls to FVP platform to protect/unprotect a
memory range.
These leverage rme features to change the PAS of a given
memory range from non

feat(fvp): added calls to unprotect/protect memory

Added SiP calls to FVP platform to protect/unprotect a
memory range.
These leverage rme features to change the PAS of a given
memory range from non-secure to secure.

The mentioned call is leveraged by the SPMC in the memory
sharing flow, when memory is shared from the normal world
onto the secure world.

More details in the SPM related patches.

Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: Iaf15d8603a549d247ffb1fc14c16bfb94d0e178a

show more ...

feat(arm): move GPT setup to common BL source

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 po

feat(arm): move GPT setup to common BL source

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

show more ...

feat(arm): retrieve GPT related data from platform

For RME-enabled platforms, initializing L0 and L1 tables and enabling
GPC checks is necessary. For systems using BL2 to load firmware images,
the G

feat(arm): retrieve GPT related data from platform

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

show more ...

refactor(arm): rename L0/L1 GPT base macros

In accordance with common naming conventions, macros specifying the base
address of a region typically use the prefix "BASE" combined with the
region name

refactor(arm): rename L0/L1 GPT base macros

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

show more ...

fix(rotpk): move rotpk definitions out of arm_def.h

The file arm_def.h currently contains common definitions used by ARM
platforms. However, some platforms may have their own definitions,
allowing t

fix(rotpk): move rotpk definitions out of arm_def.h

The file arm_def.h currently contains common definitions used by ARM
platforms. However, some platforms may have their own definitions,
allowing them to avoid a direct dependency on arm_def.h. For a clean
platform port of arm_def.h, none of the source files should directly
include arm_def.h; instead, they should include the platform header
which would indirectly include the required definitions.

Presently, the rotpk module has a source file that directly includes
arm_def.h. This could lead to compilation issues if the platform
incorporating the rotpk module has a separate implementation of some or
all of the definitions in arm_def.h file. To address this, move the
relevant definitions out of arm_def.h and into rotpk_def.h.

Signed-off-by: Rohit Mathew <Rohit.Mathew@arm.com>
Change-Id: I9e8b0d319391f9a167af5c69a7b2d42ac488e7b4

show more ...

chore(auth)!: remove CryptoCell-712/713 support

CryptoCell-712 and CryptoCell-713 drivers have been deprecated since
TF-A v2.9 and their removal was announced for TF-A v2.10 release.
See [1].

As th

chore(auth)!: remove CryptoCell-712/713 support

CryptoCell-712 and CryptoCell-713 drivers have been deprecated since
TF-A v2.9 and their removal was announced for TF-A v2.10 release.
See [1].

As the release is approaching, this patch deletes these drivers' code as
well as all references to them in the documentation and Arm platforms
code (Nuvoton platform is taken care in a subsequent patch). Associated
build options (ARM_CRYPTOCELL_INTEG and PLAT_CRYPTOCELL_BASE) have also
been removed and thus will have no effect if defined.

This is a breaking change for downstream platforms which use these
drivers.

[1] https://trustedfirmware-a.readthedocs.io/en/v2.9/about/release-information.html#removal-of-deprecated-drivers
Note that TF-A v3.0 release later got renumbered into v2.10.

Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: Idabbc9115f6732ac1a0e52b273d3380677a39813

show more ...

fix(ras): remove RAS_FFH_SUPPORT and introduce FFH_SUPPORT

This patch removes RAS_FFH_SUPPORT macro which is the combination of
ENABLE_FEAT_RAS and HANDLE_EA_EL3_FIRST_NS. Instead introduce an
inter

fix(ras): remove RAS_FFH_SUPPORT and introduce FFH_SUPPORT

This patch removes RAS_FFH_SUPPORT macro which is the combination of
ENABLE_FEAT_RAS and HANDLE_EA_EL3_FIRST_NS. Instead introduce an
internal macro FFH_SUPPORT which gets enabled when platforms wants
to enable lower EL EA handling at EL3. The internal macro FFH_SUPPORT
will be automatically enabled if HANDLE_EA_EL3_FIRST_NS is enabled.
FFH_SUPPORT along with ENABLE_FEAT_RAS will be used in source files
to provide equivalent check which was provided by RAS_FFH_SUPPORT
earlier. In generic code we needed a macro which could abstract both
HANDLE_EA_EL3_FIRST_NS and RAS_FFH_SUPPORT macros that had limitations.
Former was tied up with NS world only while the latter was tied to RAS
feature.

This is to allow Secure/Realm world to have their own FFH macros
in future.

Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ie5692ccbf462f5dcc3f005a5beea5aa35124ac73

show more ...