Merging ppc32 and ppc64

At OLS I discussed the idea of merging the ppc32 and ppc64
architectures in the Linux kernel with various ppc32 and ppc64 kernel
hackers and users.  There was broad agreement that this would be a
good thing to do, so we are going to go ahead and do it.

The plan is to create include/asm-powerpc and arch/powerpc directories
for the merged architecture and move stuff in there as it gets
merged.  The existing ppc32 and ppc64 directories will stay around
until they are no longer useful.  The intention is not to break
anything that currently works; however, we do not plan to move unused
and unmaintained platforms into the merged architecture.

The advantage of merging is that it will reduce the maintenance effort
and reduce the instances where a common bug gets fixed in one
architecture but not the other.  It will also make it easier to
support 64-bit embedded systems as they become more common.

I don't see the merge as changing the actual code that gets executed
on any given platform very much, except in one respect: we are going
to standardize on a flattened device tree as the way that information
about the platform gets passed from the boot loader to the kernel.

Comments? Flames? :)

Paul.

FYI.  For those not subscribed to linuxppc-dev or linuxppc64-dev.

- kumar

Begin forwarded message:

From: "Paul Mackerras" <redacted>
Date: August 2, 2005 10:07:34 PM CDT
To: <redacted>, <redacted>
Subject: Merging ppc32 and ppc64


At OLS I discussed the idea of merging the ppc32 and ppc64
architectures in the Linux kernel with various ppc32 and ppc64 kernel
hackers and users.  There was broad agreement that this would be a
good thing to do, so we are going to go ahead and do it.

The plan is to create include/asm-powerpc and arch/powerpc directories
for the merged architecture and move stuff in there as it gets
merged.  The existing ppc32 and ppc64 directories will stay around
until they are no longer useful.  The intention is not to break
anything that currently works; however, we do not plan to move unused
and unmaintained platforms into the merged architecture.

The advantage of merging is that it will reduce the maintenance effort
and reduce the instances where a common bug gets fixed in one
architecture but not the other.  It will also make it easier to
support 64-bit embedded systems as they become more common.

I don't see the merge as changing the actual code that gets executed
on any given platform very much, except in one respect: we are going
to standardize on a flattened device tree as the way that information
about the platform gets passed from the boot loader to the kernel.

Comments? Flames? :)

Paul.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

I don't see the merge as changing the actual code that gets executed
on any given platform very much, except in one respect: we are going
to standardize on a flattened device tree as the way that information
about the platform gets passed from the boot loader to the kernel.

Comments? Flames? :)

There are several userspace applications that parse the non-flat device 
tree in /proc/device-tree on pSeries.  While I like the idea of the 
flattened device tree I think we need to consider how many apps we are 
going to break with it.

Joel Schopp writes:

There are several userspace applications that parse the non-flat device 
tree in /proc/device-tree on pSeries.  While I like the idea of the 
flattened device tree I think we need to consider how many apps we are 
going to break with it.

... and standardizing on the flattened device tree will mean that
every ppc and ppc64 platform has stuff in /proc/device-tree, not just
those that have OF. :)

Paul.

quoted

I don't see the merge as changing the actual code that gets executed
on any given platform very much, except in one respect: we are going
to standardize on a flattened device tree as the way that information
about the platform gets passed from the boot loader to the kernel.
Comments? Flames? :)

There are several userspace applications that parse the non-flat 
device tree in /proc/device-tree on pSeries.  While I like the idea of 
the flattened device tree I think we need to consider how many apps we 
are going to break with it.

_Please_ don't throw the real device tree away; I'm happy with
the flattened device tree if and only if it is a _minimum_
requirement, and having a _real_ device tree (or even real
Open Firmware support) is still an option.


Segher

On Tue, 9 Aug 2005, Segher Boessenkool wrote:

quoted

quoted

I don't see the merge as changing the actual code that gets executed
on any given platform very much, except in one respect: we are going
to standardize on a flattened device tree as the way that information
about the platform gets passed from the boot loader to the kernel.

                         ^^^^^^^^^^^^^^^^^^^^^***********^^^^^^^^******^

quoted

quoted

Comments? Flames? :)

There are several userspace applications that parse the non-flat device tree
in /proc/device-tree on pSeries.  While I like the idea of the flattened
device tree I think we need to consider how many apps we are going to break
with it.

_Please_ don't throw the real device tree away; I'm happy with
the flattened device tree if and only if it is a _minimum_
requirement, and having a _real_ device tree (or even real
Open Firmware support) is still an option.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

quoted

quoted

