[U-Boot-Users] TFTP times out?

[U-Boot-Users] TFTP times out?

[Zhen Wang]

Hi wd,
   Yeah, I've read relevant topics in DULG and then revised my 
configuration header file as following:

#define CONFIG_ETHADDR			00:50:c2:1e:af:fb
#define CONFIG_NETMASK			255.255.255.0
#define CONFIG_IPADDR			192.168.123.100
#define CONFIG_SERVERIP			192.168.123.115
#define CONFIG_BOOTFILE			"zImage"
#define CONFIG_BOOTCOMMAND		"tftpboot\; go 0c480000"
#define CFG_LOAD_ADDR			0x0c480000

   I'm running Fedora Core 4 on my PC. I've got the tftp-server rpm 
installed, iptables turned off, tftp service enabled and xinetd 
restarted, zImage copied under the /tftpboot/ directory. But after 5 sec 
boot delay the TFTP seemed to time out like this:

TFTP from server 192.168.123.115; out IP is 192.168.123.100
Filename: 'zImage'
Load address: 0xc480000
Loading: T T # # T # T T (omitted)
Retry count exceeded; starting again

Then I interrupted the command and tried to ping my PC:

jx44b0>ping 192.168.123.115
host 192.168.123.115 is alive

I think the network condition is OK, but the TFTP always times out. I 
want to configure a longer timeout value for TFTP but don't know where. 
Waiting for your reply. Thanks a lot.

Best regards,
Zhen Wang

[U-Boot-Users] TFTP times out?

[Sam Song]

Zhen Wang <mailtojarod@gmail.com> wrote:
> I think the network condition is OK, but the TFTP
> always times out. I 

Try to see if use a direct net line. Perhaps it' the
busy load on local network made it.

Regards,

Sam


	

	
		
___________________________________________________________ 
????G??????????????????? 
http://cn.mail.yahoo.com

[U-Boot-Users] TFTP times out?

[Zhen Wang]

Sam Song wrote:
> Zhen Wang <mailtojarod@gmail.com> wrote:
> 
>>I think the network condition is OK, but the TFTP
>>always times out. I 
> 
> 
> Try to see if use a direct net line. Perhaps it' the
> busy load on local network made it.
> 
> Regards,
> 
> Sam
> 
> 
But the board is connected to my PC directly through a twisted cable.

[U-Boot-Users] TFTP times out?

[Bharathi Subramanian]

On Thu, 10 Nov 2005, Zhen Wang wrote:

> >> I think the network condition is OK, but the TFTP always times
> >> out.

> But the board is connected to my PC directly through a twisted cable.

1. Then TFTP is not properly configured OR not running. 
2. Restart the xinetd and try (if it is GNU/Linux Env)
3. Try tftp from another PC, if that works, then try from the board. 

Bye :)
-- 
Bharathi S

[U-Boot-Users] TFTP times out?

[Zhen Wang]

Bharathi Subramanian Wrote:
> On Thu, 10 Nov 2005, Zhen Wang wrote:
> 
> 
>>>>I think the network condition is OK, but the TFTP always times
>>>>out.
> 
> 
>>But the board is connected to my PC directly through a twisted cable.
> 
> 
> 1. Then TFTP is not properly configured OR not running. 
> 2. Restart the xinetd and try (if it is GNU/Linux Env)
> 3. Try tftp from another PC, if that works, then try from the board. 
> 
> Bye :)
   I did check out my tftp server configurations carefully after
read your reply.
1. I am running Fedora Core 4 on my PC and installed
tftp-server-0.40-6.i386.rpm. I did check out it by typing 'rpm -q
tftp-server'.
2. I turned on tftp service and turned off iptables service, and
configured no firewall.
3. I restarted xinetd successfully by typing 'service xinted restart'.
4. After typing 'netstat -a|grep tftp' I could see the output 'udp 0 0
*:tftp *:*'.
5. The /tftpboot directory's permission was 'drwxr-xr-x'.
6. I could tftp zImage successfully from another PC running Win XP over 
the Ethernet but still timed out from my board.
   In a word, I think I should revise the tftpboot relevant codes to 
