[Top] [All Lists]

Re: broken RM7000 in CVS ...

To: Jun Sun <>
Subject: Re: broken RM7000 in CVS ...
From: Justin Carlson <>
Date: Fri, 12 Jan 2001 12:29:39 -0800
In-reply-to: <>
Organization: Sibyte
References: <> <> <>
On Fri, 12 Jan 2001, you wrote:
> Justin Carlson wrote:
> > 
> > This is sort of true.  Mips32 does do a pretty good job of defining how to
> > probe for L1 caches and the like, but other things, such as L2 caches, are 
> > not
> > going to be so easily probed.  
> My understanding is that we don't have a standard way to probe for external
> cache (L2 or L3).  So this problem is not only for MIPS32 cpus.

It's not specific to mips32 processors, no.  My point was, the mips32 spec
doesn't (and probably shouldn't, IMHO) solve this problem completely.

> > If I'm understanding your idea correctly, this table would require you to
> > always compile in all the mmu routines for all processors, just to fill in 
> > the
> > table entries.  Doesn't seem like a particularly good idea to me, even if we
> > could use generic mips32 routines for most parts.
> >
> Each table entry can be surrounded by something like #if
> defined(CONFIG_CPU_RM7000) and #endif.  That should take care of the problem.

Not if you want to have constant-defined offsets into the table.  Which is just
about the only reason to use a table for this...Either:

1)  You've got multiple entries in the table for different cpus, which you're
indexing by some hash of PRID fields.  This requires a full table.  (Or a really
ugly hash function that's adaptive depending on which which cpu support is
compiled in)

2)  You've got a single entry table.  

Unless I'm really misunderstanding what you're proposing...


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