quoted

I don't see the merge as changing the actual code that gets executed
on any given platform very much, except in one respect: we are going
to standardize on a flattened device tree as the way that 
information
about the platform gets passed from the boot loader to the kernel.

                         
^^^^^^^^^^^^^^^^^^^^^***********^^^^^^^^******^

Yes, and that is exactly what I do not want.  We are not going
to require OF implementations that do not need yaboot or similar
to pass a flattened device tree to the kernel, eh?  Also, there
is no reason why something like yaboot (with an OF still running
underneath) should have to care about anything device-tree related
at all; the OS can just as easily ask the OF itself.


Segher

On Aug 9, 2005, at 8:30 AM, Segher Boessenkool wrote:

quoted

quoted

quoted

quoted

I don't see the merge as changing the actual code that gets

executed

quoted

quoted

quoted

quoted

on any given platform very much, except in one respect: we are

going

quoted

quoted

quoted

quoted

to standardize on a flattened device tree as the way that
information
about the platform gets passed from the boot loader to the kernel.

^^^^^^^^^^^^^^^^^^^^^***********^^^^^^^^******^

Yes, and that is exactly what I do not want.  We are not going
to require OF implementations that do not need yaboot or similar
to pass a flattened device tree to the kernel, eh?  Also, there
is no reason why something like yaboot (with an OF still running
underneath) should have to care about anything device-tree related
at all; the OS can just as easily ask the OF itself.

I was under the impression that ALL platforms regardless if the had a  
OF firmware or not would be using a flattened device tree.  Any  
conversion between an OF tree to a flatten tree would end up  
happening in boot wrapper code going forward.

- kumar

On Dinsdag 09 August 2005 16:12, Kumar Gala wrote:

quoted

Yes, and that is exactly what I do not want. =A0We are not going
to require OF implementations that do not need yaboot or similar
to pass a flattened device tree to the kernel, eh? =A0Also, there
is no reason why something like yaboot (with an OF still running
underneath) should have to care about anything device-tree related
at all; the OS can just as easily ask the OF itself.

=20
I was under the impression that ALL platforms regardless if the had a =A0
OF firmware or not would be using a flattened device tree. =A0Any =A0
conversion between an OF tree to a flatten tree would end up =A0
happening in boot wrapper code going forward.

I think you are both right, just using different terminology. The=20
running kernel uses its own representation of the device tree, which
is neither the flattened stuff nor using the OF interfaces. The=20
conversion from OF to the flattened tree is done by the kernel itself.

      Apple OF  \
          SLOF   \
       pSeries    |-1- prom_init------,
          PIBS   /                     \
           ...  /                       \
                                         \
       other    -----------------------------2--unflatten_device_tree--3--
   boot loader                              /
                                           /
       iSeries  ----------- early_setup---`

All "regular" machines enter in the traditional prom_init path (1)=20
from Open Firmware. The embedded machines that are too memory constraint
to use SLOF have a flattened device tree in their boot loader and the
legacy iSeries boxes can fake the device tree in their iSeries_early_setup
function. The main entry point (2) is entered by all machines when the
flattened device tree is there and the kernel builds its tree representation
for run time (3).

	Arnd <><

I think you are both right, just using different terminology. The
running kernel uses its own representation of the device tree, which
is neither the flattened stuff nor using the OF interfaces. The
conversion from OF to the flattened tree is done by the kernel itself.

      Apple OF  \
          SLOF   \
       pSeries    |-1- prom_init------,
          PIBS   /                     \
           ...  /                       \
                                         \
       other    -----------------------------2-- 
unflatten_device_tree--3--
   boot loader                              /
                                           /
       iSeries  ----------- early_setup---`

All "regular" machines enter in the traditional prom_init path (1)
from Open Firmware. The embedded machines that are too memory  
constraint
to use SLOF have a flattened device tree in their boot loader and the
legacy iSeries boxes can fake the device tree in their  
iSeries_early_setup
function. The main entry point (2) is entered by all machines when the
flattened device tree is there and the kernel builds its tree  
representation
for run time (3).

I guess my point is that in the "new" powerpc arch doing steps 1 & 3  
should no longer be part of the kernel proper.  The should be handled  
by boot wrappers of some form.  I know Ben tool care to ensure that  
prom_init was isolated from kernel proper and I'm suggesting we move  
it into a boot wrapper going forward.

- kumar

On Tue, Aug 09, 2005 at 03:09:02PM +0200, Segher Boessenkool wrote:

