Hi everybody,
I am writing a program to put debug data in the 32KB L1 Data cache, then read back via method in A53 TRM section 6.7) direct access to internal memory.
I disable the data cache then put zero in DDR at address 0-32KB, then enable/invalidate data cache and do a sum of that 32KB. In theory A53 would move that 32K from DDR to L1D.
Then I read back the L1D, small portion of the data are non-zero, through the tag values I can trace the contamination to contents near the stack.
My program is stored in DDR region 16-24MB which I marked as NORM_NONCACHE. The program is approx. 20KB and works at EL3/baremetal with JTAG debugger attached.
What might have gone wrong with my method?
Thank you.
User_0182
" In theory A53 would move that 32K from DDR to L1D. " This assumption is not always valid.
Given that your code in DDR region is marked as NORM_NONCACHE, Cortex-A53 TRM says:<quote>If the cache reports a hit on a memory location that is marked as Non-Cacheable or Device, thisis called an unexpected cache hit. In this architecturally UNPREDICTABLE case, the cache mightreturn incorrect data. Because the caches are physically addressed, improper translation tableconfiguration can create this scenario. Disabling the cache can also create this situation.Non-Cacheable or Device accesses do not lookup in the cache, and therefore ignore anyunexpected cache hit.</quote>
Thank you Zhifei.
In that statement in the TRM, it mentioned improper translation table.
I used the following function in the Xilinx library to mark the regions as non-cacheable. MEM_0 is the only cacheable region. I can see it's the way how it's used.
I have another question, when the jtag debugger is used, would the data cache be used for the transactions like breakpoint/watchpoints? I believe the coresight would be a DEVICE in the TRM.
#define NORM_NONCACHE 0x401UL /* Normal Non-cacheable*/ #define NORM_WB_CACHE 0x705UL // Make code region as non-cacheable. void setup_mmu() { unsigned int addr_psu_ddr_0_MEM_0 = 0x0; unsigned int addr_psu_ddr_0_MEM_1 = 0x800000; unsigned int addr_psu_ddr_0_MEM_2 = 0x1000000; for (register int i=0; i<4; i++) { // Data region. Cache-able. Xil_SetTlbAttributes(addr_psu_ddr_0_MEM_0 + i*2*MEGA, NORM_WB_CACHE); } for (register int i=0; i<4; i++) { // Data region. Not cache-able. Xil_SetTlbAttributes(addr_psu_ddr_0_MEM_1 + i*2*MEGA, NORM_NONCACHE); } for (register int i=0; i<128; i++) { // Program region. Not cache-able. Xil_SetTlbAttributes(addr_psu_ddr_0_MEM_2 + i*2*MEGA, NORM_NONCACHE); } return; }
The CoreSight components provide a multi-core debug and trace solution with high bandwidth for whole systems, including trace and monitor of the system bus. So it is not accurate to understand the Coresight as the DEVICE concept of Arm.ARM.
When JTAG is connected, if the CPU will access the external memory, CPU cache is still valid.
My application particularly needs the L1 data cache to be not contaminated by unwanted data, that's why I mark many regions as uncache-able.
How do I distinguish software breakpoint and hardware breakpoint?
In my work I use Xilinx's Vitis, which is non-gdb. (I suppose gdb uses software breakpoint?)
Please see this article for HW/SW breakpoint difference.