[Top] [All Lists]

Re: Deskstation progress and questions...

Subject: Re: Deskstation progress and questions...
From: Systemkennung Linux <>
Date: Thu, 8 Feb 1996 11:28:53 +0100 (MET)
In-reply-to: <> from "Warner Losh" at Feb 7, 96 10:36:59 pm

> I've managed to get to my first "out_p" statement!  I'm hanging there
> because mipsconfig.h defines PORT_BASE to be 0xe2000000.  On the
> Dekstation, this needs to be 0xb0000000, so I've hacked mipsconfig.h
> and am rebuilding.  Ideally, we'd have some way to do this that didn't
> require a recompile of the whole kernel, but it would also have to be
> fast, and I'm not sure that fast and configurable are both attainable
> here.  For the moment, I'm just punting and putting the ifdef in...

The whole in/out stuff originating from Linux's Intel history is a bit
messy.  The way I've coded this is optimized for maximum code speed at
minimal code size and probably a bit overoptimized.  (Andy'd says this
is a confession ...)  After all the in/out operations are *much* slower
than the speed of the host bus.  Speed is important for in/out in loops
and there the load of the address is outside the loop anyway.

For Deskstation Tyne, Magnum 4000 and Acer Pica the physical addresses
of the ports are outside the 4gb address range of the 32 bit mode and
therefore not accessible in the 32 bit mode.  I therefore mapped them
to address 0xe2000000.  This address is an arbitrarily choosen free
virtual address.  Well, to be honest it is the Acer BIOS mapping but
it's completly unimportant if whether to keep this mapping intact or not.

> However, I couldn't help notice some comments in mipsconfig.h that I
> need to ask some questions about...  Since this might later prove
> useful to other porters, I thought I'd ask them here...
> TLBMAP is defined to be 0xe4000000.  Where does one find what this
> address is for one's machine? I don't think I have physical memory at
> 0xexxxxxxx.  Is this a magic address, or can it be anywhere?  Looking
> at the MIPS User's Manual seems to indicate to me that this is
> something other than TLB, which lives in the CP0 register space, so
> this must be something else...  What, I'm not sure.  Have I overlooked
> something silly in the MUM?

TLBMAP is just an free virtual address range.  The value 0xe4000000
has been choosen arbitrarily and can be changed as needed.  This value
is hardcoded for speed reasons.

> TLB_ROOT is defined to be 0xe4390000.  (or more accurrately, (TLBMAP +
> (TLBMAP >> (12 - 2)))).  Once I find TLBMAP, then I'll have this, I'm
> sure...  Just thought I'd confirm this.


> Grepping the sources, TLBMAP shows up in
> include/asm-mips/mipsconfig.h, arch/mips/kernel{head,r4xx0}.S  From
> looking at the code there, and the MUM, it would appear that kseg3 is
> being setup to handle the TLB misses.  Hmmm, looking at r4xx0.S it
> appears that it is reloading the TLB from the PTE array that lives at
> TLBMAP.  I don't see where this gets created, however.  What am I
> missing?

You're just about to find the wonders of Linux/MIPS memory management ...
The big trick is that MIPS CPUs assume MMU data to be present in a
normal array while Linux maintains this data in a tree.  The
Linux/MIPS 32 bit memory managment code maintains this two-level tree in
KSEG1.  Entry 0 in the TLB is reserved as pointer to the first level
of this table.  It maps the first level table (4k == PAGE_SIZE) to address
TLB_ROOT.  This table then contains entries which map the complete
pagetable of 4mb size (for mapping the complete 4gb address space) to
address TLBMAP.

The trick is that the exception handler code has only to do the reload
for tlbl/tlbs exceptions (and some handling of accessed/dirty bits, which
is probably going away) and is optimized for maximum speed by moving
all complexity from it into the C code of the memory management.  This
is important when the working set of memory exceeds the value

  number of free pages * page_size

and therefore the tlb (which can essentilly be treated as cache) starts
thrashing.  At that point every instruction counts.

The code is reading/writing the MMU table at both kseg1 and kseg3.  Due
to the problems with cache aliasing on the virtual indexed R4000 caches
the pagetables have to be accessed uncached.  This is a bit a problem
for the performance and the best solution for it spells R10000 ...

> Thanks for any help you might be able to render...


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