Hi Dirk,
-----Original Message----- From: Dirk Behme [mailto:dirk.behme@googlemail.com] Sent: dinsdag 25 maart 2008 11:19 To: Pieter Voorthuijsen Cc: u-boot-users@lists.sourceforge.net; troy.kisky@boundarydevices.com Subject: Re: [PATCH] ARM: Davinci: Fix DM644x timer overflow handling and cleanup
Pieter Voorthuijsen wrote:
Hi Dirk, Troy,
Still some troubles on the DVEVM, i2c and flash are too
fast, also dhcp is racing like h#ll. See log below.
Currently the timer rolls over every 1 ms, this means
get_timer should be called at least every ms to detect a roll over... Is it better to have a static variable timer than read the timer register directly?
I see that this is standard behavior in other timer code in
u-boot, but we don't need it I think. I'll try to implement the 64-bit timer without roll over this afternoon.
I don't love the idea of 64-bit timer! We *should* get it working with 32bit timer. Do you like spending the time to implement the 64-bit timer instead in thinking/debugging the 32-bit timer?
Ok, let's fix the 32-bit first...
E.g. what happens if you use
#define TIMER_LOAD_VAL 0xffffffff
instead in patch below?
This has the same behavior a the previous one... I also saw that you did not divide the return value from get_timer, tried that too.
In the meanwhile I found that the previous patch to timer.c was quiet ok, but was missing the following in the udelay function:
--- a/cpu/arm926ejs/davinci/timer.c 2008-03-25 09:44:30.000000000 +0100 +++ b/cpu/arm926ejs/davinci/timer.c 2008-03-25 16:13:05.000000000 +0100 @@ -141,6 +141,7 @@ tmo = CFG_HZ_CLOCK / 1000; tmo *= usec; tmo /= 1000; + tmo /= 16;
endtime = get_timer_raw() + tmo;
This explains why flash etc operations went OK, but operation requiring udelay failed...
Shall we combine this with the patch you made? Or do we leave thing as they were and insert the diff above?
Best regards, Pieter