Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Wolfgang Denk]

Dear Ben,

in message <1116478614.918.75.camel@gaston> you wrote:
> 
> And here is a second draft with more infos.
> 
>            Booting the Linux/ppc64 kernel without Open Firmware

Thanks a lot for taking the initiative to come to an agreement  about
the kernel boot interface.

I have some concerns about the memory foot print and  increased  boot
time  that  will  result  from  the proposed solution. There are many
embedded systems where resources are tight and requirements are  aven
tighter.  It  would  be probably a good idea to also ask for feedback
from these folks - for example by posting your RFC on the celinux-dev
mailing list.

But my biggest concern is that we  should  try  to  come  up  with  a
solution  that  has  a  wider  acceptance. Especially from the U-Boot
point of view it is not exactly nice that each of  PowerPC,  ARM  and
MIPS  use  their very own, completely incompatible way of passing in-
formation from the boot loader to the kernel.

As is, your proposal will add just another incompatible way of  doing
the  same  thing  (of course we will have to stay backward compatible
with U-Boot to allow booting older kernels, too).


Why don't we try to come up with a solution that is acceptable to the
other architectures as well? 

Maybe you want  to  post  the  RFC  to  lkml,  or  at  least  to  the
linux-arm-kernel and linux-mips mailing lists?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Real computer scientists don't comment their  code.  The  identifiers
are so long they can't afford the disk space.

Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Pantelis Antoniou]

Wolfgang Denk wrote:
> Dear Ben,
> 
> in message <1116478614.918.75.camel@gaston> you wrote:
> 
>>And here is a second draft with more infos.
>>
>>           Booting the Linux/ppc64 kernel without Open Firmware
> 
> 
> Thanks a lot for taking the initiative to come to an agreement  about
> the kernel boot interface.
> 
> I have some concerns about the memory foot print and  increased  boot
> time  that  will  result  from  the proposed solution. There are many
> embedded systems where resources are tight and requirements are  aven
> tighter.  It  would  be probably a good idea to also ask for feedback
> from these folks - for example by posting your RFC on the celinux-dev
> mailing list.
> 
> But my biggest concern is that we  should  try  to  come  up  with  a
> solution  that  has  a  wider  acceptance. Especially from the U-Boot
> point of view it is not exactly nice that each of  PowerPC,  ARM  and
> MIPS  use  their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.
> 
> As is, your proposal will add just another incompatible way of  doing
> the  same  thing  (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).
> 
> 
> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well? 
> 
> Maybe you want  to  post  the  RFC  to  lkml,  or  at  least  to  the
> linux-arm-kernel and linux-mips mailing lists?
> 

I'm really interested in having this discussion.

I'm forced to maintain my own u-boot based solution for doing this and
I'd be very interested in whatever gets chosen.

IMHO the current mess is considerable, and at this point I wouldn't
really care if the resulting solution is less than optimal, as long
as there is one.

> Best regards,
> 
> Wolfgang Denk
> 

Regards

Pantelis

Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Benjamin Herrenschmidt]

On Thu, 2005-05-19 at 15:18 +0200, Wolfgang Denk wrote:
> Dear Ben,
> 
> in message <1116478614.918.75.camel@gaston> you wrote:
> > 
> > And here is a second draft with more infos.
> > 
> >            Booting the Linux/ppc64 kernel without Open Firmware
> 
> Thanks a lot for taking the initiative to come to an agreement  about
> the kernel boot interface.
> 
> I have some concerns about the memory foot print and  increased  boot
> time  that  will  result  from  the proposed solution. 

Like everybody it seems, which is funny in a way as I expect pretty much
none (or a few Kb maybe). The kernel side code for managing a
device-tree may represent more, but heh, have you seen the size of a
ppc64 kernel anyways ? I don't think that is very relevant. On the
bootloader side, I don't expect any significant impact. The device-tree
can be very small, and the code required on the bootloader side ranges
from nothing for a pre-built one, to a little bit if the bootloader has
to be able to change/add properties/nodes.

