linux-mips-fnet
[Top] [All Lists]

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

To: Jun Sun <jsun@mvista.com>
Subject: Re: R5000 support (specifically two-way set-associative cache...)
From: Dominic Sweetman <dom@algor.co.uk>
Date: Tue, 20 Jun 2000 10:47:42 +0100 (BST)
Cc: linux-mips@fnet.fr, linux@engr.sgi.com, nigel@algor.co.uk
In-reply-to: <394EA5A0.B882F66A@mvista.com>
References: <394EA5A0.B882F66A@mvista.com>
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


<Prev in Thread] Current Thread [Next in Thread>