summaryrefslogtreecommitdiff
path: root/src/arch/arm/libgcc
diff options
context:
space:
mode:
authorRob Barnes <robbarnes@google.com>2022-06-24 10:28:31 -0600
committerMartin L Roth <gaumless@gmail.com>2022-08-13 17:20:11 +0000
commitb11f9f7e162759cf5ae0f033e125e9158520030d (patch)
tree6c53aac2b789995fc6ea1af186f53274402310a4 /src/arch/arm/libgcc
parent175445b4bbb16b8eedc2f6bd1b3ec37cb1095bf1 (diff)
timer: Switch mono_time to uint64_t
A 32-bit long storing microseconds will rollover every ~1.19 hours. This can cause stopwatch to misbehave, causing unexpected failures. If the current field in stopwatch is near 2^31, the expires field may rollover when initialized. If this occurs, stopwatch_expired() will instantly return true. If current and expires fields are near 2^31, the current field could rollover before being checked. In this case, stopwatch_expired() will not return true for over an hour. Also stopwatch_duration_usecs() will return a large negative duration. This issue has only been observed in SMM since it never takes more than 35 minutes to boot. Switching to uint64_t mitigates this issue since it will not rollover for over 500K+ years. The raw TSC would rollover sooner than this, ~200 years, depending on the tick frequency. BUG=b:237082996 BRANCH=All TEST=Boot Nipperkin Change-Id: I4c24894718f093ac7cd1e434410bc64e6436869a Signed-off-by: Rob Barnes <robbarnes@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65403 Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Martin L Roth <gaumless@gmail.com>
Diffstat (limited to 'src/arch/arm/libgcc')
0 files changed, 0 insertions, 0 deletions