[patch 0/7] dt: dtb version: add version info to dtb

[patch 0/7] dt: dtb version: add version info to dtb

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

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@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@buildhost) (DTC 1.4.0-dirty) #4 Wed Mar 18 20:04:11 PDT 2015
  DTB linux version 4.0.0-rc4-dirty (frank@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/

[patch 1/7] dt: dtb version: consolidate documentation of chosen node bindings

[Frank Rowand]

From: Frank Rowand <frank.rowand@sonymobile.com>

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 <frank.rowand@sonymobile.com>
---
 Documentation/devicetree/bindings/chosen.txt |   31 +++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

Index: b/Documentation/devicetree/bindings/chosen.txt
===================================================================
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -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
+
+interrupt-controller (obsolete)         booting-without-of.txt
+
+linux,pci-probe-only                    pci/host-generic-pci.txt
+
+linux,stdout-path                       booting-without-of.txt
+
+ranges                                  video/simple-framebuffer-sunxi.txt
+
+stdout-path                             video/simple-framebuffer.txt
+
+
+Nodes documented in other bindings
+----------------------------------
+framebuffer                             video/simple-framebuffer.txt
+                                        video/simple-framebuffer-sunxi.txt
+
+linux,sysrq-reset-seq                   input/input-reset.txt

[patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Frank Rowand]

From: Frank Rowand <frank.rowand@sonymobile.com>

Add /chosen/dtb-node binding.

Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
---
 Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++

Index: b/Documentation/devicetree/bindings/chosen.txt
===================================================================
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -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.
+
+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

[patch 3/7] dt: dtb version: arm dts Makefile

[Frank Rowand]

From: Frank Rowand <frank.rowand@sonymobile.com>

Remove generated files from the dependencies of .dtb files, where the
generated files are created as a result of making a .dtb.

Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
---
 arch/arm/boot/dts/Makefile                   |   10 +++

Index: b/arch/arm/boot/dts/Makefile
===================================================================
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -650,5 +650,15 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
 	mt8135-evbp1.dtb
 endif
 
+# These files are generated by a kernel make if .version has changed.
+# Do not allow them to act as a dependency for rebuilding a .dtb that
+# has included dt-bindings/version.dtsi.
+PHONY += include/generated/compile.h include/generated/utsrelease.h
+
+# This file is generated by a .dtb make if .version_dtb has changed.
+# Do not allow it to act as a dependency for rebuilding a .dtb that
+# has included dt-bindings/version.dtsi.
+PHONY += include/generated/compile_dtb.h
+
 always		:= $(dtb-y)
 clean-files	:= *.dtb

[patch 4/7] dt: dtb version: kernel Makefile

[Frank Rowand]

From: Frank Rowand <frank.rowand@sonymobile.com>

Capture the initial value of .version_dtb so that when multiple .dtb files are
created in a single make the make scripts will be able to increment
.version_dtb only once instead of for each .dtb.

Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
---
 Makefile                                     |    4 +

Index: b/Makefile
===================================================================
--- a/Makefile
+++ b/Makefile
@@ -416,6 +416,9 @@ KBUILD_LDFLAGS_MODULE := -T $(srctree)/s
 KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
 KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
 
+VERSION_DTB_BASE := $(shell cat .version_dtb 2> /dev/null)
+
+export VERSION_DTB_BASE
 export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
 export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
 export CPP AR NM STRIP OBJCOPY OBJDUMP
@@ -1181,6 +1184,7 @@ CLEAN_DIRS  += $(MODVERDIR)
 MRPROPER_DIRS  += include/config usr/include include/generated          \
 		  arch/*/include/generated .tmp_objdiff
 MRPROPER_FILES += .config .config.old .version .old_version \
+		  .version_dtb .version_dtb_flock \
 		  Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
 		  signing_key.priv signing_key.x509 x509.genkey		\
 		  extra_certificates signing_key.x509.keyid		\

[patch 5/7] dt: dtb version: kbuild scripts

[Frank Rowand]

From: Frank Rowand <frank.rowand@sonymobile.com>

After applying this patch, need to add execute permission to the new file
scripts/version_dtb_increment_once

Modify the dtb compile rules to generate dtb version header files.

Create script to increment .version_dtb just once per make of one of more
dtbs, and to generate the dtb version header files.

Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
---
 scripts/Makefile.lib                         |   20 ++++--
 scripts/version_dtb_increment_once           |   90 +++++++++++++++++++++++++++

Index: b/scripts/Makefile.lib
===================================================================
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -159,11 +159,19 @@ cpp_flags      = -Wp,-MD,$(depfile) $(NO
 
 ld_flags       = $(LDFLAGS) $(ldflags-y)
 
+# Do not want to pull kernel header files into .dtb, so minimize the risk of
+# that by adding include/generated/ to include path instead of include/
+# Headers in include/generated/ are used by include/dt-bindings/version.dtsi
 dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc                    \
 		 -I$(srctree)/arch/$(SRCARCH)/boot/dts                   \
 		 -I$(srctree)/arch/$(SRCARCH)/boot/dts/include           \
 		 -I$(srctree)/drivers/of/testcase-data                   \
-		 -undef -D__DTS__
+		 -Iinclude/generated                                     \
+		 -undef -D__DTS__                                        \
+		 -D___DTB_DTB_PATH="\"$@\""                              \
+		 -D___DTB_DTS_PATH="\"$<\""                              \
+		 -D"___DTB_DTC_VERSION=\"$(shell scripts/dtc/dtc -v | cut -d" " -f2-)\""
+
 
 # Finds the multi-part object the current object will be linked into
 modname-multi = $(sort $(foreach m,$(multi-used),\
@@ -282,10 +290,12 @@ $(obj)/%.dtb.S: $(obj)/%.dtb
 	$(call cmd,dt_S_dtb)
 
 quiet_cmd_dtc = DTC     $@
-cmd_dtc = $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
-	$(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 \
-		-i $(dir $<) $(DTC_FLAGS) \
-		-d $(depfile).dtc.tmp $(dtc-tmp) ; \
+cmd_dtc =                                                                  \
+	$(srctree)/scripts/version_dtb_increment_once ;                    \
+	$(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ;   \
+	$(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0                       \
+		-i $(dir $<) $(DTC_FLAGS)                                  \
+		-d $(depfile).dtc.tmp $(dtc-tmp) ;                         \
 	cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
 
 $(obj)/%.dtb: $(src)/%.dts FORCE
Index: b/scripts/version_dtb_increment_once
===================================================================
--- /dev/null
+++ b/scripts/version_dtb_increment_once
@@ -0,0 +1,90 @@
+#!/bin/sh
+
+# increment .version_dtb at most once per build
+
+# VERSION_DTB_BASE is exported instead of passed to this script as an arg.
+#
+# If the value is passed as an arg then the make dependency triggers on
+# every build of a .dtb because if_changed_dep detects that cmd_dtc has
+# changed since the previous build (see scripts/Makefile.lib).
+
+# Nice output in kbuild format
+# Will be supressed by "make -s"
+info()
+{
+	if [ "${quiet}" != "silent_" ]; then
+		printf "  %-7s %s\n" ${1} ${2}
+	fi
+}
+
+
+# flock(1) to avoid race in parallel build
+(flock 9
+
+	if [ ! -r .version_dtb -o ! -s .version_dtb ] ; then
+		rm -f .version_dtb
+		touch .version_dtb
+	fi
+
+	VERSION_DTB=`cat .version_dtb`
+	if [ "${VERSION_DTB}" != "${VERSION_DTB_BASE}" ] ; then
+		exit
+	fi
+
+	info GEN .version_dtb
+
+	VERSION_DTB=`expr 0${VERSION_DTB} + 1`
+	echo ${VERSION_DTB} > .version_dtb
+
+	# Do not expand names
+	set -f
+
+	# Fix the language to get consistent output
+	LC_ALL=C
+	export LC_ALL
+
+	if [ -z "$KBUILD_BUILD_TIMESTAMP" ]; then
+		TIMESTAMP=`date`
+	else
+		TIMESTAMP=$KBUILD_BUILD_TIMESTAMP
+	fi
+	if test -z "$KBUILD_BUILD_USER"; then
+		COMPILE_BY=$(whoami | sed 's/\\/\\\\/')
+	else
+		COMPILE_BY=$KBUILD_BUILD_USER
+	fi
+	if test -z "$KBUILD_BUILD_HOST"; then
+		COMPILE_HOST=`hostname`
+	else
+		COMPILE_HOST=$KBUILD_BUILD_HOST
+	fi
+
+	DTB_COMPILER=`scripts/dtc/dtc -v | cut -d" " -f2-`
+
+	VERSION="UTS_RELEASE (${COMPILE_BY}@${COMPILE_HOST}) (${DTB_COMPILER}) #${VERSION_DTB} ${TIMESTAMP}"
+
+	# truncate to get same result as scripts/mkcompile_h
+	UTS_LEN=64
+	TRUNCATE="cut -b -$UTS_LEN"
+
+
+	# Generate compile_dtb.h
+	TARGET=include/generated/compile_dtb.h
+	info UPD $TARGET
+
+	( echo /\* This file is auto generated, version ${VERSION_DTB} \*/
+
+  	echo -n \#define DTB_VERSION  \"\(
+  	echo -n `echo ${COMPILE_BY} | $TRUNCATE`
+  	echo -n @
+  	echo -n `echo ${COMPILE_HOST} | $TRUNCATE`
+  	echo -n \) \(${DTB_COMPILER}\) \#${VERSION_DTB} ${TIMESTAMP}
+  	echo    \"
+
+	) > $TARGET
+
+
+) 9> .version_dtb_flock
+
+# Do not place anything here.  Exit from inside flock(1) will come here
+# instead of exiting script.

