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