| |
Dynamically loading code and cache coherency |
| |
ksattic (16:56 22/8/2005)
pnaulls (17:58 22/8/2005)
ksattic (18:28 22/8/2005)
Phlamethrower (18:39 22/8/2005)
ksattic (18:42 22/8/2005)
adrianl (21:28 22/8/2005)
ksattic (03:35 23/8/2005)
adrianl (17:25 24/8/2005)
ksattic (19:10 24/8/2005)
Hertzsprung (10:42 26/8/2005)
ksattic (15:28 26/8/2005)
john (18:52 26/9/2005)
|
| |
|
Simon Wilson |
Message #68563, posted by ksattic at 16:56, 22/8/2005 |
 Finally, an avatar!
Posts: 1291
|
Given an ARM with write-back D-cache and an I-cache (both enabled), are these the correct steps to take when dynamically loading code and then executing?
1. Load code into memory
2. Clean D-cache to memory
3. Flush write buffer
4. Invalidate I-cache
5. Execute
Is there something I'm missing? My reasoning for steps 2, 3 and 4 are to write newly-loaded instructions to memory, if there were any cache hits, and also to ensure that no stale code remains in the I-cache. Step 3 is probably not necessary as I believe step 2 blocks. I seem to be getting incorrect/stale code in the I-cache.
Thanks  |
| |
 [ Log in to reply ] |
| |
|
Peter Naulls |
Message #68566, posted by pnaulls at 17:58, 22/8/2005, in reply to message #68563 |
Member
Posts: 317
|
Only invalidating the I-cache is required. If you're seeing other problems, then you're probably doing something wrong (easy to do for stuff like this), or you have problems elsewhere. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #68567, posted by ksattic at 18:28, 22/8/2005, in reply to message #68566 |
Finally, an avatar!
Posts: 1291
|
Only invalidating the I-cache is required. If you're seeing other problems, then you're probably doing something wrong (easy to do for stuff like this), or you have problems elsewhere. Thanks for the response.
If I change the D-cache to be write-through for the area of memory my code is loaded to, then invalidating the I-cache is fine. However, when changing to write-back, this doesn't appear to do the trick.
Personally, I decided that with write-back caching, invalidating the I-cache was the only requirement, but a friend pointed out to me that the I-cache may read stale entries from main memory rather than current entries directly from the D-cache. Is my friend wrong? |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #68568, posted by Phlamethrower at 18:39, 22/8/2005, in reply to message #68567 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Why not just use OS_SyncrhoniseCodeAreas? |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #68569, posted by ksattic at 18:42, 22/8/2005, in reply to message #68568 |
Finally, an avatar!
Posts: 1291
|
Why not just use OS_SyncrhoniseCodeAreas? I'm not using RISC OS 
Thanks for the pointer to that SWI, though. Looking through Google Groups, I found the following post that appears to indicate I am doing the correct thing:
Google Groups link
The data cache is write back. Data is not written back to main memory until a cache line is replaced (there are two dirty bits per cache line, each indicating whether any of four words have been updated since read into the cache). If code is modified but the modifications are still held in the data cache when the processor comes to execute the new code, the old contents of the memory locations will be read into the instruction cache instead. [Edited by ksattic at 19:49, 22/8/2005] |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #68582, posted by adrianl at 21:28, 22/8/2005, in reply to message #68569 |
Member
Posts: 1637
|
Your original list of steps is correct for writeback cacheing and code that is being loaded as data via the CPU (ie. PIO rather DMA), since the Dcache contents will not necessarily be written back to memory.
The write buffer does need to be drained after cleaning the Dcache because the Dcache empties through the write buffer.
If you've set the memory area to write through, you'll still need the write buffer drain, but no Dcache clean.
For code transferred by DMA, you need only the Icache invalidate.
Lastly, note that the XScale core can invalidate selected Icache lines, so you don't need to invalidate the entire cache as you do on earlier ARM cores.
Oh, and check your CP register numbers carefully, or - better - copy the instruction(s) from the datasheet! As Peter says, such things can be hard to get right and to diagnose when they're wrong.
[Edited by adrianl at 22:34, 22/8/2005] |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #68584, posted by ksattic at 03:35, 23/8/2005, in reply to message #68582 |
Finally, an avatar!
Posts: 1291
|
Thanks, Adrian. It looks like I have another problem with my system (an ARM1136 machine).
That's interesting about the XScale being able to invalidate selected I-cache lines. I didn't see anything in the ARM1136 manual about it, but I'll have another look.
The CP numbers are right as far as I can tell - I checked them against the datasheets and other code I've seen. I didn't write the code myself, I am just trying to track down this problem.  |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #68620, posted by adrianl at 17:25, 24/8/2005, in reply to message #68584 |
Member
Posts: 1637
|
So? Fixed it yet?
I'll take a look at the code (if you're able to distribute it) if you think it could help. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #68626, posted by ksattic at 19:10, 24/8/2005, in reply to message #68620 |
Finally, an avatar!
Posts: 1291
|
It's not fixed yet. Unfortunately, I can't share the code as it is Sun's KVM ("Kilobyte" Virtual Machine) for Java. The rest of the stuff is Qualcomm proprietary. I confirmed that the cache functions are working correctly - I can view the memory I am caching from another processor (an ARM9) and I can see that it is dirty till I clean the d-cache on the ARM11 side.
I think the problem is the placement of the calls to the d-cache clean and i-cache invalidate functions. My thought is that they are loading the dynamic code, then calling the d-cache clean/i-cache invalidate, and then updating some dynamic code (like long jumps) without doing a clean/invalidate, so some code is left stale.
I tried to put a memory write breakpoint on the entire Java heap to see what was altering the instructions, but for some reason that wasn't working. I think more investigation is in order.
Cheers for all the help! |
| |
[ Log in to reply ] |
| |
|
James Shaw |
Message #68647, posted by Hertzsprung at 10:42, 26/8/2005, in reply to message #68626 |
 Ghost-like
Posts: 1746
|
Unfortunately, I can't share the code as it is Sun's KVM ("Kilobyte" Virtual Machine) for Java.  |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #68655, posted by ksattic at 15:28, 26/8/2005, in reply to message #68647 |
Finally, an avatar!
Posts: 1291
|
Unfortunately, I can't share the code as it is Sun's KVM ("Kilobyte" Virtual Machine) for Java.
I know...I've been so tempted to try building it on RISC OS.  |
| |
[ Log in to reply ] |
| |
|
John D |
Message #69702, posted by john at 18:52, 26/9/2005, in reply to message #68655 |
Member
Posts: 261
|
Unfortunately, I can't share the code as it is Sun's KVM ("Kilobyte" Virtual Machine) for Java.
I know...I've been so tempted to try building it on RISC OS.
Builds fine, I used it for my final year uni project. however obviously you only get the standard text interface, unless you compile against a suitable window manager. I was investigating concurrent programming so I didn't need any of that. |
| |
[ Log in to reply ] |
| |
|
