![使用 U-Boot 的 tftp 下载随机超时](https://linux22.com/image/652259/%E4%BD%BF%E7%94%A8%20U-Boot%20%E7%9A%84%20tftp%20%E4%B8%8B%E8%BD%BD%E9%9A%8F%E6%9C%BA%E8%B6%85%E6%97%B6.png)
我有一块带有 TI OMAP SoC 的定制主板。我正尝试通过 U-Boot 的 tftp 从 Linux 机器下载 uImage。几次尝试都因超时而失败(大多数尝试都超过超时限制,很少能成功),但其他几次都成功了。但是,任何其他不涉及 U-Boot 的组合都是完美的。即使有问题的主板已经启动了内核。比较网络设置(包括 sysctl),在运行 Linux 的服务机器之间没有发现明显差异。
进行了以下测试:
- u-boot <-> i686-pae Linux
- u-boot <-> i686-pae Linux kvm 客户机
- 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 KiB/秒 完毕 传输的字节数 = 2418464(24e720 十六进制)
相应的流量转储可以在这里找到: http://pastebin.com/hBBwe9bL
- u-boot <-> i686-pae Linux kvm 客户机
使用 DaVinci-EMAC 设备 来自服务器 192.168.100.112 的 TFTP;我们的 IP 地址是 192.168.100.88 文件名“uImage”。 加载地址:0xc0700000 加载中: ################################################################# ######################################################################### ######################################################################### ######################################################################### ######################################################################### ######################################################################### ######################################################################### ################## 795.9 KiB/秒 完毕 传输的字节数 = 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 KiB/秒 完毕 传输的字节数 = 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 服务器);将交换机端口设置更改为非 aneg,而是显式full-
双工;以及half-
;在其间添加/删除交换机;更改服务机器上的 MTU;从源代码构建最新的 U-Boot;在其中改变服务器 IP 地址/24
;更改sysctl
net.mem 设置;向 U-Boot 邮件列表发送了一条消息,但没有收到回复;为 U-Boot MAC 制作了静态 arp。
答案1
进一步的实验表明,此特定案例中的问题是由于 u-boot 在 和 时同时丢失了传入数据包--- NetLoop timeout handler set
,--- 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 半双工解决了传输问题,但是这显著降低了可用的带宽。
答案2
问题:
主板的传输能力肯定比主机慢得多。然后,TFTP 客户端在发送 ACK N 后可能会立即收到数据包 N+1,而主板可能还无法接收数据包(即非全双工)
丢失数据包后,双方都进入“等待超时”模式。
要做的事情:
- 在非常轻的网络或更好的背靠背连接上尝试测试
- 如果您的链接是 1Gb/100Mb,请尽可能尝试较慢的速度。
- 尝试在“服务器端”设置较低的超时时间;这将迫使服务器等待更短的时间才重新发送丢失的数据包,从而可能避免客户端超时。
- 如果您有一个能够控制“数据包间延迟”的 TFTP 服务器,请将其调高。
如果仍然有问题,请尝试使用 Wireshark 捕获流量并分析超时流量序列