[patch 6/7] dt: dtb version: dtsi files

[Frank Rowand]

From: Frank Rowand <frank.rowand@sonymobile.com>

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

Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
---
 arch/arm/boot/dts/skeleton.dtsi              |    2 
 include/dt-bindings/version.dtsi             |   19 +++++

Index: b/include/dt-bindings/version.dtsi
===================================================================
--- /dev/null
+++ b/include/dt-bindings/version.dtsi
@@ -0,0 +1,19 @@
+
+#include <utsrelease.h>
+#include <compile.h>
+#include <compile_dtb.h>
+
+/ {
+	chosen {
+		dtb-info {
+			version = UTS_RELEASE, " ", DTB_VERSION;
+			version-linux =
+				UTS_RELEASE,
+				" (", LINUX_COMPILE_BY, "@", LINUX_COMPILE_HOST, ") ",
+				"(", LINUX_COMPILER, ") ",
+				UTS_VERSION;
+			dtb-path = ___DTB_DTB_PATH;
+			dts-path = ___DTB_DTS_PATH;
+		};
+	};
+};
Index: b/arch/arm/boot/dts/skeleton.dtsi
===================================================================
--- a/arch/arm/boot/dts/skeleton.dtsi
+++ b/arch/arm/boot/dts/skeleton.dtsi
@@ -11,3 +11,5 @@
 	aliases { };
 	memory { device_type = "memory"; reg = <0 0>; };
 };
