Merging ppc32 and ppc64

Merging ppc32 and ppc64

[Paul Mackerras]

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.

Fwd: Merging ppc32 and ppc64

[Kumar Gala]

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

- kumar

Begin forwarded message:

> From: "Paul Mackerras" <paulus@samba.org>
> Date: August 2, 2005 10:07:34 PM CDT
> To: <linuxppc-dev@ozlabs.org>, <linuxppc64-dev@ozlabs.org>
> 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
>

RE: Merging ppc32 and ppc64

[Goodman, Brad]

[-- Attachment #1: Type: text/plain, Size: 126 bytes --]

As long as you keep the "legacy" directories around for a while - I'm happy.

Thanks,

-BKG
bgoodman et empirix und com

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2300 bytes --]

Re: Merging ppc32 and ppc64

[Joel Schopp]

> 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.

Re: Merging ppc32 and ppc64

[Paul Mackerras]

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.

Re: Merging ppc32 and ppc64

[Segher Boessenkool]

>> 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

Re: Merging ppc32 and ppc64

[Geert Uytterhoeven]

On Tue, 9 Aug 2005, Segher Boessenkool wrote:
> > > 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.
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

Re: Merging ppc32 and ppc64

[Segher Boessenkool]

>>>> 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

Re: Merging ppc32 and ppc64

[Kumar Gala]

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

>>>>> 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.

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

Re: Merging ppc32 and ppc64

[Arnd Bergmann]

On Dinsdag 09 August 2005 16:12, Kumar Gala wrote:
> > 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 <><

Re: Merging ppc32 and ppc64

[Olof Johansson]

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

Re: Merging ppc32 and ppc64

[Kumar Gala]

> 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

Re: Merging ppc32 and ppc64

[Segher Boessenkool]

> 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

Re: Merging ppc32 and ppc64

[Tom Rini]

On Tue, Aug 09, 2005 at 10:01:05AM -0500, Kumar Gala wrote:
> >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/

Re: Merging ppc32 and ppc64

[Kumar Gala]

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

> On Tue, Aug 09, 2005 at 10:01:05AM -0500, Kumar Gala wrote:
>
>>> 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.

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

Re: Merging ppc32 and ppc64

[Tom Rini]

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]
> >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/

Re: Merging ppc32 and ppc64

[Kumar Gala]

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

> 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]
>
>>> 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

Re: Merging ppc32 and ppc64

[Paul Mackerras]

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.

Re: Merging ppc32 and ppc64

[Paul Mackerras]

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.

Re: Merging ppc32 and ppc64

[Kumar Gala]

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

> 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.

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

- kumar

Re: Merging ppc32 and ppc64

[Segher Boessenkool]

> 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

Re: Merging ppc32 and ppc64

[Benjamin Herrenschmidt]

> 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.