2GB address space limit on 32-bit PowerPC Macintosh
dan at embeddededge.com
Tue May 17 03:11:21 EST 2005
On May 16, 2005, at 12:42 PM, Benjamin Herrenschmidt wrote:
> On the other hands, how many embedded boards care about getting the
> latest "linus" tree ?
Why are you PMac guys always treating the embedded boards
as second class citizens? Don't any of you remember that all of
initial PowerPC work was done on an embedded board and the PMac
was a beneficiary of that work? :-)
Of course we care the "linus" tree is up to date. We use that
all of the time for new product development. If it wasn't for so few
of us having permission to write updates, we would probably register
many more than you do.
> ... Embedded code has been rather frozen in
> the rock, I don't think it's much to ask from the appropriate
> to have a quick look at possibly upgrading their board support as well.
It's not frozen, it's just more tedious because we are trying to find
solutions that are commonly good for everyone, not demanding
changes and forcing everyone else to adapt.
> And it isn't a difficult change for most 6xx/7xx/7xxx based boards
> anyway. What I'm worried about is that without some "pressure" (like
> breaking them), it will simply never be fixed...
Who cares? We have the ability to support the memory map flexibility
for everyone. If you need it, use it, and fix it if necessary. There
too many other things that need attention. Again, you are taking one
of the features we added for embedded boards a long time ago, and
demanding everyone support it. That's not necessary. If you want
to use this feature on a PMac, then use it, but please don't demand
everyone else do so. We didn't do that when the feature was added.
> The whole io_block_mapping() was a bad idea in the first place.
All of the ideas in 2.6 are going to look like bad ideas in the future
It's what worked and was necessary given the lack of any other
APIs at the time. We are working on removing these in the embedded
boards, and it has to be done on the PMac as well if you want to
take advantage of something other than a 2G task space.
As time permits, I will make whatever changes to the board ports
I'm aware of so they will accommodate a 3G task space, or fix up
the configuration files so the default is 2G. At some point, we can
make it the configuration default.
More information about the Linuxppc-dev