This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cache cleaning and invalidating in ARM Cortex-A

Cleaning or invalidating the L1 cache and L2 cache will not be a single atomic operation. A core might therefore perform cache maintenance on a particular address in both L1 and L2 caches only as two discrete steps. If another core were to access the affected address between those two actions, a coherency problem can occur. Such problems can be avoided by following two simple rules.

• When cleaning, always clean the innermost (L1) cache first and then clean the outer cache(s).

• When invalidating, always invalidate the outermost cache first and the L1 cache last.

So is the below mentioned order proper ?

when Cleaning the cache L1 : it should be as Clean L1

when Cleaning the cache L2 : it should be as Clean L1, then clean L2.

When invalidating the Cache L1 : Clean L1, L2, Invalidate L2, L1

When invalidating the Cache L2 : Clean L1, L2, Invalidate L2

Please correct me if im wrong.

Parents
  • It really depends on what you are trying to achieve.  There's no simple, general answer.

    Broad statements like "when cleaning, always clean inner then outer" therefore need to be treated with some caution.

    The usual reason for a synchronisation sequence like yours is to ensure that some data written by a CPU is visible to a peripheral that bypasses the caches (or vice versa).  Once the correct barriers have been added, your sequences would be OK for some purposes in a single-core system.  The atomicity issue is commonly solved by explicit handshaking -- e.g., CPU cleans the cache, issues a suitable barrier, then tells the peripheral to start reading: the peripheral doesn't start reading until it gets this notification.

    In a multi-core system, you need to take additional things into account, such as whether hardware cache coherency is active for the memory you're trying to synchronise.

    Can you provide a more specific example of what you want to do?

Reply
  • It really depends on what you are trying to achieve.  There's no simple, general answer.

    Broad statements like "when cleaning, always clean inner then outer" therefore need to be treated with some caution.

    The usual reason for a synchronisation sequence like yours is to ensure that some data written by a CPU is visible to a peripheral that bypasses the caches (or vice versa).  Once the correct barriers have been added, your sequences would be OK for some purposes in a single-core system.  The atomicity issue is commonly solved by explicit handshaking -- e.g., CPU cleans the cache, issues a suitable barrier, then tells the peripheral to start reading: the peripheral doesn't start reading until it gets this notification.

    In a multi-core system, you need to take additional things into account, such as whether hardware cache coherency is active for the memory you're trying to synchronise.

    Can you provide a more specific example of what you want to do?

Children
No data