ARM Device Trees

This page outlines the implementation details and progress for the device trees on ARM work. At present it's just to document what I'm up to, we could merge this with the mobile-lucid-arm-device-tree-support spec. Contact Jeremy Kerr <jeremy.kerr@canonical.com> for comments/questions/etc.

Objectives

• Reduce time & effort required for ARM OEM bringup work

  • Most designs should only require a new DT, rather than new code
• Reduce patchset required from OEMs
  • Vendors' code drops should become smaller and more manageable
• Allow DT support to coexist with machine/platform IDs
  • Only the platforms we care about can be device-tree-ised, others can remain as existing
• Provide a solid case for upstreaming the DT work

Implementation Plan

My currently plan is to use the qemu 'versatilepb' platform as a testing environment for the early boot code, then continue on an iMX51 (babbage 2.0) board for device support. This should involve the following:

Backwards-compatible boot interface

It'd be desirable to have a boot interface that allows a DT-enabled bootloader to support existing kernels that are not DT aware. Of course, the board/platform/etc must have support in the non-DT kernel; specifically, the boards machine ID must be enabled in the booted kernel.

I plan to pass the DT to the kernel through a new ATAG (currently ATAG_DEVTREE, 0x5441000a). If the kernel discovers this atag during boot, it will skip the machine-ID-based detection and use the device tree to populate the mdesc.

For kernels that are not aware of ATAG_DEVTREE, they should skip this unknown tag (however, we will get a KERN_WARNING printk...), and continue with the given machine ID.

Code

Current development trees:

• qemu with initial DT support: http://kernel.ubuntu.com/git?p=jk/dt/qemu.git;a=summary

• kernel: http://kernel.ubuntu.com/git?p=jk/dt/linux-2.6.git;a=summary

Potential Issues

Early boot requirements

The kernel uses the mdesc members very early during boot (first usage is for serial debug output in __create_page_tables when CONFIG_DEBUG_LL is enabled), hence the early C environment in the plan above. However, as we're running C code with no MMU (and not at the final link address), we don't have access to global variables; this may be too restrictive for the generic drivers/of/ parsing code. A couple of options:

• Do a little initial early parsing (in asm or C) before the full parse; only need to extract a few properties for early boot (phys_io and io_pg_offset?).
• Do what powerpc does: make very early debug output non-portable (ie, depend on a compile-time IO address), bring up platform-independent debug code ASAP. Very early debug should only be needed for a small subset of problems, like MMU setup.

Upstream acceptance

For this work to be of value, we'd need to have it accepted by the ARM community. According to gcl, rmk is not convinced of the merits of DT for ARM, and would need to see benefits before accepting upstream.

Links

• lp blueprint: mobile-lucid-arm-device-tree-support

• spec: Specs/ArmDeviceTreeSupport