prolong the time before time out. But I don't the exact file(location).

Best regards,
Zhen Wang

[U-Boot-Users] TFTP times out?

[Wolfgang Denk]

In message <4372E4BF.8020401@gmail.com> you wrote:
>
>    In a word, I think I should revise the tftpboot relevant codes to 
> prolong the time before time out. But I don't the exact file(location).

No. This will NOT solve the problem.

Run a network sniffer to find  out  if  U-Boot  is  actually  sending
packets,  and  the  TFTP server fails to reply, or if U-Boot does not
send any packets at all.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
365 Days of drinking Lo-Cal beer.                       = 1 Lite-year

[U-Boot-Users] TFTP times out?

[Eckart Goehler]

Hi,

Zhen Wang wrote:
> 
> Hi wd,
>   Yeah, I've read relevant topics in DULG and then revised my 
> configuration header file as following:
> 
> #define CONFIG_ETHADDR            00:50:c2:1e:af:fb
> #define CONFIG_NETMASK            255.255.255.0
> #define CONFIG_IPADDR            192.168.123.100
> #define CONFIG_SERVERIP            192.168.123.115
> #define CONFIG_BOOTFILE            "zImage"
> #define CONFIG_BOOTCOMMAND        "tftpboot\; go 0c480000"
> #define CFG_LOAD_ADDR            0x0c480000
> 
>   I'm running Fedora Core 4 on my PC. I've got the tftp-server rpm 
> installed, iptables turned off, tftp service enabled and xinetd 
> restarted, zImage copied under the /tftpboot/ directory. But after 5 sec 
> boot delay the TFTP seemed to time out like this:
> 
> TFTP from server 192.168.123.115; out IP is 192.168.123.100
> Filename: 'zImage'
> Load address: 0xc480000
> Loading: T T # # T # T T (omitted)
> Retry count exceeded; starting again
> 
> Then I interrupted the command and tried to ping my PC:
> 
> jx44b0>ping 192.168.123.115
> host 192.168.123.115 is alive

That looks rather like a server problem (possibly firewall). You should 
try to run tftp from either the server itself, or - better - from a 
separate computer. Actually I faced same problems on a RedHat machine
till xinietd was set up properly.

regards

eckart


> 
> I think the network condition is OK, but the TFTP always times out. I 
> want to configure a longer timeout value for TFTP but don't know where. 
> Waiting for your reply. Thanks a lot.
> 
> Best regards,
> Zhen Wang

[U-Boot-Users] TFTP times out?

[André Berggren]

Hi!

We have the same problem with one minor difference. U-boot get the first part of a file and then starts getting timeouts (TTTT).
We used a Etheral to sniff and found out that u-boot ack one datapackage but when the next datapackage araives u-boot doesn?t seem to hear it. Instead u-boot timesout listening and sends another ack on the previous datapackage. The tftp server then retransmits the last datapackage again witch u-boot doesn?t hear, u-boot times out and send another ack on the previous datapackage, and we are stuck in this loop.
We use a Moxa ED6008 switch where we attached the sniffer for the recording.

See appended ethereal capture-file. Mark one UDP-package and use Analyse->decode as and chose tftp to make it more readable.

//Andr?


-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net on behalf of Wolfgang Denk
Sent: Thu 11/10/2005 9:42 AM
To: Zhen Wang
Cc: Bharathi Subramanian; u-boot-users at lists.sourceforge.net
Subject: Re: Re : [U-Boot-Users] TFTP times out? 
 
In message <4372E4BF.8020401@gmail.com> you wrote:
>
>    In a word, I think I should revise the tftpboot relevant codes to 
> prolong the time before time out. But I don't the exact file(location).

No. This will NOT solve the problem.

