From: Matthew Dharm <mdharm@momenco.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Dominic Sweetman <dom@algor.co.uk>, Jun Sun <jsun@mvista.com>,
Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: Interrupt handling....
Date: Wed, 4 Sep 2002 09:36:27 -0700 [thread overview]
Message-ID: <20020904093627.A5241@momenco.com> (raw)
In-Reply-To: <Pine.GSO.3.96.1020904144630.10619F-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Sep 04, 2002 at 02:58:26PM +0200
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.
Matt
--
Matthew Dharm Work: mdharm@momenco.com
Senior Software Designer, Momentum Computer
next prev parent reply other threads:[~2002-09-04 16:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3D6E87EB.4010000@mvista.com>
2002-09-04 1:10 ` Interrupt handling Matthew Dharm
2002-09-04 9:53 ` Dominic Sweetman
2002-09-04 12:58 ` Maciej W. Rozycki
2002-09-04 16:36 ` Matthew Dharm [this message]
2002-09-04 20:08 ` Dominic Sweetman
2002-09-05 9:17 ` Maciej W. Rozycki
2002-09-04 16:40 ` Matthew Dharm
2002-09-04 17:02 ` Maciej W. Rozycki
2002-09-04 18:16 ` Matthew Dharm
2002-09-05 9:04 ` Maciej W. Rozycki
2002-09-05 16:25 Jon Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020904093627.A5241@momenco.com \
--to=mdharm@momenco.com \
--cc=dom@algor.co.uk \
--cc=jsun@mvista.com \
--cc=linux-mips@linux-mips.org \
--cc=macro@ds2.pg.gda.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox