ARMDeviceTrees

Differences between revisions 5 and 6

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:

Item	Status
Add atag type for device tree pointer	done
Add dtb blob & atags support to bootloader/qemu	qemu done
Establish early C runtime environment in real mode to call early_setup()	dropped
Establish requirements of early mdesc usage	done
Populate early_setup() to parse enough DT for a dynamic mdesc	dropped
Parse DT pointer from atags	done
Little-endian support for drivers/of/	done
Provide memory and initrd parsing for early dt	done
Add machine probe infrastructure	done
Add machine probe support for versatile platform	done
Add DT infrastructure to later boot	in progress
Add DT discovery to amba bus	in progress
Add 'dtb wrapper' support to ARM kernel
Add DT discovery support for drivers on platforms we'd like to DT-ise	ongoing, longer term work

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

Development details

First, grab the device tree compiler from git://git.jdl.com/software/dtc.git. Compile and install to a local --prefix.

Next, compile the qemu tree above, specifying the paths to dtc's install prefix:

./configure --target-list=arm-softmmu --audio-drv-list="alsa pa" \
          --enable-fdt \
          --extra-cflags=-I<path-to-libfdt-prefix>/include \
          --extra-ldflags=-L<path-to-libfdt-prefix>/lib

Use the following device tree, saved as something like versatile.dts:

/dts-v1/;

/ {
        model = "versatilepb";
        compatible = "arm,versatilepb";
        #address-cells = <1>;
        #size-cells = <1>;

        memory {
                name = "memory";
                device_type = "memory";
                reg = <0x0 0x08000000>;
        };

        chosen {
                bootargs = "console=ttyAMA0 debug";
        };
};

The command line and memory information will be updated at runtime by qemu, so don't worry if they're not correct for your setup.

Compile this to a device tree blob:

dtc -O dtb  -o versatilepb.dtb versatilepb.dts

And place the .dtb file in the pc-bios/ directory of your qemu build tree.

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). At present, we don't do machine detection until we've reached a C environment, so we're currently incompatible with DEBUG_LL. Although users will not need DEBUG_LL, it's probably required for upstream adoption. 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.

Ubuntu Wiki