dt: dtb version: add version info to dtb

From: Frank Rowand <[email protected]>

Documentation of bindings in node /chosen are scattered in several bindings files. If not already in Documentation/devicetree/bindings/chosen.txt, add a pointer in that file to where the property and node bindings are described.

This is a clean up in anticipation of adding another node binding in /chosen.

Signed-off-by Frank Rowand <[email protected]>

---
 Documentation/devicetree/bindings/chosen.txt |   31 +++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

Index: b/Documentation/devicetree/bindings/chosen.txt
===================================================================

Documentation/devicetree/bindings/chosen.txt +13 -0

@@ -44,3 +44,34 @@ Implementation note: Linux will look for
 on PowerPC "stdout" if "stdout-path" is not found.  However, the
 "linux,stdout-path" and "stdout" properties are deprecated. New platforms
 should only use the "stdout-path" property.
+
+
+Properties documented in other bindings
+---------------------------------------
+#address-cells                          video/simple-framebuffer-sunxi.txt
+
+#size-cells                             video/simple-framebuffer-sunxi.txt
+
+bootargs                                booting-without-of.txt
+                                        usage-model.txt
+
+initrd-end                              usage-model.txt
+initrd-start                            usage-model.txt

From: Frank Rowand <[email protected]>

Add /chosen/dtb-node binding.

Signed-off-by Frank Rowand <[email protected]>

---
 Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++

Index: b/Documentation/devicetree/bindings/chosen.txt
===================================================================

Documentation/devicetree/bindings/chosen.txt +25 -0

@@ -46,6 +46,43 @@ on PowerPC "stdout" if "stdout-path" is
 should only use the "stdout-path" property.
 
 
+dtb-info node
+----------------
+
+Information that describes where the device tree blob (DTB) came from and the
+environment it was created in.
+
+This node is normally created by including arch/arm/boot/dts/skeleton.dtsi,
+which includes include/dt-bindings/version.dtsi.
+
+Properties:
+
+version
+       The version of the DTB.  This is analagous to the linux kernel version.
+
+       This is a format free field intended for human consumption.  User space
+       programs should not have any expections about this property.
+
+       The DTB number in this property is incremented each time a make that
+       creates one or more DTBs is invoked.  If the make creates multiple
+       DTBs then this number is only incremented once.
+
+       The DTB number is stored in file .version_dtb.
+
+version-linux
+       The version of the linux kernel most recently built in the source

Quoted 3 lines · Frank Rowand

From: Frank Rowand <[email protected]>

Add /chosen/dtb-node binding.

Why? Please write better commit messages.

Quoted 43 lines

Signed-off-by Frank Rowand <[email protected]>

---
 Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++

Index: b/Documentation/devicetree/bindings/chosen.txt
===================================================================

Documentation/devicetree/bindings/chosen.txt +29 -0

@@ -46,6 +46,43 @@ on PowerPC "stdout" if "stdout-path" is
 should only use the "stdout-path" property.
 
 
+dtb-info node
+----------------
+
+Information that describes where the device tree blob (DTB) came from and the
+environment it was created in.
+
+This node is normally created by including arch/arm/boot/dts/skeleton.dtsi,
+which includes include/dt-bindings/version.dtsi.
+
+Properties:
+
+version
+       The version of the DTB.  This is analagous to the linux kernel version.
+
+       This is a format free field intended for human consumption.  User space
+       programs should not have any expections about this property.
+
+       The DTB number in this property is incremented each time a make that
+       creates one or more DTBs is invoked.  If the make creates multiple
+       DTBs then this number is only incremented once.
+
+       The DTB number is stored in file .version_dtb.
+
+version-linux
+       The version of the linux kernel most recently built in the source
+       control system that contains the source used to build the DTB.
+
+       The linux kernel version number is not incremented for a make that
+       creates a DTB.

Documentation/devicetree/bindings/chosen.txt on PowerPC "stdout" if "stdout-path" is · line 83

Quoted 6 lines

Documentation/devicetree/bindings/chosen.txt +6 -0

+
+dtb-path
+       The build directory relative path of the DTB.
+
+dts-path
+       The absolute path of the .dts file compiled to create the DTB.