> There are many embedded systems where resources are tight and requirements
> are  aven tighter.  

Amen. (Though heh, this is ppc64, you can't be _that_ tight :)

>It  would  be probably a good idea to also ask for feedback
> from these folks - for example by posting your RFC on the celinux-dev
> mailing list.

I will do when I have a little bit more mature proposal.

> But my biggest concern is that we  should  try  to  come  up  with  a
> solution  that  has  a  wider  acceptance.

No other solution will be accepted on the kernel side. At least for
ppc64

> Especially from the U-Boot
> point of view it is not exactly nice that each of  PowerPC,  ARM  and
> MIPS  use  their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.

True.

> As is, your proposal will add just another incompatible way of  doing
> the  same  thing  (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).

My proposal is the only supported way to boot a ppc64 kernel. There are
talks about backporting support for that to ppc32 as well. Other
architectures are welcome to use it too though :) The device-tree in the
kernel is fully expanded into a tree structure on ppc, since it's
heavily used by various pieces of code all over the place, but for other
architectures that would like to use that, it's possible to limit
themselves to the flattened format. The ppc64 kernel contains some code
to access nodes & properties directly from the flattened format (used
early during boot) which represents very little code.

> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well? 

This has been discussed over and over again, that is the best way to
never come up with a solution as everybody will want something different
and nobody will ever agree.

The present proposal is implemented today on the ppc64 kernel already,
and we have decided to not go backward on this requirement. 

> Maybe you want  to  post  the  RFC  to  lkml,  or  at  least  to  the
> linux-arm-kernel and linux-mips mailing lists?
> 
> Best regards,
> 
> Wolfgang Denk
> 

Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Wolfgang Denk]

Dear Ben,

in message <1116541230.5153.8.camel@gaston> you wrote:
>
> > I have some concerns about the memory foot print and  increased  boot
> > time  that  will  result  from  the proposed solution. 
> 
> Like everybody it seems, which is funny in a way as I expect pretty much
> none (or a few Kb maybe). The kernel side code for managing a
> device-tree may represent more, but heh, have you seen the size of a

I am not so narrow-minded to think only about U-Boot. I try to  think
about  the  whole system, including boot loader, kernel, and any data
that might need to get passed between these two.

And please believe me, there are many, many systems out  there  where
"a few Kb" really matter.

> ppc64 kernel anyways ? I don't think that is very relevant. On the

I am aware that you think so, and I try to raise  your  awareness  of
the fact that there is a huge number of small machines out there.

Please keep in mind that the same interface will be forced sooner  or
later  on small 8xx systems with maybe just 4 MB flash and 8 or 16 MB
RAM.

And when you sell 100,000 of these units per year then "a few Kb" may
cost a lot of money. Or may cause that other, prorietary OS get used.

> bootloader side, I don't expect any significant impact. The device-tree
> can be very small, and the code required on the bootloader side ranges
> from nothing for a pre-built one, to a little bit if the bootloader has
> to be able to change/add properties/nodes.

It is IMHO wrong to have only the boot loader side in mind. We should
consider the whole system.

> > There are many embedded systems where resources are tight and requirements
> > are  aven tighter.  
> 
> Amen. (Though heh, this is ppc64, you can't be _that_ tight :)

I think you are aware that there are several people out there working
on a similar boot interface for the "small" PPC systems, too.


> >It  would  be probably a good idea to also ask for feedback
> > from these folks - for example by posting your RFC on the celinux-dev
> > mailing list.
> 
> I will do when I have a little bit more mature proposal.

Thanks in advance.


> > But my biggest concern is that we  should  try  to  come  up  with  a
> > solution  that  has  a  wider  acceptance.
> 
> No other solution will be accepted on the kernel side. At least for
> ppc64

This is not exactly a constructive position. When  each  architecture
comes  up with it's own solution for the same problem and then claims
that no other solution will be accepted we will stick  with  what  we
have now: a mess.

If this is really your position we may as well stop here.

> > As is, your proposal will add just another incompatible way of  doing
> > the  same  thing  (of course we will have to stay backward compatible
> > with U-Boot to allow booting older kernels, too).
> 
> My proposal is the only supported way to boot a ppc64 kernel. There are

Yes, of course. And using ATAGS is the only supported way to boot  an
ARM kernel, and so on.

If everybody claims that his way of doing things is the only accepted
solution we can really save all the time we are  wasting  on  such  a
discussion.


> talks about backporting support for that to ppc32 as well. Other
> architectures are welcome to use it too though :) The device-tree in the

