Re: broken RM7000 in CVS ...

[Jun Sun <jsun@mvista.com>]

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