做嵌入式开发或者平时喜欢折腾 RK 芯片盒子、开发板的朋友对 RKDevTool 这个名字应该不陌生。Windows 下给瑞芯微设备刷机、备份、调试它几乎是绕不开的一个入口。我最早认真研究 RKDevTool 的解包和打包是因为一块 RK3288 的行业主板需要预装一个自研应用官方固件里没有集成进去现场又只有 Windows 电脑必须自己改固件。折腾过几次之后我对这套流程算是摸得比较透了今天就把 Windows 下用 RKDevTool 配合其他工具做解包和打包的完整思路写出来给同样踩坑的人一个参考。这篇文章不会只停留在“下载工具、点一下按钮”的层面。解包和打包背后涉及 RK 固件的结构、分区镜像的管理、parameter 参数的理解、镜像校验的处理这些东西不搞清楚操作起来很容易出问题。尤其很多新手卡在“解包出来之后不知道哪个文件是系统”“打包完刷进去启动不了”本质上就是对固件结构缺一个整体认识。所以我会从固件组成讲起再一步步说清楚在 Windows 上到底怎么解、怎么改、怎么包回去。1. 解包打包到底在做什么1.1 RK 固件的基本构成RK 系列芯片RK3288、RK3399、RK3568、RK3588 等的官方固件通常是以一个完整的 update.img 形式发布。这个 update.img 不是单一的文件它更像一个“收纳箱”里面装着许多独立的分区镜像。每个分区负责不同的功能常见的分区名和作用包括分区常见文件名主要作用Loader无固定名称引导加载程序负责初始化硬件和加载内核Parameterparameter分区表定义告诉芯片每个分区的起始地址、大小和名称Ubootuboot.imgU-Boot 引导程序硬件初始化和启动内核的入口Bootboot.img内核和 ramdisk系统启动的核心镜像Recoveryrecovery.img恢复模式镜像用于恢复出厂和系统更新Systemsystem.imgAndroid 系统主体预装应用、框架、系统库都在这里Vendorvendor.img厂商定制分区存放厂商私有的库和配置Miscmisc.img启动标志区域记录系统启动模式和 OTA 相关数据当你拿到一张官方固件时你看到的是 update.img 这个“整包”。要做定制化修改第一步就是把它解开把里面各个分区的镜像提取出来。对应的当你修改完分区镜像还需要把修改后的分区重新装回 update.img 的“收纳箱”这个过程就是打包。1.2 RKDevTool 在整条链路里的角色这里需要先把工具角色捋清楚很多人把 RKDevTool 当成能直接解包 update.img 的软件实际上它和“解包打包”是两个不同的环节。RKDevTool 的核心身份是烧录工具它负责通过 USB 把固件写到设备的存储介质里。设备上电时按住 Recovery 键进入 Loader 模式或者 MaskRom 模式电脑上打开 RKDevTool选择要烧录的固件文件点击执行它就把镜像写入设备。也就是说RKDevTool 的主要工作是“把固件灌进设备”而不是“把固件拆开看内容”。那标题里的“RKDevTool 解包和打包”到底是什么意思实际场景中有两种理解用 RKDevTool 的“备份”功能把设备当前运行的分区镜像备份到电脑再修改备份出来的分区镜像用 RKDevTool 官方发布时附带或社区常用的固件工具如 afptool、imgRePackerRK 等对 update.img 做解包和打包。我平时在 Windows 下的完整流程是用 RKDevTool 做刷机和备份用配套的固件工具做解包和打包两者配合完成整条链路。这篇文章主要讲后者的具体操作。1.3 为什么要在 Windows 环境下操作Linux 环境下解包 RK 固件有很多现成脚本但对绝大多数开发者来说日常工作环境就是 Windows。Windows 下做这件事的难点在于工具链相对零散官方文档也不够直观。不过实际用下来Windows 完全够用关键是选对工具、走对流程。在 Windows 上折腾这套东西适合的人主要是这几类嵌入式开发工程师需要在固件里预装应用、修改系统配置做 RK 方案产品的硬件厂商技术支持需要排查现场设备问题玩家和爱好者想给自己的 RK 盒子刷入精简系统或个性化固件。无论哪类人群核心诉求都是同一件事在不改底层代码的情况下把官方固件调整成自己需要的样子。2. 环境准备与工具组合2.1 驱动安装是第一步在 Windows 上操作驱动永远是最容易踩坑的第一关。RK 设备进入 Loader 模式后电脑设备管理器里会识别到一个未知设备这时候如果驱动没装好RKDevTool 就永远显示“未发现设备”。驱动安装的步骤如下下载 Rockchip 官方驱动 DriverAssitant解压后运行 DriverInstall.exe先点击“驱动安装”如果之前安装过旧版本建议先“驱动卸载”再重新安装把设备用 USB 线连接电脑按住设备上的 Recovery 键不放再上电等电脑右下角提示新硬件打开设备管理器确认“设备管理器 - 通用串行总线控制器”下能看到 Rockchip USB 设备相关的条目。驱动安装这一步没有太多技巧就是按顺序装很多人卡住是因为设备没有真正进入 Loader 模式电脑识别不到硬件驱动装了也没意义。确认设备模式的技巧是进入 Loader 模式后设备通常不会正常启动系统屏幕可能黑屏或停在 Logo这是正常的。2.2 工具清单不只是 RKDevTool 一个文件我在 Windows 下完成解包打包实际用到的工具清单如下工具作用说明RKDevTool刷机、备份、连接设备官方工具界面为中文DriverAssitantUSB 驱动官方工具刷机前必须安装afptool解包/打包 update.img命令行工具负责处理镜像内部的固件文件imgRePackerRK 或类似图形化工具解包/打包 update.img封装了底层命令适合不太熟悉命令行的朋友7-Zip查看和提取部分分区内容有些分区镜像能被 7-Zip 直接打开如 recovery.img 内部结构Notepad 或 VS Code修改 parameter 文件、脚本文件不要用 Windows 自带记事本容易把 LF 换行改成 CRLF十六进制编辑器HxD 等检查镜像头部信息、修改二进制内容排查问题时非常有用这里特别说一下 afptool 和 imgRePackerRK 这类工具。它们和 RKDevTool 是什么关系早期 Rockchip 官方在发布 RKDevTool 时会附带一个工具包里面包含固件解包打包的命令行程序后来不同版本的发布包内容有差异加上社区不断优化出现了一批图形化封装的工具。这些工具的底层逻辑是一致的解析 update.img 的文件头按偏移量把里面的分区镜像提取出来或者反向操作把分区镜像合并回 update.img。工具版本混乱是 Windows 上最容易遇到的问题。我的建议是优先找你手里的开发板或者设备对应 SDK 发布包里自带的工具其次再考虑通用的社区版本。不同芯片平台的固件格式虽然有差异但 RK 系列整体上兼容性做得不错网上的通用工具多半能用但真要大批量生产还是用原厂配套工具最稳。2.3 固件类型先分清动手解包之前要确认你手上的固件是哪种类型。RK 固件常见的有两种update.img完整固件包包含 loader、parameter 和全部分区镜像通常用于 RKDevTool 的“升级固件”功能单独的分区镜像如 boot.img、system.img这类文件不能直接用 RKDevTool 的“整体升级”刷入但可以用 RKDevTool 的“单独烧录”功能按分区地址分别写入。解包操作针对的是 update.img单独分区镜像可以直接用其他工具进行修改不需要走解包流程。认清这个区别可以省很多事。3. 实操Windows 下解包完整流程3.1 第 1 步检查固件基本信息在解包前我习惯先核对固件的基本信息避免后面解出问题还不知道原因。用十六进制编辑器打开 update.img正常 RK 固件头部会有明显标识。主要看几个点固件头部是否包含 KEY 字段Rockchip 的固件通常在头部写入了“RKFS”之类的标识固件大小是否与正常文件一致下载不完整的固件解包基本会失败固件来源是否可信生产环境建议使用原厂发布版本不要使用来路不明的整合包。这些检查可能看起来多余但实际工作中我遇到过很多次“解包失败”的反馈最后定位下来都是下载固件不完整或者文件名被网页下载器篡改导致了文件损坏。3.2 第 2 步用命令行工具解包 update.img在 Windows 下我常用的解包方式是命令行工具 afptool。假设你的固件文件叫 update.img放在 D 盘的 rk 目录下打开命令提示符cmd进入对应目录后执行afptool -unpack update.img out_dir其中 out_dir 是你指定的输出目录用来存放解包出来的分区镜像。命令执行后工具会把 update.img 里所有分区镜像释放到这个目录里同时生成一个 parameter 文件。如果你的工具包名称不同常见命令可能是afptool -unpack update.img然后工具默认解包到当前目录下的 out 文件夹。不同版本的参数略有差异可以先用afptool -help查看帮助确认。如果不想用命令行也可以选择图形化工具。将 update.img 拖拽到 imgRePackerRK 的窗口工具会自动识别固件结构点击“解包”按钮几秒钟后就能得到解包目录。3.3 第 3 步认识解包产物解包完成后进入输出目录你会看到一堆文件。第一次看到这些文件的人往往会懵这里列一下典型的解包产物文件说明parameter分区表定义文件纯文本记录了整个存储空间的分区布局boot.imgLinux 内核与 ramdisk 的打包镜像recovery.img恢复模式镜像system.img系统分区镜像可能非常大几百 MB 到几 GBvendor.img厂商定制分区镜像部分方案有misc.img启动标志分区uboot.imgU-Boot 引导镜像loader.bin / resource.img 等固件使用的中间层资源文件这些文件里面我平时改得最多的是 system.img、vendor.img 和 parameter。system.img 是 Android 系统主体预装应用一般都放这里vendor.img 放厂商私有组件很多时候驱动和系统库在这里parameter 则影响着整个存储分区布局改错了一个数字都可能导致设备变砖。3.4 第 4 步修改分区镜像的常用方法拿到 system.img 之后怎么往里面加应用这一步就不仅仅是“解包”的问题了而是涉及 Android 系统的镜像处理。system.img 在 RK 平台上大多数是 ext4 文件系统格式。在 Windows 下要直接编辑 ext4 镜像办法不多我常用的是这几种用支持 ext4 的磁盘挂载工具如 Linux Reader、Paragon ExtFS 等把 system.img 挂载成虚拟磁盘然后像操作普通磁盘一样读写文件用 7-Zip 直接打开 system.img它能够识别 ext4 的目录结构文件也可以提取出来但往镜像里写入文件的能力有限如果只是添加一个 apk在熟悉 Android 系统目录结构的前提下很多场景可以把 apk 放到系统的预装应用目录然后重新打包镜像。这里要特别提醒解包出来的 system.img 如果直接用 7-Zip 提取 APK 再塞回去很容易损坏镜像的权限和 ownership 信息。Linux 下的系统权限、SELinux 上下文、符号链接Windows 工具不一定能完整保留。我自己的习惯是能用 imgRePackerRK 这类工具处理的轻量调整在 Windows 上做涉及大量文件操作的还是建议在 Linux 或 WSL 里挂载镜像改改完再拷到 Windows 上打包。3.5 用 RKDevTool 备份设备当前固件除了对官方 update.img 解包还有一种常见需求是“备份设备当前系统”。操作方法是设备进入 Loader 模式打开 RKDevTool切换到“高级功能”或者“备份”标签页选择要备份的分区点击备份。工具会把设备上对应分区的内容读取到电脑存成镜像文件。这个功能在什么场景下有用比如你拿到一台已经刷好系统的设备想要研究它的系统镜像但没有原厂 update.img或者你在设备上做好了系统配置想把当前系统备份为镜像批量部署到其他设备上。这种情况下用 RKDevTool 备份出来的分区镜像反过来也能作为解包修改的对象。需要注意的是备份前设备存储介质要处于良好状态备份过程中不要断开 USB 连接否则得到的镜像可能不完整烧回其他设备时可能直接无法启动。4. 实操Windows 下重新打包4.1 打包前的文件检查修改完分区内容后就要准备把修改后的文件重新封装成 update.img。这一步看似简单实则有很多细节决定成败。打包前我通常会做一轮检查确认修改后的分区镜像大小正常不会出现系统分区镜像比 parameter 定义的分区还大的情况确认 parameter 文件没被改出语法错误分区起始地址要连续不能重叠确认镜像文件权限和 SELinux 上下文没有被破坏如果之前在 Windows 下做过大量文件操作确认保留了解包出来的 loader 和 uboot 等引导文件没有动过它们。4.2 用命令行工具打包打包命令和解包是相反的。以常用的 afptool 为例假设你解包后的文件都放在 out_dir 目录下在 Windows 命令提示符中执行afptool -pack out_dir update_new.img工具会遍历 out_dir 目录中的文件根据 parameter 定义的分区表把各个分区镜像按顺序封装成一个新的 update.img。图形化工具的打包同样很简单解包后修改文件再拖回到工具窗口点击“打包”生成新的 update.img。这里有一个非常容易踩的坑很多社区工具打包出来的 update.img 不能直接用于 RKDevTool 的“升级固件”模式。原因是完整整包升级需要校验固件头部的 loader 信息如果你的打包工具没有正确处理 loader 部分固件烧录时会提示找不到 loader。我碰到这个问题时通常的解决办法是用 RKDevTool 的“导入”功能手动指定 loader 路径或者在打包时选择“包含 loader”选项。4.3 打包后校验与刷回设备打包完成后不要急着往设备上刷。先做校验对比新固件和解包前原固件的文件大小如果差距异常比如从 1GB 变成几十 MB基本就是打包配置错了用十六进制编辑器打开新固件检查头部是否有有效的固件标识有条件的话在虚拟机或者备用设备上先刷一次确认系统能够正常启动再部署到正式设备。刷回设备时打开 RKDevTool固件选择新打包的 update.img设备进入 Loader 模式后点击“执行”。烧录过程第一次会格式化设备存储分区视固件大小等待一段时间完成后设备自动重启。我第一次打包后刷机遇到了系统起不来的情况。排查到最后原因是我在 Windows 下用 7-Zip 往 system.img 里加了一个 APKAPK 的 SELinux 上下文没有设置系统启动时直接拒绝加载导致进入不了桌面。后来我在 WSL 里用setfattr补上上下文重新打包刷入问题就解决了。这个经验供大家参考。4.4 单独分区的打包思路有些场景不需要整个 update.img 打包只需要处理单个分区镜像。比如你只是改了 boot.img 里的内核参数或者只修改了 resource.img 里的开机 Logo那完全没必要重新打包 update.img。直接用 RKDevTool 的分区烧录功能把修改后的单个分区镜像按 address 写入对应分区即可。具体参数可以在 parameter 文件里查到。打开 parameter能看到类似下面的内容CMDLINE: mtdpartsrk29xxnand:0x000020000x00002000(boot),0x000020000x00004000(recovery),0x000100000x00006000(backup),0x000400000x00016000(cache),0x001000000x00056000(system),0x000080000x00156000(metadata),0x000200000x0015e000(vendor),0x000200000x0017e000(misc),0x000008000x0019e000(uboot),0x000010000x001a0000(resource),0x000400000x001a1000(private)offset 和 size 以 512 字节为扇区单位计算一下就能得到每个分区在存储介质上的起始扇区和长度。在 RKDevTool 的“下载镜像”标签页里填上分区起始地址选择对应的分区镜像就可以单独烧录了。我经常用这个功能来做快速验证只改了一个 APK就单独烧录 system 分区几十秒完成重启比整包刷写省时间得多。5. 高频问题与排查实录5.1 RKDevTool 显示“未发现设备”这是讨论度最高的问题绝大多数情况不是工具坏了而是设备没有正确进入 Loader 模式或者驱动异常。排查步骤按顺序走确认设备确实进入了 Loader 模式。RK 设备进入方式一般是按住 Recovery 键再上电不同设备可能略有差异打开设备管理器查看“通用串行总线控制器”下有没有 Rockchip USB 设备。如果没有换一根数据线很多 USB 线只能充电不能传输数据、换一个 USB 口优先使用主板后置 USB 2.0 口如果设备管理器里是黄色感叹号右键更新驱动手动指定到 DriverAssitant 安装目录有些设备上电后直接进入系统而不进入 Loader因为 Recovery 模式下系统的引导策略不同需要检查是否按住了正确的按键。经验之谈RKDevTool 对 USB 口的兼容性有时候很奇怪同一个设备换个 USB 口就好了原因不明但实测有效。另外Windows 10/11 的新版本系统有时会阻止未签名驱动的安装需要临时禁用驱动程序强制签名或者在高级启动选项里选择相应模式。5.2 解包时报错或解出来的内容不完整解包报错基本离不开三个原因固件文件损坏、工具版本不匹配、路径问题。固件文件损坏重新下载固件用哈希校验工具核对 SHA256 值工具版本不匹配部分新芯片平台的固件结构有调整老版本的解包工具可能解析不了。解决办法是找对应芯片平台的 SDK 配套工具路径问题Windows 下常见固件文件路径或输出目录里如果包含中文字符、空格、特殊符号某些命令行工具在解析路径时可能出错。我的习惯是统一放在D:\rk_tools这类纯英文路径下操作。还有一种情况是解包正常但解出来的 system.img 无法打开。这种大多是因为 system.img 内部还有一层 ext4 的 sparse 格式或加密处理。RK 平台的 system.img 多数是裸 ext4 或者带 sparse 标识的 ext47-Zip 通常能识别但个别固件会对分区镜像做压缩会看到类似system.img的文件实际上是一层 gzip 压缩包先解压才能看到 ext4 镜像。5.3 打包后固件刷不进去打包后刷不进去现象通常是 RKDevTool 执行到一半报错或者直接提示 Loader 不匹配。处理思路确认打包过程中没有替换或丢失 loader 相关文件。很多打包工具如果目录下缺少 loader 文件会自动跳过导致生成的固件没有引导程序如果提示 Loader 版本不匹配可以在打包时使用原固件的 loader或者把 RKDevTool 的 loader 设置为“使用固件内的 loader”有些较新的 RK 方案对固件做了签名校验直接改分区内容会导致签名失效这种情况下需要关闭签名校验或者使用对应方案的签名工具重新签名。这里多说一句目前很多 RK 的方案在量产固件里已经加入了安全启动机制。如果你的固件带有签名解包打包后不重新签名设备会拒绝启动或者拒绝刷入。普通爱好者手里的开发板固件一般没开这个但行业设备的量产固件经常会遇到。5.4 刷完系统无法正常启动这是打包后最常遇到的问题表现五花八门卡在 Logo、无限重启、黑屏但设备管理器能识别到设备。从我的经验看按概率从高到低排序系统分区写满了分区镜像大于 parameter 里定义的分区大小数据被截断修改文件时破坏了 SELinux 上下文或文件权限特别是 system 分区里的应用和框架文件parameter 被改错分区表与实际镜像内容不匹配某些分区起始地址出问题boot.img 的内核和 ramdisk 在解包打包过程中丢失了部分文件导致内核无法加载设备里的旧数据没有完全清除系统启动时读取了残留的旧配置。排查方式先尝试用原厂固件刷回确认设备本身没问题再用只修改一个变量的方式做对照实验比如只解包打包不改任何内容刷回去看能不能正常启动。如果解包打包原封不动都能启动失败那打包工具或打包参数有问题如果原样打包没问题再把自己做的修改一点点加回来定位到具体是哪一个文件导致的问题。6. 一些经验和提醒做固件解包打包这件事技术上并不算特别难真正难的是对各种异常情况的处理。有几个体会想写在这里算是给后来人的提醒。6.1 对自己负责备份永远不能省不管是要给设备解包、打包还是刷入自行定制的固件在动手之前如果能通过 RKDevTool 备份原始固件或至少备份重要分区那就一定要备份。设备变成砖虽然大多数情况下可以通过 MaskRom 模式重新刷回来但有些设备一旦进入 MaskRom 模式刷机方式就和 Loader 模式不同操作复杂度会提高。另外刷机会清空设备上的数据量产设备上如果有测试数据、配置文件刷机前要提前导出。我不止一次看到有同事刷完机回来找数据这种损失真的无法挽回。6.2 稳定环境很重要尽量用固定的工具组合解包打包工具版本很杂不同工具混用容易出现各种莫名其妙的问题。我的做法是确认一个可用的工具组合后就把这套组合固定下来。比如我在做 RK3568 平台的固件定制时长期使用 RKDevTool V2.96 搭配配套的打包工具除非遇到兼容性问题否则不随意更换。每换一个工具版本都要先做一次“解包后不修改直接打包”的基准验证。这个验证能帮你排除大量工具本身导致的问题也能确认当前工具环境是健康的。6.3 留下完整的操作记录固件解包打包尤其是做批量部署用的固件时我建议记录下每次的修改内容。我自己会建一个简单的修改记录表记录内容包括固件名称和来源解包用哪个工具、哪个版本修改了哪些分区、添加了哪些文件打包用哪个工具、哪个版本刷机后测试结果。有这份记录后续出现问题的时候可以快速回溯不用重新排查一遍。6.4 合规使用固件内容最后提醒一点固件里往往包含厂商的私有代码、系统组件和授权资源解包打包出来的内容最好仅用于自己的学习研究、内部测试或已经获得授权的项目。不要随意传播修改后的固件避免引发版权和授权问题。对于商用设备建议通过正规渠道和厂商获取固件定制支持这样既能够得到技术保障也不会埋下合规隐患。固件定制这条路越是深入越觉得细节决定成败。希望这篇文章能帮你把 Windows 下用 RKDevTool 解包和打包的流程跑通少走一些我当年走过的弯路。如果后面遇到具体的报错信息不妨把工具版本和固件型号一起列出来排查很多时候答案就在细节里。