Hi Dirk,
My thoughs on /cpu/arm926ejs/davinci/timer.c:
/* * Timer runs with CFG_HZ_CLOCK, currently 27MHz. To avoid wrap * around of timestamp already after min ~159s, divide it, e.g. by 16. * timestamp will then wrap around all min ~42min */
That's true, if the period of the timer is set to 0xffffffff, but:
#define TIMER_LOAD_VAL (CFG_HZ_CLOCK / CFG_HZ) timer->prd34 = TIMER_LOAD_VAL;
The period of the timer is set to 1 ms, it counts to TIMER_LOAD_VAL and resets to 0. So I thinks something else goes wrong.
In my idea these functions should do the following (with CFG_HZ=1000):
get_timer(ulong base) - Return time in ms minus base get_timer_masked(void) - Return time in ms
When we have our 64-bit timer, we don't need to do any wrapping or overflow handling, get_timer_masked can just return "Hardware timer / (CFG_HZ_CLOCK / CFG_HZ)" and be happy for 21664,5 years.
For info about the timer itself: http://focus.ti.com/lit/ug/sprue26/sprue26.pdf
Best Regards, Pieter
-----Original Message----- From: Dirk Behme [mailto:dirk.behme@googlemail.com] Sent: vrijdag 21 maart 2008 12:34 Cc: Pieter Voorthuijsen Subject: Re: [U-Boot-Users] DaVinci DM644x timer problem (divided by 16)
Dirk Behme wrote:
Pieter Voorthuijsen wrote:
Hello,
Some months ago, a patch was submitted ([ARM] fix timer overflow in DaVinci). The result was that in /cpu/arm926ejs/davinci/timer.c read_timer was divided by 16. http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=ea686f5 2e4 5b3df2938866d3f5a98bb2556dfe2b
Right now, when I have my bootdelay variable (on a DVEVM) set to 2, and countdown takes 32 seconds... Also iprobe got very very very
slow.
Maybe more items are affected by this timer division.
Haven't looked into the code, but just an idea: Why does the system think it had to wait 32 seconds instead of 2 if timer is devided by 16? Most probably cause anything tells him "x count values of counter are 1 second" or similiar? Maybe we simply have to adjust this "reference" by 16 as well? E.g. if now this reference is e.g. "32000 timer count values are one second", then we have now to configure (32000/16) = 2000 counter values are 1 second. I.e. for 2 seconds wait 4000 count values and not 64000?
What do you think?
Dirk