_Please_ don't throw the real device tree away; I'm happy with
the flattened device tree if and only if it is a _minimum_
requirement, and having a _real_ device tree (or even real
Open Firmware support) is still an option.

We already do that. prom_init.c will walk the OF device tree and build a
flattened one before booting the kernel.


-Olof

I was under the impression that ALL platforms regardless if the had a 
OF firmware or not would be using a flattened device tree.  Any 
conversion between an OF tree to a flatten tree would end up happening 
in boot wrapper code going forward.

Ah OK -- so part of the problem is indeed terminology
confusion.  I view the "boot wrapper code" (prom_init.c)
as being part of the kernel.

Another thing is that I do not want prom_init to kill
OF at all, which means you cannot have a static device
tree.  But that is another fight ;-)


Segher

On Tue, Aug 09, 2005 at 10:01:05AM -0500, Kumar Gala wrote:

quoted

I think you are both right, just using different terminology. The
running kernel uses its own representation of the device tree, which
is neither the flattened stuff nor using the OF interfaces. The
conversion from OF to the flattened tree is done by the kernel itself.

     Apple OF  \
         SLOF   \
      pSeries    |-1- prom_init------,
         PIBS   /                     \
          ...  /                       \
                                        \
      other    -----------------------------2-- 
unflatten_device_tree--3--
  boot loader                              /
                                          /
      iSeries  ----------- early_setup---`

All "regular" machines enter in the traditional prom_init path (1)
from Open Firmware. The embedded machines that are too memory  
constraint
to use SLOF have a flattened device tree in their boot loader and the
legacy iSeries boxes can fake the device tree in their  
iSeries_early_setup
function. The main entry point (2) is entered by all machines when the
flattened device tree is there and the kernel builds its tree  
representation
for run time (3).

I guess my point is that in the "new" powerpc arch doing steps 1 & 3  
should no longer be part of the kernel proper.  The should be handled  
by boot wrappers of some form.  I know Ben tool care to ensure that  
prom_init was isolated from kernel proper and I'm suggesting we move  
it into a boot wrapper going forward.

That's not 100% true because as Segher said, prom_init.c is part of the
kernel (tree, image), but is what does the translation.

-- 
Tom Rini
http://gate.crashing.org/~trini/

On Aug 9, 2005, at 11:21 AM, Tom Rini wrote:

On Tue, Aug 09, 2005 at 10:01:05AM -0500, Kumar Gala wrote:

quoted

quoted

I think you are both right, just using different terminology. The
running kernel uses its own representation of the device tree, which
is neither the flattened stuff nor using the OF interfaces. The
conversion from OF to the flattened tree is done by the kernel

itself.

quoted

quoted

     Apple OF  \
         SLOF   \
      pSeries    |-1- prom_init------,
         PIBS   /                     \
          ...  /                       \
                                        \
      other    -----------------------------2--
unflatten_device_tree--3--
  boot loader                              /
                                          /
      iSeries  ----------- early_setup---`

All "regular" machines enter in the traditional prom_init path (1)
from Open Firmware. The embedded machines that are too memory
constraint
to use SLOF have a flattened device tree in their boot loader and  
the
legacy iSeries boxes can fake the device tree in their
iSeries_early_setup
function. The main entry point (2) is entered by all machines when

the

quoted

quoted

flattened device tree is there and the kernel builds its tree
representation
for run time (3).

I guess my point is that in the "new" powerpc arch doing steps 1 & 3
should no longer be part of the kernel proper.  The should be handled

quoted

by boot wrappers of some form.  I know Ben tool care to ensure that
prom_init was isolated from kernel proper and I'm suggesting we move
it into a boot wrapper going forward.

That's not 100% true because as Segher said, prom_init.c is part of  
the
kernel (tree, image), but is what does the translation.

I'm not sure I follow.  I understand that prom_init.c is part of the  
kernel in ppc64.  I'm saying that such things should NOT be part of  
the arch/powerpc kernel going forward.  They should be handled via  
bootwrappers.

- kumar

On Tue, Aug 09, 2005 at 12:41:54PM -0500, Kumar Gala wrote:

On Aug 9, 2005, at 11:21 AM, Tom Rini wrote:

[snip]

quoted

That's not 100% true because as Segher said, prom_init.c is part of  
the
kernel (tree, image), but is what does the translation.

I'm not sure I follow.  I understand that prom_init.c is part of the  
kernel in ppc64.  I'm saying that such things should NOT be part of  
the arch/powerpc kernel going forward.  They should be handled via  
bootwrappers.

That's a "cleanup" we can argue about later, but I expect some
resistance :)

