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>