+
+#include <dt-bindings/version.dtsi>

[patch 7/7] dt: dtb version: report dtb info

[Frank Rowand]

From: Frank Rowand <frank.rowand@sonymobile.com>

Report the /chosen/dtb-info properties on boot.

Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
---

The beginning of the context for hunk 2 includes a line from
2fa645cb2703d9b3786d850db815414dfeefa51d, which is in 4.0-rc4.  The
author of that commit has submitted a request to revert the commit:
http://lkml.iu.edu/hypermail/linux/kernel/1503.2/02134.html


 drivers/of/base.c |   42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

Index: b/drivers/of/base.c
===================================================================
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1880,6 +1880,7 @@ static void of_alias_add(struct alias_pr
 void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
 {
 	struct property *pp;
+	struct device_node *dtb_info = NULL;
 
 	of_aliases = of_find_node_by_path("/aliases");
 	of_chosen = of_find_node_by_path("/chosen");
@@ -1899,6 +1900,47 @@ void of_alias_scan(void * (*dt_alloc)(u6
 		}
 	}
 
+	dtb_info = of_find_node_by_path("/chosen/dtb-info");
+	if (dtb_info == NULL)
+		dtb_info = of_find_node_by_path("/chosen@0/dtb-info");
+
+	if (dtb_info) {
+		const char *string;
+		int len;
+
+		string = of_get_property(dtb_info, "version", &len);
+		if (string) {
+			pr_notice("DTB version ");
+			for ( ; len > 0;
+				len -= (strlen(string) + 1),
+				string += (strlen(string) + 1)) {
+				pr_cont("%s", string);
+			}
+			pr_cont("\n");
+		}
+
+		string = of_get_property(dtb_info, "version-linux", &len);
+		if (string) {
+			pr_notice("DTB linux version ");
+			for ( ; len > 0;
+				len -= (strlen(string) + 1),
+				string += (strlen(string) + 1)) {
+				pr_cont("%s", string);
+			}
+			pr_cont("\n");
+		}
+
+		string = of_get_property(dtb_info, "dts-path", &len);
+		if (string)
+			pr_notice("DTB source %s\n", string);
+
+		string = of_get_property(dtb_info, "dtb-path", &len);
+		if (string)
+			pr_notice("DTB blob %s\n", string);
+
+		of_node_put(dtb_info);
+	}
+
 	if (!of_aliases)
 		return;
 

Re: [patch 0/7] dt: dtb version: add version info to dtb

[Gregory CLEMENT]

Hi,

On 19/03/2015 04:29, Frank Rowand wrote:
> 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:

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


> 
>    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@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@buildhost) (DTC 1.4.0-dirty) #4 Wed Mar 18 20:04:11 PDT 2015
>   DTB linux version 4.0.0-rc4-dirty (frank@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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Rob Herring]

On Wed, Mar 18, 2015 at 10:33 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> From: Frank Rowand <frank.rowand@sonymobile.com>
>
> Add /chosen/dtb-node binding.

Why? Please write better commit messages.

>
> Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
> ---
>  Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++
>
> Index: b/Documentation/devicetree/bindings/chosen.txt
> ===================================================================
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -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.
> +
> +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

Re: [patch 1/7] dt: dtb version: consolidate documentation of chosen node bindings

[Mark Rutland]

On Thu, Mar 19, 2015 at 03:31:50AM +0000, Frank Rowand wrote:
> From: Frank Rowand <frank.rowand@sonymobile.com>
> 
> 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 <frank.rowand@sonymobile.com>
> ---
>  Documentation/devicetree/bindings/chosen.txt |   31 +++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 
> Index: b/Documentation/devicetree/bindings/chosen.txt
> ===================================================================
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -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
> +
> +interrupt-controller (obsolete)         booting-without-of.txt
> +
> +linux,pci-probe-only                    pci/host-generic-pci.txt
> +
> +linux,stdout-path                       booting-without-of.txt
> +
> +ranges                                  video/simple-framebuffer-sunxi.txt
> +
> +stdout-path                             video/simple-framebuffer.txt

The usual form of stdout-path is documented immediately above this
section. That should probably be updated to refer to the
video/simple-framebuffer.txt case.

Mark.

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Mark Rutland]

