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.
One possible fix is to have board-specific setup routine fill in the needed
data in the mipc_cpu structure, although I am not sure if that is a little too
late in the startup process. (I think at least one flush_cache call is made
before we reach board_setup() routine).
Jun
> >
> > 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.
>
Each table entry can be surrounded by something like #if
defined(CONFIG_CPU_RM7000) and #endif. That should take care of the problem.
Jun
