We are using a Zynq-7000 SoC, and we are trying to do read and write to a locked L2 Cache through JTAG.
From JTAG, Read works properly but writes makes the specific cache line corrupted,
Step 1 : Initial Setup
1. Wrote an application Which runs from OCRAM
2. Load and lock entire L2 cache(pl310) to non existent address (physically not present SRAM address). L2 Cache is in Write-back, write-allocate mode
3. After that verified the L2 cache data from application itself and it works
Step2: Read from JTAG - Proper
Reading the L2 cache mapped locations from JTAG (using xilinx XSDB console) and it gives the application written value
Write through JTAG
Next, to check support for writing, we tried to write to a location in L2 cache from JTAG.
After writing, when we read back from same location through JTAG(using xilinx XSDB console) and application, we found that cache line size gets “corrupted”.
So could someone please tell me why locked L2 cache data get corrupted after writing through JTAG ?
ThanksAbhilash VR
Abhilash,
The issue may simply be as previously described: just because a debugger is accessing a core via a back door debug logic connection, it doesn't mean it can forego cache maintenance.
When you perform a "mwr" command in a debugger, the intent is usually that you want to commit that value to the lowest level of the memory system. As such, what usually happens is that it performs a load or store to the location via Instruction Transfer and DCC logic, and then sends a Data Cache Clean (potentially combined with an Invalidate). Since there is no real memory to back this eviction, it will not actually work as intended.
L2C-310 lockdown ONLY allows for the prevention of natural eviction, and debuggers WILL perform explicit cache maintenance, which are conceptually at odds with each other. You may be able to prevent your application from evicting itself from the cache via maintenance operations, but you usually cannot prevent a debugger from attempting to keep system memory coherent.
If you have a method of logging the transactions between xsdb and the target -- usage of the "DBGITR" register in particular -- you may be able to catch it sending an opcode for a data cache maintenance operation, which will prove this out. First things first, you may want to contact Xilinx for support, since it is far more likely to be a debugger issue at this point than any misconfiguration or misuse of the L2C-310 by yourself.
Thanks,
Matt