I just had a look at other ARM implementations of timer.c.
Some have a colourful mix of 32 and 64 bits values, resulting in some 64 bit timer functions returning the upper 32 bits always cleared.
Some implement udelay() in the "while (xxxtime() < endtime);" variant.
I will fix this for at91 and submit a patch.
I also see that:
void reset_timer(void) { gd->timer_reset_value = get_ticks(); }
ulong get_timer(ulong base) { return tick_to_time(get_ticks() - gd->timer_reset_value) - base; }
If implemented with true 64 bits for get_ticks() that function is useable for timeout programming:
ulong timeval = get_timer (0);
do { ... } while (get_timer (timeval) < TIMEOUT);
It appears that the "base" parameter and return value is in CONFIG_SYS_HZ units, and not in native ticks. That causes 64 bit mul/div every time get_timer() is called. Won't hurt in a timeout loop, though.
I guess the theoretically unnecessary function reset_timer() might have been invented to mask the issue of 32 bit wraparounds when get_timer() is not truly 64 bits???
Reinhard