Ubuntu Wiki

• Launchpad Entry: mobile-lucid-arm-device-tree-support

• Created: 2009-11-02

• Contributors:

• Packages affected:

Summary

Device tree's are a mechanism to pass hardware configuration data to the operating system. Currently ARM Linux uses the mach-type method to figure out device details but this is cumbersome for the ever-increasing number of board variants and it doesn't hold data about attached peripherals.

Using device trees could simplify board ports and reduce platform specific code.

Jeremy's kernel devicetree work is documented at KernelTeam/ARMDeviceTrees.

Release Note

Introducing device tree support for the ARM platform will require no end-user configuration and its usage should be transparent to the user.

Rationale

There are a great many number of embedded devices that are based on the same silicon chips but designed into custom boards or devices, all of which could use the same kernel if not for the slight differences between them. Furthermore, even the same family of chips can have slightly different connections leading to a custom kernel being required.

As the number of chip-sets increase, so too does the software needed to support them at the kernel level.

Device tree's try to combat these slight differences by allowing hardware resources to be described in a human-readable form which is then converted into a binary object and passed to the kernel at boot-time. This allows the kernel to discover the hardware it is running on instead of embedding this information inside the kernel itself.

This idea is based on the Open Firmware IEEE 1275 Open Firmware implementation.

User stories

• A user wants to use their hard-drive, with an installed version of Ubuntu ARM, on two separate devices which have the same SoC but differing hardware configurations.

Assumptions

Device trees on ARM have had some opposition from the ARM kernel maintainer (http://lkml.org/lkml/2009/5/27/446) but there is growing support for its inclusion. Any implementor of a device tree solution will have to work closely with the current interested parties to ensure there is a wider support by the whole community.

Design

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

There should be no UI changes.

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Notes from the UDS session.

• GL = Grant Likely.
• JK = Jeremy Kerr.
• DM = David Mandala.

Action Points

• DM to co-ordinate with GL and JK to supply hardware and resources.
• New quirks session to be arranged.

History

• Concept from Open Firmware.
• Provides a structure to describe the decices hardware.
• Used in PPC for many years on servers and Apples machines.
• Decided to do it in the embedded space by using a flattened device tree.
• FDT is a tree structure of nodes and properties (key/value pairs).
• FDT is written by the developer who brings up the board.

FDT

• Every node has one parent.
• Nodes can have sub nodes.
• Nodes can have properties.
• Kernel discovers the board variant and parses the FDT on boot.
• Variences handled easily.
• FDT Compiler (DTC) compiles .dts to .dtb (binary).
• compatible property allowed backwards-compatibility binding.
• Can be used for bootloader to kernel communication including configuration data.
• .dts files are multi-OS.

Discussions with RK

• RK wanted proof it works for ARM devices.
• GL's task it do produce a POC ARM implementation against main-line.
• GL will provide a library to allow the kernel to support FDT's on ARM (non-invasive).
• CELinux Forum have provided funding for GL.

Next steps

• GL is merging the 3 platforms that currently have FDT's to make it more generic.
• Only then can ARM support be added. First QEMU will be supported then real hardware. GUMSTIX (sp!) and beagleboard.
• OF platform will not be ported to ARM.
• Hooks will allow devices to gather more data if needed.
• Beginning of probe routine will check to see if a FDT is available and use that if possible.
• ATAG will not be replaced, it will be extended to use FDT's too.
• Where will the DT data come from?
  • GL - Not the firmware.
  • Bootloader should pass this information.
  • If not appropriate, a kernel wrapper could add an ATAG for the .dtb and jump to the kernel.
  • Softboot should be used.
• What needs to be done after POC - docs, more board ports, firmware interface needs to be decided.
• Should be available mid-Jan - GL
  • GL is FDT maintainer, patches will go in. For mainline, depends on RK.
• .dts files will be maintained in the kernel just like PPC.
• libfdt is BSD licenced.
• UEFI will not happen easily but if so, FDT's will not conflict with it - GL
• FDT's will enhance UEFI - DM
• Large overhead currently - 1 kernel per board. Lucid would be nice for FDT's but more likely for Lucid+1 - DM.
• 1 kernel per SoC family - GL

Other Notes

• DT's could be used to describe other bindings such as ALSA audio and clock tree structures.

• A new session is to be arranged to discuss DT quirk support. kernel-devicetree-quirks

CategorySpec