linux-mips
[Top] [All Lists]

Re: MIPS CACHE TESTS

To: Dennis Castleman <DennisCastleman@oaktech.com>
Subject: Re: MIPS CACHE TESTS
From: Ralf Baechle <ralf@linux-mips.org>
Date: Tue, 10 Jun 2003 21:48:13 +0200
Cc: linux-mips@linux-mips.org
In-reply-to: <56BEF0DBC8B9D611BFDB00508B5E2634102FAC@tlexposeidon.teralogic-inc.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <56BEF0DBC8B9D611BFDB00508B5E2634102FAC@tlexposeidon.teralogic-inc.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
On Fri, Jun 06, 2003 at 11:00:23AM -0700, Dennis Castleman wrote:

(Well, not Dennis but Spamassassin ...)

> This mail is probably spam.  The original message has been attached
> along with this report, so you can recognize or block similar unwanted
> mail in future.  See http://spamassassin.org/tag/ for more details.

Of course it's not been spam, sorry for that faux pas.  This has been the
first false hit since I'm running Spamassassin for the linux-mips.org
mailing lists and so turned out a little bug in the scripts.

In any case, sending HTML to any of the linux-mips.org lists is an almost
certai way to get caught by the spam filter - HTML email on Linux mailing
lists is an almost certain indicator of SPAM ...

Back to the real business ...

> Subject: MIPS CACHE TESTS

> I trying to find a way of test both the instruction and data caches for a
> MIPS 5KC core.
> Does any body have any ideas?  Data cache is easy instruction cache is not
> so easy.

The trick is to run uncached.

> The Magnum pc-50 use to have a monitor called Rx4230 MIPS Monitor.
> This monitor dumped the following on power up

You're the first one to post about using Magnums in quite a while ...

> PONs Complete...
> PON Diagnostics Version 5.05 MIPS OPT Fri May 29 14:22:07 
>  
> YOMAN doesn't have any thing like this.  If any one knows of power on tests
> for a 5KC it would be of great interest to me.

I don't know of any readily available code.  The general strategy is to
run the cache tests in uncached mode and use the Index_Load_Tag_I etc.
commands to manipulate the cache content directly.  The general
strategy is to first verify that there are no dead bits in the cache,
the initialize all cache indices such that the ECC are set correctly to
avoid a later cache error exception.  For some set-way associative caches
the LRU bits may also have to be initialized.

Linux expects all this to already have been done by the firmware before
it's started.

  Ralf

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