Subject: Re: New MIPS cache code vs. R5k secondary caches...
To: Rafal Boni <rafal@attbi.com>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: port-mips
Date: 09/20/2002 13:55:52
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 :-)
> * Second, (I haven't registered at PMC-Sierra to be able to
> get the manual yet), does anyone know if the RM5200 (and
> I asume 52xx as well?) has a R4k style SC interface, or
> if it's more R5k-like?
-rwxr-xr-x 1 thorpej wheel 3780278 Aug 21 2001 rm5200um_v3.2.pdf*
Want a copy? :-)
> * 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.
> The problems on the R5k seem to be this:
> * R5k SC is write-through (this isn't a big deal, other
> than all the writeback-only functions can be no-ops).
>
> * The CACHE instruction "operation" codes on the R5k are
> different than on the R4k 8-):
Time for a "cache_r5k*" I guess.
> * The R4k WB-INV maps to "flash invalidate", which
> flushes the whole cache, but only if the cache tag
> RAM chips support the column clear function; other-
> wise, it most likely does nothing.
> * The other ops the R4k cache code uses are undefined
> for the secondary cache on R5k systems.
>
> * 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).
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!
wbinv_range "page invalidate" the range. First round to
find the end address, then truncate to find
the start address.
wbinv_range_index Same as wbinv_all ??
inv_range Same as wbinv_range.
wb_range Noop.
--
-- Jason R. Thorpe <thorpej@wasabisystems.com>