[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Jason Cooper]

Consumers of the Linux kernel's build products are beginning to hardcode
the filenames of the dtbs generated.  Since the dtb filenames are
currently the dts filename s/dts/dtb/, this prevents the kernel
community from renaming dts files as needed.

Let's provide a consistent naming structure for consumers to script
against.  Or at least, as consistent as the dts properties themselves.

With this patch, adding the '-L' option to the dtc commandline will
cause dtc to create a symlink to the generated dtb, using the board
compatible string as the filename, eg:

  globalscale,mirabox.dtb -> armada-370-mirabox.dtb

Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
All,

I'm sending this RFC to see if this is how we want to go about this.  If it's
acceptable, I'll resend to the dtc maintainers

thx,

Jason.

 dtc.c      | 12 ++++++++++--
 dtc.h      |  1 +
 flattree.c | 30 ++++++++++++++++++++++++++++++
 srcpos.c   | 20 ++++++++++++++++++--
 srcpos.h   |  2 ++
 5 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/dtc.c b/dtc.c
index e3c96536fd9d..cb2bb1b7ce1f 100644
--- a/dtc.c
+++ b/dtc.c
@@ -49,7 +49,7 @@ static void fill_fullpaths(struct node *tree, const char *prefix)
 
 /* Usage related data. */
 static const char usage_synopsis[] = "dtc [options] <input file>";