Ummm.. Ben, I have really high respect for you, but such  a  position
is  simply  arrogant.  With the same right the ARM folks can say that
ATAGS is the way to go and other architectures are welcome to use it.
Actually they might have older rights.

> > Why don't we try to come up with a solution that is acceptable to the
> > other architectures as well? 
> 
> This has been discussed over and over again, that is the best way to
> never come up with a solution as everybody will want something different
> and nobody will ever agree.

With such a position I really wonder why you ever asked?

> The present proposal is implemented today on the ppc64 kernel already,
> and we have decided to not go backward on this requirement. 

The why the heck do you call this a RFC or a proposal? To me it seems
that you don't propose but dictate a  solution  -  a  solution  which
pretty   much  ignores  everything  but  your  own  requirements.  If
everything has been decided already I can as well shut up.

But please never claim that this has been _discusssed_.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I have made mistakes, but have never made the mistake of  claiming  I
never made one.                                     - James G. Bennet

Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Benjamin Herrenschmidt]

> I am aware that you think so, and I try to raise  your  awareness  of
> the fact that there is a huge number of small machines out there.
> 
> Please keep in mind that the same interface will be forced sooner  or
> later  on small 8xx systems with maybe just 4 MB flash and 8 or 16 MB
> RAM.

I will not force it, but others may find it a good idea to do so :)

> It is IMHO wrong to have only the boot loader side in mind. We should
> consider the whole system.

I do have the kernel in mind as well. The fact is the ppc64 kernel
relies on an Open Firmware device tree and we do not want at any cost to
get into the mess that is ppc32. We decided to define this flattened
format for that purpose, and to allow kexec functionality. I did my best
to keep the format as compact as possible (maybe a little bit more could
be saved by changing the way the full path are layed out, maybe we could
even do a new version which gzip's the while blob, but overall, it's
fairly small).

On the kernel side, as I wrote as well, the code for dealing with the
device-tree isn't that big, and will get smaller as I remove the
post-processing of nodes in prom.c that we still have here. And as I
wrote, if other platforms want to re-use that mecanism, they may want to
just use the compact/flattened format directly. The function for
scanning nodes in the flattened tree is about 40 lines of C and the
function for accessing a property in a flattened node is about as much. 
 
> 
> I think you are aware that there are several people out there working
> on a similar boot interface for the "small" PPC systems, too.

I know, and I was at the origin of the bi_rec proposal, a few years ago.
I've simply never seen anything actually happening.

> > No other solution will be accepted on the kernel side. At least for
> > ppc64
> 
> This is not exactly a constructive position. When  each  architecture
> comes  up with it's own solution for the same problem and then claims
> that no other solution will be accepted we will stick  with  what  we
> have now: a mess.
> 
> If this is really your position we may as well stop here.

The ppc64 kernel relies on an open firmware style device tree. That will
not change any time soon. This proposal is a way to define a subset of
this device-tree along with a compact & flattened format so that one
don't have to do a full Open Firmware implementation and so that mimal
trees can be used.

> Yes, of course. And using ATAGS is the only supported way to boot  an
> ARM kernel, and so on.
> 
> If everybody claims that his way of doing things is the only accepted
> solution we can really save all the time we are  wasting  on  such  a
> discussion.

