linux-mips
[Top] [All Lists]

Re: broken RM7000 in CVS ...

To: linux-mips@oss.sgi.com
Subject: Re: broken RM7000 in CVS ...
From: Justin Carlson <carlson@sibyte.com>
Date: Fri, 12 Jan 2001 11:06:56 -0800
In-reply-to: <3A5F53CB.F8EC3947@mvista.com>
Organization: Sibyte
References: <3A5E7FFB.79925DF9@mvista.com> <001e01c07c68$96155f80$0deca8c0@Ulysses> <3A5F53CB.F8EC3947@mvista.com>
Reply-to: carlson@sibyte.com
Sender: owner-linux-mips@oss.sgi.com
On Fri, 12 Jan 2001, you wrote:
> I think that is a good idea.  I suggest we have two more pointers in the
> mips_cpu strcuture : one to mips_mmu_ops structure, and the other to
> setup_exception_vectors() function.
> 
> BTW, I have a question about MIPS32 (or 4KC).  Do all MIPS32 CPUs have the
> same PRID?  Or all "incarnations" of 4KC have the same PRID?  

No.  Mips32 defines PRID into 4 partitions: a company id, processor id,
revision id, and company options field.  

>I suppose MIPS32
> CPUs have a more complete config register where you can probe for all the
> options.  For others we can use a table-like structure to fill in the options.

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.  I think the mmu_ops routines should continue
to be specialized on a per-processor basis, just because they are both quite
performance sensitive and relatively easy to write/maintain. 

> 
> Along this line, it probably makes sense to have another pointer to
> mips_cpu_config() function, where for MIPS32 it is the standard MIPS32 config
> probing function and for most others it is NULL.
> 
> Now the mips_cpu_table looks like :
> 
> struct mips_cpu mips_cpu_table[]={
>       { PRID_IMP_4KC, mips32_cpu_config},
>       { PRID_IMP_RM7K, null, 0xaaa, {...}}
>       .....
> };

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.  

> The cpu_probe() routine will now look like:
> {
>    read prid register
>    find mips_cpu_table[i] with matching PRID.
>    mips_cpu = &mips_cpu_table[i];
>    if (mips_cpu->mips_cpu_config) mips_cpu->mips_cpu_config();
> }
> 
> To me this is beautiful. Am I dreaming? :-)

See objections above.

I did submit a patch to Ralf a couple weeks ago to fix cpu_probe so it 
checks PRID according to the mips32 spec, but never heard back, and haven't
seen it show up in CVS.  WIll try again sometime soon, methinks.

-Justin


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