[U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

[U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

[Pieter Voorthuijsen]

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=ea686f52e4
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.

Is anybody else seeing this? Clearly when the timer is used by several
blocks, it cannot be easily divided by 16. I think we need something
else to work with the wrap around of the timer...

Best regards,
Pieter


Pieter Voorthuijsen
Prodrive B.V.
Science Park Eindhoven
P.O. box 28030
5602 JA Eindhoven
The Netherlands

Email pieter.voorthuijsen at prodrive.nl
Tel: +31-40-2676258
Fax: +31-40-2676201

[U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

[Dirk Behme]

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=ea686f52e4
> 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.
> 
> Is anybody else seeing this? Clearly when the timer is used by several
> blocks, it cannot be easily divided by 16. I think we need something
> else to work with the wrap around of the timer...

Thanks for the report!

Any idea what might be better?

Thanks

Dirk

[U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

[Pieter Voorthuijsen]

Hi Dirk,

If I understand correctly: When the timer wraps around, flash writes or
other long lasting actions get timed-out. 

Currently the timer is in 32 bit unchained mode, why not place it 64 bit
mode?

Best regards, Pieter

-----Original Message-----
From: Dirk Behme [mailto:dirk.behme at googlemail.com] 
Sent: donderdag 20 maart 2008 15:25
To: Pieter Voorthuijsen
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

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=ea686f52
> e4
> 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.
> 
> Is anybody else seeing this? Clearly when the timer is used by several

> blocks, it cannot be easily divided by 16. I think we need something 
> else to work with the wrap around of the timer...

Thanks for the report!

Any idea what might be better?

Thanks

Dirk

[U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

[Dirk Behme]

Pieter Voorthuijsen wrote:
> Hi Dirk,
> 
> If I understand correctly: When the timer wraps around, flash writes or
> other long lasting actions get timed-out. 

Yes. I never observed it myself. The inital report is

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/32563/match=patch+fix+timer+overflow+davinci

but the patch was rejected by Wolfgang.

I then tried to fix it with a better patch, but seems that I failed ;) 
Sorry for that.

> Currently the timer is in 32 bit unchained mode, why not place it 64 bit
> mode?

Good idea! I'm not so familiar with DaVinci timer, but sounds like an 
option. This will need some changes to davinci/timer.c to handle 64bit 
timer, but this shouldn't be to hard, right?

Do you like to send a patch?

Many thanks

Dirk

> -----Original Message-----
> From: Dirk Behme [mailto:dirk.behme at googlemail.com] 
> Sent: donderdag 20 maart 2008 15:25
> To: Pieter Voorthuijsen
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] DaVinci DM644x timer problem (divided by 16)
> 
> 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=ea686f52
>>e4
>>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.
>>
>>Is anybody else seeing this? Clearly when the timer is used by several
> 
> 
>>blocks, it cannot be easily divided by 16. I think we need something 
>>else to work with the wrap around of the timer...
> 
> 
> Thanks for the report!
> 
> Any idea what might be better?
> 
> Thanks
> 
> Dirk
> 

[U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

[Pieter Voorthuijsen]

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 at 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

[U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

[Wolfgang Denk]

In message <4CD35CD1F8085945B597F80EEC8942138A249B@exc01.bk.prodrive.nl> you wrote:
> 
> 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

Note that get_timer_masked() is an  ugly  artefact  of  some  earlier
U-Boot ports we should try to get rid of. It should not be needed nor
used.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Plan to throw one away.  You will anyway."
                              - Fred Brooks, "The Mythical Man Month"