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.