On Mon, May 04, 2015 at 06:20:35PM -0500, Rob Herring wrote:

On Fri, May 1, 2015 at 4:22 PM, Rob Landley <rob@...> wrote:

On 04/11/2015 02:20 PM, Rowand, Frank wrote:

In recent years there have been proposed tools to aid in the creation of valid
device trees and in debugging device tree issues. An example of this is the
various approaches proposed (with source code provided) to validate device tree
source against valid bindings. As of today, device tree related tools,
techniques, and debugging infrastructure have not progressed very far. I have
submitted a device tree related proposal for the Linux Plumbers 2015 conference
to spur action and innovation in such tools, techniques, and debugging
infrastructure.

The current title of the track is "Device Tree Tools, Validation, and
Troubleshooting". The proposal is located at

http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting

Want I want to do is:

1) Download an archive of device tree files describing a bunch of
boards. (Both dts and corresponding dtb files, with maybe a .txt telling
me about the board and the -append line qemu needs to give it any
board-specific kernel command line stuff like "console=myserialport".)

The dts half is here[1]. It is a kernel repository automatically
stripped of everything but dts files.

2) Feed one of the dtb files to qemu to instantiate a bunch of devices.

I'd like this too. The QEMU maintainers don't really agree. I think
the ARM virt platform is the wrong way around with QEMU generating the
DT. There was a patch series to allow sysbus devices to be created on
the command line like you can with PCI. This would have allowed a
front end script to generate a QEMU command line from a DT. I'm not
sure if it ever got in.

I suggested something like this several years ago to Anthony Liguori
who didn't much like it. However qemu has changed a fair bit since
then, so it might be worth revisiting.

It's a big job though - lots of integration work with qemu's
configuration core. In particular allowing this without breaking
migrations or the various qapis is not straightforward.

It would lower the bar to adding new platforms to just writing models
for blocks perhaps. I'm not sure there's enough interest. The number
of ARM platforms supported in QEMU is much less than the kernel.

I havea presentation proposal for KVM Forum covering some ideas which
could be at least first steps towards doing this.

--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson