On Wed, 28 Feb 2001, Toru Nishimura wrote:

> > there are some technical issues that need to be resolved before
> > support can be committed to the tree.  the main problem is that the 
> > rc32332 has a MIPS3 style MMU, but no 64-bit instructions.   (e.g. so 
> > all those dmtc0 instructions in locore_mips3.S have to be changed to
> > mtc0, etc.).  also, the cache is 2-way, but has 16 byte lines (i hacked
> > around that, but a clean solution is needed ... cgd has some proposals
> > in this area).
> 
> Whenever I look at mips/ directory, my lung starts choking for more
> fresh oxygen.  The IDT chip is one implemetation of recently defined
> MIPS32 specification.  For insn set wise it's a MIPS-II, but has R4000
> style doubled TLB entry MMU, yet 32bit long for everything, has 2way
> set associative primary cache.  What neccesary to have is closures
> to encapulate parameters and "ops" to build sane foundations like this;
> 
> struct cpuops mips1_cpuops = {
>         mips1_inv_icache,
>         mips1_sync_inv_dcache,
>         mips1_sync_dcache,
>         mips1_inv_dcache,
>         mips1_flush_cache,
>         mips1_SETASID,
>         mips1_TBIAP,
>         mips1_TBIS,
>         mips1_TLBWR,
>         mips1_wbflush,          /* depends on hardware implementation */
> };

There is currently a version of this in the MI mips layer if you look at
sys/arch/mips/include/locore.h for the mips_locore_jumpvec_t definition.

The MI cache probing need to have some way of setting prefered values
from the MD layer - several ports (pmax/arc/newsmips) hack the L2 cache
configuration in the MI layer - with each port doing it a different way!!

Wayne
-- 
  _____	   	Wayne Knowles,  Systems Manager
 / o   \/   	National Institute of Water & Atmospheric Research Ltd
 \/  v /\   	P.O. Box 14-901 Kilbirnie, Wellington, NEW ZEALAND
  `---'     	Email:   w.knowles@niwa.cri.nz