[U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.