Subject: R5000 support (specifically two-way set-associative cache...)

From: Jun Sun <[email-masked]>
Date: Mon, 19 Jun 2000 15:58:40 -0700

I looked into the R5000 support and have a couple of questions:

1. Is R5000, specifically NEC Vr5000, fully supported?  I have seen
CONFIG_CPU_R5000 defined, but it does not appear to do much.

2. Specifically, NEC Vr5000 has two-way set-associative cache.  I
browsed through the cache code, and got concerned that I don't see any
code that seems to take care of that.  Do I miss something?

3. I understand Geert has a port to DDB5074 (with Vr5000 CPU).  Is this
port completed (including all interrupts, PCI related stuff).  Is this
port reliable?

Thanks a lot.

Jun

---

From: Geert Uytterhoeven <[email-masked]>
Date: Tue, 20 Jun 2000 10:44:28 +0200 (MET DST)

> port completed (including all interrupts, PCI related stuff).  Is this

  - Interrupts (both Nile4, PCI and ISA) are working.
  - PCI bus mastering doesn't work yet (I guess so because the Tulip driver
    doesn't work yet).
  - About reliability: I see random crashes, but they seem to happen on other
    platforms as well.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
[email-masked] ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

---

From: Dominic Sweetman <[email-masked]>
Date: Tue, 20 Jun 2000 10:47:42 +0100 (BST)

> code that seems to take care of that.  Do I miss something?

The two-way cache on the R5000 (and its R4600 parent) is implemented
so that the cache operations used during running don't have to know
about the cache organisation.  Even initialisation of an R5000 cache
can be done by a piece of code which has no reference to two-wayness
and just works over R4x00/R5000 CPUs.

So this is not *necessarily* a problem.  

> port completed (including all interrupts, PCI related stuff).  Is this

A note on this and Geert's response: early Vrc5074 system controller
chips had lots of bugs, with some particularly nasty ones hitting PCI
transfers with external initiators (like the ethernet chip).  Anyone
pioneering Linux on it should check carefully with NEC about the
status of their particular revision.

Dominic Sweetman
Algorithmics Ltd
[email-masked]

---

From: Geert Uytterhoeven <[email-masked]>
Date: Tue, 20 Jun 2000 12:02:41 +0200 (MET DST)

> status of their particular revision.

Since the same boards are fine running Aperios, I assume we don't have the
early ones.

Gr{oetje,eeting}s,

						Geert

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 20 Jun 2000 03:51:59 +0200

> CONFIG_CPU_R5000 defined, but it does not appear to do much.

Indeed, the various CPU options for the R4xxx / R5xxx CPUs mostly deal
with C compiler options as a minor optimization.

> code that seems to take care of that.  Do I miss something?

Yes :-)

The R5000 has R4600 style caches, so also uses the same code.

> port completed (including all interrupts, PCI related stuff).  Is this

I leave the question to Geert to answer.

  Ralf

---

From: Jun Sun <[email-masked]>
Date: Tue, 20 Jun 2000 11:41:10 -0700

> So this is not *necessarily* a problem.

I am not sure here.

Vr5000 uses vAddr:0 (bit 0) to select the way in a set.  I just cannot
imagine how you can invalidate both ways without referring to some
vAddrs that end with 1.

I understand some CPUs (perhaps R4600 is so?) uses the most-significant
bit within the cache line to select the way.  In that case, one can just
treat the line size as half as what the actual line size is, and the
cache can be treated as if they are directed mapped.  But I believe this
can not be the case with Vr5000.

Can someone familiar with R4600 tell us more about how R4600 cache is
setup to hide two-wayness?  Thanks.

Jun

---

From: Jun Sun <[email-masked]>
Date: Tue, 20 Jun 2000 12:01:37 -0700

Oops!  My bad!

I meant to talk about Vr5000 but I was looking at the Vr5432 manual!

So here is the clarification :

1. both CPUs have two-way set-associative caches
2. Vr5432 uses vAddr:0 to select the way
3. I am not 100% sure about Vr5000.  I think it actually uses vAddr:4,
the MSB of cache line size.  If this is true, the
reducing-line-size-by-half trick would work for Vr5000.

Sorry for the confusion.

Jun

---

From: Dominic Sweetman <[email-masked]>
Date: Tue, 20 Jun 2000 21:59:32 +0100 (BST)

> 2. Vr5432 uses vAddr:0 to select the way

The Vr5432 is indeed different, compelling you to be aware of the
number of sets.

> 3. I am not 100% sure about Vr5000.

It uses a high-order bit, just like R4600.

> > Can someone familiar with R4600 tell us more about how R4600 cache
> > is setup to hide two-wayness?  Thanks.

Fundamentally:

o "index" operations just go first through one set, then the other.
  So long as initialisation routines are applied to each possible
  index in turn, both sets get initialised.

o "hit" operations "just work".

So long as initialisation is done carefully (basic rule: perform one
stage to the whole cache before going on to the next), run-time cache
maintenance can and should be done with "hit" instructions, and you
don't need to worry whether the CPU is direct mapped, 2- or 4-way set
associative.

(it's all explained in my book, "See MIPS Run", of course...)

Even with the Vr5432 you only have to know the difference when first
setting up the CPU.

Dominic Sweetman
Algorithmics Ltd
[email-masked]

---

From: Jun Sun <[email-masked]>
Date: Fri, 30 Jun 2000 18:22:58 -0700

> Even with the Vr5432 you only have to know the difference when first

Not exactly - the current Linux/MIPS implementation uese index
operations to flush cache.
As a result flush_all_cache() does not really flush all cache.

Jun