Starting the arch/powerpc merge

I have pushed a commit to the powerpc-merge.git tree which gets us far
enough to be able to build a 32-bit powermac kernel with
ARCH=powerpc.  It's still very rough in places, and it uses bits out
of arch/ppc/kernel and arch/ppc/syslib, but it is a start.

Of course, this means that we are about to bump up against the really
hard bits of the merge.  Things like

* converting ppc32 to use the lmb infrastructure
* introducing the device-tree flattening/unflattening to ppc32
* working out how to deal with the early hash table initialization
  that POWER4 needs on ppc32
* reconciling the fact that ppc64 needs RELOC in the prom_init code,
  whereas ppc32 doesn't; but ppc64 doesn't need RELOC when running
  with the MMU off but ppc32 does (or needs -mrelocatable).

I look forward to people sending me patches to push this on a bit
further, and in particular to populate arch/powerpc/platforms a bit
more. :)

Paul.

On Sep 26, 2005, at 7:25 PM, Paul Mackerras wrote:

I have pushed a commit to the powerpc-merge.git tree which gets us far
enough to be able to build a 32-bit powermac kernel with
ARCH=powerpc.  It's still very rough in places, and it uses bits out
of arch/ppc/kernel and arch/ppc/syslib, but it is a start.

Of course, this means that we are about to bump up against the really
hard bits of the merge.  Things like

* converting ppc32 to use the lmb infrastructure
* introducing the device-tree flattening/unflattening to ppc32
* working out how to deal with the early hash table initialization
  that POWER4 needs on ppc32
* reconciling the fact that ppc64 needs RELOC in the prom_init code,
  whereas ppc32 doesn't; but ppc64 doesn't need RELOC when running
  with the MMU off but ppc32 does (or needs -mrelocatable).

I look forward to people sending me patches to push this on a bit
further, and in particular to populate arch/powerpc/platforms a bit
more. :)

You have duplicated files between arch/ppc/ and arch/powerpc.  Do you  
plan on cleaning this up are should we make sure we "fix" both?

- kumar

On Mon, 26 Sep 2005 22:39:56 -0500 Kumar Gala [off-list ref] wrote:

You have duplicated files between arch/ppc/ and arch/powerpc.  Do you  
plan on cleaning this up are should we make sure we "fix" both?

I have done a patch that fixed most of those (but not all).  It will be in the
merge tree when Paulus next pushes it out.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

On Tue, Sep 27, 2005 at 10:25:38AM +1000, Paul Mackerras wrote:

* working out how to deal with the early hash table initialization
  that POWER4 needs on ppc32

What about just dropping POWER3/4 support in 32bit mode?

Christoph Hellwig writes:

What about just dropping POWER3/4 support in 32bit mode?

Yes... I'm getting very close to deciding to do that.  In fact POWER3
isn't too bad, since it still has BATs, but POWER4/PPC970 would be
tricky.

Does anyone on these lists have any major objections if we drop
support for 32-bit kernels on POWER3 and POWER4/PPC970?

Paul.

Paul Mackerras kirjoitti:

Christoph Hellwig writes:

quoted

What about just dropping POWER3/4 support in 32bit mode?

Yes... I'm getting very close to deciding to do that.  In fact POWER3
isn't too bad, since it still has BATs, but POWER4/PPC970 would be
tricky.

Does anyone on these lists have any major objections if we drop
support for 32-bit kernels on POWER3 and POWER4/PPC970?

I think it was Kumar Gala who already asked this a while ago. For me, 
32-bit kernel on a 970 has been useful "initial stage" of gradually 
porting kernel stuff over to real 64-bit, but if I'm the only user and 
keeping the support is a nuisance, go ahead and drop it.

-- Heikki Lindholm

Heikki Lindholm wrote:

Paul Mackerras kirjoitti:

quoted

Christoph Hellwig writes:

quoted

What about just dropping POWER3/4 support in 32bit mode?

Yes... I'm getting very close to deciding to do that.  In fact POWER3
isn't too bad, since it still has BATs, but POWER4/PPC970 would be
tricky.

Does anyone on these lists have any major objections if we drop
support for 32-bit kernels on POWER3 and POWER4/PPC970?

I think it was Kumar Gala who already asked this a while ago. For me, 
32-bit kernel on a 970 has been useful "initial stage" of gradually 
porting kernel stuff over to real 64-bit, but if I'm the only user and 
keeping the support is a nuisance, go ahead and drop it.

-- Heikki Lindholm

Count me in too; using a 970 in 32 bit mode, because of gentoo X.org
problems in 64 bit mode.

Regards

Pantelis

Paul Mackerras wrote:

Pantelis Antoniou writes:

quoted

Count me in too; using a 970 in 32 bit mode, because of gentoo X.org
problems in 64 bit mode.

