[U-Boot] [RFC PATCH] lib/timer: initialize timebase_l/timebase_h

[Andre Przywara]

On systems using the generic timer routines defined in lib/time.c we
use timebase_l and timebase_h fields from the gd to detect wraparounds
in our tick counter. The tick calculcation algorithm silently assumes
that a long is only 32 bits, which leads to wrong results when timebase_h
is not 0 on 64-bit systems.
As one possible fix lets initialize timebase_h (and timebase_l) to 0, so
on 64-bit systems timebase_h will never(TM) be bigger than 0 and thus
cannot spoil timebase_l by being ORed into it.

This fixes occasional timeout issues on the Pine64 (and possibly other
ARM64 systems).

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
Hi,

I am bit puzzled what the proper fix is, this one is the easiest I could
come up with. Not sure if the gd should be zeroed normally (and it's just
broken on sunxi/arm64 because of some linker issues) or whether we really
forgot to initialize those fields and just got away with it.
Other fixes I tried are implementing get_ticks() in armv8/generic_timer.c
or fixing the generic get_ticks() implementation by using
"#if BITS_PER_LONG < 64" in the function to shortcut the code on 64-bit
systems.
Please have your say on what's best.

Cheers,
Andre.

P.S. "Never" above seems to be 195 years assuming a worst-case 3GHz
arch timer.

 lib/time.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/time.c b/lib/time.c
index f37150f..b77d134 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -109,6 +109,8 @@ static uint64_t notrace tick_to_time(uint64_t tick)
 
 int __weak timer_init(void)
 {
+	gd->timebase_l = 0;
+	gd->timebase_h = 0;
 	return 0;
 }
 
-- 
2.8.2