-static const char usage_short_opts[] = "qI:O:o:V:d:R:S:p:fb:i:H:sW:E:hv";
+static const char usage_short_opts[] = "qI:O:o:V:d:R:S:p:fb:i:H:sW:E:Lhv";
 static struct option const usage_long_opts[] = {
 	{"quiet",            no_argument, NULL, 'q'},
 	{"in-format",         a_argument, NULL, 'I'},
@@ -67,6 +67,7 @@ static struct option const usage_long_opts[] = {
 	{"phandle",           a_argument, NULL, 'H'},
 	{"warning",           a_argument, NULL, 'W'},
 	{"error",             a_argument, NULL, 'E'},
+	{"sym-link",         no_argument, NULL, 'L'},
 	{"help",             no_argument, NULL, 'h'},
 	{"version",          no_argument, NULL, 'v'},
 	{NULL,               no_argument, NULL, 0x0},
@@ -97,6 +98,7 @@ static const char * const usage_opts_help[] = {
 	 "\t\tboth   - Both \"linux,phandle\" and \"phandle\" properties",
 	"\n\tEnable/disable warnings (prefix with \"no-\")",
 	"\n\tEnable/disable errors (prefix with \"no-\")",
+	"\n\tCreate a symlink to the dtb named by board compatible string",
 	"\n\tPrint this help and exit",
 	"\n\tPrint version and exit",
 	NULL,
@@ -109,7 +111,7 @@ int main(int argc, char *argv[])
 	const char *outform = "dts";
 	const char *outname = "-";
 	const char *depname = NULL;
-	int force = 0, sort = 0;
+	int force = 0, sort = 0, mksymlink = 0;
 	const char *arg;
 	int opt;
 	FILE *outf = NULL;
@@ -184,6 +186,9 @@ int main(int argc, char *argv[])
 		case 'E':
 			parse_checks_option(false, true, optarg);
 			break;
+		case 'L':
+			mksymlink = 1;
+			break;
 
 		case 'h':
 			usage(NULL);
@@ -247,6 +252,9 @@ int main(int argc, char *argv[])
 		dt_to_source(outf, bi);
 	} else if (streq(outform, "dtb")) {
 		dt_to_blob(outf, bi, outversion);
+		if (mksymlink) {
+			dt_to_symlink(bi, outname);
+		}
 	} else if (streq(outform, "asm")) {
 		dt_to_asm(outf, bi, outversion);
 	} else if (streq(outform, "null")) {
diff --git a/dtc.h b/dtc.h
index 264a20cf66a8..0cdb558fead1 100644
--- a/dtc.h
+++ b/dtc.h
@@ -254,6 +254,7 @@ void process_checks(int force, struct boot_info *bi);
 
 void dt_to_blob(FILE *f, struct boot_info *bi, int version);
 void dt_to_asm(FILE *f, struct boot_info *bi, int version);
+void dt_to_symlink(struct boot_info *bi, const char *outname);
 
 struct boot_info *dt_from_blob(const char *fname);
 
diff --git a/flattree.c b/flattree.c
index 665dad7bb465..e1720dec4389 100644
--- a/flattree.c
+++ b/flattree.c
@@ -577,6 +577,36 @@ void dt_to_asm(FILE *f, struct boot_info *bi, int version)
 	data_free(strbuf);
 }
 
+void dt_to_symlink(struct boot_info *bi, const char *outname)
+{
+	struct property *prop;
+	const char *board;
+	int symlen;
+	char *symname;
+	char *dname;
+	char *bname;
+
+	prop = get_property(bi->dt, "compatible");
+	board = prop->val.val;
+
+	symlen = strlen(outname) + prop->val.len;
+	symname = xmalloc(symlen);
+
+	dname = xdirname(outname);
+	bname = xbasename(outname);
+
+	snprintf(symname, symlen, "%s/%s.dtb", dname, board);
+
+	/* create the symlink */
+	if (symlink(bname, symname) == -1) {
+		die("Couldn't create symlink %s: %s\n", symlink, strerror(errno));
+	}
+
+	free(symname);
+	free(dname);
+	free(bname);
+}
+
 struct inbuf {
 	char *base, *limit, *ptr;
 };
diff --git a/srcpos.c b/srcpos.c
index c20bc5315bc1..5f9e032330ea 100644
--- a/srcpos.c
+++ b/srcpos.c
@@ -34,7 +34,7 @@ struct search_path {
 static struct search_path *search_path_head, **search_path_tail;
 
 
-static char *dirname(const char *path)
+char *xdirname(const char *path)
 {
 	const char *slash = strrchr(path, '/');
 
@@ -49,6 +49,22 @@ static char *dirname(const char *path)
 	return NULL;
 }
 
+char *xbasename(const char *path)
+{
+	const char *slash = strrchr(path, '/');
+
+	if (slash) {
+		int len = strlen(path) - (slash - path);
+		char *base = xmalloc(len + 1);
+
+		memcpy(base, slash + 1, len);
+		base[len] = '\0';
+		return base;
+	}
+
+	return NULL;
+}
+
 FILE *depfile; /* = NULL */
 struct srcfile_state *current_srcfile; /* = NULL */
 
@@ -150,7 +166,7 @@ void srcfile_push(const char *fname)
 	srcfile = xmalloc(sizeof(*srcfile));
 
 	srcfile->f = srcfile_relative_open(fname, &srcfile->name);
-	srcfile->dir = dirname(srcfile->name);
+	srcfile->dir = xdirname(srcfile->name);
 	srcfile->prev = current_srcfile;
 
 	srcfile->lineno = 1;
diff --git a/srcpos.h b/srcpos.h
index 93a27123c2e9..a6b6ad308d52 100644
--- a/srcpos.h
+++ b/srcpos.h
@@ -57,6 +57,8 @@ FILE *srcfile_relative_open(const char *fname, char **fullnamep);
 void srcfile_push(const char *fname);
 int srcfile_pop(void);
 
+char *xdirname(const char *path);
+char *xbasename(const char *path);
 /**
  * Add a new directory to the search path for input files
  *
-- 
1.8.4.2

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Stephen Warren]

On 11/11/2013 01:29 PM, Jason Cooper wrote:
> Consumers of the Linux kernel's build products are beginning to hardcode
> the filenames of the dtbs generated.  Since the dtb filenames are
> currently the dts filename s/dts/dtb/, this prevents the kernel
> community from renaming dts files as needed.

My take is that the DTB filenames are part of the ABI, and therefore the
DTS filenames are also part of the ABI. Why would we want to rename them?

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Jason Cooper]

On Mon, Nov 11, 2013 at 02:24:11PM -0700, Stephen Warren wrote:
> On 11/11/2013 01:29 PM, Jason Cooper wrote:
> > Consumers of the Linux kernel's build products are beginning to hardcode
> > the filenames of the dtbs generated.  Since the dtb filenames are
> > currently the dts filename s/dts/dtb/, this prevents the kernel
> > community from renaming dts files as needed.
> 
> My take is that the DTB filenames are part of the ABI, and therefore the
> DTS filenames are also part of the ABI. Why would we want to rename them?

This idea originated from a conversation with Olof about starting to
pre-pend the manufacturer name to the dts files:

  https://lkml.org/lkml/2013/11/8/378

imho, at some point there is going to be an ABI breakage wrt dtb names
when the devicetree moves to a separate repository.  All users will have
to rework their scripts at that point.

If that assumption is correct, why not put in place a _good_ ABI that
allows us to be flexible as needed and specific for end users?  If you're
still with me on this idea, shouldn't we put this in place now (as
symlinks, thus retaining old names) so that we can switch over more
easily later?

thx,

Jason.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Rob Herring]

On Mon, Nov 11, 2013 at 3:24 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/11/2013 01:29 PM, Jason Cooper wrote:
>> Consumers of the Linux kernel's build products are beginning to hardcode
>> the filenames of the dtbs generated.  Since the dtb filenames are
>> currently the dts filename s/dts/dtb/, this prevents the kernel
>> community from renaming dts files as needed.
>
> My take is that the DTB filenames are part of the ABI, and therefore the
> DTS filenames are also part of the ABI. Why would we want to rename them?

I agree with the ABI part, but for long term I think compatible
strings are a better choice for the ABI than filenames. A link
provides for a way to transition.

Whether a platform can tolerate a filename change is really up to the
platform maintainer like other ABI changes.

Rob

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Stephen Warren]

On 11/12/2013 08:29 AM, Rob Herring wrote:
> On Mon, Nov 11, 2013 at 3:24 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 11/11/2013 01:29 PM, Jason Cooper wrote:
>>> Consumers of the Linux kernel's build products are beginning to hardcode
>>> the filenames of the dtbs generated.  Since the dtb filenames are
>>> currently the dts filename s/dts/dtb/, this prevents the kernel
>>> community from renaming dts files as needed.
>>
>> My take is that the DTB filenames are part of the ABI, and therefore the
>> DTS filenames are also part of the ABI. Why would we want to rename them?
> 
> I agree with the ABI part, but for long term I think compatible
> strings are a better choice for the ABI than filenames. A link
> provides for a way to transition.

But this change isn't making the compatible value be the ABI, it's still
keeping the filename as the ABI, but creating a different way of
choosing the filename.

In other words, if the compatible value is the ABI, then the algorithm is:

* Search for all available DTBs
* Parse each DTB to find one with a matching compatible value

Whereas if the filename is the ABI, the algorithm is:

* Calculate the filename
* Load that one specific file, without looking at its content

Some additional thoughts:

* The filename is only relevant to the bootloader (or whatever
locates/selects a DTB). The kernel/OS just gets a single DTB passed to
it and uses it, without any naming metadata[1].

* Perhaps different bootloaders work different ways. For example, I've
set up U-Boot on all Tegra devices so that if U-Boot expands the string
"${soc}-${board}.dtb" using its environment, it'll generate the correct
DTB filename.

* Other boot-loaders might like "${compatible_parsed_from_the_dtb}" to
be the filename; that's Jason's proposal.

* Other SW (which I mention in [1]) might want to locate DTBs based on
ARM machine ID rather than compatible value.

* As such, we're really talking about an indexing process when
installing/packaging/searching DTBs. Shouldn't this file renaming happen
as part of that process, not the build process?

* When we create symlinks or any kind of index, I think we want to
create links for all entries in the compatible property (or other index
source). Consider if we have two boards:

Cardhu revision A02
Cardhu revision A04

Initially we think they're the same because we didn't read the
schematics well enough, but then later we split them. That means we'll
start out with one file:

nvidia,tegra30-cardhu.dtb

then later have instead:

nvidia,tegra30-cardhu-a02.dtb
nvidia,tegra30-cardhu-a04.dtb

Similarly, perhaps one DTB is (initially thought to be?) suitable for
multiple ARM machine IDs, etc.

So, bootloaders would have to search for $vendor,$soc-$board-$rev.dtb
then fall back to $vendor,$soc-$board.dtb (both those values are in the
compatible properties in those DTBs).

But then "nvidia,tegra30" is in the compatible property for many boards.
I wonder how we resolve that?

[1] I'm ignoring the idea that was proposed of passing n DTBs to the
kernel and having it select one based on machine ID. So by "the kernel"
I mean the code that runs after the DTB is selected.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Jason Cooper]

Stephen,

On Tue, Nov 12, 2013 at 11:38:47AM -0700, Stephen Warren wrote:
> On 11/12/2013 08:29 AM, Rob Herring wrote:
> > On Mon, Nov 11, 2013 at 3:24 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> >> On 11/11/2013 01:29 PM, Jason Cooper wrote:
> >>> Consumers of the Linux kernel's build products are beginning to hardcode
> >>> the filenames of the dtbs generated.  Since the dtb filenames are
> >>> currently the dts filename s/dts/dtb/, this prevents the kernel
> >>> community from renaming dts files as needed.
> >>
> >> My take is that the DTB filenames are part of the ABI, and therefore the
> >> DTS filenames are also part of the ABI. Why would we want to rename them?
> > 
> > I agree with the ABI part, but for long term I think compatible
> > strings are a better choice for the ABI than filenames. A link
> > provides for a way to transition.
> 
> But this change isn't making the compatible value be the ABI, it's still
> keeping the filename as the ABI, but creating a different way of
> choosing the filename.

Right, which provides a path towards a slightly more sane ABI.  If we
choose to implement this, or another variant, we get to shape a
migration path towards an ABI we designed.  As opposed to locked in to
one we didn't even see coming.

> In other words, if the compatible value is the ABI, then the algorithm is:
> 
> * Search for all available DTBs
> * Parse each DTB to find one with a matching compatible value
> 
> Whereas if the filename is the ABI, the algorithm is:
> 
> * Calculate the filename
> * Load that one specific file, without looking at its content
> 
> Some additional thoughts:
> 
> * The filename is only relevant to the bootloader (or whatever
> locates/selects a DTB). The kernel/OS just gets a single DTB passed to
> it and uses it, without any naming metadata[1].

As I see it (and perhaps this suffers from my limited view of the
embedded space, eg fairly marvell-specific), there are two scenarios:

1) The end goal:  bootloaders load a single DTB from a chunk of flash
and pass it off to the kernel/next stage, whatever.  Either there is no
filename, just a flash partition, or the vendor has chosen some dtb
naming scheme suitable for their needs, eg OMAP SoCs pulling the
bootloader from an SD card would need to name the dtb contained on the
same SD card. board.dtb?  I'm assuming here that the SD card files are
board specific (x-loader, uboot, env, dtb)

2) right now: distributions are creating utilities, such a flash-kernel
in Debian, that pick from a slew of dtbs, append it to the zImage, and
create the uImage.  The bootloaders in these installs don't have support
for fdt.

Our problem (as I see it) is that #2 is creating an ABI out of something
we never realized would become an ABI, the filenames created by 'make
dtbs'.

And since the dtb name is derived directly from the dts name, we're
getting locked into a bunch of filenames that are less than ideal
because we didn't know what we didn't know when we started this two+
years ago.

> * Perhaps different bootloaders work different ways. For example, I've
> set up U-Boot on all Tegra devices so that if U-Boot expands the string
> "${soc}-${board}.dtb" using its environment, it'll generate the correct
> DTB filename.

Why does the bootloader have to choose?  Is this a development scenario or
a deployed scenario?

> * Other boot-loaders might like "${compatible_parsed_from_the_dtb}" to
> be the filename; that's Jason's proposal.
> 
> * Other SW (which I mention in [1]) might want to locate DTBs based on
> ARM machine ID rather than compatible value.

fyi:  https://github.com/zonque/pxa-impedance-matcher.git

> * As such, we're really talking about an indexing process when
> installing/packaging/searching DTBs. Shouldn't this file renaming happen
> as part of that process, not the build process?

I agree, but it's not.  Hence the patch.

> * When we create symlinks or any kind of index, I think we want to
> create links for all entries in the compatible property (or other index
> source). 

We can't, you'll get collisions.  In my globalscale,mirabox.dtb example,
the next string is 'marvell,armada370'.  That matches many boards which
_aren't_ compatible with the globalscale,mirabox.dtb.

> Consider if we have two boards:
> 
> Cardhu revision A02
> Cardhu revision A04
> 
> Initially we think they're the same because we didn't read the
> schematics well enough, but then later we split them. That means we'll
> start out with one file:
> 
> nvidia,tegra30-cardhu.dtb

We've seen this as well with a couple of boards.

> then later have instead:
> 
> nvidia,tegra30-cardhu-a02.dtb
> nvidia,tegra30-cardhu-a04.dtb
> 
> Similarly, perhaps one DTB is (initially thought to be?) suitable for
> multiple ARM machine IDs, etc.
> 
> So, bootloaders would have to search for $vendor,$soc-$board-$rev.dtb
> then fall back to $vendor,$soc-$board.dtb (both those values are in the
> compatible properties in those DTBs).

I disagree here.  I don't think this decision/discovery process should
be done by the bootloader.  It should be done by the distribution
installer/firmware upgrade utility.  The risk of breaking boot is too
high.

> But then "nvidia,tegra30" is in the compatible property for many boards.
> I wonder how we resolve that?

At least during installer/upgrade the distro has the opportunity to
query the user, "Hey, this used to have nvidia,tegra30-cardhu.dtb, but
now I need to choose between nvidia,tegra30-cardhu-a02.dtb and
nvidia,tegra30-cardhu-a04.dtb.  Please see
http://wiki.mydistro.org/devicetree/upgrade/nvidia,tegra30-cardhu for
howto determine which variant matches your board."

Ideally, there would be programmatic way for the upgrader to determine
which variant it is on, but failing that, it could fall back to the
above.

thx,

Jason.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Andrew Lunn]

> 2) right now: distributions are creating utilities, such a flash-kernel
> in Debian, that pick from a slew of dtbs, append it to the zImage, and
> create the uImage.  The bootloaders in these installs don't have support
> for fdt.
> 
> Our problem (as I see it) is that #2 is creating an ABI out of something
> we never realized would become an ABI, the filenames created by 'make
> dtbs'.

Well, flash-kernel could be taught how to parse .dtb files to get the
compatibility strings out of them, rather than use filenames.

It might still be early enough to give distributions some guidelines
about what DT folks consider ABI and what is not. How they should find
a fitting .dtb file and how they should not.

  Andrew

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Jason Cooper]

On Tue, Nov 12, 2013 at 08:40:09PM +0100, Andrew Lunn wrote:
> > 2) right now: distributions are creating utilities, such a flash-kernel
> > in Debian, that pick from a slew of dtbs, append it to the zImage, and
> > create the uImage.  The bootloaders in these installs don't have support
> > for fdt.
> > 
> > Our problem (as I see it) is that #2 is creating an ABI out of something
> > we never realized would become an ABI, the filenames created by 'make
> > dtbs'.
> 
> Well, flash-kernel could be taught how to parse .dtb files to get the
> compatibility strings out of them, rather than use filenames.
> 
> It might still be early enough to give distributions some guidelines
> about what DT folks consider ABI and what is not. How they should find
> a fitting .dtb file and how they should not.

True, but this isn't a 'search /boot/config-X for CONFIG_Y so we can
configure for Z' *cough* *grub* *cough*.  flash-kernel currently doesn't
have any more correct way to select dtbs than by filename.

It's normal to look for arch/<arch>/boot/zImage after a build.  Module
names are not 1-1 with object files or source files, they are unique,
and static.  Our failure was not providing a similar ABI for the dtbs.
imho, we messed up, so we should fix it.

thx,

Jason.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Stephen Warren]

On 11/12/2013 12:30 PM, Jason Cooper wrote:
> Stephen,
> 
> On Tue, Nov 12, 2013 at 11:38:47AM -0700, Stephen Warren wrote:
>> On 11/12/2013 08:29 AM, Rob Herring wrote:
>>> On Mon, Nov 11, 2013 at 3:24 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> On 11/11/2013 01:29 PM, Jason Cooper wrote:
>>>>> Consumers of the Linux kernel's build products are beginning to hardcode
>>>>> the filenames of the dtbs generated.  Since the dtb filenames are
>>>>> currently the dts filename s/dts/dtb/, this prevents the kernel
>>>>> community from renaming dts files as needed.
>>>>
>>>> My take is that the DTB filenames are part of the ABI, and therefore the
>>>> DTS filenames are also part of the ABI. Why would we want to rename them?
>>>
>>> I agree with the ABI part, but for long term I think compatible
>>> strings are a better choice for the ABI than filenames. A link
>>> provides for a way to transition.
>>
>> But this change isn't making the compatible value be the ABI, it's still
>> keeping the filename as the ABI, but creating a different way of
>> choosing the filename.
> 
> Right, which provides a path towards a slightly more sane ABI.  If we
> choose to implement this, or another variant, we get to shape a
> migration path towards an ABI we designed.  As opposed to locked in to
> one we didn't even see coming.

I don't really agree here; I specifically named all the Tegra DTB/.dts
files in a sane fashion precisely so that U-Boot could easily determine
which one to load. It's hard to see how this wasn't a predictable issue.

...
>> * Perhaps different bootloaders work different ways. For example, I've
>> set up U-Boot on all Tegra devices so that if U-Boot expands the string
>> "${soc}-${board}.dtb" using its environment, it'll generate the correct
>> DTB filename.
> 
> Why does the bootloader have to choose?  Is this a development scenario or
> a deployed scenario?

I would expect it to work in both scenarios.

Assuming the DTB is in a filesystem rather than in a singleton location
in flash, the DTB must have a filename. It'd be far better to store each
board's DTB as a separate filename, rather than have some process copy
"the" DTB to a singleton filename at install time. Doing so allows the
same filesystem to work on multiple boards unmodified.

As an example, I move my SD card between ~10 different Tegra boards
without touching its content, and U-Boot loads the correct DTB based on
the board it's running on. Pengutronix demo'd a single SD card being
moved between a couple of entirely unrelated boards at ELC-E too.

Given that assumption, the bootloader must somehow determine which
filename to load at boot time, rather than some one-time installation
process doing the picking operation.

...
>> * As such, we're really talking about an indexing process when
>> installing/packaging/searching DTBs. Shouldn't this file renaming happen
>> as part of that process, not the build process?
> 
> I agree, but it's not.  Hence the patch.

Well, you could patch either:-)

...
>> So, bootloaders would have to search for $vendor,$soc-$board-$rev.dtb
>> then fall back to $vendor,$soc-$board.dtb (both those values are in the
>> compatible properties in those DTBs).
> 
> I disagree here.  I don't think this decision/discovery process should
> be done by the bootloader.  It should be done by the distribution
> installer/firmware upgrade utility.  The risk of breaking boot is too
> high.

That means distros have to have board identification logic, and
explicitly have code that selects the correct DT. Thus, distros would
have to be explicitly ported to each board (since IDing the board would
need some kind of board specific logic). Isn't the push towards
single-zImage and DT explicitly so that distros require zero
board-specific knowledge?

BTW, since the outcome of this discussion possibly affects distro
installers and kernel packages, perhaps the discussion should take place
on, or be CC'd to, cross-distro at lists.linaro.org?

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Jason Cooper]

On Tue, Nov 12, 2013 at 01:15:51PM -0700, Stephen Warren wrote:
> On 11/12/2013 12:30 PM, Jason Cooper wrote:
> > On Tue, Nov 12, 2013 at 11:38:47AM -0700, Stephen Warren wrote:
> >> On 11/12/2013 08:29 AM, Rob Herring wrote:
> >>> On Mon, Nov 11, 2013 at 3:24 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> >>>> On 11/11/2013 01:29 PM, Jason Cooper wrote:
> >>>>> Consumers of the Linux kernel's build products are beginning to hardcode
> >>>>> the filenames of the dtbs generated.  Since the dtb filenames are
> >>>>> currently the dts filename s/dts/dtb/, this prevents the kernel
> >>>>> community from renaming dts files as needed.
> >>>>
> >>>> My take is that the DTB filenames are part of the ABI, and therefore the
> >>>> DTS filenames are also part of the ABI. Why would we want to rename them?
> >>>
> >>> I agree with the ABI part, but for long term I think compatible
> >>> strings are a better choice for the ABI than filenames. A link
> >>> provides for a way to transition.
> >>
> >> But this change isn't making the compatible value be the ABI, it's still
> >> keeping the filename as the ABI, but creating a different way of
> >> choosing the filename.
> > 
> > Right, which provides a path towards a slightly more sane ABI.  If we
> > choose to implement this, or another variant, we get to shape a
> > migration path towards an ABI we designed.  As opposed to locked in to
> > one we didn't even see coming.
> 
> I don't really agree here; I specifically named all the Tegra DTB/.dts
> files in a sane fashion precisely so that U-Boot could easily determine
> which one to load. It's hard to see how this wasn't a predictable issue.

This is the difference between a commercial effort and a hobbyist
effort.  I think I have a plan for how we can both get what we want.  I
could change the argument to 'dtc ... -L arch/arm/boot ...'.  Thus:

$ cd arch/arm/boot
$ ls -l *.dtb        # minus a few columns
...
globalscale,mirabox.dtb -> dts/armada-370-mirabox.dtb
...


This way, aftermarket users (debian installers, etc) could go to the
same place they go for zImages, and find a standard named dtb.  They
wouldn't need to parse the dtbs, just look at the current compatible
string for the board they are installing on and find the matching file.
For commercial efforts, nothing changes, the well-thought out *.dtb
filenames are still in the same place they always were.  A self-imposed
vendor ABI, if you will.

Then, in situations where dts filenames need to change, that can happen
(typically per vendor) because the ABI, from the kernel maintainers pov,
is the symlinks in arch/arm/boot/.

As for the migration, there wouldn't need to be one beyond this first
step of providing symlinks.  That way, vendor-preferred filenames stay
as they are.

Would that work better for you?

thx,

Jason.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Stephen Warren]

On 11/14/2013 09:28 AM, Jason Cooper wrote:
> On Tue, Nov 12, 2013 at 01:15:51PM -0700, Stephen Warren wrote:
>> On 11/12/2013 12:30 PM, Jason Cooper wrote:
>>> On Tue, Nov 12, 2013 at 11:38:47AM -0700, Stephen Warren wrote:
>>>> On 11/12/2013 08:29 AM, Rob Herring wrote:
>>>>> On Mon, Nov 11, 2013 at 3:24 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>>> On 11/11/2013 01:29 PM, Jason Cooper wrote:
>>>>>>> Consumers of the Linux kernel's build products are beginning to hardcode
>>>>>>> the filenames of the dtbs generated.  Since the dtb filenames are
>>>>>>> currently the dts filename s/dts/dtb/, this prevents the kernel
>>>>>>> community from renaming dts files as needed.
>>>>>>
>>>>>> My take is that the DTB filenames are part of the ABI, and therefore the
>>>>>> DTS filenames are also part of the ABI. Why would we want to rename them?
>>>>>
>>>>> I agree with the ABI part, but for long term I think compatible
>>>>> strings are a better choice for the ABI than filenames. A link
>>>>> provides for a way to transition.
>>>>
>>>> But this change isn't making the compatible value be the ABI, it's still
>>>> keeping the filename as the ABI, but creating a different way of
>>>> choosing the filename.
>>>
>>> Right, which provides a path towards a slightly more sane ABI.  If we
>>> choose to implement this, or another variant, we get to shape a
>>> migration path towards an ABI we designed.  As opposed to locked in to
>>> one we didn't even see coming.
>>
>> I don't really agree here; I specifically named all the Tegra DTB/.dts
>> files in a sane fashion precisely so that U-Boot could easily determine
>> which one to load. It's hard to see how this wasn't a predictable issue.
> 
> This is the difference between a commercial effort and a hobbyist
> effort.  I think I have a plan for how we can both get what we want.  I
> could change the argument to 'dtc ... -L arch/arm/boot ...'.  Thus:
> 
> $ cd arch/arm/boot
> $ ls -l *.dtb        # minus a few columns
> ...
> globalscale,mirabox.dtb -> dts/armada-370-mirabox.dtb
> ...

I don't think the symlinks should be in arch/arm/boot, since that's not
where the source files are. They should either exist in
arch/arm/boot/dts (since that's the source file location, and that
generally determines the object/binary/output file location in the
kernel build system), or in some user-specified directory, created as a
side-effect of e.g. "make dtbs_install". There have been some small
discussions of a dtb install target before, but I don't remember the
details.

> This way, aftermarket users (debian installers, etc) could go to the
> same place they go for zImages, and find a standard named dtb.  They
> wouldn't need to parse the dtbs, just look at the current compatible
> string for the board they are installing on and find the matching file.
> For commercial efforts, nothing changes, the well-thought out *.dtb
> filenames are still in the same place they always were.  A self-imposed
> vendor ABI, if you will.
> 
> Then, in situations where dts filenames need to change, that can happen
> (typically per vendor) because the ABI, from the kernel maintainers pov,
> is the symlinks in arch/arm/boot/.
> 
> As for the migration, there wouldn't need to be one beyond this first
> step of providing symlinks.  That way, vendor-preferred filenames stay
> as they are.
> 
> Would that work better for you?

I don't think a distro should need to know the DTB filename at all.
Rather, the/a bootloader should know which platform it's running on, and
provide a variable/... to the boot script/... that defines the DTB
filename. That would completely remove all the knowledge of DTB
filenames from distros.

I don't think there's anything stopping you from renaming
dts/armada-370-mirabox.dts to globalscale,mirabox.dts, as a one-time
ABI-breaking event, if you want the compatible value to be the filename
for those DTs. Is there a reason you'd want the .dts and .dtb filenames
to differ? You'd mentioned flexibility in renaming the .dts files, but
why would you need that flexibility?

Perhaps if we had to, we could just rename all .dts to conform to the
new naming rule and then I can deal with the bootloader fallout for Tegra:-(

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Jason Gunthorpe]

On Thu, Nov 14, 2013 at 12:00:24PM -0700, Stephen Warren wrote:

> I don't think a distro should need to know the DTB filename at all.
> Rather, the/a bootloader should know which platform it's running on, and
> provide a variable/... to the boot script/... that defines the DTB
> filename. That would completely remove all the knowledge of DTB
> filenames from distros.

At some point the distro has to install a dtb into some cannonical
place so the bootloader can find it..

Are you thinking that distros will have to ship a /boot/dtbs/*.dtb
with every dtb from the kernel build?

What happens when you install two different versions of the kernel?

What about boot schemes that can load a kernel version dependent dtb?

I've said this before - I really think the kernel community will do
itself a big favor if it encourages boot schemes that can handle a
kernel version dependent dtb, rather that design schemes that
absolutely can't allow for that.

Jason

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Russell King - ARM Linux]

On Thu, Nov 14, 2013 at 12:16:22PM -0700, Jason Gunthorpe wrote:
> On Thu, Nov 14, 2013 at 12:00:24PM -0700, Stephen Warren wrote:
> 
> > I don't think a distro should need to know the DTB filename at all.
> > Rather, the/a bootloader should know which platform it's running on, and
> > provide a variable/... to the boot script/... that defines the DTB
> > filename. That would completely remove all the knowledge of DTB
> > filenames from distros.
> 
> At some point the distro has to install a dtb into some cannonical
> place so the bootloader can find it..
> 
> Are you thinking that distros will have to ship a /boot/dtbs/*.dtb
> with every dtb from the kernel build?

Why are we even having this discussion?  Where distros want to install
dtbs is their policy.  What we should do is make it _possible_ for them
to have policy, not define the policy for them.

The problem here is this.  Consider how often these files change, and
how often there's differences in them.  Sensible distros allow you to
have several kernels installed so that you can switch to other
versions if, for example, you run into problems.

Distros have two main choices - either to ship the DTBs separately
assuming that they'll always be compatible and correct, or ship them
with the kernel itself (in which case we've lost the plot about what
DT is supposed to give us.)

That's where the problem lies: what if a distro wants to have installed
more than one set of DTBs corresponding to $old_kernel and $new_kernel.

This really isn't something for us kernel developers to decide.  It's
a distro question and it needs distro people to think about it and put
proposals forward for what they'd like to see.

In my experience, that won't happen - they like hiding away and sorting
out their own problems.  The communication between distros and kernel
folk has always tended to be extremely poor.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Stephen Warren]

On 11/14/2013 12:16 PM, Jason Gunthorpe wrote:
> On Thu, Nov 14, 2013 at 12:00:24PM -0700, Stephen Warren wrote:
> 
>> I don't think a distro should need to know the DTB filename at all.
>> Rather, the/a bootloader should know which platform it's running on, and
>> provide a variable/... to the boot script/... that defines the DTB
>> filename. That would completely remove all the knowledge of DTB
>> filenames from distros.
> 
> At some point the distro has to install a dtb into some cannonical
> place so the bootloader can find it..
> 
> Are you thinking that distros will have to ship a /boot/dtbs/*.dtb
> with every dtb from the kernel build?

Yes. How else would the distro support booting the install on arbitrary
boards?

> What happens when you install two different versions of the kernel?

/boot/zImage-$version
/boot/dtbs-$version/*.dtb

> What about boot schemes that can load a kernel version dependent dtb?

I think that's solved by installing the DTB files in a
kernel-version-specific directory.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Matt Sealey]

On Thu, Nov 14, 2013 at 3:37 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/14/2013 12:16 PM, Jason Gunthorpe wrote:
>> On Thu, Nov 14, 2013 at 12:00:24PM -0700, Stephen Warren wrote:
>>
>>> I don't think a distro should need to know the DTB filename at all.
>>> Rather, the/a bootloader should know which platform it's running on, and
>>> provide a variable/... to the boot script/... that defines the DTB
>>> filename. That would completely remove all the knowledge of DTB
>>> filenames from distros.
>>
>> At some point the distro has to install a dtb into some cannonical
>> place so the bootloader can find it..

Right, and this place can be *anywhere* with *any name* in the scripted case.

In a non-scripted case, it just needs to match the bootloader name and
where it differs from the one in the kernel right now, this would be
hellish. To use GlobalScale as an example, since the patch did - if
Marvell or GlobalScale ship a U-Boot that boots the board, that has a
fixed name and *then* rename their tree in the kernel source, they
should be shot. The kernel community should be careful about it if
they're not Marvell or GlobalScale and didn't check with the
bootloader situation.. but when it happens, this is *entirely* a
packaging problem for your package maintainers. *ENTIRELY*.

In the case where it gets flashed into the board rather than left on a
filesystem, then it doesn't matter one jot what the filename is as
long as it goes to the right offset - which is going to end up
hardcoded in your distro, right? So stop hardcoding it (flash-kernel
does a particularly crappy, but eventually usable job of this under
Debian/Ubuntu right now already so they're safe).

>> Are you thinking that distros will have to ship a /boot/dtbs/*.dtb
>> with every dtb from the kernel build?
>
> Yes. How else would the distro support booting the install on arbitrary
> boards?

There are LOTS of ways. Mark and Russell insist on me being more
concise, so I'll simply say the distros have to do more work and
there's not really any way around it. Specifying "requirements for a
distro boot" means making everything comply with that, which is a lot
of work for distros anyway. May as well make your distro work around
the problems where they actually have some control - distro scripting,
distro board support, and not esoteric kernel build behaviors, or
having distro teams work on fixing non-compliant bootloaders.

Ta,
Matt Sealey <neko@bakuhatsu.net>

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Grant Likely]

On Thu, 14 Nov 2013 14:37:48 -0700, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/14/2013 12:16 PM, Jason Gunthorpe wrote:
> > On Thu, Nov 14, 2013 at 12:00:24PM -0700, Stephen Warren wrote:
> > 
> >> I don't think a distro should need to know the DTB filename at all.
> >> Rather, the/a bootloader should know which platform it's running on, and
> >> provide a variable/... to the boot script/... that defines the DTB
> >> filename. That would completely remove all the knowledge of DTB
> >> filenames from distros.
> > 
> > At some point the distro has to install a dtb into some cannonical
> > place so the bootloader can find it..
> > 
> > Are you thinking that distros will have to ship a /boot/dtbs/*.dtb
> > with every dtb from the kernel build?
> 
> Yes. How else would the distro support booting the install on arbitrary
> boards?
> 
> > What happens when you install two different versions of the kernel?
> 
> /boot/zImage-$version
> /boot/dtbs-$version/*.dtb
> 
> > What about boot schemes that can load a kernel version dependent dtb?
> 
> I think that's solved by installing the DTB files in a
> kernel-version-specific directory.

That's certainly the way I would solve it.

g.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Russell King - ARM Linux]

On Thu, Nov 14, 2013 at 11:28:59AM -0500, Jason Cooper wrote:
> This is the difference between a commercial effort and a hobbyist
> effort.  I think I have a plan for how we can both get what we want.  I
> could change the argument to 'dtc ... -L arch/arm/boot ...'.  Thus:
> 
> $ cd arch/arm/boot
> $ ls -l *.dtb        # minus a few columns
> ...
> globalscale,mirabox.dtb -> dts/armada-370-mirabox.dtb
> ...
> 
> 
> This way, aftermarket users (debian installers, etc) could go to the
> same place they go for zImages, and find a standard named dtb.  They
> wouldn't need to parse the dtbs, just look at the current compatible
> string for the board they are installing on and find the matching file.

There's little point saying that they should be in arch/arm/boot.
Unless the distro is installing from a kernel source tree on every
platform, the location of the dtbs really doesn't matter.

Let's look at the typical distro build process:

- take the source
- patch it
- build it
- install it, relatively placing files according to their ultimate
  destination
- packaging the result up, adding metadata and scripts to aid installation

So, how does affecting where things are in the build tree help after all
that process?  What matters for DT files are:

(a) their names
(b) their location after installation

Where it appears in the build tree is neither here nor there, and IMHO
should not be of concern to any distro - just the same as picking the
zImage/uImage/whatever out of arch/arm/boot is none of their business.

We have ways and means to deal with the installation of kernel images
and modules.  There's well defined makefile targets for this, and
make variables which control where and how these get put.  For the
kernel image, you can specify the script to be run (which is called
with the location of the *Image file) for copying.  Pulling it manually
out of arch/arm/boot is really a failure of the distro packaging people
to get their process right.

The same goes for the DT files: if we don't provide a method for the
kernel build system to install these in a sane way, then that's our
failing.  However, distros should be asking for this, and not picking
the files out of arch/arm/boot/dts.

As for the commercial vs hobbist, there's very little difference here.
If you're a hobbist, building natively, that's where having the right
/sbin/installkernel present is a godsend, especially if you're running
some distro.  If you don't, most likely you understand what's required
to install a kernel.

Last point - on the Carrier-1, I have a fully automated setup which I
can fire off a build, walk away, and it will build a kernel including
modules, install it locally on my x86 PC in ~/systems/imx6 - including
appending the DT file, tar up the appropriate files, automatically copy
the tar file over, unpack it, update the initramfs for ubuntu 12.04,
update the vfat /boot filesystem appropriately, and reboot the platform.

Yes, I know the target system with that.  That's not my point.  The point
I'm making is that that level of automation is possible without excessive
amounts of messing about with kernel build internals - that all runs with
standard unmodified kbuild.

So, maintain a sense of perspective and separation of stages please.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Jason Cooper]

On Thu, Nov 14, 2013 at 07:26:29PM +0000, Russell King - ARM Linux wrote:
> We have ways and means to deal with the installation of kernel images
> and modules.  There's well defined makefile targets for this, and
> make variables which control where and how these get put.  For the
> kernel image, you can specify the script to be run (which is called
> with the location of the *Image file) for copying.  Pulling it manually
> out of arch/arm/boot is really a failure of the distro packaging people
> to get their process right.
> 
> The same goes for the DT files: if we don't provide a method for the
> kernel build system to install these in a sane way, then that's our
> failing.  However, distros should be asking for this, and not picking
> the files out of arch/arm/boot/dts.

Exactly.  V2 hopefully this weekend implementing 'make dtbs-install'

thx,

Jason.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Javier Martinez Canillas]

Hi Jason,

On Fri, Nov 15, 2013 at 4:23 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Thu, Nov 14, 2013 at 07:26:29PM +0000, Russell King - ARM Linux wrote:
>> We have ways and means to deal with the installation of kernel images
>> and modules.  There's well defined makefile targets for this, and
>> make variables which control where and how these get put.  For the
>> kernel image, you can specify the script to be run (which is called
>> with the location of the *Image file) for copying.  Pulling it manually
>> out of arch/arm/boot is really a failure of the distro packaging people
>> to get their process right.
>>
>> The same goes for the DT files: if we don't provide a method for the
>> kernel build system to install these in a sane way, then that's our
>> failing.  However, distros should be asking for this, and not picking
>> the files out of arch/arm/boot/dts.
>
> Exactly.  V2 hopefully this weekend implementing 'make dtbs-install'

Just a small comment, I think the make target should be called
'dtbs_install and not of 'dtbs-install' to be consistent with make
{modules,firmware,headers}_install

>
> thx,
>
> Jason.
>

Best regards,
Javier

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Jason Cooper]

On Fri, Nov 15, 2013 at 06:09:50PM +0100, Javier Martinez Canillas wrote:
> Hi Jason,
> 
> On Fri, Nov 15, 2013 at 4:23 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Thu, Nov 14, 2013 at 07:26:29PM +0000, Russell King - ARM Linux wrote:
> >> We have ways and means to deal with the installation of kernel images
> >> and modules.  There's well defined makefile targets for this, and
> >> make variables which control where and how these get put.  For the
> >> kernel image, you can specify the script to be run (which is called
> >> with the location of the *Image file) for copying.  Pulling it manually
> >> out of arch/arm/boot is really a failure of the distro packaging people
> >> to get their process right.
> >>
> >> The same goes for the DT files: if we don't provide a method for the
> >> kernel build system to install these in a sane way, then that's our
> >> failing.  However, distros should be asking for this, and not picking
> >> the files out of arch/arm/boot/dts.
> >
> > Exactly.  V2 hopefully this weekend implementing 'make dtbs-install'
> 
> Just a small comment, I think the make target should be called
> 'dtbs_install and not of 'dtbs-install' to be consistent with make
> {modules,firmware,headers}_install

Yep, typo on my part.

thx,

Jason.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Grant Likely]

On Mon, 11 Nov 2013 20:29:20 +0000, Jason Cooper <jason@lakedaemon.net> wrote:
> Consumers of the Linux kernel's build products are beginning to hardcode
> the filenames of the dtbs generated.  Since the dtb filenames are
> currently the dts filename s/dts/dtb/, this prevents the kernel
> community from renaming dts files as needed.
> 
> Let's provide a consistent naming structure for consumers to script
> against.  Or at least, as consistent as the dts properties themselves.
> 
> With this patch, adding the '-L' option to the dtc commandline will
> cause dtc to create a symlink to the generated dtb, using the board
> compatible string as the filename, eg:
> 
>   globalscale,mirabox.dtb -> armada-370-mirabox.dtb

This whole thread is just crazy. The filename is not an ABI. Anything
digging into the kernel build tree is a) wrong, and b) userspace tooling
consuming the kernel build products which is /not/ ABI and can be changed

If we want to have a tool or script for creating a well formed directory
full of .dtb files because it would be helpful to U-Boot or something
else, then that is fine. Make it part of the "make install" path.

g.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Jason Cooper]

On Fri, Nov 15, 2013 at 09:12:15PM +0900, Grant Likely wrote:
> On Mon, 11 Nov 2013 20:29:20 +0000, Jason Cooper <jason@lakedaemon.net> wrote:
> > Consumers of the Linux kernel's build products are beginning to hardcode
> > the filenames of the dtbs generated.  Since the dtb filenames are
> > currently the dts filename s/dts/dtb/, this prevents the kernel
> > community from renaming dts files as needed.
> > 
> > Let's provide a consistent naming structure for consumers to script
> > against.  Or at least, as consistent as the dts properties themselves.
> > 
> > With this patch, adding the '-L' option to the dtc commandline will
> > cause dtc to create a symlink to the generated dtb, using the board
> > compatible string as the filename, eg:
> > 
> >   globalscale,mirabox.dtb -> armada-370-mirabox.dtb
> 
> This whole thread is just crazy. The filename is not an ABI. Anything
> digging into the kernel build tree is a) wrong, and b) userspace tooling
> consuming the kernel build products which is /not/ ABI and can be changed

whew.  I still think there is a need for an install target.  The fact
that our changing filenames might break things is an indicator of that.

> If we want to have a tool or script for creating a well formed directory
> full of .dtb files because it would be helpful to U-Boot or something
> else, then that is fine. Make it part of the "make install" path.

I'm currently reworking the patch(es) to implement 'make dtbs-install'.
I'll hopefully have them ready this weekend or sooner.  I'm taking the
same tack as install.sh (/sbin/installdtbs takes precedence).

thx,

Jason.

[RFC DTC PATCH] dtc: add symlink (-L) output to dtbs

[Grant Likely]

On Fri, 15 Nov 2013 10:21:42 -0500, Jason Cooper <jason@lakedaemon.net> wrote:
> On Fri, Nov 15, 2013 at 09:12:15PM +0900, Grant Likely wrote:
> > On Mon, 11 Nov 2013 20:29:20 +0000, Jason Cooper <jason@lakedaemon.net> wrote:
> > > Consumers of the Linux kernel's build products are beginning to hardcode
> > > the filenames of the dtbs generated.  Since the dtb filenames are
> > > currently the dts filename s/dts/dtb/, this prevents the kernel
> > > community from renaming dts files as needed.
> > > 
> > > Let's provide a consistent naming structure for consumers to script
> > > against.  Or at least, as consistent as the dts properties themselves.
> > > 
> > > With this patch, adding the '-L' option to the dtc commandline will
> > > cause dtc to create a symlink to the generated dtb, using the board
> > > compatible string as the filename, eg:
> > > 
> > >   globalscale,mirabox.dtb -> armada-370-mirabox.dtb
> > 
> > This whole thread is just crazy. The filename is not an ABI. Anything
> > digging into the kernel build tree is a) wrong, and b) userspace tooling
> > consuming the kernel build products which is /not/ ABI and can be changed
> 
> whew.  I still think there is a need for an install target.  The fact
> that our changing filenames might break things is an indicator of that.
> 
> > If we want to have a tool or script for creating a well formed directory
> > full of .dtb files because it would be helpful to U-Boot or something
> > else, then that is fine. Make it part of the "make install" path.
> 
> I'm currently reworking the patch(es) to implement 'make dtbs-install'.
> I'll hopefully have them ready this weekend or sooner.  I'm taking the
> same tack as install.sh (/sbin/installdtbs takes precedence).

Cool, I think that is a good approach.

g.

[RFC PATCH V2 0/2] Add 'make dtbs_install'

[Jason Cooper]

Detailed changelog can be found in each patch.

The kernel community never created a 'dtbs_install' make target for properly
handling the build output of the kernel's devicetree files.  Currently, the dtb
files are simply their source file, s/dts/dtb/.  Users have recently begun
retrieving these files from inside the kernel tree.  Any change to the dts
filenames breaks the scripts of those users.

Before this gets too far along, we'd like to create a standardized method of
installing the dtb files for users to find and use.  In addition, some vendors
have done a diligent job naming their devicetree source files appropriately and
we don't want to break their setups.

This patch series solves both problems by creating a dtbs_install make target
which calls arch/arm/boot/installdtbs.sh.  If /sbin/installdtbs or
~/bin/installdtbs is present, they will be run instead of the default behavior.

The default action is to install a given dtb to

  /lib/modules/${kernel_version}/devicetree/${board_compatible}.dtb

Ideally, the devicetree file should be independent of the kernel version,
however, we aren't there yet.  So, while the devicetree files live in the
kernel source tree, we'll install them as above.  Once they are in their own
repository, this install target can be removed, and users can adjust their
workflow to getting the dtbs from a new location.

Jason Cooper (2):
  dtc: add 'compat' output option, prints board string
  kbuild: dtbs_install: new make target

 Makefile                     |  3 ++-
 arch/arm/Makefile            |  4 ++++
 arch/arm/boot/installdtbs.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
 scripts/dtc/dtc.c            |  3 +++
 scripts/dtc/dtc.h            |  1 +
 scripts/dtc/flattree.c       |  9 +++++++++
 6 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/installdtbs.sh

-- 
1.8.4.3

[RFC PATCH V2 1/2] dtc: add 'compat' output option, prints board string

[Jason Cooper]

Consumers of the Linux kernel's build products are beginning to hardcode
the filenames of the dtbs generated.  Since the dtb filenames are
currently the dts filename s/dts/dtb/, this prevents the kernel
community from renaming dts files as needed.

Let's provide a consistent naming structure for consumers to script
against.  Or at least, as consistent as the dts properties themselves.

With this patch, adding the '-O compat' option to the dtc commandline
will cause dtc to parse the provided file, and print out the board
compatible string to stdout.

This will facilitate an 'installdtbs.sh' script in the kernel for naming
dtb files by their compatible string, eg:

$ dtc -I dtb -O compat arch/arm/boot/dts/armada-370-mirabox.dtb
globalscale,mirabox

This change will also simplify distribution install scripts that need to
search through many dtbs to find the right one for a target board.

Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
changes since v1:
 - made patch against in-tree dtc code to facilitate testing
 - dtc prints compatible string to stdout now, instead of creating symlink
    - should be more flexible for end-users

 scripts/dtc/dtc.c      | 3 +++
 scripts/dtc/dtc.h      | 1 +
 scripts/dtc/flattree.c | 9 +++++++++
 3 files changed, 13 insertions(+)

diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index a375683c1534..89264bb0a3dd 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -68,6 +68,7 @@ static void  __attribute__ ((noreturn)) usage(void)
 	fprintf(stderr, "\t\tOutput formats are:\n");
 	fprintf(stderr, "\t\t\tdts - device tree source text\n");
 	fprintf(stderr, "\t\t\tdtb - device tree blob\n");
+	fprintf(stderr, "\t\t\tcompat - print board compatible string\n");
 	fprintf(stderr, "\t\t\tasm - assembler source\n");
 	fprintf(stderr, "\t-V <output version>\n");
 	fprintf(stderr, "\t\tBlob version to produce, defaults to %d (relevant for dtb\n\t\tand asm output only)\n", DEFAULT_FDT_VERSION);
@@ -250,6 +251,8 @@ int main(int argc, char *argv[])
 		dt_to_blob(outf, bi, outversion);
 	} else if (streq(outform, "asm")) {
 		dt_to_asm(outf, bi, outversion);
+	} else if (streq(outform, "compat")) {
+		dt_to_compat(bi);
 	} else if (streq(outform, "null")) {
 		/* do nothing */
 	} else {
diff --git a/scripts/dtc/dtc.h b/scripts/dtc/dtc.h
index 3e42a071070e..d4e47c697c2f 100644
--- a/scripts/dtc/dtc.h
+++ b/scripts/dtc/dtc.h
@@ -255,6 +255,7 @@ void process_checks(int force, struct boot_info *bi);
 
 void dt_to_blob(FILE *f, struct boot_info *bi, int version);
 void dt_to_asm(FILE *f, struct boot_info *bi, int version);
+void dt_to_compat(struct boot_info *bi);
 
 struct boot_info *dt_from_blob(const char *fname);
 
diff --git a/scripts/dtc/flattree.c b/scripts/dtc/flattree.c
index 665dad7bb465..bdbd3d7e8964 100644
--- a/scripts/dtc/flattree.c
+++ b/scripts/dtc/flattree.c
@@ -577,6 +577,15 @@ void dt_to_asm(FILE *f, struct boot_info *bi, int version)
 	data_free(strbuf);
 }
 
+void dt_to_compat(struct boot_info *bi)
+{
+	struct property *prop;
+
+	prop = get_property(bi->dt, "compatible");
+
+	printf("%s\n", prop->val.val);
+}
+
 struct inbuf {
 	char *base, *limit, *ptr;
 };
-- 
1.8.4.3

[RFC PATCH V2 1/2] dtc: add 'compat' output option, prints board string

[Stephen Warren]

On 11/18/2013 11:38 AM, Jason Cooper wrote:
> Consumers of the Linux kernel's build products are beginning to hardcode
> the filenames of the dtbs generated.  Since the dtb filenames are
> currently the dts filename s/dts/dtb/, this prevents the kernel
> community from renaming dts files as needed.
> 
> Let's provide a consistent naming structure for consumers to script
> against.  Or at least, as consistent as the dts properties themselves.
> 
> With this patch, adding the '-O compat' option to the dtc commandline
> will cause dtc to parse the provided file, and print out the board
> compatible string to stdout.
> 
> This will facilitate an 'installdtbs.sh' script in the kernel for naming
> dtb files by their compatible string, eg:
> 
> $ dtc -I dtb -O compat arch/arm/boot/dts/armada-370-mirabox.dtb
> globalscale,mirabox
> 
> This change will also simplify distribution install scripts that need to
> search through many dtbs to find the right one for a target board.
> 
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> ---
> changes since v1:
>  - made patch against in-tree dtc code to facilitate testing

I assume this patch would first get applied to the upstream dtc, then
back-ported into the kernel though?

I wonder if dtc is the correct place to put this feature at all though.
It seems like a tiny standalone utility using libfdt would be better.
Actually, perhaps the existing fdtget utility (which seems to be
scripts/dtc/fdtget.c in the kernel although I don't know if it's built
by the kernel yet) can be used rather than creating a new one? Using
fdtget seems like it'd allow more flexibility later, if the naming rules
change, via scripting rather than having to edit the dtc source code.

[RFC PATCH V2 1/2] dtc: add 'compat' output option, prints board string

[Jason Cooper]

On Mon, Nov 18, 2013 at 12:01:02PM -0700, Stephen Warren wrote:
> On 11/18/2013 11:38 AM, Jason Cooper wrote:
> > Consumers of the Linux kernel's build products are beginning to hardcode
> > the filenames of the dtbs generated.  Since the dtb filenames are
> > currently the dts filename s/dts/dtb/, this prevents the kernel
> > community from renaming dts files as needed.
> > 
> > Let's provide a consistent naming structure for consumers to script
> > against.  Or at least, as consistent as the dts properties themselves.
> > 
> > With this patch, adding the '-O compat' option to the dtc commandline
> > will cause dtc to parse the provided file, and print out the board
> > compatible string to stdout.
> > 
> > This will facilitate an 'installdtbs.sh' script in the kernel for naming
> > dtb files by their compatible string, eg:
> > 
> > $ dtc -I dtb -O compat arch/arm/boot/dts/armada-370-mirabox.dtb
> > globalscale,mirabox
> > 
> > This change will also simplify distribution install scripts that need to
> > search through many dtbs to find the right one for a target board.
> > 
> > Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> > ---
> > changes since v1:
> >  - made patch against in-tree dtc code to facilitate testing
> 
> I assume this patch would first get applied to the upstream dtc, then
> back-ported into the kernel though?

Yes.

> I wonder if dtc is the correct place to put this feature at all though.
> It seems like a tiny standalone utility using libfdt would be better.
> Actually, perhaps the existing fdtget utility (which seems to be
> scripts/dtc/fdtget.c in the kernel although I don't know if it's built
> by the kernel yet) can be used rather than creating a new one? Using
> fdtget seems like it'd allow more flexibility later, if the naming rules
> change, via scripting rather than having to edit the dtc source code.

Ah, neat.  I missed fdtget.c.  I'll take a look at that, it sounds
promising.

thx,

Jason.

[RFC PATCH V2 1/2] dtc: add 'compat' output option, prints board string

[Jason Cooper]

On Mon, Nov 18, 2013 at 12:01:02PM -0700, Stephen Warren wrote:
> On 11/18/2013 11:38 AM, Jason Cooper wrote:
> > Consumers of the Linux kernel's build products are beginning to hardcode
> > the filenames of the dtbs generated.  Since the dtb filenames are
> > currently the dts filename s/dts/dtb/, this prevents the kernel
> > community from renaming dts files as needed.
> > 
> > Let's provide a consistent naming structure for consumers to script
> > against.  Or at least, as consistent as the dts properties themselves.
> > 
> > With this patch, adding the '-O compat' option to the dtc commandline
> > will cause dtc to parse the provided file, and print out the board
> > compatible string to stdout.
> > 
> > This will facilitate an 'installdtbs.sh' script in the kernel for naming
> > dtb files by their compatible string, eg:
> > 
> > $ dtc -I dtb -O compat arch/arm/boot/dts/armada-370-mirabox.dtb
> > globalscale,mirabox
> > 
> > This change will also simplify distribution install scripts that need to
> > search through many dtbs to find the right one for a target board.
> > 
> > Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> > ---
> > changes since v1:
> >  - made patch against in-tree dtc code to facilitate testing
> 
> I assume this patch would first get applied to the upstream dtc, then
> back-ported into the kernel though?
> 
> I wonder if dtc is the correct place to put this feature at all though.
> It seems like a tiny standalone utility using libfdt would be better.
> Actually, perhaps the existing fdtget utility (which seems to be
> scripts/dtc/fdtget.c in the kernel although I don't know if it's built
> by the kernel yet) can be used rather than creating a new one? Using
> fdtget seems like it'd allow more flexibility later, if the naming rules
> change, via scripting rather than having to edit the dtc source code.

yep, just tested it.  It was easier to build fdtget in the dtc source
tree, but the result was suitable:

$ ./fdtget ../linux/arch/arm/boot/dts/armada-370-mirabox.dtb / compatible
globalscale,mirabox marvell,armada370 marvell,armada-370-xp

Thanks for the pointer.

thx,

Jason.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

Unlike other build products in the Linux kernel, the devicetree blobs
are simply the name of their source file, s/dts/dtb/.  There is also no
'make *install' mechanism to put them in a standard place with a
standard naming structure.

Unfortunately, users have begun scripting pulling the needed dtbs from
within the kernel tree, thus hardcoding the dtbs names.  In turn, this
means any changes to the dts filenames breaks these scripts.

This patch is an attempt to fix this problem.  Akin to 'make install',
this creates a new make target, dtbs_install.  The script that gets
called defers to a vendor or distribution supplied installdtbs binary,
if found in the system.  Otherwise, the default action is to install a
given dtb into

  /lib/modules/${kernel_version}/devicetree/${board_compat}.dtb

This solves several problems for us.  The board compatible string should
be unique, this enforces/highlights that.  While devicetrees are
stablilizing, the fact is, devicetrees aren't (yet) independent of
kernel version.  This install target facilitates keeping track of that.

Once the devicetree files are moved to their own repository, this
install target can be removed as users will be modifying their scripts
anyway.

Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
changes since v1:
 - added this patch

 Makefile                     |  3 ++-
 arch/arm/Makefile            |  4 ++++
 arch/arm/boot/installdtbs.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/installdtbs.sh

diff --git a/Makefile b/Makefile
index 920ad07180c9..29d609e972d6 100644
--- a/Makefile
+++ b/Makefile
@@ -339,6 +339,7 @@ OBJDUMP		= $(CROSS_COMPILE)objdump
 AWK		= awk
 GENKSYMS	= scripts/genksyms/genksyms
 INSTALLKERNEL  := installkernel
+INSTALLDTBS    := installdtbs
 DEPMOD		= /sbin/depmod
 PERL		= perl
 CHECK		= sparse
@@ -391,7 +392,7 @@ KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(S
 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
-export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
+export MAKE AWK GENKSYMS INSTALLKERNEL INSTALLDTBS PERL UTS_MACHINE
 export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c99b1086d83d..c16ebb1e74b0 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -314,6 +314,10 @@ PHONY += dtbs
 dtbs: scripts
 	$(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) dtbs
 
+dtbs_install: dtbs
+	$(CONFIG_SHELL) $(srctree)/$(boot)/installdtbs.sh $(KERNELRELEASE) \
+	"$(MODLIB)/devicetree" "$(srctree)/$(boot)/dts"
+
 # We use MRPROPER_FILES and CLEAN_FILES now
 archclean:
 	$(Q)$(MAKE) $(clean)=$(boot)
diff --git a/arch/arm/boot/installdtbs.sh b/arch/arm/boot/installdtbs.sh
new file mode 100644
index 000000000000..c46c109363d2
--- /dev/null
+++ b/arch/arm/boot/installdtbs.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+#
+# This file is subject to the terms and conditions of the GNU General Public
+# License.  See the file "COPYING" in the main directory of this archive
+# for more details.
+#
+# Copyright (C) 1995 by Linus Torvalds
+#
+# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
+#
+# Further adapted from arch/x86/boot/install.sh by Jason Cooper
+#
+# "make dtbs_install" script
+#
+# Arguments:
+#   $1 - kernel version
+#   $2 - default install path (blank if root directory)
+#   $3 - directory containing dtbs
+#
+
+# User may have a custom install script
+
+if [ -x ~/bin/${INSTALLDTBS} ]; then exec ~/bin/${INSTALLDTBS} "$@"; fi
+if [ -x /sbin/${INSTALLDTBS} ]; then exec /sbin/${INSTALLDTBS} "$@"; fi
+
+DTC=./scripts/dtc/dtc
+
+# Default install
+[ -d "$2" ] && rm -rf "$2"
+
+mkdir -p "$2"
+
+for dtb in `find "$3" -name "*.dtb"`; do
+	# we use dtc to parse the dtb, get the board compatible string,
+	# and then copy the dtb to $2/${board_compatible}.dtb
+	compat="`$DTC -I dtb -O compat "$dtb"`"
+
+	if [ -e "$2/${compat}.dtb" ]; then
+		echo "Install $dtb: $2/${compat}.dtb already exists!" 1>&2
+		exit 1
+	else
+		cp "$dtb" "$2/${compat}.dtb"
+	fi
+done
-- 
1.8.4.3

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/18/2013 11:38 AM, Jason Cooper wrote:
> Unlike other build products in the Linux kernel, the devicetree blobs
> are simply the name of their source file, s/dts/dtb/.  There is also no
> 'make *install' mechanism to put them in a standard place with a
> standard naming structure.
> 
> Unfortunately, users have begun scripting pulling the needed dtbs from
> within the kernel tree, thus hardcoding the dtbs names.  In turn, this
> means any changes to the dts filenames breaks these scripts.
> 
> This patch is an attempt to fix this problem.  Akin to 'make install',
> this creates a new make target, dtbs_install.  The script that gets
> called defers to a vendor or distribution supplied installdtbs binary,
> if found in the system.  Otherwise, the default action is to install a
> given dtb into
> 
>   /lib/modules/${kernel_version}/devicetree/${board_compat}.dtb

Is co-mingling the DTs in the same (top-level) directory as modules a
good idea. I guess there is an explicit devicetree/ sub-directory so
they're easy to pull out of the source tree, but even so, they're
certainly not modules. I would assume that distros would put them into
e.g. /boot/dtbs/${kernelversion} or something more like that. Would it
make sense for the install target to use a path more like that, or
perhaps at least /dtbs/${kernelversion} to keep it separate from modules?

Sorry for the bikeshedding.

> diff --git a/arch/arm/Makefile b/arch/arm/Makefile

> +dtbs_install: dtbs
> +	$(CONFIG_SHELL) $(srctree)/$(boot)/installdtbs.sh $(KERNELRELEASE) \
> +	"$(MODLIB)/devicetree" "$(srctree)/$(boot)/dts"

Architectures besides ARM use device trees. Shouldn't "make
dtbs_install" work for them too?

> diff --git a/arch/arm/boot/installdtbs.sh b/arch/arm/boot/installdtbs.sh

> +for dtb in `find "$3" -name "*.dtb"`; do
> +	# we use dtc to parse the dtb, get the board compatible string,
> +	# and then copy the dtb to $2/${board_compatible}.dtb
> +	compat="`$DTC -I dtb -O compat "$dtb"`"
> +
> +	if [ -e "$2/${compat}.dtb" ]; then
> +		echo "Install $dtb: $2/${compat}.dtb already exists!" 1>&2
> +		exit 1
> +	else
> +		cp "$dtb" "$2/${compat}.dtb"
> +	fi
> +done

This only appears to create ${compat}.dtb, and not ${dtb} too. So, it
doesn't seem to address part of the cover letter, "In addition, some
vendors have done a diligent job naming their devicetree source files
appropriately and we don't want to break their setups." Was that
deliberate? If so, I guess I need to send some patches to U-Boot.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

On Mon, Nov 18, 2013 at 12:09:19PM -0700, Stephen Warren wrote:
> On 11/18/2013 11:38 AM, Jason Cooper wrote:
> > Unlike other build products in the Linux kernel, the devicetree blobs
> > are simply the name of their source file, s/dts/dtb/.  There is also no
> > 'make *install' mechanism to put them in a standard place with a
> > standard naming structure.
> > 
> > Unfortunately, users have begun scripting pulling the needed dtbs from
> > within the kernel tree, thus hardcoding the dtbs names.  In turn, this
> > means any changes to the dts filenames breaks these scripts.
> > 
> > This patch is an attempt to fix this problem.  Akin to 'make install',
> > this creates a new make target, dtbs_install.  The script that gets
> > called defers to a vendor or distribution supplied installdtbs binary,
> > if found in the system.  Otherwise, the default action is to install a
> > given dtb into
> > 
> >   /lib/modules/${kernel_version}/devicetree/${board_compat}.dtb
> 
> Is co-mingling the DTs in the same (top-level) directory as modules a
> good idea. I guess there is an explicit devicetree/ sub-directory so
> they're easy to pull out of the source tree, but even so, they're
> certainly not modules. I would assume that distros would put them into
> e.g. /boot/dtbs/${kernelversion} or something more like that. Would it
> make sense for the install target to use a path more like that, or
> perhaps at least /dtbs/${kernelversion} to keep it separate from modules?

I thought about the proposed /boot/dtbs/${kernelversion} and it didn't
sit well with me.  /boot is for the files needed to boot the machine,
not all the files you *might* need to boot the machine.  I'm speaking
generally, I understand your situation is different.

I tried to follow the analogy of the kernel modules, All of them are
installed in /lib/modules/$kernelversion}, then, the initramfs builder
selects a few modules needed to find the rootfs, etc and packs just
those into the initramfs.

> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> 
> > +dtbs_install: dtbs

This answers below ^^^^

> > +	$(CONFIG_SHELL) $(srctree)/$(boot)/installdtbs.sh $(KERNELRELEASE) \
> > +	"$(MODLIB)/devicetree" "$(srctree)/$(boot)/dts"
> 
> Architectures besides ARM use device trees. Shouldn't "make
> dtbs_install" work for them too?

Yes, once the idea is hammered out, I'll add powerpc/mips/etc.

> > diff --git a/arch/arm/boot/installdtbs.sh b/arch/arm/boot/installdtbs.sh
> 
> > +for dtb in `find "$3" -name "*.dtb"`; do
> > +	# we use dtc to parse the dtb, get the board compatible string,
> > +	# and then copy the dtb to $2/${board_compatible}.dtb
> > +	compat="`$DTC -I dtb -O compat "$dtb"`"
> > +
> > +	if [ -e "$2/${compat}.dtb" ]; then
> > +		echo "Install $dtb: $2/${compat}.dtb already exists!" 1>&2
> > +		exit 1
> > +	else
> > +		cp "$dtb" "$2/${compat}.dtb"
> > +	fi
> > +done
> 
> This only appears to create ${compat}.dtb, and not ${dtb} too. 

See my comment, above.

> So, it doesn't seem to address part of the cover letter, "In addition,
> some vendors have done a diligent job naming their devicetree source
> files appropriately and we don't want to break their setups." Was that
> deliberate? If so, I guess I need to send some patches to U-Boot.

I assume you are still pulling from arch/arm/boot/dts/*.dtb, right?
Those build products don't go away with this patch, so you should be
fine.  Unless I'm mis-understanding your workflow...

thx,

Jason.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/18/2013 12:19 PM, Jason Cooper wrote:
> On Mon, Nov 18, 2013 at 12:09:19PM -0700, Stephen Warren wrote:
>> On 11/18/2013 11:38 AM, Jason Cooper wrote:
>>> Unlike other build products in the Linux kernel, the devicetree blobs
>>> are simply the name of their source file, s/dts/dtb/.  There is also no
>>> 'make *install' mechanism to put them in a standard place with a
>>> standard naming structure.
>>>
>>> Unfortunately, users have begun scripting pulling the needed dtbs from
>>> within the kernel tree, thus hardcoding the dtbs names.  In turn, this
>>> means any changes to the dts filenames breaks these scripts.
>>>
>>> This patch is an attempt to fix this problem.  Akin to 'make install',
>>> this creates a new make target, dtbs_install.  The script that gets
>>> called defers to a vendor or distribution supplied installdtbs binary,
>>> if found in the system.  Otherwise, the default action is to install a
>>> given dtb into
...
>> This only appears to create ${compat}.dtb, and not ${dtb} too. 
> 
> See my comment, above.
> 
>> So, it doesn't seem to address part of the cover letter, "In addition,
>> some vendors have done a diligent job naming their devicetree source
>> files appropriately and we don't want to break their setups." Was that
>> deliberate? If so, I guess I need to send some patches to U-Boot.
> 
> I assume you are still pulling from arch/arm/boot/dts/*.dtb, right?
> Those build products don't go away with this patch, so you should be
> fine.  Unless I'm mis-understanding your workflow...

Yes, but I thought the whole point of this was that everyone would/could
switch to running "make dtbs_install", then pulling out the files from
the install tree, instead of any use-case requiring obtaining files
directly from the source/build tree?

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

On Mon, Nov 18, 2013 at 12:23:48PM -0700, Stephen Warren wrote:
> On 11/18/2013 12:19 PM, Jason Cooper wrote:
> > On Mon, Nov 18, 2013 at 12:09:19PM -0700, Stephen Warren wrote:
> >> On 11/18/2013 11:38 AM, Jason Cooper wrote:
> >>> Unlike other build products in the Linux kernel, the devicetree blobs
> >>> are simply the name of their source file, s/dts/dtb/.  There is also no
> >>> 'make *install' mechanism to put them in a standard place with a
> >>> standard naming structure.
> >>>
> >>> Unfortunately, users have begun scripting pulling the needed dtbs from
> >>> within the kernel tree, thus hardcoding the dtbs names.  In turn, this
> >>> means any changes to the dts filenames breaks these scripts.
> >>>
> >>> This patch is an attempt to fix this problem.  Akin to 'make install',
> >>> this creates a new make target, dtbs_install.  The script that gets
> >>> called defers to a vendor or distribution supplied installdtbs binary,
> >>> if found in the system.  Otherwise, the default action is to install a
> >>> given dtb into
> ...
> >> This only appears to create ${compat}.dtb, and not ${dtb} too. 
> > 
> > See my comment, above.
> > 
> >> So, it doesn't seem to address part of the cover letter, "In addition,
> >> some vendors have done a diligent job naming their devicetree source
> >> files appropriately and we don't want to break their setups." Was that
> >> deliberate? If so, I guess I need to send some patches to U-Boot.
> > 
> > I assume you are still pulling from arch/arm/boot/dts/*.dtb, right?
> > Those build products don't go away with this patch, so you should be
> > fine.  Unless I'm mis-understanding your workflow...
> 
> Yes, but I thought the whole point of this was that everyone would/could
> switch to running "make dtbs_install", then pulling out the files from
> the install tree, instead of any use-case requiring obtaining files
> directly from the source/build tree?

Yes, in the script, it checks for the existence of /sbin/installdtbs.
If it's there, it will override the default behavior and execute that
script.

So yours can be:

#!/bin/sh

[ -d "/boot/dtbs/$1" ] && rm -rf "/boot/dtbs/$1"

mkdir -p "/boot/dtbs/$1"

for dtb in `find "$3" -name "*.dtb"`; do
	cp "$dtb" "/boot/dtbs/$1/${dtb##*/}"
done

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/18/2013 12:28 PM, Jason Cooper wrote:
> On Mon, Nov 18, 2013 at 12:23:48PM -0700, Stephen Warren wrote:
>> On 11/18/2013 12:19 PM, Jason Cooper wrote:
>>> On Mon, Nov 18, 2013 at 12:09:19PM -0700, Stephen Warren wrote:
>>>> On 11/18/2013 11:38 AM, Jason Cooper wrote:
>>>>> Unlike other build products in the Linux kernel, the devicetree blobs
>>>>> are simply the name of their source file, s/dts/dtb/.  There is also no
>>>>> 'make *install' mechanism to put them in a standard place with a
>>>>> standard naming structure.
>>>>>
>>>>> Unfortunately, users have begun scripting pulling the needed dtbs from
>>>>> within the kernel tree, thus hardcoding the dtbs names.  In turn, this
>>>>> means any changes to the dts filenames breaks these scripts.
>>>>>
>>>>> This patch is an attempt to fix this problem.  Akin to 'make install',
>>>>> this creates a new make target, dtbs_install.  The script that gets
>>>>> called defers to a vendor or distribution supplied installdtbs binary,
>>>>> if found in the system.  Otherwise, the default action is to install a
>>>>> given dtb into
>> ...
>>>> This only appears to create ${compat}.dtb, and not ${dtb} too. 
>>>
>>> See my comment, above.
>>>
>>>> So, it doesn't seem to address part of the cover letter, "In addition,
>>>> some vendors have done a diligent job naming their devicetree source
>>>> files appropriately and we don't want to break their setups." Was that
>>>> deliberate? If so, I guess I need to send some patches to U-Boot.
>>>
>>> I assume you are still pulling from arch/arm/boot/dts/*.dtb, right?
>>> Those build products don't go away with this patch, so you should be
>>> fine.  Unless I'm mis-understanding your workflow...
>>
>> Yes, but I thought the whole point of this was that everyone would/could
>> switch to running "make dtbs_install", then pulling out the files from
>> the install tree, instead of any use-case requiring obtaining files
>> directly from the source/build tree?
> 
> Yes, in the script, it checks for the existence of /sbin/installdtbs.
> If it's there, it will override the default behavior and execute that
> script.

But that means everyone (a lot of people, and all distros) has to write,
or at least download and install, such a script. Equally, that script
would incorrectly affect the naming of non-Tegra DTBs that follow the
new convention. The naming of the Tegra DTBs is based more on the fact
that they're the Tegra DTBs than the fact that I'm using them.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

On Mon, Nov 18, 2013 at 12:38:11PM -0700, Stephen Warren wrote:
> On 11/18/2013 12:28 PM, Jason Cooper wrote:
> > On Mon, Nov 18, 2013 at 12:23:48PM -0700, Stephen Warren wrote:
> >> On 11/18/2013 12:19 PM, Jason Cooper wrote:
> >>> On Mon, Nov 18, 2013 at 12:09:19PM -0700, Stephen Warren wrote:
> >>>> On 11/18/2013 11:38 AM, Jason Cooper wrote:
> >>>>> Unlike other build products in the Linux kernel, the devicetree blobs
> >>>>> are simply the name of their source file, s/dts/dtb/.  There is also no
> >>>>> 'make *install' mechanism to put them in a standard place with a
> >>>>> standard naming structure.
> >>>>>
> >>>>> Unfortunately, users have begun scripting pulling the needed dtbs from
> >>>>> within the kernel tree, thus hardcoding the dtbs names.  In turn, this
> >>>>> means any changes to the dts filenames breaks these scripts.
> >>>>>
> >>>>> This patch is an attempt to fix this problem.  Akin to 'make install',
> >>>>> this creates a new make target, dtbs_install.  The script that gets
> >>>>> called defers to a vendor or distribution supplied installdtbs binary,
> >>>>> if found in the system.  Otherwise, the default action is to install a
> >>>>> given dtb into
> >> ...
> >>>> This only appears to create ${compat}.dtb, and not ${dtb} too. 
> >>>
> >>> See my comment, above.
> >>>
> >>>> So, it doesn't seem to address part of the cover letter, "In addition,
> >>>> some vendors have done a diligent job naming their devicetree source
> >>>> files appropriately and we don't want to break their setups." Was that
> >>>> deliberate? If so, I guess I need to send some patches to U-Boot.
> >>>
> >>> I assume you are still pulling from arch/arm/boot/dts/*.dtb, right?
> >>> Those build products don't go away with this patch, so you should be
> >>> fine.  Unless I'm mis-understanding your workflow...
> >>
> >> Yes, but I thought the whole point of this was that everyone would/could
> >> switch to running "make dtbs_install", then pulling out the files from
> >> the install tree, instead of any use-case requiring obtaining files
> >> directly from the source/build tree?
> > 
> > Yes, in the script, it checks for the existence of /sbin/installdtbs.
> > If it's there, it will override the default behavior and execute that
> > script.
> 
> But that means everyone (a lot of people, and all distros) has to write,
> or at least download and install, such a script. 

They would already be modifying their build environment to make use of
'make dtbs_install', and few extra lines of shell script to integrate
with existing systems certainly isn't unreasonable?

> Equally, that script would incorrectly affect the naming of non-Tegra
> DTBs that follow the new convention. The naming of the Tegra DTBs is
> based more on the fact that they're the Tegra DTBs than the fact that
> I'm using them.

Umm, I wrote that script in 2 minutes.  I'm sure you could come up with
something Tegra-specific (perhaps using fdtget?) that places only the
Tegra dtbs in the location that works with Tegra's u-boot.

The point is, we're trying to set a reasonable default, _and_ respect
the pre-existing workflows.  I don't think 15 lines of script is too
much to ask.  Especially since it would be written to adopt a *new*
workflow, not fix a workflow broken by callous kernel maintainers. ;-)

thx,

Jason.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/18/2013 12:52 PM, Jason Cooper wrote:
> On Mon, Nov 18, 2013 at 12:38:11PM -0700, Stephen Warren wrote:
>> On 11/18/2013 12:28 PM, Jason Cooper wrote:
>>> On Mon, Nov 18, 2013 at 12:23:48PM -0700, Stephen Warren wrote:
>>>> On 11/18/2013 12:19 PM, Jason Cooper wrote:
>>>>> On Mon, Nov 18, 2013 at 12:09:19PM -0700, Stephen Warren wrote:
>>>>>> On 11/18/2013 11:38 AM, Jason Cooper wrote:
>>>>>>> Unlike other build products in the Linux kernel, the devicetree blobs
>>>>>>> are simply the name of their source file, s/dts/dtb/.  There is also no
>>>>>>> 'make *install' mechanism to put them in a standard place with a
>>>>>>> standard naming structure.
>>>>>>>
>>>>>>> Unfortunately, users have begun scripting pulling the needed dtbs from
>>>>>>> within the kernel tree, thus hardcoding the dtbs names.  In turn, this
>>>>>>> means any changes to the dts filenames breaks these scripts.
>>>>>>>
>>>>>>> This patch is an attempt to fix this problem.  Akin to 'make install',
>>>>>>> this creates a new make target, dtbs_install.  The script that gets
>>>>>>> called defers to a vendor or distribution supplied installdtbs binary,
>>>>>>> if found in the system.  Otherwise, the default action is to install a
>>>>>>> given dtb into
>>>> ...
>>>>>> This only appears to create ${compat}.dtb, and not ${dtb} too. 
>>>>>
>>>>> See my comment, above.
>>>>>
>>>>>> So, it doesn't seem to address part of the cover letter, "In addition,
>>>>>> some vendors have done a diligent job naming their devicetree source
>>>>>> files appropriately and we don't want to break their setups." Was that
>>>>>> deliberate? If so, I guess I need to send some patches to U-Boot.
>>>>>
>>>>> I assume you are still pulling from arch/arm/boot/dts/*.dtb, right?
>>>>> Those build products don't go away with this patch, so you should be
>>>>> fine.  Unless I'm mis-understanding your workflow...
>>>>
>>>> Yes, but I thought the whole point of this was that everyone would/could
>>>> switch to running "make dtbs_install", then pulling out the files from
>>>> the install tree, instead of any use-case requiring obtaining files
>>>> directly from the source/build tree?
>>>
>>> Yes, in the script, it checks for the existence of /sbin/installdtbs.
>>> If it's there, it will override the default behavior and execute that
>>> script.
>>
>> But that means everyone (a lot of people, and all distros) has to write,
>> or at least download and install, such a script. 
> 
> They would already be modifying their build environment to make use of
> 'make dtbs_install', and few extra lines of shell script to integrate
> with existing systems certainly isn't unreasonable?
> 
>> Equally, that script would incorrectly affect the naming of non-Tegra
>> DTBs that follow the new convention. The naming of the Tegra DTBs is
>> based more on the fact that they're the Tegra DTBs than the fact that
>> I'm using them.
> 
> Umm, I wrote that script in 2 minutes.  I'm sure you could come up with
> something Tegra-specific (perhaps using fdtget?) that places only the
> Tegra dtbs in the location that works with Tegra's u-boot.

Again, the point is not that it's hard to write the script. As you
demonstrated, it's easy. The problem is that then, everybody has to do
something different for Tegra, forever. No matter how small the actual
cost of doing it is, it's still non-scalable to require that everyone
know about this special case. I'm not convinced the issue would be
isolated to Tegra either.

The whole point of "make dtbs_install" is that people can run it, and
get the results they're expected to use. If this isn't the case, what
exactly is the point of any of the renaming that "make dtbs_install" is
doing?

Certainly, it makes sense to have a "make dtbs_install" target, to
isolate DTB consumers from the source locations of the DTBs.

However, if "make dtbs_install" is doing anything other than just
copying files (i.e. if it does any kind of renaming at all), then it had
better do *everything* that's required to solve *all* cases, and not
just solve the one case you care about.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Russell King - ARM Linux]

On Mon, Nov 18, 2013 at 03:46:32PM -0700, Stephen Warren wrote:
> Again, the point is not that it's hard to write the script. As you
> demonstrated, it's easy. The problem is that then, everybody has to do
> something different for Tegra, forever. No matter how small the actual
> cost of doing it is, it's still non-scalable to require that everyone
> know about this special case. I'm not convinced the issue would be
> isolated to Tegra either.

That's why there's the facility to allow an override to the script,
just like there's the facility to override the default script when
running "make install".

The script which the kernel uses is just a template for what kernel
developers expect to be the common case.  That's not necessarily what
most distros do.

In fact, most distros today provide their own installation script which
gets run automatically when you do "make install" which copies the
kernel and then rebuilds an initramfs with everything appropriate for
that kernel inside.

Even the distro script can be overridden with a script in ~/bin by the
user running "make install" (which therefore doesn't even have to be
root if installing it into a location accessible by the user.)

This is really no different.  If the as-supplied-by-the-kernel script
doesn't fit your needs, you are free to override it.

What this gives us is the facility for distros to _sanely_ hook into
the kernel build process to obtain the DT files if they so wish.

As for renaming the files from what we have in the kernel, I'd say...
why bother.  What if we have two DT blobs with the same compatible
string (which is not unlikely when you have two configurations for a
platform)?  I'd recommend keeping the names in the kernel tree when
installing.  If a distro needs to find the compatible string, then
that's a bit of parsing they should do.  Otherwise, we lose the ability
to tell users "you need this DT blob file called X" because X will
depend whether it's been installed or not.

And in some cases where getting the wrong DT blob could end up quite
literally destroying your hardware (eg, by setting an LDO regulator to
bypass mode), it's extremely important that anything here is _simple_
and doesn't involve lots of indirection.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

Russell,

On Tue, Nov 19, 2013 at 12:28:01PM +0000, Russell King - ARM Linux wrote:
> As for renaming the files from what we have in the kernel, I'd say...
> why bother.

When I first read your email, I agreed, and started down the path of
dropping the rename, then...

> What if we have two DT blobs with the same compatible string (which is
> not unlikely when you have two configurations for a platform)?

If a board has two different, especially destructive, configurations, it
should have two different compatible strings.  Especially since 90% (I'm
swagging) of a distro's use of dtbs is to upgrade the dtb on an already
installed system.  They'll most likely pull the board compatible string
from /proc/device-tree/compatible, and then go hunt for the dtb.

That's why I prefer to rename the dtbs, it removes the need to parse the
dtb (fdtget *isn't* currently built/installed by default in dtc), and it
allows distros, for the most common use case, to easily find a matching
dtb on an existing system.

In the event that an already deployed dtb is found to have an alternate
rev (with or without destructive changes), on our side, we add a more
specific compatible string and a new dts for the new rev.  The distro
dtb upgrader detects it's on a 'globalscale,mirabox' and sees that the
options are now globalscale,mirabox-rev1.dtb and
globalscale,mirabox-rev2.dtb.  It throws up a user prompt asking the
user to determine which board rev it's on.  Or, if safe to do so, it
programatically determines which rev it is on and updates the dtb.

> I'd recommend keeping the names in the kernel tree when installing.
> If a distro needs to find the compatible string, then that's a bit of
> parsing they should do.  Otherwise, we lose the ability to tell users
> "you need this DT blob file called X" because X will depend whether
> it's been installed or not.

All I'm suggesting doing is extending the same standard we have for
compatible strings at the node level to the board level.  If we don't
change the filename, then we *have* to extend the consistent naming to
the dts files as well.

I think it's just as easy to say "you need globalscale,mirabox-rev1 now"
as anything else.

> And in some cases where getting the wrong DT blob could end up quite
> literally destroying your hardware (eg, by setting an LDO regulator to
> bypass mode), it's extremely important that anything here is _simple_
> and doesn't involve lots of indirection.

kept for context, above.

thx,

Jason.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Russell King - ARM Linux]

On Tue, Nov 19, 2013 at 09:23:36AM -0500, Jason Cooper wrote:
> All I'm suggesting doing is extending the same standard we have for
> compatible strings at the node level to the board level.  If we don't
> change the filename, then we *have* to extend the consistent naming to
> the dts files as well.

That, in itself, is not a bad thing to do, and totally solves the problem.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

Russell,

On Tue, Nov 19, 2013 at 03:02:12PM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 19, 2013 at 09:23:36AM -0500, Jason Cooper wrote:
> > All I'm suggesting doing is extending the same standard we have for
> > compatible strings at the node level to the board level.  If we don't
> > change the filename,

To be clear, by this I meant dtbs_install changing
armada-370-mirabox.dtb to globalscale,mirabox.dtb.

> > then we *have* to extend the consistent naming to the dts files as
> > well.
> 
> That, in itself, is not a bad thing to do, and totally solves the problem.

By "That" are you referring to extending the standard for compatible
strings to the board level, or forcing consistent naming on the dts
files?

thx,

Jason.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Russell King - ARM Linux]

On Tue, Nov 19, 2013 at 10:20:47AM -0500, Jason Cooper wrote:
> By "That" are you referring to extending the standard for compatible
> strings to the board level, or forcing consistent naming on the dts
> files?

A consistent file naming on both the dtb and dts files.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Russell King - ARM Linux]

On Tue, Nov 19, 2013 at 03:21:46PM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 19, 2013 at 10:20:47AM -0500, Jason Cooper wrote:
> > By "That" are you referring to extending the standard for compatible
> > strings to the board level, or forcing consistent naming on the dts
> > files?
> 
> A consistent file naming on both the dtb and dts files.

It's time to knock the idea of naming the DT blobs after the compatible
string on its head as well.  That's really not going to work.  Just
leave the filenames as is, and move the problem into userspace to solve.

Why?

arch/arm/boot/dts/imx28-cfa10036.dts-   compatible = "crystalfontz,cfa10036", "fsl,imx28";
arch/arm/boot/dts/imx28-cfa10037.dts-   compatible = "crystalfontz,cfa10037", "crystalfontz,cfa10036", "fsl,imx28";
arch/arm/boot/dts/imx28-cfa10049.dts-   compatible = "crystalfontz,cfa10049", "crystalfontz,cfa10036", "fsl,imx28";
arch/arm/boot/dts/imx28-cfa10055.dts-   compatible = "crystalfontz,cfa10055", "crystalfontz,cfa10037", "crystalfontz,cfa10036", "fsl,imx28";
arch/arm/boot/dts/imx28-cfa10057.dts-   compatible = "crystalfontz,cfa10057", "crystalfontz,cfa10036", "fsl,imx28";

We already have DT blobs where the compatible string(s) for a DT blob
conflict with other DT blobs.

Using the compatible string as a filename means that you have to choose
one of the above to name the DT blob, whereas the above compatible
strings allow any of those to be used with "crystalfontz,cfa10036".

So, given a platform with "crystalfontz,cfa10036" you may wish to
offer to the user to select one of those five.  How do you do that
if you've named the files after the compatible string (maybe the
first compatible string.)

See - by doing this, you are building policy into the kernel build
system and potentially taking away choice from userspace.

Just use the filenames we already have in the kernel tree.  Let userspace
parse the DT blobs for the compatible strings - it can then provide the
user with the choice of all and _also_ show that certain of DT blobs
may be compatible with a range of boards as well.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

On Tue, Nov 19, 2013 at 07:22:46PM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 19, 2013 at 03:21:46PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Nov 19, 2013 at 10:20:47AM -0500, Jason Cooper wrote:
> > > By "That" are you referring to extending the standard for compatible
> > > strings to the board level, or forcing consistent naming on the dts
> > > files?
> > 
> > A consistent file naming on both the dtb and dts files.
> 
> It's time to knock the idea of naming the DT blobs after the compatible
> string on its head as well.  That's really not going to work.  Just
> leave the filenames as is, and move the problem into userspace to solve.

Ack, I was working my way towards that anyway.

> See - by doing this, you are building policy into the kernel build
> system and potentially taking away choice from userspace.

And this is my reason for dropping the idea.  Thanks for clarifying it
for me.  I'll submit a non-RFC version that just copies the files
without the name change.

thx,

Jason.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Grant Likely]

On Tue, 19 Nov 2013 19:22:46 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Tue, Nov 19, 2013 at 03:21:46PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Nov 19, 2013 at 10:20:47AM -0500, Jason Cooper wrote:
> > > By "That" are you referring to extending the standard for compatible
> > > strings to the board level, or forcing consistent naming on the dts
> > > files?
> > 
> > A consistent file naming on both the dtb and dts files.
> 
> It's time to knock the idea of naming the DT blobs after the compatible
> string on its head as well.  That's really not going to work.  Just
> leave the filenames as is, and move the problem into userspace to solve.
> 
[...]
> 
> Just use the filenames we already have in the kernel tree.  Let userspace
> parse the DT blobs for the compatible strings - it can then provide the
> user with the choice of all and _also_ show that certain of DT blobs
> may be compatible with a range of boards as well.

Yes, the consistent filename format is a non-problem. The files that
exist already have names. Nothing else is going to use them. Done. It
makes total sense to require that new files follow some sane naming
convention, but it is a mistake to project that back and say all
existing files must also be renamed.

Sure it may look untidy, particularly to those of us with
obsessive-compulsive tendencies, but it isn't actually a problem.

g.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Russell King - ARM Linux]

On Wed, Nov 20, 2013 at 01:10:04PM +0000, Grant Likely wrote:
> On Tue, 19 Nov 2013 19:22:46 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > On Tue, Nov 19, 2013 at 03:21:46PM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Nov 19, 2013 at 10:20:47AM -0500, Jason Cooper wrote:
> > > > By "That" are you referring to extending the standard for compatible
> > > > strings to the board level, or forcing consistent naming on the dts
> > > > files?
> > > 
> > > A consistent file naming on both the dtb and dts files.
> > 
> > It's time to knock the idea of naming the DT blobs after the compatible
> > string on its head as well.  That's really not going to work.  Just
> > leave the filenames as is, and move the problem into userspace to solve.
> > 
> [...]
> > 
> > Just use the filenames we already have in the kernel tree.  Let userspace
> > parse the DT blobs for the compatible strings - it can then provide the
> > user with the choice of all and _also_ show that certain of DT blobs
> > may be compatible with a range of boards as well.
> 
> Yes, the consistent filename format is a non-problem. The files that
> exist already have names. Nothing else is going to use them. Done.

Grant, you have the wrong end of the stick.  This discussion is about
what happens when files from

	$(objtree)/arch/arm/boot/dts

get installed into

	/lib/modules/$(kernelversion)/...

and their renaming from the filenames we already have in arch/arm/boot/dts
to a filename generated from the compatible string.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Grant Likely]

On Wed, 20 Nov 2013 13:56:18 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Wed, Nov 20, 2013 at 01:10:04PM +0000, Grant Likely wrote:
> > On Tue, 19 Nov 2013 19:22:46 +0000, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > > On Tue, Nov 19, 2013 at 03:21:46PM +0000, Russell King - ARM Linux wrote:
> > > > On Tue, Nov 19, 2013 at 10:20:47AM -0500, Jason Cooper wrote:
> > > > > By "That" are you referring to extending the standard for compatible
> > > > > strings to the board level, or forcing consistent naming on the dts
> > > > > files?
> > > > 
> > > > A consistent file naming on both the dtb and dts files.
> > > 
> > > It's time to knock the idea of naming the DT blobs after the compatible
> > > string on its head as well.  That's really not going to work.  Just
> > > leave the filenames as is, and move the problem into userspace to solve.
> > > 
> > [...]
> > > 
> > > Just use the filenames we already have in the kernel tree.  Let userspace
> > > parse the DT blobs for the compatible strings - it can then provide the
> > > user with the choice of all and _also_ show that certain of DT blobs
> > > may be compatible with a range of boards as well.
> > 
> > Yes, the consistent filename format is a non-problem. The files that
> > exist already have names. Nothing else is going to use them. Done.
> 
> Grant, you have the wrong end of the stick.  This discussion is about
> what happens when files from
> 
> 	$(objtree)/arch/arm/boot/dts
> 
> get installed into
> 
> 	/lib/modules/$(kernelversion)/...
> 
> and their renaming from the filenames we already have in arch/arm/boot/dts
> to a filename generated from the compatible string.

Umm, I don't follow where we're having a disconnect. That is what I'm
talking about. I'm arguing that renaming the files with installing them
is a bad idea. Are you not arguing the same here?

g.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

On Wed, Nov 20, 2013 at 01:10:04PM +0000, Grant Likely wrote:
> Sure it may look untidy, particularly to those of us with
> obsessive-compulsive tendencies, but it isn't actually a problem.

Hey!  I resemble that remark! :)

thx,

Jason.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/19/2013 07:23 AM, Jason Cooper wrote:
...
> That's why I prefer to rename the dtbs, it removes the need to parse the
> dtb (fdtget *isn't* currently built/installed by default in dtc)

fdtget is in fact both built and installed by default. At the very least
in the latest dtc source, and it's certainly part of at least the Ubuntu
packages for older versions too, so I assume it's been the default for a
while.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

On Tue, Nov 19, 2013 at 11:40:36AM -0700, Stephen Warren wrote:
> On 11/19/2013 07:23 AM, Jason Cooper wrote:
> ...
> > That's why I prefer to rename the dtbs, it removes the need to parse the
> > dtb (fdtget *isn't* currently built/installed by default in dtc)
> 
> fdtget is in fact both built and installed by default. At the very least
> in the latest dtc source, and it's certainly part of at least the Ubuntu
> packages for older versions too, so I assume it's been the default for a
> while.

Ah.  Gentoo must be the weird one. :(

thx,

Jason.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/19/2013 05:28 AM, Russell King - ARM Linux wrote:
> On Mon, Nov 18, 2013 at 03:46:32PM -0700, Stephen Warren wrote:
>> Again, the point is not that it's hard to write the script. As you
>> demonstrated, it's easy. The problem is that then, everybody has to do
>> something different for Tegra, forever. No matter how small the actual
>> cost of doing it is, it's still non-scalable to require that everyone
>> know about this special case. I'm not convinced the issue would be
>> isolated to Tegra either.
> 
> That's why there's the facility to allow an override to the script,
> just like there's the facility to override the default script when
> running "make install".

Again, you are completely missing the point about that not scaling at all.

But I will go and investigate what it takes to support renaming the
DTBs. Everyone (using Tegra) will have to update their bootloader, but
perhaps that can be dealt with.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Russell King - ARM Linux]

On Tue, Nov 19, 2013 at 11:42:17AM -0700, Stephen Warren wrote:
> On 11/19/2013 05:28 AM, Russell King - ARM Linux wrote:
> > On Mon, Nov 18, 2013 at 03:46:32PM -0700, Stephen Warren wrote:
> >> Again, the point is not that it's hard to write the script. As you
> >> demonstrated, it's easy. The problem is that then, everybody has to do
> >> something different for Tegra, forever. No matter how small the actual
> >> cost of doing it is, it's still non-scalable to require that everyone
> >> know about this special case. I'm not convinced the issue would be
> >> isolated to Tegra either.
> > 
> > That's why there's the facility to allow an override to the script,
> > just like there's the facility to override the default script when
> > running "make install".
> 
> Again, you are completely missing the point about that not scaling at all.

No I'm not.  What you're looking for is perfection.  Perfection is something
we can't have here - we can have "good enough".

Look, the problem is very simple: we have a bunch of DT descriptions in
the kernel, which we build to a blob.  We don't want distributions poking
around in the kernel source tree to retrieve these blobs, so we provide
a way to install them somewhere.

The installation should just copy the blobs to a path in the filesystem
_or_ allow a distro to hook into the installation process, just like we
provide for the installation of the zImage.  That is our job done.  We
should do *nothing* more.

If we start doing more than that, we're getting into the realms of
distribution policy, and that's something we should not be involved in.

This is precisely the reason why we don't get involved with working out
what steps are needed to install a kernel zImage onto a target: that
is _not_ the kernel's job to work out that you may need to package it
up and maybe copy it over to a TFTP server, or maybe copy it onto a SD
card, or maybe place it in /boot and do a certain number of other
steps.

All that the kernel build's job here is to provide the results of the
kernel build.  It is not about working out which DT blob is right for
any particular platform.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/19/2013 11:52 AM, Russell King - ARM Linux wrote:
> On Tue, Nov 19, 2013 at 11:42:17AM -0700, Stephen Warren wrote:
>> On 11/19/2013 05:28 AM, Russell King - ARM Linux wrote:
>>> On Mon, Nov 18, 2013 at 03:46:32PM -0700, Stephen Warren wrote:
>>>> Again, the point is not that it's hard to write the script. As you
>>>> demonstrated, it's easy. The problem is that then, everybody has to do
>>>> something different for Tegra, forever. No matter how small the actual
>>>> cost of doing it is, it's still non-scalable to require that everyone
>>>> know about this special case. I'm not convinced the issue would be
>>>> isolated to Tegra either.
>>>
>>> That's why there's the facility to allow an override to the script,
>>> just like there's the facility to override the default script when
>>> running "make install".
>>
>> Again, you are completely missing the point about that not scaling at all.
> 
> No I'm not.  What you're looking for is perfection.  Perfection is something
> we can't have here - we can have "good enough".

For the issue I care about, it's not hard to have perfection. Why
wouldn't I want that.

Reading your comments below, I think we're talking about slightly
different aspects of the problem though.

> Look, the problem is very simple: we have a bunch of DT descriptions in
> the kernel, which we build to a blob.  We don't want distributions poking
> around in the kernel source tree to retrieve these blobs, so we provide
> a way to install them somewhere.

Sure. I have no problem at all if the kernel implemnts a "make
dtbs_install" target. It certainly should.

> The installation should just copy the blobs to a path in the filesystem
> _or_ allow a distro to hook into the installation process, just like we
> provide for the installation of the zImage.  That is our job done.  We
> should do *nothing* more.

OK, if you're arguing that there should be absolutely zero renaming at
all under any circumstances, I'm fine with that.

My argument was that the proposed renaming step (renaming the DTBs based
on the top-level compatible) is not appropriate for Tegra, even if it is
what some other platforms might want. My issue could be addressed by any of:

a) Never renaming anything. I believe this is what you're arguing for.

b) Having some kind of in-kernel list of DTs that do get renamed, and
those that don't. Tegra DTs would be in the latter don't-rename list.

c) Simply renaming any DT source files in the kernel that are perceived
to have the wrong name currently, rather than renaming during each "make
dtbs_install". Tegra DTs currently have the correct name, so wouldn't be
renamed.

I'm fine with any of those solutions. (a) or (c) seem simplest to me.

> If we start doing more than that, we're getting into the realms of
> distribution policy, and that's something we should not be involved in.
> 
> This is precisely the reason why we don't get involved with working out
> what steps are needed to install a kernel zImage onto a target: that
> is _not_ the kernel's job to work out that you may need to package it
> up and maybe copy it over to a TFTP server, or maybe copy it onto a SD
> card, or maybe place it in /boot and do a certain number of other
> steps.
> 
> All that the kernel build's job here is to provide the results of the
> kernel build.  It is not about working out which DT blob is right for
> any particular platform.

For the record, I was never talking about the kernel selecting a
particular DTB to install, or a particular DTB for a target. I assume
that "make dtbs_install" always installs all DTBs that the kernel built.
The discussion in this thread has been about (re-)naming not selecting
DTBs. It's up to some out-of-kernel process to pick which (or all) of
those to actually use.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Russell King - ARM Linux]

On Tue, Nov 19, 2013 at 12:27:01PM -0700, Stephen Warren wrote:
> On 11/19/2013 11:52 AM, Russell King - ARM Linux wrote:
> > The installation should just copy the blobs to a path in the filesystem
> > _or_ allow a distro to hook into the installation process, just like we
> > provide for the installation of the zImage.  That is our job done.  We
> > should do *nothing* more.
> 
> OK, if you're arguing that there should be absolutely zero renaming at
> all under any circumstances, I'm fine with that.

That's what I'm arguing for.  Consider what happens when we need to
identify a specific DT blob to be used for a board:

"For the Zynteknology Amazingboard, you need to use the DT file
imx6dl-amazingboard.dtb".

What happens if we have an installation system which renames the files?

"For the Zynteknology Amazingboard, you need to use the DT file
imx6dl-amazingboard.dtb, but this may also be named
zynteknology,amazingboard.dtb on installation".

Now, the user has to work out which of two filenames instead of just one,
and it becomes a lot harder - it's not difficult for _us_ developers, but
from the user point of view, it is, because there is now two things they
have to deal with, and a greater chance of making an error.

Now, as for using the compatible strings, if you look at the email I just
sent previously, I've shown why naming DT blobs by their compatible string
is a stupid thing to do.  I'll go further: it's an idiotic thing which
can't work.

We already have DT blobs which contain a _range_ of compatible strings.
Does that mean we always choose the first compatible string?  If you're
using that to match up a DT blob, you've just failed because what if
your platform needs to match against the second compatible string?

Use symlinks for all compatible strings?  Well, what if you have two DT
blobs which contain the same compatible string?  Yes, we do have lots
which fall into this case already.

Hence, naming files by compatible string _can't_ ever work sanely.  It
assumes that compatible strings are unique.  They plainly aren't.

So, I think we keep the existing naming scheme and just copy the files
as is to the installation location.  Anything more than that is a
"distro" choice - if a distro wants to offer the user a list of DT
images to use, the distro needs a tool which parses the compatible
strings, works out which of the files match the target, and present the
user with that choice - because we already have the case where there is
no 1:1 relationship between files and board.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

On Tue, Nov 19, 2013 at 11:42:17AM -0700, Stephen Warren wrote:
> On 11/19/2013 05:28 AM, Russell King - ARM Linux wrote:
> > On Mon, Nov 18, 2013 at 03:46:32PM -0700, Stephen Warren wrote:
> >> Again, the point is not that it's hard to write the script. As you
> >> demonstrated, it's easy. The problem is that then, everybody has to do
> >> something different for Tegra, forever. No matter how small the actual
> >> cost of doing it is, it's still non-scalable to require that everyone
> >> know about this special case. I'm not convinced the issue would be
> >> isolated to Tegra either.
> > 
> > That's why there's the facility to allow an override to the script,
> > just like there's the facility to override the default script when
> > running "make install".
> 
> Again, you are completely missing the point about that not scaling at all.
> 
> But I will go and investigate what it takes to support renaming the
> DTBs. Everyone (using Tegra) will have to update their bootloader, but
> perhaps that can be dealt with.

Setting aside the idea of hard-coding filenames into any bootloader
binary, did you catch that the proposed solution would allow you to
continue using the dts filenames as they currently are?

The find command in my example /sbin/installdtbs script spits out the
in-tree dtb filename as it currently stands, and then you do what you
want with it in your script.  Including, copying it, filename intact,
into the location of your choice.  How could that possibly require you
to upgrade your bootloader?

I must admit I'm a bit mystified as to what Tegra is doing that this
breaks it so horribly...

thx,

Jason.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/19/2013 11:57 AM, Jason Cooper wrote:
> On Tue, Nov 19, 2013 at 11:42:17AM -0700, Stephen Warren wrote:
>> On 11/19/2013 05:28 AM, Russell King - ARM Linux wrote:
>>> On Mon, Nov 18, 2013 at 03:46:32PM -0700, Stephen Warren wrote:
>>>> Again, the point is not that it's hard to write the script. As you
>>>> demonstrated, it's easy. The problem is that then, everybody has to do
>>>> something different for Tegra, forever. No matter how small the actual
>>>> cost of doing it is, it's still non-scalable to require that everyone
>>>> know about this special case. I'm not convinced the issue would be
>>>> isolated to Tegra either.
>>>
>>> That's why there's the facility to allow an override to the script,
>>> just like there's the facility to override the default script when
>>> running "make install".
>>
>> Again, you are completely missing the point about that not scaling at all.
>>
>> But I will go and investigate what it takes to support renaming the
>> DTBs. Everyone (using Tegra) will have to update their bootloader, but
>> perhaps that can be dealt with.
> 
> Setting aside the idea of hard-coding filenames into any bootloader
> binary, did you catch that the proposed solution would allow you to
> continue using the dts filenames as they currently are?

I don't consider requiring people to install a custom /sbin/installdtbs
in order to override renaming done by the default in-kernel
scripts/installdtbs a solution.

Think of a distro that wants to support 5 different SoCs. If they
install a custom /sbin/installdtbs that does zero renaming, then they'll
get the desired DTB names for Tegra, but perhaps not for other SoCs. If
the don't install a custom /sbin/installdtbs that does zero renaming,
then they'll perhaps get the desired DTB names for SoCs other than
Tegra, but won't for Tegra.

Assuming we ever rename DTBs at all, there are a couple ways to solve this:

a) Require everyone who runs "make dtbs_install" (and who cares about
multiple SoCs, i.e. all distros at least) to install (and perhaps write)
their own custom /sbin/installdtbs that only renames some DTBs.

b) Just put the correct logic in the in-kernel installdtbs script, so
nobody has to do anything; it "just works" out-of-the-box.

> The find command in my example /sbin/installdtbs script spits out the
> in-tree dtb filename as it currently stands, and then you do what you
> want with it in your script.  Including, copying it, filename intact,
> into the location of your choice.  How could that possibly require you
> to upgrade your bootloader?

A "solution" that requires people to install custom scripts to undo
renaming that shouldn't be happening in the first place just isn't
workable; there's too much communication and support cost associated
with it.

So, if the renaming during "make dtbs_install" absolutely has to happen,
then I guess I'd just have to live with it, and force everyone to
upgrade their bootloader instead.

> I must admit I'm a bit mystified as to what Tegra is doing that this
> breaks it so horribly...

The idea is that a disto boot process runs as follow:

* U-Boot runs and initializes.

* U-Boot searches the boot disk (or any disk that could be a boot disk)
for e.g. /boot/boot.scr, and executes it.

* boot.scr loads the kernel, initrd, DTB, sets up the command-line, and
boots the kernel.

A few points to make here:

a) There must be a boot.scr or similar on disk, to provide a way for
distros to parameterize the boot process. At the very least they need to
configure the kernel command-line, specify whether an initrd is used at
all, etc.

b) boot.scr is responsible for loading the zImage etc. from disk, rather
than the default U-Boot environment doing this. This allows distros
complete flexibility re: where to put the zImage etc. on disk. On distro
might store a single copy in /boot/zImage, another might use
/boot/zImage-${kernelversion}, another might use
/boot/${kernelversion}/zImage, etc. By putting the onus on boot.scr to
do the loading, the distro has complete flexibility in file naming here.

c) There are a number of system-specific parameters required to
implement zImage/DTB loading. For example, the SDRAM address that they
should be loaded to. Distros shouldn't have to detect which board
they're running on and calculate the values of all those parameters.
Instead, U-Boot should provide the values to boot.scr, by setting
certain standard variables in the environment.

For example, the zImage gets loaded to $kernel_addr_r, the DTB to
$fdt_addr_r, etc.

d) Finally, boot.scr needs to load the DTB. This requires knowing which
DTB to load. Again, the distro shouldn't have to detect which board
they're running on, and either install the correct DTB to a static
filename, or make a decision on the DTB filename to load. Instead,
distros should simply install all DTBs generated by the kernel build,
and use some run-time information to calculate the DTB filename using a
completely HW-agnostic and generic algorithm.

To support this, U-Boot can be configured to add certain standard
environment variables to the default environment. These define which SoC
and board the code is running on. These are ${soc} and ${board}. If you
then calculate the DTB filename as ${soc}-${board}.dtb, that should work
anywhere. This is why keeping the current in-kernel DTB filenames is
important, so they match the assumption that this algorithm works.

Note: if the firmware contains an embedded DTB, boot.scr could detect
this e.g. by the standard variable $fdt_addr being set, and hence skiip
loading a DTB. IIRC, this is how Calxeda boards are set up.


So finally, if the kernel "make dtbs_install" starts renaming DTB files,
then I need to adjust the boot.scr we're using to use some other
algorithm to calculate the DTB filename. Given the filename isn't then
purely derived from ${soc} and ${board}, I probably need to set up some
additional (or replacement) variables in the standard U-Boot environment
that contain the extra fields required to calculate the DTB filename.
The existing ${vendor} might work. However, it'd be simplest if I just
had U-Boot export something like ${dtb_filename}, which contained the
(or a list of) filenames to try.

You can take a look at my boot.scr generation tool at:
https://github.com/NVIDIA/tegra-uboot-scripts

That probably works on the Raspberry Pi too (since I set up the Pi's
U-Boot port to work the same way) and likely would require minimal
changes to work on at least some TI and Calxeda boards.

The idea is that eventually, and board that wants to support a generic
distro booting on it would export the standard variables I mentioned
above, have a default U-Boot environment that simply searched for and
executed boot.scr, and distros would use a generic boot.scr as generated
by the tool I linked to above.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

On Tue, Nov 19, 2013 at 12:53:07PM -0700, Stephen Warren wrote:
> On 11/19/2013 11:57 AM, Jason Cooper wrote:
> > On Tue, Nov 19, 2013 at 11:42:17AM -0700, Stephen Warren wrote:
> >> On 11/19/2013 05:28 AM, Russell King - ARM Linux wrote:
> >>> On Mon, Nov 18, 2013 at 03:46:32PM -0700, Stephen Warren wrote:
> >>>> Again, the point is not that it's hard to write the script. As you
> >>>> demonstrated, it's easy. The problem is that then, everybody has to do
> >>>> something different for Tegra, forever. No matter how small the actual
> >>>> cost of doing it is, it's still non-scalable to require that everyone
> >>>> know about this special case. I'm not convinced the issue would be
> >>>> isolated to Tegra either.
> >>>
> >>> That's why there's the facility to allow an override to the script,
> >>> just like there's the facility to override the default script when
> >>> running "make install".
> >>
> >> Again, you are completely missing the point about that not scaling at all.
> >>
> >> But I will go and investigate what it takes to support renaming the
> >> DTBs. Everyone (using Tegra) will have to update their bootloader, but
> >> perhaps that can be dealt with.
> > 
> > Setting aside the idea of hard-coding filenames into any bootloader
> > binary, did you catch that the proposed solution would allow you to
> > continue using the dts filenames as they currently are?
> 
> I don't consider requiring people to install a custom /sbin/installdtbs
> in order to override renaming done by the default in-kernel
> scripts/installdtbs a solution.

Russell's point about not creating policy for userspace is on the mark.
*I* think the most-specific compatible string should be unique per
board, and thus would be a sane naming scheme.  But that is exactly as
Russell said making policy for userspace.  If you said as much, I missed
it.  Sorry about that.

Now, off on a tangent...

> > I must admit I'm a bit mystified as to what Tegra is doing that this
> > breaks it so horribly...
> 
> The idea is that a disto boot process runs as follow:
> 
> * U-Boot runs and initializes.
> 
> * U-Boot searches the boot disk (or any disk that could be a boot disk)
> for e.g. /boot/boot.scr, and executes it.
> 
> * boot.scr loads the kernel, initrd, DTB, sets up the command-line, and
> boots the kernel.
> 
> A few points to make here:
> 
> a) There must be a boot.scr or similar on disk, to provide a way for
> distros to parameterize the boot process. At the very least they need to
> configure the kernel command-line, specify whether an initrd is used at
> all, etc.
> 
> b) boot.scr is responsible for loading the zImage etc. from disk, rather
> than the default U-Boot environment doing this. This allows distros
> complete flexibility re: where to put the zImage etc. on disk. On distro
> might store a single copy in /boot/zImage, another might use
> /boot/zImage-${kernelversion}, another might use
> /boot/${kernelversion}/zImage, etc. By putting the onus on boot.scr to
> do the loading, the distro has complete flexibility in file naming here.
> 
> c) There are a number of system-specific parameters required to
> implement zImage/DTB loading. For example, the SDRAM address that they
> should be loaded to. Distros shouldn't have to detect which board
> they're running on and calculate the values of all those parameters.
> Instead, U-Boot should provide the values to boot.scr, by setting
> certain standard variables in the environment.
> 
> For example, the zImage gets loaded to $kernel_addr_r, the DTB to
> $fdt_addr_r, etc.
> 
> d) Finally, boot.scr needs to load the DTB. This requires knowing which
> DTB to load. Again, the distro shouldn't have to detect which board
> they're running on, and either install the correct DTB to a static
> filename, or make a decision on the DTB filename to load. Instead,
> distros should simply install all DTBs generated by the kernel build,
> and use some run-time information to calculate the DTB filename using a
> completely HW-agnostic and generic algorithm.
> 
> To support this, U-Boot can be configured to add certain standard
> environment variables to the default environment. These define which SoC
> and board the code is running on. These are ${soc} and ${board}. If you
> then calculate the DTB filename as ${soc}-${board}.dtb, that should work
> anywhere. This is why keeping the current in-kernel DTB filenames is
> important, so they match the assumption that this algorithm works.
> 
> Note: if the firmware contains an embedded DTB, boot.scr could detect
> this e.g. by the standard variable $fdt_addr being set, and hence skiip
> loading a DTB. IIRC, this is how Calxeda boards are set up.

Ok, so the ${soc}-${board} is a work-around until all bootloaders are
providing a dtb, or until all bootloaders are providing a stable dtb?

I ask because in tinkering with pxa-impedance-matcher [1], I've setup
selecting from many dtbs at boot (linked in, no fs support) by
specifying the desired board compatible string on the kernel
commandline (patches still a wip).  The impedance-matcher then scans
through the provided dtbs looking for a match.

It's a hack, and only useful until bootloaders are providing dtbs.  If
the dtb is upgradable, then it goes away earlier.  If the dtb isn't,
then it'll be around longer.  It's goal is to keep silly code out of the
kernel (non-standard atag-to-fdt translation, other bootloader
workarounds).  Perhaps it'll be used to translate ACPI into DT for a
bit... :)

> So finally, if the kernel "make dtbs_install" starts renaming DTB files,
> then I need to adjust the boot.scr we're using to use some other
> algorithm to calculate the DTB filename. Given the filename isn't then
> purely derived from ${soc} and ${board}, I probably need to set up some
> additional (or replacement) variables in the standard U-Boot environment
> that contain the extra fields required to calculate the DTB filename.
> The existing ${vendor} might work. However, it'd be simplest if I just
> had U-Boot export something like ${dtb_filename}, which contained the
> (or a list of) filenames to try.
> 
> You can take a look at my boot.scr generation tool at:
> https://github.com/NVIDIA/tegra-uboot-scripts
> 
> That probably works on the Raspberry Pi too (since I set up the Pi's
> U-Boot port to work the same way) and likely would require minimal
> changes to work on at least some TI and Calxeda boards.
> 
> The idea is that eventually, and board that wants to support a generic
> distro booting on it would export the standard variables I mentioned
> above, have a default U-Boot environment that simply searched for and
> executed boot.scr, and distros would use a generic boot.scr as generated
> by the tool I linked to above.

Thanks for the detailed explanation.  I'll post a non-RFC version in the
next few days.

thx,

Jason.

[1] https://github.com/zonque/pxa-impedance-matcher.git

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/19/2013 01:39 PM, Jason Cooper wrote:
> On Tue, Nov 19, 2013 at 12:53:07PM -0700, Stephen Warren wrote:
...
>> d) Finally, boot.scr needs to load the DTB. This requires knowing which
>> DTB to load. Again, the distro shouldn't have to detect which board
>> they're running on, and either install the correct DTB to a static
>> filename, or make a decision on the DTB filename to load. Instead,
>> distros should simply install all DTBs generated by the kernel build,
>> and use some run-time information to calculate the DTB filename using a
>> completely HW-agnostic and generic algorithm.
>>
>> To support this, U-Boot can be configured to add certain standard
>> environment variables to the default environment. These define which SoC
>> and board the code is running on. These are ${soc} and ${board}. If you
>> then calculate the DTB filename as ${soc}-${board}.dtb, that should work
>> anywhere. This is why keeping the current in-kernel DTB filenames is
>> important, so they match the assumption that this algorithm works.
>>
>> Note: if the firmware contains an embedded DTB, boot.scr could detect
>> this e.g. by the standard variable $fdt_addr being set, and hence skiip
>> loading a DTB. IIRC, this is how Calxeda boards are set up.
> 
> Ok, so the ${soc}-${board} is a work-around until all bootloaders are
> providing a dtb, or until all bootloaders are providing a stable dtb?

I suppose so yes.

However, I'm not really convinced we'll see that many products with a DT
embedded into them that's stable, complete[1], and based on upstream
bindings, in the particularly near future. I think distros will likely
need to deal with DTs-in-filesystems for a while yet. But anyway, either
way should work out just fine.

[1] For example, we aren't that far off some reasonably stable basic
bindings for Tegra now . However, there are still devices we haven't
added to DT at all, so while the DT ABI stability issue is fading, the
need-to-upgrade-your-DTB case still exists to get new features, and
upgrading the DTB via the filesystem is a lot easier and more convenient
than doing so via firmware updates or firmware flashing commands.

[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Grant Likely]

On Tue, 19 Nov 2013 14:06:05 -0700, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/19/2013 01:39 PM, Jason Cooper wrote:
> > On Tue, Nov 19, 2013 at 12:53:07PM -0700, Stephen Warren wrote:
> ...
> >> d) Finally, boot.scr needs to load the DTB. This requires knowing which
> >> DTB to load. Again, the distro shouldn't have to detect which board
> >> they're running on, and either install the correct DTB to a static
> >> filename, or make a decision on the DTB filename to load. Instead,
> >> distros should simply install all DTBs generated by the kernel build,
> >> and use some run-time information to calculate the DTB filename using a
> >> completely HW-agnostic and generic algorithm.
> >>
> >> To support this, U-Boot can be configured to add certain standard
> >> environment variables to the default environment. These define which SoC
> >> and board the code is running on. These are ${soc} and ${board}. If you
> >> then calculate the DTB filename as ${soc}-${board}.dtb, that should work
> >> anywhere. This is why keeping the current in-kernel DTB filenames is
> >> important, so they match the assumption that this algorithm works.
> >>
> >> Note: if the firmware contains an embedded DTB, boot.scr could detect
> >> this e.g. by the standard variable $fdt_addr being set, and hence skiip
> >> loading a DTB. IIRC, this is how Calxeda boards are set up.
> > 
> > Ok, so the ${soc}-${board} is a work-around until all bootloaders are
> > providing a dtb, or until all bootloaders are providing a stable dtb?
> 
> I suppose so yes.
> 
> However, I'm not really convinced we'll see that many products with a DT
> embedded into them that's stable, complete[1], and based on upstream
> bindings, in the particularly near future. I think distros will likely
> need to deal with DTs-in-filesystems for a while yet. But anyway, either
> way should work out just fine.
> 
> [1] For example, we aren't that far off some reasonably stable basic
> bindings for Tegra now . However, there are still devices we haven't
> added to DT at all, so while the DT ABI stability issue is fading, the
> need-to-upgrade-your-DTB case still exists to get new features, and
> upgrading the DTB via the filesystem is a lot easier and more convenient
> than doing so via firmware updates or firmware flashing commands.

I'm completely fine with requiring a DT upgrade to enable new features,
so long as keeping the same DT doesn't cause regress when running on
mainline. Keeping that support enabled in firmware is important.

g.

[RFC PATCH V3 0/2] Add 'make dtbs_install'

[Jason Cooper]

Detailed changelog can be found in each patch.

The kernel community never created a 'dtbs_install' make target for properly
handling the build output of the kernel's devicetree files.  Currently, the dtb
files are simply their source file, s/dts/dtb/.  Users have recently begun
retrieving these files from inside the kernel tree.  Any change to the dts
filenames breaks the scripts of those users.

Before this gets too far along, we'd like to create a standardized method of
installing the dtb files for users to find and use.  In addition, some vendors
have done a diligent job naming their devicetree source files appropriately and
we don't want to break their setups.

This patch series solves both problems by creating a dtbs_install make target
which calls arch/arm/boot/installdtbs.sh.  If /sbin/installdtbs or
~/bin/installdtbs is present, they will be run instead of the default behavior.

The default action is to install a given dtb to

  /lib/modules/${kernel_version}/devicetree/${board_compatible}.dtb

Ideally, the devicetree file should be independent of the kernel version,
however, we aren't there yet.  So, while the devicetree files live in the
kernel source tree, we'll install them as above.  Once they are in their own
repository, this install target can be removed, and users can adjust their
workflow to getting the dtbs from a new location.

Jason Cooper (2):
  scripts: dtc: build fdtget for extracting properties from dtbs
  kbuild: dtbs_install: new make target

 Makefile                     |  3 ++-
 arch/arm/Makefile            |  4 ++++
 arch/arm/boot/installdtbs.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
 scripts/dtc/.gitignore       |  2 +-
 scripts/dtc/Makefile         | 10 +++++++++-
 5 files changed, 60 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/installdtbs.sh

-- 
1.8.4.3

[RFC PATCH V3 1/2] scripts: dtc: build fdtget for extracting properties from dtbs

[Jason Cooper]

In order for 'make dtbs_install' to be maintainable, we need a reliable
way to determine the board compatible string for a given dtb.  fdtget
does that easily as written, but currently isn't built by the kernel.

Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
changes since v2:
 - switch from modifying dtc to building fdtget

changes since v1:
 - made patch against in-tree dtc code to facilitate testing
 - dtc prints compatible string to stdout now, instead of creating symlink
    - should be more flexible for end-users

 scripts/dtc/.gitignore |  2 +-
 scripts/dtc/Makefile   | 10 +++++++++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/scripts/dtc/.gitignore b/scripts/dtc/.gitignore
index 095acb49a374..80f6b50fdf77 100644
--- a/scripts/dtc/.gitignore
+++ b/scripts/dtc/.gitignore
@@ -2,4 +2,4 @@ dtc
 dtc-lexer.lex.c
 dtc-parser.tab.c
 dtc-parser.tab.h
-
+fdtget
diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
index 2a48022c41e7..021522cb76f2 100644
--- a/scripts/dtc/Makefile
+++ b/scripts/dtc/Makefile
@@ -1,12 +1,16 @@
 # scripts/dtc makefile
 
-hostprogs-y	:= dtc
+hostprogs-y	:= dtc fdtget
 always		:= $(hostprogs-y)
 
 dtc-objs	:= dtc.o flattree.o fstree.o data.o livetree.o treesource.o \
 		   srcpos.o checks.o util.o
 dtc-objs	+= dtc-lexer.lex.o dtc-parser.tab.o
 
+include $(src)/libfdt/Makefile.libfdt
+
+fdtget-objs	:= fdtget.o util.o $(patsubst %, libfdt/%, $(LIBFDT_OBJS))
+
 # Source files need to get at the userspace version of libfdt_env.h to compile
 
 HOSTCFLAGS_DTC := -I$(src) -I$(src)/libfdt
@@ -14,6 +18,7 @@ HOSTCFLAGS_DTC := -I$(src) -I$(src)/libfdt
 HOSTCFLAGS_checks.o := $(HOSTCFLAGS_DTC)
 HOSTCFLAGS_data.o := $(HOSTCFLAGS_DTC)
 HOSTCFLAGS_dtc.o := $(HOSTCFLAGS_DTC)
+HOSTCFLAGS_fdtget.o := $(HOSTCFLAGS_DTC)
 HOSTCFLAGS_flattree.o := $(HOSTCFLAGS_DTC)
 HOSTCFLAGS_fstree.o := $(HOSTCFLAGS_DTC)
 HOSTCFLAGS_livetree.o := $(HOSTCFLAGS_DTC)
@@ -21,6 +26,9 @@ HOSTCFLAGS_srcpos.o := $(HOSTCFLAGS_DTC)
 HOSTCFLAGS_treesource.o := $(HOSTCFLAGS_DTC)
 HOSTCFLAGS_util.o := $(HOSTCFLAGS_DTC)
 
+$(foreach file, $(LIBFDT_OBJS), \
+	$(eval HOSTCFLAGS_$(file) = -I$(src)/libfdt))
+
 HOSTCFLAGS_dtc-lexer.lex.o := $(HOSTCFLAGS_DTC)
 HOSTCFLAGS_dtc-parser.tab.o := $(HOSTCFLAGS_DTC)
 
-- 
1.8.4.3

[RFC PATCH V3 1/2] scripts: dtc: build fdtget for extracting properties from dtbs

[Stephen Warren]

On 11/18/2013 02:21 PM, Jason Cooper wrote:
> In order for 'make dtbs_install' to be maintainable, we need a reliable
> way to determine the board compatible string for a given dtb.  fdtget
> does that easily as written, but currently isn't built by the kernel.

> diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile

> +include $(src)/libfdt/Makefile.libfdt
> +
> +fdtget-objs	:= fdtget.o util.o $(patsubst %, libfdt/%, $(LIBFDT_OBJS))

I observe that there's a scripts/dtc/Makefile.dtc that /isn't/ used by
scripts/dtc/Makefile. Hence, having scripts/dtc/Makefile use
scripts/dtc/libfdt/Makefile.libfdt seems slightly inconsistent. That
said, it's probably a good idea to use Makefile.libfdt, so perhaps the
answer here is to update Makefile to use Makefile.dtc sometime, rather
than not use Makefile.libfdt in this patch?

Otherwise, this patch seems to make sense.

[RFC PATCH V3 1/2] scripts: dtc: build fdtget for extracting properties from dtbs

[Grant Likely]

On Mon, 18 Nov 2013 15:54:26 -0700, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/18/2013 02:21 PM, Jason Cooper wrote:
> > In order for 'make dtbs_install' to be maintainable, we need a reliable
> > way to determine the board compatible string for a given dtb.  fdtget
> > does that easily as written, but currently isn't built by the kernel.
> 
> > diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
> 
> > +include $(src)/libfdt/Makefile.libfdt
> > +
> > +fdtget-objs	:= fdtget.o util.o $(patsubst %, libfdt/%, $(LIBFDT_OBJS))
> 
> I observe that there's a scripts/dtc/Makefile.dtc that /isn't/ used by
> scripts/dtc/Makefile. Hence, having scripts/dtc/Makefile use
> scripts/dtc/libfdt/Makefile.libfdt seems slightly inconsistent. That
> said, it's probably a good idea to use Makefile.libfdt, so perhaps the
> answer here is to update Makefile to use Makefile.dtc sometime, rather
> than not use Makefile.libfdt in this patch?

Perhaps. I'll leave that to another patch is someone wants to take it
on. I'm not overly worried though.

Applied, thanks.

g.

[RFC PATCH V3 2/2] kbuild: dtbs_install: new make target

[Jason Cooper]

Unlike other build products in the Linux kernel, the devicetree blobs
are simply the name of their source file, s/dts/dtb/.  There is also no
'make *install' mechanism to put them in a standard place with a
standard naming structure.

Unfortunately, users have begun scripting pulling the needed dtbs from
within the kernel tree, thus hardcoding the dtbs names.  In turn, this
means any changes to the dts filenames breaks these scripts.

This patch is an attempt to fix this problem.  Akin to 'make install',
this creates a new make target, dtbs_install.  The script that gets
called defers to a vendor or distribution supplied installdtbs binary,
if found in the system.  Otherwise, the default action is to install a
given dtb into

  /lib/modules/${kernel_version}/devicetree/${board_compat}.dtb

This solves several problems for us.  The board compatible string should
be unique, this enforces/highlights that.  While devicetrees are
stablilizing, the fact is, devicetrees aren't (yet) independent of
kernel version.  This install target facilitates keeping track of that.

Once the devicetree files are moved to their own repository, this
install target can be removed as users will be modifying their scripts
anyway.

Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
changes since v2:
 - use fdtget instead of a modified dtc to get the board compat string

changes since v1:
 - added this patch

 Makefile                     |  3 ++-
 arch/arm/Makefile            |  4 ++++
 arch/arm/boot/installdtbs.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/installdtbs.sh

diff --git a/Makefile b/Makefile
index 920ad07180c9..29d609e972d6 100644
--- a/Makefile
+++ b/Makefile
@@ -339,6 +339,7 @@ OBJDUMP		= $(CROSS_COMPILE)objdump
 AWK		= awk
 GENKSYMS	= scripts/genksyms/genksyms
 INSTALLKERNEL  := installkernel
+INSTALLDTBS    := installdtbs
 DEPMOD		= /sbin/depmod
 PERL		= perl
 CHECK		= sparse
@@ -391,7 +392,7 @@ KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(S
 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
-export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
+export MAKE AWK GENKSYMS INSTALLKERNEL INSTALLDTBS PERL UTS_MACHINE
 export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c99b1086d83d..c16ebb1e74b0 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -314,6 +314,10 @@ PHONY += dtbs
 dtbs: scripts
 	$(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) dtbs
 
+dtbs_install: dtbs
+	$(CONFIG_SHELL) $(srctree)/$(boot)/installdtbs.sh $(KERNELRELEASE) \
+	"$(MODLIB)/devicetree" "$(srctree)/$(boot)/dts"
+
 # We use MRPROPER_FILES and CLEAN_FILES now
 archclean:
 	$(Q)$(MAKE) $(clean)=$(boot)
diff --git a/arch/arm/boot/installdtbs.sh b/arch/arm/boot/installdtbs.sh
new file mode 100644
index 000000000000..3adef376188f
--- /dev/null
+++ b/arch/arm/boot/installdtbs.sh
@@ -0,0 +1,44 @@
+#!/bin/sh
+#
+# This file is subject to the terms and conditions of the GNU General Public
+# License.  See the file "COPYING" in the main directory of this archive
+# for more details.
+#
+# Copyright (C) 1995 by Linus Torvalds
+#
+# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
+#
+# Further adapted from arch/x86/boot/install.sh by Jason Cooper
+#
+# "make dtbs_install" script
+#
+# Arguments:
+#   $1 - kernel version
+#   $2 - default install path (blank if root directory)
+#   $3 - directory containing dtbs
+#
+
+# User may have a custom install script
+
+if [ -x ~/bin/${INSTALLDTBS} ]; then exec ~/bin/${INSTALLDTBS} "$@"; fi
+if [ -x /sbin/${INSTALLDTBS} ]; then exec /sbin/${INSTALLDTBS} "$@"; fi
+
+FDTGET=./scripts/dtc/fdtget
+
+# Default install
+[ -d "$2" ] && rm -rf "$2"
+
+mkdir -p "$2"
+
+for dtb in `find "$3" -name "*.dtb"`; do
+	# we use fdtget to parse the dtb, get the board compatible string,
+	# and then copy the dtb to $2/${board_compatible}.dtb
+	compat="`$FDTGET -t s "$dtb" / compatible | cut -d ' ' -f 1`"
+
+	if [ -e "$2/${compat}.dtb" ]; then
+		echo "Install $dtb: $2/${compat}.dtb already exists!" 1>&2
+		exit 1
+	else
+		cp "$dtb" "$2/${compat}.dtb"
+	fi
+done
-- 
1.8.4.3

[RFC PATCH V2 1/2] dtc: add 'compat' output option, prints board string

[Grant Likely]

On Mon, 18 Nov 2013 18:38:14 +0000, Jason Cooper <jason@lakedaemon.net> wrote:
> Consumers of the Linux kernel's build products are beginning to hardcode
> the filenames of the dtbs generated.  Since the dtb filenames are
> currently the dts filename s/dts/dtb/, this prevents the kernel
> community from renaming dts files as needed.
> 
> Let's provide a consistent naming structure for consumers to script
> against.  Or at least, as consistent as the dts properties themselves.
> 
> With this patch, adding the '-O compat' option to the dtc commandline
> will cause dtc to parse the provided file, and print out the board
> compatible string to stdout.

Can you use the fdtget tool here instead? It will parse and return
property values for a given .dtb.

It certainly makes sense to post this here for the purpose of review,
but any changes to dtc need to be against the upstream dtc repository.

g.


> This will facilitate an 'installdtbs.sh' script in the kernel for naming
> dtb files by their compatible string, eg:
> 
> $ dtc -I dtb -O compat arch/arm/boot/dts/armada-370-mirabox.dtb
> globalscale,mirabox
> 
> This change will also simplify distribution install scripts that need to
> search through many dtbs to find the right one for a target board.
> 
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> ---
> changes since v1:
>  - made patch against in-tree dtc code to facilitate testing
>  - dtc prints compatible string to stdout now, instead of creating symlink
>     - should be more flexible for end-users
> 
>  scripts/dtc/dtc.c      | 3 +++
>  scripts/dtc/dtc.h      | 1 +
>  scripts/dtc/flattree.c | 9 +++++++++
>  3 files changed, 13 insertions(+)
> 
> diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
> index a375683c1534..89264bb0a3dd 100644
> --- a/scripts/dtc/dtc.c
> +++ b/scripts/dtc/dtc.c
> @@ -68,6 +68,7 @@ static void  __attribute__ ((noreturn)) usage(void)
>  	fprintf(stderr, "\t\tOutput formats are:\n");
>  	fprintf(stderr, "\t\t\tdts - device tree source text\n");
>  	fprintf(stderr, "\t\t\tdtb - device tree blob\n");
> +	fprintf(stderr, "\t\t\tcompat - print board compatible string\n");
>  	fprintf(stderr, "\t\t\tasm - assembler source\n");
>  	fprintf(stderr, "\t-V <output version>\n");
>  	fprintf(stderr, "\t\tBlob version to produce, defaults to %d (relevant for dtb\n\t\tand asm output only)\n", DEFAULT_FDT_VERSION);
> @@ -250,6 +251,8 @@ int main(int argc, char *argv[])
>  		dt_to_blob(outf, bi, outversion);
>  	} else if (streq(outform, "asm")) {
>  		dt_to_asm(outf, bi, outversion);
> +	} else if (streq(outform, "compat")) {
> +		dt_to_compat(bi);
>  	} else if (streq(outform, "null")) {
>  		/* do nothing */
>  	} else {
> diff --git a/scripts/dtc/dtc.h b/scripts/dtc/dtc.h
> index 3e42a071070e..d4e47c697c2f 100644
> --- a/scripts/dtc/dtc.h
> +++ b/scripts/dtc/dtc.h
> @@ -255,6 +255,7 @@ void process_checks(int force, struct boot_info *bi);
>  
>  void dt_to_blob(FILE *f, struct boot_info *bi, int version);
>  void dt_to_asm(FILE *f, struct boot_info *bi, int version);
> +void dt_to_compat(struct boot_info *bi);
>  
>  struct boot_info *dt_from_blob(const char *fname);
>  
> diff --git a/scripts/dtc/flattree.c b/scripts/dtc/flattree.c
> index 665dad7bb465..bdbd3d7e8964 100644
> --- a/scripts/dtc/flattree.c
> +++ b/scripts/dtc/flattree.c
> @@ -577,6 +577,15 @@ void dt_to_asm(FILE *f, struct boot_info *bi, int version)
>  	data_free(strbuf);
>  }
>  
> +void dt_to_compat(struct boot_info *bi)
> +{
> +	struct property *prop;
> +
> +	prop = get_property(bi->dt, "compatible");
> +
> +	printf("%s\n", prop->val.val);
> +}
> +
>  struct inbuf {
>  	char *base, *limit, *ptr;
>  };
> -- 
> 1.8.4.3
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC PATCH V3 2/2] kbuild: dtbs_install: new make target

