TDA4VM: c7x and a72 cache coherence

Ryan,

I was asked to review your question.  It looks like this has been pending for a while with no updates from us or you.  Sorry for that.  I'll try and add some comments which hopefully help in improving understanding.

The system is designed for to be coherent for the MSMC direct connected memories (DDR & MSMC-SRAM). The logic in the MSMC will monitor all transactions landing in those memories and preform the necessary actions to keep all masters in sync. If your application needs hardware coherency then one of these two memory endpoints needs to be used. Other out of msmc-cluster srams will require SW management to ensure coherency.

The A72 and the C7x use the same MMU format so a simplified view is what works for the A72 will work for the C7x.  Perhaps the ARM will be a more familiar reference for you. Memory which is marked with copy-back-cache-inner is what is tracked by the HW.  Attributes + address + secure state (secure vs. non-secure) is used to track the transactions. Entities which can adjust the side band attributes which follow transactions need to ensure these settings are not misaligned or coherency will be lost. One example which has caused issue is the R5 clusters. They each have a register which forces the secure vs. non-secure state (other entities like USB have similar control points). If the R5 is setting secure but the same memory for the A72 or C7x is non-secure issues can result.

The MSMC memory can be setup as a coherent SRAM or as a coherent L3-Level cache.  The optimal setting between cache and sram will depend on the system application needs. Per the spec the L2CFG.M3CACHE is used to setup the ability for the C7x L2 cache to allocate or not from the MSMC L3 for areas configured as a cache. 0 tells the UMC (unified memory controller) to not allocate and 1 tells the UMC to follow the side band (cmemtype and ccinner) to decide whether to allocate or not.

As to your Lauterbach question. The MAP.Denyaccess was there to help make the debug experience more robust. The trace decoder may need to read memory to reconstruct trace.  Before the debugger port fully matured, sometimes a read to a wrong location happened as part of its operation. Depending on the state of the c7x system, this could result in a lock up which got in the way of productive debugging. This map deny was a protection to stop the user or the debugger from issuing a possibility fatal physical access. With current builds of TRACE32, I've not seen any issues in this area, so maybe today its a protection against the user probing in a nonsense place.  If your application sets up valid things in these other areas you can adjust the setting.

Regards,

Richard W.

Can c7x access a DDR 64bit address(like 0x8_8000_0000) before the mmu is enabled? I have seen lauterbach hang when loading code to a 64bit address before mmu is enabled and map.denyacess isn't set.

Ill check in a few days but I believe my c7x was secure mode and a72 wasn't so maybe that is why coherency didn't work.

Assuming r5 isn't in secure mode can it have coherency with a72 or other r5 cores?

Ryan,

Before the CMMU is enabled the C7x makes accesses using the reset uTLB entry value.  They default to a 1-1 mapping for up to 16GB of address space for the secure supervisor. Accesses past this region (like high DDR in 0x880000000) will result in a fault.  Without MMU and exception handlers these accesses above 16GB will result in a lock up. If you experiment with map.denyaccess you will find you can make accesses up to the 0x4_0000_0000 (16GB) without a lower map spaces collapsing. Its expected the boot code can operate in the lower 16GB. One of the uTLB entries can be reprogrammed to give higher accesses if necessary before the MMU is enabled.

Yes, mixed security states between the cores result in an alias. The hardware won't make those accesses coherent. Only by natural displacement might the accesses sometimes happen to be coherent.

For common access which are in MSMC-SRAM or MSMC-DDR cross cluster coherency will be there. The security state must be aligned. Local access to areas like TCMs or non-MSMC SRAMs would not be coherent.

Regards,

Richard W. 

Setting CXM to 3 root supervisor(S) vs 5(secure super) and then setting the appropriate TCR,TBR,MAR,SCR_S registers fixed the coherency. Thanks. 

Can only 1 uTLB be programmed. I would probably need 0 and 0x8_8000_0000 accessible at the same time so I can jump from 0 to upper address. Guessing I need to enable the mmu and then jump to 0x8_8... 

Where is the bit that says if r5 is secure?

I was also wondering when/if peripherals(usb,csi,emmc,udma..) use msmc or go right to ddr. Are they read or write allocate? Maybe they only use msmc cache if the data is already in msmc otherwise go to ddr. Does a cpu cache flush cause data to go to ddr or just msmc? What is a good way to know what is in msmc and ddr? I think the lauterbach E checkbox only shows msmc.