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

I am looking for several things at the moment:

1) Suggestions of additional topics to be discussed.

2) Emails or other messages expressing an interest in attending the
device tree track.

3) Commitments to attend the device tree track (the conference committee
is looking at attendee interest and commitments as part of the process
of accepting the device tree track).

4) Identifying additional people who should attend the device tree track.

The desired outcome of the device tree track is to encourage the future
development of tools, process, etc to make device tree related development,
test, review and system administration more efficient, faster, easier, more
robust, and to improve troubleshooting and debugging facilities. Some
examples of areas of interest could include:
- make it easier to create correct device tree source files
- support for debugging incorrect device tree source files
- create a kernel that correctly boots one or more specific device trees
(eg a kernel configured to include the proper drivers and subsystems)
- create drivers that properly work for a device tree binding definition
- create drivers that support detecting errors in the related node(s) in
a device tree

The wiki page lists additional areas of interest.

Thanks,

Frank Rowand
Sony Mobile Communications

On Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank
<Frank.Rowand@...> 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

I am looking for several things at the moment:

1) Suggestions of additional topics to be discussed.

2) Emails or other messages expressing an interest in attending the
device tree track.

3) Commitments to attend the device tree track (the conference committee
is looking at attendee interest and commitments as part of the process
of accepting the device tree track).

4) Identifying additional people who should attend the device tree track.

The desired outcome of the device tree track is to encourage the future
development of tools, process, etc to make device tree related development,
test, review and system administration more efficient, faster, easier, more
robust, and to improve troubleshooting and debugging facilities. Some
examples of areas of interest could include:
- make it easier to create correct device tree source files
- support for debugging incorrect device tree source files
- create a kernel that correctly boots one or more specific device trees
(eg a kernel configured to include the proper drivers and subsystems)
- create drivers that properly work for a device tree binding definition
- create drivers that support detecting errors in the related node(s) in
a device tree

The wiki page lists additional areas of interest.

Is there a device tree porting HOWTO anywhere? If I have a board
that's using explicit C initialization, and I want to convert it over
to device tree, step by step what do I do?

If I'm writing a new board support, what device tree bits do I need to
get a shell prompt on a serial port running out of initramfs?
(Physical memory, interrupt controller, timer to drive the scheduler,
serial chip...)

There's a bunch of device tree reference material out there, but no
tutorial material at all, that I can find...

Rob

Hi Rob,

On Sun, Apr 12, 2015 at 2:05 AM, Rob Landley <rob@...> wrote:

Is there a device tree porting HOWTO anywhere? If I have a board
that's using explicit C initialization, and I want to convert it over
to device tree, step by step what do I do?

If I'm writing a new board support, what device tree bits do I need to
get a shell prompt on a serial port running out of initramfs?
(Physical memory, interrupt controller, timer to drive the scheduler,
serial chip...)

There's a bunch of device tree reference material out there, but no
tutorial material at all, that I can find...

http://www.devicetree.org/Device_Tree_Usage

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

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 Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank
<Frank.Rowand@...> 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

I am looking for several things at the moment:

1) Suggestions of additional topics to be discussed.

A few things on my list:

- Supported and not supported overlay usecases
- Tools for overlays - I think overlays has created new challenges in
validation and a need for new tools. How to test an overlay applies?
Generating a dtb from dts + overlay dts. Generating an overlay from a
diff of old and new dts (overlay as a way to update old dtbs)
- Shrinking the binding review fire hose. How to improve binding
documentation structure and review.
- Standardizing Android dtb handling. Appended DTB for arm64? Not
liked by upstream, but already in use.

2) Emails or other messages expressing an interest in attending the
device tree track.

3) Commitments to attend the device tree track (the conference committee
is looking at attendee interest and commitments as part of the process
of accepting the device tree track).

I plan to attend. I'm probably attending some of the Android mini conf
too, so I'll have to split my time.

