Dear Ben,
in message <1116541230.5153.8.camel@gaston> you wrote:
quoted
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.
quoted
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.
quoted
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.
quoted
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.
quoted
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.
quoted
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
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.
quoted
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.
quoted
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.
quoted
quoted
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 :)
quoted
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.
On Fri, 2005-05-20 at 01:14 +0200, Wolfgang Denk wrote:
quoted
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