-- 
Tom Rini
http://gate.crashing.org/~trini/

On Aug 9, 2005, at 12:47 PM, Tom Rini wrote:

On Tue, Aug 09, 2005 at 12:41:54PM -0500, Kumar Gala wrote:

quoted

On Aug 9, 2005, at 11:21 AM, Tom Rini wrote:

[snip]

quoted

quoted

That's not 100% true because as Segher said, prom_init.c is part of
the
kernel (tree, image), but is what does the translation.

I'm not sure I follow.  I understand that prom_init.c is part of the
kernel in ppc64.  I'm saying that such things should NOT be part of
the arch/powerpc kernel going forward.  They should be handled via
bootwrappers.

That's a "cleanup" we can argue about later, but I expect some
resistance :)

Why argue later?  Isn't part of the point of the merge to do cleanup  
between ppc32 & ppc64.  When would be the point to discuss this?

- kumar

Segher Boessenkool writes:

_Please_ don't throw the real device tree away; I'm happy with
the flattened device tree if and only if it is a _minimum_
requirement, and having a _real_ device tree (or even real
Open Firmware support) is still an option.

Aarrgh! <sound of paulus tearing hair out>

There seems to be a lot of misunderstanding about the flattened device
tree concept.  The flattened device tree is simply a representation of
a device tree (i.e., the full, or "real" (whatever that means) device
tree) that does not contain any pointers and is in a single contiguous
block of memory.

On systems with open firmware, the boot is separated into two phases.
In the first phase, OF is still active.  The kernel is not based at
physical address 0, and can do OF client calls.  In the second phase,
the kernel is based at physical address 0 and OF's memory has been
reclaimed by the kernel.  The flattened device tree is the main data
structure that is passed from the first phase to the second.  One of
the first things that the second phase does is to expand the flattened
device tree into the normal in-kernel device tree representation (a
tree of struct device_node).

Having the flattened device tree doesn't mean that we will be using
the device tree less, it means we will be using it _more_.

Paul.

Segher Boessenkool writes:

Yes, and that is exactly what I do not want.  We are not going
to require OF implementations that do not need yaboot or similar
to pass a flattened device tree to the kernel, eh?  Also, there
is no reason why something like yaboot (with an OF still running
underneath) should have to care about anything device-tree related
at all; the OS can just as easily ask the OF itself.

For now the kernel will cope with either having an OF client interface
entry point or a flattened device tree passed to it.  In the future we
intend to move all the OF client calls into the zImage wrapper and
have the zImage wrapper pass the flattened device tree to the kernel
proper.  That will be much cleaner because we will be able to get rid
of all of the dodgy RELOC stuff in prom_init.c.

It is already the case (and has always been the case) that you can't
boot a vmlinux image directly from OF - there is always either or both
of yaboot or a zImage wrapper in between anyway.

Paul.

On Aug 9, 2005, at 5:55 PM, Paul Mackerras wrote:

Segher Boessenkool writes:

quoted

Yes, and that is exactly what I do not want.  We are not going
to require OF implementations that do not need yaboot or similar
to pass a flattened device tree to the kernel, eh?  Also, there
is no reason why something like yaboot (with an OF still running
underneath) should have to care about anything device-tree related
at all; the OS can just as easily ask the OF itself.

For now the kernel will cope with either having an OF client interface
entry point or a flattened device tree passed to it.  In the future we
intend to move all the OF client calls into the zImage wrapper and
have the zImage wrapper pass the flattened device tree to the kernel
proper.  That will be much cleaner because we will be able to get rid
of all of the dodgy RELOC stuff in prom_init.c.

Can you clarify when the "future" is.  I'd like to see this change  
happen as part of the arch/powerpc work.

- kumar

It is already the case (and has always been the case) that you can't
boot a vmlinux image directly from OF - there is always either or both
of yaboot or a zImage wrapper in between anyway.

If you fix the ELF headers, you can boot a vmlinux directly
from OF just fine.

I agree getting rid of all that RELOC() stuff is a worthy goal;
I just hope there's a better way to do it...

Anyway, I'm not going to stand in you guys way -- please
just don't make it harder for me without reason, though.


Segher

Having the flattened device tree doesn't mean that we will be using
the device tree less, it means we will be using it _more_.

The reason Segher is freaking out is because he wants to keep OF alive
in the future while the kernel is running.... (at least with SLOF)

I think that would require a different entry point with no flattened
tree, and changing of all the OF accessors to call OF instead of walking
an in-kernel tree. That is far from our current target though.

Ben.