Run a network sniffer to find  out  if  U-Boot  is  actually  sending
packets,  and  the  TFTP server fails to reply, or if U-Boot does not
send any packets at all.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
365 Days of drinking Lo-Cal beer.                       = 1 Lite-year


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.f-secure.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tftp.cap
Type: application/octet-stream
Size: 5706 bytes
Desc: tftp.cap
Url : http://lists.denx.de/pipermail/u-boot/attachments/20051110/6587d0f7/attachment.obj 

[U-Boot-Users] TFTP times out?

[Jerry Van Baren]

A: What really annoys Wolfgang?
Q: HTML (and I bet you thought I was going to say top posting ;-).

</humor>

"but when the next datapackage araives u-boot doesn?t seem to hear it"

I'm thinking the above quote is almost correct.  "Doesn't process it" is 
probably the correct statement.  It sounds like your u-boot build has 
problems receiving ethernet packets after a while.  This could be many 
things, but is almost undoubtedly a software problem and increasing 
timeouts won't fix it, it will just ACK previous packets longer.

I would check packet handling.  My first suspicion is that your receive 
packet handling isn't handling the packet queue properly.  An example of 
this would be if two packets are received but you only handle one of 
them and never go on to the next - as long as you only receive one 
packet per poll, you are OK, but if you receive two you get stuck.

gvb

Andr? Berggren wrote:
> Hi!
> 
> We have the same problem with one minor difference. U-boot get the
> first part of a file and then starts getting timeouts (TTTT).
> We used a Etheral to sniff and found out that u-boot ack one
> datapackage but when the next datapackage araives u-boot doesn?t seem
> to hear it. Instead u-boot timesout listening and sends another ack
> on the previous datapackage. The tftp server then retransmits the
> last datapackage again witch u-boot doesn?t hear, u-boot times out
> and send another ack on the previous datapackage, and we are stuck in
> this loop.
> We use a Moxa ED6008 switch where we attached the sniffer for the
recording.
> 
> See appended ethereal capture-file. Mark one UDP-package and use
> Analyse->decode as and chose tftp to make it more readable.
> 
> //Andr?
> 
> 
> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net on behalf of Wolfgang Denk
> Sent: Thu 11/10/2005 9:42 AM
> To: Zhen Wang
> Cc: Bharathi Subramanian; u-boot-users at lists.sourceforge.net
> Subject: Re: Re : [U-Boot-Users] TFTP times out? 
>  
> In message <4372E4BF.8020401@gmail.com> you wrote:
> 
>>   In a word, I think I should revise the tftpboot relevant codes to 
>>prolong the time before time out. But I don't the exact file(location).
> 
> 
> No. This will NOT solve the problem.
> 
> Run a network sniffer to find  out  if  U-Boot  is  actually  sending
> packets,  and  the  TFTP server fails to reply, or if U-Boot does not
> send any packets at all.
> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot-Users] TFTP times out?

[NZG]

In developing the Coldfire 5282 port we use for our SoM-5282EM, I had a very 
similar problem.
It took  awhile to track down, but turned out to me an imperfect timer 
implementation.
The timer is used to generate required network delays and timeouts, and if it 
is not implemented properly, you will see just this.
That is, short network transaction will work fine, but long ones, my crash and 
continually restart.

I would do some investigation into your timer, 
The first step would be to make sure sleep works correctly.

NZG.



