[OLPC-devel] Device tree
Mitch Bradley
wmb at firmworks.com
Mon Aug 14 15:18:13 EDT 2006
> Our big set of variables is all the stuff/buses that can be on USB.
>
There is a trivially easy way to handle USB device trees in our environment:
Since USB is hot-pluggable, the device tree is inherently a temporal
approximation of reality, because a device could be plugged or unplugged
at any point in the boot sequence.
So for the greased path of booting from NAND FLASH, the BIOS just
populates the device tree with the USB devices that are soldered to the
mainboard and lets the final kernel sort out the details. So
enumeration only gets done once.
>> c) I will go out on a limb and say that I could add rudimentary OF
>> device tree support to either or both of LinuxBIOS and a custom kernel
>> in a very short time. Especially if the actual configuration is mostly
>> known. No methods, just properties. You may well ask: Why bother with
>> a device tree if the configuration is known? The answer: Because when
>> we do the 2nd generation hardware and kernel, we will wish that we had.
> True. I watched the iPAQ folks *try* to do this, though, and then not
> follow through (so there wasn't sufficient information later). If we're
> going to do this, we'd better do it out of the box.
>
There is a trick to solve the "not enough information about a device"
problem. Actually, it's not exactly a trick; I explicitly designed in
this capability from the outset.
It depends on the fact that OF properties are retrieved by name, and if
the kernel asks for a property that doesn't exist, it is notified of
that fact.
So you don't have to anticipate all of the descriptive properties in
advance. When the first hardware variant comes into existence, you then
invent a property to report that difference. The new kernel that
supports the new hardware knows that if the new property is not present,
the hardware behaves the old way. Migration occurs gracefully.
You still have to be rigorous about creating new properties when the
hardware changes, but you don't have to predict the future. It suffices
to be a professional, but you don't have to be a fortune teller.
More information about the Devel
mailing list