Skip to content

[Feature]: Cache Maintenance Support for Cortex-A and Cortex-R #318

Closed

Description

@hamtinepeng

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?

Activity

  1. JonatanAntoni commented on Sep 2, 2026

    @JonatanAntoni
    Member

    cc @Masmiseim36

    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.

  2. Masmiseim36 commented on Sep 2, 2026

    @Masmiseim36
    Contributor

    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.

  3. JonatanAntoni commented on Sep 3, 2026

    @JonatanAntoni
    Member

    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.

  4. hamtinepeng commented on Sep 3, 2026

    @hamtinepeng
    ContributorAuthor

    Thank you for your help. I already have a patch ready, but I'll wait for this PR to be merged first.

  5. hamtinepeng commented on Sep 4, 2026

    @hamtinepeng
    ContributorAuthor
  6. hamtinepeng commented on Oct 27, 2026

    @hamtinepeng
    ContributorAuthor

    Solved with #319

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions