From: "Bradley D. LaRonde" <brad@ltc.com>
To: <sjhill@cotw.com>
Cc: "linux-mips" <linux-mips@oss.sgi.com>
Subject: Re: What is the maximum physical RAM for a 32bit MIPS core?
Date: Tue, 5 Feb 2002 16:58:26 -0500 [thread overview]
Message-ID: <02a001c1ae90$43748d40$5601010a@prefect> (raw)
In-Reply-To: 3C604D73.88F1CDCE@cotw.com
----- Original Message -----
From: "Steven J. Hill" <sjhill@cotw.com>
To: "Pete Popov" <ppopov@pacbell.net>
Cc: "Hartvig Ekner" <hartvige@mips.com>; "linux-mips"
<linux-mips@oss.sgi.com>
Sent: Tuesday, February 05, 2002 4:24 PM
Subject: Re: What is the maximum physical RAM for a 32bit MIPS core?
> Pete Popov wrote:
> >
> > I'm not sure if it's a "little" though. Ralf has already done the work
> > for 64bit memory support on 32bit kernels, but that only works currently
> > on 64bit CPUs. I started hacking on the 64bit memory patch to get it to
> > work on 32bit processors, but had to put that aside for a few weeks. I
> > hope to get back to it soon.
> >
> Sure, the "little" is a relative term. As far as your patch is concerned,
> you are essentially trying to use a true 32-bit processor (my definition
> being that it is not a 64-bit processor running in 32-bit mode), to
address
> address more than 4GB of physical memory. I don't see how that is possible
> with just the MMU and TLB unless you are using chip selects and customm
> logic.
As already mentioned, a MIPS TLB entry typically can point with 36 bits
(that's 67TB of address space?) at physical memory. If you have more than
2^31 bytes of physical memory, then a single process can't map all of
physical memory into it's address space, but it can map in pages (using TLB
entries) from anywhere within the 36-bit physical memory space.
In other words, process address space doesn't limit physical address space.
Only TLB capability limits physical address space.
And right, KSEG0 and KSEG1 can only get at the low 0.5GB of physical memory.
You can imagine that KSEG0 is implemented with a single hardwired TLB entry
that maps virtual address 0x80000000 to physical address 0x0, 0.5GB wide.
The only way to get to physical memory above 0.5GB is through a TLB entry.
Regards,
Brad
WARNING: multiple messages have this Message-ID (diff)
From: "Bradley D. LaRonde" <brad@ltc.com>
To: sjhill@cotw.com
Cc: linux-mips <linux-mips@oss.sgi.com>
Subject: Re: What is the maximum physical RAM for a 32bit MIPS core?
Date: Tue, 5 Feb 2002 16:58:26 -0500 [thread overview]
Message-ID: <02a001c1ae90$43748d40$5601010a@prefect> (raw)
Message-ID: <20020205215826.94e1CW6V-484nJPeX0rTsdy_GwHeNZsg1iO7O5V4Qv8@z> (raw)
In-Reply-To: 3C604D73.88F1CDCE@cotw.com
----- Original Message -----
From: "Steven J. Hill" <sjhill@cotw.com>
To: "Pete Popov" <ppopov@pacbell.net>
Cc: "Hartvig Ekner" <hartvige@mips.com>; "linux-mips"
<linux-mips@oss.sgi.com>
Sent: Tuesday, February 05, 2002 4:24 PM
Subject: Re: What is the maximum physical RAM for a 32bit MIPS core?
> Pete Popov wrote:
> >
> > I'm not sure if it's a "little" though. Ralf has already done the work
> > for 64bit memory support on 32bit kernels, but that only works currently
> > on 64bit CPUs. I started hacking on the 64bit memory patch to get it to
> > work on 32bit processors, but had to put that aside for a few weeks. I
> > hope to get back to it soon.
> >
> Sure, the "little" is a relative term. As far as your patch is concerned,
> you are essentially trying to use a true 32-bit processor (my definition
> being that it is not a 64-bit processor running in 32-bit mode), to
address
> address more than 4GB of physical memory. I don't see how that is possible
> with just the MMU and TLB unless you are using chip selects and customm
> logic.
As already mentioned, a MIPS TLB entry typically can point with 36 bits
(that's 67TB of address space?) at physical memory. If you have more than
2^31 bytes of physical memory, then a single process can't map all of
physical memory into it's address space, but it can map in pages (using TLB
entries) from anywhere within the 36-bit physical memory space.
In other words, process address space doesn't limit physical address space.
Only TLB capability limits physical address space.
And right, KSEG0 and KSEG1 can only get at the low 0.5GB of physical memory.
You can imagine that KSEG0 is implemented with a single hardwired TLB entry
that maps virtual address 0x80000000 to physical address 0x0, 0.5GB wide.
The only way to get to physical memory above 0.5GB is through a TLB entry.
Regards,
Brad
next prev parent reply other threads:[~2002-02-05 21:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-05 16:50 What is the maximum physical RAM for a 32bit MIPS core? Steven J. Hill
2002-02-05 17:47 ` Hartvig Ekner
2002-02-05 20:46 ` Steven J. Hill
2002-02-05 20:53 ` Hartvig Ekner
2002-02-05 20:53 ` Hartvig Ekner
2002-02-05 21:15 ` Pete Popov
2002-02-05 21:24 ` Steven J. Hill
2002-02-05 21:44 ` Pete Popov
2002-02-05 21:58 ` Bradley D. LaRonde [this message]
2002-02-05 21:58 ` Bradley D. LaRonde
2002-02-06 8:49 ` Geert Uytterhoeven
2002-02-06 11:16 ` nick
2002-02-06 12:07 ` Geert Uytterhoeven
2002-02-06 14:14 ` Bradley D. LaRonde
2002-02-06 14:14 ` Bradley D. LaRonde
2002-02-06 5:29 ` Ralf Baechle
2002-02-06 2:33 ` Ralf Baechle
2002-02-06 13:17 ` William Lee Irwin III
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='02a001c1ae90$43748d40$5601010a@prefect' \
--to=brad@ltc.com \
--cc=linux-mips@oss.sgi.com \
--cc=sjhill@cotw.com \
/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