History log of /rk3399_ARM-atf/plat/arm/board/tc/platform.mk (Results 1 – 25 of 155)
Revision Date Author Comments
# bc3dac6c 27-Nov-2025 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge "fix(cpufeat): require FEAT_AMUv1p1 to enable the auxiliary counters" into integration


# 6edbd2d6 10-Nov-2025 Boyan Karatotev <boyan.karatotev@arm.com>

fix(cpufeat): require FEAT_AMUv1p1 to enable the auxiliary counters

The auxiliary counters are a feature of FEAT_AMUv1p1 but it's possible
to enable them (ENABLE_AMU_AUXILIARY_COUNTERS=1) without en

fix(cpufeat): require FEAT_AMUv1p1 to enable the auxiliary counters

The auxiliary counters are a feature of FEAT_AMUv1p1 but it's possible
to enable them (ENABLE_AMU_AUXILIARY_COUNTERS=1) without enabling
FEAT_AMUv1p1. As a result, the AMU_RESTRICT_COUNTERS may not take
effect, making this configuration potentially insecure.

Fix this by adding a constraints and rejigging auxiliary counter enables
such that they only happen when FEAT_AMUv1p1 has been enabled so that's
more apparent.

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

show more ...


# 42ddca15 23-Oct-2025 Bipin Ravi <bipin.ravi@arm.com>

Merge "fix(tc): force specifying TARGET_PLATFORM" into integration


# 81fece21 20-Oct-2025 Olivier Deprez <olivier.deprez@arm.com>

fix(tc): force specifying TARGET_PLATFORM

tc platform.mk has assumptions about TARGET_PLATFORM to be properly
defined.

For PLAT=tc if not specifying TARGET_PLATFORM on build command line, it
emits

fix(tc): force specifying TARGET_PLATFORM

tc platform.mk has assumptions about TARGET_PLATFORM to be properly
defined.

For PLAT=tc if not specifying TARGET_PLATFORM on build command line, it
emits the cryptic error message:

expr: syntax error: unexpected argument \u20182\u2019
plat/arm/board/tc/platform.mk:75: *** Platform tc is no longer available.. Stop.

Add an assert such that the error becomes:

plat/arm/board/tc/platform.mk:9: *** TARGET_PLATFORM must not be empty. Stop.

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

show more ...


# ddc1fcee 26-Sep-2025 Manish Pandey <manish.pandey2@arm.com>

Merge "refactor(arm/common): gate coherency behind flag" into integration


# 36fbcf4d 17-Sep-2025 Ahmed Azeem <ahmed.azeem@arm.com>

refactor(arm/common): gate coherency behind flag

Introduce a macro guard so platform coherency functions are only
compiled when HW_ASSISTED_COHERENCY is 0 (disabled). Many platforms
enable HW-assist

refactor(arm/common): gate coherency behind flag

Introduce a macro guard so platform coherency functions are only
compiled when HW_ASSISTED_COHERENCY is 0 (disabled). Many platforms
enable HW-assisted coherency by default, so compiling empty
definitions is unnecessary.

This refactor removes those empty functions for Arm CSS platforms.

Change-Id: I102ead46960e9da2d8b968f60cbfd3e5e5da1096
Signed-off-by: Ahmed Azeem <ahmed.azeem@arm.com>

show more ...


# cd30f9f8 18-Sep-2025 Govindraj Raja <govindraj.raja@arm.com>

Merge "chore(tc): align core names to Arm Lumex" into integration


# 7dae0451 04-Sep-2025 Min Yao Ng <minyao.ng@arm.com>

chore(tc): align core names to Arm Lumex

Adopt core names aligned to Arm Lumex [1]

Nevis => C1-Nano
Gelas => C1-Pro
Travis => C1-Ultra
Alto => C1-Premium

C1-Pro TRM: https://developer.arm.com/docu

chore(tc): align core names to Arm Lumex

Adopt core names aligned to Arm Lumex [1]

Nevis => C1-Nano
Gelas => C1-Pro
Travis => C1-Ultra
Alto => C1-Premium

C1-Pro TRM: https://developer.arm.com/documentation/107771/0102/
C1-Ultra TRM: https://developer.arm.com/documentation/108014/0100/
C1-Premium TRM: https://developer.arm.com/documentation/109416/0100/
C1-Nano TRM: https://developer.arm.com/documentation/107753/0001/

