简介本资源是面向嵌入式Linux驱动开发者的RK3568平台YT8521S千兆以太网PHY芯片适配补丁包专为需要在Rockchip平台快速集成国产Motorcomm PHY器件的工程师设计解决内核驱动缺失、环回测试支持不足及硬件兼容性调试难题。压缩包共11个文件含6个C源码如motorcomm.c、dwmac-rk-tool.c、2个头文件motorcomm_phy.h等、2个说明类txt文档及1个关键patch补丁覆盖驱动实现、工具扩展与测试验证全链路总大小仅52KB轻量易集成。已有1643人学习下载适合具备Linux内核4.19/4.4版本开发经验、正开展RK3568网口调试或国产PHY适配项目的中高级嵌入式开发者。读者可直接复用补丁完成驱动编译加载结合readme.txt理解适配逻辑利用0001_yt8521s_loopback_test.patch快速启用环回功能大幅缩短PHY Bring-up周期。1. RK_YTPHY_20210906.zip 不是普通固件包它是 RK 平台 PHY 驱动与硬件协同调测的关键快照看到RK_YTPHY_20210906.zip这个命名很多刚接触 Rockchip SoC 的嵌入式工程师第一反应是“又一个旧版 SDK 压缩包”但实际拆开后常会困惑里面没有完整 kernel 源码树也没有 buildroot 或 u-boot只有drivers/net/phy/rockchip/下几组 patch、一组.dtsi片段、配套的dwmac-rk-tool二进制和一份极简的README.md。它真正承载的是 2021 年 9 月前后某款搭载 YT 系列定制 PHY 芯片非标准 RTL8211F/DP83848的 RK3328/RK3399 板卡在 kernel 4.19 主线适配中为解决 PHY link 不稳、auto-negotiation 失败、MII/RGMII 时序偏移等硬伤所沉淀的最小可验证方案。它不面向最终用户而是给驱动工程师、硬件联调人员用的“问题定位锚点”——当你在 RK 平台点亮 MIPI 屏幕时发现以太网 PHY 初始化失败导致系统 hang 在 early boot或ethtool -s eth0 speed 1000 duplex full后链路秒断这个 zip 就是你回溯电源树 RK 配置、PHY 寄存器重写逻辑、以及dwmac-rk-tool低层寄存器探针行为的最短路径。适用人群明确正在 RK3399 Pro 或 RK3566 上调试千兆以太网 PHY 的 BSP 工程师、需要复现并修复phylink状态机异常的内核开发者以及被rk_gmac_dvfs电源管理策略误关 PHY 供电而卡住的硬件验证人员。2. 解析 RK_YTPHY_20210906.zip 的核心组成与 kernel 4.19 兼容性边界2.1 压缩包内文件结构与真实作用域映射解压RK_YTPHY_20210906.zip后典型目录结构如下RK_YTPHY_20210906/ ├── drivers/ │ └── net/ │ └── phy/ │ └── rockchip/ │ ├── ytphy.c # YT 系列 PHY 驱动主文件非标准 vendor ID │ ├── ytphy.h # 寄存器定义与私有 ops 结构体 │ └── Makefile # 编译规则依赖 CONFIG_PHY_ROCKCHIP ├── dts/ │ ├── rk3328-ytphy.dtsi # 针对 RK3328 的 PHY 节点定义含 reset-gpios, phy-supply │ └── rk3399-ytphy.dtsi # 针对 RK3399 的 PHY 节点定义含 phy-mode rgmii-rxid ├── tools/ │ └── dwmac-rk-tool # ARM64 交叉编译的用户态寄存器读写工具非开源v1.2.3 ├── patches/ │ ├── 0001-phy-rockchip-add-YT-PHY-support.patch │ └── 0002-dwmac-rk-fix-RGMII-timing-for-YT-PHY.patch └── README.md提示该包不提供完整 kernel tree所有 patch 均基于 kernel 4.19.217 LTS 分支生成。若你使用 kernel 4.4如 RK3288 常用版本直接应用0001-phy-rockchip-add-YT-PHY-support.patch会因struct phy_driver成员变更如config_init→config_aneg而编译失败kernel 5.10 则因phylink架构重构ytphy.c中ytphy_config_aneg()的调用链已失效。必须先确认你的 kernel 版本是否在4.19.190 ~ 4.19.230区间。2.2 YT PHY 驱动ytphy.c的三个关键设计点ytphy.c并非简单复制realtek.c其核心差异体现在以下三处2.2.1 自定义 vendor ID 与设备匹配逻辑YT PHY 使用非标准 OUI0x001122非 IEEE 注册因此驱动中ytphy_match_table显式声明static const struct mdio_device_id ytphy_ids[] { { 0x00112200, 0xfffffff0 }, // YT8010A: 0x00112200 mask { 0x00112210, 0xfffffff0 }, // YT8010B: 0x00112210 mask { } };这要求硬件原理图中 PHY 的PHY_ID引脚配置必须输出0x001122xx否则mdio_bus扫描时无法触发ytphy_probe()。常见错误是误将PHY_ID[15:0]接地导致读到0x00000000dmesg | grep phy仅显示rockchip-gmac f7200000.ethernet: no PHY found。2.2.2 RGMII RX/TX 延迟补偿的硬件联动机制YT PHY 要求 RK GMAC 的 RGMII 接口在phy-mode rgmii-rxid时必须关闭 GMAC 内部 RX delay否则出现rx_error持续增长。ytphy.c在ytphy_config_init()中强制写寄存器// 关闭 GMAC 内部 RX delay对应 RK3399 TRM Section 18.3.2.1 reg readl(gmac_base GMAC_MAC_RXQ_CTRL0); reg ~GMAC_RXQ_CTRL0_RX_DELAY_EN; writel(reg, gmac_base GMAC_MAC_RXQ_CTRL0);此操作绕过了phylink的标准协商流程属于 RK 平台特有 hack。若你在设备树中错误配置phy-mode rgmii-id则ytphy.c不会执行此写操作导致千兆链路在 1000Mbps 下丢包率 30%。2.2.3 电源树 RKpower tree RK敏感的 PHY 供电时序YT PHY 对phy-supply的上电时序极为敏感必须在gmac_clkin稳定后 ≥100μs且在phy_reset释放前完成。rk3399-ytphy.dtsi中定义gmac { phy-mode rgmii-rxid; phy-supply vcc_phy; // 必须指向独立 LDO不能复用 vcc_io reset-gpios gpio0 12 GPIO_ACTIVE_LOW; // GPIO0_A12 #address-cells 1; #size-cells 0; phy0 { reg 0; compatible rockchip,ytphy; rockchip,phy-addr 0; rockchip,phy-reset-duration 10; // reset pulse width: 10ms }; };注意vcc_phy必须在pmu中明确定义为独立 regulator并在gmac的clocks之后 enable。若复用vcc_ioytphy.c中ytphy_probe()会因regulator_enable(vcc_phy)返回-EPROBE_DEFER而反复 deferdmesg出现rockchip-ytphy: probe defered循环。2.3 dwmac-rk-tool 的底层寄存器探针能力解析dwmac-rk-tool是此包中唯一用户态工具专用于绕过 kernel driver 直接读写 GMAC 寄存器验证硬件连通性。其核心命令如下命令说明典型用途./dwmac-rk-tool -r 0x0000读取 GMAC MAC 控制寄存器offset 0x0000验证 GMAC 是否被正确 reset./dwmac-rk-tool -w 0x0004 0x00000001写入 MAC 配置寄存器0x0004bit01 启用 TX测试 MAC TX path 是否物理连通./dwmac-rk-tool -m 0x10000 0x000000ff读取 PHY 地址 0 的 MII 寄存器 0x10PHY ID1确认 PHY 是否被 MDIO 总线识别关键参数说明-r / -w后的地址为GMAC 寄存器物理地址偏移量非绝对地址需结合 SoC TRM 查找。例如 RK3399 GMAC base 为0xff730000-r 0x0000即读0xff730000。-m命令执行 MDIO 读操作0x10000表示 PHY address0, register0x10PHY ID1。若返回0x00000000说明 PHY 未上电或 MDIO bus 开路。该工具不校验 kernel 4.19 的phylink状态机仅验证硬件层通信。若dwmac-rk-tool -m 0x10000返回有效 ID 但ifconfig eth0 up后ethtool eth0显示Link detected: no问题必在ytphy.c的ytphy_config_aneg()或电源树配置。3. 在 kernel 4.19 环境下集成 YT PHY 驱动的完整构建流程3.1 内核源码树准备与 patch 应用假设你已获取官方 kernel 4.19.217 LTS 源码https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.217.tar.xz执行以下步骤# 解压并进入源码根目录 tar -xf linux-4.19.217.tar.xz cd linux-4.19.217 # 复制 YT PHY 驱动到对应位置 mkdir -p drivers/net/phy/rockchip cp /path/to/RK_YTPHY_20210906/drivers/net/phy/rockchip/* drivers/net/phy/rockchip/ # 应用补丁注意顺序 patch -p1 /path/to/RK_YTPHY_20210906/patches/0001-phy-rockchip-add-YT-PHY-support.patch patch -p1 /path/to/RK_YTPHY_20210906/patches/0002-dwmac-rk-fix-RGMII-timing-for-YT-PHY.patch # 更新 drivers/net/phy/Kconfig添加 YT PHY 配置项 echo -e \nconfig PHY_ROCKCHIP_YT\n\ttristate \Rockchip YT PHY support\\n\tdepends on PHY_ROCKCHIP\n\thelp\n\t Support for YT series PHY chips (0x001122xx) on Rockchip SoCs. drivers/net/phy/Kconfig # 更新 drivers/net/phy/Makefile添加编译规则 echo obj-\$(CONFIG_PHY_ROCKCHIP_YT) rockchip/ytphy.o drivers/net/phy/Makefile提示0002-dwmac-rk-fix-RGMII-timing-for-YT-PHY.patch修改的是drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c若你的 kernel 4.19 源码中该文件路径为drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c标准路径则 patch 可直接应用若为drivers/net/ethernet/rockchip/rk_gmac.c旧版 RK 分支需手动将dwmac-rk.c中rk_gmac_set_rgmii_delay()函数替换为 patch 中的实现。3.2 内核配置启用 YT PHY 支持使用make menuconfig进入图形配置界面按路径导航Device Drivers --- [*] Network device support --- [*] PHY device support and infrastructure --- * Rockchip PHY support (CONFIG_PHY_ROCKCHIP) * Rockchip YT PHY support (CONFIG_PHY_ROCKCHIP_YT) # 新增选项同时确保以下相关选项已启用CONFIG_NET_VENDOR_STMICROystmmac 是 RK GMAC 的基础 driverCONFIG_STMMAC_ETHystmmac 以太网核心CONFIG_STMMAC_PLATFORMyplatform bus 支持CONFIG_PTP_1588_CLOCKy若需硬件时间戳保存配置后执行make -j$(nproc)编译。编译成功后drivers/net/phy/rockchip/ytphy.ko即为生成的模块。3.3 设备树DTS修改与电源树 RK 适配以 RK3399 为例编辑arch/arm64/boot/dts/rockchip/rk3399-evb.dts在gmac节点中整合rk3399-ytphy.dtsi#include rk3399-ytphy.dtsi gmac { status okay; phy-mode rgmii-rxid; phy-supply vcc_phy; // ... 其他原有属性保持不变 }; // 在根节点或 pmu 下添加 vcc_phy regulator 定义 pmu { vcc_phy: vcc-phy-regulator { compatible rockchip,rk808-regulator; regulator-name vcc_phy; regulator-min-microvolt 3300000; regulator-max-microvolt 3300000; regulator-always-on; /* 必须指定 parent supply避免 probe defer */ vcc_phy-supply vcc_io; }; };注意vcc_phy-supply vcc_io是关键。vcc_io是 PMIC 输出的 3.3Vvcc_phy是其子 regulator。若省略此行regulator_get(pdev-dev, phy)在ytphy_probe()中会返回-EPROBE_DEFER因为vcc_phy的 parent 未 ready。可通过cat /sys/kernel/debug/regulator/vcc_phy/state验证其状态是否为enabled。3.4 模块加载与链路验证命令集编译完成后将ytphy.ko推送到目标板并加载# 加载依赖模块顺序不可颠倒 insmod ./stmmac.ko insmod ./dwmac-rk.ko insmod ./ytphy.ko # 观察 dmesg 输出 dmesg | tail -20 # 正常应包含 # rockchip-ytphy ff730000.ethernet-0: PHY [0] driver [ytphy] # rockchip-ytphy ff730000.ethernet-0: Link is Up - 1000/Full # 验证 PHY 状态 ethtool eth0 | grep -E (Speed|Duplex|Link) # 输出应为Speed: 1000Mb/s, Duplex: Full, Link detected: yes # 检查 PHY 寄存器需 root echo 0x0000 /sys/bus/mdio_bus/devices/0:00/reg cat /sys/bus/mdio_bus/devices/0:00/reg # 应返回 0x786d YT PHY 标准状态值若ethtool eth0显示Link detected: no但dwmac-rk-tool -m 0x10000返回0x00112200则问题在ytphy.c的ytphy_config_aneg()。此时需在函数开头添加pr_info(YT PHY aneg start\n);重新编译加载观察dmesg是否打印该信息——若未打印说明phy_start_aneg()未被调用根源在phylink的phylink_create()参数错误。4. 排查 RK 平台 PHY 初始化失败的三大高频场景与 dwmac-rk-tool 实战诊断法4.1 场景一PHY ID 读取为 0x00000000 —— 硬件连接或供电失效这是最基础也最易忽略的问题。当dwmac-rk-tool -m 0x10000返回0x00000000表明 MDIO 总线未收到 PHY 响应。按以下顺序排查检查 PHY reset 引脚电平用万用表测量reset-gpios对应的 GPIO如 RK3399 的GPIO0_A12确认上电后是否为高电平active-low高电平为 reset 状态。若为低电平说明 reset 未释放检查rockchip,phy-reset-duration是否过短或 GPIO 配置错误。验证 PHY 供电电压用示波器测量vcc_phy引脚确认是否稳定输出 3.3V。若电压跌落至 2.8V 以下ytphy.c中regulator_enable(vcc_phy)会失败dmesg出现regulator_enable failed: -EIO。MDIO bus 硬件开路检测dwmac-rk-tool -r 0x0000若返回0xffffffff说明 GMAC 寄存器不可读可能是gmac_clkin未输入或 GMAC 未 reset。此时需检查cru中gmac_clkin的 clock source 是否配置为ext_gmac且外部晶振已起振。4.2 场景二链路能 up 但 ping 丢包率 50% —— RGMII 时序或 PHY 寄存器配置错误此场景表现为ethtool eth0显示Link detected: yes但ping -I eth0 192.168.1.1 -c 100丢包严重。核心原因在于 YT PHY 的 RGMII RX delay 补偿未生效# 使用 dwmac-rk-tool 检查 GMAC RX delay 寄存器状态 ./dwmac-rk-tool -r 0x0008 # 读取 GMAC_MAC_RXQ_CTRL0 # 正常值应为 0x00000000bit00 表示 disable # 若返回 0x00000001则说明 ytphy.c 中的写操作未执行解决方案确认ytphy.c已被正确编译进内核lsmod | grep ytphy检查gmac节点中phy-mode是否严格等于rgmii-rxid注意引号和大小写若使用phy-mode rgmii-id需手动在ytphy.c的ytphy_config_init()中添加writel(0, gmac_base GMAC_MAC_RXQ_CTRL0);强制关闭。4.3 场景三系统启动卡在 Waiting for root device —— 电源树 RKpower tree RK导致 PHY probe defer当dmesg出现大量rockchip-ytphy: probe deferred且无其他错误说明ytphy_probe()因regulator_get()返回-EPROBE_DEFER而循环 retry。根本原因是vcc_phy的 parent regulator如vcc_io尚未 ready。诊断命令# 查看 regulator 依赖树 cat /sys/kernel/debug/regulator/vcc_phy/parent # 应输出 vcc_io # 检查 vcc_io 状态 cat /sys/kernel/debug/regulator/vcc_io/state # 若为 disabled则问题在此 # 查看 vcc_io 的 enable source cat /sys/kernel/debug/regulator/vcc_io/users # 若为空说明无 driver 请求 enable需检查 pmu 中 vcc_io 的定义是否遗漏 regulator-always-on;修复方法在pmu的vcc_io节点中添加regulator-always-on;并确保vcc_phy的vcc_phy-supply vcc_io存在。重启后cat /sys/kernel/debug/regulator/vcc_phy/state应立即显示enabled。5. 利用 dwmac-rk-tool 快速验证 YT PHY 寄存器配置的 4 个关键指令dwmac-rk-tool是 RK_YTPHY_20210906.zip 中最被低估的调试利器。它不依赖 kernel driver直接操作硬件能在 driver 加载前定位 PHY 级问题。以下是生产环境中验证 YT PHY 状态的黄金四指令5.1 指令一读取 PHY 基础 ID确认芯片型号与连接./dwmac-rk-tool -m 0x10000 # 输出示例0x00112200 # 解析高 16 位 0x001122 为 YT 厂商 ID低 16 位 0x0000 为芯片型号 YT8010A若输出0x00000000立即停止后续调试按 4.1 节排查硬件。5.2 指令二读取 PHY 状态寄存器BMSR判断 link 和 aneg 状态./dwmac-rk-tool -m 0x11000 # 输出示例0x0000796d # 解析bit111link okbit51aneg completebit31aneg able # 若 bit110说明 PHY 物理层未连通网线未插或 PHY 未供电5.3 指令三读取 YT PHY 私有寄存器 0x1f验证自定义配置生效YT PHY 将关键配置如 RGMII delay 模式映射到扩展寄存器0x1f。标准值如下寄存器值含义适用场景0x00000001RGMII RX delay enabledphy-mode rgmii-id0x00000000RGMII RX delay disabledphy-mode rgmii-rxid推荐执行./dwmac-rk-tool -m 0x1f000 # 若配置为 rgmii-rxid 但返回 0x00000001则 ytphy.c 中的 disable 操作失败5.4 指令四强制写 PHY 寄存器 0x00触发 link 重协商当ethtool eth0显示 link down但硬件连接正常时可强制 PHY 重启协商# 先读当前控制寄存器值 ./dwmac-rk-tool -m 0x00000 # 写 0x0000重启 aneg再写 0x3000aneg enable restart ./dwmac-rk-tool -w 0x00000 0x0000 ./dwmac-rk-tool -w 0x00000 0x3000 # 1 秒后读 BMSR 确认 link sleep 1 ./dwmac-rk-tool -m 0x11000此操作等效于ethtool -r eth0但绕过 kernel driver可验证 PHY 本身是否健康。若执行后0x11000仍为0x00000000则 PHY 芯片已损坏或焊接虚焊。提示dwmac-rk-tool的所有-m操作均通过/dev/mem访问需 root 权限。若系统启用了CONFIG_STRICT_DEVMEMy需临时禁用echo 0 /proc/sys/kernel/devmem。生产环境切勿长期关闭调试完毕后恢复为1。本文还有配套的精品资源点击获取