[U-Boot-Users] TFTP times out?

[Zhen Wang <mailtojarod@gmail.com>]

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