On Thu, Mar 19, 2015 at 03:33:22AM +0000, Frank Rowand wrote:
> From: Frank Rowand <frank.rowand@sonymobile.com>
> 
> 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?

> Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
> ---
>  Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++
> 
> Index: b/Documentation/devicetree/bindings/chosen.txt
> ===================================================================
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -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.

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

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

> +
> +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?

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

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Frank Rowand]

On 3/19/2015 6:23 AM, Rob Herring wrote:
> On Wed, Mar 18, 2015 at 10:33 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> From: Frank Rowand <frank.rowand@sonymobile.com>
>>
>> Add /chosen/dtb-node binding.
> 
> Why? Please write better commit messages.

Will update.

> 
>>
>> Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
>> ---
>>  Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++
>>
>> Index: b/Documentation/devicetree/bindings/chosen.txt
>> ===================================================================
>> --- a/Documentation/devicetree/bindings/chosen.txt
>> +++ b/Documentation/devicetree/bindings/chosen.txt
>> @@ -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.
>> +
>> +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?

Nope.  This is describing where the dtb and the dts were on the build host
when the dtb was built.  The computer where the dtb is currently located
when this information is useful (on the "target") is probably not even the
same computer the dtb was built on.

Mark Rutland asks a lot more questions about this
so I'll answer some more in reply to his comments.

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

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Frank Rowand]

