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

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

On Fri, 2005-05-20 at 08:33 +1000, Benjamin Herrenschmidt wrote:
> > Marius was talking about the amount of data passed to the kernel.
> 
> A few Kb maybe... Current implementations always provide a full featured
> device-tree with pci devices so they aren't a good example (and I don't
> have numbers in mind at the moment). I'll try to get some later today.
> The property names are factored out (only one copy of a given name) to
> avoid bloat, the node format is very compact, A small device-tree would
> be only about a dozen node (the minimal is 5 nodes including the root)
> with only a few properties 

Ok, I got some numbers here. (I have removed the page alignment
constraint for the DT block and the strings block in the "blob" passed
in btw, I forgot to update v2)
 
 - The minimal example device-tree given as an example in the document
(exactly identical as the one in v2 of the document, which means it may
even shrink more, see below) fits in a blob (complete with header) of
764 bytes.

 - The complete device-tree of my PowerMac laptop (this is _huge_, Apple
puts a _lot_ of stuff in there, way more than most embedded board even
the most complex ones will ever need) fits into a 37k blob.

I will come up with more numbers soon including a good "average" example
that is a Maple board with all the ISA/serial stuff (which is very
useful to have there) but without the individual PCI devices.

On an additional note, I'm also rev'ing up the blob format with
additional space savings in mind:

 - Current version is 2. That's what the kernel recognises and what
current kexec tools generate (well... they actually generate a version 1
but the difference is minor).

 - Version 3 will be backward compatible and just adds a "string table
size" field to the header to help kernel do better memory management
with the flattened device-tree. kexec can implement it, older kernel
will still understand the tree.

 - Version 16 will not be backward compatible (will require kernel
patches, but that should be ok for new board vendors) that allows more
space saving. For this version, I'm planning the following changes for
now:

   * Relax some alignement restrictions (already did it for the numbers
above)
   * Allow replacing of the full path string with only the "name at unit
address" part, letting the kernel reconstruct the full path. With this
change, the "name" property get be dropped in each node as well as in
can be reconstructed by the kernel. There is a lot of redundency in the
full path, so that should save a bit. Side effect is also to remove any
name requirement for the root node.
   * Make the "linux,phandle" property optional. It will only be
required for nodes that are referenced by another node using a phandle
value (typically, nodes part of the interrupt tree).

With those chances, the example minimal tree may shrink down to about
600 bytes (gross estimate), which would mean an average tree with a few
devices would be between one and 3Kb (gross estimate too).

Ben.