On Thursday 10 November 2005 7:40 am, Jerry Van Baren wrote:
> A: What really annoys Wolfgang?
> Q: HTML (and I bet you thought I was going to say top posting ;-).
>
> </humor>
>
> "but when the next datapackage araives u-boot doesn?t seem to hear it"
>
> I'm thinking the above quote is almost correct.  "Doesn't process it" is
> probably the correct statement.  It sounds like your u-boot build has
> problems receiving ethernet packets after a while.  This could be many
> things, but is almost undoubtedly a software problem and increasing
> timeouts won't fix it, it will just ACK previous packets longer.
>
> I would check packet handling.  My first suspicion is that your receive
> packet handling isn't handling the packet queue properly.  An example of
> this would be if two packets are received but you only handle one of
> them and never go on to the next - as long as you only receive one
> packet per poll, you are OK, but if you receive two you get stuck.
>
> gvb
>
> Andr? Berggren wrote:
> > Hi!
> >
> > We have the same problem with one minor difference. U-boot get the
> > first part of a file and then starts getting timeouts (TTTT).
> > We used a Etheral to sniff and found out that u-boot ack one
> > datapackage but when the next datapackage araives u-boot doesn?t seem
> > to hear it. Instead u-boot timesout listening and sends another ack
> > on the previous datapackage. The tftp server then retransmits the
> > last datapackage again witch u-boot doesn?t hear, u-boot times out
> > and send another ack on the previous datapackage, and we are stuck in
> > this loop.
> > We use a Moxa ED6008 switch where we attached the sniffer for the
>
> recording.
>
> > See appended ethereal capture-file. Mark one UDP-package and use
> > Analyse->decode as and chose tftp to make it more readable.
> >
> > //Andr?
> >
> >
> > -----Original Message-----
> > From: u-boot-users-admin at lists.sourceforge.net on behalf of Wolfgang Denk
> > Sent: Thu 11/10/2005 9:42 AM
> > To: Zhen Wang
> > Cc: Bharathi Subramanian; u-boot-users at lists.sourceforge.net
> > Subject: Re: Re : [U-Boot-Users] TFTP times out?
> >
> > In message <4372E4BF.8020401@gmail.com> you wrote:
> >>   In a word, I think I should revise the tftpboot relevant codes to
> >>prolong the time before time out. But I don't the exact file(location).
> >
> > No. This will NOT solve the problem.
> >
> > Run a network sniffer to find  out  if  U-Boot  is  actually  sending
> > packets,  and  the  TFTP server fails to reply, or if U-Boot does not
> > send any packets at all.
> >
> > Best regards,
> >
> > Wolfgang Denk
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] TFTP times out?

[Zhen Wang]

Andr? Berggren Wrote:
> Hi!
> 
> We have the same problem with one minor difference. U-boot get the first part of a file and then starts getting timeouts (TTTT).
> We used a Etheral to sniff and found out that u-boot ack one datapackage but when the next datapackage araives u-boot doesn?t seem to hear it. Instead u-boot timesout listening and sends another ack on the previous datapackage. The tftp server then retransmits the last datapackage again witch u-boot doesn?t hear, u-boot times out and send another ack on the previous datapackage, and we are stuck in this loop.
> We use a Moxa ED6008 switch where we attached the sniffer for the recording.
> 
> See appended ethereal capture-file. Mark one UDP-package and use Analyse->decode as and chose tftp to make it more readable.
> 
> //Andr?
> 
> 
   Thanks a lot! I've downloaded Ethereal v0.10.13 and learned to use it 
last night. In order to find some problems I built u-boot with several 
  different configurations and then I sniffed TFTP traffic between my 
board and PC utilizing Ethereal. Then I could figure a table as following:

filename           CFG_HZ  TIMEOUT  TIMEOUT_COUNT        block #
------------------------------------------------------------------------
u-boot-tftp0.bin   1000       5(s)        10                231
u-boot-tftp2.bin   1000      100(s)      270               4179
u-boot-tftp3.bin   1000      100(s)      400               4260
u-boot-tftp4.bin   1000       5(s)       400               4260

   CFG_HZ is a configuration _SETTING_ in my board's configuration 
