[I am forwarding this to the list so that someone can correct me, if I am
On 20-Aug-98 Gleb O. Raiko wrote:
> What we still can't understand is when we must flush I-cache. Well, we
> do understand it in theory - I-cache must be flushed when new mapping
> for a physical page occurs.
Well, this is true for a R4k but not for a R3000. The R4k (and higher) have
virtually indexed caches, the R3000 (and R2000) have physically indexed caches.
If I understand this right, the only need for cacheflushing would be:
o DMA, obviously. Here both caches have to be flushed.
o Copying code. In this case the D-cache would be up to date, but the I-cache
doesn't know that code has changed. Here the I-cache has to be flushed.
The cache operations in arch/mips/mm/r2300.c are still quite R4000 oriented and
I have only implemented cache sizing and cache_flush_all for now. I still have
other problems ;-). If you are interested, I'd be happy to send you a copy.
> What we would do is to reduce cache
> flushing, e.g. don't flush I-cache if new mapping occurs for data
> segments (data, bss, stack, or whatever) what seems wrong to me because
> user may wish to execute a code which was formed in a data segment.
> Do you already know the policy ?
> Another issue we're working on is a bug (bugs?) in
> put_user/copy_to_user. It's reproduced fine - ls /lib shows garbage.