Subject: Re: New MIPS cache code vs. R5k secondary caches...
To: Jason R Thorpe <thorpej@wasabisystems.com>
From: Rafal Boni <rafal@attbi.com>
List: port-mips
Date: 09/20/2002 19:21:24
In message <20020920135552.R1648@dr-evil.shagadelic.org>, you write:
-> On Fri, Sep 20, 2002 at 04:24:00PM -0400, Rafal Boni wrote:
->
-> > * First of all, Jason noted that he'd verified RM5260 worked
-> > on his P5064; was this with L2 or without?
->
-> As far as I know, none of the QED (now PMC-Sierra) RM52xx CPUs have an
-> L2 cache interface. Obviously, mine was tested without :-)
Ah! I did register for doc access at PMC-Sierra after I sent the previous
mail, and grabbed the manual and errata, but haven't read any of it yet.
-> > * Given the R5k has separate SC-present and SC-enabled bits,
-> > should the generic cache code only try and use the cache
-> > if both are true? Currently, it assumes if the SC-present
-> > bit is on, it must set up (and hence use) SC cache ops.
->
-> It should probably check SC-present and SC-enabled.
That's what I was thinking; this would also make it very easy to work around
the SC badness by clearing the enable bit in mips_machdep_cache_config() and
this causing the cache code to ignore the L2 cache.
-> > * The only defined operation for secondary cache is "page
-> > invalidate" which requires "page" (where "page" == 128
-> > cache lines of 32-bytes each) aligned addresses.
-> >
-> > * This means no indexed operations for secondary
-> > cache; what are the repercussions on the cache
-> > code here?
->
-> The code obviously tried to use HIT ops when it can. Since the L2
-> is write-through, you're okay ... you can make wbinv_range_index the
-> same as wbinv_all (sure, that sucks, but it will provide correct operation).
Hmm, OK. That would work.
-> So, it sounds like you need the following ops for the R5000 L2:
->
-> wbinv_all "page invalidate" the entire L2 in a loop.
-> Not sure how you'll go about doing this if
-> there is no index op!
Yah, I'm not either. The Linux code I've seem people toss around does as
if the page invalidate cacheop where actually indexed -- by just walking
from KSEG0 to KSEG0 + sdcache_size and invalidating each page inbetween.
Another way to do this may be to simply use the SDcache INDEX STORE TAG
to mark all the cache blocks invalid; this could also be used if we wanted
to invalidate very small regions (ie, << page size).
-> wbinv_range "page invalidate" the range. First round to
-> find the end address, then truncate to find
-> the start address.
Yup, this is the easy one.
-> wbinv_range_index Same as wbinv_all ??
->
-> inv_range Same as wbinv_range.
->
-> wb_range Noop.
Right.
--rafal
----
Rafal Boni rafal@attbi.com
We are all worms. But I do believe I am a glowworm. -- Winston Churchill