On 3/19/2015 6:49 AM, Mark Rutland wrote:
> On Thu, Mar 19, 2015 at 03:33:22AM +0000, Frank Rowand wrote:
>> From: Frank Rowand <frank.rowand@sonymobile.com>
>>
>> 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?

Will update and add better information.

> 
>> Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
>> ---
>>  Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++
>>
>> Index: b/Documentation/devicetree/bindings/chosen.txt
>> ===================================================================
>> --- a/Documentation/devicetree/bindings/chosen.txt
>> +++ b/Documentation/devicetree/bindings/chosen.txt
>> @@ -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.
> 
> I doubt that this would stay the case for long were this property added.
> 
>> +	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.

OK, I'll remove the reference to .version_dtb.

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

So I would encourage a slightly unusual mind set when reviewing this
binding (not that I really know what that mind set is!).

The answer to the specific question of why add a "not well-defined"
binding is the same answer as to why have a kernel version string.
There was a proposal to remove the kernel version string and that
was quickly dropped.

I should have written more about why this is useful.

This binding provides the provenance of the DTB.  What source (and
version of the source) and version of the compiler (dtc) was used
to make the DTB.

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.

> 
>> +
>> +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?

I will make the name more generic.

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

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

> 
> Why would you _ever_ need an absolute path!?

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

> 
> Mark.
> 

Re: [patch 0/7] dt: dtb version: add version info to dtb

[Frank Rowand]

On 3/19/2015 1:12 AM, Gregory CLEMENT wrote:
> Hi,
> 
> On 19/03/2015 04:29, Frank Rowand wrote:
>> 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:
> 
> 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.

Thanks for noticing that!  I'll add skeleton64.dtsi.

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

I'll go check again.


> 
> Thanks,
> 
> Gregory
> 
> 
>>
>>    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@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@buildhost) (DTC 1.4.0-dirty) #4 Wed Mar 18 20:04:11 PDT 2015
>>   DTB linux version 4.0.0-rc4-dirty (frank@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@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Geert Uytterhoeven]

On Thu, Mar 19, 2015 at 6:02 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> Why would you _ever_ need an absolute path!?
>
> The absolute path tells you which source repository contained the source.

Really? Usually it's just gonna be <something>/linux-2.6...

IMHO it leaks information (the <something>) you don't want to be in final
build, like login names and file server names.
We already have way to many uses of __FILE__ in the kernel source tree.
Unfortunately there's no replacement macro with just the relative path,
against the topdir of the source tree.

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Frank Rowand]

