[U-Boot-Users] RE: [PATCH] ARM: Davinci: Fix DM644x timer overflow handling and cleanup

Pieter Voorthuijsen pieter.voorthuijsen at Prodrive.nl
Tue Mar 25 16:45:15 CET 2008


Hi Dirk, 

> -----Original Message-----
> From: Dirk Behme [mailto:dirk.behme at googlemail.com] 
> Sent: dinsdag 25 maart 2008 11:19
> To: Pieter Voorthuijsen
> Cc: u-boot-users at lists.sourceforge.net; troy.kisky at 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




More information about the U-Boot mailing list