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.