| Message ID | 20200221161418.20225-1-alexandre.torgue@st.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add device tree build information | expand |
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 > > 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 >
Hi Alexandred, Ping. -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 > >> >> 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 >> > >
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 >>> >> >> >
Hi Alexandre, On Mon, Mar 02, 2020 at 01:55:55PM +0100, Alexandre Torgue wrote: >On 2/28/20 6:47 PM, Frank Rowand wrote: >> > 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. Have you made any progress on this please? Cheers,
Hi Steeve On 3/31/20 3:03 AM, Steve McIntyre wrote: > Hi Alexandre, > > On Mon, Mar 02, 2020 at 01:55:55PM +0100, Alexandre Torgue wrote: >> On 2/28/20 6:47 PM, Frank Rowand wrote: >>>> 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. > > Have you made any progress on this please? Unfortunately no. I cook something locally but not yet upstream-able. Due to project issue I didn't find time to work on it. I think (I hope) to be less busy next week and so I'll restart it. regards alex > > Cheers, >