linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Torgue <alexandre.torgue@st.com>
To: Frank Rowand <frowand.list@gmail.com>, <robh+dt@kernel.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Michal Marek <michal.lkml@markovi.net>,
	<david@gibson.dropbear.id.au>, <sjg@chromium.org>
Cc: <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-kbuild@vger.kernel.org>,
	<devicetree-compiler@vger.kernel.org>,
	Ian Lepore <ian@freebsd.org>
Subject: Re: [RFC PATCH v2 0/4] Add device tree build information
Date: Mon, 2 Mar 2020 13:55:55 +0100	[thread overview]
Message-ID: <dba17be2-067f-8221-f313-7a3edcf61511@st.com> (raw)
In-Reply-To: <67d75f0c-7478-23b0-8619-746cf83cedb5@gmail.com>

Hi Franck

On 2/28/20 6:47 PM, Frank Rowand wrote:
> Hi Alexandred,
> 
> Ping.
> 

Sorry I was off last week.

> -Frank
> 
> 
> On 2/21/20 11:47 AM, Frank Rowand wrote:
>> 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@gibson.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

Yes. I try briefly this idea but I got issues with dts-v1 tag. I agree, 
it is cleaner to not modify input dts file. I can rework int this way.

regards
Alex

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

  reply	other threads:[~2020-03-02 12:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-21 16:14 [RFC PATCH v2 0/4] Add device tree build information Alexandre Torgue
2020-02-21 16:14 ` [RFC PATCH v2 1/4] scripts: Add script to generate dtb " Alexandre Torgue
2020-02-21 17:52   ` Frank Rowand
2020-02-21 19:38     ` Rob Herring
2020-03-02 12:40       ` Alexandre Torgue
2020-02-23 21:59     ` David Gibson
2020-02-24  0:57       ` Frank Rowand
2020-02-21 16:14 ` [RFC PATCH v2 2/4] of: fdt: print " Alexandre Torgue
2020-02-26 21:36   ` Rob Herring
2020-02-21 16:14 ` [RFC PATCH v2 3/4] ARM: dts: stm32: Add dtb build information entry for stm32mp157c-dk2 Alexandre Torgue
2020-02-21 16:14 ` [RFC PATCH v2 4/4] script: make automatic dtb build info generation Alexandre Torgue
2020-02-21 17:59   ` Frank Rowand
2020-02-26 20:56   ` Rob Herring
2020-02-21 17:47 ` [RFC PATCH v2 0/4] Add device tree build information Frank Rowand
2020-02-28 17:47   ` Frank Rowand
2020-03-02 12:55     ` Alexandre Torgue [this message]
2020-03-31  1:03       ` Steve McIntyre
2020-03-31 15:00         ` Alexandre Torgue

Reply instructions:

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

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

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=dba17be2-067f-8221-f313-7a3edcf61511@st.com \
    --to=alexandre.torgue@st.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=devicetree-compiler@vger.kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=ian@freebsd.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=robh+dt@kernel.org \
    --cc=sjg@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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