History log of /rk3399_ARM-atf/plat/arm/board/fvp/fvp_gicv3.c (Results 1 – 18 of 18)
Revision Date Author Comments
# e8460bd9 02-Oct-2025 Mark Dykes <mark.dykes@arm.com>

Merge "fix(arm): don't override the gic redistributor frames" into integration


# 1d59d686 25-Sep-2025 Boyan Karatotev <boyan.karatotev@arm.com>

fix(arm): don't override the gic redistributor frames

Patch 75170704c made an oversight - it would provide a default value for
the gicr_frames variable but would always set to it, regardless of
whet

fix(arm): don't override the gic redistributor frames

Patch 75170704c made an oversight - it would provide a default value for
the gicr_frames variable but would always set to it, regardless of
whether the platform might want to use something different. The thinking
was to provide a default and then let each platform override it, however
the order was swapped.

To fix this, put the gic_set_gicr_frames() in bl31_platform_setup()
rather than arm_bl31_platform_setup(). This way, platforms that use the
default can still enjoy it automatically pulled in from common code,
platforms that need fully custom gicr_frames can simply set it, and
platforms that override bl31_platform_setup() for unrelated reasons only
have to redo the call to gic_set_gicr_frames(). This has a tiny benefit
over the old approach in that there will never be 2 gicr_frames arrays.

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

show more ...


# dfdb73f7 16-Sep-2025 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge changes from topic "bk/no_blx_setup" into integration

* changes:
fix: replace stray BL2_AT_EL3 with RESET_TO_BL2
refactor(aarch64): move BL31 specific setup out of the PSCI entrypoint
re

Merge changes from topic "bk/no_blx_setup" into integration

* changes:
fix: replace stray BL2_AT_EL3 with RESET_TO_BL2
refactor(aarch64): move BL31 specific setup out of the PSCI entrypoint
refactor: unify blx_setup() and blx_main()
fix(bl2): unify the BL2 EL3 and RME entrypoints

show more ...


# f856626b 10-Sep-2025 Boyan Karatotev <boyan.karatotev@arm.com>

fix: replace stray BL2_AT_EL3 with RESET_TO_BL2

For FVP, patch 259b67c08 should have used the latter but introduced the
former. That was a mistake, correct it.

The nuvoton platform seems to have co

fix: replace stray BL2_AT_EL3 with RESET_TO_BL2

For FVP, patch 259b67c08 should have used the latter but introduced the
former. That was a mistake, correct it.

The nuvoton platform seems to have copied arm_def.h and would have been
missed at some point. Update that too.

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

show more ...


# baf2e39f 08-Aug-2025 Madhukar Pappireddy <madhukar.pappireddy@arm.com>

Merge changes I61d77211,I9cb5c1fa,I8e8a92fd into integration

* changes:
refactor(gicv3): clarify redistributor base address usage with USE_GIC_DRIVER=3
fix(gicv3): remove plat_gicv3_base.c
ref

Merge changes I61d77211,I9cb5c1fa,I8e8a92fd into integration

* changes:
refactor(gicv3): clarify redistributor base address usage with USE_GIC_DRIVER=3
fix(gicv3): remove plat_gicv3_base.c
refactor(versal-net): use the generic GIC driver

show more ...


# 75170704 29-Jul-2025 Boyan Karatotev <boyan.karatotev@arm.com>

refactor(gicv3): clarify redistributor base address usage with USE_GIC_DRIVER=3

The GICv3 driver has 2 methods of discovering the redistributors:
a) via setting gicr_base - done at boot and assumes

refactor(gicv3): clarify redistributor base address usage with USE_GIC_DRIVER=3

The GICv3 driver has 2 methods of discovering the redistributors:
a) via setting gicr_base - done at boot and assumes all GICR frames are
contiguous. This is the original method.

b) via gicv3_rdistif_probe() - called from platform code and requires
gicr_base == 0. It relaxes the requirement for frames to be
contiguous, like in a multichip configuration, and defers the
discovery to core bringup. This was introduced later.

Configurations possible with option a) are also possible with option b)
with only slightly different behaviour. USE_GIC_DRIVER=3 inherited
option b) from plat_gicv3_base.c and as such option a) is unusable.
However, it is unclear from code how this should be used. Clarify this
by requiring platforms initialise with gic_set_gicr_frames() and
adding relevant comments.

Also rename plat_arm_override_gicr_frames() to gic_set_gicr_frames() as
this is not plat arm specific and a part of the generic GIC driver.

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

show more ...


# 139a5d05 18-Apr-2025 Madhukar Pappireddy <madhukar.pappireddy@arm.com>

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 ...


# c5c54e20 07-Jan-2025 Boyan Karatotev <boyan.karatotev@arm.com>

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 ...


