Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed

[David Gibson]

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: pgpiFB20saCNZ.pgp
Description: PGP signature