| Message ID | 20200113181625.3130-1-alexandre.torgue@st.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add device tree build information | expand |
Hi Alexandre! alexandre.torgue@st.com wrote: > >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. > >To achieve that a new option "-B" (using an argument) is added to dtc. >The argument is a file 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). >DTC use it to append dts file with a new string property "Build-info". > >of/fdt.c is modified to printout "Build-info" property during Kernel boot and >scripts/Makefile.lib is modified to use dtc -B option during kernel make (this >last part could be improved for sure). > >Regards >Alex > >Alexandre Torgue (3): > dtc: Add dtb build information option > of: fdt: print dtb build information > scripts: Use -B dtc option to generate dtb build information. > > drivers/of/fdt.c | 9 +++++++ > scripts/Makefile.lib | 11 +++++--- > scripts/dtc/dtc.c | 55 +++++++++++++++++++++++++++++++++----- > scripts/gen_dtb_build_info | 11 ++++++++ > 4 files changed, 76 insertions(+), 10 deletions(-) > create mode 100755 scripts/gen_dtb_build_info Looks good to me in testing here: [ 0.000000] OF: fdt: From Linux 5.5.0-rc6-00031-g95e20af9fb9c-dirty by stemci01 the Wed 15 Jan 14:33:25 GMT 2020. Tested-By: Steve McIntyre <steve.mcintyre@linaro.org>
On 1/13/20 12:16 PM, Alexandre Torgue wrote: > 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. > > To achieve that a new option "-B" (using an argument) is added to dtc. > The argument is a file 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). > DTC use it to append dts file with a new string property "Build-info". > > of/fdt.c is modified to printout "Build-info" property during Kernel boot and > scripts/Makefile.lib is modified to use dtc -B option during kernel make (this > last part could be improved for sure). Please read through the thread at: https://lore.kernel.org/linux-arm-kernel/550A42AC.8060104@gmail.com/ which was my attempt to do something similar. -Frank > > Regards > Alex > > Alexandre Torgue (3): > dtc: Add dtb build information option > of: fdt: print dtb build information > scripts: Use -B dtc option to generate dtb build information. > > drivers/of/fdt.c | 9 +++++++ > scripts/Makefile.lib | 11 +++++--- > scripts/dtc/dtc.c | 55 +++++++++++++++++++++++++++++++++----- > scripts/gen_dtb_build_info | 11 ++++++++ > 4 files changed, 76 insertions(+), 10 deletions(-) > create mode 100755 scripts/gen_dtb_build_info >
Hi Franck, On 1/16/20 3:28 AM, Frank Rowand wrote: > On 1/13/20 12:16 PM, Alexandre Torgue wrote: >> 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. >> >> To achieve that a new option "-B" (using an argument) is added to dtc. >> The argument is a file 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). >> DTC use it to append dts file with a new string property "Build-info". >> >> of/fdt.c is modified to printout "Build-info" property during Kernel boot and >> scripts/Makefile.lib is modified to use dtc -B option during kernel make (this >> last part could be improved for sure). > > Please read through the thread at: > > https://lore.kernel.org/linux-arm-kernel/550A42AC.8060104@gmail.com/ > > which was my attempt to do something similar. Yes the idea is the same: get build DTB information like build date, "who built the DTB" ... The difference seems to be the way to do it. In my case, I don't want to modify existing dts source files., but I "just" append them by creating a new property with a string containing this build information. Why your proposition has not been accepted ? Regards Alex > > -Frank > >> >> Regards >> Alex >> >> Alexandre Torgue (3): >> dtc: Add dtb build information option >> of: fdt: print dtb build information >> scripts: Use -B dtc option to generate dtb build information. >> >> drivers/of/fdt.c | 9 +++++++ >> scripts/Makefile.lib | 11 +++++--- >> scripts/dtc/dtc.c | 55 +++++++++++++++++++++++++++++++++----- >> scripts/gen_dtb_build_info | 11 ++++++++ >> 4 files changed, 76 insertions(+), 10 deletions(-) >> create mode 100755 scripts/gen_dtb_build_info >> >
On 1/16/20 2:19 AM, Alexandre Torgue wrote: > Hi Franck, > > On 1/16/20 3:28 AM, Frank Rowand wrote: >> On 1/13/20 12:16 PM, Alexandre Torgue wrote: >>> 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. >>> >>> To achieve that a new option "-B" (using an argument) is added to dtc. >>> The argument is a file 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). >>> DTC use it to append dts file with a new string property "Build-info". >>> >>> of/fdt.c is modified to printout "Build-info" property during Kernel boot and >>> scripts/Makefile.lib is modified to use dtc -B option during kernel make (this >>> last part could be improved for sure). >> >> Please read through the thread at: >> >> https://lore.kernel.org/linux-arm-kernel/550A42AC.8060104@gmail.com/ >> >> which was my attempt to do something similar. > > Yes the idea is the same: get build DTB information like build date, > "who built the DTB" ... The difference seems to be the way to do it. > In my case, I don't want to modify existing dts source files., but I > "just" append them by creating a new property with a string > containing this build information.> > Why your proposition has not been accepted ? Since you are asking this question, I am presuming that you did not read the replies in the thread I referenced. Please read through the entire thread. Most of the review comments were objecting to the concept of my proposal. -Frank > > Regards > Alex > >> >> -Frank >> >>> >>> Regards >>> Alex >>> >>> Alexandre Torgue (3): >>> dtc: Add dtb build information option >>> of: fdt: print dtb build information >>> scripts: Use -B dtc option to generate dtb build information. >>> >>> drivers/of/fdt.c | 9 +++++++ >>> scripts/Makefile.lib | 11 +++++--- >>> scripts/dtc/dtc.c | 55 +++++++++++++++++++++++++++++++++----- >>> scripts/gen_dtb_build_info | 11 ++++++++ >>> 4 files changed, 76 insertions(+), 10 deletions(-) >>> create mode 100755 scripts/gen_dtb_build_info >>> >> >
Hi Franck On 1/17/20 8:13 PM, Frank Rowand wrote: > > On 1/16/20 2:19 AM, Alexandre Torgue wrote: >> Hi Franck, >> >> On 1/16/20 3:28 AM, Frank Rowand wrote: >>> On 1/13/20 12:16 PM, Alexandre Torgue wrote: >>>> 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. >>>> >>>> To achieve that a new option "-B" (using an argument) is added to dtc. >>>> The argument is a file 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). >>>> DTC use it to append dts file with a new string property "Build-info". >>>> >>>> of/fdt.c is modified to printout "Build-info" property during Kernel boot and >>>> scripts/Makefile.lib is modified to use dtc -B option during kernel make (this >>>> last part could be improved for sure). >>> >>> Please read through the thread at: >>> >>> https://lore.kernel.org/linux-arm-kernel/550A42AC.8060104@gmail.com/ >>> >>> which was my attempt to do something similar. >> >> Yes the idea is the same: get build DTB information like build date, >> "who built the DTB" ... The difference seems to be the way to do it. >> In my case, I don't want to modify existing dts source files., but I >> "just" append them by creating a new property with a string >> containing this build information.> >> Why your proposition has not been accepted ? > > Since you are asking this question, I am presuming that you did not > read the replies in the thread I referenced. Please read through > the entire thread. Most of the review comments were objecting to > the concept of my proposal. Sorry I have been lazy :$. This series is a tiny one compare to yours, and adds less dtb information (only git used, who built dtb and the date). There are no "dtb versions", and "absolute/relative" path which created concerns. One remaining concern is "reproducible build" but making dtb info optional could respond to it. I continue to think that it's useful to get those information (even if it's only a string) But before continuing (and find a better technical way to do it), I need to know if there are no other obstacles. Regards Alex > > -Frank > >> >> Regards >> Alex >> >>> >>> -Frank >>> >>>> >>>> Regards >>>> Alex >>>> >>>> Alexandre Torgue (3): >>>> dtc: Add dtb build information option >>>> of: fdt: print dtb build information >>>> scripts: Use -B dtc option to generate dtb build information. >>>> >>>> drivers/of/fdt.c | 9 +++++++ >>>> scripts/Makefile.lib | 11 +++++--- >>>> scripts/dtc/dtc.c | 55 +++++++++++++++++++++++++++++++++----- >>>> scripts/gen_dtb_build_info | 11 ++++++++ >>>> 4 files changed, 76 insertions(+), 10 deletions(-) >>>> create mode 100755 scripts/gen_dtb_build_info >>>> >>> >> >
On 1/20/20 4:56 AM, Alexandre Torgue wrote: > Hi Franck > > On 1/17/20 8:13 PM, Frank Rowand wrote: >> >> On 1/16/20 2:19 AM, Alexandre Torgue wrote: >>> Hi Franck, >>> >>> On 1/16/20 3:28 AM, Frank Rowand wrote: >>>> On 1/13/20 12:16 PM, Alexandre Torgue wrote: >>>>> 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. >>>>> >>>>> To achieve that a new option "-B" (using an argument) is added to dtc. >>>>> The argument is a file 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). >>>>> DTC use it to append dts file with a new string property "Build-info". >>>>> >>>>> of/fdt.c is modified to printout "Build-info" property during Kernel boot and >>>>> scripts/Makefile.lib is modified to use dtc -B option during kernel make (this >>>>> last part could be improved for sure). >>>> >>>> Please read through the thread at: >>>> >>>> https://lore.kernel.org/linux-arm-kernel/550A42AC.8060104@gmail.com/ >>>> >>>> which was my attempt to do something similar. >>> >>> Yes the idea is the same: get build DTB information like build date, >>> "who built the DTB" ... The difference seems to be the way to do it. >>> In my case, I don't want to modify existing dts source files., but I >>> "just" append them by creating a new property with a string >>> containing this build information.> >>> Why your proposition has not been accepted ? >> >> Since you are asking this question, I am presuming that you did not >> read the replies in the thread I referenced. Please read through >> the entire thread. Most of the review comments were objecting to >> the concept of my proposal. > > Sorry I have been lazy :$. This series is a tiny one compare to > yours, and adds less dtb information (only git used, who built dtb > and the date). There are no "dtb versions", and "absolute/relative" > path which created concerns. One remaining concern is "reproducible Here is an example of the info from one of my builds: From Linux 5.5.0-rc2-dirty by frowand the Mon Jan 20 09:50:58 CST 2020. The information 'Linux 5.5.0-rc2-dirty' is precisely what was most objected to in my proposal. -Frank > build" but making dtb info optional could respond to it. I continue > to think that it's useful to get those information (even if it's only > a string) But before continuing (and find a better technical way to > do it), I need to know if there are no other obstacles. > > Regards > Alex > > >> >> -Frank >> >>> >>> Regards >>> Alex >>> >>>> >>>> -Frank >>>> >>>>> >>>>> Regards >>>>> Alex >>>>> >>>>> Alexandre Torgue (3): >>>>> dtc: Add dtb build information option >>>>> of: fdt: print dtb build information >>>>> scripts: Use -B dtc option to generate dtb build information. >>>>> >>>>> drivers/of/fdt.c | 9 +++++++ >>>>> scripts/Makefile.lib | 11 +++++--- >>>>> scripts/dtc/dtc.c | 55 +++++++++++++++++++++++++++++++++----- >>>>> scripts/gen_dtb_build_info | 11 ++++++++ >>>>> 4 files changed, 76 insertions(+), 10 deletions(-) >>>>> create mode 100755 scripts/gen_dtb_build_info >>>>> >>>> >>> >> >
Hi Frank! Thanks for the link back to the previous discussion, it's very helpful. On Mon, Jan 20, 2020 at 10:14:22AM -0600, Frank Rowand wrote: >On 1/20/20 4:56 AM, Alexandre Torgue wrote: ... >> and the date). There are no "dtb versions", and "absolute/relative" >> path which created concerns. One remaining concern is "reproducible > >Here is an example of the info from one of my builds: > > From Linux 5.5.0-rc2-dirty by frowand the Mon Jan 20 09:50:58 CST 2020. > >The information 'Linux 5.5.0-rc2-dirty' is precisely what was most objected >to in my proposal. ACK. :-( I'm surprised to see so much push-back on what looks like a simple piece of information here. I've had users *specifically* asking for this kind of identification so that they can verify the version of the DTB they're using at runtime. Right now it can be a guessing game, which does not help people trying to debug problems. Cheers,
On 1/20/20 12:28 PM, Steve McIntyre wrote: > Hi Frank! > > Thanks for the link back to the previous discussion, it's very > helpful. > > On Mon, Jan 20, 2020 at 10:14:22AM -0600, Frank Rowand wrote: >> On 1/20/20 4:56 AM, Alexandre Torgue wrote: > > ... > >>> and the date). There are no "dtb versions", and "absolute/relative" >>> path which created concerns. One remaining concern is "reproducible >> >> Here is an example of the info from one of my builds: >> >> From Linux 5.5.0-rc2-dirty by frowand the Mon Jan 20 09:50:58 CST 2020. >> >> The information 'Linux 5.5.0-rc2-dirty' is precisely what was most objected >> to in my proposal. > > ACK. :-( I'm surprised to see so much push-back on what looks like a > simple piece of information here. Me too. > > I've had users *specifically* asking for this kind of identification > so that they can verify the version of the DTB they're using at > runtime. Right now it can be a guessing game, which does not help > people trying to debug problems. > > Cheers, > If the information was reported as debug information via pr_debug(), would that work for your use case? Or would the users' kernels not have debug enabled in the configuration? -Frank
On 1/20/20 9:20 PM, Frank Rowand wrote: > On 1/20/20 12:28 PM, Steve McIntyre wrote: >> Hi Frank! >> >> Thanks for the link back to the previous discussion, it's very >> helpful. >> >> On Mon, Jan 20, 2020 at 10:14:22AM -0600, Frank Rowand wrote: >>> On 1/20/20 4:56 AM, Alexandre Torgue wrote: >> >> ... >> >>>> and the date). There are no "dtb versions", and "absolute/relative" >>>> path which created concerns. One remaining concern is "reproducible >>> >>> Here is an example of the info from one of my builds: >>> >>> From Linux 5.5.0-rc2-dirty by frowand the Mon Jan 20 09:50:58 CST 2020. >>> >>> The information 'Linux 5.5.0-rc2-dirty' is precisely what was most objected >>> to in my proposal. >> >> ACK. :-( I'm surprised to see so much push-back on what looks like a >> simple piece of information here. > > Me too. > > >> >> I've had users *specifically* asking for this kind of identification >> so that they can verify the version of the DTB they're using at >> runtime. Right now it can be a guessing game, which does not help >> people trying to debug problems. >> >> Cheers, >> > > If the information was reported as debug information via pr_debug(), > would that work for your use case? Or would the users' kernels > not have debug enabled in the configuration? And even pr_debug() might not be sufficient since the property value is available via /proc/device-tree if the proc file system is enabled.
[ Adding lakml to the CC list ] On Mon, Jan 20, 2020 at 09:20:55PM -0600, Frank Rowand wrote: >On 1/20/20 12:28 PM, Steve McIntyre wrote: >> On Mon, Jan 20, 2020 at 10:14:22AM -0600, Frank Rowand wrote: >>> On 1/20/20 4:56 AM, Alexandre Torgue wrote: >>> >>> Here is an example of the info from one of my builds: >>> >>> From Linux 5.5.0-rc2-dirty by frowand the Mon Jan 20 09:50:58 CST 2020. >>> >>> The information 'Linux 5.5.0-rc2-dirty' is precisely what was most objected >>> to in my proposal. >> >> ACK. :-( I'm surprised to see so much push-back on what looks like a >> simple piece of information here. > >Me too. So, looking at the comments back on the old thread... Alexandre is proposing somthing slightly different here: a patch to add a simple string to allow for a description of where the DTB came from. The particular example he uses here fills in build details from the Linux repo, but it could just as easily be filled in as part of a U-Boot build, or the build of a DTB included with EDK2, or whatever other firmware might include it. It might be useful to also add similar debug output into U-Boot, or for that matter any other DT-using project. As Rob says later, it's simply information for humans to help identify where a DTB came from. Nothing more. >> I've had users *specifically* asking for this kind of identification >> so that they can verify the version of the DTB they're using at >> runtime. Right now it can be a guessing game, which does not help >> people trying to debug problems. > >If the information was reported as debug information via pr_debug(), >would that work for your use case? Or would the users' kernels >not have debug enabled in the configuration? Quite possibly not - I'm not 100% sure to be honest. :-/