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
Hi Matt,
Thanks for the reply !
To give an overview of our requirement ,
1. We want to load the application program (binary) directly into L2 cache through DAP using JTAG controller,mainly for debugging during development phase. ( This is where we are facing problem)
2. In our system we dont have an external RAM
3. We are using OCRAM for data space and for code space we want to use L2 cache as RAM
4.In Final product there will be a loader program in the flash which can intialize and lock L2 cache to a non-existent SRAM address space,and load the binary to be executed. ( This we tested and works fine)
Now coming to the points you raised,
What we meant by "corruption" is, after the write through JTAG, upon reading back the data, specific cache line became "zero". All other cache line data values remain same as what we wrote from Application.
Yes i expect we should be able to write the data to the cache because we are able to read and write properly from Application.
About Access to Cache
Based on the following figure from ARM CoreSight Technical Introduction document( ARM-EPM-039795), We thought DAP can get data from L2 cache through AXI interconnect / L2 cache controller but not through ARM Core.
From the above figure we infered when DAP try to read a memory location(non existent) whose data avail in L2 cache with state as "Modifed",the AXI interconnect/L2 cache controller detects the latest data is in L2 cache and will provide the latest data in cache through AXI interconnect as response to the read.
We can read the L2 cache values through JTAG (using xsdb console). We know this much as we got the proper values that was written by the application program.
xsdb% mrd 0xE4000000 4 --> read 4 values from address 0xE4000000 (Non existent SRAM address, locked to L2 cache)
E4000000: 0000000A -> Application Written value
E4000004: 0000000B
E4000008: 0000000C
E400000C: 0000000D
Write and Read back after write
After that when we write and read back (this time write using the JTAG via the xsdb console instead of an application program), the specific cache line value become zero.
xsdb% mwr 0xE4000000 0x12 --> write a value to address 0xE4000000 (Non existent SRAM address, locked to L2 cache)
xsdb% mrd 0xE4000000 4 --> Read back gives everything zero instead of setting it to 0x12
E4000000: 00000000
E4000004: 00000000
E4000008: 00000000
E400000C: 00000000
We also noticed if the physical memory exist (we tried with one portion of OCRAM), we are able to read and write from JTAG.
Based on this we infer as follows,
1.For the read access from DAP data in L2 cache was returned by AXI interconnect/L2 controller as explained above.
2.For write transaction from DAP, the AXI interconnect/ L2 controller detects it as a write to an address which is available in L2 cache with status as "Modified". Since AXI interconnect cannot write to the L2 cache(even though it can read),it will permit the write transaction to the physical address. Now L2 cache controller takes it as content modification in memory and it will change the status of this address in L2 cache as "invalid". This status is applicable to the cache line.
3.For Further reads from DAP, to the above address, AXI interconnect/ L2 controller detects it as read from an address in L2 cache with status as "invalid" and so instead of giving response from L2 cache, it wil allow to read from the "non-existent" physical address space and so we get junk data (in this case we saw all 0s).
4. Further, when we tried to read from the same location from application in OCRAM (through ARM core), we got 0s for that cache line. This could be because, when core tried to read from the address, it found status in L2 as "invalid" and so tried to fill cache line from the "non-existent" SRAM and so cache line became 0000.
As you mentioned, if we can write to L2 cache from DAP through ARM core, we would like to know how to do that. As described above, for our attempt, we don't think it happened through the ARM core. If there is a way to do that, that would solve our problem.
Please advise ?
Thanks in Advance,
Abhilash VR
Hi Abhilash,
Can you expand on what you mean by "corrupted"? Is it that the data you wrote does not appear in the cache? Did you expect that you would or wouldn't be able to write to that line?
Note that there's no way for the DAP access to directly read into the L2C-310, it would go via the ARM core, so your second and third diagrams are technically misleading -- that said, it isn't the diagram that would be the problem.
It is technically possible that the Xilinx debugger (as with most debuggers) play games with the SCTLR.C bit and perhaps even the L2C-310 settings to effect a physical memory access which does not get intercepted by a cache, or may perform cache maintenance operations (lockdown only guarantees that a line would not be naturally evicted -- cache maintenance may still cause this which would not be desirable). How exactly are you enacting the write using XSDB (note, we can't support Xilinx's tools particularly, but it may give away a clue).
Ta,