[U-Boot] About the CRC of u-boot.bin
I found out that even with the same source code, the final u-boot.bin has a different MD5sum each time I build. Is that possible to get an identical u-boot.bin for the same source code, no matter when I build?
Dear Peter Pan,
In message BANLkTiknD3J66KeKHXDv8eRB7STQyGbnBQ@mail.gmail.com you wrote:
I found out that even with the same source code, the final u-boot.bin has a different MD5sum each time I build. Is that possible to get an identical u-boot.bin for the same source code, no matter when I build?
No, as the image contains a time stamp that changes each time you build a new image.
Best regards,
Wolfgang Denk
On Saturday, June 11, 2011 02:55:41 Wolfgang Denk wrote:
Peter Pan wrote:
I found out that even with the same source code, the final u-boot.bin has a different MD5sum each time I build. Is that possible to get an identical u-boot.bin for the same source code, no matter when I build?
No, as the image contains a time stamp that changes each time you build a new image.
i wonder if we should make this a config tweak. some people (not really myself) would like to be able to confirm the same result every time and the timestamp is an acceptable loss ... -mike
Our product is used in a safety-critical situation. We want to make sure that the product we released is exactly the one we tested in our labs. Because our product is released in a checkout-build-release process, it is impossible to just give out the binary file we tested.
Maybe there is a workaround to solve this problem.
2011/6/12 Mike Frysinger vapier@gentoo.org:
On Saturday, June 11, 2011 02:55:41 Wolfgang Denk wrote:
Peter Pan wrote:
I found out that even with the same source code, the final u-boot.bin has a different MD5sum each time I build. Is that possible to get an identical u-boot.bin for the same source code, no matter when I build?
No, as the image contains a time stamp that changes each time you build a new image.
i wonder if we should make this a config tweak. some people (not really myself) would like to be able to confirm the same result every time and the timestamp is an acceptable loss ... -mike
Dear Peter Pan,
In message BANLkTikd2r_g1WVrMe7_M7nD-xR3X-F7zg@mail.gmail.com you wrote:
Our product is used in a safety-critical situation. We want to make sure that the product we released is exactly the one we tested in our labs.
In this case you must make sure to ship exactly the same binary image that was used during testing. You must not test oneiomage, then rebuild and ship the new (untested) one.
Because our product is released in a checkout-build-release process, it is impossible to just give out the binary file we tested.
I cannot parse this.
Best regards,
Wolfgang Denk
Dear Peter Pan,
Am 13.06.2011 um 06:17 schrieb Peter Pan:
Our product is used in a safety-critical situation. We want to make sure that the product we released is exactly the one we tested in our labs.
Because our product is released in a checkout-build-release process, it is impossible to just give out the binary file we tested.
Why don't you just test the binary that was built for release?
2011/6/12 Mike Frysinger vapier@gentoo.org:
On Saturday, June 11, 2011 02:55:41 Wolfgang Denk wrote:
No, as the image contains a time stamp that changes each time you build a new image.
i wonder if we should make this a config tweak. some people (not really myself) would like to be able to confirm the same result every time and the timestamp is an acceptable loss ...
The build-timestamp is an quite usable parameter, if it is configurable it should be opt-out.
When I looked for the char *version_string I found out this is defined in respective architecture board.c. Shouldn't this be defined somewhere else to have always the same string?
regards
Andreas Bießmann
On Monday, June 13, 2011 04:11:57 Andreas Bießmann wrote:
The build-timestamp is an quite usable parameter, if it is configurable it should be opt-out.
goes without saying
When I looked for the char *version_string I found out this is defined in respective architecture board.c. Shouldn't this be defined somewhere else to have always the same string?
feel free to submit a patch. there is a lot of logic in arch/*/lib/board.c that should be unified.
also, please fix your e-mail client to properly wrap long lines -mike
u-boot-bounces@lists.denx.de wrote:
Our product is used in a safety-critical situation. We want to make sure that the product we released is exactly the one we tested in our labs. Because our product is released in a checkout-build-release process, it is impossible to just give out the binary file we tested.
I am pretty sure I saw some patches for Linux within the last couple of months that make this a config option for the kernel for the same kind of reasons. Maybe good for inspiration.
Sorry, but I can't remember exactly when, or if they got into mainline.
Seems like a good option to have, though.
-- Jon Povey jon.povey@racelogic.co.uk
Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network
OK, I will try to find that Linux patch and see how it goes.
And, first of all, I will suggest my manager to change the checkout-build-release process. I also agree that just release the binary we tested is a much better way.
Thank you guys.
2011/6/13 Jon Povey Jon.Povey@racelogic.co.uk:
u-boot-bounces@lists.denx.de wrote:
Our product is used in a safety-critical situation. We want to make sure that the product we released is exactly the one we tested in our labs. Because our product is released in a checkout-build-release process, it is impossible to just give out the binary file we tested.
I am pretty sure I saw some patches for Linux within the last couple of months that make this a config option for the kernel for the same kind of reasons. Maybe good for inspiration.
Sorry, but I can't remember exactly when, or if they got into mainline.
Seems like a good option to have, though.
-- Jon Povey jon.povey@racelogic.co.uk
Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network
participants (5)
-
Andreas Bießmann -
Jon Povey -
Mike Frysinger -
Peter Pan -
Wolfgang Denk