feat(fvp): implement platform API for LFA cancel operation

Introduce and implement a stub implementation of `plat_lfa_cancel()`
for the FVP platform. This function will later be expanded to handle
c

feat(fvp): implement platform API for LFA cancel operation

Introduce and implement a stub implementation of `plat_lfa_cancel()`
for the FVP platform. This function will later be expanded to handle
component-specific LFA cancellation logic.

Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I9690b011313bbe0fd458cbe47f32445f8d2d79fa

show more ...

feat(fvp): implement platform API for LFA activation pending check

Introduce and implement `is_plat_lfa_activation_pending()' API for the
FVP platform. Currently, only the RMM component is marked as

feat(fvp): implement platform API for LFA activation pending check

Introduce and implement `is_plat_lfa_activation_pending()' API for the
FVP platform. Currently, only the RMM component is marked as pending.

Change-Id: I6cc84c65ba5fe1b47cc65cbeeb349aac9235533a
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

feat(fvp): initialize LFA component activators in platform layer

Update the FVP platform's LFA component table to populate the
'activator' and 'activation_pending' by introducing fields
in plat_lfa_

feat(fvp): initialize LFA component activators in platform layer

Update the FVP platform's LFA component table to populate the
'activator' and 'activation_pending' by introducing fields
in plat_lfa_component_info_t.
- 'activator': function pointers for component-specific
activation logic
- 'activation_pending': tracks whether the component's activation
is pending

Set the activator function pointers for supported components:
- BL31 via get_bl31_activator()
- RMM (if RME is enabled) via get_rmm_activator()

This allows the LFA service to invoke component-specific prime
and activate callbacks through platform-registered hooks.

Change-Id: Ifd997a8b8cab209c25aabb2e9d4eab59e909ea4d
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

feat(fvp): implement LFA get components API

Introduce platform-specific implementation of
`plat_lfa_get_components()` for the Arm FVP platform. This function
returns LFA component metadata, includin

feat(fvp): implement LFA get components API

Introduce platform-specific implementation of
`plat_lfa_get_components()` for the Arm FVP platform. This function
returns LFA component metadata, including component ID, UUID for
each supported firmware image and number of components.

Change-Id: I9e7cbce5865becf3e4babcb770bc5eb3b69a0be8
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

Merge changes I2af839ae,Ifd0c7b4e,I56763cb4,I93aec580,Icbd43503, ... into integration

