archive mirror
 help / color / mirror / Atom feed
From: (Mark Rutland)
Subject: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding
Date: Thu, 19 Mar 2015 19:12:31 +0000	[thread overview]
Message-ID: <20150319191231.GC11683@leverpostej> (raw)
In-Reply-To: <>

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



  parent reply	other threads:[~2015-03-19 19:12 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19  3:29 [patch 0/7] dt: dtb version: add version info to dtb Frank Rowand
2015-03-19  3:31 ` [patch 1/7] dt: dtb version: consolidate documentation of chosen node bindings Frank Rowand
2015-03-19 13:40   ` Mark Rutland
2015-03-19  3:33 ` [patch 2/7] dt: dtb version: document chosen/dtb-info node binding Frank Rowand
2015-03-19 13:23   ` Rob Herring
2015-03-19 16:42     ` Frank Rowand
2015-03-19 18:41     ` Russell King - ARM Linux
2015-03-19 18:53       ` Mark Rutland
2015-03-19 19:01       ` Frank Rowand
2015-03-19 19:32         ` Russell King - ARM Linux
2015-03-19 20:44           ` Frank Rowand
2015-03-20 14:42             ` Mark Rutland
2015-03-19 13:49   ` Mark Rutland
2015-03-19 17:02     ` Frank Rowand
2015-03-19 17:23       ` Geert Uytterhoeven
2015-03-19 19:12       ` Mark Rutland [this message]
2015-03-19 21:27         ` Frank Rowand
2015-03-20 15:25           ` Mark Rutland
2015-03-19 17:37   ` Frank Rowand
2015-03-19  3:34 ` [patch 3/7] dt: dtb version: arm dts Makefile Frank Rowand
2015-03-19  3:36 ` [patch 4/7] dt: dtb version: kernel Makefile Frank Rowand
2015-03-19  3:38 ` [patch 5/7] dt: dtb version: kbuild scripts Frank Rowand
2015-03-19  3:39 ` [patch 6/7] dt: dtb version: dtsi files Frank Rowand
2015-03-19 18:46   ` Sascha Hauer
2015-03-19  3:41 ` [patch 7/7] dt: dtb version: report dtb info Frank Rowand
2015-03-19  8:12 ` [patch 0/7] dt: dtb version: add version info to dtb Gregory CLEMENT
2015-03-19 17:05   ` Frank Rowand
2015-03-20 13:46 ` Rob Herring
2015-03-20 19:14   ` Uwe Kleine-König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150319191231.GC11683@leverpostej \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).