[U-Boot] u-boot tftp problem
Hi all
I'm asking for your help to figure out what interferes with u-boot's tftp in my setup. I have a custom board with TI OMAP SoC. I'm trying to download uImage from linux machine via tftp. It fails with timeouts (most of the tries timeout limit exceeds) on several, but succeeds on others. However any other combination not involving u-boot is flawless. Even when the board in question has booted kernel. Comparing network settings (incl. sysctl) gave no significant difference between serving machines, which run Linux. Following tests were taken: u-boot <-> i686-pae Linux u-boot <-> i686-pae Linux kvm guest u-boot <-> x86_64 windows 7 Results are as follows:
1. u-boot <-> i686-pae Linux Using DaVinci-EMAC device TFTP from server 192.168.100.254; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc0700000 Loading: ############T ###############################T ##########T ############ #######T ################################################T ########## ##########################T ####################################### ###########################T ###################################### ################################T ################################# ################################################################# ########T ######################################################### ################## 11.7 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/hBBwe9bL
2. u-boot <-> i686-pae Linux kvm guest Using DaVinci-EMAC device TFTP from server 192.168.100.112; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc0700000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################## 795.9 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/ZXYdpmSe
3. u-boot <-> x86_64 windows 7 Using DaVinci-EMAC device TFTP from server 192.168.100.86; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc0700000 Loading: ################################################################# ################################################################# ################################### 173.8 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/UWFEZjTz
At this point I have no idea, what could cause timeouts for u-boot and I have no more clues on how to solve this. Any help greatly appreciated.
Thanks in advance Best regards
On Fri, Feb 13, 2015 at 8:05 PM, PF4Public PF4Public@mail.ru wrote:
Hi all
I'm asking for your help to figure out what interferes with u-boot's tftp
in my setup.
I have a custom board with TI OMAP SoC. I'm trying to download uImage
from linux machine via tftp. It fails with timeouts (most of the tries timeout limit exceeds) on several, but succeeds on others. However any other combination not involving u-boot is flawless. Even when the board in question has booted kernel. Comparing network settings (incl. sysctl) gave no significant difference between serving machines, which run Linux.
Are you saying that it is completely consistent that when TFTPing from a specific TFTP server to u-boot you always get these time-outs, but with a different one you never get them? Have you compared the traffic on the wire? Try turning on debug traces in the network stack and compare what it sees to what's on the wire. Perhaps the davinci emac driver is causing you trouble. Is there a cache enabled on your board that you could disable to eliminate the driver's tolerance of a cache?
Following tests were taken: u-boot <-> i686-pae Linux u-boot <-> i686-pae Linux kvm guest u-boot <-> x86_64 windows 7 Results are as follows:
- u-boot <-> i686-pae Linux
Using DaVinci-EMAC device TFTP from server 192.168.100.254; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc0700000 Loading: ############T ###############################T ##########T
############
#######T ################################################T
##########
##########################T
#######################################
###########################T
######################################
################################T
#################################
################################################################# ########T
#########################################################
################## 11.7 KiB/sdone Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/hBBwe9bL
- u-boot <-> i686-pae Linux kvm guest
Using DaVinci-EMAC device TFTP from server 192.168.100.112; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc0700000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################## 795.9 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/ZXYdpmSe
- u-boot <-> x86_64 windows 7
Using DaVinci-EMAC device TFTP from server 192.168.100.86; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc0700000 Loading: ################################################################# ################################################################# ################################### 173.8 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/UWFEZjTz
At this point I have no idea, what could cause timeouts for u-boot and I
have no more clues on how to solve this. Any help greatly appreciated.
Simply that the packet that the network stack expects has not be received at that level. They could be lost in a number of places.
Thanks in advance Best regards _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Are you saying that it is completely consistent that when TFTPing from a specific TFTP
server to u-boot you always get these time-outs, but with a different one you never get them? Exactly. Even when I try to download uImage from kvm host machine, I still got timeouts. But should I try to download from kvm guest, which obviously uses the same switch port as does host, I got fast download. A little slower, but still without timeouts, tftp gets uImage from MS Windows 7 host, which runs http://tftpd32.jounin.net/ .That was the first I could google up for Windows.
Have you compared the traffic on the wire?
Careful examination of dumps leads me to the following conclusions: 1. Download session with timeouts had a lot of retransmissions. Having those dumps made on server side, I'm not certain if U-Boot really received lost packets, but what is clear is that tftpd sends some packets twice before receiving acknowledgement packet from U-Boot. 2. Even though Windows server uses block sizes 1500, still those packets are perfectly delivered to U-Boot. 3. Sometimes something really weird happens, like this: 00:00:00.000061 IP (tos 0x0, ttl 64, id 34608, offset 0, flags [DF], proto UDP (17), length 544)
192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 423
00:00:00.000417 IP (tos 0x0, ttl 255, id 11691, offset 0, flags [DF], proto UDP (17), length 32)
192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 423
00:00:00.000056 IP (tos 0x0, ttl 64, id 34609, offset 0, flags [DF], proto UDP (17), length 544)
192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 424
00:00:05.000165 IP (tos 0x0, ttl 255, id 11692, offset 0, flags [DF], proto UDP (17), length 32)
192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 423
00:00:00.000014 IP (tos 0x0, ttl 64, id 34720, offset 0, flags [DF], proto UDP (17), length 544)
192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 424
00:00:00.000015 IP (tos 0x0, ttl 64, id 34721, offset 0, flags [DF], proto UDP (17), length 544)
192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 424
00:00:00.000521 IP (tos 0x0, ttl 255, id 11693, offset 0, flags [DF], proto UDP (17), length 32)
192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 424
That is tftpd sends block 423 and receives acknowledgement. Then it sends block 424, but the reply was delayed for 5 seconds and was in fact for block 423 again. This happened quite often with timing variations: 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 526 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 526 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 527 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 527 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 526 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 527 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 527 ... 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 1558 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 1558 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 1559 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 1559 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 1558 192.168.100.254.56334 > 192.168.100.88.3821: 516 DATA block 1559 192.168.100.88.3821 > 192.168.100.254.56334: 4 ACK block 1559
Try turning on debug traces in the network stack and compare what it sees to what's on
the wire. I'll give it a try, thanks. Is "#define DEBUG_NET_PKT 0" related here, which I found in include/net.h ?
Perhaps the davinci emac driver is causing you trouble. Is there a cache enabled on your
board that you could disable to eliminate the driver's tolerance of a cache? You mean "CONFIG_SYS_ICACHE_OFF" and "CONFIG_SYS_DCACHE_OFF". I'll try them. I've googled something like "dcache off" command, but it didn't work for me in U-Boot command line, so suppose I should disable them via defines. Am I right?
Simply that the packet that the network stack expects has not be received at that level.
They could be lost in a number of places. But how come they are lost so selectively? I mean that somehow packets from Windows and other Linux hosts got delivered just fine.
Best regards.
Hi,
Here's what I think happens:
When working with large TFTP packets (probably 4096 bytes, as set in your board config file), U-Boot TFTP code sends wrong acknowledges for the TFTP packets. If the TFTP server implementation is too strict (the OpenBSD server is a good example), the transfer will inevitably fail very soon after start. Here's an example:
1. TFTP server sends block 0 2. Board acknowledges block 0 3. TFTP server sends block 1 4. Board acknowledges block 0
At this point you can see either proper or very obscure error messages in the TFTP server logs, so trust only to network dumps for diagnostics.
What can you do to resolve your issue:
1. Fix the bug in U-Boot tftp networking code and submit a patch. 2. Reduce your TFTP blksize, by commenting CONFIG_TFTPBLOCKSIZE in your board config. The default value is 1468, which should work fine. U-Boot behaves nicer with smaller packets.
Hope this helps. Regards, Nikolay
participants (3)
-
Joe Hershberger -
Nikolay Dimitrov -
PF4Public