[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1b946fcf-47a9-012d-1b04-f4bbd2682607@gmail.com>
Date: Fri, 21 Feb 2020 11:47:44 -0600
From: Frank Rowand <frowand.list@...il.com>
To: Alexandre Torgue <alexandre.torgue@...com>, robh+dt@...nel.org,
Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>,
david@...son.dropbear.id.au, sjg@...omium.org
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kbuild@...r.kernel.org, devicetree-compiler@...r.kernel.org,
Ian Lepore <ian@...ebsd.org>
Subject: Re: [RFC PATCH v2 0/4] Add device tree build information
On 2/21/20 10:14 AM, Alexandre Torgue wrote:
> (with title it's better ;)
>
> Hi,
>
> The goal of this series is to add device tree build information in dtb.
> This information can be dtb build date, where devicetree files come from,
> who built the dtb ... Actually, same kind of information that you can find
> in the Linux banner which is printout during kernel boot. Having the same
> kind of information for device tree is useful for debugging and maintenance.
>
> A file (dtb-build.txt) containing a string with build information (e.g.,
>>>From Linux 5.5.0-rc1 by alex the Mon Jan 13 18:25:38 CET 2020) is generated by
> "gen_dtb_build_info.sh" script.
>
> This file has to be included manually in each dts file that would like to use
> this build information.
In the RFC series, you said:
"I gonna prepare a V2 with David proposition (to use overlay format) by
keeping in mind not to modify existing dts(i) files."
https://lore.kernel.org/linux-devicetree/9d83a36c-78c5-3452-bb48-209d68c46038@st.com/
But here in v2 instead requires including dtb-build.txt.
This would require modifying every single main .dts file to get the build info.
I would prefer the method that Ian and David came up with (sorry, no lore link,
it did not go to lkml). Extract from David's email:
Date: Tue, 21 Jan 2020 13:05:25 +1100
From: David Gibson <david@...son.dropbear.id.au>
Subject: Re: [RFC PATCH 1/3] dtc: Add dtb build information option
> 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.
-Frank
>
> of/fdt.c is modified to printout "build-info" property during Kernel boot and
> scripts/Makefile.lib is modified to call "gen_dtb_build_info.sh" script.
>
> Patch 1 & 2 script and of/fdt.c updates
> Patch 3 is an example of use in stm32mp157c-dk2.dts file.
> Patch 4 is a tentative to make it automatic (not yet 100% functional).
>
> regards
> Alex
>
> Changes since v1;
> - Remove modification in dtc (no more -B option)
> - Generate a file containing build info which is directly included in dts
> file.
>
>
> Regards
> Alex
>
> Alexandre Torgue (4):
> scripts: Add script to generate dtb build information
> of: fdt: print dtb build information
> ARM: dts: stm32: Add dtb build information entry for stm32mp157c-dk2
> script: make automatic dtb build info generation
>
> arch/arm/boot/dts/stm32mp157c-dk2.dts | 1 +
> drivers/of/fdt.c | 9 +++++++++
> scripts/Makefile.lib | 3 +++
> scripts/gen_dtb_build_info.sh | 12 ++++++++++++
> 4 files changed, 25 insertions(+)
> create mode 100755 scripts/gen_dtb_build_info.sh
>
Powered by blists - more mailing lists