Re: 2GB address space limit on 32-bit PowerPC Macintosh

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Mon, 2005-05-16 at 16:31 -0400, Dan Malek wrote:
> On May 16, 2005, at 2:06 PM, Mark A. Greer wrote:
> 
> > Oops...
> > /me unintentionally stepped into the middle of a flame war  :)
> 
> Just pee on it :-)
> 
> > To be clear, "offender" == board that has an io_block_mapping below 
> > the 3 GB line.
> 
> That is one of the obvious changes. You are likely to find some other 
> assumptions
> that may need attention.  The problem with io_block_mapping is you just 
> can't
> remove it, you have to fix up all of the code that is based on the 
> assumption these
> spaces are mapped.  You are likely to find yourself in a situation 
> where you need
> access to some board control registers before VM is set up and you can 
> call
> ioremap().  So, you will find yourself doing some hack in head.S to map 
> BAT
> registers to get access to this, which is exactly what 
> io_block_mapping() does,
> only in a way that is obvious :-)

Well, I agree that way we currently do it has this issue, but I think
this is because we did it wrong in the first place. We really shouldn't
need to do anything before ioremap can be used. And if we need an early
ioremap, we could implement bolted hash entries like we do on ppc64 :)
However, don't get wrong here, I'm not 100% opposed to the use of BATs
for early mappings, I just think that the whole hard-coding of the
virtual address is a bad idea, and that we shouldn't have allowed them
to be below KERNELBASE. The BAT could still have been "dynamically"
positioned using the ioremap_bot mecanism with appropriate alignment, or
at worse, we could have kept the current mecanism, but just not let it
work below KERNELBASE.

Ben.