So these become an ABI and we can never change the directory structure?

The problem with informational fields is someone, somewhere will rely on them and then we are stuck with them. Look at /proc/cpuinfo.

Rob

Quoted 14 lines · Frank Rowand

Documentation/devicetree/bindings/chosen.txt +14 -0

+version
+       The version of the DTB.  This is analagous to the linux kernel version.
+
+       This is a format free field intended for human consumption.  User space
+       programs should not have any expections about this property.
+
+       The DTB number in this property is incremented each time a make that
+       creates one or more DTBs is invoked.  If the make creates multiple
+       DTBs then this number is only incremented once.
+
+       The DTB number is stored in file .version_dtb.
+
+version-linux
+       The version of the linux kernel most recently built in the source

Documentation/devicetree/bindings/chosen.txt on PowerPC "stdout" if "stdout-path" is · line 83

Quoted 10 lines

Documentation/devicetree/bindings/chosen.txt +10 -0

+       control system that contains the source used to build the DTB.
+
+       The linux kernel version number is not incremented for a make that
+       creates a DTB.
+
+dtb-path
+       The build directory relative path of the DTB.
+
+dts-path
+       The absolute path of the .dts file compiled to create the DTB.

So these become an ABI and we can never change the directory structure?

The problem with informational fields is someone, somewhere will rely on them and then we are stuck with them. Look at /proc/cpuinfo.

And yes, you are right - anything like this which we add immediately becames a user ABI which becomes *very* difficult to change later, so in order to accept anything like this, we have to be absolutely sure that this is something we really really really really want to do. Let me put it another way: once this is accepted, it will probably be impossible to ever change it.

Quoted 28 lines · Rob Herring

Quoted 14 lines · Frank Rowand

Documentation/devicetree/bindings/chosen.txt +14 -0

+version
+       The version of the DTB.  This is analagous to the linux kernel version.
+
+       This is a format free field intended for human consumption.  User space
+       programs should not have any expections about this property.
+
+       The DTB number in this property is incremented each time a make that
+       creates one or more DTBs is invoked.  If the make creates multiple
+       DTBs then this number is only incremented once.
+
+       The DTB number is stored in file .version_dtb.
+
+version-linux
+       The version of the linux kernel most recently built in the source

Documentation/devicetree/bindings/chosen.txt on PowerPC "stdout" if "stdout-path" is · line 83

Quoted 10 lines

Documentation/devicetree/bindings/chosen.txt +10 -0

+       control system that contains the source used to build the DTB.
+
+       The linux kernel version number is not incremented for a make that
+       creates a DTB.
+
+dtb-path
+       The build directory relative path of the DTB.
+
+dts-path
+       The absolute path of the .dts file compiled to create the DTB.

So these become an ABI and we can never change the directory structure?

Quoted 2 lines

The problem with informational fields is someone, somewhere will rely on them and then we are stuck with them. Look at /proc/cpuinfo.

There's a bigger problem: including the Linux kernel specific version means that we will _never_ be able to move them out of the kernel.

Moreover, what it means is that people can then write code to test what the dtb version is, and we'll end up with the dtb version being tested to determine various features.

Since the design goal of DTB is to describe the hardware, including the Linux kernel version is totally against that: the Linux kernel version should be totally irrelevant. What's more relevant would be a _hardware_ version field, but even that's questionable...

And yes, you are right - anything like this which we add immediately becames a user ABI which becomes *very* difficult to change later, so in order to accept anything like this, we have to be absolutely sure that this is something we really really really really want to do. Let me put it another way: once this is accepted, it will probably be impossible to ever change it.

... just like Bogomips in /proc/cpuinfo.

On 3/19/2015 11:41 AM, Russell King - ARM Linux wrote:
What??? Why would we ever accept code that tested the dtb version instead of the compatible strings and properties in device nodes? The dtb version is a meaningless number just like the kernel version number in /proc/version is a meaningless number. It starts at 1 (and can be reset to 1 anytime the person controlling the build environment chooses to for any random reason). The dtb version number only makes sense in a local context to check which build of an object actually got onto the target.