[1]:
https://www.arm.com/product-filter?families=c1%20cpus
https://www.arm.com/products/mobile/compute-subsystems/lumex

Signed-off-by: Min Yao Ng <minyao.ng@arm.com>
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: Id4b487ef6a6fd1b00b75b09c5d06d81bce50a15d
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...


# 35b2bbf4 28-Jul-2025 Manish Pandey <manish.pandey2@arm.com>

Merge changes from topic "bk/pabandon_cleanup" into integration

* changes:
feat(cpus): add pabandon support to the Alto cpu
feat(psci): optimise clock init on a pabandon
feat(psci): check that

Merge changes from topic "bk/pabandon_cleanup" into integration

* changes:
feat(cpus): add pabandon support to the Alto cpu
feat(psci): optimise clock init on a pabandon
feat(psci): check that CPUs handled a pabandon
feat(psci): make pabandon support generic
refactor(psci): unify coherency exit between AArch64 and AArch32
refactor(psci): absorb psci_power_down_wfi() into common code
refactor(platforms): remove usage of psci_power_down_wfi
fix(cm): disable SPE/TRBE correctly

show more ...


# 04c39e46 24-Mar-2025 Boyan Karatotev <boyan.karatotev@arm.com>

feat(psci): make pabandon support generic

Support for aborted powerdowns does not require much dedicated code.
Rather, it is largely a matter of orchestrating things to happen in the
right order.

T

feat(psci): make pabandon support generic

Support for aborted powerdowns does not require much dedicated code.
Rather, it is largely a matter of orchestrating things to happen in the
right order.

The only exception to this are older secure world dispatchers, which
assume that a CPU_SUSPEND call will be terminal and therefore can
clobber context. This was patched over in common code and hidden behind
a flag. This patch moves this to the dispatchers themselves.

Dispatchers that don't register svc_suspend{_finish} are unaffected.
Those that do must save the NS context before clobbering it and
restoring in only in case of a pabandon. Due to this operation being
non-trivial, this patch makes the assumption that these dispatchers will
only be present on hardware that does not support pabandon and therefore
does not add any contexting for them. In case this assumption ever
changes, asserts are added that should alert us of this change.

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

show more ...


# 9e7679ed 23-Jun-2025 Govindraj Raja <govindraj.raja@arm.com>

Merge "feat(tc): add support for configuring DSU settings" into integration


# fd4e6026 14-May-2025 Arvind Ram Prakash <arvind.ramprakash@arm.com>

feat(tc): add support for configuring DSU settings

This patch allows tc platforms to update DSU
CLUSTERPWRDN_EL1 and CLUSTERPWRCTLR_EL1 settings.
TC22 and TC23 use the DSU-120. Currently
we use the

feat(tc): add support for configuring DSU settings

This patch allows tc platforms to update DSU
CLUSTERPWRDN_EL1 and CLUSTERPWRCTLR_EL1 settings.
TC22 and TC23 use the DSU-120. Currently
we use the reset values as default settings as
per the DSU-120 TRM.

Reference: https://developer.arm.com/documentation/102547/0201

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

show more ...


# f8901e38 23-Jun-2025 Manish Pandey <manish.pandey2@arm.com>

Merge "feat(dsu): support power control and autonomous powerdown config" into integration


# d52ff2b3 07-May-2025 Arvind Ram Prakash <arvind.ramprakash@arm.com>

feat(dsu): support power control and autonomous powerdown config

This patch allows platforms to enable certain DSU settings
to ensure memory retention and control over
cache power requests. We also

feat(dsu): support power control and autonomous powerdown config

This patch allows platforms to enable certain DSU settings
to ensure memory retention and control over
cache power requests. We also move the driver out of css
into drivers/arm. Platforms can configure the
CLUSTERPWRCTLR and CLUSTERPWRDN registers [1] to improve
power efficiency.

These registers enable finer-grained control of
DSU power state transitions, including
powerdown and retention.

IMP_CLUSTERPWRCTLR_EL1 provides:
- Functional retention: Allows configuration of the
duration of inactivity before the DSU uses
CLUSTERPACTIVE to request functional retention.

