Jamie Bennett Speaks

Thoughts from Jamie Bennett

ELC2009 – Device Trees for ARM

Written by JamieBennett onOctober 20th, 2009 at3:58 pm in


  Vitaly Wool




On Friday 16th October 2009 Vitaly gave a technical, and often hotly debated
presentation on the state of device tree’s on the ARM platform. The talk was
well attended for such a technical presentation and the audience was found
often engaging with Vitaly as he delivered his talk. There seemed to be an
underlying hostility towards Device Trees on the ARM platform (and in general
its fair to say) due to the lack of documentation, standards among its users,
the inability to describe certain devices and it lack of real world exposure
outside of the PPC and Spark worlds.

Main points

  • Device trees could save a lot of bloat.
  • Device trees could save a lot of time when implementing new SoC’s.
  • Current implementations aren’t adequate.
  • There is no proven test case outside of openfirmware and PPC.
  • No complicated architecture is using device tree’s.
  • Lack of standardisation is holding device tree’s back.
  • It is hard to define something in the device tree format.


Although the majority of the audience seemed well versed on the subject,
especially as the previous talk had been on device trees, Vitaly began by
explaining what a device tree was.

He went on to say a device tree is:

  • A tree-like data structure where each node has a name, properties and a single parent.
  • A standard described in IEEE 1275.
  • A plain text structure compiled into a binary form and parsed by the kernel at boot time.
  • A description of the running platform including the functional layout (CPU, Memory e.t.c) the configuration (kernel parameters) and the device names.
  • Can be supplied by the firmware.
  • A requirement on PPC and Sparc but no other architecture.

Current ARM implementation

Currently ARM uses arch/arm/tools/mach-types and the Machine ID from the firmware to describe the machine configuration. This has the disadvantage of being unable to indicate the platform well and it doesn’t handle variants well. Also it doesn’t tell you about the attached peripherals.

This approach means that adding new chipset support is overcomplicated. You need to define many variables and even then the kernel needs recompiling too. This leads to platform data bloat. There is also no way to tell the kernel it shouldn’t re-init some devices on boot-up which leads to splash screen flicker and longer boot times.

The consequence of the current setup is that we can’t build a kernel that has support for more than one chipset, even if they live in the same family such as I.MX31 and OMAP2430.

Device Trees on ARM status

There have been multiple attempts to implement device tree’s for the ARM platform and get the main line kernel to adopt it. Each attempt has failed with Russell King (ARM Maintainer) being the main leader of the opposed.

Advantages of Device Tree’s on ARM

  • New SoC’s can be added faster.
  • No recompilation of the kernel to support other SoC’s in the same family.
  • Initialisation improvments including the ability to have parallel initialisation and dependancy rules.

This would lead to true multi-platform kernels.

Disadvantages of Device Tree’s on ARM

  • There is additional code needed to parse the new tree format and get the required information from it. There is an argument that this is bloat but the reality is that the relatively small amount of code that is added more than compensates for the removed platform specific code.
  • Parsing the tree needs to be done at boot time so it could slow down the boot. To avoid slow down, parallel initialisation can be done.
  • Some devices can’t be described well with device tree for example GPS, bluetooth, and GPIO based ones. So the point was made that device trees are just not read for all devices.
  • There are some corner cases with device tree’s such as PXA on ARM and GPIO configuration.
  • Device trees are relatively untested outside of the PPC and Sparc architecture and hence there is no real proof of concept for ARM to prove that it will work for a full ARM system.

Comparisons with PPC

There was a discussion about how PPC’s needs are very simple compared to ARM’s.

Some of the points raised were:

  • PPC has no platform_data analog.
  • PPC has no resource analogue.
  • ARM’s of_device would need to be either replaced or reworked.
  • ARM has none-standard firmware.
  • ARM is inherently a closed architecture.


The talk and discussion was very anti-device trees on ARM. People were focusing on the negatives rather than what benefits ARM would gain from this. There was a sense that something had to be done but exactly what eluded everyone.

One Response to 'ELC2009 – Device Trees for ARM'

Subscribe to comments with RSS or TrackBack to 'ELC2009 – Device Trees for ARM'.

  1. [...] runs very well on some ARM based platforms and there is a sustained effort to make it work more ubiquitously across many more. To that end our goal is to have Ubuntu running on any ARM based device (as long [...]

Leave a Reply