From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhen Wang Date: Fri, 11 Nov 2005 14:18:20 +0800 Subject: [U-Boot-Users] TFTP times out? In-Reply-To: <518B77BB6246D54D9E88FC49AFB0389D2B1D34@seskoptronicmsx.optronic.local> References: <518B77BB6246D54D9E88FC49AFB0389D2B1D34@seskoptronicmsx.optronic.local> Message-ID: <437437AC.1080809@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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