>> I'm not sure when it's necessary to flush the cache, now...
>
>is the cache real-addressed or virtual-addressed?
>in the abscence of DMA, one will require a cache flush
>and the other won't?
>(real doesn't require a flush?)
>I'm not sure
>eheh
>nick

The 68030 performs on chip cache look up in parallel with address
translation.  Thus on chip caches recieve virtual addresses.  In the event
that the virtual address requested is found in the appropriate on chip
cache, the mmu information is ignored(not strictly true).  On the 68030
motorola's user manual states on pages 6-1 that the intruction and data
caches are virtually addressed.  Thus the on chip caches should require a
cache flush any time the translation from virtual to physical addresses
changes.  This means whenever you change from process A to process B.  Now
here is where it get interesting: the 68030 has two root pointers to the
translation tree, the CRP and the SRP.  Under software control, the
processor can be configured to either use the CRP for all accesses
supervisor and user, or it can use the CRP for user mode accesses and the
SRP for supervisor mode accesses.  What MacBSD does I haven't a clue, as I
haven't had a chance to get that far into the code(allen should know) but
if the cpu is configured to use use the SRP and the CRP and they don't
point to the same place then a cache flush would be required when changing
from user to kernel mode.

NOTE: Here's a really interesting case: suppose that process A has one of
it's pages paged out to disk and subsequently does an access to a virtual
location that resides in the paged out page, but is also in the cache.
Essentially two cases arrise: 1) the page's descriptor resides in the
address translation cache 2) the page's descriptor doesn't reside in the
ATC if the pages translation resides what happens?  If the ATC is cacheing
the translation, and the ATC indicates that the range is invalid then a
fault occurs, BUT if translation is not in the ATC TWO MORE cases occur: 1)
the acceess is a read 2) the access is a write.  If it is a read the cache
value is used EVEN though the descriptor in the translation tables in
memory indicates an access to an invalid page (this occurs since the tables
are never consulted becuase the acces hits in the cache).  If it is a write
then the the tables must be searched since the 68030 on chip caches are
write through, and a physical address must be determined.  So when ever a
page is changed to invalid and the translation is not in the ATC the cache
should be flushed as well.

The above applies strictly to the on chip caches.  Since the processor
never places virtual addresses on the address bus, off chip caches must use
physical addresses and would be immune to changes in the current address
translation.  However, when accesses are made to memory mapped I/O then the
external cache must either recieve a cache inhibit signal from the I/O
device or it must be flushed.  Similarly in the case of DMA an external
cache should be flushed, or I suppose it could be made to snoop the DMA
access and invalidate address by address as the DMA procedes.

I am very interested in why external caches don't work with MacBSD on the
IIcI (I assume that internal caches do).  Does any one have any ideas?

---------
Christopher R. Bowman
crb@eng.umd.edu
My home page