[Top] [All Lists]

Re: Interrupt handling....

To: "Maciej W. Rozycki" <>
Subject: Re: Interrupt handling....
From: Matthew Dharm <>
Date: Wed, 4 Sep 2002 09:36:27 -0700
Cc: Dominic Sweetman <>, Jun Sun <>, Linux-MIPS <>
In-reply-to: <>; from on Wed, Sep 04, 2002 at 02:58:26PM +0200
Organization: Momentum Computer, Inc.
Original-recipient: rfc822;
References: <> <>
User-agent: Mutt/
On Wed, Sep 04, 2002 at 02:58:26PM +0200, Maciej W. Rozycki wrote:
> 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. 

This is the case.  The board itself has up to 1G of SDRAM.  Most of the
boards we sell have a minimum of 512MB.  So our I/O (PCI, external devices,
etc.) all have physical addresses in the high-end of the address space.

64-bit mode would be great... and we plan to go there eventually.  But, for
now, 32-bit is where we are.

> > 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. 

This is exactly the case.  Our organization focuses on high-end computing
platforms.  512MB is becoming a minimum amount of memory for us.


Matthew Dharm                              Work:
Senior Software Designer, Momentum Computer

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