Subject: ARM caches
To: None <port-arm32@netbsd.org>
From: Ignatios Souvatzis <is@jocelyn.rhein.de>
List: port-arm32
Date: 02/26/1999 21:01:02
Hello,
I tried to understand how StrongARMs and our kernel work wrt. caches.
Let me summarize, and correct me if I'm wrong:
- both I and D caches are virtual. (If available)
- At context switch time, we flush the user addresses from the caches.
As a result:
- if a process modifies itself, or a kernel modifies curproc, it has to
do I-cache syncing.
- if a process or the kernel modifies a process != curproc, it doesn't
have to do extra work besides what would happen at the next context switch
making it active.
Is this right?
The reason I'm asking is that I looked at the relevant code and at StrongARM
documentation, trying to understand what pmap_procwr would need to do on
arm32. (And I tried setting a breakpoint from gdb, and it worked.)
It looks to me that it would do a
/****/
if (p != curproc)
return;
call_the_available_icache_sync_code();
/****/
Yes, so its not relevant for gdb, but somebody might be find a reason
to manipulate its own address space through procfs instead of directly.
For the background, look at tech-kern, thread
PR 6152 (gdb fails on UVM for seperate I&D), and fix (ATTN portmasters
Regards,
Ignatios