Quoted 9 lines · Frank Rowand

On 3/19/2015 11:41 AM, Russell King - ARM Linux wrote:
What??? Why would we ever accept code that tested the dtb version instead of the compatible strings and properties in device nodes? The dtb version is a meaningless number just like the kernel version number in /proc/version is a meaningless number. It starts at 1 (and can be reset to 1 anytime the person controlling the build environment chooses to for any random reason). The dtb version number only makes sense in a local context to check which build of an object actually got onto the target.

I think you need to learn a lesson here. I rotfled at your "just like the kernel version number" comment, because we already have code in the kernel to map 3.x and 4.x kernels to a 2.60.x number because userspace breaks with 3.x and 4.x version numbers.

I'm quite sure that someone made the exact same argument about kernel version numbers that you're making above about versioning dtb stuff.

At the end of the day, if userspace starts abusing an API that we've provided in good faith, and we change something such as the version information which results in userspace breaking - even if userspace is doing something that's wrong according to how we've defined it, it's still our problem to fix. No userspace regressions when upgrading. That's the rule.

Don't bother trying to argue against this - you can't. We will not accept any argument (no matter how valid) which will result in userspace breaking upon an upgrade.

You must be *absolutely* *sure* that you want to export this information, and that you are absolutely happy with the consequences which would occur should userspace then start using this information in a way which you did not intend, which could very well block you from ever being able to change the version number from a prescribed "this version number makes userspace work" value.

Quoted 6 lines

You must be *absolutely* *sure* that you want to export this information, and that you are absolutely happy with the consequences which would occur should userspace then start using this information in a way which you did not intend, which could very well block you from ever being able to change the version number from a prescribed "this version number makes userspace work" value.

I understand the concern you are expressing. And I agree it is an issue to be concerned about and not dismissed. But I also think that the concern is mis-characterizing the "DTB version". To pick on the example in patch 0, an analogous Linux version is "#5" (not "4.0.0"):

Linux version 4.0.0-rc4-dirty (frank at buildhost) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #5 SMP PREEMPT Wed Mar 18 20:04:48 PDT 2015

and the proposed DTB version is "#4":

DTB version 4.0.0-rc4-dirty (frank at buildhost) (DTC 1.4.0-dirty) #4 Wed Mar 18 20:04:11 PDT 2015

I don't think the concern holds for "#5" and "#4".

I will concede that there is something unique in the proposed DTB version - the source code system commit version number (in this example "4.0.0-rc4-dirty" from git).

From: Frank Rowand <[email protected]>

Add /chosen/dtb-node binding.

Signed-off-by Frank Rowand <[email protected]>

---
 Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++

Index: b/Documentation/devicetree/bindings/chosen.txt
===================================================================

Documentation/devicetree/bindings/chosen.txt +6 -0

@@ -46,6 +46,43 @@ on PowerPC "stdout" if "stdout-path" is
 should only use the "stdout-path" property.
 
 
+dtb-info node
+----------------
+
+Information that describes where the device tree blob (DTB) came from and the
+environment it was created in.
+

Quoted 3 lines · Frank Rowand

From: Frank Rowand <[email protected]>

Add /chosen/dtb-node binding.

Why? It doesn't matter what the cover says, the commit message should have a rationale.

Who needs this information, and when do they need it?

Why is the existing information insufficient?

Quoted 19 lines

Signed-off-by Frank Rowand <[email protected]>

---
 Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++

Index: b/Documentation/devicetree/bindings/chosen.txt
===================================================================

Documentation/devicetree/bindings/chosen.txt +6 -0

@@ -46,6 +46,43 @@ on PowerPC "stdout" if "stdout-path" is
 should only use the "stdout-path" property.
 
 
+dtb-info node
+----------------
+
+Information that describes where the device tree blob (DTB) came from and the
+environment it was created in.
+

Documentation/devicetree/bindings/chosen.txt on PowerPC "stdout" if "stdout-path" is · line 64

Quoted 10 lines

Documentation/devicetree/bindings/chosen.txt +10 -0

+This node is normally created by including arch/arm/boot/dts/skeleton.dtsi,
+which includes include/dt-bindings/version.dtsi.
+
+Properties:
+
+version
+	The version of the DTB.  This is analagous to the linux kernel version.
+
+	This is a format free field intended for human consumption.  User space
+	programs should not have any expections about this property.

I doubt that this would stay the case for long were this property added.

Documentation/devicetree/bindings/chosen.txt on PowerPC "stdout" if "stdout-path" is · line 70

Quoted 5 lines

Documentation/devicetree/bindings/chosen.txt +5 -0

+	The DTB number in this property is incremented each time a make that
+	creates one or more DTBs is invoked.  If the make creates multiple
+	DTBs then this number is only incremented once.
+
+	The DTB number is stored in file .version_dtb.

This is irrelevant to the binding, and as you mention above, you can make no expectations about this property.

I'm not sure I see the point in adding a property which is not well-defined and not guarnateed to be in any way stable.

Documentation/devicetree/bindings/chosen.txt on PowerPC "stdout" if "stdout-path" is · line 77

Quoted 8 lines

Documentation/devicetree/bindings/chosen.txt +7 -0

+
+version-linux
+	The version of the linux kernel most recently built in the source
+	control system that contains the source used to build the DTB.
+
+	The linux kernel version number is not incremented for a make that
+	creates a DTB.

...so if I build a DTB outside of a linux source tree I don't get to describe that?

Documentation/devicetree/bindings/chosen.txt on PowerPC "stdout" if "stdout-path" is · line 83

Quoted 6 lines

Documentation/devicetree/bindings/chosen.txt +5 -0

+dtb-path
+	The build directory relative path of the DTB.
+
+dts-path
+	The absolute path of the .dts file compiled to create the DTB.

Why do you need the DTB path?

Why do these differ w.r.t. absolute/relative?

Why would you _ever_ need an absolute path!?

Mark.

Quoted 1 line

Why would you _ever_ need an absolute path!?

The absolute path tells you which source repository contained the source.

Quoted 2 lines

I'm not sure I see the point in adding a property which is not well-defined and not guarnateed to be in any way stable.

This binding is kind of an odd ball to me. It is clearly _not_ describing hardware, which is really the central point of the dtb. But the chosen node is allowed to cover policy things like the boot command line.

If I want to debug DTB related issues, read the source that was used to create the DTB, or slightly modify the DTB - where is the source and what is the version of it in the source control system.

When building and installing a DTB, did the version that I wanted to install on the target actually get on the target.

Quoted 7 lines

Documentation/devicetree/bindings/chosen.txt on PowerPC "stdout" if "stdout-path" is · line 83

Quoted 5 lines

Documentation/devicetree/bindings/chosen.txt +5 -0

+dtb-path
+	The build directory relative path of the DTB.
+
+dts-path
+	The absolute path of the .dts file compiled to create the DTB.

Why do you need the DTB path?

Paranoia. Even if not probable, one could build different DTBs from the same .dts.

Quoted 1 line

Why do these differ w.r.t. absolute/relative?

Those are the forms of the path that are present in the build system. If there is a good reason to change one of them to the other form, I could add the extra complexity to massage the path.

Quoted 2 lines

Why would you _ever_ need an absolute path!?

The absolute path tells you which source repository contained the source.

Quoted 6 lines

Quoted 2 lines

I'm not sure I see the point in adding a property which is not well-defined and not guarnateed to be in any way stable.

This binding is kind of an odd ball to me. It is clearly _not_ describing hardware, which is really the central point of the dtb. But the chosen node is allowed to cover policy things like the boot command line.

Sure, but this has nothing to do with policy regarding the HW. This is entirely to do with the build environment of the DTB, which in general you don't need to know.

Quoted 3 lines

If I want to debug DTB related issues, read the source that was used to create the DTB, or slightly modify the DTB - where is the source and what is the version of it in the source control system.

That's only useful if you have access to the machine that the source is on, access to the repo on said machine, and so on.

You can easily slightly modify a DTB by decompiling and recompiling it, as bootloaders do to inject /chosen/bootargs. Admittedly this can be painful, but at least you know exactly what was changed, because you know which DTB you started with.

