[U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile
Use the GNU 'date' command to auto-generate a new U-Boot timestamp on every compile.
Signed-off-by: Peter Tyser ptyser@xes-inc.com --- I noticed that the build time of U-Boot was not updated on every compile which occassionally threw me for a loop as to whether a new U-Boot binary was programmed, etc. This patch updates a U_BOOT_DATE define on every compile which can then be used in place of the multiple "__DATE__ - __TIME__" preprocessor macros that are currently used.
This also ensures the timestamp will be the same for a board if it uses __TIME__ in multiple files.
Let me know if this would be accepted into mainline and I'll generate a formal patch updating all __DATE__/__TIME__ references.
Makefile | 2 ++ cpu/mpc85xx/start.S | 2 +- 2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile index c711df6..2c76003 100644 --- a/Makefile +++ b/Makefile @@ -366,6 +366,8 @@ $(VERSION_FILE): @( printf '#define U_BOOT_VERSION "U-Boot %s%s"\n' "$(U_BOOT_VERSION)" \ '$(shell $(CONFIG_SHELL) $(TOPDIR)/tools/setlocalversion $(TOPDIR))' \ ) > $@.tmp + @( printf '#define U_BOOT_DATE "%s"\n' '$(shell date +"%b %d %C%y - %T")' \ + ) >> $@.tmp @cmp -s $@ $@.tmp && rm -f $@.tmp || mv -f $@.tmp $@
gdbtools: diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S index 25d0390..dc55700 100644 --- a/cpu/mpc85xx/start.S +++ b/cpu/mpc85xx/start.S @@ -272,7 +272,7 @@ _start: .globl version_string version_string: .ascii U_BOOT_VERSION - .ascii " (", __DATE__, " - ", __TIME__, ")" + .ascii " (", U_BOOT_DATE, ")" .ascii CONFIG_IDENT_STRING, "\0"
.align 4
On Fri, 2008-10-17 at 17:51 -0500, Peter Tyser wrote:
Use the GNU 'date' command to auto-generate a new U-Boot timestamp on every compile.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
I noticed that the build time of U-Boot was not updated on every compile which occassionally threw me for a loop as to whether a new U-Boot binary was programmed, etc. This patch updates a U_BOOT_DATE define on every compile which can then be used in place of the multiple "__DATE__ - __TIME__" preprocessor macros that are currently used.
This also ensures the timestamp will be the same for a board if it uses __TIME__ in multiple files.
Let me know if this would be accepted into mainline and I'll generate a formal patch updating all __DATE__/__TIME__ references.
Instead of U_BOOT_DATE, we could use U_BOOT_DATE (month, day, year) and U_BOOT_TIME (24 hour time) to provide more granularity if others want that level of control.
Peter
On Fri, 17 Oct 2008 17:51:21 -0500 Peter Tyser ptyser@xes-inc.com wrote:
Use the GNU 'date' command to auto-generate a new U-Boot timestamp on every compile.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
I noticed that the build time of U-Boot was not updated on every compile which occassionally threw me for a loop as to whether a new U-Boot binary was programmed, etc. This patch updates a U_BOOT_DATE define on every compile which can then be used in place of the multiple "__DATE__ - __TIME__" preprocessor macros that are currently used.
this text probably belongs in the commit message above your SOB. But I still don't understand why __TIME__ didn't work for you..can you elaborate?
Kim
Hi Kim,
Use the GNU 'date' command to auto-generate a new U-Boot timestamp on every compile.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
I noticed that the build time of U-Boot was not updated on every compile which occassionally threw me for a loop as to whether a new U-Boot binary was programmed, etc. This patch updates a U_BOOT_DATE define on every compile which can then be used in place of the multiple "__DATE__ - __TIME__" preprocessor macros that are currently used.
this text probably belongs in the commit message above your SOB. But I still don't understand why __TIME__ didn't work for you..can you elaborate?
__TIME__ and __DATE__ aren't ideal as they are only updated when the file that contains them is recompiled. For example, during the normal modify/build/test cycle the version string remains the same for an 85xx board as start.S would not be recompiled. So any number of U-Boot compilations can contain different code, but have the same build time/version string. eg when a board boots up and spits out:
U-Boot 1.3.4 (Aug 7 2008 - 12:32:20)
CPU: 8572E, Version: 1.0, (0x80e80010) ....
the code really may not have been compiled on Aug 7th, it could have been compiled today, yesterday, etc.
It would be nice in my mind if every compile of U-Boot resulted in a new build time string. Thus you could easily determine which version is programmed on a board during bootup, by looking at a binary on your host computer using hexdump, etc. The RFC/PATCH I submitted made this change for the 85xx platform as an example - other uses of __TIME__ and __DATE__ would be similarly updated in a formal patch.
Also, if a board used __TIME__/__DATE__ in more than one location, it could be confusing as the times wouldn't be identical. For example, if the build time were printed in common/lcd.c, it would not be identical to the time printed on the serial port since lcd.c was not compiled at the same time as cpu/mpc8xx/start.S.
Best, Peter
Dear Peter Tyser,
In message 1224554522.11401.28.camel@ptyser-laptop you wrote:
this text probably belongs in the commit message above your SOB. But I still don't understand why __TIME__ didn't work for you..can you elaborate?
__TIME__ and __DATE__ aren't ideal as they are only updated when the file that contains them is recompiled. For example, during the normal modify/build/test cycle the version string remains the same for an 85xx board as start.S would not be recompiled. So any number of U-Boot compilations can contain different code, but have the same build time/version string. eg when a board boots up and spits out:
Actually the time stamp is completely useless in determining if the code is the same or different. I can compile the same code many times resulting in different time stamps and yet it's the very same code. And I can (at least theoretically) manage to build two completely different versions at the same time...
U-Boot 1.3.4 (Aug 7 2008 - 12:32:20)
...
the code really may not have been compiled on Aug 7th, it could have been compiled today, yesterday, etc.
Who cares when it was really built? If you are working in the recommended environment (i. e. using git) then you can be sure that this was the code of the v1.3.4 release; otherwise you would have seen something as
U-Boot 2008.10-rc2-00018-g8fd4166-dirty (Sep 30 2008 - 13:42:17)
This clearly tells you which version the code was based on (and that it contains local modifications that were not yet checked in).
It would be nice in my mind if every compile of U-Boot resulted in a new build time string. Thus you could easily determine which version is programmed on a board during bootup, by looking at a binary on your host
Timestamps are not suitable to provide this type of information. If you care about which code you are running, than make sure to use git.
Also, if a board used __TIME__/__DATE__ in more than one location, it could be confusing as the times wouldn't be identical. For example, if
Why would that be confusing? It seems natural to me that time changes when you do several things sequentially. If a board used __TIME__/__DATE__ in more than one location, then the board maintainer either did this intentionally (and thus wants to acchieve this result), or he did it without thinking, in which case it is obviously not an important issue to him).
the build time were printed in common/lcd.c, it would not be identical to the time printed on the serial port since lcd.c was not compiled at the same time as cpu/mpc8xx/start.S.
If you care about reliable version information, use the git based ID strings.
Best regards,
Wolfgang Denk
Hi Wolfgang,
__TIME__ and __DATE__ aren't ideal as they are only updated when the file that contains them is recompiled. For example, during the normal modify/build/test cycle the version string remains the same for an 85xx board as start.S would not be recompiled. So any number of U-Boot compilations can contain different code, but have the same build time/version string. eg when a board boots up and spits out:
Actually the time stamp is completely useless in determining if the code is the same or different. I can compile the same code many times resulting in different time stamps and yet it's the very same code.
The code won't be the same - the version string will be different and the different binaries would have different md5sums.
U-Boot 1.3.4 (Aug 7 2008 - 12:32:20)
...
the code really may not have been compiled on Aug 7th, it could have been compiled today, yesterday, etc.
Who cares when it was really built? If you are working in the recommended environment (i. e. using git) then you can be sure that this was the code of the v1.3.4 release; otherwise you would have seen something as
U-Boot 2008.10-rc2-00018-g8fd4166-dirty (Sep 30 2008 - 13:42:17)
This clearly tells you which version the code was based on (and that it contains local modifications that were not yet checked in).
Which local modifications though? Until I make another commit every version string will be the same.
It would be nice in my mind if every compile of U-Boot resulted in a new build time string. Thus you could easily determine which version is programmed on a board during bootup, by looking at a binary on your host
Timestamps are not suitable to provide this type of information. If you care about which code you are running, than make sure to use git.
I do, but the minor annoyance of having the exact same version string/time stamp for different code still exists for uncommited changes.
Also, if a board used __TIME__/__DATE__ in more than one location, it could be confusing as the times wouldn't be identical. For example, if
Why would that be confusing? It seems natural to me that time changes when you do several things sequentially. If a board used __TIME__/__DATE__ in more than one location, then the board maintainer either did this intentionally (and thus wants to acchieve this result), or he did it without thinking, in which case it is obviously not an important issue to him).
I agree that its not an important issue, but that's not to say it hasn't/won't confused customers/developers. eg the first time I noticed it, it fooled me into thinking my flash wasn't properly programmed after updating u-boot.
the build time were printed in common/lcd.c, it would not be identical to the time printed on the serial port since lcd.c was not compiled at the same time as cpu/mpc8xx/start.S.
If you care about reliable version information, use the git based ID strings.
I use git, but its version strings only change when commits occur. I think having an accurate build time stamp would be a nice feature. FWIW, Linux handles this "issue" very similarly to my proposed solution so that it can have its pretty banner. It even takes it a step further and gives a specific compile number (#15):
Linux version 2.6.23.17 (ptyser@ptyser) (gcc version 4.3.1 (crosstool-NG-xes) ) #15 SMP Wed Aug 6 11:45:55 CDT 2008
I know this patch isn't a big deal, but I think it would be a valuable change. If others don't agree I'll drop the issue.
Thanks, Peter
Peter Tyser wrote:
Hi Wolfgang,
[big snip]
I use git, but its version strings only change when commits occur. I think having an accurate build time stamp would be a nice feature. FWIW, Linux handles this "issue" very similarly to my proposed solution so that it can have its pretty banner. It even takes it a step further and gives a specific compile number (#15):
Linux version 2.6.23.17 (ptyser@ptyser) (gcc version 4.3.1 (crosstool-NG-xes) ) #15 SMP Wed Aug 6 11:45:55 CDT 2008
I know this patch isn't a big deal, but I think it would be a valuable change. If others don't agree I'll drop the issue.
Thanks, Peter
+1 Call me old fashioned, but I like time/date stamps. They are more meaningful to me as a quick "did I really load a new u-boot" or "when did I do *that*" than a git hash.
Cost: $0.00. Benefit: $0.02. Benefit/Cost = priceless.
FWIIW, gvb
Dear Jerry Van Baren,
In message 48FDEC8D.6010502@ge.com you wrote:
I know this patch isn't a big deal, but I think it would be a valuable change. If others don't agree I'll drop the issue.
...
+1 Call me old fashioned, but I like time/date stamps. They are more meaningful to me as a quick "did I really load a new u-boot" or "when did I do *that*" than a git hash.
Note that I'm not against this in principle. But if it gets changed, then not only for a single architecture, but everywhere.
Cost: $0.00. Benefit: $0.02. Benefit/Cost = priceless.
Cost: work to implement, review and test. Benefit: $0.02. Benefit/Cost = small ;-)
Best regards,
Wolfgang Denk
Hi Wolfgang,
Note that I'm not against this in principle. But if it gets changed, then not only for a single architecture, but everywhere.
Cost: $0.00. Benefit: $0.02. Benefit/Cost = priceless.
Cost: work to implement, review and test. Benefit: $0.02. Benefit/Cost = small ;-)
This PATCH/RFC was only meant as a quick example per the original email comments. It sounds like the patch would be worthwhile (let me know if I'm mistaken) so I'll go ahead and create a proper patch updating __TIME__/__DATE__ where relevant.
Thanks, Peter
On Tuesday 21 October 2008, Peter Tyser wrote:
Why would that be confusing? It seems natural to me that time changes when you do several things sequentially. If a board used __TIME__/__DATE__ in more than one location, then the board maintainer either did this intentionally (and thus wants to acchieve this result), or he did it without thinking, in which case it is obviously not an important issue to him).
I agree that its not an important issue, but that's not to say it hasn't/won't confused customers/developers. eg the first time I noticed it, it fooled me into thinking my flash wasn't properly programmed after updating u-boot.
Happend to me a few times as well. So I like your patch.
the build time were printed in common/lcd.c, it would not be identical to the time printed on the serial port since lcd.c was not compiled at the same time as cpu/mpc8xx/start.S.
If you care about reliable version information, use the git based ID strings.
I use git, but its version strings only change when commits occur. I think having an accurate build time stamp would be a nice feature. FWIW, Linux handles this "issue" very similarly to my proposed solution so that it can have its pretty banner. It even takes it a step further and gives a specific compile number (#15):
Linux version 2.6.23.17 (ptyser@ptyser) (gcc version 4.3.1 (crosstool-NG-xes) ) #15 SMP Wed Aug 6 11:45:55 CDT 2008
I know this patch isn't a big deal, but I think it would be a valuable change. If others don't agree I'll drop the issue.
As mentioned above, I think your patch is an improvement. So why not accept it?
Acked-by: Stefan Roese sr@denx.de
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Dear Stefan Roese,
In message 200810211657.06019.sr@denx.de you wrote:
I know this patch isn't a big deal, but I think it would be a valuable change. If others don't agree I'll drop the issue.
As mentioned above, I think your patch is an improvement. So why not accept it?
Because it changes one place and leaves 43 other, identical places unchanged.
Best regards,
Wolfgang Denk
Dear Peter Tyser,
In message 1224600029.18428.339.camel@localhost.localdomain you wrote:
Actually the time stamp is completely useless in determining if the code is the same or different. I can compile the same code many times resulting in different time stamps and yet it's the very same code.
The code won't be the same - the version string will be different and the different binaries would have different md5sums.
The *code* will be exactly the same. The binary images may differ in some strings, but the code is still the same.
But actually you just confirmed my argumnt.
U-Boot 2008.10-rc2-00018-g8fd4166-dirty (Sep 30 2008 - 13:42:17)
This clearly tells you which version the code was based on (and that it contains local modifications that were not yet checked in).
Which local modifications though? Until I make another commit every version string will be the same.
Indeed. Which tells you that it is a bad idea to ship any binaries with uncommitted modifications in your tree.
Hey, we can only provide the best environment for a sane development process. If you don't play by the rules you are then not exactly in a good position to complain. Talk to your QA manager, if you doubt my words ;-)
Timestamps are not suitable to provide this type of information. If you care about which code you are running, than make sure to use git.
I do, but the minor annoyance of having the exact same version string/time stamp for different code still exists for uncommited changes.
You must be doing something awfully wrong when you have uncommited changes in any form of software you're releasing.
I use git, but its version strings only change when commits occur. I
Thisis intentional - commits are the only way to change the code. Anything between commits is work in progress which you never should release to anybody, not even your bst friends.
I know this patch isn't a big deal, but I think it would be a valuable change. If others don't agree I'll drop the issue.
We take great care to generate a useful version ID string that really gets updated as soon as one of the files changes. The fact that we apend the __DATE__ and __TIME__ output to the boot messages is just for informational purposes (and a relict from earlier times, when git did not exist yet).1s
Note that there are more than 40 places in the code where __DATE__ and/or __TIME__ get used, in different ways. If you want to put more meaning into these strings than we have now, you will have to address all these use cases.
Best regards,
Wolfgang Denk
On Tue, Oct 21, 2008 at 9:59 AM, Wolfgang Denk wd@denx.de wrote:
Dear Peter Tyser,
Timestamps are not suitable to provide this type of information. If you care about which code you are running, than make sure to use git.
I do, but the minor annoyance of having the exact same version string/time stamp for different code still exists for uncommited changes.
You must be doing something awfully wrong when you have uncommited changes in any form of software you're releasing.
I don't think he's wanting this as much for releases (which would be fine with the git id as you mentioned), but during the development process. It is very useful during development to have a timestamp which confirms that what you are running now is what you expect. There are various ways I have used this:
* Catch that I failed to copy the new image to my tftp directory * Confirm that I'm booting from the flash bank I just programmed * Helpful for figuring out which of the files in my tftp directory corresponds to what's running
Also, while I can see good arguments for not having a time stamp, having one that is not up-to-date seems totally useless. The stamp might not be updated for months, and thus provides only an indicator as to when the date was last updated.
Upshot: I endorse this patch's concept, and urge Peter to put in his (apparently underpaid) time to complete it. :)
Andy
Hi Andy,
I don't think he's wanting this as much for releases (which would be fine with the git id as you mentioned), but during the development process. It is very useful during development to have a timestamp which confirms that what you are running now is what you expect. There are various ways I have used this:
- Catch that I failed to copy the new image to my tftp directory
- Confirm that I'm booting from the flash bank I just programmed
- Helpful for figuring out which of the files in my tftp directory
corresponds to what's running
100% agree - all our releases are generated from fully-committed git trees with tags. This patch only intends to improve development.
Also, while I can see good arguments for not having a time stamp, having one that is not up-to-date seems totally useless. The stamp might not be updated for months, and thus provides only an indicator as to when the date was last updated.
Upshot: I endorse this patch's concept, and urge Peter to put in his (apparently underpaid) time to complete it. :)
I'll submit a patch shortly. I'll also mention the underpaid comment to management and see what comes of that;)
Peter
participants (6)
-
Andy Fleming -
Jerry Van Baren -
Kim Phillips -
Peter Tyser -
Stefan Roese -
Wolfgang Denk