[Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Fri, Feb 13, 2009 at 01:32:19AM +0100, Carl-Daniel Hailfinger wrote:
> On 13.02.2009 00:58, Paul Brook wrote:
> >> Unless I'm mistaken, Linux is able to probe most hardware properties.
> >
> > You are badly mistaken.
> 
> Point taken.
> 
> 
> > On x86 workstation/server class hardware you might get away with it because 
> > everything interesting is either  standard legacy ports or PCI, and your 
> > firmware/bios already took care of the really hairy bits.
> 
> If the firmware doesn't set up the things which can't be probed, can it
> even be called firmware or is it more like a glorified bootloader?

A bootloader, not even much glorified, is often all there is on
embedded systems.

> > On embedded systems there's often very little that can be automatically 
> > detected, much less functionality provided by the firmware (You're lucky if 
> > all your RAM is even turned on!) and you just have to know where stuff is.
> 
> Ouch. I always thought turning on all the RAM was either a hardware (old
> x86) or firmware (modern x86) task.
> 
> I'm a bit surprised by the lack of automatically detectable features in
> embedded systems. Wouldn't automatic detection allow reusing whole OS
> images on slighly different systems and thus lower development cost?

Automatic detection requires protocols between hardware, firmware and
OS to implement it.  The ones that exist for full systems are too
heavyweight for embedded systems, or assume things about the hardware
setup that don't suit what embedded systems want to include.
Typically it's just been easier for embedded vendors to hack their
kernels to know the hardware directly.

The tradeoffs we've made for use of flattened device trees represent
an effort to achieve lower development cost precisely as you describe
here.  Inherently probably hardware (e.g. PCI, USB) is mostly omitted
from the tree, leaving a minimal blob of almost static information
which the firmware/bootloader can include to tell the OS about the
hardware setup while still having almost no "moving parts".

The kernel can still neatly support systems which don't provide a
flattened tree by being built with a wrapper.  The wrapper, which is
specific to a particular hardware/firmware combination contains a
flattened tree, plus some code to tweak it with what little
information the embedded firmware / hardware does provide (ram size
and flash size are common examples).

This way we have a kernel which can run unmodified on many systems
which do provide a flattened tree, and we're no worse off for systems
which don't (a hardware specific kernel is replaced by a hardware
specific kernel+wrapper combination).

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson