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".)
2) Feed one of the dtb files to qemu to instantiate a bunch of devices.
3) Feed the same file to a generic-ish linux kernel to bind to those
devices. (Or have qemu do this for me.)
Every year or so I sit down to figure out how to do this, spent fifteen
minutes head scratching, and wander away again.
The archive in 1) should have subdirectories for architectures, with the
same name as the corresponding kernel arch directory. It would be nice
if there was some sort of dts_defconfig that built a vmlinux that
statically linked in all the drivers with a device tree binding. It
would be _really_ nice if qemu's vmlinux loader actually worked on all
the hardware targets.
In theory, this should be easy. In practice, I've never made it work.
Rob
Hi Rob,
On Fri, May 1, 2015 at 11:22 PM, Rob Landley <[email protected]> wrote:
> The archive in 1) should have subdirectories for architectures, with the
> same name as the corresponding kernel arch directory. It would be nice
> if there was some sort of dts_defconfig that built a vmlinux that
> statically linked in all the drivers with a device tree binding. It
"Generating .config from DTS"
https://groups.google.com/forum/#!topic/linux.kernel/xYrKolsgr0Y
In the mean time, partial mathing (for i2c/spi devices) has been implemented.
https://github.com/geertu/linux-scripts/blob/master/linux-config-from-dt
It needs more work to generate a full .config, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, May 1, 2015 at 4:22 PM, Rob Landley <[email protected]> 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.
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.
Rob
[1] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Hi Rob
On Tue, May 5, 2015 at 1:20 AM, Rob Herring <[email protected]> wrote:
> On Fri, May 1, 2015 at 4:22 PM, Rob Landley <[email protected]> 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.
>
> [1] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Great!
While "git log" has the "--nomerges" option, cgit hasn't, making it hard to see
the actual changes through the forest of merges.
Any chance merge commits not causing any changes can be stripped out, too?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
+Ian
On Tue, May 5, 2015 at 2:34 AM, Geert Uytterhoeven <[email protected]> wrote:
> Hi Rob
>
> On Tue, May 5, 2015 at 1:20 AM, Rob Herring <[email protected]> wrote:
>> On Fri, May 1, 2015 at 4:22 PM, Rob Landley <[email protected]> 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.
>>
>> [1] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
>
> Great!
>
> While "git log" has the "--nomerges" option, cgit hasn't, making it hard to see
> the actual changes through the forest of merges.
>
> Any chance merge commits not causing any changes can be stripped out, too?
That's a question for Ian.
Rob
On Mon, May 04, 2015 at 06:20:35PM -0500, Rob Herring wrote:
> On Fri, May 1, 2015 at 4:22 PM, Rob Landley <[email protected]> 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