0

I have a custom board with TI OMAP SoC. I'm trying to download uImage from linux machine via U-Boot's tftp. It fails with timeouts (most of the tries timeout limit exceeds and very rarely it gets through) 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

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

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

It certainly has something to do with U-Boot network stack, but I believe this is the right place to ask this question.

I have read this article: http://www.denx.de/wiki/view/DULG/TFTPTimeout, however what is described there is not related to my situation since results do not depend on switches in-between.

What I have tried already: tftpd / tftpd-hpa; tftpblocksize=512; x86_64 linux kernel (tftp server); changing switch port settings to not aneg, but explicit full-duplex; as well as half-; adding/removing switches in-between; changing MTU at the serving machine; building latest U-Boot from source; varying server IP-address within /24; changing sysctl net. mem settings; sent a message to U-Boot mailing list, but got no reply; made static arp for U-Boot MAC.

0

As further experiments showed, the problem in this particular case was because of u-boot losing incoming packets coincidentally with --- NetLoop timeout handler set and --- NetLoop timeout, which I suppose is caused by either mac driver implementation in u-boot or u-boot networking handling itself. High pps of upstream Cisco switch might contribute to this because of rapid packet processing.

Successful transfers from Windows host are manifested by the fact that chosen tftp implementation has timeouts less than those of u-boot and as a consequence resending packets again, which happen to be captured by u-boot within its time limits.

Tests also show that setting #define TIMEOUT 8000UL at compile time or tftptimeout 1000 at run time allow for enough time for tftp server to retransmit lost packet allowing transmission to proceed. This is exactly what's observed with downloading from Windows host.

More testing showed that setting upstream switch port (not the same port, facing u-boot with the board in question) to 10 Mbit/s half-duplex solves transmission issue, however this significantly reduces the bandwidth available.

-1

The problem:

  1. The board betwork capabilities sure are way slower than the host counterpart. Then the TFTP client after sending ACK N might immediately receive Data Packet N+1 when the board probably is not able to receive the packet yet (i.e. no full duplex)

  2. After the missed packet both parties enter in a "waiting for timeout" mode.

Things to do:

  1. Try your test on a very light network or even better a back-to-back connection
  2. If your link is 1Gb/100Mb try slower if possible.
  3. Try setting lower timeouts on the "server side"; this will force the server to wait less time before to resend the missed packet probably avoiding the client timeout.
  4. If you have a TFTP Server able to control the "inter packet delay" make it higher.

If you still in trouble try capturing traffic with Wireshark and analyze the timeout traffic sequence

  • Sorry, but point 1 in your answer is wrong as I mentioned no problems with networking when the board in question runs Linux kernel rather than u-boot. Quote: "However any other combination not involving U-Boot is flawless. Even when the board in question has booted kernel." – PF4Public May 28 '16 at 17:20
  • Since you insist I'd like to clarify this a little bit in more detail. Your assumption of "board betwork capabilities sure are way slower" is in contradiction with the fact that Linux kernel is fine with network capabilities of the board as it is clear from the question itself, as well as this assumption does not account for successful transfers from Windows host. With regard of "the board probably is not able to receive the packet yet" I must say that this does not hold true since board has enough capabilities for processing network packets as I've already mentioned, – PF4Public May 29 '16 at 18:55
  • 1
    As per "(i.e. no full duplex)" it is also clear from the question itself, that I've tried different settings to no avail, so this assumption is also wrong. In the end your answer does not provide any clue on why transfers from Windows host succeed. Now that I've made my point clear, care to elaborate on your downvote and provide some proofs for your satatements, namely: "you have no idea what you are talking about" and ""my" answer is in fact right" – PF4Public May 29 '16 at 18:55
  • How is your statement Linux network driver and the u-boot network driver are completely different related to Your assumption of "board betwork capabilities sure are way slower" is in contradiction? – PF4Public Jun 8 '16 at 12:06
  • When your board is driven by U-boot its network driver has a very poor performance, if you manage to run the "same" hardware under Linux its network driver will show a much higher performance. That's why when a bootloader/manager drives the NIC timing issues are very common. – Pat Jun 8 '16 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.