lkml.org 
[lkml]   [2015]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
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@landley.net> 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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2015-05-06 07:21    [W:0.097 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site