AM263P4: Cache and MPU issues related to AM263P4

Hi mingzhe dai,

Apologies for a delayed response, I'll try to answer all your questions one by one,

mingzhe dai said:

In the syscfg configuration of AM263P4, are the Region Attributes configurations limited to only certain combinations, rather than all possible combinations of Memory type, Shareability, Cacheability, and Cache policy?

Let me discuss this implementation in the SDK with the team and get back on why is this the case.

mingzhe dai said:

I would like to confirm whether my understanding of the Region Attributes combinations provided in syscfg is correct, particularly the highlighted entries.？

I have summarized in the table below:

You can also refer the ARM R5F TRM Section 7 (/cfs-file/__key/communityserver-discussions-components-files/908/1067.DDI0460C_5F00_cortexr5_5F00_trm.pdf)

mingzhe dai said:

According to the TRM manual, the last 32 bytes of every 512KB must be configured as non-cached. However, in the fastboot example, this region is set to shareable. Isn't shareable equivalent to cached + shareable?

No, configuring an MPU region as shareable does not automatically make it cached. Shareability and cacheability are independent attributes that can be configured separately. As above table shows, a region can be sharable and non-cachable. 

BUT, looking at the ti_dpl_config,c auto-generated code, I observe that when marked as Shared, the region also gets marked as "Cachable". I'll let the team know about this bug (jira.itg.ti.com/.../MCUSDK-14961)

mingzhe dai said:

Does AM263P4 currently only support Write-Back and Write-Allocate cache policies? So, whenever the RAM region is configured as cached, data consistency can only be maintained through Write-Back. Does this mean that automatic data consistency can theoretically only be achieved via Write-Through? How can I determine which data will be processed by the Cache, i.e., when to perform manual data synchronization (Write-Back)?

Yes, for the AM263P4 with ARM R5F cores, the SDK configuration primarily supports Write-Back and Write-Allocate (WB, WA) cache policies when a memory region is configured as cacheable.

When using Write-Back policy, data consistency isn't maintained automatically between cache and memory. The cache will hold modified data until the cache line is evicted, which means:

1. Data consistency can only be automatically maintained with Write-Through policy, which would write to both cache and memory simultaneously.
2. For Write-Back policy, you need manual cache maintenance operations (data synchronization) in these scenarios:
- When DMA or another processor needs to read memory that might have modified data in your CPU's cache
- When your CPU needs to read memory that might have been modified by DMA or another processor

To determine when to perform manual data synchronization:

- For CPU-to-memory: Use CacheP_wb() or CacheP_wbInv() before another master accesses memory written by CPU
- For memory-to-CPU: Use CacheP_inv() before CPU reads memory modified by another master
- For shared memory regions: Apply appropriate synchronization at critical points where consistency matters

Regards,
Shaunak

mingzhe dai said:

In the fastboot example, the RAM is configured as Cached. After performing relevant Flash operations, data consistency between the Cache and RAM is achieved using CacheP_wb to synchronize the data. In non-fastboot SBL (Secondary Boot Loader), the RAM region is configured as shareable. Given that shareable implies cached, does this also require the use of CacheP_wb to synchronize data between the Cache and RAM to ensure consistency?

By default, with the current SDK implementation, if region is marked as Sharable, by default it is being marked as cached, but the opposite is not true. If I mark the region as Cached, it is not sharable. Let me discuss on this potential bug with the team.

Ideally, If the region is "shared and non cached", we dont need CacheP_wb, but if it is "shared and cached", we do need it.