linux-mips-fnet
[Top] [All Lists]

Re: [PATCH]: Linux for Baget/MIPS (r3k & VME box)

To: linux-mips@fnet.fr
Subject: Re: [PATCH]: Linux for Baget/MIPS (r3k & VME box)
From: Harald Koerfgen <harald.koerfgen@netcologne.de>
Date: Thu, 20 Aug 1998 21:53:55 +0200 (MEST)
In-reply-to: <35DBDCAC.95D9FF44@niisi.msk.ru>
Organization: none
Reply-to: "Harald Koerfgen" <harald.koerfgen@netcologne.de>
Sender: harry@franz.no.dom
[I am forwarding this to the list so that someone can correct me, if I am
writing bullsh*t]

Hi Gleb,

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.
> 
> Regards,
> Gleb.

Happy hacking.
---
Regards,
Harald

<Prev in Thread] Current Thread [Next in Thread>