[Grant Likely]

On Mon, 18 Nov 2013 21:21:06 +0000, Jason Cooper <jason@lakedaemon.net> wrote:
> Unlike other build products in the Linux kernel, the devicetree blobs
> are simply the name of their source file, s/dts/dtb/.  There is also no
> 'make *install' mechanism to put them in a standard place with a
> standard naming structure.
> 
> Unfortunately, users have begun scripting pulling the needed dtbs from
> within the kernel tree, thus hardcoding the dtbs names.  In turn, this
> means any changes to the dts filenames breaks these scripts.
> 
> This patch is an attempt to fix this problem.  Akin to 'make install',
> this creates a new make target, dtbs_install.  The script that gets
> called defers to a vendor or distribution supplied installdtbs binary,
> if found in the system.  Otherwise, the default action is to install a
> given dtb into
> 
>   /lib/modules/${kernel_version}/devicetree/${board_compat}.dtb
> 
> This solves several problems for us.  The board compatible string should
> be unique, this enforces/highlights that.  While devicetrees are
> stablilizing, the fact is, devicetrees aren't (yet) independent of
> kernel version.  This install target facilitates keeping track of that.
> 
> Once the devicetree files are moved to their own repository, this
> install target can be removed as users will be modifying their scripts
> anyway.
> 
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> ---
> changes since v2:
>  - use fdtget instead of a modified dtc to get the board compat string
> 
> changes since v1:
>  - added this patch
> 
>  Makefile                     |  3 ++-
>  arch/arm/Makefile            |  4 ++++
>  arch/arm/boot/installdtbs.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++

Place the script in scripts/ please. There is no need for it to be arm
specific.

>  3 files changed, 50 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/installdtbs.sh
> 
> diff --git a/Makefile b/Makefile
> index 920ad07180c9..29d609e972d6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -339,6 +339,7 @@ OBJDUMP		= $(CROSS_COMPILE)objdump
>  AWK		= awk
>  GENKSYMS	= scripts/genksyms/genksyms
>  INSTALLKERNEL  := installkernel
> +INSTALLDTBS    := installdtbs
>  DEPMOD		= /sbin/depmod
>  PERL		= perl
>  CHECK		= sparse
> @@ -391,7 +392,7 @@ KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(S
>  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
> -export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
> +export MAKE AWK GENKSYMS INSTALLKERNEL INSTALLDTBS PERL UTS_MACHINE
>  export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
>  
>  export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c99b1086d83d..c16ebb1e74b0 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -314,6 +314,10 @@ PHONY += dtbs
>  dtbs: scripts
>  	$(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) dtbs
>  
> +dtbs_install: dtbs
> +	$(CONFIG_SHELL) $(srctree)/$(boot)/installdtbs.sh $(KERNELRELEASE) \
> +	"$(MODLIB)/devicetree" "$(srctree)/$(boot)/dts"
> +
>  # We use MRPROPER_FILES and CLEAN_FILES now
>  archclean:
>  	$(Q)$(MAKE) $(clean)=$(boot)
> diff --git a/arch/arm/boot/installdtbs.sh b/arch/arm/boot/installdtbs.sh
> new file mode 100644
> index 000000000000..3adef376188f
> --- /dev/null
> +++ b/arch/arm/boot/installdtbs.sh
> @@ -0,0 +1,44 @@
> +#!/bin/sh
> +#
> +# This file is subject to the terms and conditions of the GNU General Public
> +# License.  See the file "COPYING" in the main directory of this archive
> +# for more details.
> +#
> +# Copyright (C) 1995 by Linus Torvalds
> +#
> +# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
> +#
> +# Further adapted from arch/x86/boot/install.sh by Jason Cooper
> +#
> +# "make dtbs_install" script
> +#
> +# Arguments:
> +#   $1 - kernel version
> +#   $2 - default install path (blank if root directory)
> +#   $3 - directory containing dtbs
> +#
> +
> +# User may have a custom install script
> +
> +if [ -x ~/bin/${INSTALLDTBS} ]; then exec ~/bin/${INSTALLDTBS} "$@"; fi
> +if [ -x /sbin/${INSTALLDTBS} ]; then exec /sbin/${INSTALLDTBS} "$@"; fi
> +
> +FDTGET=./scripts/dtc/fdtget
> +
> +# Default install
> +[ -d "$2" ] && rm -rf "$2"
> +
> +mkdir -p "$2"
> +
> +for dtb in `find "$3" -name "*.dtb"`; do
> +	# we use fdtget to parse the dtb, get the board compatible string,
> +	# and then copy the dtb to $2/${board_compatible}.dtb
> +	compat="`$FDTGET -t s "$dtb" / compatible | cut -d ' ' -f 1`"
> +
> +	if [ -e "$2/${compat}.dtb" ]; then
> +		echo "Install $dtb: $2/${compat}.dtb already exists!" 1>&2
> +		exit 1
> +	else
> +		cp "$dtb" "$2/${compat}.dtb"
> +	fi

It sounded to me like the question of whether to rename the .dtbs is
still up in the air. Personally, I don't think the naming convention is
as big an issue as has been expressed. If some of the names are a
little non-specific, is that really a big problem? Once a filename is
chosen for a device, then it belongs to that device. New hardware can
always choose a more-specific name.

Regardless, I'll let the debate proceed a bit to see if some consensus
can be formed before acking this patch.

In general though the script looks fine to me.

g.

[PATCH V4] kbuild: dtbs_install: new make target

[Jason Cooper]

Unlike other build products in the Linux kernel, there is no 'make
*install' mechanism to put devicetree blobs in a standard place.

This patch is an attempt to fix this problem.  Akin to 'make install',
this creates a new make target, dtbs_install.  The script that gets
called defers to a distribution or user supplied installdtbs binary,
if found in the system.  Otherwise, the default action is to install a
given dtb into

  /lib/modules/${kernel_version}/devicetree/${dts_filename}.dtb

This is done to keep dtbs from different kernel versions separate until
things have settled down.  Once the dtbs are stable, and not so strongly
linked to the kernel version, the devicetree files will most likely move
to their own repo.  Users will need to upgrade install scripts at that
time.

Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
Question: should I make a note about the filenames not being considered an ABI,
or just let it be?

changes since v3:
 - drop renaming files to ${compat}.dtb (rmk/swarren)
 - move installdtbs.sh to ./scripts/ (gcl)

changes since v2:
 - use fdtget instead of a modified dtc to get the board compat string

changes since v1:
 - added this patch

 Makefile               |  3 ++-
 arch/arm/Makefile      |  4 ++++
 scripts/installdtbs.sh | 33 +++++++++++++++++++++++++++++++++
 3 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 scripts/installdtbs.sh

diff --git a/Makefile b/Makefile
index 920ad07180c9..29d609e972d6 100644
--- a/Makefile
+++ b/Makefile
@@ -339,6 +339,7 @@ OBJDUMP		= $(CROSS_COMPILE)objdump
 AWK		= awk
 GENKSYMS	= scripts/genksyms/genksyms
 INSTALLKERNEL  := installkernel
+INSTALLDTBS    := installdtbs
 DEPMOD		= /sbin/depmod
 PERL		= perl
 CHECK		= sparse
@@ -391,7 +392,7 @@ KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(S
 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
-export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
+export MAKE AWK GENKSYMS INSTALLKERNEL INSTALLDTBS PERL UTS_MACHINE
 export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c99b1086d83d..6c7abfc5eb5e 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -314,6 +314,10 @@ PHONY += dtbs
 dtbs: scripts
 	$(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) dtbs
 
+dtbs_install: dtbs
+	$(CONFIG_SHELL) $(srctree)/scripts/installdtbs.sh $(KERNELRELEASE) \
+	"$(MODLIB)/devicetree" "$(srctree)/$(boot)/dts"
+
 # We use MRPROPER_FILES and CLEAN_FILES now
 archclean:
 	$(Q)$(MAKE) $(clean)=$(boot)
diff --git a/scripts/installdtbs.sh b/scripts/installdtbs.sh
new file mode 100644
index 000000000000..11027f00c3a4
--- /dev/null
+++ b/scripts/installdtbs.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+#
+# This file is subject to the terms and conditions of the GNU General Public
+# License.  See the file "COPYING" in the main directory of this archive
+# for more details.
+#
+# Copyright (C) 1995 by Linus Torvalds
+#
+# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
+#
+# Further adapted from arch/x86/boot/install.sh by Jason Cooper
+#
+# "make dtbs_install" script
+#
+# Arguments:
+#   $1 - kernel version
+#   $2 - default install path (blank if root directory)
+#   $3 - directory containing dtbs
+#
+
+# User may have a custom install script
+
+if [ -x ~/bin/${INSTALLDTBS} ]; then exec ~/bin/${INSTALLDTBS} "$@"; fi
+if [ -x /sbin/${INSTALLDTBS} ]; then exec /sbin/${INSTALLDTBS} "$@"; fi
+
+# Default install
+[ -d "$2" ] && rm -rf "$2"
+
+mkdir -p "$2"
+
+for dtb in `find "$3" -name "*.dtb"`; do
+	cp "$dtb" "$2/${dtb##*/}"
+done
-- 
1.8.4.3

[PATCH V4] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/19/2013 02:27 PM, Jason Cooper wrote:
> Unlike other build products in the Linux kernel, there is no 'make
> *install' mechanism to put devicetree blobs in a standard place.
> 
> This patch is an attempt to fix this problem.  Akin to 'make install',
> this creates a new make target, dtbs_install.  The script that gets
> called defers to a distribution or user supplied installdtbs binary,
> if found in the system.  Otherwise, the default action is to install a
> given dtb into
> 
>   /lib/modules/${kernel_version}/devicetree/${dts_filename}.dtb

I still don't see why you wouldn't install the files in
/lib/devicetrees, but I suppose that location is fine.

> This is done to keep dtbs from different kernel versions separate until
> things have settled down.  Once the dtbs are stable, and not so strongly
> linked to the kernel version, the devicetree files will most likely move
> to their own repo.  Users will need to upgrade install scripts at that
> time.
> 
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> ---
> Question: should I make a note about the filenames not being considered an ABI,
> or just let it be?

I still believe they're an ABI.

I guess Grant meant that they aren't an ABI to the kernel at run-time,
unlike the content which is an ABI. That's fine.

However, I believe the files certainly are an ABI to any script that
takes them from the "make dtbs_install" output directory.

Perhaps the best resolution is to just say nothing and let it be:-)

> diff --git a/arch/arm/Makefile b/arch/arm/Makefile

> +dtbs_install: dtbs
> +	$(CONFIG_SHELL) $(srctree)/scripts/installdtbs.sh $(KERNELRELEASE) \
> +	"$(MODLIB)/devicetree" "$(srctree)/$(boot)/dts"

I still think this rule should be in Makefile not arch/arm/Makefile.

Aside from those couple of issues, this version looks OK to me.

[PATCH V4] kbuild: dtbs_install: new make target

[Grant Likely]

On Tue, 19 Nov 2013 14:58:05 -0700, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/19/2013 02:27 PM, Jason Cooper wrote:
> > Unlike other build products in the Linux kernel, there is no 'make
> > *install' mechanism to put devicetree blobs in a standard place.
> > 
> > This patch is an attempt to fix this problem.  Akin to 'make install',
> > this creates a new make target, dtbs_install.  The script that gets
> > called defers to a distribution or user supplied installdtbs binary,
> > if found in the system.  Otherwise, the default action is to install a
> > given dtb into
> > 
> >   /lib/modules/${kernel_version}/devicetree/${dts_filename}.dtb
> 
> I still don't see why you wouldn't install the files in
> /lib/devicetrees, but I suppose that location is fine.

/boot/devicetrees/${kernel_version} would be my choice. /boot is more
likely to be available to firmware than /lib would be.

g.

[PATCH V4] kbuild: dtbs_install: new make target

[Jason Cooper]

On Wed, Nov 20, 2013 at 01:21:58PM +0000, Grant Likely wrote:
> On Tue, 19 Nov 2013 14:58:05 -0700, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > On 11/19/2013 02:27 PM, Jason Cooper wrote:
> > > Unlike other build products in the Linux kernel, there is no 'make
> > > *install' mechanism to put devicetree blobs in a standard place.
> > > 
> > > This patch is an attempt to fix this problem.  Akin to 'make install',
> > > this creates a new make target, dtbs_install.  The script that gets
> > > called defers to a distribution or user supplied installdtbs binary,
> > > if found in the system.  Otherwise, the default action is to install a
> > > given dtb into
> > > 
> > >   /lib/modules/${kernel_version}/devicetree/${dts_filename}.dtb
> > 
> > I still don't see why you wouldn't install the files in
> > /lib/devicetrees, but I suppose that location is fine.
> 
> /boot/devicetrees/${kernel_version} would be my choice. /boot is more
> likely to be available to firmware than /lib would be.

True, but a lot of systems make /boot a small, non-automounted separate
partition.  It's not that all of the dtbs take up a lot of space, but
that only one of them is needed to boot, which is what /boot is intended
to hold.

I think it's a distribution issue to determine whether to put one, some
or all of the dtbs in /boot.  I'd prefer not to make that decision for
them.

Is /lib/devicetrees/${kernelversion}/ an acceptable middle ground?

thx,

Jason.

[PATCH V4] kbuild: dtbs_install: new make target

[Jason Cooper]

On Tue, Nov 19, 2013 at 02:58:05PM -0700, Stephen Warren wrote:
> On 11/19/2013 02:27 PM, Jason Cooper wrote:
> > Unlike other build products in the Linux kernel, there is no 'make
> > *install' mechanism to put devicetree blobs in a standard place.
> > 
> > This patch is an attempt to fix this problem.  Akin to 'make install',
> > this creates a new make target, dtbs_install.  The script that gets
> > called defers to a distribution or user supplied installdtbs binary,
> > if found in the system.  Otherwise, the default action is to install a
> > given dtb into
> > 
> >   /lib/modules/${kernel_version}/devicetree/${dts_filename}.dtb
> 
> I still don't see why you wouldn't install the files in
> /lib/devicetrees, but I suppose that location is fine.

Hmm, after sleeping on it a night, I've come around.  If we install to
/lib/devicetree/${kernel_version}/, then when the devicetree moves to
it's own repo, it should be able to install to /lib/devicetree.

So this:
 1) hints at the still strong connection between a dtb and the kernel
    version
 2) doesn't sound odd like installing dtbs into a modules directory
 3) allows a future independent repository to install
    non-kernel-version-dependent dtbs in a sane location.

I'm still not in favor of installing to /boot/anything since /boot is
often a separate, small partition.  I even set mine not to automount.
The number and size of dtbs is only going to grow.  Better to install
them in a location with lots of space, and /lib is used to having the
kernel modules installed in it.

> > This is done to keep dtbs from different kernel versions separate until
> > things have settled down.  Once the dtbs are stable, and not so strongly
> > linked to the kernel version, the devicetree files will most likely move
> > to their own repo.  Users will need to upgrade install scripts at that
> > time.
> > 
> > Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> > ---
> > Question: should I make a note about the filenames not being considered an ABI,
> > or just let it be?
> 
> I still believe they're an ABI.
> 
> I guess Grant meant that they aren't an ABI to the kernel at run-time,
> unlike the content which is an ABI. That's fine.
> 
> However, I believe the files certainly are an ABI to any script that
> takes them from the "make dtbs_install" output directory.
> 
> Perhaps the best resolution is to just say nothing and let it be:-)

Fine by me.

> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> 
> > +dtbs_install: dtbs
> > +	$(CONFIG_SHELL) $(srctree)/scripts/installdtbs.sh $(KERNELRELEASE) \
> > +	"$(MODLIB)/devicetree" "$(srctree)/$(boot)/dts"
> 
> I still think this rule should be in Makefile not arch/arm/Makefile.

