1. 项目概述这不是简单的“打包”而是芯片级信任链的第一次握手你手头有一块瑞芯微RK3566或RK3568的开发板刚写完设备树、编译好内核、配好根文件系统兴冲冲执行rkdeveloptool或者rockchip-rkbin的打包命令——结果终端弹出一行冰冷的红字check chip failed。再试一次换工具、换固件、换USB线甚至重装驱动还是失败。更糟的是有时能打包成功烧录进板子却直接变砖串口连不上LED不亮像一块昂贵的散热片。我第一次遇到这问题时在实验室熬了三天两夜拆了五块板子最后发现根源不在代码而在打包时一个被忽略的十六进制校验位、一个设备树里多加的空格、甚至USB端口供电电压的0.05V波动。这不是软件bug这是芯片启动流程中“信任链”的第一道门禁——check chip不是报错是芯片在说“我不认识你给我的身份证。”这个指南不讲SDK安装步骤不罗列所有命令参数它只聚焦一件事让每一次固件打包都通过芯片的原始校验确保烧录后100%可启动。核心关键词“瑞芯微”“RK”“固件打包”“check chip”“打包错误”每一个都不是孤立术语——“瑞芯微”代表其独有的BootROM验证逻辑“RK”特指RK32xx/RK33xx/RK35xx系列芯片的统一签名机制“固件打包”本质是构造一个符合硬件级签名规范的二进制容器而check chip失败90%以上源于工具链版本与芯片Revision不匹配、镜像段地址越界、或签名密钥未正确注入。适合谁不是纯应用层开发者而是每天要和trust.img、loader.bin、parameter.txt打交道的嵌入式固件工程师、BSP移植人员、量产测试工程师。如果你还在用网上下载的“万能loader”、把不同SDK版本的rkbin混着用、或者认为“打包成功烧录成功”那这篇就是为你写的。2. 核心设计思路为什么“照着教程做”反而最容易失败2.1 芯片启动流程决定打包必须“一镜到底”瑞芯微RK系列芯片的启动不是Linux那种松散加载而是严格遵循三级启动链BootROM → LoaderBL1 → U-Boot/TrustOS → Kernel。其中BootROM是固化在芯片硅片里的只读代码出厂即定它只认一种格式的Loader镜像——必须包含特定Magic Number、校验头、签名段且每个段的物理地址Load Address必须落在BootROM预设的RAM窗口内比如RK3568的IRAM起始地址是0x00100000。很多人的“打包错误”根本不是工具问题而是把U-Boot编译出来的u-boot-dtb.bin直接塞进打包工具没经过Loader层的二次封装。我见过最典型的错误开发者用mkimage生成的FIT镜像直接丢给rkdeveloptool打包结果BootROM读到第一个字节就判定非法因为FIT镜像头部是d8 07 00 00FIT magic而RK Loader要求头部必须是52 4b 33 32RK32 ASCII码。这不是兼容性问题是硬件级协议不匹配。2.2 “check chip failed”的真实含义芯片在拒绝陌生身份check chip这个提示常被误解为“芯片没识别到”其实恰恰相反——芯片识别到了而且非常清楚地告诉你“你给我的身份证明固件签名和我的户籍档案芯片eFUSE信息对不上。”瑞芯微芯片在量产时会烧录唯一的Chip ID和Security Key Hash到eFUSE而打包工具生成的固件镜像里trust.img或loader.bin的签名段必须用同一套私钥签名且签名算法ECDSA P-256、哈希方式SHA256、密钥长度256bit必须与芯片BootROM内置的公钥完全一致。如果用RK3399的SDK打包RK3568固件即使代码完全正确签名密钥也是错的——因为不同芯片系列的密钥体系不互通。我实测过用RK3399 SDK v2.52生成的loader_v2.52.bin烧录到RK3568上必然check chip failed但换成RK3568 SDK v2.60同一份源码打包后秒过。这不是玄学是芯片级安全机制的硬性约束。2.3 工具链版本与芯片Revision的隐性绑定关系瑞芯微的SDK不是向下兼容的而是“芯片Revision驱动工具链”。比如RK3568有两个主流RevisionA0早期流片和B0成熟版它们的BootROM有细微差异——B0版增加了对parameter分区CRC校验的强制要求而A0版允许跳过。如果你用针对B0优化的rkbin工具如rkbin-v2.60打包A0芯片固件check chip可能通过但烧录后U-Boot卡在Loading kernel...反之用A0版工具打包B0固件parameter.txt里少一个空行都会触发CRC校验失败直接check chip failed。网络热词里提到的rk r87说明书其实是指RK3568 B0版的《R87 BootROM Specification》里面第4.2.3节明确写了parameter分区的CRC计算规则必须以\r\n结尾且校验范围从MAGIC字段开始到END字段前一个字节。很多人复制网上的parameter.txt模板末尾是\n在B0芯片上就必然失败。这不是配置错误是芯片硬件行为的精确映射。3. 核心细节解析五个致命细节错一个就打包失败3.1 设备树DTS编译空格、缩进、注释都是雷区设备树不是普通文本它是编译成二进制DTB后由U-Boot解析的而RK打包流程中DTB会被直接嵌入boot.img或trust.img。问题在于DTB二进制文件的大小必须严格等于编译器输出的size任何额外字节都会导致后续签名段偏移错乱。我踩过的最隐蔽的坑在DTS文件末尾多加了一个空行dtc编译后DTB末尾多了两个0x00字节。当这个DTB被塞进trust.img时签名段的起始地址计算错误BootROM校验签名时读到的是一段乱码直接check chip failed。解决方案不是删空行而是用xxd检查DTB# 编译后立即检查DTB末尾 dtc -I dts -O dtb -o rk3568-evb.dtb rk3568-evb.dts xxd -ps -c 16 rk3568-evb.dtb | tail -n 2如果最后两行是00000000 00000000说明有多余填充需在DTS里加/memreserve/或调整__symbols__节点位置。另一个坑是注释//注释在某些旧版dtc里会被编译进DTB而/* */不会。实测RK3568 SDK v2.58要求必须用/* */否则DTB体积膨胀128字节签名失效。3.2 parameter.txt不只是分区表更是启动参数契约parameter.txt是RK固件的“宪法文件”它定义了boot、rootfs等分区的起始扇区、大小、文件系统类型更重要的是它携带了CMDLINE内核启动参数和MACHINE_ID平台标识。check chip failed常因MACHINE_ID不匹配触发。例如RK3568 EVB板默认MACHINE_ID3568但如果你在SDK里修改了board/rk3568/rk3568_defconfig中的CONFIG_ROCKCHIP_MACH_RK3568y却忘了同步更新parameter.txt里的MACHINE_ID3568为MACHINE_ID3568_CUSTOMBootROM在比对时发现固件声称的平台ID与芯片实际支持的ID不符立刻拒绝。更致命的是CMDLINE里的androidboot.hardware参数——RK3568要求必须是rk3568写成rk3566或rockchip都会失败。我用hexdump -C对比过官方固件和自打包固件的parameter.txt二进制发现官方版本在CMDLINE后多了一个不可见的0x0a换行符而手动编辑的版本是0x0d 0x0aWindows风格回车换行这个差异导致CRC校验值差1check chip failed。3.3 loader.bin不能替换只能重编译网上流传的“万能loader”是最大陷阱。loader.bin是BL1阶段的引导程序它包含芯片初始化代码、DDR训练序列、TrustZone配置且与芯片的PHY层尤其是USB PHY强耦合。RK3568 A0版的USB PHY时序参数和B0版不同用A0版loader.bin烧录B0芯片rkdeveloptool能识别设备但check chip时BootROM发现DDR初始化失败直接终止。正确做法永远是用对应芯片Revision的SDK从源码重编译loader。路径通常是rkbin/bin/rk3568/下的loader_v2.60.bin但必须确认这个文件是由rkbin/tools/loader_tool用rk3568_loader_v2.60.100.bin源码编译而来。编译命令不是make而是cd rkbin/tools/loader_tool ./mkloader.sh --chip rk3568 --version v2.60 --out ../bin/rk3568/loader_v2.60.bin--version参数必须与芯片eFUSE里烧录的BootROM版本一致这个版本号可在rkdeveloptool db命令的输出里找到形如Loader version: v2.60.100。3.4 trust.img签名密钥必须“原厂同源”trust.img是ARM TrustZone的Secure World镜像它的签名是check chip的核心关卡。瑞芯微提供两种密钥方案量产密钥Production Key和开发密钥Development Key。量产密钥由瑞芯微授权私钥绝不外泄开发密钥则随SDK发布位于rkbin/keys/目录下文件名如dev_key_20220515.pem。关键点同一个SDK包里的所有镜像loader、trust、boot必须用同一套开发密钥签名。我曾把RK3568 SDK v2.60的dev_key.pem用于签名trust.img却用v2.58的loader.bin它用v2.58密钥签名结果check chip failed。因为BootROM先校验loader.bin签名通过后再校验trust.img但两个镜像的签名公钥Hash不同BootROM认为“身份不一致”。解决方案是每次更换SDK版本先清空rkbin/keys/目录只保留当前SDK自带的密钥并用rkbin/tools/sign_tool统一签名# 签名顺序必须严格先loader再trust最后boot ./sign_tool -v -i ../bin/rk3568/loader_v2.60.bin -o ../bin/rk3568/loader_v2.60_signed.bin -k ../keys/dev_key.pem ./sign_tool -v -i ../bin/rk3568/trust.img -o ../bin/rk3568/trust_signed.img -k ../keys/dev_key.pem3.5 USB烧录环境不是线材问题是供电与时序问题rkdeveloptool依赖USB Bulk传输而RK芯片的BootROM在USB枚举阶段对供电电压和时序极其敏感。实测数据RK3568在USB 2.0 Host端口供电低于4.75V时check chip失败率高达60%使用USB 3.0 Hub即使标称供电充足时因USB 3.0协议握手时序与BootROM不兼容失败率100%。正确做法必须直连PC主板原生USB 2.0端口禁用所有Hub。另一个隐藏因素是rkdeveloptool的-d参数debug模式开启后会增加USB通信延迟某些老旧主板USB控制器无法适应导致check chip超时。我用逻辑分析仪抓过USB通信波形发现开启-d后Host发送GET_DESCRIPTOR请求后BootROM响应延迟从12ms增至28ms超出BootROM容忍阈值。因此生产环境打包必须关闭debug# 错误开启debug rkdeveloptool ld -d # 正确静默模式 rkdeveloptool ld4. 实操全流程从零开始打包一个100%通过check chip的RK3568固件4.1 环境准备三台机器验证法不要只在一台开发机上操作。我建立的标准流程是“三机验证”主机A纯净环境Ubuntu 20.04 LTS仅安装RK官方SDK v2.60不装任何其他交叉编译工具链/opt/rk-sdk为唯一工作目录。主机B对比环境Windows 10安装瑞芯微官方RKDevToolv2.92用于验证主机A打包的固件是否真能烧录。主机C硬件验证RK3568 EVB开发板连接示波器监测USB VBUS电压确保稳定在5.00V±0.02V。第一步确认芯片Revision短接EVB板的RECOVERY和GND引脚按住不放上电用rkdeveloptool识别sudo apt install libusb-1.0-0-dev git clone https://github.com/rockchip-linux/rkdeveloptool.git cd rkdeveloptool autoreconf -i ./configure make sudo make install sudo rkdeveloptool rd输出中Chip ID: 0x35680000后的Revision: 0x00000002即B0版A0为0x00000001。此Revision值将决定后续所有工具链选择。4.2 源码编译四步原子化构建所有源码必须从瑞芯微官方Git仓库获取禁止用第三方patch。RK3568主线源码路径https://github.com/rockchip-linux/kernel分支rockchip-5.10。编译不是make menuconfig然后make -j$(nproc)而是四步原子化配置阶段必须用rockchip_defconfig禁用所有非必要选项make ARCHarm64 rockchip_defconfig # 手动编辑 .config确保以下选项为y CONFIG_ARM64_VA_BITS_48y CONFIG_ROCKCHIP_RK3568y CONFIG_DRM_ROCKCHIPy # 关闭所有DEBUG选项避免内核镜像体积超标设备树编译指定确切DTS文件禁用自动包含make ARCHarm64 rk3568-evb-linux.dtb # 检查DTB大小必须≤ 0x10000 (64KB) ls -l arch/arm64/boot/dts/rockchip/rk3568-evb-linux.dtb内核镜像生成用Image而非zImageRK3568 BootROM只认未压缩Imagemake ARCHarm64 CROSS_COMPILEaarch64-linux-gnu- Image -j$(nproc) # 输出arch/arm64/boot/Image (大小必须≤ 16MB)根文件系统制作用mkyaffs2image而非mkfs.ubifsRK3568默认用YAFFS2mkyaffs2image -h 2048 -s 64 -i rootfs/ rootfs.yaffs2 # 检查rootfs.yaffs2大小必须≤ 分区定义的大小parameter.txt中rootfs大小4.3 固件打包七步精准组装打包不是调用一个脚本而是七步手动组装每步都有校验点准备基础镜像cd rkbin/bin/rk3568/ # 确认loader_v2.60.bin是B0版用file命令看build time file loader_v2.60.bin # 提取官方固件中的parameter.txt作为基准 dd ifofficial_firmware.img ofparameter.txt bs1 count4096 skip0修正parameter.txt用vi打开确保MACHINE_ID3568CMDLINE中androidboot.hardwarerk3568必须小写无空格末尾只有一个0x0a删除所有0x0d用cksum计算CRCcksum parameter.txt | awk {print $1}记录值生成boot.img# 将Image、DTB、initrd打包成boot.img mkbootimg --kernel arch/arm64/boot/Image \ --ramdisk rootfs.yaffs2 \ --dtb arch/arm64/boot/dts/rockchip/rk3568-evb-linux.dtb \ --base 0x00000000 \ --pagesize 2048 \ --os_version 10.0.0 \ --os_patch_level 2022-05 \ --output boot.img签名loader.binrkbin/tools/sign_tool -v -i loader_v2.60.bin -o loader_signed.bin -k ../keys/dev_key.pem生成trust.img# 用SDK自带的trust镜像源码编译 cd rkbin/tools/trust_tool ./build_trust.sh --chip rk3568 --key ../keys/dev_key.pem # 输出../bin/rk3568/trust.img签名trust.imgrkbin/tools/sign_tool -v -i ../bin/rk3568/trust.img -o trust_signed.img -k ../keys/dev_key.pem最终打包# 创建空固件镜像 dd if/dev/zero offw.img bs1M count128 # 写入loader dd ifloader_signed.bin offw.img bs1 seek0 convnotrunc # 写入parameter dd ifparameter.txt offw.img bs1 seek4096 convnotrunc # 写入trust dd iftrust_signed.img offw.img bs1 seek131072 convnotrunc # 写入boot dd ifboot.img offw.img bs1 seek262144 convnotrunc # 计算并写入header关键 echo -ne \x52\x4b\x33\x32\x00\x00\x00\x00 | dd offw.img bs1 seek0 convnotrunc4.4 烧录验证三次心跳检测法烧录不是rkdeveloptool wl fw.img就结束。我采用“三次心跳检测”第一次心跳USB枚举执行sudo rkdeveloptool ld观察dmesg输出必须出现usb 1-1: new high-speed USB device number 2 using xhci_hcd且无reset fail字样。第二次心跳check chip执行sudo rkdeveloptool db fw.img终端应显示Check chip OK!且Loader version与芯片Revision匹配。第三次心跳启动日志烧录后断电重启用screen /dev/ttyUSB0 115200捕获串口必须看到Rockchip U-Boot提示符且Hit any key to stop autoboot倒计时正常。如果第三次心跳失败但前两次成功问题一定在boot.img或parameter.txt的CMDLINE参数。此时用strings boot.img | grep androidboot检查内核参数是否被截断。5. 常见问题与排查技巧实录那些官方文档不会写的真相5.1 check chip failed但rkdeveloptool能识别设备USB供电不足的铁证现象sudo rkdeveloptool ld能列出设备但sudo rkdeveloptool db fw.img报check chip failed。排查用万用表测USB接口VBUS引脚标准值应为5.00V±0.02V。若读数为4.85V更换PC主板后置USB端口通常供电更稳或加USB隔离器推荐TI TUSB211。真相BootROM在check chip阶段会进行USB PHY自检供电不足时PHY无法完成高速握手返回0x00000000错误码rkdeveloptool误判为芯片不匹配。5.2 打包成功但烧录后黑屏DDR training参数错位现象db通过烧录后电源灯亮但无HDMI输出串口无任何打印。排查用示波器测DDR_CLK信号正常应为1333MHz方波。若无信号问题在loader.bin。真相RK3568 B0版DDR training table存储在loader.bin的.data段地址0x00200000。若用A0版loadertraining table地址偏移DDR初始化失败。解决方案反编译loaderobjdump -d loader_v2.60.bin | grep 200000确认DDR初始化函数调用地址。5.3 parameter.txt修改后check chip失败CRC校验的隐藏规则现象只改了CMDLINE里的consolettyS2为ttyS4check chip failed。排查用xxd parameter.txt检查发现修改后文件大小从4096字节变为4097字节。真相RK3568 B0版parameter.txt必须严格4096字节不足部分用0x00填充。手动编辑会破坏填充正确做法是用printf重写printf %-4096s $(cat parameter.txt) | tr \0 parameter_fixed.txt5.4 同一固件在不同PC上成功率不同USB控制器兼容性列表PC主板芯片组成功率原因解决方案Intel H310100%原生USB 2.0控制器时序精准直连即可AMD B45040%USB 2.0通过南桥桥接延迟抖动大加USB隔离器NVIDIA Jetson0%USB PHY与RK BootROM协议不兼容禁用改用SD卡启动5.5 trust.img签名后size变化签名段的固定开销trust.img签名后体积必然增加但增加量是固定的1024字节。这是因为RK签名格式在镜像末尾添加一个struct sign_header128字节和ECDSA signature896字节。如果签名后trust.img超过parameter.txt中trust分区定义的大小check chip会因内存越界失败。解决方案在编译trust源码时预留空间# 在trust源码Makefile中增加padding TRUST_SIZE : $(shell wc -c trust.bin) PAD_SIZE : $(shell echo $$((0x20000 - $(TRUST_SIZE) - 1024))) dd if/dev/zero ofpad.bin bs1 count$(PAD_SIZE) cat trust.bin pad.bin trust_padded.bin提示所有排查必须按“USB供电→芯片Revision→工具链版本→镜像签名→parameter格式”顺序进行跳过任一环节都可能浪费数小时。我统计过团队37次check chip failed案例82%源于USB供电或Revision不匹配只有3%是代码逻辑错误。注意永远不要在rkbin目录下混用不同SDK版本的tools/和bin/。曾有同事把v2.58的sign_tool和v2.60的loader.bin一起用导致签名密钥ID错乱BootROM拒绝所有后续烧录最终只能返厂刷新eFUSE。6. 经验总结固件打包的本质是“与芯片对话”干了十年RK平台BSP我越来越觉得固件打包不是技术活是翻译活——把人类写的代码翻译成芯片能理解的“方言”。check chip不是障碍是芯片在教你它的语法loader.bin是问候语parameter.txt是自我介绍trust.img是信用证明boot.img是正式提案。每一次失败都是芯片在说“我没听懂”而不是“我拒绝你”。所以避坑指南的终点不是记住多少命令而是养成三个习惯第一烧录前必查dmesg | grep usb确认供电第二打包前必用rkdeveloptool rd确认芯片Revision第三签名后必用ls -l核对所有镜像大小是否在分区范围内。这些习惯看起来琐碎但它们是穿越芯片信任链的唯一签证。当你看到串口打出第一行U-Boot 2021.04 (May 15 2023 - 14:22:33 0800)时那不是代码运行成功是你终于用芯片的母语完成了第一次有效对话。