> 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 */
};

void
qed_sync_inv_dcache_2way(va, sz)
        vaddr_t va;
        vsize_t sz;
{
        vaddr_t sva, eva;
        vsize_t setsize;

        __asm __volatile (".set mips3");
        sva = va & ~127;
        eva = (va + sz + 127) & ~127;
        setsize = cpucnf.dc_totalsize >> 1;
        do {
                /* sync and invalidate when hit */
                __asm __volatile ("cache 0x15, 0(%0)" :: "r"(sva));
                __asm __volatile ("cache 0x15, 0(%0)" :: "r"(sva + setsize));
                sva += cpucnf.dc_linesize;
        } while (sva <= eva);
}

Combined with CPU personality closure 'struct cpucnf', mips/ would
flexiblity to absorb variations.

Tohru Nishimura