header file(I don't know its exact function till now). TIMEOUT and 
TIMEOUT_COUNT both are constants defined in net/tftp.c.
   I've got a 2130KB(i.e. 4260 TFTP packages) uClinux zImage to download 
over the twisted cable which connected my board with my PC directly.
   The numbers in last column of above table indicate the last TFTP 
block id received from the TFTP server(PC) before giving up(i.e. retry 
count beyonds TIMEOUT_COUNT). Therefore 4260 indicates a complete download.
   According to the table, TIMEOUT doesn't seem to be a critical part in 
unsuccessful downloads. Though I can use a large TIMEOUT_COUNT to 
accomplish the download, it's a bad solution. Now my first suspicion is 
that the timing without interrupts scheme implemented in 
cpu/s3c44b0/interrupts.c.

Best regards,
Zhen Wang

[U-Boot-Users] TFTP times out?

[Martin Krause]

Hie Zhen,

Zhen Wang wrote on Friday, November 11, 2005 7:18 AM: 
>    CFG_HZ is a configuration _SETTING_ in my board's configuration
> header file(I don't know its exact function till now). TIMEOUT and

CFG_HZ defines the number of timer ticks per second. The function
get_timer() returns the current vaule of the internal timer tick 
counter (with the variable name: 'timestamp'). The following code
snippet should delay for exat one second:

	...
	tmo = get_timer(0) + 1 * CFG_HZ;
	while (get_timer(0) < tmo);


> TIMEOUT_COUNT both are constants defined in net/tftp.c.
>    I've got a 2130KB(i.e. 4260 TFTP packages) uClinux zImage to
> download 
> over the twisted cable which connected my board with my PC directly.
>    The numbers in last column of above table indicate the last TFTP
> block id received from the TFTP server(PC) before giving up(i.e. retry
> count beyonds TIMEOUT_COUNT). Therefore 4260 indicates a complete
>    download. According to the table, TIMEOUT doesn't seem to be a
> critical part in 
> unsuccessful downloads. Though I can use a large TIMEOUT_COUNT to
> accomplish the download, it's a bad solution. Now my first suspicion
> is 
> that the timing without interrupts scheme implemented in
> cpu/s3c44b0/interrupts.c.

There actually seems to be a bug. CFG_HZ is set to 1000 on your board.
This means in one second the counter returned by get_timer() should
increase by 1000. But this doesn't correspond to the implementation
of udelay() on your board (from cpu/s3c44b0/interrupts.c):

void udelay (unsigned long usec)
{
	ulong tmo;

	tmo = usec / 1000;
	tmo *= CFG_HZ;
	tmo /= 8;

	tmo += get_timer (0);

	while (get_timer_masked () < tmo)
		/*NOP*/;
}

This assumes that the internal counter increases by 8 in one second.
Since CFG_HZ should be 1000 (according to Wolfgang Denk) I suggest
to fix the TIMER_LOAD_VAL on your board, so that one underrun
of timer TCNT01 accours every 1 ms.


Regards,
Martin

[U-Boot-Users] TFTP times out?

[Wolfgang Denk]

In message <47F3F98010FF784EBEE6526EAAB078D1C05E8D@tq-mailsrv.tq-net.de> you wrote:
> 
> CFG_HZ defines the number of timer ticks per second. The function
> get_timer() returns the current vaule of the internal timer tick 
> counter (with the variable name: 'timestamp'). The following code
> snippet should delay for exat one second:
> 
> 	...
> 	tmo = get_timer(0) + 1 * CFG_HZ;
> 	while (get_timer(0) < tmo);

Warning. This code will NOT work when there is a wrap-around.

> There actually seems to be a bug. CFG_HZ is set to 1000 on your board.

This setting is the correct value. It was a mistake of mine  to  name
this CFG_* and give users the idea this could be changed.

> This means in one second the counter returned by get_timer() should
> increase by 1000. But this doesn't correspond to the implementation
> of udelay() on your board (from cpu/s3c44b0/interrupts.c):
> 
> void udelay (unsigned long usec)
> {
> 	ulong tmo;
> 
> 	tmo = usec / 1000;
> 	tmo *= CFG_HZ;
> 	tmo /= 8;
> 
> 	tmo += get_timer (0);
> 
> 	while (get_timer_masked () < tmo)
> 		/*NOP*/;
> }

Indeed. This implementetion is seriously broken.

It  will  also  result  in  totally  unexpected  delays  in  case  of
wrap-around  (there  are more broken implementations like this in the
existing U-Boot code; maintainers should take care).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Without followers, evil cannot spread.
	-- Spock, "And The Children Shall Lead", stardate 5029.5