- Cache power request: These bits are output on
CLUSTERPACTIVE[19:16] to indicate to the power controller
which cache portions must remain powered.

IMP_CLUSTERPWRDN_EL1 includes:
- Powerdown: Triggers full cluster powerdown, including
control logic.

- Memory retention: Requests memory retention mode,
keeping L3 RAM contents while powering off
the rest of the DSU.

The DSU-120 TRM [2] provides the full field definitions,
which are used as references in the `dsu_driver_data` structure.

References:
[1]: https://developer.arm.com/documentation/100453/latest/
[2]: https://developer.arm.com/documentation/102547/0201/?lang=en

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

show more ...


# c76da4ec 25-Apr-2025 Olivier Deprez <olivier.deprez@arm.com>

Merge "chore(tc): remove TC2 platform variant" into integration


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


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

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


# f036ddaf 09-Apr-2025 Manish V Badarkhe <Manish.Badarkhe@arm.com>

chore(tc): remove TC2 platform variant

Remove TC2 platform support which was deprecated in the last release.

Change-Id: Ibf4a94a0168151ebc66eaca044a143c51e974a1f
Signed-off-by: Manish V Badarkhe <M

chore(tc): remove TC2 platform variant

Remove TC2 platform support which was deprecated in the last release.

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

show more ...


# 31ddca40 14-Apr-2025 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge "feat(psci): remove cpu context init by index" into integration


# ef738d19 21-Jun-2024 Manish Pandey <manish.pandey2@arm.com>

feat(psci): remove cpu context init by index

Currently, the calling core (meaning the core which received the call to
CPU_ON or the powerdown path of CPU_SUSPEND on the same core) is in
charge of in

feat(psci): remove cpu context init by index

Currently, the calling core (meaning the core which received the call to
CPU_ON or the powerdown path of CPU_SUSPEND on the same core) is in
charge of initialising the context for the waking core (the warmboot
entrypoint for both). This is convenient because the calling core can
write the context while in coherency and the waking core will only need
the context after its entered coherency. This avoids any cache
maintenance and makes communication simple.

However, this has 3 main problems:
a) asymmetric feature support is problematic - the calling core has no
way of knowing the feature set of the waking core. If the two
diverge, the architectural feature discovery via ID registers breaks
down. We've thus far "fixed" this on a case by case basis which
doesn't scale and introduces redundancy.

b) powerdown abandon (pabandon) introduces a contradiction - the calling
core has to initialise the context for when the core wakes up, but
should the core not powerdown it needs its old context intact. The only
way to work around this is by keeping two copies of context which
incurs a runtime and memory overhead.

c) cm_prepare_el3_exit[_ns]() doesn't have access to the entrypoint but needs
it to make initialisation decisions. We can infer some of this from
registers that have already been written but this is awkwardly
limiting for what we can do. This also necessitates the split from
the context initialisation.

We can solve all three by a making a core be in full ownership of its
own context. The calling core then only writes entrypoint information
and nothing else. The waking core then initialises its own context as it
sees fit with full knowledge of the whole picture.

The only tricky bit is cache coherency - the waking core has to be able
to coherently observe its new entrypoint. Calling cores will write to
the shared region with coherent caches on. If we make sure to read the
context only after the waking core has entered coherency, then we can
avoid cache operations and let hardware handle everything.

We can skip the spsr check for FEAT_TCR2 as it doesn't make a
difference. We can also skip enabling it twice from generic code.

Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: I86e7fe8b698191fc3b469e5ced1fd010f8754b0e

show more ...


# 2e0354f5 25-Feb-2025 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge changes I3d950e72,Id315a8fe,Ib62e6e9b,I1d0475b2 into integration

* changes:
perf(cm): drop ZCR_EL3 saving and some ISBs and replace them with root context
perf(psci): get PMF timestamps wi

Merge changes I3d950e72,Id315a8fe,Ib62e6e9b,I1d0475b2 into integration

* changes:
perf(cm): drop ZCR_EL3 saving and some ISBs and replace them with root context
perf(psci): get PMF timestamps with no cache flushes if possible
perf(amu): greatly simplify AMU context management
perf(mpmm): greatly simplify MPMM enablement

show more ...


# 83ec7e45 06-Nov-2024 Boyan Karatotev <boyan.karatotev@arm.com>

