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

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

[Jun Sun]

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

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

[Ralf Baechle]

On Mon, Jun 19, 2000 at 03:58:40PM -0700, Jun Sun wrote:

> 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.

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

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

Yes :-)

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

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

I leave the question to Geert to answer.

  Ralf

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

[Geert Uytterhoeven]

On Mon, 19 Jun 2000, Jun Sun wrote:
> 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?

  - 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)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

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

[Dominic Sweetman]

Jun Sun (jsun@mvista.com) writes:

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

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.  

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

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
dom@algor.co.uk

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

[Geert Uytterhoeven]

On Tue, 20 Jun 2000, Dominic Sweetman wrote:
> Jun Sun (jsun@mvista.com) writes:
> > 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?
> 
> 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.

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

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248638 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

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

[Jun Sun]

Dominic Sweetman wrote:
> 
> Jun Sun (jsun@mvista.com) writes:
> 
> > 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?
> 
> 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.
> 

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

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

[Jun Sun]

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 

Jun Sun wrote:
> 
> Dominic Sweetman wrote:
> >
> > Jun Sun (jsun@mvista.com) writes:
> >
> > > 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?
> >
> > 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.
> >
> 
> 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

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

[Dominic Sweetman]

Jun Sun (jsun@mvista.com) writes:

> I meant to talk about Vr5000 but I was looking at the Vr5432 manual!
> 1. both CPUs have two-way set-associative caches
> 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
dom@algor.co.uk

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

[Jun Sun]

> 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.
> 

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.


> Dominic Sweetman
> Algorithmics Ltd

Jun
> dom@algor.co.uk

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

[Kevin D. Kissell]

In any case, note that the cache descriptor structures
defined by MIPS Technologies for the Linux 2.2 kernels
(coming one of these days to 2.3) allow for the cache
geometry to be fully described and specified, either
as a simple table copy based on the PrID, or as a
combination of table data and dynamic probing.

            Kevin K.

-----Original Message-----
From: Jun Sun <jsun@mvista.com>
To: Dominic Sweetman <dom@algor.co.uk>
Cc: linux-mips@fnet.fr <linux-mips@fnet.fr>; linux@cthulhu.engr.sgi.com
<linux@cthulhu.engr.sgi.com>; nigel@algor.co.uk <nigel@algor.co.uk>
Date: Saturday, July 01, 2000 3:29 AM
Subject: Re: R5000 support (specifically two-way set-associative cache...)


>
>> 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.
>>
>
>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.
>
>
>> Dominic Sweetman
>> Algorithmics Ltd
>
>Jun
>> dom@algor.co.uk

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

[Kevin D. Kissell]

In any case, note that the cache descriptor structures
defined by MIPS Technologies for the Linux 2.2 kernels
(coming one of these days to 2.3) allow for the cache
geometry to be fully described and specified, either
as a simple table copy based on the PrID, or as a
combination of table data and dynamic probing.

            Kevin K.

-----Original Message-----
From: Jun Sun <jsun@mvista.com>
To: Dominic Sweetman <dom@algor.co.uk>
Cc: linux-mips@fnet.fr <linux-mips@fnet.fr>; linux@cthulhu.engr.sgi.com
<linux@cthulhu.engr.sgi.com>; nigel@algor.co.uk <nigel@algor.co.uk>
Date: Saturday, July 01, 2000 3:29 AM
Subject: Re: R5000 support (specifically two-way set-associative cache...)


>
>> 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.
>>
>
>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.
>
>
>> Dominic Sweetman
>> Algorithmics Ltd
>
>Jun
>> dom@algor.co.uk