On 3/18/2015 8:33 PM, Frank Rowand wrote:
> From: Frank Rowand <frank.rowand@sonymobile.com>
> 
> Add /chosen/dtb-node binding.
> 
> Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
> ---
>  Documentation/devicetree/bindings/chosen.txt |   37 +++++++++++
> 
> Index: b/Documentation/devicetree/bindings/chosen.txt
> ===================================================================
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -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.

I left out optional vs required.  The next version will state that the dtb-info
node and each separate property within it are optional.

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

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Russell King - ARM Linux]

On Thu, Mar 19, 2015 at 08:23:29AM -0500, Rob Herring wrote:
> On Wed, Mar 18, 2015 at 10:33 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> > +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.
> 
> 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.

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.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [patch 6/7] dt: dtb version: dtsi files

[Sascha Hauer]

On Wed, Mar 18, 2015 at 08:39:37PM -0700, Frank Rowand wrote:
> From: Frank Rowand <frank.rowand@sonymobile.com>
> 
> Create a .dtsi file to contain the /chosen/dtb-info node and populate the
> properties in that node.
> 
> Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
> ---
>  arch/arm/boot/dts/skeleton.dtsi              |    2 
>  include/dt-bindings/version.dtsi             |   19 +++++
> 
> Index: b/include/dt-bindings/version.dtsi
> ===================================================================
> --- /dev/null
> +++ b/include/dt-bindings/version.dtsi
> @@ -0,0 +1,19 @@
> +
> +#include <utsrelease.h>
> +#include <compile.h>
> +#include <compile_dtb.h>
> +
> +/ {
> +	chosen {
> +		dtb-info {
> +			version = UTS_RELEASE, " ", DTB_VERSION;
> +			version-linux =
> +				UTS_RELEASE,
> +				" (", LINUX_COMPILE_BY, "@", LINUX_COMPILE_HOST, ") ",
> +				"(", LINUX_COMPILER, ") ",
> +				UTS_VERSION;
> +			dtb-path = ___DTB_DTB_PATH;
> +			dts-path = ___DTB_DTS_PATH;
> +		};
> +	};
> +};

People are working on reproducible builds to be able to build bit
identical packages for a whole Distribution [1]. While I don't know
how feasible this really is I think we should not actively work on making
that impossible. The people working on reproducible builds state that
timestamps in binaries are bad, because when you can reproduce it it
doesn't matter if it was build yesterday or a decade ago.

Like others already said for security reasons (and also for
reproducibility) I don't want to leak the pathes or machine names I use to
build dtbs into the binaries.

So all this should at least be configurable.

Sascha

[1] https://wiki.debian.org/ReproducibleBuilds

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Mark Rutland]

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

Agreed.

Having debugged issues with bad DTBs in the past without having this
information, I don't see it as being majorly helpful -- the DTB is
relatively simple and can be decompiled.

You don't gain much from being able to read which file it was built from
on a random server you don't have access to, and if you do have access
to the source it's relatively easy to discover the file it was built
from.

So unless there's a really compelling case for this, I don't see the
point in having it.

Mark.

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Frank Rowand]

On 3/19/2015 11:41 AM, Russell King - ARM Linux wrote:
> On Thu, Mar 19, 2015 at 08:23:29AM -0500, Rob Herring wrote:
>> On Wed, Mar 18, 2015 at 10:33 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>>> +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.
>>
>> 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.
> 
> 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.

As I failed to properly document, but have said will be in the next
version, the dtb-info node and all of the properties are optional.

As I replied to Mark, I will change version-linux to a more generic
name and meaning in the next version.  The property could be missing,
it could be about BSD, it could be about uboot.  Whatever.

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

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 could be creating some confusion here though.  The dtb version string
also includes the current commit of the source code repository, in
exactly the same manner as the kernel version string does.

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

Would it be more palatable if including the dtb-info node was conditional
on some debug config option?


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

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Mark Rutland]

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

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

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

[...]

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

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.

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

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Russell King - ARM Linux]

