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@xxxxxxxxxxx> 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
Attachment:
pgphwNqMHMHYG.pgp
Description: PGP signature