Consider what modification by other agents means for provenance of the DTB. We've already been bitten by bootloaders messing with the DTB [1], and simple loaders can change things substantially [2,3], and won't update any provenance binding.

Quoted 3 lines

When building and installing a DTB, did the version that I wanted to install on the target actually get on the target.

You can already check the hash if you want to check that you copies the correct version; which is better than trusting an arbitrary string, because if anything fiddles with the DTB it will change.

[...]

Quoted 8 lines

Quoted 7 lines

Documentation/devicetree/bindings/chosen.txt on PowerPC "stdout" if "stdout-path" is · line 83

Quoted 5 lines

Documentation/devicetree/bindings/chosen.txt +5 -0

+dtb-path
+	The build directory relative path of the DTB.
+
+dts-path
+	The absolute path of the .dts file compiled to create the DTB.

Why do you need the DTB path?

Quoted 2 lines

Paranoia. Even if not probable, one could build different DTBs from the same .dts.

One could also build the same DTB from two different dts files, no?

You could build the same dtb from the same dts, but with some arbitrary things changed, such that the at either end of the process is irrelevant. Personally, I end up doing this a fair amount when testing.

Quoted 8 lines

Quoted 2 lines

Why do these differ w.r.t. absolute/relative?

Those are the forms of the path that are present in the build system. If there is a good reason to change one of them to the other form, I could add the extra complexity to massage the path.

Quoted 1 line

Quoted 3 lines

Quoted 1 line

Why would you _ever_ need an absolute path!?

The absolute path tells you which source repository contained the source.

Except that the absolute path is realtive to the machine it was built on, so doesn't actually help.

On various machines I have folders called /home/mark/src/linux. These are not the same folder. If I gave you a DTB that told you it was from /home/mark/src/linux/arch/arm64/boot/dts/vendor/foo.dts, you would have difficulty acquiring that precise file.

As far as I can tell, this binding just allows you to place a meaningless set of strings in the DTB, that don't actually tell you anything useful.

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/329938.html
[2] https://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/
[3] https://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/commit/?id=e4ae51a1c128ccaac01bdc834692fd15c3a3c8de

Quoted 3 lines

You can already check the hash if you want to check that you copies the correct version; which is better than trusting an arbitrary string, because if anything fiddles with the DTB it will change.

I'm confused. If the bootloader fiddles with the DTB then I can not compare a hash of the DTB from the build host to a hash of the DTB on the target. Of course the bootloader can also fiddle with the dtb-info if it wants to . Bootloaders do what they want to do. :-(

Quoted 11 lines

Quoted 10 lines

Quoted 7 lines

Documentation/devicetree/bindings/chosen.txt on PowerPC "stdout" if "stdout-path" is · line 83

Quoted 5 lines

Documentation/devicetree/bindings/chosen.txt +5 -0

+dtb-path
+	The build directory relative path of the DTB.
+
+dts-path
+	The absolute path of the .dts file compiled to create the DTB.

Why do you need the DTB path?

Paranoia. Even if not probable, one could build different DTBs from the same .dts.

Quoted 5 lines

One could also build the same DTB from two different dts files, no?

You could build the same dtb from the same dts, but with some arbitrary things changed, such that the at either end of the process is irrelevant. Personally, I end up doing this a fair amount when testing.

Exactly. And the dtb version number will change when the DTB is recompiled.

Quoted 7 lines

Quoted 7 lines

Quoted 1 line

Why do these differ w.r.t. absolute/relative?

Those are the forms of the path that are present in the build system. If there is a good reason to change one of them to the other form, I could add the extra complexity to massage the path.

Quoted 1 line

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

Why would you _ever_ need an absolute path!?

The absolute path tells you which source repository contained the source.

Except that the absolute path is realtive to the machine it was built on, so doesn't actually help.

Different use cases for different people.

In all cases the absolute path includes the relative path, so it is just a case of extra information. The relative portion of the path is still useful for anyone who wants to know what .dts was used in the build, even if they don't have access to the build machine. (They do have access to the gpl v2 source code, which will have at least the relative portion of the path because that is needed to build the DTB from the .dts.)

