i.MX6开发板U-Boot下以太网ping失败：ARP重试超限问题求助

从你提供的信息来看，mii info已经显示PHY成功协商为100baseT全双工，说明物理链路是正常的，Ping失败且ARP重试超时的问题大概率出在网络参数配置、ARP交互或者设备MAC相关的环节上。下面是一步步的排查和解决建议：

• 先确认网络参数的合理性
  执行printenv命令检查你设置的所有网络变量：

  • 确保ipaddr和serverip处于同一网段，比如ipaddr=192.168.1.10、serverip=192.168.1.20，同时netmask要匹配（比如255.255.255.0）。如果是跨网段Ping，才需要正确设置gatewayip，同网段Ping可以暂时去掉gatewayip测试。
  • 检查ethaddr是否合法且唯一，避免和网络内其他设备的MAC地址冲突。设置后可以用printenv ethaddr确认是否生效。

• 验证物理连接的稳定性
  虽然MII显示协商成功，但还是可以做这些验证：

  • 更换一根已知正常的网线，或者切换到交换机的其他端口测试，排除网线/端口故障。
  • 检查交换机是否有MAC地址绑定、VLAN隔离等限制，确保你设置的ethaddr没有被交换机拦截。

• 手动干预ARP交互
  ARP重试超时说明U-Boot无法获取目标IP的MAC地址，可以试试这些操作：

  • 执行reset eth（或部分版本的fec_reset）重新初始化以太网设备，然后再尝试Ping。
  • 如果你的U-Boot版本支持，执行arp ping <serverip>手动触发ARP请求，观察是否有响应。
  • 手动绑定静态ARP条目：先获取目标服务器的MAC地址，然后执行setenv arpentry <serverip>:<server_mac>，比如setenv arpentry 192.168.1.20:aa:bb:cc:dd:ee:ff，之后再执行ping <serverip>测试。

• 调整U-Boot以太网相关配置
  有些情况下U-Boot的默认配置可能导致ARP重试问题：

  • 尝试增加ARP重试次数，执行setenv arp_retry 10（不同U-Boot版本变量名可能不同，比如部分版本是arp_retries），然后保存环境变量saveenv后重启测试。
  • 确认ethprime变量是否设置为FEC（执行printenv ethprime），确保U-Boot默认使用的是正确的以太网设备。

如果以上步骤都无法解决，你可以提供printenv的完整输出、目标服务器的网络配置，以及mii dump 0 1的结果（查看PHY状态寄存器的详细信息），这样能进一步定位问题。

内容的提问来源于stack exchange，提问作者md.jamal