[U-Boot] u-boot tftp problem

PF4Public
2015-02-18T15:33:48Z

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