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.
Wolfgang Denk wrote:
Dear Ben,
in message <1116478614.918.75.camel@gaston> you wrote:
quoted
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
On Thu, 2005-05-19 at 15:18 +0200, Wolfgang Denk wrote:
Dear Ben,
in message <1116478614.918.75.camel@gaston> you wrote:
quoted
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
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
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.