这块板子前两天还在正常跑今天在 Uboot 里敲下ping 192.168.1.100回显却是ping failed; host 192.168.1.100 is not alive。更让人头大的是同一根网线插到笔记本上能通插到 PC 上也大概率能通一换成 VMware 或者 VirtualBox 里的虚拟机Uboot 就装死。Uboot ping 不通 PC 机或虚拟机本质上不是一句“网络不通”能概括的它横跨 MAC、PHY、设备树、时钟、环境变量、防火墙、虚拟网卡桥接模式这几层。只要中间任意一层掉链子现象都长得很像。下面我按实际排障顺序把这套问题拆开讲清楚适合正在移植 Uboot、调 RK3568、IMX6ULL、FMQL 千兆网或者刚装完虚拟机准备联调板子的人参考。1. 先搞清楚 Uboot 里的 ping 到底在干什么1.1 Uboot 网络协议栈比 Linux 小很多别用 Linux 经验硬套Uboot 下的网络功能一直是个“够用就行”的状态。它没有 Linux 那么完整的网络栈也没有 systemd、NetworkManager、netplan 这些帮你兜底的东西。Uboot 里通常只有最基础的以太网驱动、ARP、ICMP、TFTP、DHCP 等少量协议。ping命令能跑起来说明编译时已经打开了CONFIG_CMD_PING、CONFIG_CMD_NET、CONFIG_NET之类的选项并且当前有可用的网络设备。但“命令存在”不等于“链路可用”更不等于“对端会回你”。在 Uboot 里执行ping大致会走这么几步先确认当前选中的网口然后检查 PHY 链路是否 up接着发 ARP 请求询问目标 IP 的 MAC 地址收到 ARP 回复后再发 ICMP Echo Request最后等 ICMP Echo Reply。很多人的板子卡在第一步或者第二步也就是 PHY 链路根本没起来。也有人能打印出 link up但 ARP 永远收不到回复。还有人 ARP 通了ICMP 被对端防火墙吞掉于是 Uboot 只会告诉你目标不 alive。Uboot 的网络设备命名和 Linux 不一样。你可能会看到eth0、eth1也可能看到gmac0、fec0。哪个口是当前活动口可以用bdinfo、printenv、ethact之类的环境变量确认。有些板子默认ethact指向了错误网口比如你插的是千兆口它却拿另一个没接网线的口去 ping结果自然失败。遇到多网口板子先用ethact切到正确设备或者用setenv ethact gmac0再试。提示Uboot 下不要指望ifconfig、ip addr、ethtool这些 Linux 命令。大多数 Uboot 只支持ping、tftp、dhcp、mii、mdio、setenv、printenv。先确认命令集再谈排查。1.2 ping 成功的最小必要条件一条链上不能有断点Uboot ping 通 PC 或虚拟机最少要同时满足这些条件。板子 MAC 控制器已经初始化PHY 已经上电、复位完成、地址识别正确MAC 和 PHY 之间的接口模式与时钟方向匹配PHY 和对端网卡完成自协商链路状态为 up。Uboot 侧ipaddr与对端 IP 在同一网段netmask没写错ethaddr不是全 0 或全 F。对端网卡处于同一广播域中间没有路由器隔断ARP 能广播到。对端系统允许 ICMP Echo Request 入站或者至少没有把 ARP 和 ICMP 全部拦掉。如果用了虚拟机还要虚拟机网络模式允许板子的广播包进入虚拟机。只要其中一个条件不成立ping就会失败。问题在于 Uboot 报错信息非常贫乏。它不会告诉你“PHY 没起来”也不会告诉你“ARP 没收到回复”。它只会给一个统一失败结果。因此排查时必须自己把链路切开一段一段确认。我的习惯是先看 PHY 链路再看 ARP最后看 ICMP。顺序不要乱否则很容易在应用层瞎改浪费一整天。1.3 为什么 PC 能通虚拟机却经常不通PC 能通、虚拟机不通这个现象太常见了。原因通常不在 Uboot而在虚拟机的网络模式。虚拟机默认常用 NAT 模式。NAT 模式下虚拟机躲在主机后面外面设备不能直接访问虚拟机的私有 IP。Uboot 发的 ARP 广播到不了虚拟机虚拟机也不知道板子的 IP 对应哪个 MAC。你可能会想“那我用端口转发”但 ICMP 不是 TCP/UDP端口转发通常不适用于普通 ping很多虚拟化工具也不给你转 ICMP。另一种常见情况是虚拟机用了“仅主机模式”。这个模式只让主机和虚拟机通信板子不在这个虚拟网络里。除非你把板子网线接到主机某个物理网卡并且把这个物理网卡也桥进仅主机网络否则 Uboot 永远 ping 不到虚拟机。还有一种是桥接模式选错了物理网卡。主机有 WiFi 和有线网卡虚拟机自动桥接到了 WiFi而板子插在有线网卡上。两个网络不在同一广播域当然不通。虚拟机网络适配器本身也可能有问题。Windows 里 VMware 的 VMnet1 或 VMnet8 出现感叹号虚拟网卡驱动没装好或者网卡被禁用都会导致虚拟机没有可用网络。Ubuntu 虚拟机里ip addr只有lo那就别急着怪 Uboot。先让虚拟机自己拿到同网段 IP能 ping 通主机再让 Uboot 来 ping 它。这个顺序很重要。2. 硬件链路与设备树多数故障在这里2.1 接口模式与时钟方向RGMII、RMII 不是随便填的MAC 和 PHY 之间的接口模式是 Uboot 网络不通的高频原因。RK3568、IMX6ULL、FMQL 这些平台常见 RGMII、RMII、MII。模式不对轻则百兆能通千兆不通重则完全没链路。RGMII 又分rgmii、rgmii-id、rgmii-txid、rgmii-rxid。这些后缀决定延迟加在 MAC 侧还是 PHY 侧。很多原理图里 PHY 默认不加内部延迟设备树就必须写rgmii-id让 MAC 补延迟。如果写成了普通rgmii链路可能显示 up但 ARP 丢包ping 不通。时钟方向也要注意。RGMII 的 TXC 和 RXC 由谁提供PHY 还是 MAC必须和硬件设计一致。有些板子 PHY 输出 125MHz 时钟给 MAC有些是 MAC 输出。设备树里的assigned-clock、clock-names、tx_delay、rx_delay都可能影响。IMX6ULL 的 FEC 控制器经常用phy-mode rmii但 RMII 还需要 50MHz 参考时钟。如果时钟源没使能PHY 可能被识别但数据发不出去。RK3568 的 GMAC 节点里常见phy-mode rgmii-id同时还要配snps,reset-gpio、snps,reset-active-low、snps,reset-delays-us。这些复位参数不对PHY 上电后可能没被正确复位。你会在mdio list里看不到 PHY或者看到地址但寄存器读出来全是0xffff。FMQL 千兆网不通时也要优先看这些接口模式、延迟、复位、时钟而不是一上来就改驱动。2.2 PHY 地址、复位、供电和 MDIO 扫描PHY 地址由硬件 strapping 电阻决定一般是 0 到 31。设备树里reg 0表示 PHY 地址 0。如果硬件实际是地址 1设备树写 0Uboot 就找不到 PHY。表现是mdio list没有输出或者网络设备初始化失败。你可以用mdio list扫描总线看能不能列出 PHY。能列出地址后再读 PHY ID 寄存器确认是不是你原理图上的那颗 PHY。PHY 复位也很关键。有些板子复位 GPIO 极性写反上电后 PHY 一直处于复位状态。有些复位延时太短PHY 还没准备好MAC 就开始访问。还有些板子 PHY 供电由 GPIO 控制Uboot 没打开这个电源PHY 根本没工作。这类问题在自制板、核心板加底板、飞线调试时特别多。不要只看“网口灯亮不亮”有些 PHY 在 link 没起来时灯就是不亮而有些 PHY 默认常亮不能作为唯一依据。MDIO 读写是排查利器。不同 Uboot 命令不同常见有mii、mdio。比如mdio list mdio read 0 0 mdio read 0 1 mdio read 0 2 mdio read 0 30x00是 BMCR0x01是 BMSR0x02和0x03是 PHY ID。如果读出来是0xffff通常是 MDIO 通信失败、PHY 没供电、复位没释放、地址不对。如果 PHY ID 正常再看 BMSR 的 link 状态位。链路没起来时先查网线、对端网卡、自协商不要直接改 IP。2.3 千兆不通、百兆能通延迟线、IO 电压和走线一起看“百兆能 ping千兆不行”是非常典型的 RGMII 问题。百兆时 RGMII 用 25MHz 时钟千兆用 125MHz。频率一高延迟、走线、IO 电压、参考时钟的问题就暴露出来。常见原因有设备树没加内部延迟PCB 走线长度不匹配PHY 的 IO 电压和 MAC 不匹配RGMII 的 TX/RX 延迟配置错误。你可以先强制百兆验证链路再逐步定位千兆。Uboot 里有些 PHY 驱动支持mii命令写寄存器但不要乱写先确认 PHY 手册里的寄存器定义。RK3568 这类平台在千兆模式下rgmii-id往往是必须的。IMX6ULL 如果跑 RMII本身只有百兆不要拿千兆 PHY 的预期去套。FMQL 板子如果千兆不通也要看 PHY 是不是支持 RGMII 延迟或者 MAC 侧有没有延迟配置。还有一点网线质量也会影响千兆。劣质网线百兆能通千兆自协商直接降到百兆或者失败。换一根六类线往往能排除很多“玄学”。注意不要看到“百兆能通”就认为硬件没问题。千兆对时钟和数据窗口更敏感很多板子就是百兆正常、千兆丢包。先确认协商结果再看延迟配置。3. Uboot 配置、环境变量与驱动排查3.1 环境变量最容易犯的错IP、掩码、ethaddr、ethactUboot 环境变量里和 ping 最相关的是ipaddr、serverip、netmask、gatewayip、ethaddr、ethact。ipaddr是板子自己的 IPserverip是你要 ping 的目标 IP。很多人只改了ipaddr忘记改serverip结果 ping 的还是编译时的默认地址。还有人把netmask写成255.255.255.255导致板子认为目标不在同一网段ARP 请求发不出去。同网段 ping 时gatewayip通常不参与但设错也不会直接导致失败除非协议栈实现比较特殊。ethaddr也要注意。Uboot 里 MAC 地址如果全 0 或者全 F有些交换机、虚拟网卡会直接丢弃。你可以在printenv ethaddr里确认必要时setenv ethaddr 02:00:00:12:34:56。这个地址只要局域网内不冲突即可。多网口板子还要看ethact。比如 RK3568 有两个 GMAC你插的是 GMAC1但ethact是 GMAC0。Uboot 会拿 GMAC0 去 ping而 GMAC0 可能没接 PHY 或者没插网线。切过去再试printenv ethact setenv ethact gmac1 ping 192.168.1.100环境变量改完记得saveenv否则重启就丢。但调试阶段别急着保存先确认当前生效值。3.2 DTS、pinctrl、时钟、CONFIG 检查清单Uboot 设备树和 Linux 设备树可能不是同一份。很多人改的是 Linux DTSUboot 用的却是另一份 DTS或者 Uboot 根本没使能对应节点。排查时先确认 Uboot 当前使用的 DTS再看 MAC 节点状态是不是okay。检查pinctrl有没有配 RGMII 引脚clocks和clock-names有没有使能PHY 节点有没有被正确引用。RK3568 的 GMAC 节点里常见phy-handle、phy-mode、snps,reset-gpioIMX6ULL 的 FEC 节点里常见phy-mode、phy-handle、fsl,magic-packet。Uboot 配置也要看。CONFIG_CMD_NET、CONFIG_CMD_PING、CONFIG_CMD_MII、CONFIG_CMD_MDIO是否打开。对应 MAC 驱动有没有编译进去比如CONFIG_ETH_DESIGNWARE、CONFIG_FEC_MXC、CONFIG_GMAC_ROCKCHIP。PHY 驱动有没有打开比如CONFIG_PHY_REALTEK、CONFIG_PHY_MOTORCOMM、CONFIG_PHY_ATHEROS。如果 PHY 驱动没开Uboot 可能只能读 ID不能自动配置自协商。还有CONFIG_NET_RANDOM_ETHADDR这类选项会影响 MAC 地址生成。检查项常见问题验证方式DTS 节点节点 status 为 disabled看 Uboot 启动日志、fdt printpinctrl引脚复用没配查寄存器、示波器看波形时钟参考时钟没使能看时钟树、PHY 是否工作MAC 驱动没编译进 Ubootbdinfo、看网络设备PHY 驱动PHY 不识别mdio list、读 PHY ID命令配置没有 ping 命令help ping3.3 MDIO 寄存器与 ARP 观测别只盯 IP排查到中途建议把 PHY 寄存器和 ARP 抓包结合起来看。PHY 侧先看 BMSR 的 link 位和自协商完成位。如果 link 没起来后面都没意义。链路 up 后看 Uboot 发 ping 时对端有没有收到 ARP。可以在 PC 或 Linux 虚拟机上抓包sudo tcpdump -i any -n -e arp or icmp如果只看到板子的 ARP 请求没有回复说明广播包到了对端但对端没回或者回复没到板子。这时查对端 IP 是否同网段、防火墙是否拦 ARP、虚拟机是否桥接正确。如果连 ARP 请求都看不到说明包根本没从对端网卡出来问题在物理层、交换机、虚拟网卡或者板子 MAC。如果看到 ARP 回复也看到 ICMP 请求但没有 ICMP 回复重点查防火墙。如果看到 ICMP 回复但 Uboot 还说失败那可能是 Uboot 驱动收包有问题或者校验和、缓冲区配置有毛病。Uboot 侧可以打开调试宏比如CONFIG_NET_DEBUG、CONFIG_ETH_DEBUG不同版本名字不一样。打开后能看到发送和接收计数。不要在生产版本里长期打开调试完关掉。3.4 回显含义分段判断host is not alive 不等于全盘没救Uboot ping 失败常见回显有几种。ping failed; host 192.168.1.100 is not alive是最常见的表示发出了请求但没等到有效回复。ARP Retry count exceeded; starting again表示 ARP 阶段就失败了。No ethernet found表示 Uboot 根本没识别到网络设备。Could not initialize PHY表示 PHY 初始化失败。Link down或No link表示链路没起来。不同版本措辞有差异但大致能分成三类设备没起来、ARP 不通、ICMP 不通。设备没起来查驱动、DTS、PHY、时钟。ARP 不通查同网段、交换机、虚拟网络模式、防火墙对 ARP 的处理。ICMP 不通查防火墙、对端是否禁止 ping、虚拟化网络是否允许 ICMP。把回显和抓包结合基本能定位到层。最怕的是只知道“不通”不知道卡在哪一步。4. PC 和虚拟机侧防火墙、桥接模式和虚拟网卡4.1 VMware、VirtualBox 网络模式怎么选桥接最省事虚拟机网络模式主要有桥接、NAT、仅主机。Uboot 要 ping 虚拟机优先选桥接模式。桥接模式下虚拟机像局域网里一台独立机器和板子在同一广播域ARP 能通ICMP 也能通。NAT 模式下虚拟机在主机后面外部设备不能直接访问Uboot 很难 ping 到。仅主机模式下只有主机和虚拟机通信板子如果不在这个虚拟网络里也不通。VMware 里可以在“虚拟网络编辑器”里看 VMnet0 桥接到了哪张物理网卡。如果你主机同时有 WiFi 和有线网卡VMnet0 自动桥接可能选了 WiFi。板子插在有线网卡上虚拟机却在 WiFi 网段肯定不通。手动把桥接指定到板子实际连接的那张有线网卡。VirtualBox 里对应“桥接网卡”设置也要选对物理网卡。WiFi 桥接有时对广播包支持不好能用有线就用有线。模式板子能否直接 ping 虚拟机适用场景注意点桥接通常可以板子联调、TFTP、NFS必须桥接到正确物理网卡NAT通常不可以虚拟机上网ICMP 不能靠端口转发解决仅主机通常不可以主机与虚拟机内部通信板子不在该虚拟网络4.2 Windows 和 Linux 防火墙ICMP 入站经常被默认拦Windows 默认防火墙会拦 ICMP Echo Request。你在 PC 上能 ping 通别人不代表别人能 ping 通你。Uboot ping PC 时PC 必须允许入站 ICMPv4 Echo Request。可以在“高级安全 Windows Defender 防火墙”里新建入站规则选择“自定义”协议选 ICMPv4类型选“回显请求”允许连接。也可以临时关闭防火墙测试但测试完记得恢复。域网络、专用网络、公用网络三个配置文件都要放行尤其是虚拟机桥接后可能被识别为“公用网络”。Linux 虚拟机也要看防火墙。Ubuntu 默认 ufw 可能是关闭的但有些镜像会开。CentOS、Fedora 的 firewalld 默认可能拦 ICMP。可以临时放行sudo iptables -I INPUT -p icmp --icmp-type echo-request -j ACCEPTfirewalld 可以sudo firewall-cmd --permanent --add-rich-rulerule protocol valueicmp accept sudo firewall-cmd --reload还要确认内核没有全局忽略 ICMPcat /proc/sys/net/ipv4/icmp_echo_ignore_all如果是 1可以临时改为 0sudo sysctl -w net.ipv4.icmp_echo_ignore_all0注意关闭防火墙只是定位手段不是最终方案。定位完要按需放行 ICMP不要把系统裸奔当成常态。4.3 虚拟机没有网络适配器、VMnet1 感叹号、桥接失败怎么办Windows 下 VMware 的虚拟网卡经常出问题。设备管理器里 VMnet1 有感叹号通常是虚拟网卡驱动没装好或者版本不匹配。可以尝试在 VMware 安装程序里修复安装或者用管理员权限运行“虚拟网络编辑器”恢复默认设置。VMware 17 有时在 Windows 上会出现虚拟机没有配置和打开选项或者网络适配器缺失。先确认 VMware 服务是否启动比如 NAT 服务、DHCP 服务、桥接服务。VirtualBox 则要确认增强功能不是必需的但桥接驱动要装好。虚拟机里ip addr只有lo说明网卡没被识别。先看虚拟机设置里网络适配器是否勾选“已连接”和“启动时连接”。有些虚拟机克隆后 MAC 地址冲突也会导致网络异常。可以重新生成 MAC 地址。Linux 虚拟机里如果是 NetworkManager 管理检查nmcli device status看网卡是不是unmanaged。如果是unmanaged可能是配置文件问题需要把网卡交给 NetworkManager。主机访问虚拟机网站、虚拟机 ping 不通网关这些和 Uboot ping 虚拟机是不同层次的问题但排障思路一样先确认虚拟机能上网、能 ping 通主机、能 ping 通同网段其他设备再让板子加入这个网络。不要一上来就让 Uboot 去 ping 一个自己网络都没配好的虚拟机。4.4 用 tcpdump 和 Wireshark 确认包到底出没出去抓包是解决“到底谁没回”的最快方法。在 Linux 虚拟机里sudo tcpdump -i any -n -e arp or icmp在 Windows PC 上可以用 Wireshark过滤器写arp || icmp。先看板子发出的 ARP 请求里源 IP 是不是你设置的ipaddr目标 IP 是不是虚拟机的 IP。如果源 IP 是 0.0.0.0说明 Uboot 网络参数没生效。如果目标 IP 不对说明serverip设错。如果 ARP 请求到了虚拟机虚拟机也回了 ARP但 Uboot 没收到问题可能在虚拟机网卡、桥接、交换机。如果 ARP 正常ICMP 请求也到了但没回复问题在防火墙或 ICMP 设置。抓包时要注意接口。虚拟机可能有多个网卡tcpdump -i any最省事。Windows 上选对虚拟网卡或物理网卡。如果只抓物理网卡桥接的包可能看不到如果只抓虚拟网卡外部包可能看不到。先ipconfig或ip addr确认接口再抓。5. 实战排查流程半小时定位 ping 不通5.1 第一阶段物理层与 PHY 链路检查先把 Uboot 网络设备、PHY、链路状态确认一遍。启动板子进 Uboot执行bdinfo看有没有 eth 设备。用printenv看ipaddr、serverip、netmask、ethact。用mdio list看 PHY 是否被扫描到。读 PHY 的 BMSR确认 link 和自协商。如果 PHY 都找不到不要继续查 IP直接查硬件、DTS、时钟、复位。如果 PHY 找到了但 link down换网线、换对端网口、检查对端是否 up。如果 link up 但百兆/千兆不对查 RGMII 延迟和接口模式。这一阶段的目标是让 Uboot 知道“网线插着、PHY 活着、链路 up”。没有这个基础后面所有操作都是白费。5.2 第二阶段ARP 与 ICMP 链路验证链路 up 后设置正确的 IPsetenv ipaddr 192.168.1.10 setenv serverip 192.168.1.100 setenv netmask 255.255.255.0 setenv gatewayip 192.168.1.1 ping 192.168.1.100同时在对端开抓包。如果看到 ARP 请求没有 ARP 回复检查对端 IP 是否同网段、是否允许 ARP、虚拟机是否桥接。如果看到 ARP 回复没有 ICMP 请求说明 Uboot 收到 ARP 后没发 ICMP可能是驱动收包问题。如果看到 ICMP 请求没有 ICMP 回复检查防火墙和 ICMP 设置。如果看到 ICMP 回复Uboot 仍然失败可能是 Uboot 驱动收包异常或者校验和、DMA 描述符问题。5.3 第三阶段交叉替换与对照实验定位到可疑环节后用替换法验证。换一根网线换一个交换机换一台 PC换一张 USB 网卡。PC 能通、虚拟机不通优先改虚拟机桥接模式。虚拟机桥接 WiFi 不通换有线网卡桥接。Uboot 百兆能通、千兆不通强制百兆或改 RGMII 延迟。A 板子能通、B 板子不通对比设备树和 PHY 寄存器。不要同时改多个变量一次只动一个否则你不知道是哪个改动生效。5.4 常见问题速查表现象可能原因快速验证处理方向No ethernet found驱动没编、DTS 没使能bdinfo查 CONFIG、DTSmdio list 为空PHY 地址错、供电、复位读 PHY ID查硬件、复位 GPIOPHY ID 为 0xffffMDIO 不通、PHY 没工作示波器看 MDC/MDIO查时钟、供电、引脚Link down网线、对端、自协商换线换口确认对端 up百兆通千兆不通RGMII 延迟、走线、IO 电压强制百兆改 phy-mode、delayARP 请求无回复不同网段、虚拟机 NAT抓包改桥接、改 IPARP 通 ICMP 不通防火墙拦 ICMP抓包看回复放行 ICMPICMP 回复 Uboot 仍失败驱动收包、DMA看 Uboot 调试查驱动、描述符虚拟机只有 lo网卡没启用、驱动缺失ip addr修虚拟机网卡VMnet1 感叹号虚拟网卡驱动异常设备管理器修复安装 VMware6. 几个容易忽略的坑与个人经验6.1 Uboot 的 ping 不解析域名别拿 www.baidu.com 去试Uboot 里的ping通常只接受 IP 地址不解析域名。你敲ping www.baidu.com它要么报未知命令要么把域名当非法参数。热词里有人遇到ping: www.baidu.com: Name or service not known那是 Linux 的 DNS 问题不是 Uboot 的问题。Uboot 阶段一般还没有 DNS 客户端也不需要访问外网。调试板子时用局域网 IP别用域名。要传文件就用 TFTP 服务器 IP要联调就用 PC 或虚拟机 IP。6.2 自协商、双工、交叉线老设备和新网卡会互相别扭有些老 PHY 和新千兆网卡自协商会出问题。现象是链路 up但丢包严重或者只能百兆。可以尝试在 PC 侧强制百兆全双工或者在 Uboot 侧通过 PHY 寄存器强制。交叉线现在大多数网卡支持自动翻转但老交换机和老 PHY 不一定。如果你用的是直连板子和 PC可以换交叉线试试。更省事的办法是中间加一个小交换机让两边都按标准接法协商。很多“玄学不通”加个交换机就好了。6.3 虚拟机桥接 WiFi 的兼容性比你想的更差用笔记本联调板子时很多人只有 WiFi没有有线网口。虚拟机桥接到 WiFi有时能收到 ARP但广播包会被过滤或者桥接驱动对无线网卡支持不好。Uboot ping 虚拟机时ARP 是广播ICMP 是单播。广播在 WiFi 桥接下容易出问题。建议用 USB 千兆网卡或者 USB 网卡加小交换机把板子和虚拟机桥接到同一个有线广播域。这个方案很土但成功率很高。VMware 里把 VMnet0 桥接到 USB 网卡VirtualBox 里桥接名称选 USB 网卡板子和虚拟机都设同网段 IP。6.4 供电、复位和上电顺序别等抓包才想起来最后说一个最容易被忽略的坑PHY 供电和复位时序。有些板子 PHY 和 MAC 共用电源上电顺序不对PHY 初始化失败。有些板子复位 GPIO 默认拉低Uboot 没及时释放PHY 一直复位。表现是 PHY ID 读不到或者时好时坏。你可以用万用表量 PHY 电源用示波器看复位脚。如果 Uboot 启动日志里 PHY 初始化偶尔成功偶尔失败重点查电源和复位。还有时钟25MHz 或 50MHz 参考时钟没起来PHY 也不会工作。硬件问题用软件很难绕过去早查早省事。我个人在实际操作中的体会是Uboot ping 不通时先别急着改内核、改 IP、重装虚拟机。先按“PHY 链路、ARP、ICMP、对端防火墙、虚拟机网络模式”这条线走一遍九成问题会自己浮出来。手上常备一根确认好的网线、一个百兆小交换机、一个 USB 有线网卡能省下大量来回折腾的时间。