The extra information in the absolute path could be useful to a build engineer, a distro engineer, or a support person for a distro. Or could just be useless extra info.

Quoted 4 lines

On various machines I have folders called /home/mark/src/linux. These are not the same folder. If I gave you a DTB that told you it was from /home/mark/src/linux/arch/arm64/boot/dts/vendor/foo.dts, you would have difficulty acquiring that precise file.

If you distributed the DTB to me under the gpl v2 then you have also either distributed the source to me or offered to make it available to me.

From: Frank Rowand <[email protected]>

Add /chosen/dtb-node binding.

Signed-off-by Frank Rowand <[email protected]>

---
 Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++

Index: b/Documentation/devicetree/bindings/chosen.txt
===================================================================

Documentation/devicetree/bindings/chosen.txt +32 -0

+
+This node is normally created by including arch/arm/boot/dts/skeleton.dtsi,
+which includes include/dt-bindings/version.dtsi.
+
+Properties:
+
+version
+	The version of the DTB.  This is analagous to the linux kernel version.
+
+	This is a format free field intended for human consumption.  User space
+	programs should not have any expections about this property.
+
+	The DTB number in this property is incremented each time a make that
+	creates one or more DTBs is invoked.  If the make creates multiple
+	DTBs then this number is only incremented once.
+
+	The DTB number is stored in file .version_dtb.
+
+version-linux
+	The version of the linux kernel most recently built in the source
+	control system that contains the source used to build the DTB.
+
+	The linux kernel version number is not incremented for a make that
+	creates a DTB.
+
+dtb-path
+	The build directory relative path of the DTB.
+
+dts-path
+	The absolute path of the .dts file compiled to create the DTB.
+
+
 Properties documented in other bindings
 ---------------------------------------
 #address-cells                          video/simple-framebuffer-sunxi.txt

From: Frank Rowand <[email protected]>

Create a .dtsi file to contain the /chosen/dtb-info node and populate the properties in that node.

Signed-off-by Frank Rowand <[email protected]>

---
 arch/arm/boot/dts/skeleton.dtsi              |    2 
 include/dt-bindings/version.dtsi             |   19 +++++

Index: b/include/dt-bindings/version.dtsi
===================================================================

include/dt-bindings/version.dtsi new file +9 -0

