[U-Boot] u-boot tftp problem

[PF4Public]

 >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.