From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Wozniak <awozniak@mc.com>
Date: Tue, 29 Mar 2005 18:17:45 -0500
Subject: [U-Boot-Users] OCOTEA get_timer() bug
In-Reply-To: <200503290826.01044.sr@denx.de>
References: <20050328195851.A1730C108D@atlas.denx.de> <200503290826.01044.sr@denx.de>
Message-ID: <4249E219.7000507@mc.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hello,

My only concern with the fix is that it will break something else that
assumes the timer interval to be 10msec.  There are a few "files" that
depend on it for timeout operations:

cpu/ppc4xx/440gx_enet.c
          if ((time_now - time_start) > 3000)   <--- 30 sec timo?

net/bootp.c
	bp->bp_secs = htons(get_timer(0) / CFG_HZ);
	...
         BootpID += get_timer(0);

net/tftp.c
	TftpOurPort = 1024 + (get_timer(0) % 3072);

net/net.c
post/rtc.c
tools/updater/flash_hw.c

-Andrew

Stefan Roese wrote:
> On Monday 28 March 2005 21:58, Wolfgang Denk wrote:
> 
> 
>>>I've tested the following and propose it as a fix, replace this:
>>>   val = gd->bd->bi_intfreq/100;	 /* 10 msec */
>>>with:
>>>   val = gd->bd->bi_intfreq/1000; /* 1 msec */
>>>
>>>I've also tested some of the network related functions to insure that no
>>>timeout conditions have appeared.
>>>
>>>I want to post this patch but would prefer a code review from those that
>>>are more familiar with get_timer() use within the OCOTEA codebase.
>>
>>I don't know why the 440 is handled separately.
>>
>>Stefan, do you have an idea?
> 
> 
> No. The 440 port was done by Scott McNutt <smcnutt@artsyncp.com>, if I 
> remember right. But it seems that the fix is correct. Scott (or any other 440 
> users), any comments on this?
> 
> Best regards,
> Stefan
>