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