* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
2005-05-19 13:18 ` [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2) Wolfgang Denk
@ 2005-05-19 13:16 ` Pantelis Antoniou
2005-05-19 22:20 ` Benjamin Herrenschmidt
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Pantelis Antoniou @ 2005-05-19 13:16 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc64-dev, linuxppc-embedded, u-boot-users, linuxppc-dev
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
2005-05-19 13:18 ` [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2) Wolfgang Denk
2005-05-19 13:16 ` Pantelis Antoniou
@ 2005-05-19 22:20 ` Benjamin Herrenschmidt
2005-05-19 23:14 ` Wolfgang Denk
2005-05-20 3:51 ` Hollis Blanchard
2005-05-20 4:24 ` Paul Mackerras
3 siblings, 1 reply; 10+ messages in thread
From: Benjamin Herrenschmidt @ 2005-05-19 22:20 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-dev, linuxppc64-dev, linuxppc-embedded, u-boot-users
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
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
2005-05-19 22:20 ` Benjamin Herrenschmidt
@ 2005-05-19 23:14 ` Wolfgang Denk
2005-05-19 23:28 ` Benjamin Herrenschmidt
2005-05-20 6:44 ` Stefan Nickl
0 siblings, 2 replies; 10+ messages in thread
From: Wolfgang Denk @ 2005-05-19 23:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, linuxppc64-dev, linuxppc-embedded, u-boot-users
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
2005-05-19 23:14 ` Wolfgang Denk
@ 2005-05-19 23:28 ` Benjamin Herrenschmidt
2005-05-20 6:44 ` Stefan Nickl
1 sibling, 0 replies; 10+ messages in thread
From: Benjamin Herrenschmidt @ 2005-05-19 23:28 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-dev, linuxppc64-dev, linuxppc-embedded, u-boot-users
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
2005-05-19 23:14 ` Wolfgang Denk
2005-05-19 23:28 ` Benjamin Herrenschmidt
@ 2005-05-20 6:44 ` Stefan Nickl
1 sibling, 0 replies; 10+ messages in thread
From: Stefan Nickl @ 2005-05-20 6:44 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc64-dev, linuxppc-embedded, u-boot-users, linuxppc-dev
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
2005-05-19 13:18 ` [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2) Wolfgang Denk
2005-05-19 13:16 ` Pantelis Antoniou
2005-05-19 22:20 ` Benjamin Herrenschmidt
@ 2005-05-20 3:51 ` Hollis Blanchard
2005-05-20 6:59 ` Wolfgang Denk
2005-05-20 4:24 ` Paul Mackerras
3 siblings, 1 reply; 10+ messages in thread
From: Hollis Blanchard @ 2005-05-20 3:51 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc-dev, linuxppc64-dev, u-boot-users, linuxppc-embedded
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
2005-05-20 3:51 ` Hollis Blanchard
@ 2005-05-20 6:59 ` Wolfgang Denk
0 siblings, 0 replies; 10+ messages in thread
From: Wolfgang Denk @ 2005-05-20 6:59 UTC (permalink / raw)
To: Hollis Blanchard
Cc: linuxppc-dev, linuxppc64-dev, u-boot-users, linuxppc-embedded
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_
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
2005-05-19 13:18 ` [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2) Wolfgang Denk
` (2 preceding siblings ...)
2005-05-20 3:51 ` Hollis Blanchard
@ 2005-05-20 4:24 ` Paul Mackerras
2005-05-20 4:28 ` Paul Mackerras
3 siblings, 1 reply; 10+ messages in thread
From: Paul Mackerras @ 2005-05-20 4:24 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linuxppc64-dev, linuxppc-embedded, u-boot-users, linuxppc-dev
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)
2005-05-20 4:24 ` Paul Mackerras
@ 2005-05-20 4:28 ` Paul Mackerras
0 siblings, 0 replies; 10+ messages in thread
From: Paul Mackerras @ 2005-05-20 4:28 UTC (permalink / raw)
To: Wolfgang Denk, linuxppc64-dev, linuxppc-embedded, u-boot-users,
linuxppc-dev
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.
^ permalink raw reply [flat|nested] 10+ messages in thread