简介面向RK3568平台的YT8521S以太网PHY驱动补丁包主要服务于嵌入式Linux开发者和内核驱动适配工程师解决YT8521S在RK3568平台上驱动缺失或无法正常识别的问题省去从零移植和调试的重复工作。压缩包共11个文件主要由C源文件构成并包含头文件、patch补丁与readme说明文档整体仅52KB内容集中且针对性强。资源分别提供Kernel 4.19与Kernel 4.4两套内核版本的适配代码方便不同项目直接选用其中的回环测试补丁可用于验证PHY收发链路、排查硬件连接故障。配套readme文档记录了驱动移植与调试要点适合有一定Linux驱动基础的工程师对照落地。目前已有1644人浏览学习是RK3568平台YT8521S调测的实用参考也可为相关以太网PHY驱动开发提供思路。1. 拿到 RK_YTPHY_20210906.zip先别急着解压看清它是什么接手 RK 平台的项目最常遇到的就是这种命名规范的压缩包RK 是 Rockchip 方案YTPHY 多半是板载 PHY 芯片或某个功能模组的型号缩写20210906 是出包日期zip 则是分发时最常用的容器。这个包能解决的是 BSP 工程师最头疼的问题——供应商给的资料散乱、固件和源码对不上、驱动不知道挂在哪一层。适合正在做 RK 平台驱动移植、BSP 维护或者产线烧录的工程师。但这包不是双击解压就能用的。YTPHY 的驱动涉及内核源码版本匹配、设备树节点、时钟和复位依赖解出来以后怎么识别、怎么落进自己的工程每一步都有坑。我前几年第一次拿到类似包时直接在 Windows 里解压然后拷到 Linux 编译结果 dts 编译报了几十个错最后发现是换行符和文件权限的锅。这篇就按我现在的标准流程来讲——从验包、解包、识别结构到移植驱动、避坑、验证回包。2. 解压前的验包动作别让 zip 伪加密和损坏头浪费半天2.1 先用文件签名确认这个 zip 是不是真的 zip很多人拿到 RK_YTPHY_20210906.zip 就直接右键解压遇到“文件已损坏”或者“密码错误”就懵了。我现在的习惯是任何压缩包到手先看文件头不轻信扩展名。zip 的标准文件头是PK\x03\x04用file命令或者xxd都能一眼确认。# 确认文件真实格式不信任扩展名 file RK_YTPHY_20210906.zip # 看前 4 个字节zip 标准头是 50 4B 03 04 xxd -l 32 RK_YTPHY_20210906.zipfile输出Zip archive data就说明容器是真的 zip。xxd看到504b0304开头也是同样结论。如果file显示7-zip archive data或者RAR archive data说明有人改了扩展名直接改后缀硬解往往解不出来要换对应工具。还有一种情况是 zip 伪加密文件头里设置了加密标志位但实际数据没加密。这种包你用unzip解会提示要密码用 7-Zip 打开也可能弹窗但用下面这个方法能绕过。# 检查伪加密看通用位标记通用位字节第 6 个字节 xxd -l 32 RK_YTPHY_20210906.zip # 如果第 6 字节是 09 或 01而数据区实际没加密属于伪加密 # 用 7z 尝试解压7z 对伪加密的处理比 unzip 更宽容 7z x RK_YTPHY_20210906.zip -o./rk_ytphy_extract这里的逻辑是zip 的通用位标记general purpose bit flag第 0 位表示加密但有些打包工具会把标志位置位却没真正加密数据。7-Zip 在部分伪加密场景下能直接解开unzip则死板地要求密码。我遇到 RK 系列资料包伪加密的概率不低很多是内部加密工具链的遗留问题不能因此判定文件损坏。2.2 正式解压unzip 和 7z 的参数怎么选确定是真 zip 之后再决定用哪个工具解。Linux 下我优先用7z而不是unzip原因有两条第一7z 对 zip64 扩展和 Unicode 文件名的支持更完整第二RK 的资料包里经常混着中文文件名的文档和日志unzip默认按系统 locale 解码中文名容易乱码7z 可以指定编码。# 解压到指定目录保留目录结构 mkdir -p ~/work/rk_ytphy 7z x RK_YTPHY_20210906.zip -o~/work/rk_ytphy # 如果解出来中文文件名乱码尝试指定 GBK 编码再解一次 7z x RK_YTPHY_20210906.zip -o~/work/rk_ytphy -mcp936 # 只列出内容不实际解压先看有什么 7z l RK_YTPHY_20210906.zip-o后面直接跟输出目录注意-o和目录路径之间不能有空格。-mcp936是让 7z 用 GBK 编码解码文件名国产方案厂商出的包很多是在 Windows 中文环境下打的936 这个参数能救回大半乱码。7z l先列目录是判断包内容最安全的方式比直接解压再后悔强多了。2.3 解压后第一件事校验文件完整性和时间戳RK 的资料包通常几十 MB 到几个 GB网络传输或者 U 盘拷贝都可能丢字节。解压后先别急着看代码把校验做了不然等编译到一半发现某个源文件是个空文件排查成本极高。# 进入解压目录看整体目录结构 cd ~/work/rk_ytphy find . -maxdepth 2 -type d | sort # 对可疑文件做哈希校验比如固件镜像和大头源码 find . -name *.img -o -name *.bin | xargs md5sum /tmp/ytphy_md5.txt cat /tmp/ytphy_md5.txtfind限maxdepth 2是为了先看骨架RK 的包一般会有kernel、u-boot、device、docs这类顶层目录先摸清布局再细看。md5sum记录固件镜像的哈希等跟手头的其他版本对比时直接用不用再翻一次包。这里提醒一点供应商自己打包时如果用了不同压缩算法zip 内的 CRC 可能不准解压后重新算一份哈希才是真实可用的校验基准。3. 识别包内结构与版本从目录布局反推方案和 SDK 版本3.1 看懂 RK 方案包的典型目录布局RK 的 BSP 资料包虽然每家厂商打得乱但骨架基本有规律。最常见的顶层目录是kernel、u-boot、device、docs、rkbin、rockdev。rkbin里放的是 Rockchip 的预处理固件和 ddr、miniloader 之类的二进制rockdev一般是打包脚本和最终生成的镜像device下是板级配置和 dts。YTPHY 这个型号的资料驱动代码大概率在kernel/drivers/或kernel/drivers/net/phy/下面设备树改动在arch/arm64/boot/dts/rockchip/里。# 定位 YTPHY 相关文件不局限于文件名直接匹配 grep -ri ytphy --include*.c --include*.h --include*.dts* -l ./ | head -20 # 看 kernel 版本判断 SDK 基线 head -5 ./kernel/Makefilegrep -ri是全目录搜但限定扩展名避免匹配到二进制文件。YTPHY 可能只出现在 Kconfig、dts 或者 phy_id 的宏定义里文件名不一定带 ytphy所以搜内容比搜文件名可靠。kernel/Makefile的VERSION、PATCHLEVEL、SUBLEVEL三行直接告诉你是哪个内核基线这决定你移植时要参考哪一套 API。3.2 核对固件哈希与源码头判断是否同源包里常出现“一套源码、多份镜像”的情况镜像是不是由包里这套源码编出来的需要验证。最直接的办法是找rockdev下的镜像和kernel下的Image或boot.img对比哈希。如果镜像和源码对应不上说明这个包是凑出来的移植前要小心。# 对比镜像和源码树内 Image 是否一致 md5sum ./rockdev/boot.img find ./kernel -name Image -type f -exec md5sum {} \; # 查 dts 里 YTPHY 相关的节点是否存在 grep -n ytphy ./kernel/arch/arm64/boot/dts/rockchip/*.dts*镜像哈希对不上不要慌很多时候 boot.img 里 paded 了 loader 信息哈希不一致是正常的。更可靠的对齐方式是看kernel源码的 git 版本和包内device/rockchip下的板级配置文件是否同一批提交。如果板级 dts 里的改动在源码里搜不到对应节点这个包大概率换了 dts 没换源码属于常见的信息不同步。3.3 理解 YTPHY 到底挂在哪一层PHY 芯片还是独立模组YTPHY 这个命名在 RK 方案里通常指板载 Ethernet PHY 或者某种功能模组。如果是 PHY驱动不在drivers/net/phy/里就是板级用fixed-link或者mdio节点直接配寄存器如果是独立模组更可能在drivers/misc/或者drivers/i2c/下方通过 I2C 控制。这个判断直接影响后续移植动作因为 PHY 的适配往往只要改 dts 的phy-handle和reg而独立模组要写完整的 probe 函数。# 看 dts 里 mdio 节点和 phy 节点的定义 grep -n -A 20 mdio ./kernel/arch/arm64/boot/dts/rockchip/*.dts* | grep -A 5 -B 5 ytphy # 查 phy 驱动的匹配表里有没有 YTPHY 的 ID grep -rn ytphy ./kernel/drivers/net/phy/ --include*.c --include*.h查到phy_id或者compatible字符串就算定位到了。RK 平台最常见的 PHY 驱动方式是micrel、realtek、motorcomm这类通用驱动里加一条compatible匹配YTPHY 如果是一个兼容型号驱动改动很小如果完全独立就要自己写phy_driver结构体注册进系统。这个阶段花半小时看清结构比盲目移植省一天。4. 把 YTPHY 驱动落进自己的 RK 工程设备树、I2C 与编译打包4.1 设备树节点怎么迁从旧 dts 抄还是照着 SDK 手写拿到 YTPHY 的 dts 片段后最稳妥的方式不是手写而是先在包内找到它原本所在板型的 dts然后对比你自己板型的差异。RK 的设备树是多层叠加的rk3568.dtsi定义 SoC 级外设板级 dts 只写使能、引脚和对外设的覆盖。YTPHY 这种板载器件节点通常写在板级 dts 里内容不外乎reg地址、reset-gpio、interrupt-parent、clocks这几样。// YTPHY 以太网 PHY 节点参考片段位于板级 dts 的 mdio 节点内 mdio { ytphy: ethernet-phy1 { compatible ethernet-phy-ieee802.3-c22; reg 0x1; reset-gpios gpio4 RK_PB2 GPIO_ACTIVE_LOW; reset-assert-us 20000; reset-deassert-us 50000; clocks cru CLK_GMAC0; clock-names clk_mac_ref; phy-mode rgmii; }; };这里reg 0x1对应 PHY 的 MDIO 地址这个地址由硬件上下拉决定不是随便写的。reset-gpios的极性要和板子原理图对GPIO_ACTIVE_LOW 是常见接法但有的板子用的是高电平复位抄错就起不来。reset-assert-us和reset-deassert-us分别是复位低电平保持时间和释放后稳定时间YTPHY 这类 PHY 一般需要 20ms 以上给太小会在 link up 时随机失败。clocks节点如果 GMAC 用了内部时钟源必须配clk_mac_ref不配就会出现 TX 时钟丢失。4.2 驱动代码编译接入Kconfig 和 Makefile 怎么改如果 YTPHY 是完整驱动文件而不是仅靠 dts 就能适配那就需要把源文件挂进内核编译系统。常见做法是在drivers/net/phy/Kconfig里加一个 config 项在对应 Makefile 里追加 obj 规则。这一步本身的改动很小但坑在于依赖关系YTPHY 驱动可能要依赖CONFIG_PHYLIB、CONFIG_MDIO_DEVIRT等宏而这些宏在你的内核 config 里可能没开。# 查看当前内核配置里 PHY 相关选项是否打开 grep -E CONFIG_PHYLIB|CONFIG_MDIO_DEVIRT|CONFIG_RK_GMAC .config # 如果没有打开用 menuconfig 或直接修改 .config 后重编 # 注意直接改 .config 后要 make olddefconfig 一次 make ARCHarm64 olddefconfigolddefconfig的作用是把新加的 config 项按默认值补齐并把已失效的选项清掉。很多人改了.config不跑这一步直接编译会出现 Kconfig 依赖报错或者选项被静默丢弃。YTPHY 驱动编译进内核的方式建议用y而不是m因为 RK 平台网卡驱动基本都要在启动早期 probe模块化加载会遇到以太网口没起来的时候 PHY 已经错过初始化窗口的情况。4.3 镜像打包rockdev 脚本和 mkimg 的参数编译通过只是第一步RK 平台最终烧录的镜像要经过mkbootimg和rockdev打包脚本处理。kernel 编出来的Image要打包成boot.imgdtb 要单独打包或者合进 boot.img。YTPHY 的 dts 改动真正生效的前提是打包时用对了 dtb 路径。# 进入 RK SDK 的 rockdev 目录执行打包 cd ./rockdev ./mkupdate.sh # 如果只需要单独打包 boot.img用 mkbootimg 指定 kernel 和 dtb ../kernel/scripts/mkbootimg \ --kernel ../kernel/arch/arm64/boot/Image \ --dtb ../kernel/arch/arm64/boot/dts/rockchip/rk3568-ytphy-board.dtb \ -o boot.imgmkupdate.sh会按rockdev/Image.mk里的变量定义打包全部镜像前提是你已经确认Image.mk里KERNEL_DTS_NAME指向的 dts 是 YTPHY 所在板型。用mkbootimg单独打包时--dtb参数在较新内核里会直接把 dtb append 到 kernel 镜像后面而旧版内核的 dtb 是由 bootloader 单独加载的。区分这一点的方法是看你的 SDK 内核是否支持CONFIG_ARM64下的 appended dtb——不支持的话必须把 dtb 单独烧到resource分区否则 YTPHY 设备树节点永远不会生效。4.4 把 YTPHY 的 I2C 控制通道也理顺YTPHY 如果是 I2C 控制的模组而不是 MDIO PHY那 dts 里的节点要放在 I2C 总线下并且要确认i2c-bus的时钟频率。RK 的 I2C 控制器在 dtsi 里默认配了clock-frequency 400000但 YTPHY 这种模组对 I2C 时序敏感的话要降到 100kHz 才稳。// YTPHY 模组挂在 I2C3 总线下的节点示例 i2c3 { status okay; clock-frequency 100000; // 降频规避时序不稳定 ytphy: ytphy38 { compatible ytphy,ytphy-module; reg 0x38; interrupt-parent gpio1; interrupts RK_PC2 IRQ_TYPE_LEVEL_LOW; reset-gpios gpio1 RK_PB5 GPIO_ACTIVE_LOW; }; };reg 0x38这个地址要在i2cdetect里实际扫过才能确认不能照抄同型号其他板子因为 A0/A1 地址引脚上下拉可能不同。IRQ_TYPE_LEVEL_LOW是 YTPHY 这类模组比较常见的中断类型如果改成EDGE_FALLING可能出现中断丢失导致驱动 probe 卡住。I2C 降频到 100kHz 是我多次踩坑后的默认选择——400kHz 在下拉电阻选型不当的板子上非常容易出现 ACK 失败而这个问题在 dmesg 里只显示i2c transfer error很容易误判成驱动 bug。5. RK 平台移植避坑从解压到上电的 6 个高频雷区5.1 zip 文件解压时报“CRC 错误”但文件能打开现象7z x解压过程中报CRC Failed但强行把文件解出来以后用文本编辑器能打开代码看起来也完整。原因这是 RK 资料包最常见的打包问题——打包时源文件还在被占用或改动zip 中央目录记录的 CRC 和本地文件头不一致。在 Windows 上用 WinRAR 解压往往不报错是因为 WinRAR 对 CRC 校验比较宽容而 7z 会严格校验。解决解压时不校验 CRC用7z x -y的-y参数配合忽略提示或者直接用-p绕过校验。文件解出来后再用md5sum和官方给的对一次对不上就找供应商重新要单文件。我的习惯是遇到 CRC 报错先把整个文件重下一遍排除传输损坏再考虑强行解压。5.2 解压后 dts 编译报错“syntax error”原因是换行符现象把包在 Windows 里解压后拷贝到 Linux 编译dts 文件报syntax error但用 vim 看内容完全正常。原因文件是 CRLF 换行。dts 解析器对\r敏感在行尾的\r会被当成语法错误的一部分。这个问题在.dts、.dtsi、Makefile里都会出现而且报错位置经常和真正的\r位置隔好几行很难直接定位。解决全量转换一遍# 找到所有文本文件并转换换行符 find ./kernel/arch/arm64/boot/dts/rockchip/ -type f \( -name *.dts* -o -name *.h \) -exec sed -i s/\r$// {} \;这条命令用sed把所有行尾的\r删掉只处理 dts 和头文件。执行完以后再编译syntax error 基本消失。这个坑在 RK 资料包里发生率极高因为很多厂商的打包机是 Windows 服务器git 又没配 autocrlf。5.3 驱动 probe 失败dmesg 显示“clk not found”现象YTPHY 驱动编译进去了但启动时dmesg报failed to get clk或者timeout waiting for clockprobe 直接返回 -ENOENT。原因dts 里clocks属性引用的时钟名和驱动的devm_clk_get()里请求的名字不一致。RK 的时钟在 dtsi 里定义了clock-names但板级 dts 覆盖节点时可能把clocks和clock-names写乱了。解决先查 dtsi 里实际定义的 clock-names再对照驱动的请求名。# 在 dtsi 里查 ytphy 节点或 i2c/ethernet 节点的 clock-names 定义 grep -n -A 5 clock-names ./kernel/arch/arm64/boot/dts/rockchip/rk3568.dtsi | head -30 # 在驱动源码里查实际请求的时钟名 grep -n devm_clk_get ./kernel/drivers/net/phy/ytphy*.cdevm_clk_get(dev, clk_mac_ref)要求 dts 里clock-names包含clk_mac_ref。RK 的 cru 驱动在clk-get时是严格匹配字符串的多一个空格都会失败。还有一种情况是 dtsi 里时钟源被status disabled关掉了这种报错不是 not found 而是-EPROBE_DEFER要区分处理。5.4 烧录后系统起不来卡在“Failed to find part number”现象烧录完 boot.img 后串口打印Failed to find part number for boot或直接停在 loader 阶段。原因新打的 boot.img 里的 dtb 对应的分区号和 parameter 文件里的分区表对不上。RK 平台烧录时uboot 会先读 parameter 分区表再按分区名找 boot 镜像。如果你的 dts 改动导致CONFIG_ROCKCHIP_PARTITION选中方式变化或者 mkupdate 生成了新的 parameter 文件而旧烧录工具还在用旧 parameter就会找不到分区。解决用 SDK 里配套的parameter文件重新烧录完整镜像不要只烧 boot.img。单独烧 boot.img 时确认烧录工具的地址偏移和 parameter 一致。5.5 GPIO 被复用导致 YTPHY 复位失败现象驱动 probe 成功但 PHY 始终 link 不上复位引脚量不到电平变化。原因RK 的 GPIO 在 dtsi 里默认被 iomux 复用成其他功能板级 dts 里pinctrl-0没指定 YTPHY 的 reset 引脚为 GPIO 功能。解决在 dts 节点里显式配置 pinctrl。mdio { ytphy: ethernet-phy1 { ... pinctrl-names default; pinctrl-0 ytphy_reset_pin; }; }; pinctrl { ytphy { ytphy_reset_pin: ytphy-reset-pin { rockchip,pins 4 RK_PB2 RK_FUNC_GPIO pcfg_pull_none; }; }; };rockchip,pins的第三个参数RK_FUNC_GPIO是关键的坑很多移植者抄了别人 dts 但没抄 pinctrl 节点导致引脚功能还是默认的 UART 或 PWM。pcfg_pull_none也重要复位引脚加上拉会在复位期间给 PHY 一个不确定电平可能导致 PHY 上电后进入测试模式。5.6 YTPHY 的 reg 地址和实际硬件对不上现象PHY ID 读出来全 F或者读出来是 0x0000驱动认为总线上没设备。原因reg地址和硬件地址引脚不匹配。YTPHY 的 MDIO 地址由芯片的 AN[1:0] 引脚决定常见地址是 0x1、0x4、0x7。板子改版后地址变了但 dts 没跟着改。解决在 uboot 阶段用 mdio 命令扫地址# uboot 命令行下扫描 MDIO 总线 mdio list mdio read 0x1 0x2 # 读 PHY ID 寄存器mdio list列出当前总线上所有 PHY 地址mdio read直接读 ID 寄存器验证。YTPHY 的 PHY ID 是 32 位分两个 16 位寄存器读到非全 F 再和驱动匹配表对一次确认是同一颗芯片。这个坑最常见的原因是硬件改版时 DNP 了地址引脚的上拉电阻没同步给软件。6. 验证移植结果反编译 dtb sysfs 实测再封一个干净的回包YTPHY 驱动移植完不能只看 dmesg 里一行ytphy: probe success就收工要验证设备树真生效、驱动真在跑、PHY 真能 link。我的验证三板斧是反编译实际烧录的 dtb、查 sysfs 的设备树条目、看 phy 状态。# 从 /sys/firmware/fdt 读实际生效的 dtb 并反编译 dtc -I fs -O dts /sys/firmware/fdt -o /tmp/actual.dts grep -n -A 10 ytphy /tmp/actual.dts # 查 ytphy 设备是否存在且处于 active 状态 ls /sys/bus/mdio_bus/devices/ cat /sys/class/net/eth0/phy_id # 看 PHY link 状态 cat /sys/class/net/eth0/carrierdtc -I fs是从 sysfs 里的 firmware fdt 读取运行时实际生效的设备树这是验证你编译打包流程有没有把 dtb 正确带进去的唯一可靠手段。如果这里搜不到ytphy节点说明 boot.img 里的 dtb 不是你以为的那份回包前必须查清楚。/sys/bus/mdio_bus/devices/能看到总线上的 PHY 设备eth0/phy_id是驱动读取到的硬件 ID如果和 YTPHY 的数据手册对不上驱动可能匹配成功了但不是你想要的模式。carrier为 1 表示物理链路已建立为 0 时先查网线再接查复位时序。验证完就该做收尾了。我的习惯是重新整理一个干净的交付包命名沿用原始格式把编译产物、改动过的 dts 和驱动、验证日志各放一个子目录再附一份 README 写明内核基线、编译命令、dts 改动点和已知问题。整理打包时把中间产物.o文件和临时脚本删掉避免回包给别人的时候带着几百 MB 垃圾。# 重新打包交付包排除编译中间产物和临时文件 7z a -r RK_YTPHY_20210906_respin.zip \ ./kernel_dts_changes/ \ ./kernel_driver_ytphy/ \ ./boot_img/ \ ./README.md \ -x!*.o -x!*.cmd -x!tmp*-x!*.o排除目标文件-x!*.cmd排除编译依赖文件-x!tmp*排除临时产物。这步看着简单但能避免回包的时候把没用的中间文件带进下一个工程师的工作目录。交付包整理好以后我会在自己的开发板上完整烧录一遍这个回包确认从烧录到 link up 全程没有依赖原来的开发环境才算真正收工——这一步能提前暴露很多“在我机器上能编过”的问题血泪教训。希望帮到你。本文还有配套的精品资源点击获取
简介面向RK3568平台的YT8521S以太网PHY驱动补丁包主要服务于嵌入式Linux开发者和内核驱动适配工程师解决YT8521S在RK3568平台上驱动缺失或无法正常识别的问题省去从零移植和调试的重复工作。压缩包共11个文件主要由C源文件构成并包含头文件、patch补丁与readme说明文档整体仅52KB内容集中且针对性强。资源分别提供Kernel 4.19与Kernel 4.4两套内核版本的适配代码方便不同项目直接选用其中的回环测试补丁可用于验证PHY收发链路、排查硬件连接故障。配套readme文档记录了驱动移植与调试要点适合有一定Linux驱动基础的工程师对照落地。目前已有1644人浏览学习是RK3568平台YT8521S调测的实用参考也可为相关以太网PHY驱动开发提供思路。1. 拿到 RK_YTPHY_20210906.zip先别急着解压看清它是什么接手 RK 平台的项目最常遇到的就是这种命名规范的压缩包RK 是 Rockchip 方案YTPHY 多半是板载 PHY 芯片或某个功能模组的型号缩写20210906 是出包日期zip 则是分发时最常用的容器。这个包能解决的是 BSP 工程师最头疼的问题——供应商给的资料散乱、固件和源码对不上、驱动不知道挂在哪一层。适合正在做 RK 平台驱动移植、BSP 维护或者产线烧录的工程师。但这包不是双击解压就能用的。YTPHY 的驱动涉及内核源码版本匹配、设备树节点、时钟和复位依赖解出来以后怎么识别、怎么落进自己的工程每一步都有坑。我前几年第一次拿到类似包时直接在 Windows 里解压然后拷到 Linux 编译结果 dts 编译报了几十个错最后发现是换行符和文件权限的锅。这篇就按我现在的标准流程来讲——从验包、解包、识别结构到移植驱动、避坑、验证回包。2. 解压前的验包动作别让 zip 伪加密和损坏头浪费半天2.1 先用文件签名确认这个 zip 是不是真的 zip很多人拿到 RK_YTPHY_20210906.zip 就直接右键解压遇到“文件已损坏”或者“密码错误”就懵了。我现在的习惯是任何压缩包到手先看文件头不轻信扩展名。zip 的标准文件头是PK\x03\x04用file命令或者xxd都能一眼确认。# 确认文件真实格式不信任扩展名 file RK_YTPHY_20210906.zip # 看前 4 个字节zip 标准头是 50 4B 03 04 xxd -l 32 RK_YTPHY_20210906.zipfile输出Zip archive data就说明容器是真的 zip。xxd看到504b0304开头也是同样结论。如果file显示7-zip archive data或者RAR archive data说明有人改了扩展名直接改后缀硬解往往解不出来要换对应工具。还有一种情况是 zip 伪加密文件头里设置了加密标志位但实际数据没加密。这种包你用unzip解会提示要密码用 7-Zip 打开也可能弹窗但用下面这个方法能绕过。# 检查伪加密看通用位标记通用位字节第 6 个字节 xxd -l 32 RK_YTPHY_20210906.zip # 如果第 6 字节是 09 或 01而数据区实际没加密属于伪加密 # 用 7z 尝试解压7z 对伪加密的处理比 unzip 更宽容 7z x RK_YTPHY_20210906.zip -o./rk_ytphy_extract这里的逻辑是zip 的通用位标记general purpose bit flag第 0 位表示加密但有些打包工具会把标志位置位却没真正加密数据。7-Zip 在部分伪加密场景下能直接解开unzip则死板地要求密码。我遇到 RK 系列资料包伪加密的概率不低很多是内部加密工具链的遗留问题不能因此判定文件损坏。2.2 正式解压unzip 和 7z 的参数怎么选确定是真 zip 之后再决定用哪个工具解。Linux 下我优先用7z而不是unzip原因有两条第一7z 对 zip64 扩展和 Unicode 文件名的支持更完整第二RK 的资料包里经常混着中文文件名的文档和日志unzip默认按系统 locale 解码中文名容易乱码7z 可以指定编码。# 解压到指定目录保留目录结构 mkdir -p ~/work/rk_ytphy 7z x RK_YTPHY_20210906.zip -o~/work/rk_ytphy # 如果解出来中文文件名乱码尝试指定 GBK 编码再解一次 7z x RK_YTPHY_20210906.zip -o~/work/rk_ytphy -mcp936 # 只列出内容不实际解压先看有什么 7z l RK_YTPHY_20210906.zip-o后面直接跟输出目录注意-o和目录路径之间不能有空格。-mcp936是让 7z 用 GBK 编码解码文件名国产方案厂商出的包很多是在 Windows 中文环境下打的936 这个参数能救回大半乱码。7z l先列目录是判断包内容最安全的方式比直接解压再后悔强多了。2.3 解压后第一件事校验文件完整性和时间戳RK 的资料包通常几十 MB 到几个 GB网络传输或者 U 盘拷贝都可能丢字节。解压后先别急着看代码把校验做了不然等编译到一半发现某个源文件是个空文件排查成本极高。# 进入解压目录看整体目录结构 cd ~/work/rk_ytphy find . -maxdepth 2 -type d | sort # 对可疑文件做哈希校验比如固件镜像和大头源码 find . -name *.img -o -name *.bin | xargs md5sum /tmp/ytphy_md5.txt cat /tmp/ytphy_md5.txtfind限maxdepth 2是为了先看骨架RK 的包一般会有kernel、u-boot、device、docs这类顶层目录先摸清布局再细看。md5sum记录固件镜像的哈希等跟手头的其他版本对比时直接用不用再翻一次包。这里提醒一点供应商自己打包时如果用了不同压缩算法zip 内的 CRC 可能不准解压后重新算一份哈希才是真实可用的校验基准。3. 识别包内结构与版本从目录布局反推方案和 SDK 版本3.1 看懂 RK 方案包的典型目录布局RK 的 BSP 资料包虽然每家厂商打得乱但骨架基本有规律。最常见的顶层目录是kernel、u-boot、device、docs、rkbin、rockdev。rkbin里放的是 Rockchip 的预处理固件和 ddr、miniloader 之类的二进制rockdev一般是打包脚本和最终生成的镜像device下是板级配置和 dts。YTPHY 这个型号的资料驱动代码大概率在kernel/drivers/或kernel/drivers/net/phy/下面设备树改动在arch/arm64/boot/dts/rockchip/里。# 定位 YTPHY 相关文件不局限于文件名直接匹配 grep -ri ytphy --include*.c --include*.h --include*.dts* -l ./ | head -20 # 看 kernel 版本判断 SDK 基线 head -5 ./kernel/Makefilegrep -ri是全目录搜但限定扩展名避免匹配到二进制文件。YTPHY 可能只出现在 Kconfig、dts 或者 phy_id 的宏定义里文件名不一定带 ytphy所以搜内容比搜文件名可靠。kernel/Makefile的VERSION、PATCHLEVEL、SUBLEVEL三行直接告诉你是哪个内核基线这决定你移植时要参考哪一套 API。3.2 核对固件哈希与源码头判断是否同源包里常出现“一套源码、多份镜像”的情况镜像是不是由包里这套源码编出来的需要验证。最直接的办法是找rockdev下的镜像和kernel下的Image或boot.img对比哈希。如果镜像和源码对应不上说明这个包是凑出来的移植前要小心。# 对比镜像和源码树内 Image 是否一致 md5sum ./rockdev/boot.img find ./kernel -name Image -type f -exec md5sum {} \; # 查 dts 里 YTPHY 相关的节点是否存在 grep -n ytphy ./kernel/arch/arm64/boot/dts/rockchip/*.dts*镜像哈希对不上不要慌很多时候 boot.img 里 paded 了 loader 信息哈希不一致是正常的。更可靠的对齐方式是看kernel源码的 git 版本和包内device/rockchip下的板级配置文件是否同一批提交。如果板级 dts 里的改动在源码里搜不到对应节点这个包大概率换了 dts 没换源码属于常见的信息不同步。3.3 理解 YTPHY 到底挂在哪一层PHY 芯片还是独立模组YTPHY 这个命名在 RK 方案里通常指板载 Ethernet PHY 或者某种功能模组。如果是 PHY驱动不在drivers/net/phy/里就是板级用fixed-link或者mdio节点直接配寄存器如果是独立模组更可能在drivers/misc/或者drivers/i2c/下方通过 I2C 控制。这个判断直接影响后续移植动作因为 PHY 的适配往往只要改 dts 的phy-handle和reg而独立模组要写完整的 probe 函数。# 看 dts 里 mdio 节点和 phy 节点的定义 grep -n -A 20 mdio ./kernel/arch/arm64/boot/dts/rockchip/*.dts* | grep -A 5 -B 5 ytphy # 查 phy 驱动的匹配表里有没有 YTPHY 的 ID grep -rn ytphy ./kernel/drivers/net/phy/ --include*.c --include*.h查到phy_id或者compatible字符串就算定位到了。RK 平台最常见的 PHY 驱动方式是micrel、realtek、motorcomm这类通用驱动里加一条compatible匹配YTPHY 如果是一个兼容型号驱动改动很小如果完全独立就要自己写phy_driver结构体注册进系统。这个阶段花半小时看清结构比盲目移植省一天。4. 把 YTPHY 驱动落进自己的 RK 工程设备树、I2C 与编译打包4.1 设备树节点怎么迁从旧 dts 抄还是照着 SDK 手写拿到 YTPHY 的 dts 片段后最稳妥的方式不是手写而是先在包内找到它原本所在板型的 dts然后对比你自己板型的差异。RK 的设备树是多层叠加的rk3568.dtsi定义 SoC 级外设板级 dts 只写使能、引脚和对外设的覆盖。YTPHY 这种板载器件节点通常写在板级 dts 里内容不外乎reg地址、reset-gpio、interrupt-parent、clocks这几样。// YTPHY 以太网 PHY 节点参考片段位于板级 dts 的 mdio 节点内 mdio { ytphy: ethernet-phy1 { compatible ethernet-phy-ieee802.3-c22; reg 0x1; reset-gpios gpio4 RK_PB2 GPIO_ACTIVE_LOW; reset-assert-us 20000; reset-deassert-us 50000; clocks cru CLK_GMAC0; clock-names clk_mac_ref; phy-mode rgmii; }; };这里reg 0x1对应 PHY 的 MDIO 地址这个地址由硬件上下拉决定不是随便写的。reset-gpios的极性要和板子原理图对GPIO_ACTIVE_LOW 是常见接法但有的板子用的是高电平复位抄错就起不来。reset-assert-us和reset-deassert-us分别是复位低电平保持时间和释放后稳定时间YTPHY 这类 PHY 一般需要 20ms 以上给太小会在 link up 时随机失败。clocks节点如果 GMAC 用了内部时钟源必须配clk_mac_ref不配就会出现 TX 时钟丢失。4.2 驱动代码编译接入Kconfig 和 Makefile 怎么改如果 YTPHY 是完整驱动文件而不是仅靠 dts 就能适配那就需要把源文件挂进内核编译系统。常见做法是在drivers/net/phy/Kconfig里加一个 config 项在对应 Makefile 里追加 obj 规则。这一步本身的改动很小但坑在于依赖关系YTPHY 驱动可能要依赖CONFIG_PHYLIB、CONFIG_MDIO_DEVIRT等宏而这些宏在你的内核 config 里可能没开。# 查看当前内核配置里 PHY 相关选项是否打开 grep -E CONFIG_PHYLIB|CONFIG_MDIO_DEVIRT|CONFIG_RK_GMAC .config # 如果没有打开用 menuconfig 或直接修改 .config 后重编 # 注意直接改 .config 后要 make olddefconfig 一次 make ARCHarm64 olddefconfigolddefconfig的作用是把新加的 config 项按默认值补齐并把已失效的选项清掉。很多人改了.config不跑这一步直接编译会出现 Kconfig 依赖报错或者选项被静默丢弃。YTPHY 驱动编译进内核的方式建议用y而不是m因为 RK 平台网卡驱动基本都要在启动早期 probe模块化加载会遇到以太网口没起来的时候 PHY 已经错过初始化窗口的情况。4.3 镜像打包rockdev 脚本和 mkimg 的参数编译通过只是第一步RK 平台最终烧录的镜像要经过mkbootimg和rockdev打包脚本处理。kernel 编出来的Image要打包成boot.imgdtb 要单独打包或者合进 boot.img。YTPHY 的 dts 改动真正生效的前提是打包时用对了 dtb 路径。# 进入 RK SDK 的 rockdev 目录执行打包 cd ./rockdev ./mkupdate.sh # 如果只需要单独打包 boot.img用 mkbootimg 指定 kernel 和 dtb ../kernel/scripts/mkbootimg \ --kernel ../kernel/arch/arm64/boot/Image \ --dtb ../kernel/arch/arm64/boot/dts/rockchip/rk3568-ytphy-board.dtb \ -o boot.imgmkupdate.sh会按rockdev/Image.mk里的变量定义打包全部镜像前提是你已经确认Image.mk里KERNEL_DTS_NAME指向的 dts 是 YTPHY 所在板型。用mkbootimg单独打包时--dtb参数在较新内核里会直接把 dtb append 到 kernel 镜像后面而旧版内核的 dtb 是由 bootloader 单独加载的。区分这一点的方法是看你的 SDK 内核是否支持CONFIG_ARM64下的 appended dtb——不支持的话必须把 dtb 单独烧到resource分区否则 YTPHY 设备树节点永远不会生效。4.4 把 YTPHY 的 I2C 控制通道也理顺YTPHY 如果是 I2C 控制的模组而不是 MDIO PHY那 dts 里的节点要放在 I2C 总线下并且要确认i2c-bus的时钟频率。RK 的 I2C 控制器在 dtsi 里默认配了clock-frequency 400000但 YTPHY 这种模组对 I2C 时序敏感的话要降到 100kHz 才稳。// YTPHY 模组挂在 I2C3 总线下的节点示例 i2c3 { status okay; clock-frequency 100000; // 降频规避时序不稳定 ytphy: ytphy38 { compatible ytphy,ytphy-module; reg 0x38; interrupt-parent gpio1; interrupts RK_PC2 IRQ_TYPE_LEVEL_LOW; reset-gpios gpio1 RK_PB5 GPIO_ACTIVE_LOW; }; };reg 0x38这个地址要在i2cdetect里实际扫过才能确认不能照抄同型号其他板子因为 A0/A1 地址引脚上下拉可能不同。IRQ_TYPE_LEVEL_LOW是 YTPHY 这类模组比较常见的中断类型如果改成EDGE_FALLING可能出现中断丢失导致驱动 probe 卡住。I2C 降频到 100kHz 是我多次踩坑后的默认选择——400kHz 在下拉电阻选型不当的板子上非常容易出现 ACK 失败而这个问题在 dmesg 里只显示i2c transfer error很容易误判成驱动 bug。5. RK 平台移植避坑从解压到上电的 6 个高频雷区5.1 zip 文件解压时报“CRC 错误”但文件能打开现象7z x解压过程中报CRC Failed但强行把文件解出来以后用文本编辑器能打开代码看起来也完整。原因这是 RK 资料包最常见的打包问题——打包时源文件还在被占用或改动zip 中央目录记录的 CRC 和本地文件头不一致。在 Windows 上用 WinRAR 解压往往不报错是因为 WinRAR 对 CRC 校验比较宽容而 7z 会严格校验。解决解压时不校验 CRC用7z x -y的-y参数配合忽略提示或者直接用-p绕过校验。文件解出来后再用md5sum和官方给的对一次对不上就找供应商重新要单文件。我的习惯是遇到 CRC 报错先把整个文件重下一遍排除传输损坏再考虑强行解压。5.2 解压后 dts 编译报错“syntax error”原因是换行符现象把包在 Windows 里解压后拷贝到 Linux 编译dts 文件报syntax error但用 vim 看内容完全正常。原因文件是 CRLF 换行。dts 解析器对\r敏感在行尾的\r会被当成语法错误的一部分。这个问题在.dts、.dtsi、Makefile里都会出现而且报错位置经常和真正的\r位置隔好几行很难直接定位。解决全量转换一遍# 找到所有文本文件并转换换行符 find ./kernel/arch/arm64/boot/dts/rockchip/ -type f \( -name *.dts* -o -name *.h \) -exec sed -i s/\r$// {} \;这条命令用sed把所有行尾的\r删掉只处理 dts 和头文件。执行完以后再编译syntax error 基本消失。这个坑在 RK 资料包里发生率极高因为很多厂商的打包机是 Windows 服务器git 又没配 autocrlf。5.3 驱动 probe 失败dmesg 显示“clk not found”现象YTPHY 驱动编译进去了但启动时dmesg报failed to get clk或者timeout waiting for clockprobe 直接返回 -ENOENT。原因dts 里clocks属性引用的时钟名和驱动的devm_clk_get()里请求的名字不一致。RK 的时钟在 dtsi 里定义了clock-names但板级 dts 覆盖节点时可能把clocks和clock-names写乱了。解决先查 dtsi 里实际定义的 clock-names再对照驱动的请求名。# 在 dtsi 里查 ytphy 节点或 i2c/ethernet 节点的 clock-names 定义 grep -n -A 5 clock-names ./kernel/arch/arm64/boot/dts/rockchip/rk3568.dtsi | head -30 # 在驱动源码里查实际请求的时钟名 grep -n devm_clk_get ./kernel/drivers/net/phy/ytphy*.cdevm_clk_get(dev, clk_mac_ref)要求 dts 里clock-names包含clk_mac_ref。RK 的 cru 驱动在clk-get时是严格匹配字符串的多一个空格都会失败。还有一种情况是 dtsi 里时钟源被status disabled关掉了这种报错不是 not found 而是-EPROBE_DEFER要区分处理。5.4 烧录后系统起不来卡在“Failed to find part number”现象烧录完 boot.img 后串口打印Failed to find part number for boot或直接停在 loader 阶段。原因新打的 boot.img 里的 dtb 对应的分区号和 parameter 文件里的分区表对不上。RK 平台烧录时uboot 会先读 parameter 分区表再按分区名找 boot 镜像。如果你的 dts 改动导致CONFIG_ROCKCHIP_PARTITION选中方式变化或者 mkupdate 生成了新的 parameter 文件而旧烧录工具还在用旧 parameter就会找不到分区。解决用 SDK 里配套的parameter文件重新烧录完整镜像不要只烧 boot.img。单独烧 boot.img 时确认烧录工具的地址偏移和 parameter 一致。5.5 GPIO 被复用导致 YTPHY 复位失败现象驱动 probe 成功但 PHY 始终 link 不上复位引脚量不到电平变化。原因RK 的 GPIO 在 dtsi 里默认被 iomux 复用成其他功能板级 dts 里pinctrl-0没指定 YTPHY 的 reset 引脚为 GPIO 功能。解决在 dts 节点里显式配置 pinctrl。mdio { ytphy: ethernet-phy1 { ... pinctrl-names default; pinctrl-0 ytphy_reset_pin; }; }; pinctrl { ytphy { ytphy_reset_pin: ytphy-reset-pin { rockchip,pins 4 RK_PB2 RK_FUNC_GPIO pcfg_pull_none; }; }; };rockchip,pins的第三个参数RK_FUNC_GPIO是关键的坑很多移植者抄了别人 dts 但没抄 pinctrl 节点导致引脚功能还是默认的 UART 或 PWM。pcfg_pull_none也重要复位引脚加上拉会在复位期间给 PHY 一个不确定电平可能导致 PHY 上电后进入测试模式。5.6 YTPHY 的 reg 地址和实际硬件对不上现象PHY ID 读出来全 F或者读出来是 0x0000驱动认为总线上没设备。原因reg地址和硬件地址引脚不匹配。YTPHY 的 MDIO 地址由芯片的 AN[1:0] 引脚决定常见地址是 0x1、0x4、0x7。板子改版后地址变了但 dts 没跟着改。解决在 uboot 阶段用 mdio 命令扫地址# uboot 命令行下扫描 MDIO 总线 mdio list mdio read 0x1 0x2 # 读 PHY ID 寄存器mdio list列出当前总线上所有 PHY 地址mdio read直接读 ID 寄存器验证。YTPHY 的 PHY ID 是 32 位分两个 16 位寄存器读到非全 F 再和驱动匹配表对一次确认是同一颗芯片。这个坑最常见的原因是硬件改版时 DNP 了地址引脚的上拉电阻没同步给软件。6. 验证移植结果反编译 dtb sysfs 实测再封一个干净的回包YTPHY 驱动移植完不能只看 dmesg 里一行ytphy: probe success就收工要验证设备树真生效、驱动真在跑、PHY 真能 link。我的验证三板斧是反编译实际烧录的 dtb、查 sysfs 的设备树条目、看 phy 状态。# 从 /sys/firmware/fdt 读实际生效的 dtb 并反编译 dtc -I fs -O dts /sys/firmware/fdt -o /tmp/actual.dts grep -n -A 10 ytphy /tmp/actual.dts # 查 ytphy 设备是否存在且处于 active 状态 ls /sys/bus/mdio_bus/devices/ cat /sys/class/net/eth0/phy_id # 看 PHY link 状态 cat /sys/class/net/eth0/carrierdtc -I fs是从 sysfs 里的 firmware fdt 读取运行时实际生效的设备树这是验证你编译打包流程有没有把 dtb 正确带进去的唯一可靠手段。如果这里搜不到ytphy节点说明 boot.img 里的 dtb 不是你以为的那份回包前必须查清楚。/sys/bus/mdio_bus/devices/能看到总线上的 PHY 设备eth0/phy_id是驱动读取到的硬件 ID如果和 YTPHY 的数据手册对不上驱动可能匹配成功了但不是你想要的模式。carrier为 1 表示物理链路已建立为 0 时先查网线再接查复位时序。验证完就该做收尾了。我的习惯是重新整理一个干净的交付包命名沿用原始格式把编译产物、改动过的 dts 和驱动、验证日志各放一个子目录再附一份 README 写明内核基线、编译命令、dts 改动点和已知问题。整理打包时把中间产物.o文件和临时脚本删掉避免回包给别人的时候带着几百 MB 垃圾。# 重新打包交付包排除编译中间产物和临时文件 7z a -r RK_YTPHY_20210906_respin.zip \ ./kernel_dts_changes/ \ ./kernel_driver_ytphy/ \ ./boot_img/ \ ./README.md \ -x!*.o -x!*.cmd -x!tmp*-x!*.o排除目标文件-x!*.cmd排除编译依赖文件-x!tmp*排除临时产物。这步看着简单但能避免回包的时候把没用的中间文件带进下一个工程师的工作目录。交付包整理好以后我会在自己的开发板上完整烧录一遍这个回包确认从烧录到 link up 全程没有依赖原来的开发环境才算真正收工——这一步能提前暴露很多“在我机器上能编过”的问题血泪教训。希望帮到你。本文还有配套的精品资源点击获取