On Thu, Mar 19, 2015 at 12:01:42PM -0700, Frank Rowand wrote:
> 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.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Frank Rowand]

On 3/19/2015 12:32 PM, Russell King - ARM Linux wrote:
> On Thu, Mar 19, 2015 at 12:01:42PM -0700, Frank Rowand wrote:
>> 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 am aware of that and totally agree that it is on point.

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

And I totally agree with that.

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

No argument.  But I am not arguing for that.

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

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Frank Rowand]

On 3/19/2015 12:12 PM, Mark Rutland wrote:
>>> 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.
> 
>> 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.

Consider substituting the Linux kernel for the DTB and make the same
statement to see if that sounds like a concern.

Then consider that in many cases a DTB could come from a Linux or
Android distribution, just like many Linux kernels do.  My understanding
is that the sources in the kernel tree used to make DTBs are gpl v2
and thus just as available as the source to a Linux kernel would be.

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

Yes, there are circumstances where I might find that the best way to
work on a problem.  I also often use debuggers to show me an assembly
display when debugging a kernel problem.  But I sometimes prefer to
start at the source code level.

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

Yes, bootloaders can cause issues.  This patch set is not intended to
deal with those problems.

btw, thank you for the references, concrete examples help a lot (and
they are interesting examples)!

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

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

> 
> [...]
> 
>>>> +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.
> 
> 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.

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

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

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

Re: [patch 0/7] dt: dtb version: add version info to dtb

[Rob Herring]

On Wed, Mar 18, 2015 at 10:29 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> Rob,
>
> 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.

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

Actually, we really want to get rid of skeleton.dtsi. At least the
memory node because it obscures whether the memory node is correct or
not. Then if there is no memory node, there is not much point to it.

Rob

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Mark Rutland]

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

The problem that Russell is describing is that regardless of the origin
and intended purpose of the value, some consumer of the value will
decide that some arbitrary value means something special to them (even
if it does not), and when this changes thigns will break.

So in that respect, it doesn't matter where the value came from or what
you intend it to mean; it will almost certainly be abused. We try to
avoid introducing fragile interfaces like these.

Mark.

Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding

[Mark Rutland]

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

This is a fundamental issue with the approach: if bootloaders  mess with
the DTB, then the provenance information is at best misleading.

If bootloaders don't mess with the DTB, then a hash gives you reliable
provenance information, provided you have a DB of the hashes of DTBs
you've shipped. If you're already in the habit of distributing binaries
that should be fine, and if you're not then it presumably doesn't matter
anyway.

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

Consider having to work around stale object issues in the build system
with git clean -fdx or similar. While unfortunate, this is sometimes
necessary. Due to this, I build two different DTBs with exactly the same
"version".

If you need to tell these apart, you can do that by hash. You don't need
the "version" to do so.

(and yes, I am aware that the same is true of the kernel).

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

Given the reservations that have been expressed so far, it sounds like
the set of negative use cases is larger than the set of positives.

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

I very much suspect it will end up being the latter. For example I've
seen various iterations of certain FW ship with all-zero ID numbers, for
which the use-cases of said ID numbers are exactly those you mention
above.

As far as I can see, the only consistent and sane way to identify a
binary object is by its hash, which for obvious reasons cannot be
encoded within itself (though can be computed consistently).

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

That being the case you don't care about the fields; we've established
that they're meaningless to the end user.

Were I to have distributed files to you, I would have archived the
relevant build (with source, config, and so on). I can look up what I've
distributed to you and hand you the source without needing additional
properties in the DTB.

Mark.

Re: [patch 0/7] dt: dtb version: add version info to dtb

[Uwe Kleine-König]

Hello,

On Fri, Mar 20, 2015 at 08:46:09AM -0500, Rob Herring wrote:
> On Wed, Mar 18, 2015 at 10:29 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> > 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.
To push the balance a bit into the IMHO right direction: I think the
version info is a bad idea and fully agree with Russell's concerns.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |