Hi David
On 1/21/20 3:05 AM, David Gibson wrote:
On Mon, Jan 20, 2020 at 11:55:52AM -0700, Ian Lepore wrote:
On Sun, 2020-01-19 at 16:39 +1000, David Gibson wrote:
On Fri, Jan 17, 2020 at 08:43:23AM -0600, Rob Herring wrote:
On Fri, Jan 17, 2020 at 6:26 AM David Gibson
<david@xxxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, Jan 16, 2020 at 09:58:23AM +0100, Alexandre Torgue wrote:
Hi David
[...]
My first idea was to not modify all existing .dts files. Adding
an extra option in dtc is (for me) the softer way to do it. I
mean, compile information should come through compiler without
modify .dts files outside from dtc. In this way it will be easy
to everybody using dtc (inside our outside Linux tree) to add
dtb build info (even if they don't how to write a dts file).
But you're not really having this information coming from the
compiler. Instead you're adding a compiler option that just
force includes another file into the generated tree, and it's up
to your build scripts to put something useful into that file.
I don't really see that as preferable to modifying the .dts
files.
I also dislike the fact that the option as proposed is much more
general than the name suggests, but also very similar too, but
much more specific than the existing /incbin/ option.
What might be better would be to have a dtc option which force
appends an extra .dts to the mail .dts compiled. You can then
put an overlay template in that file, something like:
&{/} {
linux,build-info = /incbin/ "build-info.txt;
}
I like this suggestion either as an include another dts file or an
overlay.
Sorry, to be clear what I'm talking about here is just including
another dts file, and using the compile-type overlay syntax. This is
not the same as .dtbo style runtime overlays (though the final result
is about the same in this case).
Given that dts files are run through the C preprocessor before being
fed to dtc, the build script could use the '-include' flag to force-
include a fragment containing generated build info without any need to
modify existing dts files.
Uh... maybe. -include will essentially prepend the forced file, which
is a bit awkward for our purposes. It means that the prepended file
would need the /dts-v1/ tag, and we couldn't have it in the main files
which would be a bit confusing. I think it would also cause problems
with any /memreserve/ tags and means that the main tree could in
theory overwrite the build information which we don't necessarily
want.
I guess we could build things the other way around: have the main .dts
file specified with -include and have the dts on the dtc commandline
be a fixed one with the build information. It'd be a little weird,
though.
I reopen this old RFC on my side (sorry for the delay). I sent a v2 for
it some weeks but without adding modifications you suggested. I'm now
looking at it. Just to remind you my goal: I want to add a property in
the ongoing build dts. This property will contain build-info (date ...).
So I created a toto.dtsi, with :
&{/} {
build-info = /incbin/ "build-info.txt;
}
In Makefile.lib, before calling:
test ?= $(objtree)/scripts/toto.dtsi
$(HOSTCC) ...
cat $(test) >> $(dtc-tmp) ;\
$(DTC) -O ...
Is it something acceptable? Or did you have something else in mind ?
(and if nothing in mind, it's my fault, to long time to reopen this
subject :))
thanks in advance
alex
The latter could be useful as a way to maintain current dtb
files while splitting the source files into base and overlay dts
files.
But no, let's not prepend this with 'linux'. It's not a property
specific for Linux to consume.
It's not really about who consumes it. It's about defining a
namespace for the new property to exist in, since it's not part of a
relevant standard (if we wanted to make it such, we should pin down
what goes in there with much more precision).
This is specific to files built in the Linux tree, hence my
suggestion of "linux", whoever ends up consuming them.
I tend to agree with this. We use the dts files in freebsd, and if we
wanted to include some build metadata, it would probably have different
info in a different format than what linux uses. I would be inclined
to add those as freebsd,build-info. As well as the namespace, this
would give consumers some clue about what format the build info string
might have.
-- Ian
