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