On Wed, 2005-05-18 at 10:12 +0200, Marius Groeger wrote:
Ben,
On Wed, 18 May 2005, Benjamin Herrenschmidt wrote:
Here's the very first draft of my HOWTO about booting the linux/ppc64 kernel without open firmware. It's still incomplete, the main chapter
^^^^^^^^^^^^^^^^^^^^^One could argue whether the full-blown emulation of an OF device tree may really be called this.... ;-)
You must be kidding :)
Honestly, a device tree is small and rather simple to layout, and would fix most of the issues with piling up crap like incompatible boot_info structures and that sort of thing that plague the ppc32 kernel.
A full blown implementation of OF is a lot bigger. It requires at least 3 different interfaces (the user interface, the fcode interface, the client interface), along with all the bits & pieces to get a full runtime environment.
b) Direct entry with a flattened device-tree block. This entry point is called by a) after the OF trampoline and can also be called directly by a bootloader that does not support the Open Firmware client interface. It is also used by "kexec" to
For OF based systems, what you outline definitely makes an awful lot of sense.
How so ? OF based system just implement the OF interface...
For others I wonder what the costs of this are in terms of the memory footprint (both RAM and ROM). Are there reference implementations in existence?
You may not have noticed (well, I haven't filled part III yet so it may not be clear), but I'm only making a very small subset of the device-tree mandatory, though I do encourage people to provide an as complete as possible.
For example, I will definitely not require the bootloader to provide a full tree of PCI devices, only host bridges, in order to get interrupt routing and resource mapping. However, I encourage people to put things like on-chip devices in there, it makes everything much more flexible.
Regarding the cost, well, the device-tree itself is fairly small, maybe a couple of pages for a minimum one. As I wrote, embedded boards can decide to have it built at booloader build time, and simply embedded as a blob in the firmware and passed along to the kernel, that is 0 firmware code. However, it would be simple to add minimum capabilities to the firmware for editing/adding properties (for things like memory size or kernel command line).
I wonder sometimes why people are so "afraid" of the device-tree concept... it's really simple, does not require that much code, and makes everything so much more flexible in the long run.
Ben.