Maybe. I'd rather have this proposal completed and have actual comments
about the _content_ of it rather than such a debate at this point. Once
we have that working, we can talk about extending it.

> > talks about backporting support for that to ppc32 as well. Other
> > architectures are welcome to use it too though :) The device-tree in the
> 
> Ummm.. Ben, I have really high respect for you, but such  a  position
> is  simply  arrogant.  With the same right the ARM folks can say that
> ATAGS is the way to go and other architectures are welcome to use it.
> Actually they might have older rights.

May well be. But that out of topic. The decision has been made already.

> > > Why don't we try to come up with a solution that is acceptable to the
> > > other architectures as well? 
> > 
> > This has been discussed over and over again, that is the best way to
> > never come up with a solution as everybody will want something different
> > and nobody will ever agree.
> 
> With such a position I really wonder why you ever asked?

I'm asking for comments about the content of the proposal and posting to
inform people of what's going on. You are the one wanting to extend it
to other architectures :)

> > The present proposal is implemented today on the ppc64 kernel already,
> > and we have decided to not go backward on this requirement. 
> 
> The why the heck do you call this a RFC or a proposal? To me it seems
> that you don't propose but dictate a  solution  -  a  solution  which
> pretty   much  ignores  everything  but  your  own  requirements.  If
> everything has been decided already I can as well shut up.

I'm asking for comments about the actual details of it, if something was
overlooked in the format (though that actually works today), if my
wording is wrong in parts, if we should define in more details some
aspect of it.

> But please never claim that this has been _discusssed_.

No, what I meant earlier is that trying to come up with something like
that, as you stated earlier, has been discussed again and again and
again without any useful result.

Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Stefan Nickl]

On Fri, 2005-05-20 at 01:14 +0200, Wolfgang Denk wrote:
> > ppc64 kernel anyways ? I don't think that is very relevant. On the
> 
> I am aware that you think so, and I try to raise  your  awareness  of
> the fact that there is a huge number of small machines out there.
> 
> Please keep in mind that the same interface will be forced sooner  or
> later  on small 8xx systems with maybe just 4 MB flash and 8 or 16 MB
> RAM.

I don't seem to be getting the point: As you proved conclusively on your
website, 2.6 (and IMHO very likely anything that will come after it)
does not scale down well to small systems like the 8xx any more anyways.

And I don't think such a major change will be "forced" upon the mostly
frozen 2.4 tree.

So why try to stop the folks that want to unite the current "mess" in a
proven superset datastructure that seems to suit quite fine with all
chips that came into production for (at least) the last five years?

-- 
Stefan Nickl
Kontron Modular Computers

Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Hollis Blanchard]

On May 19, 2005, at 8:18 AM, Wolfgang Denk wrote:
>
> But my biggest concern is that we  should  try  to  come  up  with  a
> solution  that  has  a  wider  acceptance. Especially from the U-Boot
> point of view it is not exactly nice that each of  PowerPC,  ARM  and
> MIPS  use  their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.
>
> As is, your proposal will add just another incompatible way of  doing
> the  same  thing  (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).
>
> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well?
>
> Maybe you want  to  post  the  RFC  to  lkml,  or  at  least  to  the
> linux-arm-kernel and linux-mips mailing lists?

As you observe, having multiple incompatible communication mechanisms 
is an issue of u-boot code maintenance. Since you are the most affected 
party, perhaps you could propose something for all the architectures? 
You're obviously much more in tune with the needs of ARM and MIPS...

In the meantime, it sounds like this device tree stuff solves ppc64's 
problem in a way the maintainers are happy with, so it's hard to ask 
them to come up with a solution to a problem they don't have.

-Hollis

Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Wolfgang Denk]

In message <6fcc07be88e5091ac1428e9bbde6d92f@penguinppc.org> you wrote:
>
> > Maybe you want  to  post  the  RFC  to  lkml,  or  at  least  to  the
> > linux-arm-kernel and linux-mips mailing lists?
> 
> As you observe, having multiple incompatible communication mechanisms 
> is an issue of u-boot code maintenance. Since you are the most affected 

