You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature]: Cache Maintenance Support for Cortex-A and Cortex-R #318
Most Cortex-R cores (except the Cortex-R82) use the AArch32 CP15 coprocessor interface, similarly to ARMv7-A processors. As a result, the L1 cache maintenance code is very close across Armv7-A, Armv7-R, and Armv8-R.
However, the Cortex-R52 does not provide an equivalent register interface for L2 cache maintenance, as it does not use the same external L2 cache controller (PL310/L2C-310) commonly found on ARMv7-A systems.
Today, this code is already available in armv7a.h, but there is currently no equivalent support for Cortex-R.
For instance, I noticed that the Zephyr project has already consolidated this code in arch/arm/core/cortex_a_r/cache.c.
Given this overlap, could you help me determine the most appropriate architectural split for CMSIS? If necessary, what would be a suitable name for the shared header?
In general, we could found some cache_pl310.h file or similar and include them via the architecture profiles. We may end up with some high level cache functions like the ones we are already heaving, which are implemented per core forwarding calls to the underlaying implementation. This may looks similar as what we did with the gicv2.h where the R-profile just forwards to the A-profile.
I agree with you. The GIC, IRQ, and CP15 drivers are already separated into dedicated files. The L1 cache functionality is currently still part of the arm7a.h header file, but it could easily be extracted into a separate file following the same approach as the other drivers.
As a further step, it might also be possible to introduce a generic cache API that could cover both Cortex-A and Cortex-M caches. This could provide a more consistent interface across the different architectures.
Activity
JonatanAntoni commentedon Sep 2, 2026
cc @Masmiseim36
In general, we could found some
cache_pl310.hfile or similar and include them via the architecture profiles. We may end up with some high level cache functions like the ones we are already heaving, which are implemented per core forwarding calls to the underlaying implementation. This may looks similar as what we did with thegicv2.hwhere the R-profile just forwards to the A-profile.Masmiseim36 commentedon Sep 2, 2026
I agree with you. The GIC, IRQ, and CP15 drivers are already separated into dedicated files. The L1 cache functionality is currently still part of the arm7a.h header file, but it could easily be extracted into a separate file following the same approach as the other drivers.
As a further step, it might also be possible to introduce a generic cache API that could cover both Cortex-A and Cortex-M caches. This could provide a more consistent interface across the different architectures.
JonatanAntoni commentedon Sep 3, 2026
Let's start with A-/R-class first; and if you come up with a generic approach, we can extend it to M-class at any later point.
hamtinepeng commentedon Sep 3, 2026
Thank you for your help. I already have a patch ready, but I'll wait for this PR to be merged first.
hamtinepeng commentedon Sep 4, 2026
#319
hamtinepeng commentedon Oct 27, 2026
Solved with #319