From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org, John Reiser <jreiser@BitWagon.com>
Subject: Re: 2GB address space limit on 32-bit PowerPC Macintosh
Date: Mon, 16 May 2005 09:34:29 +1000 [thread overview]
Message-ID: <1116200069.5095.51.camel@gaston> (raw)
In-Reply-To: <17031.56167.926193.391545@cargo.ozlabs.ibm.com>
On Mon, 2005-05-16 at 09:29 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > We "inherited" from some historic junk in the prep and chrp support,
> > that a lot of embedded platforms blindly copied, where archs use
> > io_block_mapping() early during boot to hard-wire various IO stuffs in
> > various places in the address space, including just after 2Gb. It's
> > totally bogus, but nobody really cared to fix it so far. The 2Gb
> > TASK_SIZE limit doesn't seem to have ever been an issue for ppc32 users
> > so far I must say, at least you are the first one to complain ;)
>
> I believe that prep and chrp are also now OK with a 3GB TASK_SIZE
> limit, it's just various embedded board ports that will blow up with
> 3GB. We should change the default to 3GB to encourage the embedded
> guys to fix their ports properly (or else to put in the appropriate
> Kconfig stuff to force it back to 2GB for their port).
>
static void __init
prep_map_io(void)
{
io_block_mapping(0x80000000, PREP_ISA_IO_BASE, 0x10000000, _PAGE_IO);
io_block_mapping(0xf0000000, PREP_ISA_MEM_BASE, 0x08000000, _PAGE_IO);
}
We need to fix that too :) Though I suppose we can just switch that to
page tables, I don't really see the point of using a BAT here...
Ben.
next prev parent reply other threads:[~2005-05-15 23:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-15 22:36 2GB address space limit on 32-bit PowerPC Macintosh John Reiser
2005-05-15 23:01 ` Benjamin Herrenschmidt
2005-05-15 23:29 ` Paul Mackerras
2005-05-15 23:34 ` Benjamin Herrenschmidt [this message]
2005-05-16 5:51 ` Kumar Gala
2005-05-16 5:52 ` Benjamin Herrenschmidt
2005-05-16 6:21 ` Kumar Gala
2005-05-16 6:22 ` Benjamin Herrenschmidt
2005-05-16 15:04 ` Dan Malek
2005-05-16 15:05 ` Benjamin Herrenschmidt
2005-05-16 15:52 ` Dan Malek
2005-05-16 16:42 ` Benjamin Herrenschmidt
2005-05-16 17:11 ` Dan Malek
2005-05-17 0:54 ` Benjamin Herrenschmidt
2005-05-16 18:00 ` Mark A. Greer
2005-05-16 18:06 ` Mark A. Greer
2005-05-16 20:31 ` Dan Malek
2005-05-16 20:43 ` Mark A. Greer
2005-05-16 21:02 ` Dan Malek
2005-05-17 3:14 ` Benjamin Herrenschmidt
2005-05-17 0:56 ` Benjamin Herrenschmidt
2005-05-16 16:11 ` Wolfgang Denk
2005-05-16 16:22 ` Eugene Surovegin
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=1116200069.5095.51.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=jreiser@BitWagon.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.