@@ -0,0 +1,19 @@
+
+#include <utsrelease.h>
+#include <compile.h>
+#include <compile_dtb.h>
+
+/ {
+	chosen {
+		dtb-info {
+			version = UTS_RELEASE, " ", DTB_VERSION;

Rob,

Can this be added to the next trees to get some test exposure before submitting to Linus?

There is currently no way to tie a device tree blob (DTB) back to the source and environment used to create it. Add this information, including a DTB version number, which is somewhat analogous to the Linux kernel version number.

The DTB version number is independent of the kernel version number, and is incremented for each make of one or more DTBs.

The DTB information is placed in node /chosen/dtb-info. The data for this node will be automatically generated by the .dtb make system for any .dts that includes arch/arm/boot/dts/skeleton.dtsi, either directly or indirectly. This means that architectures other than arm will not receive this feature. This can be added to other architectures by modifying their skeleton.dtsi.

There are 70 of the 557 arm .dts files that do not include skeleton.dtsi. Thus the .dtb files created for these systems will not have the /chosen/dtb-info node:

   armada-xp-axpwifiap.dts
   armada-xp-db.dts
   armada-xp-gp.dts
   armada-xp-lenovo-ix4-300d.dts
   armada-xp-matrix.dts
   armada-xp-netgear-rn2120.dts
   armada-xp-openblocks-ax3-4.dts
   armada-xp-synology-ds414.dts
   atlas6-evb.dts
   atlas7-evb.dts
   axm5516-amarillo.dts
   bcm2835-rpi-b-plus.dts
   bcm2835-rpi-b.dts
   ea3250.dts
   ecx-2000.dts
   highbank.dts
   hip04-d01.dts
   integratorap.dts
   integratorcp.dts
   ls1021a-qds.dts
   ls1021a-twr.dts
   meson6-atv1200.dts
   moxart-uc7112lx.dts
   mt8127-moose.dts
   mt8135-evbp1.dts
   nspire-clp.dts
   nspire-cx.dts
   nspire-tp.dts
   phy3250.dts
   picoxcell-pc7302-pc3x2.dts
   picoxcell-pc7302-pc3x3.dts
   prima2-evb.dts
   r7s72100-genmai.dts
   r8a73a4-ape6evm-reference.dts
   r8a73a4-ape6evm.dts
   r8a7790-lager.dts
   r8a7791-henninger.dts
   r8a7791-koelsch.dts
   r8a7794-alt.dts
   spear1310-evb.dts
   spear1340-evb.dts
   spear300-evb.dts
   spear310-evb.dts
   spear320-evb.dts
   spear320-hmi.dts
   spear600-evb.dts
   stih407-b2120.dts
   stih410-b2120.dts
   stih415-b2000.dts
   stih415-b2020.dts
   stih416-b2000.dts
   stih416-b2020.dts
   stih416-b2020e.dts
   stih418-b2199.dts
   sun9i-a80-optimus.dts
   vexpress-v2p-ca15-tc1.dts
   vexpress-v2p-ca15_a7.dts
   vexpress-v2p-ca5s.dts
   vexpress-v2p-ca9.dts
   vt8500-bv07.dts
   wm8505-ref.dts
   wm8650-mid.dts
   wm8750-apc8750.dts
   wm8850-w70v2.dts
   xenvm-4.2.dts
   zynq-parallella.dts
   zynq-zc702.dts
   zynq-zc706.dts
   zynq-zed.dts
   zynq-zybo.dts

An example of the DTB information reported is:

  $ echo ; cat /proc/version; echo ; echo ; dmesg | grep DTB

Linux version 4.0.0-rc4-dirty (frank at buildhost) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #5 SMP PREEMPT Wed Mar 18 20:04:48 PDT 2015

DTB version 4.0.0-rc4-dirty (frank at buildhost) (DTC 1.4.0-dirty) #4 Wed Mar 18 20:04:11 PDT 2015
DTB linux version 4.0.0-rc4-dirty (frank at build_host) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #3 SMP PREEMPT Wed Mar 18 20:02:46 PDT 2015 DTB source /local/nobackup/src/git_linus/linux--4.0/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
DTB blob arch/arm/boot/dts/qcom-apq8074-dragonboard.dtb

The values of the /chosen/dtb-info/ properties are also available in /proc/device-tree/chosen/dtb-info/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi,

Quoted 18 lines · Frank Rowand

Rob,

Can this be added to the next trees to get some test exposure before submitting to Linus?

There is currently no way to tie a device tree blob (DTB) back to the source and environment used to create it. Add this information, including a DTB version number, which is somewhat analogous to the Linux kernel version number.

The DTB version number is independent of the kernel version number, and is incremented for each make of one or more DTBs.

The DTB information is placed in node /chosen/dtb-info. The data for this node will be automatically generated by the .dtb make system for any .dts that includes arch/arm/boot/dts/skeleton.dtsi, either directly or indirectly. This means that architectures other than arm will not receive this feature. This can be added to other architectures by modifying their skeleton.dtsi.

Quoted 3 lines

There are 70 of the 557 arm .dts files that do not include skeleton.dtsi. Thus the .dtb files created for these systems will not have the /chosen/dtb-info node:

About the following list some of them use skeleton64.dtsi instead of skeleton.dtsi. All the armada-xp-*.dts uses it and also axm5516-amarillo.dts (through axm55xx.dtsi), the ls1021a-*.dts, the mt8127-moose.dts, the mt8135-evbp1.dts and the sun9i-a80-optimus.dts.

So maybe it would worth updating skeleton64.dtsi.

For the other ones it seems that actually they use skeleton.dtsi but not through a dtsi file.

Thanks,

Gregory

Quoted 94 lines

   armada-xp-axpwifiap.dts
   armada-xp-db.dts
   armada-xp-gp.dts
   armada-xp-lenovo-ix4-300d.dts
   armada-xp-matrix.dts
   armada-xp-netgear-rn2120.dts
   armada-xp-openblocks-ax3-4.dts
   armada-xp-synology-ds414.dts
   atlas6-evb.dts
   atlas7-evb.dts
   axm5516-amarillo.dts
   bcm2835-rpi-b-plus.dts
   bcm2835-rpi-b.dts
   ea3250.dts
   ecx-2000.dts
   highbank.dts
   hip04-d01.dts
   integratorap.dts
   integratorcp.dts
   ls1021a-qds.dts
   ls1021a-twr.dts
   meson6-atv1200.dts
   moxart-uc7112lx.dts
   mt8127-moose.dts
   mt8135-evbp1.dts
   nspire-clp.dts
   nspire-cx.dts
   nspire-tp.dts
   phy3250.dts
   picoxcell-pc7302-pc3x2.dts
   picoxcell-pc7302-pc3x3.dts
   prima2-evb.dts
   r7s72100-genmai.dts
   r8a73a4-ape6evm-reference.dts
   r8a73a4-ape6evm.dts
   r8a7790-lager.dts
   r8a7791-henninger.dts
   r8a7791-koelsch.dts
   r8a7794-alt.dts
   spear1310-evb.dts
   spear1340-evb.dts
   spear300-evb.dts
   spear310-evb.dts
   spear320-evb.dts
   spear320-hmi.dts
   spear600-evb.dts
   stih407-b2120.dts
   stih410-b2120.dts
   stih415-b2000.dts
   stih415-b2020.dts
   stih416-b2000.dts
   stih416-b2020.dts
   stih416-b2020e.dts
   stih418-b2199.dts
   sun9i-a80-optimus.dts
   vexpress-v2p-ca15-tc1.dts
   vexpress-v2p-ca15_a7.dts
   vexpress-v2p-ca5s.dts
   vexpress-v2p-ca9.dts
   vt8500-bv07.dts
   wm8505-ref.dts
   wm8650-mid.dts
   wm8750-apc8750.dts
   wm8850-w70v2.dts
   xenvm-4.2.dts
   zynq-parallella.dts
   zynq-zc702.dts
   zynq-zc706.dts
   zynq-zed.dts
   zynq-zybo.dts

An example of the DTB information reported is:

  $ echo ; cat /proc/version; echo ; echo ; dmesg | grep DTB

Linux version 4.0.0-rc4-dirty (frank at buildhost) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #5 SMP PREEMPT Wed Mar 18 20:04:48 PDT 2015

DTB version 4.0.0-rc4-dirty (frank at buildhost) (DTC 1.4.0-dirty) #4 Wed Mar 18 20:04:11 PDT 2015
DTB linux version 4.0.0-rc4-dirty (frank at build_host) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #3 SMP PREEMPT Wed Mar 18 20:02:46 PDT 2015 DTB source /local/nobackup/src/git_linus/linux--4.0/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
DTB blob arch/arm/boot/dts/qcom-apq8074-dragonboard.dtb

The values of the /chosen/dtb-info/ properties are also available in /proc/device-tree/chosen/dtb-info/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Rob,

Can this be added to the next trees to get some test exposure before submitting to Linus?

There is currently no way to tie a device tree blob (DTB) back to the source and environment used to create it. Add this information, including a DTB version number, which is somewhat analogous to the Linux kernel version number.

The DTB version number is independent of the kernel version number, and is incremented for each make of one or more DTBs.

The DTB information is placed in node /chosen/dtb-info. The data for this node will be automatically generated by the .dtb make system for any .dts that includes arch/arm/boot/dts/skeleton.dtsi, either directly or indirectly. This means that architectures other than arm will not receive this feature. This can be added to other architectures by modifying their skeleton.dtsi.

There are 70 of the 557 arm .dts files that do not include skeleton.dtsi. Thus the .dtb files created for these systems will not have the /chosen/dtb-info node:

Quoted 2 lines · Frank Rowand

Can this be added to the next trees to get some test exposure before submitting to Linus?

No. I've yet to see anyone think this is a good idea.