Summary of OLS Device Tree BoF

[Grant Likely]

Hey everyone,

Here's a quick summary of the things that were discussed in the Device
Tree BoF Thursday afternoon:

Participants:
Hugh Blemings (IBM)
Josh Boyer (IBM)
Jeff Carlyle (Motorola)
Rob Landley
Grant Likely (Secret Lab)
John Linn (Xilinx)
David Mandala (Canonical)
Scott Moser (IBM)
(I've forgotten the name of the fellow working with MIPS; please reply
to this email to add yourself to the list.)

Started with a quick overview of device trees;
- where the design originated from (heavily based on Open Firmware
ieee1275 device tree format)
  - actively developed within the PowerPC and Sparc Linux communities.
- where it is documented
  - Documentation/powerpc/booting-without-of.txt
  - Documentation/powerpc/dts-bindings/*
  - Open Firmware specifications
(http://www.complang.tuwien.ac.at/forth/1275.ps.gz)
  - Open firmware recommended practices
(http://playground.sun.com/1275/practice/)
  - Josh Boyer's and Grant Likely's OLS2008 paper (not posted yet;
will reply with address when I've posted it.)
  - Unpublished Power.org ePAPR spec.
- How it is used
  - The data structure is simply a tree of nodes.  Nodes have named
properties containing arbitrary data.
  - Usage conventions define how to describe hardware using the tree.
  - The OS is able to use data in the tree to decide what kind of
board and which device drivers to load.
- With arch/powerpc; it is required to pass the kernel (vmlinux) a
pointer to a device tree blob at boot.
  - Two ways to do this;
    1. Firmware provides the device tree blob.  U-Boot does this
    2. Device tree can be a payload of the bootwrapper.
      - Boot wrapper documented in Documentation/powerpc/bootwrapper.txt

Rob Landley asked several questions related to bringing up a PowerPC
kernel up on platforms with wacky firmware.  In particular, qemu-ppc
with OpenHackware firmware.
- How do powerpc systems boot when firmware doesn't understand device trees
  - the simpleImage.% build targets are useful when the firmware
interface is not understood.
  - Older versions of u-boot can use the cuImage.% targets
  - both simpleImage and cuImage targets embed a device tree blob into
the kernel
- Where is all this documented?
  - Action item for Grant Likely: add links to additional
documentation into Documentation/powerpc/booting-without-of.txt

It was mentioned that the MIPS folks are playing around with a port of
open firmware support taken from the Sparc architecture.  Primary
motivation is to get away from hard coding platform configuration into
kernel code for each board.

David Mandala (Canonical) recommended getting in touch with ARM and
the core ARM kernel maintainers to see how much interest there is in
using the device tree for ARM platforms.  Getting ARM international or
the core ARM maintainers would make adoption easier than trying to
bring in device tree support one ARM board at a time.  Jeff Carlyle
(Motorola) said that Motorola has a platform internally which is using
the device tree.

Up to this point, the linuxppc-dev mailing list has been the de facto
forum for discussing device tree bindings for boards and device
drivers.  Since the data structure is so flexible it is easy to put
data into it that conflicts with established conventions.  To protect
against this there is a lot of pressure to document and publish new
device tree bindings on the linuxppc-dev list before drivers that use
it are merged into the kernel.  However, since device tree interest
goes beyond the powerpc ecosystem, it probably doesn't make sense to
direct all device tree discussions to that list.  Hugh Blemmings (IBM)
took the initiative to create a new list:
devicetree-discuss at ozlabs.org.  The idea is to direct all device tree
bindings to this new list regardless of architecture.

In addition, the current bindings are documented in the
Documentation/powerpc/ directory.  It probably makes sense to move the
documentation to an arch neutral directory.  Perhaps
Documentation/dts-bindings?  Action Item: begin a discussion on this
list about moving all binding documentation [just reply to this thread
:-) ].

Also, because the device tree bindings are not necessarily Linux
specific, is it appropriate to move the bindings documentation out of
the kernel entirely?  A wiki might be a good idea, but on the other
hand, it probably needs to be something that ensures new bindings are
reviewed and achieve some level of consensus before it is put into
use.  In that regard, email seems to be the best method to encourage
review and feedback.

I think that covers the important point, but if I've missed anything
important, please reply and fill in the missing details.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.