diff options
author | Martin Roth <martin.roth@se-eng.com> | 2013-03-11 13:17:27 -0600 |
---|---|---|
committer | Stefan Reinauer <stefan.reinauer@coreboot.org> | 2013-04-01 20:52:31 +0200 |
commit | d2be1f11e11b68d88f9065ae75f32d7982cc3fe6 (patch) | |
tree | aa140b6663a227e3c6710b9048cbb1483c49d827 /src/southbridge/amd/sr5650 | |
parent | d0d7e7d7619e469dc936a579a6ce2adee9425ca6 (diff) |
AMD hudson & SB800 - Fix issues with mawk
When calculating the offsets of the various binary blobs within the
coreboot.rom file, we noticed that using mawk as the awk tool instead
of using gawk led to build issues. This was finally traced to the
maximum value of the unsigned long variables within mawk - 0x7fff_ffff.
Because we were doing calculations on values up in the 0xffxxxxxx
range, these numbers would either be turned into floating point values
and printed using scientific notation, or truncated at 0x7fff_ffff.
To fix this, we print the values out as floating point, with no decimal
digits. This works in gawk, mawk, and original-awk and as the testing
below show, seems to be the best way to do this.
printf %u 0xFFFFFFFF | awk '{printf("%.0f %u %d", $1 , $1 , $1 )}'
mawk: 4294967295 2147483647 2147483647
original-awk: 4294967295 2147483648 4294967295
gawk: 4294967295 4294967295 4294967295
The issue of %d not matching gawk and original-awk has been reported
to ubuntu.
In the future, I'd recommend that whenever awk is used, a format is
specified. It doesn't seem that we can count on the representation
being the same between the different versions.
Change-Id: I7b6b821c8ab13ad11f72e674ac726a98e8678710
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2628
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Diffstat (limited to 'src/southbridge/amd/sr5650')
0 files changed, 0 insertions, 0 deletions