d*mn.  I sent this version too quick.  Thanks for catching that.  I
didn't expand my test coverage after moving installdtbs.sh.

> Aside from those couple of issues, this version looks OK to me.

Great!  Hopefully Linus won't have any concerns when it passes through
him.

thx,

Jason.

[PATCH V4] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/20/2013 10:08 AM, Jason Cooper wrote:
> On Tue, Nov 19, 2013 at 02:58:05PM -0700, Stephen Warren wrote:
>> On 11/19/2013 02:27 PM, Jason Cooper wrote:
>>> Unlike other build products in the Linux kernel, there is no 'make
>>> *install' mechanism to put devicetree blobs in a standard place.
>>>
>>> This patch is an attempt to fix this problem.  Akin to 'make install',
>>> this creates a new make target, dtbs_install.  The script that gets
>>> called defers to a distribution or user supplied installdtbs binary,
>>> if found in the system.  Otherwise, the default action is to install a
>>> given dtb into
>>>
>>>   /lib/modules/${kernel_version}/devicetree/${dts_filename}.dtb
>>
>> I still don't see why you wouldn't install the files in
>> /lib/devicetrees, but I suppose that location is fine.
> 
> Hmm, after sleeping on it a night, I've come around.  If we install to
> /lib/devicetree/${kernel_version}/, then when the devicetree moves to
> it's own repo, it should be able to install to /lib/devicetree.
> 
> So this:
>  1) hints at the still strong connection between a dtb and the kernel
>     version
>  2) doesn't sound odd like installing dtbs into a modules directory
>  3) allows a future independent repository to install
>     non-kernel-version-dependent dtbs in a sane location.
> 
> I'm still not in favor of installing to /boot/anything since /boot is
> often a separate, small partition.  I even set mine not to automount.
> The number and size of dtbs is only going to grow.  Better to install
> them in a location with lots of space, and /lib is used to having the
> kernel modules installed in it.

Isn't installdtbs (the in-kernel version) typically installing to a
temporary staging directory, which is then packaged up by some process?

If you point DESTDIR/INSTALL_MOD_PATH/... at / when running it, or
install a custom /sbin/installdtbs that ignores the path and always
copies the files to /, then haven't you specifically opted in to /boot
being an available and appropriate location?

As such, I'm tending to agree with Grant that /boot/devicetrees/...
makes more sense that /lib/devicetrees/...; my use of "/lib" above was
simply me writing to fast and typing the wrong thing!

[PATCH V4] kbuild: dtbs_install: new make target

[Grant Likely]

On Wed, 20 Nov 2013 12:08:45 -0500, Jason Cooper <jason@lakedaemon.net> wrote:
> I'm still not in favor of installing to /boot/anything since /boot is
> often a separate, small partition.  I even set mine not to automount.
> The number and size of dtbs is only going to grow.  Better to install
> them in a location with lots of space, and /lib is used to having the
> kernel modules installed in it.

This is just the kernel default action. It can be overridden with a
local script or an environment variable. /boot definitely makes more
sense that /lib.

g.

[PATCH V5] kbuild: dtbs_install: new make target

[Jason Cooper]

Unlike other build products in the Linux kernel, there is no 'make
*install' mechanism to put devicetree blobs in a standard place.

This patch is an attempt to fix this problem.  Akin to 'make install',
this creates a new make target, dtbs_install.  The script that gets
called defers to a distribution or user supplied installdtbs binary,
if found in the system.  Otherwise, the default action is to install a
given dtb into

  /boot/devicetrees/${kernel_version}/${dts_filename}.dtb

This is done to keep dtbs from different kernel versions separate until
things have settled down.  Once the dtbs are stable, and not so strongly
linked to the kernel version, the devicetree files will most likely move
to their own repo.  Users will need to upgrade install scripts at that
time.

Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
changes since v4:
 - move make target from arch/arm/Makefile to Makefile (swarren)
 - change default install location to /boot/devicetrees/$KERNVER (swarren/gcl)
 - add INSTALL_DTBS_PATH for changing build root (jac)

changes since v3:
 - drop renaming files to ${compat}.dtb (rmk/swarren)
 - move installdtbs.sh to ./scripts/ (gcl)

changes since v2:
 - use fdtget instead of a modified dtc to get the board compat string

changes since v1:
 - added this patch

 Makefile               | 20 +++++++++++++++++++-
 scripts/installdtbs.sh | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 scripts/installdtbs.sh

diff --git a/Makefile b/Makefile
index 920ad07180c9..bd28cb211411 100644
--- a/Makefile
+++ b/Makefile
@@ -339,6 +339,7 @@ OBJDUMP		= $(CROSS_COMPILE)objdump
 AWK		= awk
 GENKSYMS	= scripts/genksyms/genksyms
 INSTALLKERNEL  := installkernel
+INSTALLDTBS    := installdtbs
 DEPMOD		= /sbin/depmod
 PERL		= perl
 CHECK		= sparse
@@ -391,7 +392,7 @@ KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(S
 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
-export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
+export MAKE AWK GENKSYMS INSTALLKERNEL INSTALLDTBS PERL UTS_MACHINE
 export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
@@ -704,6 +705,15 @@ export KBUILD_IMAGE ?= vmlinux
 export	INSTALL_PATH ?= /boot
 
 #
+# INSTALL_DTBS_PATH specifies a prefix for relocations required by build roots.
+# Like INSTALL_MOD_PATH, it isn't defined in the Makefile, but can be passed as
+# an argument if needed.
+#
+
+DTBBOOT = $(INSTALL_DTBS_PATH)/boot/devicetrees/$(KERNELRELEASE)
+export DTBBOOT
+
+#
 # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
 # relocations required by build roots.  This is not defined in the
 # makefile but the argument can be passed to make if needed.
@@ -914,6 +924,14 @@ firmware_install: FORCE
 	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.fwinst obj=firmware __fw_install
 
 # ---------------------------------------------------------------------------
+# devicetree install
+PHONY += dtbs_install
+
+dtbs_install:
+	$(CONFIG_SHELL) $(srctree)/scripts/installdtbs.sh $(KERNELRELEASE) \
+	"$(DTBBOOT)" "$(srctree)"
+
+# ---------------------------------------------------------------------------
 # Kernel headers
 
 #Default location for installed headers
diff --git a/scripts/installdtbs.sh b/scripts/installdtbs.sh
new file mode 100644
index 000000000000..11027f00c3a4
--- /dev/null
+++ b/scripts/installdtbs.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+#
+# This file is subject to the terms and conditions of the GNU General Public
+# License.  See the file "COPYING" in the main directory of this archive
+# for more details.
+#
+# Copyright (C) 1995 by Linus Torvalds
+#
+# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
+#
+# Further adapted from arch/x86/boot/install.sh by Jason Cooper
+#
+# "make dtbs_install" script
+#
+# Arguments:
+#   $1 - kernel version
+#   $2 - default install path (blank if root directory)
+#   $3 - directory containing dtbs
+#
+
+# User may have a custom install script
+
+if [ -x ~/bin/${INSTALLDTBS} ]; then exec ~/bin/${INSTALLDTBS} "$@"; fi
+if [ -x /sbin/${INSTALLDTBS} ]; then exec /sbin/${INSTALLDTBS} "$@"; fi
+
+# Default install
+[ -d "$2" ] && rm -rf "$2"
+
+mkdir -p "$2"
+
+for dtb in `find "$3" -name "*.dtb"`; do
+	cp "$dtb" "$2/${dtb##*/}"
+done
-- 
1.8.4.4

[PATCH V5] kbuild: dtbs_install: new make target

[Stephen Warren]

On 11/21/2013 12:35 PM, Jason Cooper wrote:
> Unlike other build products in the Linux kernel, there is no 'make
> *install' mechanism to put devicetree blobs in a standard place.
> 
> This patch is an attempt to fix this problem.  Akin to 'make install',
> this creates a new make target, dtbs_install.  The script that gets
> called defers to a distribution or user supplied installdtbs binary,
> if found in the system.  Otherwise, the default action is to install a
> given dtb into
> 
>   /boot/devicetrees/${kernel_version}/${dts_filename}.dtb
> 
> This is done to keep dtbs from different kernel versions separate until
> things have settled down.  Once the dtbs are stable, and not so strongly
> linked to the kernel version, the devicetree files will most likely move
> to their own repo.  Users will need to upgrade install scripts at that
> time.

Acked-by: Stephen Warren <swarren@nvidia.com>

[PATCH V5] kbuild: dtbs_install: new make target

[Kumar Gala]

On Nov 21, 2013, at 1:35 PM, Jason Cooper <jason@lakedaemon.net> wrote:

> Unlike other build products in the Linux kernel, there is no 'make
> *install' mechanism to put devicetree blobs in a standard place.
> 
> This patch is an attempt to fix this problem.  Akin to 'make install',
> this creates a new make target, dtbs_install.  The script that gets
> called defers to a distribution or user supplied installdtbs binary,
> if found in the system.  Otherwise, the default action is to install a
> given dtb into
> 
>  /boot/devicetrees/${kernel_version}/${dts_filename}.dtb
> 
> This is done to keep dtbs from different kernel versions separate until
> things have settled down.  Once the dtbs are stable, and not so strongly
> linked to the kernel version, the devicetree files will most likely move
> to their own repo.  Users will need to upgrade install scripts at that
> time.
> 
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> ---
> changes since v4:
> - move make target from arch/arm/Makefile to Makefile (swarren)
> - change default install location to /boot/devicetrees/$KERNVER (swarren/gcl)
> - add INSTALL_DTBS_PATH for changing build root (jac)
> 
> changes since v3:
> - drop renaming files to ${compat}.dtb (rmk/swarren)
> - move installdtbs.sh to ./scripts/ (gcl)
> 
> changes since v2:
> - use fdtget instead of a modified dtc to get the board compat string
> 
> changes since v1:
> - added this patch
> 
> Makefile               | 20 +++++++++++++++++++-
> scripts/installdtbs.sh | 33 +++++++++++++++++++++++++++++++++
> 2 files changed, 52 insertions(+), 1 deletion(-)
> create mode 100644 scripts/installdtbs.sh
> 
> diff --git a/Makefile b/Makefile
> index 920ad07180c9..bd28cb211411 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -339,6 +339,7 @@ OBJDUMP		= $(CROSS_COMPILE)objdump
> AWK		= awk
> GENKSYMS	= scripts/genksyms/genksyms
> INSTALLKERNEL  := installkernel
> +INSTALLDTBS    := installdtbs
> DEPMOD		= /sbin/depmod
> PERL		= perl
> CHECK		= sparse
> @@ -391,7 +392,7 @@ KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(S
> 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
> -export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
> +export MAKE AWK GENKSYMS INSTALLKERNEL INSTALLDTBS PERL UTS_MACHINE
> export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
> 
> export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
> @@ -704,6 +705,15 @@ export KBUILD_IMAGE ?= vmlinux
> export	INSTALL_PATH ?= /boot
> 
> #
> +# INSTALL_DTBS_PATH specifies a prefix for relocations required by build roots.
> +# Like INSTALL_MOD_PATH, it isn't defined in the Makefile, but can be passed as
> +# an argument if needed.
> +#

Nit, do we want to match INSTALL_MOD_PATH and drop the ?S? for INSTALL_DTB_PATH?

> +
> +DTBBOOT = $(INSTALL_DTBS_PATH)/boot/devicetrees/$(KERNELRELEASE)
> +export DTBBOOT
> +
> +#
> # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
> # relocations required by build roots.  This is not defined in the
> # makefile but the argument can be passed to make if needed.
> @@ -914,6 +924,14 @@ firmware_install: FORCE
> 	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.fwinst obj=firmware __fw_install
> 
> # ---------------------------------------------------------------------------
> +# devicetree install
> +PHONY += dtbs_install
> +
> +dtbs_install:
> +	$(CONFIG_SHELL) $(srctree)/scripts/installdtbs.sh $(KERNELRELEASE) \
> +	"$(DTBBOOT)" "$(srctree)"
> +
> +# ---------------------------------------------------------------------------
> # Kernel headers
> 
> #Default location for installed headers
> diff --git a/scripts/installdtbs.sh b/scripts/installdtbs.sh
> new file mode 100644
> index 000000000000..11027f00c3a4
> --- /dev/null
> +++ b/scripts/installdtbs.sh
> @@ -0,0 +1,33 @@
> +#!/bin/sh
> +#
> +# This file is subject to the terms and conditions of the GNU General Public
> +# License.  See the file "COPYING" in the main directory of this archive
> +# for more details.
> +#
> +# Copyright (C) 1995 by Linus Torvalds
> +#
> +# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
> +#
> +# Further adapted from arch/x86/boot/install.sh by Jason Cooper
> +#
> +# "make dtbs_install" script
> +#
> +# Arguments:
> +#   $1 - kernel version
> +#   $2 - default install path (blank if root directory)
> +#   $3 - directory containing dtbs
> +#
> +
> +# User may have a custom install script
> +
> +if [ -x ~/bin/${INSTALLDTBS} ]; then exec ~/bin/${INSTALLDTBS} "$@"; fi
> +if [ -x /sbin/${INSTALLDTBS} ]; then exec /sbin/${INSTALLDTBS} "$@"; fi
> +
> +# Default install
> +[ -d "$2" ] && rm -rf "$2"
> +
> +mkdir -p "$2"
> +
> +for dtb in `find "$3" -name "*.dtb"`; do
> +	cp "$dtb" "$2/${dtb##*/}"
> +done
> -- 
> 1.8.4.4
> 
> --
> 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

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V5] kbuild: dtbs_install: new make target

[Olof Johansson]

On Thu, Nov 21, 2013 at 3:31 PM, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Nov 21, 2013, at 1:35 PM, Jason Cooper <jason@lakedaemon.net> wrote:
>
>> Unlike other build products in the Linux kernel, there is no 'make
>> *install' mechanism to put devicetree blobs in a standard place.
>>
>> This patch is an attempt to fix this problem.  Akin to 'make install',
>> this creates a new make target, dtbs_install.  The script that gets
>> called defers to a distribution or user supplied installdtbs binary,
>> if found in the system.  Otherwise, the default action is to install a
>> given dtb into
>>
>>  /boot/devicetrees/${kernel_version}/${dts_filename}.dtb

Random bikeshed of the day. Maybe this was already covered in the long
thread and just tell me to shut up and go away if it was and I'm not
presenting new arguments:

I like this whole approach, but I'm all for shorter pathnames as long
as they are unique. Also, keeping it below 8 can be useful for FAT
/boot filesystems. I propose /boot/dtb/ instead.


-Olof

[PATCH V5] kbuild: dtbs_install: new make target

[Grant Likely]

On Thu, 21 Nov 2013 15:36:47 -0800, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Nov 21, 2013 at 3:31 PM, Kumar Gala <galak@codeaurora.org> wrote:
> >
> > On Nov 21, 2013, at 1:35 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> >
> >> Unlike other build products in the Linux kernel, there is no 'make
> >> *install' mechanism to put devicetree blobs in a standard place.
> >>
> >> This patch is an attempt to fix this problem.  Akin to 'make install',
> >> this creates a new make target, dtbs_install.  The script that gets
> >> called defers to a distribution or user supplied installdtbs binary,
> >> if found in the system.  Otherwise, the default action is to install a
> >> given dtb into
> >>
> >>  /boot/devicetrees/${kernel_version}/${dts_filename}.dtb
> 
> Random bikeshed of the day. Maybe this was already covered in the long
> thread and just tell me to shut up and go away if it was and I'm not
> presenting new arguments:
> 
> I like this whole approach, but I'm all for shorter pathnames as long
> as they are unique. Also, keeping it below 8 can be useful for FAT
> /boot filesystems. I propose /boot/dtb/ instead.

Makes sense to me.

g.

[PATCH V5] kbuild: dtbs_install: new make target

[Jason Cooper]

On Fri, Nov 22, 2013 at 07:42:24AM +0000, Grant Likely wrote:
> On Thu, 21 Nov 2013 15:36:47 -0800, Olof Johansson <olof@lixom.net> wrote:
> > On Thu, Nov 21, 2013 at 3:31 PM, Kumar Gala <galak@codeaurora.org> wrote:
> > >
> > > On Nov 21, 2013, at 1:35 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > >
> > >> Unlike other build products in the Linux kernel, there is no 'make
> > >> *install' mechanism to put devicetree blobs in a standard place.
> > >>
> > >> This patch is an attempt to fix this problem.  Akin to 'make install',
> > >> this creates a new make target, dtbs_install.  The script that gets
> > >> called defers to a distribution or user supplied installdtbs binary,
> > >> if found in the system.  Otherwise, the default action is to install a
> > >> given dtb into
> > >>
> > >>  /boot/devicetrees/${kernel_version}/${dts_filename}.dtb
> > 
> > Random bikeshed of the day. Maybe this was already covered in the long
> > thread and just tell me to shut up and go away if it was and I'm not
> > presenting new arguments:
> > 
> > I like this whole approach, but I'm all for shorter pathnames as long
> > as they are unique. Also, keeping it below 8 can be useful for FAT
> > /boot filesystems. I propose /boot/dtb/ instead.
> 
> Makes sense to me.

hmm, following that logic, there are 497 dts files in todays HEAD.  Only
116 of those are 8 characters or less (114 if you remove dupes).  Which
means a vast majority of dtb file names would have issues in Olof's
scenario.

Might I re-suggest /lib/devicetrees (or, /lib/dtb, or /lib/dtbs)?

thx,

Jason.

[PATCH V5] kbuild: dtbs_install: new make target

[Jason Cooper]

On Thu, Nov 21, 2013 at 05:31:49PM -0600, Kumar Gala wrote:
> On Nov 21, 2013, at 1:35 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > diff --git a/Makefile b/Makefile
> > index 920ad07180c9..bd28cb211411 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -339,6 +339,7 @@ OBJDUMP		= $(CROSS_COMPILE)objdump
> > AWK		= awk
> > GENKSYMS	= scripts/genksyms/genksyms
> > INSTALLKERNEL  := installkernel
> > +INSTALLDTBS    := installdtbs
> > DEPMOD		= /sbin/depmod
> > PERL		= perl
> > CHECK		= sparse
> > @@ -391,7 +392,7 @@ KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(S
> > 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
> > -export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
> > +export MAKE AWK GENKSYMS INSTALLKERNEL INSTALLDTBS PERL UTS_MACHINE
> > export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
> > 
> > export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
> > @@ -704,6 +705,15 @@ export KBUILD_IMAGE ?= vmlinux
> > export	INSTALL_PATH ?= /boot
> > 
> > #
> > +# INSTALL_DTBS_PATH specifies a prefix for relocations required by build roots.
> > +# Like INSTALL_MOD_PATH, it isn't defined in the Makefile, but can be passed as
> > +# an argument if needed.
> > +#
> 
> Nit, do we want to match INSTALL_MOD_PATH and drop the ?S? for INSTALL_DTB_PATH?

Yeah, I can go either way on this one.  So, sure.

thx,

Jason.

> > +
> > +DTBBOOT = $(INSTALL_DTBS_PATH)/boot/devicetrees/$(KERNELRELEASE)
> > +export DTBBOOT
> > +
> > +#
> > # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
> > # relocations required by build roots.  This is not defined in the
> > # makefile but the argument can be passed to make if needed.
> > @@ -914,6 +924,14 @@ firmware_install: FORCE
> > 	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.fwinst obj=firmware __fw_install
> > 
> > # ---------------------------------------------------------------------------
> > +# devicetree install
> > +PHONY += dtbs_install
> > +
> > +dtbs_install:
> > +	$(CONFIG_SHELL) $(srctree)/scripts/installdtbs.sh $(KERNELRELEASE) \
> > +	"$(DTBBOOT)" "$(srctree)"
> > +
> > +# ---------------------------------------------------------------------------
> > # Kernel headers
> > 
> > #Default location for installed headers

[PATCH V5] kbuild: dtbs_install: new make target

[Jason Cooper]

Kumar,

On Thu, Nov 21, 2013 at 05:31:49PM -0600, Kumar Gala wrote:
> On Nov 21, 2013, at 1:35 PM, Jason Cooper <jason@lakedaemon.net> wrote:
...
> > #
> > +# INSTALL_DTBS_PATH specifies a prefix for relocations required by build roots.
> > +# Like INSTALL_MOD_PATH, it isn't defined in the Makefile, but can be passed as
> > +# an argument if needed.
> > +#
> 
> Nit, do we want to match INSTALL_MOD_PATH and drop the ?S? for INSTALL_DTB_PATH?

I thought about this, and I prefer to keep the S.  Installing one
module sounds silly, while installing one dtb implies we are doing
something we aren't.  Namely selecting the correct dtb.

thx,

Jason.

[PATCH V5] kbuild: dtbs_install: new make target

[Grant Likely]

On Thu, 21 Nov 2013 19:35:52 +0000, Jason Cooper <jason@lakedaemon.net> wrote:
> Unlike other build products in the Linux kernel, there is no 'make
> *install' mechanism to put devicetree blobs in a standard place.
> 
> This patch is an attempt to fix this problem.  Akin to 'make install',
> this creates a new make target, dtbs_install.  The script that gets
> called defers to a distribution or user supplied installdtbs binary,
> if found in the system.  Otherwise, the default action is to install a
> given dtb into
> 
>   /boot/devicetrees/${kernel_version}/${dts_filename}.dtb
> 
> This is done to keep dtbs from different kernel versions separate until
> things have settled down.  Once the dtbs are stable, and not so strongly
> linked to the kernel version, the devicetree files will most likely move
> to their own repo.  Users will need to upgrade install scripts at that
> time.
> 
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> ---
> changes since v4:
>  - move make target from arch/arm/Makefile to Makefile (swarren)
>  - change default install location to /boot/devicetrees/$KERNVER (swarren/gcl)
>  - add INSTALL_DTBS_PATH for changing build root (jac)
> 
> changes since v3:
>  - drop renaming files to ${compat}.dtb (rmk/swarren)
>  - move installdtbs.sh to ./scripts/ (gcl)
> 
> changes since v2:
>  - use fdtget instead of a modified dtc to get the board compat string
> 
> changes since v1:
>  - added this patch
> 
>  Makefile               | 20 +++++++++++++++++++-

Adding it to Makefile enables it unconditionally for all architectures,
even the ones with no DT support. I suspect (but have no evidence for)
that this will be considered bad form. I have no problem with each
architecture adding the build rule explicitly. The script is in a common
place and that is the important bit.

g.

>  scripts/installdtbs.sh | 33 +++++++++++++++++++++++++++++++++
>  2 files changed, 52 insertions(+), 1 deletion(-)
>  create mode 100644 scripts/installdtbs.sh
> 
> diff --git a/Makefile b/Makefile
> index 920ad07180c9..bd28cb211411 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -339,6 +339,7 @@ OBJDUMP		= $(CROSS_COMPILE)objdump
>  AWK		= awk
>  GENKSYMS	= scripts/genksyms/genksyms
>  INSTALLKERNEL  := installkernel
> +INSTALLDTBS    := installdtbs
>  DEPMOD		= /sbin/depmod
>  PERL		= perl
>  CHECK		= sparse
> @@ -391,7 +392,7 @@ KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(S
>  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
> -export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
> +export MAKE AWK GENKSYMS INSTALLKERNEL INSTALLDTBS PERL UTS_MACHINE
>  export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
>  
>  export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
> @@ -704,6 +705,15 @@ export KBUILD_IMAGE ?= vmlinux
>  export	INSTALL_PATH ?= /boot
>  
>  #
> +# INSTALL_DTBS_PATH specifies a prefix for relocations required by build roots.
> +# Like INSTALL_MOD_PATH, it isn't defined in the Makefile, but can be passed as
> +# an argument if needed.
> +#
> +
> +DTBBOOT = $(INSTALL_DTBS_PATH)/boot/devicetrees/$(KERNELRELEASE)
> +export DTBBOOT
> +
> +#
>  # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
>  # relocations required by build roots.  This is not defined in the
>  # makefile but the argument can be passed to make if needed.
> @@ -914,6 +924,14 @@ firmware_install: FORCE
>  	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.fwinst obj=firmware __fw_install
>  
>  # ---------------------------------------------------------------------------
> +# devicetree install
> +PHONY += dtbs_install
> +
> +dtbs_install:
> +	$(CONFIG_SHELL) $(srctree)/scripts/installdtbs.sh $(KERNELRELEASE) \
> +	"$(DTBBOOT)" "$(srctree)"
> +
> +# ---------------------------------------------------------------------------
>  # Kernel headers
>  
>  #Default location for installed headers
> diff --git a/scripts/installdtbs.sh b/scripts/installdtbs.sh
> new file mode 100644
> index 000000000000..11027f00c3a4
> --- /dev/null
> +++ b/scripts/installdtbs.sh
> @@ -0,0 +1,33 @@
> +#!/bin/sh
> +#
> +# This file is subject to the terms and conditions of the GNU General Public
> +# License.  See the file "COPYING" in the main directory of this archive
> +# for more details.
> +#
> +# Copyright (C) 1995 by Linus Torvalds
> +#
> +# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
> +#
> +# Further adapted from arch/x86/boot/install.sh by Jason Cooper
> +#
> +# "make dtbs_install" script
> +#
> +# Arguments:
> +#   $1 - kernel version
> +#   $2 - default install path (blank if root directory)
> +#   $3 - directory containing dtbs
> +#
> +
> +# User may have a custom install script
> +
> +if [ -x ~/bin/${INSTALLDTBS} ]; then exec ~/bin/${INSTALLDTBS} "$@"; fi
> +if [ -x /sbin/${INSTALLDTBS} ]; then exec /sbin/${INSTALLDTBS} "$@"; fi
> +
> +# Default install
> +[ -d "$2" ] && rm -rf "$2"
> +
> +mkdir -p "$2"
> +
> +for dtb in `find "$3" -name "*.dtb"`; do
> +	cp "$dtb" "$2/${dtb##*/}"
> +done
> -- 
> 1.8.4.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V5] kbuild: dtbs_install: new make target

[Jason Cooper]

On Fri, Nov 22, 2013 at 07:44:11AM +0000, Grant Likely wrote:
> On Thu, 21 Nov 2013 19:35:52 +0000, Jason Cooper <jason@lakedaemon.net> wrote:
> > Unlike other build products in the Linux kernel, there is no 'make
> > *install' mechanism to put devicetree blobs in a standard place.
> > 
> > This patch is an attempt to fix this problem.  Akin to 'make install',
> > this creates a new make target, dtbs_install.  The script that gets
> > called defers to a distribution or user supplied installdtbs binary,
> > if found in the system.  Otherwise, the default action is to install a
> > given dtb into
> > 
> >   /boot/devicetrees/${kernel_version}/${dts_filename}.dtb
> > 
> > This is done to keep dtbs from different kernel versions separate until
> > things have settled down.  Once the dtbs are stable, and not so strongly
> > linked to the kernel version, the devicetree files will most likely move
> > to their own repo.  Users will need to upgrade install scripts at that
> > time.
> > 
> > Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> > ---
> > changes since v4:
> >  - move make target from arch/arm/Makefile to Makefile (swarren)
> >  - change default install location to /boot/devicetrees/$KERNVER (swarren/gcl)
> >  - add INSTALL_DTBS_PATH for changing build root (jac)
> > 
> > changes since v3:
> >  - drop renaming files to ${compat}.dtb (rmk/swarren)
> >  - move installdtbs.sh to ./scripts/ (gcl)
> > 
> > changes since v2:
> >  - use fdtget instead of a modified dtc to get the board compat string
> > 
> > changes since v1:
> >  - added this patch
> > 
> >  Makefile               | 20 +++++++++++++++++++-
> 
> Adding it to Makefile enables it unconditionally for all architectures,
> even the ones with no DT support. I suspect (but have no evidence for)
> that this will be considered bad form. I have no problem with each
> architecture adding the build rule explicitly. The script is in a common
> place and that is the important bit.

Ok, once we nail down Olof's concern, I'll move the target back to
arch/arm/Makefile

thx,

Jason.

[PATCH V6] kbuild: dtbs_install: new make target

[Jason Cooper]

Unlike other build products in the Linux kernel, there is no 'make
*install' mechanism to put devicetree blobs in a standard place.

This patch is an attempt to fix this problem.  Akin to 'make install',
this creates a new make target, dtbs_install.  The script that gets
called defers to a distribution or user supplied installdtbs binary,
if found in the system.  Otherwise, the default action is to install the
built dtbs into

  /lib/devicetrees/${kernel_version}/${dts_filename}.dtb

This is done to keep dtbs from different kernel versions separate until
things have settled down.  Once the dtbs are stable, and not so strongly
linked to the kernel version, the devicetree files will most likely move
to their own repo.  Users will need to upgrade install scripts at that
time.

/lib has been selected over /boot since /boot is often a FAT filesystem
and a majority of the dts filenames are longer than 8+3.

Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
Note: Stephen, I haven't added your Ack because I wanted to make sure you were
Ok with the change to /lib in light of /boot partitions formatted to FAT

changes since v5:
 - move make target back to arch/arm/Makefile (gcl)
 - change default install location to /lib from /boot (FAT) (ojn,jac)

changes since v4:
 - move make target from arch/arm/Makefile to Makefile (swarren)
 - change default install location to /boot/devicetrees/$KERNVER (swarren/gcl)
 - add INSTALL_DTBS_PATH for changing build root (jac)

changes since v3:
 - drop renaming files to ${compat}.dtb (rmk/swarren)
 - move installdtbs.sh to ./scripts/ (gcl)

changes since v2:
 - use fdtget instead of a modified dtc to get the board compat string

changes since v1:
 - added this patch

 Makefile               | 12 +++++++++++-
 arch/arm/Makefile      | 10 ++++++++++
 scripts/installdtbs.sh | 33 +++++++++++++++++++++++++++++++++
 3 files changed, 54 insertions(+), 1 deletion(-)
 create mode 100644 scripts/installdtbs.sh

diff --git a/Makefile b/Makefile
index c0c2d58e3998..240e0d52b126 100644
--- a/Makefile
+++ b/Makefile
@@ -339,6 +339,7 @@ OBJDUMP		= $(CROSS_COMPILE)objdump
 AWK		= awk
 GENKSYMS	= scripts/genksyms/genksyms
 INSTALLKERNEL  := installkernel
+INSTALLDTBS    := installdtbs
 DEPMOD		= /sbin/depmod
 PERL		= perl
 CHECK		= sparse
@@ -391,7 +392,7 @@ KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(S
 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
-export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
+export MAKE AWK GENKSYMS INSTALLKERNEL INSTALLDTBS PERL UTS_MACHINE
 export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
@@ -704,6 +705,15 @@ export KBUILD_IMAGE ?= vmlinux
 export	INSTALL_PATH ?= /boot
 
 #
+# INSTALL_DTBS_PATH specifies a prefix for relocations required by build roots.
+# Like INSTALL_MOD_PATH, it isn't defined in the Makefile, but can be passed as
+# an argument if needed.
+#
+
+DTBBOOT = $(INSTALL_DTBS_PATH)/lib/devicetrees/$(KERNELRELEASE)
+export DTBBOOT
+
+#
 # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
 # relocations required by build roots.  This is not defined in the
 # makefile but the argument can be passed to make if needed.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c99b1086d83d..400a3a7ee899 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -314,6 +314,12 @@ PHONY += dtbs
 dtbs: scripts
 	$(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) dtbs
 
+PHONY += dtbs_install
+
+dtbs_install: dtbs
+	$(CONFIG_SHELL) $(srctree)/scripts/installdtbs.sh $(KERNELRELEASE) \
+	"$(DTBBOOT)" "$(srctree)"
+
 # We use MRPROPER_FILES and CLEAN_FILES now
 archclean:
 	$(Q)$(MAKE) $(clean)=$(boot)
@@ -331,6 +337,10 @@ define archhelp
   echo  '  bootpImage    - Combined zImage and initial RAM disk'
   echo  '                  (supply initrd image via make variable INITRD=<path>)'
   echo  '* dtbs          - Build device tree blobs for enabled boards'
+  echo  '  dtbs_install  - Install dtbs'
+  echo  '                  Install using (your) ~/bin/$(INSTALLDTBS) or'
+  echo  '                  (distribution) /sbin/$(INSTALLDTBS) or'
+  echo  '                  install to $(DTBBOOT)'
   echo  '  install       - Install uncompressed kernel'
   echo  '  zinstall      - Install compressed kernel'
   echo  '  uinstall      - Install U-Boot wrapped compressed kernel'
diff --git a/scripts/installdtbs.sh b/scripts/installdtbs.sh
new file mode 100644
index 000000000000..11027f00c3a4
--- /dev/null
+++ b/scripts/installdtbs.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+#
+# This file is subject to the terms and conditions of the GNU General Public
+# License.  See the file "COPYING" in the main directory of this archive
+# for more details.
+#
+# Copyright (C) 1995 by Linus Torvalds
+#
+# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
+#
+# Further adapted from arch/x86/boot/install.sh by Jason Cooper
+#
+# "make dtbs_install" script
+#
+# Arguments:
+#   $1 - kernel version
+#   $2 - default install path (blank if root directory)
+#   $3 - directory containing dtbs
+#
+
+# User may have a custom install script
+
+if [ -x ~/bin/${INSTALLDTBS} ]; then exec ~/bin/${INSTALLDTBS} "$@"; fi
+if [ -x /sbin/${INSTALLDTBS} ]; then exec /sbin/${INSTALLDTBS} "$@"; fi
+
+# Default install
+[ -d "$2" ] && rm -rf "$2"
+
+mkdir -p "$2"
+
+for dtb in `find "$3" -name "*.dtb"`; do
+	cp "$dtb" "$2/${dtb##*/}"
+done
-- 
1.8.4.4

[PATCH V6] kbuild: dtbs_install: new make target

[Stephen Warren]

On 12/01/2013 04:56 PM, Jason Cooper wrote:
> Unlike other build products in the Linux kernel, there is no 'make
> *install' mechanism to put devicetree blobs in a standard place.
> 
> This patch is an attempt to fix this problem.  Akin to 'make install',
> this creates a new make target, dtbs_install.  The script that gets
> called defers to a distribution or user supplied installdtbs binary,
> if found in the system.  Otherwise, the default action is to install the
> built dtbs into
> 
>   /lib/devicetrees/${kernel_version}/${dts_filename}.dtb
> 
> This is done to keep dtbs from different kernel versions separate until
> things have settled down.  Once the dtbs are stable, and not so strongly
> linked to the kernel version, the devicetree files will most likely move
> to their own repo.  Users will need to upgrade install scripts at that
> time.
> 
> /lib has been selected over /boot since /boot is often a FAT filesystem
> and a majority of the dts filenames are longer than 8+3.
> 
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> ---
> Note: Stephen, I haven't added your Ack because I wanted to make sure you were
> Ok with the change to /lib in light of /boot partitions formatted to FAT

This script shouldn't be installing directly to the filesystem, but
rather some staging area that then gets copied to the desired location
by distro-/use-specific scripts. As such, the filesystem in /boot isn't
relevant.

But that said, I won't try and NAK it because of that.

[PATCH V6] kbuild: dtbs_install: new make target

[Russell King - ARM Linux]

On Tue, Dec 03, 2013 at 10:37:28AM -0700, Stephen Warren wrote:
> On 12/01/2013 04:56 PM, Jason Cooper wrote:
> > Unlike other build products in the Linux kernel, there is no 'make
> > *install' mechanism to put devicetree blobs in a standard place.
> > 
> > This patch is an attempt to fix this problem.  Akin to 'make install',
> > this creates a new make target, dtbs_install.  The script that gets
> > called defers to a distribution or user supplied installdtbs binary,
> > if found in the system.  Otherwise, the default action is to install the
> > built dtbs into
> > 
> >   /lib/devicetrees/${kernel_version}/${dts_filename}.dtb
> > 
> > This is done to keep dtbs from different kernel versions separate until
> > things have settled down.  Once the dtbs are stable, and not so strongly
> > linked to the kernel version, the devicetree files will most likely move
> > to their own repo.  Users will need to upgrade install scripts at that
> > time.
> > 
> > /lib has been selected over /boot since /boot is often a FAT filesystem
> > and a majority of the dts filenames are longer than 8+3.
> > 
> > Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> > ---
> > Note: Stephen, I haven't added your Ack because I wanted to make sure you were
> > Ok with the change to /lib in light of /boot partitions formatted to FAT
> 
> This script shouldn't be installing directly to the filesystem, but
> rather some staging area that then gets copied to the desired location
> by distro-/use-specific scripts. As such, the filesystem in /boot isn't
> relevant.

Why do you think that?  All the other install targets install direct to
the common destinations unless you ask for an alternative location.  Why
should this be any different?

[PATCH V6] kbuild: dtbs_install: new make target

[Jason Cooper]

Grant,

On Sun, Dec 01, 2013 at 11:56:28PM +0000, Jason Cooper wrote:
> Unlike other build products in the Linux kernel, there is no 'make
> *install' mechanism to put devicetree blobs in a standard place.
> 
> This patch is an attempt to fix this problem.  Akin to 'make install',
> this creates a new make target, dtbs_install.  The script that gets
> called defers to a distribution or user supplied installdtbs binary,
> if found in the system.  Otherwise, the default action is to install the
> built dtbs into
> 
>   /lib/devicetrees/${kernel_version}/${dts_filename}.dtb
> 
> This is done to keep dtbs from different kernel versions separate until
> things have settled down.  Once the dtbs are stable, and not so strongly
> linked to the kernel version, the devicetree files will most likely move
> to their own repo.  Users will need to upgrade install scripts at that
> time.
> 
> /lib has been selected over /boot since /boot is often a FAT filesystem
> and a majority of the dts filenames are longer than 8+3.
> 
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> ---

Is this good to go?

thx,

Jason.

> Note: Stephen, I haven't added your Ack because I wanted to make sure you were
> Ok with the change to /lib in light of /boot partitions formatted to FAT
> 
> changes since v5:
>  - move make target back to arch/arm/Makefile (gcl)
>  - change default install location to /lib from /boot (FAT) (ojn,jac)
> 
> changes since v4:
>  - move make target from arch/arm/Makefile to Makefile (swarren)
>  - change default install location to /boot/devicetrees/$KERNVER (swarren/gcl)
>  - add INSTALL_DTBS_PATH for changing build root (jac)
> 
> changes since v3:
>  - drop renaming files to ${compat}.dtb (rmk/swarren)
>  - move installdtbs.sh to ./scripts/ (gcl)
> 
> changes since v2:
>  - use fdtget instead of a modified dtc to get the board compat string
> 
> changes since v1:
>  - added this patch
> 
>  Makefile               | 12 +++++++++++-
>  arch/arm/Makefile      | 10 ++++++++++
>  scripts/installdtbs.sh | 33 +++++++++++++++++++++++++++++++++
>  3 files changed, 54 insertions(+), 1 deletion(-)
>  create mode 100644 scripts/installdtbs.sh
> 
> diff --git a/Makefile b/Makefile
> index c0c2d58e3998..240e0d52b126 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -339,6 +339,7 @@ OBJDUMP		= $(CROSS_COMPILE)objdump
>  AWK		= awk
>  GENKSYMS	= scripts/genksyms/genksyms
>  INSTALLKERNEL  := installkernel
> +INSTALLDTBS    := installdtbs
>  DEPMOD		= /sbin/depmod
>  PERL		= perl
>  CHECK		= sparse
> @@ -391,7 +392,7 @@ KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(S
>  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
> -export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
> +export MAKE AWK GENKSYMS INSTALLKERNEL INSTALLDTBS PERL UTS_MACHINE
>  export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
>  
>  export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
> @@ -704,6 +705,15 @@ export KBUILD_IMAGE ?= vmlinux
>  export	INSTALL_PATH ?= /boot
>  
>  #
> +# INSTALL_DTBS_PATH specifies a prefix for relocations required by build roots.
> +# Like INSTALL_MOD_PATH, it isn't defined in the Makefile, but can be passed as
> +# an argument if needed.
> +#
> +
> +DTBBOOT = $(INSTALL_DTBS_PATH)/lib/devicetrees/$(KERNELRELEASE)
> +export DTBBOOT
> +
> +#
>  # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
>  # relocations required by build roots.  This is not defined in the
>  # makefile but the argument can be passed to make if needed.
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c99b1086d83d..400a3a7ee899 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -314,6 +314,12 @@ PHONY += dtbs
>  dtbs: scripts
>  	$(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) dtbs
>  
> +PHONY += dtbs_install
> +
> +dtbs_install: dtbs
> +	$(CONFIG_SHELL) $(srctree)/scripts/installdtbs.sh $(KERNELRELEASE) \
> +	"$(DTBBOOT)" "$(srctree)"
> +
>  # We use MRPROPER_FILES and CLEAN_FILES now
>  archclean:
>  	$(Q)$(MAKE) $(clean)=$(boot)
> @@ -331,6 +337,10 @@ define archhelp
>    echo  '  bootpImage    - Combined zImage and initial RAM disk'
>    echo  '                  (supply initrd image via make variable INITRD=<path>)'
>    echo  '* dtbs          - Build device tree blobs for enabled boards'
> +  echo  '  dtbs_install  - Install dtbs'
> +  echo  '                  Install using (your) ~/bin/$(INSTALLDTBS) or'
> +  echo  '                  (distribution) /sbin/$(INSTALLDTBS) or'
> +  echo  '                  install to $(DTBBOOT)'
>    echo  '  install       - Install uncompressed kernel'
>    echo  '  zinstall      - Install compressed kernel'
>    echo  '  uinstall      - Install U-Boot wrapped compressed kernel'
> diff --git a/scripts/installdtbs.sh b/scripts/installdtbs.sh
> new file mode 100644
> index 000000000000..11027f00c3a4
> --- /dev/null
> +++ b/scripts/installdtbs.sh
> @@ -0,0 +1,33 @@
> +#!/bin/sh
> +#
> +# This file is subject to the terms and conditions of the GNU General Public
> +# License.  See the file "COPYING" in the main directory of this archive
> +# for more details.
> +#
> +# Copyright (C) 1995 by Linus Torvalds
> +#
> +# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
> +#
> +# Further adapted from arch/x86/boot/install.sh by Jason Cooper
> +#
> +# "make dtbs_install" script
> +#
> +# Arguments:
> +#   $1 - kernel version
> +#   $2 - default install path (blank if root directory)
> +#   $3 - directory containing dtbs
> +#
> +
> +# User may have a custom install script
> +
> +if [ -x ~/bin/${INSTALLDTBS} ]; then exec ~/bin/${INSTALLDTBS} "$@"; fi
> +if [ -x /sbin/${INSTALLDTBS} ]; then exec /sbin/${INSTALLDTBS} "$@"; fi
> +
> +# Default install
> +[ -d "$2" ] && rm -rf "$2"
> +
> +mkdir -p "$2"
> +
> +for dtb in `find "$3" -name "*.dtb"`; do
> +	cp "$dtb" "$2/${dtb##*/}"
> +done
> -- 
> 1.8.4.4
> 
> --
> 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

[PATCH V6] kbuild: dtbs_install: new make target

[Grant Likely]

On Fri, 10 Jan 2014 13:29:23 -0500, Jason Cooper <jason@lakedaemon.net> wrote:
> Grant,
> 
> On Sun, Dec 01, 2013 at 11:56:28PM +0000, Jason Cooper wrote:
> > Unlike other build products in the Linux kernel, there is no 'make
> > *install' mechanism to put devicetree blobs in a standard place.
> > 
> > This patch is an attempt to fix this problem.  Akin to 'make install',
> > this creates a new make target, dtbs_install.  The script that gets
> > called defers to a distribution or user supplied installdtbs binary,
> > if found in the system.  Otherwise, the default action is to install the
> > built dtbs into
> > 
> >   /lib/devicetrees/${kernel_version}/${dts_filename}.dtb
> > 
> > This is done to keep dtbs from different kernel versions separate until
> > things have settled down.  Once the dtbs are stable, and not so strongly
> > linked to the kernel version, the devicetree files will most likely move
> > to their own repo.  Users will need to upgrade install scripts at that
> > time.
> > 
> > /lib has been selected over /boot since /boot is often a FAT filesystem
> > and a majority of the dts filenames are longer than 8+3.
> > 
> > Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> > ---
> 
> Is this good to go?

I took another look at it and did some rework. It bothered my that the
install script didnt' have any knowledge of the actual build targets and
just blindly copied the files it finds. I've reworked the patch to make
each file a separate target and also fixed a few bugs in the process.

I also removed the call out to an external script. I'm not convinced a
call out hook is the best approach when a buildroot tool can post
process the install directory. It wouldn't be hard to add back in, but I
don't want it to block this feature. I'll post my version in a minute.

g.

[PATCH V6] kbuild: dtbs_install: new make target

[Russell King - ARM Linux]

Okay, I'm digging up an old version of this patch - v7 was merged but
I find *nowhere* where that version was posted to people involved in
this discussion.

The reason is that I would've commented on v7, because of this stupid
thing (which is now in scripts/Makefile.dtbsinst):

+       $(Q)if [ -d $(INSTALL_DTBS_PATH).old ]; then rm -rf $(INSTALL_DTBS_PATH).old; fi
+       $(Q)if [ -d $(INSTALL_DTBS_PATH) ]; then mv $(INSTALL_DTBS_PATH) $(INSTALL_DTBS_PATH).old; fi
+       $(Q)mkdir -p $(INSTALL_DTBS_PATH)

What gives any kernel installation target the right to move a directory
out of the way?

Let's say that you do this:

	make install INSTALL_PATH=$sys_root/boot
	make dtbs_install INSTALL_DTBS_PATH=$sys_root/boot

The result is that dtbs_install thinks it has the right to rename that
boot directory to boot.old, create a new one, and place the DTBs in
there, thereby leaving you with no kernel to boot - and if you run it
again, it _deletes_ the original directory.

No *other* kernel install target has this behaviour, not even 'make
modules_installl'.  This is stupid and dangerous behaviour.  At the
very least, this behaviour should be *well* documented.

Linus, will you take a patch to remove the lines moving a pre-existing
INSTALL_DTBS_PATH directory out of the way?

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

[PATCH] dtbsinstall: don't move target directory out of the way

[Russell King]

No other kernel installation target moves the target directory out of
the way, even deleting an old version of it.  These are destructive
operations, ones which the kernel build system should not be making.

Remove this behaviour.

If this behaviour is required at installation time, this should be
done by the installation external to the kernel makefiles, just like
it would be done for 'make modules_install'.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 scripts/Makefile.dtbinst | 2 --
 1 file changed, 2 deletions(-)

diff --git a/scripts/Makefile.dtbinst b/scripts/Makefile.dtbinst
index 909ed7a2ac61..e0254058b0e9 100644
--- a/scripts/Makefile.dtbinst
+++ b/scripts/Makefile.dtbinst
@@ -23,8 +23,6 @@ include $(srctree)/$(obj)/Makefile
 PHONY += __dtbs_install_prep
 __dtbs_install_prep:
 ifeq ("$(dtbinst-root)", "$(obj)")
-	$(Q)if [ -d $(INSTALL_DTBS_PATH).old ]; then rm -rf $(INSTALL_DTBS_PATH).old; fi
-	$(Q)if [ -d $(INSTALL_DTBS_PATH) ]; then mv $(INSTALL_DTBS_PATH) $(INSTALL_DTBS_PATH).old; fi
 	$(Q)mkdir -p $(INSTALL_DTBS_PATH)
 endif
 
-- 
1.8.3.1

[PATCH] dtbsinstall: don't move target directory out of the way

[Jason Cooper]

On Sat, Mar 28, 2015 at 01:37:19PM +0000, Russell King wrote:
> No other kernel installation target moves the target directory out of
> the way, even deleting an old version of it.  These are destructive
> operations, ones which the kernel build system should not be making.
> 
> Remove this behaviour.
> 
> If this behaviour is required at installation time, this should be
> done by the installation external to the kernel makefiles, just like
> it would be done for 'make modules_install'.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  scripts/Makefile.dtbinst | 2 --
>  1 file changed, 2 deletions(-)

Acked-by: Jason Cooper <jason@lakedaemon.net>

thx,

Jason.

[PATCH V6] kbuild: dtbs_install: new make target

[Jason Cooper]

Russell,

On Sat, Mar 28, 2015 at 01:23:20PM +0000, Russell King - ARM Linux wrote:
> Okay, I'm digging up an old version of this patch - v7 was merged but
> I find *nowhere* where that version was posted to people involved in
> this discussion.

fwiw, I just went through my archive of patch submissions:

$ ls ~/projects/linux/dtbs_install/
v2  v3  v4  v5  v6
$

I never wrote a v7.  :-(  Regardless,

> The reason is that I would've commented on v7, because of this stupid
> thing (which is now in scripts/Makefile.dtbsinst):
> 
> +       $(Q)if [ -d $(INSTALL_DTBS_PATH).old ]; then rm -rf $(INSTALL_DTBS_PATH).old; fi
> +       $(Q)if [ -d $(INSTALL_DTBS_PATH) ]; then mv $(INSTALL_DTBS_PATH) $(INSTALL_DTBS_PATH).old; fi
> +       $(Q)mkdir -p $(INSTALL_DTBS_PATH)
> 
> What gives any kernel installation target the right to move a directory
> out of the way?
> 
> Let's say that you do this:
> 
> 	make install INSTALL_PATH=$sys_root/boot
> 	make dtbs_install INSTALL_DTBS_PATH=$sys_root/boot
> 
> The result is that dtbs_install thinks it has the right to rename that
> boot directory to boot.old, create a new one, and place the DTBs in
> there, thereby leaving you with no kernel to boot - and if you run it
> again, it _deletes_ the original directory.
> 
> No *other* kernel install target has this behaviour, not even 'make
> modules_installl'.  This is stupid and dangerous behaviour.  At the
> very least, this behaviour should be *well* documented.

you are correct.  This should be fixed.

thx,

Jason.

[PATCH V6] kbuild: dtbs_install: new make target

[Olof Johansson]

On Sat, Mar 28, 2015 at 8:58 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> Russell,
>
> On Sat, Mar 28, 2015 at 01:23:20PM +0000, Russell King - ARM Linux wrote:
>> Okay, I'm digging up an old version of this patch - v7 was merged but
>> I find *nowhere* where that version was posted to people involved in
>> this discussion.
>
> fwiw, I just went through my archive of patch submissions:
>
> $ ls ~/projects/linux/dtbs_install/
> v2  v3  v4  v5  v6
> $
>
> I never wrote a v7.  :-(  Regardless,

It was posted by Grant, and posted to LKML, devicetree@ and
linux-kbuild. The patch was directly cc:d to Jason, Michal Marek,
Russell and Rob Herring.


-Olof

[PATCH V6] kbuild: dtbs_install: new make target

[Russell King - ARM Linux]

On Sun, Mar 29, 2015 at 01:34:41PM -0700, Olof Johansson wrote:
> On Sat, Mar 28, 2015 at 8:58 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > Russell,
> >
> > On Sat, Mar 28, 2015 at 01:23:20PM +0000, Russell King - ARM Linux wrote:
> >> Okay, I'm digging up an old version of this patch - v7 was merged but
> >> I find *nowhere* where that version was posted to people involved in
> >> this discussion.
> >
> > fwiw, I just went through my archive of patch submissions:
> >
> > $ ls ~/projects/linux/dtbs_install/
> > v2  v3  v4  v5  v6
> > $
> >
> > I never wrote a v7.  :-(  Regardless,
> 
> It was posted by Grant, and posted to LKML, devicetree@ and
> linux-kbuild. The patch was directly cc:d to Jason, Michal Marek,
> Russell and Rob Herring.

I couldn't find a copy of it - grepping for "^Subject:.*dtb.*install"
around December 2013 and before only found Jason's original patches.

The commit introducing it says:

commit f4d4ffc03efc864645b990e1d579bbe1b8e358a4
Author:     Jason Cooper <jason@lakedaemon.net>
AuthorDate: Sun Dec 1 23:56:28 2013 +0000
Commit:     Grant Likely <grant.likely@linaro.org>
CommitDate: Thu Feb 20 15:53:39 2014 +0000

    kbuild: dtbs_install: new make target

So it seems that I was looking at the wrong date range... Grant did
send the patch on the 4th February, which I never got around to
reading.

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

[PATCH V6] kbuild: dtbs_install: new make target

[Jason Cooper]

On Sun, Mar 29, 2015 at 01:34:41PM -0700, Olof Johansson wrote:
> On Sat, Mar 28, 2015 at 8:58 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > Russell,
> >
> > On Sat, Mar 28, 2015 at 01:23:20PM +0000, Russell King - ARM Linux wrote:
> >> Okay, I'm digging up an old version of this patch - v7 was merged but
> >> I find *nowhere* where that version was posted to people involved in
> >> this discussion.
> >
> > fwiw, I just went through my archive of patch submissions:
> >
> > $ ls ~/projects/linux/dtbs_install/
> > v2  v3  v4  v5  v6
> > $
> >
> > I never wrote a v7.  :-(  Regardless,
> 
> It was posted by Grant, and posted to LKML, devicetree@ and
> linux-kbuild. The patch was directly cc:d to Jason, Michal Marek,
> Russell and Rob Herring.

Ah, now I found it:

  http://lkml.iu.edu/hypermail/linux/kernel/1402.0/01294.html

My initial search missed it because it didn't have v7 in the subject.
I should just trust the Google, and not my grep-fu.  :-)

Thanks for the clarification.

thx,

Jason.