I'm using an X.org server on a ppc64 kernel, and it all works,
including DRI.  Both 32-bit and 64-bit X server and clients work.  We
now have the 32-bit ioctl compatibility sorted out in the kernel DRM.
So I don't think X is a reason to run a 32-bit kernel any more.

What X.org problems do you see with a 64-bit kernel?

Paul.

I didn't really tried a very recent kernel, I tried it about a month ago,
and it didn't work. Could be a gentoo problem for all I know.

Since I don't have time to debug these kind of problems, it's really nice
to know that it now works :).

No worries then.

Regards

Pantelis

Pantelis Antoniou writes:

Count me in too; using a 970 in 32 bit mode, because of gentoo X.org
problems in 64 bit mode.

I'm using an X.org server on a ppc64 kernel, and it all works,
including DRI.  Both 32-bit and 64-bit X server and clients work.  We
now have the 32-bit ioctl compatibility sorted out in the kernel DRM.
So I don't think X is a reason to run a 32-bit kernel any more.

What X.org problems do you see with a 64-bit kernel?

Paul.

Kumar Gala writes:

You have duplicated files between arch/ppc/ and arch/powerpc.  Do you  
plan on cleaning this up are should we make sure we "fix" both?

I did that deliberately so that I could hack the merged version
without worrying about whether I would break the compile with ARCH=ppc
or ARCH=ppc64.  If it turns out that the merged version of some file
is sufficiently similar to the ppc version, we can then delete the ppc
version and just use the merged version.

Paul.

On Tue, 2005-09-27 at 18:30 +1000, Paul Mackerras wrote:

Christoph Hellwig writes:

quoted

What about just dropping POWER3/4 support in 32bit mode?

Yes... I'm getting very close to deciding to do that.  In fact POWER3
isn't too bad, since it still has BATs, but POWER4/PPC970 would be
tricky.

Does anyone on these lists have any major objections if we drop
support for 32-bit kernels on POWER3 and POWER4/PPC970?

I've stopped supporting G5 on 32 bits kernel for some time now, I have
absolutely no problem just dropping the POWER4 support in 32 bits kernel
in the merged tree.

Ben.

On 28-Sep-2005 Benjamin Herrenschmidt wrote:

On Tue, 2005-09-27 at 18:30 +1000, Paul Mackerras wrote:

quoted

Christoph Hellwig writes:

quoted

What about just dropping POWER3/4 support in 32bit mode?

Yes... I'm getting very close to deciding to do that.  In fact POWER3
isn't too bad, since it still has BATs, but POWER4/PPC970 would be
tricky.

Does anyone on these lists have any major objections if we drop
support for 32-bit kernels on POWER3 and POWER4/PPC970?

I've stopped supporting G5 on 32 bits kernel for some time now, I have
absolutely no problem just dropping the POWER4 support in 32 bits kernel
in the merged tree.

Out of curiosity, is there any advantage in using a 32 bits
kernel on ppc64 over a 64 bits kernel ?  Speed ?  Complexity ?
Compatibility ?  Memory ?



--
Giuliano.

Giuliano Pochini writes:

Out of curiosity, is there any advantage in using a 32 bits
kernel on ppc64 over a 64 bits kernel ?  Speed ?  Complexity ?
Compatibility ?  Memory ?

Not really.  The main thing in the past has been that DRI with 32-bit
X server and clients would work with a 32-bit kernel but not a 64-bit
kernel, but that's fixed now.  A 64-bit kernel is faster on most
lmbench tests.  I guess a 32-bit kernel might end up a little smaller,
but that's the only possible advantage I can think of.

Paul.

I wrote:

Not really.  The main thing in the past has been that DRI with 32-bit
X server and clients would work with a 32-bit kernel but not a 64-bit
kernel, but that's fixed now.  A 64-bit kernel is faster on most
lmbench tests.  I guess a 32-bit kernel might end up a little smaller,
but that's the only possible advantage I can think of.

Oops, sorry, mail system breakage here...

Paul.

On 06-Oct-2005 Paul Mackerras wrote:

quoted

Out of curiosity, is there any advantage in using a 32 bits
kernel on ppc64 over a 64 bits kernel ?  Speed ?  Complexity ?
Compatibility ?  Memory ?

Not really.  The main thing in the past has been that DRI with 32-bit
X server and clients would work with a 32-bit kernel but not a 64-bit
kernel, but that's fixed now.  A 64-bit kernel is faster on most
lmbench tests.  I guess a 32-bit kernel might end up a little smaller,
but that's the only possible advantage I can think of.

And 32<->64 bits compatibility layer for 32bits apps is not needed,
so maybe they run a bit faster. Well, at this point IMHO 32-on-64
support may be dropped without regrets. Spending time for an useless
thing is - uhm - useless.

Oops, sorry, mail system breakage here...

My mail wasn't important anyway :))


--
Giuliano.