# 5d893410 07-Jan-2025 Boyan Karatotev <boyan.karatotev@arm.com>

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 ...


# cb331826 12-Dec-2024 Boyan Karatotev <boyan.karatotev@arm.com>

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 ...


# 2aaed860 23-Sep-2022 Joanna Farley <joanna.farley@arm.com>

Merge "refactor(libc): clean up dependencies in libc" into integration


# 885e2683 12-Sep-2022 Claus Pedersen <claustbp@google.com>

refactor(libc): clean up dependencies in libc

- Removing platform dependencies from libc modules.
- Replacing panicking with actual error handling.
- Debug macros are included indirectly from assert

refactor(libc): clean up dependencies in libc

- Removing platform dependencies from libc modules.
- Replacing panicking with actual error handling.
- Debug macros are included indirectly from assert.h. Removing
"platform_def.h" from assert.h and adding "common/debug.h"
where the macros are used.
- Removing hack for fixing PLAT_LOG_LEVEL_ASSERT to 40.
Instead removing assert with expression, as this
does not provide additional information.

Signed-off-by: Claus Pedersen <claustbp@google.com>
Change-Id: Icc201ea7b63c1277e423c1cfd13fd6816c2bc568

show more ...


# 925477ec 10-Feb-2021 Madhukar Pappireddy <madhukar.pappireddy@arm.com>

Merge changes from topic "GIC-work" into integration

* changes:
plat/arm: fvp: Protect GICR frames for fused/unused cores
doc: Build option to protect GICR frame
plat/arm: fvp: Do not map GIC

Merge changes from topic "GIC-work" into integration

* changes:
plat/arm: fvp: Protect GICR frames for fused/unused cores
doc: Build option to protect GICR frame
plat/arm: fvp: Do not map GIC region in BL1 and BL2

show more ...


# f98630fb 24-Jan-2021 Manish V Badarkhe <Manish.Badarkhe@arm.com>

plat/arm: fvp: Protect GICR frames for fused/unused cores

Currently, BLs are mapping the GIC memory region as read-write
for all cores on boot-up.

This opens up the security hole where the active c

plat/arm: fvp: Protect GICR frames for fused/unused cores

Currently, BLs are mapping the GIC memory region as read-write
for all cores on boot-up.

This opens up the security hole where the active core can write
the GICR frame of fused/inactive core. To avoid this issue, disable
the GICR frame of all inactive cores as below:

1. After primary CPU boots up, map GICR region of all cores as
read-only.
2. After primary CPU boots up, map its GICR region as read-write
and initialize its redistributor interface.
3. After secondary CPU boots up, map its GICR region as read-write
and initialize its redistributor interface.
4. All unused/fused core's redistributor regions remain read-only and
write attempt to such protected regions results in an exception.

As mentioned above, this patch offers only the GICR memory-mapped
region protection considering there is no facility at the GIC IP
level to avoid writing the redistributor area.

These changes are currently done in BL31 of Arm FVP and guarded under
the flag 'FVP_GICR_REGION_PROTECTION'.

As of now, this patch is tested manually as below:
1. Disable the FVP cores (core 1, 2, 3) with core 0 as an active core.
2. Verify data abort triggered by manually updating the ‘GICR_CTLR’
register of core 1’s(fused) redistributor from core 0(active).

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

show more ...


# caf24c49 09-Jun-2020 Mark Dykes <mardyk01@review.trustedfirmware.org>

Merge "plat/fvp: Add support for dynamic description of secure interrupts" into integration


# 452d5e5e 02-Jun-2020 Madhukar Pappireddy <madhukar.pappireddy@arm.com>

plat/fvp: Add support for dynamic description of secure interrupts

Using the fconf framework, the Group 0 and Group 1 secure interrupt
descriptors are moved to device tree and retrieved in runtime.

plat/fvp: Add support for dynamic description of secure interrupts

Using the fconf framework, the Group 0 and Group 1 secure interrupt
descriptors are moved to device tree and retrieved in runtime. This
feature is enabled by the build flag SEC_INT_DESC_IN_FCONF.

Change-Id: I360c63a83286c7ecc2426cd1ff1b4746d61e633c
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>

show more ...


# a773abb6 20-May-2020 Mark Dykes <mardyk01@review.trustedfirmware.org>

Merge "plat/fvp: Populate GICv3 parameters dynamically" into integration


# 8370c8ce 12-May-2020 laurenw-arm <lauren.wehrmeister@arm.com>

plat/fvp: Populate GICv3 parameters dynamically

Query the GICD and GICR base addresses in runtime using fconf getter
APIs.

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

plat/fvp: Populate GICv3 parameters dynamically

Query the GICD and GICR base addresses in runtime using fconf getter
APIs.

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

show more ...