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

[Benjamin Herrenschmidt]

On Fri, 2005-05-20 at 09:11 +0200, Marius Groeger wrote:
> On Fri, 20 May 2005, Benjamin Herrenschmidt wrote:
> 
> > Ok, I got some numbers here. (I have removed the page alignment
> 
> Thanks!
> 
> I think we'll just have to try all that out for ourselves. Simple 
> boards will probably be at the lower end of your figures, which 
> *should* be fine for most people.

I expect so. Apple device-trees are really bloated :) I'm also rev'ing
up the format to be even a bit more compact. On the other hand, the low
figure I posted is a really very minimal tree with no device at all in
it. It would be interesting to see what Marvell comes up with.

> How do you view this, though: couldn't it happen in the future, once 
> the dev-tree has been widely established, that more and more drivers 
> are converted to pull their properties off the tree, because it is so 
> convenient? That *could* lead to rising expectations toward the 
> firmware, and make what once was a small blob a big blob. Is it 
> reasonable to assume drivers will #ifdef such behaviour?

It's very difficult to foresee. But most modern busses like PCI, PCIX,
PCIE etc... have their own "probing" facilities and such doesn't need
devices to be present in the tree. (It is handy to put some there when
ancialliary data has to be passed along, like MAC addresses, but that
isn't mandatory at this point). It would be nice however that busses
without those facilities (or pseudo busses), like on chip devices or
superio chips expose their internals via the device-tree, but again,
there is no need to bloat them with gazillion of properties. Just the
basic to be identified, matched to a driver and address/ports/interrupts
mappings. In fact, the device-tree "bloat" to expose those infos may
well be less than the code bloat for hard-coding all possible
combinations in the kernel, especially if you want a given kernel image
to deal with more than one revision of a board (which you _really_ want,
or am I the only one to had bad experience with production and customer
screwing up updates in the past ?)

> Again, I'm just thinking here, no opinions yet. Well, if you want one: 
> <opinion> Actually I always liked the idea of clever firmware, which 
> usually knows the underlying hardware best. </opinion>

The goal of this compact format is to allow for both clever and
non-clever firmwares. You can have a pre-built device-tree "blob" that
you just pass around, or really build one on the fly, though in that
later case, it may be worth simply implementing the OF client
interface :)

I'm also hoping there will be soon an open source release of a complete
Open Firmware implementation (fully in forth/fcode on top of the engine)
though I really can't tell much more about it at this point, and there
is the openbios project which also aims to be an OF implementation (that
one using a lot of C code)

> Don't underestimate embedded hardware. The MPC5554 has 286(!) 
> selectable-priority interrupt sources... :-)

Yes, but you don't need a node for each of them, nor even a property :)
You only need typically an interrupt-related property per device having
an interrupt (a given property can contain values for several interrupts
if a device has more than one) or per bridge for interrupt-maps (like
PCI). Though if you actually _use_ all of them (like wire 200 GPIOs used
as IRQs on your board or such thing :), well, it may be worth spending a
few Kb's of device-tree to avoid a hard coding mess in your kernel.

> Cheers,
> Marius
>