[Top] [All Lists]

Re: broken RM7000 in CVS ...

Subject: Re: broken RM7000 in CVS ...
From: Jun Sun <>
Date: Fri, 12 Jan 2001 12:27:55 -0800
References: <> <001e01c07c68$96155f80$0deca8c0@Ulysses> <> <>
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).


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


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