No, it's vice versa. U-Boot has always been  just  implementing  what
the  kernel  does.  There are many other boot loaders around that all
have to adhere to the interface(s) imposed on them by the kernel.

> In the meantime, it sounds like this device tree stuff solves ppc64's 
> problem in a way the maintainers are happy with, so it's hard to ask 
> them to come up with a solution to a problem they don't have.

Well, actually nobody has problems:  the  ARM  and  MIPS  folks  have
working  solutions,  too.  The  next  architecture will implement yet
another way of passing information to the kernel,  implement  it  and
state that they will not accept any other solution, and so on.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Where people stand is not as important as which way they face.
        - Terry Pratchett & Stephen Briggs, _The Discworld Companion_

Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Paul Mackerras]

Wolfgang Denk writes:

> But my biggest concern is that we  should  try  to  come  up  with  a
> solution  that  has  a  wider  acceptance. Especially from the U-Boot
> point of view it is not exactly nice that each of  PowerPC,  ARM  and
> MIPS  use  their very own, completely incompatible way of passing in-
> formation from the boot loader to the kernel.

I am familiar with birecs and I have looked at the ARM atags
structure, which is the same as birecs at an abstract level, i.e. a
list of arbitrary blobs of data, each with a binary tag and a size.

As far as MIPS is concerned, there didn't seem to be any single
consistent way of passing information from the bootloader to the
kernel.  They seem to be in a similar mess to ppc32 in this respect.
I want to avoid that mess for ppc64 by stating now, while there is
only one embedded ppc64 board that runs linux (the Maple eval board)
that there is one true way to pass information into the kernel at boot
time, and that is a flattened device tree.

Birecs and atags are both OK at representing a specified, limited set
of items of information, such as the location and size of an initrd
image or the total amount of memory in a system.  They fall down when
it comes to giving information about the devices in the system and
their interconnections.  For instance, atags has a structure for
representing a frame buffer - but what if you have two video cards in
your system?

Essentially, each element in the birecs/atags list is like a property
in a device tree that has only one node, and the entire birecs/atags
list is like a 1-node device tree.  What the device tree gives you is
the ability to organize those pieces of information hierarchically so
that it becomes obvious when you have multiple instances of a device
(e.g. a PCI host bridge), what pieces of information apply to which
device instances, and which devices have to be used to get to certain
other devices.

Thus, my opinion is that the device tree is technically superior to
the birecs/atags approach.  The device tree has also proven itself to
be capable of representing the information that the kernel needs about
all sorts of systems from the very small to the very large.  Unless
you can come up with something even better, ppc64 won't be changing.
In particular we're not going to go back to anything like birecs or
atags.

Also, given that a minimal flattened device tree fits in well under
1kB, any arguments about "excessive" memory usage will need to be
accompanied by specific code and data sizes of a real-world example.

> As is, your proposal will add just another incompatible way of  doing
> the  same  thing  (of course we will have to stay backward compatible
> with U-Boot to allow booting older kernels, too).

U-Boot currently doesn't support any ppc64 machines, does it?  So
how is there a backward compatibility issue?

Ben's proposal is for ppc64, at least as present.  If the ppc32
embedded developers decide they want to use a device tree, that would
be good, but it will proceed by 

> Why don't we try to come up with a solution that is acceptable to the
> other architectures as well? 

Other architectures are welcome to move to using a device tree.  The
problem is going to be convincing them to spend the effort to make the
change.  None of the other architectures currently have a solution
that is appealing.

Paul.

Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Paul Mackerras]

I wrote:

> Ben's proposal is for ppc64, at least as present.  If the ppc32
> embedded developers decide they want to use a device tree, that would
> be good, but it will proceed by 

... and got interrupted.  I meant to write "proceed by persuasion and
consensus, not fiat".

Paul.