Folks:
	I've been slowly, and with some help from others, trying to revive
	the SGI O2 support; on my L2-less R5000 O2 things seem to work well
	modulo the gross hacks I need to get interrupts delivered and serv-
	iced.

	However, on Chris Sekiya's R5000SC, things go loopy very quickly
	with the kernel dying spontaneously at random places.  Luckily,
	the R5000 lets you disable L2-cache at runtime... doing so and
	fooling the cache code into thinking there isn't a cache makes
	it work.

	I've read up on the R5k secondary cache interface and functions,
	and it turns out that we do a very wrong thing on the R5000 by
	making the assumption it's secondary caches work just like the
	R4k caches.

	I'm not a born-and-bred MIPS-head and my "See MIPS Run" is still
	in storage, so I thought I'd ask a few questions here:

		* First of all, Jason noted that he'd verified RM5260 worked
		  on his P5064; was this with L2 or 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?
		* 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.

	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-):

			* 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?

Thanks for any hints/thoughts,
--rafal

----
Rafal Boni                                                     rafal@attbi.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill