我有一个带有 TI OMAP SoC 的定制板。我正在尝试通过 U-Boot 的 tftp 从 linux 机器下载 uImage。它在几个超时（大多数尝试超时限制超过并且很少通过）失败，但在其他人上成功。然而，任何其他不涉及 U-Boot 的组合都是完美的。即使有问题的主板已经启动内核。比较网络设置（包括 sysctl）在运行 Linux 的服务机器之间没有显着差异。
进行了以下测试：
- u-boot <-> i686-pae Linux
- u-boot <-> i686-pae Linux kvm guest
- u-boot <-> x86_64 windows 7
结果如下：
- u-boot <-> i686-pae Linux
使用 DaVinci-EMAC 设备
来自服务器 192.168.100.254 的 TFTP；我们的 IP 地址是 192.168.100.88
文件名“uImage”。
加载地址：0xc0700000
正在加载：############T ##############################T ### #######T ############
#######T ######################################### ######T ##########
#########################T ####################### ################
##########################T ##################### ################
###############################T ################# ################
################################################# ###############
########T ######################################## ################
##################
11.7 KB/秒
完毕
传输的字节数 = 2418464（24e720 十六进制）
相应的流量转储可以在这里找到：http: //pastebin.com/hBBwe9bL
- u-boot <-> i686-pae Linux kvm guest
使用 DaVinci-EMAC 设备
来自服务器 192.168.100.112 的 TFTP；我们的 IP 地址是 192.168.100.88
文件名“uImage”。
加载地址：0xc0700000
正在加载：################################################ #################
################################################# ###############
################################################# ###############
################################################# ###############
################################################# ###############
################################################# ###############
################################################# ###############
##################
795.9 KB/秒
完毕
传输的字节数 = 2418464（24e720 十六进制）
相应的流量转储可以在这里找到：http: //pastebin.com/ZXYdpmSe
- u-boot <-> x86_64 windows 7
使用 DaVinci-EMAC 设备
来自服务器 192.168.100.86 的 TFTP；我们的 IP 地址是 192.168.100.88
文件名“uImage”。
加载地址：0xc0700000
正在加载：################################################ #################
################################################# ###############
##################################
173.8 KB/秒
完毕
传输的字节数 = 2418464（24e720 十六进制）
相应的流量转储可以在这里找到：http: //pastebin.com/UWFEZjTz
在这一点上，我不知道是什么导致 u-boot 超时，我也没有更多关于如何解决这个问题的线索。非常感谢任何帮助。
它当然与 U-Boot 网络堆栈有关，但我相信这是提出这个问题的正确地方。
我已经阅读了这篇文章： http: //www.denx.de/wiki/view/DULG/TFTPTimeout，但是那里描述的内容与我的情况无关，因为结果不依赖于中间的开关。
我已经尝试过的：tftpd/ tftpd-hpa; tftpblocksize=512; x86_64 linux内核（tftp服务器）；将交换机端口设置更改为不是 aeg，而是显式full-双工；以及half-；添加/删除中间的开关；在发球机上更改 MTU；从源代码构建最新的 U-Boot；内变化的服务器IP地址/24；换sysctl网。内存设置；向 U-Boot 邮件列表发送消息，但没有得到回复；为 U-Boot MAC 制作静态 arp。
正如进一步的实验表明的那样，这种特殊情况下的问题是因为 u-boot 丢失传入的数据包与
--- NetLoop timeout handler setand巧合--- NetLoop timeout，我认为这是由 u-boot 中的 mac 驱动程序实现或 u-boot 网络处理本身引起的。由于快速的数据包处理，上游 Cisco 交换机的高 pps 可能会导致此问题。从 Windows 主机成功传输的事实证明，选择的 tftp 实现的超时时间少于 u-boot 的超时时间，因此再次重新发送数据包，而这些数据包恰好在其时间限制内被 u-boot 捕获。
测试还表明，
#define TIMEOUT 8000UL在编译时或tftptimeout 1000运行时设置允许 tftp 服务器有足够的时间重新传输丢失的数据包，从而继续传输。这正是从 Windows 主机下载所观察到的。更多的测试表明，将上游交换机端口（不是同一个端口，面向有问题的板的 u-boot）设置为 10 Mbit/s 半双工可以解决传输问题，但这会显着降低可用带宽。
问题：
董事会投注能力肯定比主机对手慢得多。那么 TFTP 客户端在发送 ACK N 后可能会立即收到 Data Packet N+1，而此时板子可能还无法接收数据包（即没有全双工）
丢失数据包后，双方进入“等待超时”模式。
要做的事情：
如果您仍然遇到问题，请尝试使用 Wireshark 捕获流量并分析超时流量序列