[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