* changes:
docs(fvp): add GICv5 build instructions and limitations
feat(fvp): add GICv5 support
feat(gicv5

Merge changes I2af839ae,Ifd0c7b4e,I56763cb4,I93aec580,Icbd43503, ... into integration

* changes:
docs(fvp): add GICv5 build instructions and limitations
feat(fvp): add GICv5 support
feat(gicv5): probe components
feat(gicv5): initialise the IWB
feat(gicv5): initialise the IRS
feat(gicv5): assign interrupt sources to appropriate security states
feat(gicv5): add a barebones GICv5 driver
feat(gicv5): add support for building with gicv5

show more ...

docs(fvp): add GICv5 build instructions and limitations

Add documentation for enabling GICv5 support in the FVP platform,
including required build options and guidance on usage. Also document
curren

docs(fvp): add GICv5 build instructions and limitations

Add documentation for enabling GICv5 support in the FVP platform,
including required build options and guidance on usage. Also document
current limitations and known constraints.

Introduce build-time checks to ensure incompatible configurations
(e.g., with SPMD or RMMD) fail early with a clear error message.

Initial GICv5 support in FVP is intended to facilitate early Linux
kernel bring-up and to assist with upstream kernel patch development.

Note: This patch is a temporary measure and should be reverted once
proper and complete GICv5 support is upstreamed in TF-A.

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

show more ...

feat(fvp): add GICv5 support

Factors out GICv3 specific code and replace it with GICv5. This can be
selected with FVP_USE_GIC_DRIVER=FVP_GICV5. Specifically, the FCONF
logic does not apply to GICv5

feat(fvp): add GICv5 support

Factors out GICv3 specific code and replace it with GICv5. This can be
selected with FVP_USE_GIC_DRIVER=FVP_GICV5. Specifically, the FCONF
logic does not apply to GICv5 as the bindings are completely different.

This patch does not include a device tree. This will be added at a later
date.

Change-Id: Ifd0c7b4e0bc2ea1e53a6779ab4c50c4aec39dafb
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge "fix(fvp): workaround when PCIe 2 region is not present in DTB" into integration

fix(fvp): workaround when PCIe 2 region is not present in DTB

This patch applies a workaround to the RMM manifest when the DT
does not specify the 2nd PCIe region. As per FVP RevC memory map [1],
th

fix(fvp): workaround when PCIe 2 region is not present in DTB

This patch applies a workaround to the RMM manifest when the DT
does not specify the 2nd PCIe region. As per FVP RevC memory map [1],
there are 2 PCIe regions but the upstream FVP DT sourced from
kernel.org does not have this region specified. Temporarily
workaround this issue in FVP platform layer till the upstream DT is
fixed.

Note that the DT in `fdts` folder of TF-A source tree already has the
2 regions specified.

[1] https://developer.arm.com/documentation/100966/1101-00/Programming-Reference-for-Base-FVPs/Base---memory

Change-Id: If220e2dbeff00a1bf6eccadbb0ebb661b9c5e529
Signed-off-by: Soby Mathew <soby.mathew@arm.com>

show more ...

feat(fvp): add FVP_HW_CONFIG_ADDR make variable

Add a new variable that can be optionally set when calling `make`
to allow hw_config (such as DTB) to exist at a specified address.
Prior to this chan

feat(fvp): add FVP_HW_CONFIG_ADDR make variable

Add a new variable that can be optionally set when calling `make`
to allow hw_config (such as DTB) to exist at a specified address.
Prior to this change, the location was hardcoded to 0x82000000, which
could be overwritten if a preceeding image is large enough.
This new variable acts such that if it is unset, the behaviour
is exactly as before this patch, and if it is set, then the value
given is the hw-config's secondary-load-address value in the
fvp_fw_config DT.

Change-Id: I0b5158ef8c089b04078f2e9bb4408f03107591a5
Signed-off-by: emily.boarer@arm.com

show more ...

fix(fvp): avoid stack usage in check_cpupwrctrl_el1_is_available()

The function is called from assembly language before the stack is set
up. This fix prevents accessing unmapped memory at 0xffffffff

fix(fvp): avoid stack usage in check_cpupwrctrl_el1_is_available()

The function is called from assembly language before the stack is set
up. This fix prevents accessing unmapped memory at 0xffffffff_ffffffxx
by not storing the midr_no_cpupwrctl array on the stack.

Change-Id: I920e32c34bddf86a1dbf05b7115026413483b3c1
Signed-off-by: Linus Nielsen <linus@haxx.se>

show more ...

Merge "chore(fvp): remove unused macro definition" into integration

fix(fvp): increase EventLog size for OP-TEE with multiple SPs

When OP-TEE runs with multiple Secure Partitions (SPs), a larger
EventLog size is required to accommodate the additional measurements.
T

fix(fvp): increase EventLog size for OP-TEE with multiple SPs

When OP-TEE runs with multiple Secure Partitions (SPs), a larger
EventLog size is required to accommodate the additional measurements.
This patch updates the configuration to allocate sufficient memory
in such cases.

In the future, the Maximum EventLog size should be calculated based
on the maximum number of images loaded by BL2. That enhancement can
be addressed in a separate patch.

Change-Id: Ibd9bed0a5b1029158142711fd08809729dd05b08
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

feat(fvp): increase BL1 RW for PSA Crypto

Increase BL1 RW for PSA Crypto due to PSA key ID management redesign
needing an increase in heap size.

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeiste

feat(fvp): increase BL1 RW for PSA Crypto

Increase BL1 RW for PSA Crypto due to PSA key ID management redesign
needing an increase in heap size.

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I7c8d009f244be6252eff0d3ded3f1ca83fb1de21

show more ...

chore(fvp): remove unused macro definition

Remove an unused macro from the FVP platform code to
reduce clutter.

Change-Id: I88f9b3e6567362c0559fa58e1fbf9ace49c986b6
Signed-off-by: Manish V Badarkhe

chore(fvp): remove unused macro definition

Remove an unused macro from the FVP platform code to
reduce clutter.

Change-Id: I88f9b3e6567362c0559fa58e1fbf9ace49c986b6
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

Merge changes from topic "fix_pmuv3p9_test" into integration

* changes:
fix(smccc): properly set RAS feature bit
fix(trng): allow FEAT_RNG_TRAP in dynamic fashion
feat(smccc): add FEAT_TWED to

Merge changes from topic "fix_pmuv3p9_test" into integration

* changes:
fix(smccc): properly set RAS feature bit
fix(trng): allow FEAT_RNG_TRAP in dynamic fashion
feat(smccc): add FEAT_TWED to ARCH_FEATURE_AVAILABILITY
feat(cpufeat): add support for PMUv3p9

show more ...

fix(arm): update tsp_early_platform_setup prototype

The prototype for tsp_early_platform_setup has been redefined. Update
the platform implementation to match the new function signature and
ensure c

fix(arm): update tsp_early_platform_setup prototype

The prototype for tsp_early_platform_setup has been redefined. Update
the platform implementation to match the new function signature and
ensure compatibility with the updated TSP interface. Also, update the
prototype for arm_tsp_early_platform_setup to make use of these
arguments in common code.

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

show more ...

feat(fvp): port event log to firmware handoff

Support handing off the event log to both the secure and non-secure
worlds using the firmware handoff framework. This also needs us to
increase the maxi

feat(fvp): port event log to firmware handoff

Support handing off the event log to both the secure and non-secure
worlds using the firmware handoff framework. This also needs us to
increase the maximum allocation for TB-FW configuration to accommodate
trusted boot entries.

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

show more ...

feat(fvp): increase bl2 mmap len for handoff

With firmware handoff and OP-TEE the BL2 translation tables need to be
one entry longer than they currently are. Increase the current max
length by this

feat(fvp): increase bl2 mmap len for handoff

With firmware handoff and OP-TEE the BL2 translation tables need to be
one entry longer than they currently are. Increase the current max
length by this much to allow to build these two configurations together.

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

show more ...

Merge changes I86959e67,I0b0d1d36,I5b5267f4,I056c8710,I3474aa97 into integration

* changes:
chore: fix preprocessor checks
refactor: convert arm platforms to use the generic GIC driver
refacto

Merge changes I86959e67,I0b0d1d36,I5b5267f4,I056c8710,I3474aa97 into integration

* changes:
chore: fix preprocessor checks
refactor: convert arm platforms to use the generic GIC driver
refactor(gic): promote most of the GIC driver to common code
refactor: make arm_gicv2.c and arm_gicv3.c common
refactor(fvp): use more arm generic code for gicv3

show more ...

refactor: convert arm platforms to use the generic GIC driver

This reduces the code the platforms have to carry and makes their build
rules a bit simpler.

The main benefit is that plat_my_core_pos(

refactor: convert arm platforms to use the generic GIC driver

This reduces the code the platforms have to carry and makes their build
rules a bit simpler.

The main benefit is that plat_my_core_pos() no longer needs to be called
within the driver, helping with performance a bit.

Change-Id: I0b0d1d36d20d67c41c8c9dc14ade11bda6d4a6af
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

Merge changes from topic "hm/evlog" into integration

* changes:
refactor(measured-boot): refine event log lib docs
refactor(fvp): explicitly handle event log errors
feat(measured-boot): make e

Merge changes from topic "hm/evlog" into integration

* changes:
refactor(measured-boot): refine event log lib docs
refactor(fvp): explicitly handle event log errors
feat(measured-boot): make event log lib standalone

show more ...

refactor(gic): promote most of the GIC driver to common code

More often than not, Arm based systems include some revision of a GIC.
There are two ways of adding support for them in platform code - c

refactor(gic): promote most of the GIC driver to common code

More often than not, Arm based systems include some revision of a GIC.
There are two ways of adding support for them in platform code - calling
the top-level helpers from plat/arm/common/arm_gicvX.c or by using the
driver directly. Both of these methods allow for a high degree of
customisation - most functions are defined to be weak and there are no
calls to any of them in generic code.

As it turns out, requirements around those GICs are largely the same.
Platforms that use arm_gicvX.c use the helpers identically among each
other. Platforms that use the driver directly tend to end up with calls
that look a lot like the arm_gicvX.c helpers and the weakness of the
functions are never exercised.

All of this results in a lot of code duplication to do what is
essentially the same thing. Even though it's not a lot of code, when
multiplied among many platforms it becomes significant and makes
refactoring it quite difficult. It's also bug prone since the steps are
a little convoluted and things are likely to work even with subtle
errors (see 50009f61177421118f42d6a000611ba0e613d54b).

So promote as much of the GIC to be called from common code. Do the
setup in bl31_main() and have every PSCI method do the state management
directly instead of delegating it to the platform hooks. We can base
this implementation on arm_gicvX.c since they already offer logical
names and have worked quite well so far with minimal changes.

The main benefit of doing this is reduced code duplication. If we assume
that, outside of some platform setup, GIC management is identical, then
a platform can add support by telling the build system, regardless of
GIC revision. The other benefit is performance - BL31 and PSCI already
know the core_pos and they can pass it as an argument instead of having
to call plat_my_core_pos(). Now, the only platform specific GIC actions
necessary are the saving and restoring of context on entering and
exiting a power domain. The PSCI library does not keep track of this so
it is unable perform it itself. The routines themselves are also
provided.

For compatibility all of this is hidden behind a build flag. Platforms
are encouraged to adopt this driver, but it would not be practical to
convert and validate every GIC based platform.

This patch renames the functions in question to follow the
gic_<function>() convention. This allows the names to be version
agnostic.

Finally, drop the weak definitions - they are unused, likely to remain
so, and can be added back if the need arises.

Change-Id: I5b5267f4b72f633fb1096400ec8e4b208694135f
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

refactor: make arm_gicv2.c and arm_gicv3.c common

These files were meant to be platform specific, but they are generic
enough that a range of platforms find them useful. However, refactoring
them is

refactor: make arm_gicv2.c and arm_gicv3.c common

These files were meant to be platform specific, but they are generic
enough that a range of platforms find them useful. However, refactoring
them is difficult as their use is platform specific. So copy them to a
generic place and redirect platforms to them.

The new copies will remain for compatibility for platforms that don't
want to or can't take up upcoming refactors and the old copies can be
drastically refactored to make them more widely applicable.

Change-Id: I056c8710cdda4d8a81b324d392762c29e02cdae1
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

refactor(fvp): use more arm generic code for gicv3

The arm generic implementation for the GIC is quite comprehensive and
the fvp's requirements don't diverge too much. Despite that, they
completely

refactor(fvp): use more arm generic code for gicv3

The arm generic implementation for the GIC is quite comprehensive and
the fvp's requirements don't diverge too much. Despite that, they
completely override a lot of code that is effectively reused. Use the
generic implementation instead to make it easier to follow and override
as little code as possible.

Change-Id: I3474aa970d7fbb91d75c0be6a255bc0da734f860
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...