[Top] [All Lists]

Re: Linux/MIPS for DECstations...

Subject: Re: Linux/MIPS for DECstations...
From: Ralf Baechle <>
Date: Wed, 1 Oct 1997 15:35:08 -0700 (PDT)
In-reply-to: <> from "Harald Koerfgen" at Oct 1, 97 07:53:34 pm
> >Nevertheless, for your case the superfluous srl instruction shouldn't make
> >a difference.  Note that the R3000 exception mechanism is a bit different
> >from the R4000, which means I'll have to read a bit ...
> Me too...
> Ok, all documentation about MIPS Processors are the "IDT R30xx Family Software
> Reference Manual" from IDT and the "MIPS R4000 Microprocessor User's Manual" 
> from SGI.
> [hours later]
> After carefully re-resing the IDT Manual ant glance at the SGI Manual, it is 
> my 
> understanding, that indeed there is a difference in the exception mechanism
> between the R3000 and the R4000.
> R4000:
> *All* TLB misses cause a TLB refill exception. If a TLB miss happens in the
> exception routine itself, a TLBL or TLBS exception is caused. This is handled
> bye the general exception handler.
> R3000:
> *Only* references to KSEG0 (0x00000000- 0x7fffffff) may cause a TLB exception.
> TLB misses with references to KSEG2 (0xc0000000 - 0xffffffff !!!) cause a 
> or TLBS exception, which is handled by the general exception handler.

So what you have to do in software is pretty easy.  To make things even
easier take a look at what the code in r4k_misc.S does when
NOTLB_OPTIMIZE is optimized.  That's the minimum it has to do; the rest
of the assembler code tries to handle some simple cases like dirtying
pages without calling the generic memory managment but that is just for
performance reasons.  Plus, on the R3000 you additionally have to examine
c0_badvaddr if it contains a KSEG2 address:

NESTED(r2k_handle_tlbl, PT_SIZE, sp)
                mfc0    k0,CP0_BADVADDR
                bltz    k0, go_utlb_tlbl

utlb_tlbl:      /* Do what the your old tlbl handler does */
                END(r2k_handle_tlbl, PT_SIZE, sp)
go_utlb_tlbl:   j       utlb_handler    /* The thing at KSEG0 or so */

If yes, just jump to the TLB exception handler.  Same thing for the tlbs

> Just to make shure, that I understand this right: can anybody on the list
> confirm this?

Yes, that's about right.  At least it's what I remember ...

> This could explain, why the kernel seems to die in the second level eception
> handler. It's simply a reference to the freshly vmalloced hash table.

You may want to modify the debugging helpers in arch/mips/lib/tlbdump.c
for the R3000, they'll probably really solve you alot of headaches.

> Paul wrote:
> >...I should probably say that I think this code is of dubious
> >parentage!  It would probably be best for you to look closely at the
> >MMU code.  I was only just getting my head around the R3K MMU when I
> >ran out of time to keep working on it, so I'd suggest you might even
> >want to throw it away and write it again!
> That would be the best. Ok, if nobody else wants to do it, I'll start 
> rewriting
> the R3000 TLB stuff.

When you're done with that you can call yourself MIPS-Man :-)


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