2GB address space limit on 32-bit PowerPC Macintosh
Kumar Gala
kumar.gala at freescale.com
Mon May 16 15:51:03 EST 2005
On May 15, 2005, at 6:34 PM, Benjamin Herrenschmidt wrote:
> 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...
Are the embedded board ports broken because of similar
io_block_mapping() calls or for some other reason?
I'm in agreement that we should bump TASK_SIZE to 3GB and fix things,
how about after 2.6.12 is out?
- kumar
More information about the Linuxppc-dev
mailing list