perf(amu): greatly simplify AMU context management

The current code is incredibly resilient to updates to the spec and
has worked quite well so far. However, recent implementations expose a
weakness

perf(amu): greatly simplify AMU context management

The current code is incredibly resilient to updates to the spec and
has worked quite well so far. However, recent implementations expose a
weakness in that this is rather slow. A large part of it is written in
assembly, making it opaque to the compiler for optimisations. The
future proofness requires reading registers that are effectively
`volatile`, making it even harder for the compiler, as well as adding
lots of implicit barriers, making it hard for the microarchitecutre to
optimise as well.

We can make a few assumptions, checked by a few well placed asserts, and
remove a lot of this burden. For a start, at the moment there are 4
group 0 counters with static assignments. Contexting them is a trivial
affair that doesn't need a loop. Similarly, there can only be up to 16
group 1 counters. Contexting them is a bit harder, but we can do with a
single branch with a falling through switch. If/when both of these
change, we have a pair of asserts and the feature detection mechanism to
guard us against pretending that we support something we don't.

We can drop contexting of the offset registers. They are fully
accessible by EL2 and as such are its responsibility to preserve on
powerdown.

Another small thing we can do, is pass the core_pos into the hook.
The caller already knows which core we're running on, we don't need to
call this non-trivial function again.

Finally, knowing this, we don't really need the auxiliary AMUs to be
described by the device tree. Linux doesn't care at the moment, and any
information we need for EL3 can be neatly placed in a simple array.

All of this, combined with lifting the actual saving out of assembly,
reduces the instructions to save the context from 180 to 40, including a
lot fewer branches. The code is also much shorter and easier to read.

Also propagate to aarch32 so that the two don't diverge too much.

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

show more ...


# 2590e819 25-Nov-2024 Boyan Karatotev <boyan.karatotev@arm.com>

perf(mpmm): greatly simplify MPMM enablement

MPMM is a core-specific microarchitectural feature. It has been present
in every Arm core since the Cortex-A510 and has been implemented in
exactly the s

perf(mpmm): greatly simplify MPMM enablement

MPMM is a core-specific microarchitectural feature. It has been present
in every Arm core since the Cortex-A510 and has been implemented in
exactly the same way. Despite that, it is enabled more like an
architectural feature with a top level enable flag. This utilised the
identical implementation.

This duality has left MPMM in an awkward place, where its enablement
should be generic, like an architectural feature, but since it is not,
it should also be core-specific if it ever changes. One choice to do
this has been through the device tree.

This has worked just fine so far, however, recent implementations expose
a weakness in that this is rather slow - the device tree has to be read,
there's a long call stack of functions with many branches, and system
registers are read. In the hot path of PSCI CPU powerdown, this has a
significant and measurable impact. Besides it being a rather large
amount of code that is difficult to understand.

Since MPMM is a microarchitectural feature, its correct placement is in
the reset function. The essence of the current enablement is to write
CPUPPMCR_EL3.MPMM_EN if CPUPPMCR_EL3.MPMMPINCTL == 0. Replacing the C
enablement with an assembly macro in each CPU's reset function achieves
the same effect with just a single close branch and a grand total of 6
instructions (versus the old 2 branches and 32 instructions).

Having done this, the device tree entry becomes redundant. Should a core
that doesn't support MPMM arise, this can cleanly be handled in the
reset function. As such, the whole ENABLE_MPMM_FCONF and platform hooks
mechanisms become obsolete and are removed.

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

show more ...


# e0be63c8 13-Feb-2025 Manish V Badarkhe <manish.badarkhe@arm.com>

Merge changes I712712d7,I1932500e,I75dda77e,I12f3b8a3,Ia72e5900 into integration

* changes:
refactor(rse)!: remove rse_comms_init
refactor(arm): switch to rse_mbx_init
refactor(rse): put MHU c

Merge changes I712712d7,I1932500e,I75dda77e,I12f3b8a3,Ia72e5900 into integration

* changes:
refactor(rse)!: remove rse_comms_init
refactor(arm): switch to rse_mbx_init
refactor(rse): put MHU code in a dedicated file
refactor(tc): add plat_rse_comms_init
refactor(arm)!: rename PLAT_MHU_VERSION flag

show more ...


1234567