linux-mips
[Top] [All Lists]

RE: Interrupt handling....

To: Dominic Sweetman <dom@algor.co.uk>
Subject: RE: Interrupt handling....
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Wed, 4 Sep 2002 14:58:26 +0200 (MET DST)
Cc: Matthew Dharm <mdharm@momenco.com>, Jun Sun <jsun@mvista.com>, Linux-MIPS <linux-mips@linux-mips.org>
In-reply-to: <200209040953.KAA17466@mudchute.algor.co.uk>
Organization: Technical University of Gdansk
Original-recipient: rfc822;linux-mips@linux-mips.org
Reply-to: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 4 Sep 2002, Dominic Sweetman wrote:

> > Which, as you can see, attempts to access address 0xfc00000c.
> 
> But that address is in the MIPS CPU's 'kseg2' region.  Addresses there
> are always translated by the TLB, and you haven't got an entry.
> 
> Registers from things like the 2nd level interrupt controller are
> memory mapped I/O locations, and you need to do an uncached access to
> the appropriate physical address.

 As I understand 0xfc00000c is the physical address.  Thus you cannot
reach it via KSEG0/1 (although you may use XKPHYS to get there in the
64-bit mode).  Still ioremap() already handles the case mapping the area
requested in the KSEG2 space, so it should work just fine. 

> Most MIPS hardware has registers mapped between 0-512Mbyte
> (0-0x1fff.ffff) physical, because a MIPS CPU can do uncached accesses
> to that using the 'kseg1' window, which occupies the 
> 
>   0xa000.0000-0xbfff.ffff  (CPU virtual address)
>   0x0000.0000-0x1fff.ffff  (physical address).

 As I understand this is an exception.  Possibly the system supports more
than 512MB of RAM and the designers wanted to avoid holes. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +



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