4) Identifying additional people who should attend the device tree track.

Arnd Bergmann
Matt Porter
Jon Loeliger
Gaurav Minocha

Rob

The desired outcome of the device tree track is to encourage the future
development of tools, process, etc to make device tree related development,
test, review and system administration more efficient, faster, easier, more
robust, and to improve troubleshooting and debugging facilities. Some
examples of areas of interest could include:
- make it easier to create correct device tree source files
- support for debugging incorrect device tree source files
- create a kernel that correctly boots one or more specific device trees
(eg a kernel configured to include the proper drivers and subsystems)
- create drivers that properly work for a device tree binding definition
- create drivers that support detecting errors in the related node(s) in
a device tree

The wiki page lists additional areas of interest.

Thanks,

Frank Rowand
Sony Mobile Communications
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@...
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Tue, Apr 14, 2015 at 04:36:15PM +0100, Rob Herring wrote:

On Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank
<Frank.Rowand@...> 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

I am looking for several things at the moment:

1) Suggestions of additional topics to be discussed.

A few things on my list:

- Supported and not supported overlay usecases

I guess Kernel-driven overlay application (it's been called "quirks"
elsewhere) would fall under this? It's rather scary, and would need
fairly strict rules to be feasible and remain maintainable, which is
going to limit where it can be used.

I think the core guys for that are on the list already?

- Standardizing Android dtb handling. Appended DTB for arm64? Not
liked by upstream, but already in use.

If people are going to package a kernel and DTB together, it would be
nice if they could at least be easily decomposed (using something like
FIT).

So +1 for that discussion.

2) Emails or other messages expressing an interest in attending the
device tree track.

I'm interested.

3) Commitments to attend the device tree track (the conference committee
is looking at attendee interest and commitments as part of the process
of accepting the device tree track).

If the DT track goes ahead, I'll be there.

Mark.

On Tuesday 14 April 2015 10:36:15 Rob Herring wrote:

4) Identifying additional people who should attend the device tree track.

Arnd Bergmann
Matt Porter
Jon Loeliger
Gaurav Minocha

Sorry, I won't be there. I should have replied earlier, but I'll be on
parental leave at the time.

Arnd

On Tue, Apr 14, 2015 at 10:36:15AM -0500, Rob Herring wrote:

On Sat, Apr 11, 2015 at 2:20 PM, Rowand, Frank
<Frank.Rowand@...> 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

I am looking for several things at the moment:

1) Suggestions of additional topics to be discussed.

A few things on my list:

- Supported and not supported overlay usecases
- Tools for overlays - I think overlays has created new challenges in
validation and a need for new tools. How to test an overlay applies?
Generating a dtb from dts + overlay dts. Generating an overlay from a
diff of old and new dts (overlay as a way to update old dtbs)
- Shrinking the binding review fire hose. How to improve binding
documentation structure and review.
- Standardizing Android dtb handling. Appended DTB for arm64? Not
liked by upstream, but already in use.

- Clean up of existing hardware-specific bindings to conform to the
generic bindings, working dts files in the kernel tree, and bring
consistency to the documentation style/syntax.

2) Emails or other messages expressing an interest in attending the
device tree track.

3) Commitments to attend the device tree track (the conference committee
is looking at attendee interest and commitments as part of the process
of accepting the device tree track).

I plan to attend. I'm probably attending some of the Android mini conf
too, so I'll have to split my time.

4) Identifying additional people who should attend the device tree track.

Arnd Bergmann
Matt Porter
Jon Loeliger
Gaurav Minocha

I also plan to attend. I have an interest in most of the topics already
mentioned as well as the topic I added above.

-Matt

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 <rob@...> 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 -- geert@...

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 <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.

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 <robherring2@...> 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.

[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 -- geert@...

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 <geert@...> wrote:

Hi Rob

On Tue, May 5, 2015 at 1:20 AM, Rob Herring <robherring2@...> 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.

[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 <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