上个月调试一块RK平台的板子eMMC里残留了一份旧系统RKDevTool每次都提示烧录成功断电重启却还是老系统。反复折腾了一下午最后靠MaskROM模式下的强制低格才彻底解决。这个经历让我想把双平台烧录eMMC的一些高阶玩法整理出来。如果你平时只把RKDevTool当成选个镜像点开始的傻瓜工具或者刚切到Linux环境面对Upgrade_Tool觉得无从下手这篇文章值得看完。文章核心围绕Rockchip平台的eMMC烧录场景覆盖Windows图形工具和Linux命令行工具搭配使用的思路以及5个能实打实提升效率和成功率的技巧适合做嵌入式开发、测试和维护设备的工程师参考。1. 烧录前的认知铺垫工具分工、工作模式与固件构成1.1 两个工具的本质关系和选择逻辑RKDevTool是Rockchip在Windows上提供的图形化烧录工具Upgrade_Tool是官方配套的Linux命令行工具。很多人以为后者是前者的替代品其实两者底层走的是同一套USB烧录协议只差在交互形式。选择哪个取决于你当前处于什么工作场景。我的习惯是日常开发调试、临时刷个固件用RKDevTool最省事。图形界面把设备枚举、分区加载、烧录进度都展示得很直观鼠标点几下就能完成。但一旦遇到批量刷机、无人值守、需要集成到自动化测试流程的时候RKDevTool就显得力不从心。这时候Upgrade_Tool才是正主它能放进shell脚本能通过SSH远程执行还能把输出重定向到日志文件这些能力在产线场景中是刚需。容易被忽略的一点是RKDevTool虽然只提供Windows图形界面但它的配置文件、分区列表逻辑和Upgrade_Tool的分区定义是共通的。在Windows上调试好的分区方案切换成Linux命令行时几乎可以无缝平移。这就意味着你在熟悉的环境里把流程跑通然后写一套脚本两边的工作量不会白费。1.2 Loader模式与MaskROM模式搞懂这个才能谈高阶操作烧录之前先要搞懂设备的两种引导模式。Loader模式是板卡上的引导loader还能正常跑起来时进入的烧录模式。最常见的进入方式按住板子上的RECOVERY恢复键不放再插入USB或者重新上电系统里就能看到对应的Rockchip设备。这种模式适用于绝大多数正常烧录场景只要loader没有被破坏都可以用它完成刷机。MaskROM模式则是芯片内部固化ROM引导出来的烧录模式常被称为短路模式或救砖模式。当eMMC里的loader已经损坏、分区表混乱、甚至整块eMMC是空白状态时Loader模式根本进不去但芯片内部的ROM代码依然在监听USB等待宿主下发指令。这时候只有MaskROM模式能救设备。进入MaskROM通常需要短接eMMC的CLK引脚到地或者短接板子上标注的测试点具体位置因板卡而异需要查对应硬件手册。这里有一个很多人不了解的点给eMMC做完整低格大部分情况下要求设备处于MaskROM模式而不是Loader模式。原因后面技巧一会详细说。1.3 认识固件包update.img和分区镜像的区别不少初学者把固件理解成一个文件操作上也确实只拿一个update.img做整包烧录就够了。但从高阶玩法的角度看必须理解update.img内部由多个分区镜像组成loader、parameter、boot、kernel、resource、misc、system、recovery等它们各有分工。为什么要强调这个因为实际工作中频繁刷整包既浪费时间也容易引入干扰。举个例子你只是改了一个内核驱动整包烧录意味着要把system分区几百MB重新写一遍还要在分区切换时承担写入失败的风险。按需刷单个分区效率和安全性都好得多。分区名常见镜像文件主要用途loaderloader.img一级引导加载器parameterparameter.txt分区表定义文件bootboot.imgLinux内核与设备树kernelkernel.img内核镜像部分平台resourceresource.img资源文件、设备树部分平台miscmisc.img系统切换标记systemsystem.img根文件系统recoveryrecovery.imgAndroid恢复系统这张表在不同方案里有增减但核心逻辑一致分区名对应镜像内容parameter.txt决定分区布局。后面技巧二围绕它的可玩性展开。2. 技巧一MaskROM强制低格专治刷不进、刷完还是旧系统的顽固板子2.1 为什么普通烧录治不了根常规烧录流程是通过Loader或MaskROM建立通信把分区表和各分区镜像逐个写入eMMC的User Data Area。但这里有个很多人没注意到的盲区——eMMC除了用户数据区还有Boot Area Partitionboot0/boot1和RPMBReplay Protected Memory Block等特殊区域。普通烧录过程中bootloader会被正常写入用户可见区域但历史残留数据并不会被完整擦除。我举个实际案例。一块板子上一版固件用A分区方案新固件改动了分区表大小。直接烧新固件时工具反复报错排查到最后才发现是eMMC里旧的分区表残留和新parameter冲突。换成MaskROM模式下的强制低格把整块eMMC物理清干净再重新烧一次就过了。当你遇到以下现象优先考虑低格而不是反复重试同一套烧录流程烧录工具在写分区表阶段反复报错烧录过程提示成功但重启后系统仍是旧版本从A厂商固件刷成B厂商固件后出现莫名启动失败eMMC之前被其他工具、其他平台写乱过无法确定状态2.2 RKDevTool下如何正确低格Windows端的操作先把设备驱动装好推荐用Rockchip官方DriverAssitant。这里有个细节Windows 10/11安装驱动偶尔会遇到签名问题需要临时禁用驱动强制签名装完后记得恢复。设备进入MaskROM模式后打开RKDevTool正常情况下主界面会检测到设备。低格操作一般藏在高级功能或存储相关页签里不同版本菜单位置略有差异但核心逻辑一致点击低格或擦除eMMC等待工具完成擦除。完成后切回升级固件页恢复正常烧录流程。这里必须强调一个词断电禁止。低格过程中一旦断电或拔出USBeMMC可能处于半擦除状态反而更难救。执行前确认供电稳定用质量好的USB线别用又长又细的充电线凑合。这块我踩过亏烧到一半线松了板子直接变砖最后靠短接测试点进MaskROM才救回来。2.3 Upgrade_Tool的低格与验证Linux下低格操作思路一致只是把点按钮换成了敲命令。使用Upgrade_Tool前需要确认设备权限通常会直接加sudo或者写一条udev规则让普通用户也能访问设备节点。# 查看设备是否被识别 sudo ./upgrade_tool ld # 执行低格/擦除eMMC不同版本命令名可能不同 sudo ./upgrade_tool lf eMMC不同版本的Upgrade_Tool对低格命令的命名不完全一样有的版本是菜单式交互执行时留意输出里是否出现erase或low level format关键字。如果当前版本不支持这个命令跑一下sudo ./upgrade_tool --help查清楚再动手。低格完成后我习惯紧接着烧一遍完整update.img而不是只刷某个分区。原因是低格后的eMMC完全干净这时整包烧录能确保新分区表干干净净落盘。烧完顺手再用工具读一下设备信息确认分区已经重新建立。注意低格是破坏性操作会清空eMMC上的所有数据包括量产校准参数、序列号、设备证书等。操作前务必确认这些数据是否已经备份。产线场景尤其要小心别把整批设备的校准数据全抹了。3. 技巧二按分区烧录只刷你需要改的那一块3.1 分区烧录能省时间的场景分区烧录在开发阶段特别实用。调试内核改了个驱动整包烧录几百MB不值当想调整设备树里的外设配置单独重写resource分区就行U-Boot更新了新版本单独刷loader分区就够。对每天反复编译验证的开发者来说按分区烧录节省的不只是时间还降低了频繁整包烧写对eMMC寿命的消耗。分区烧录也能帮定位问题。系统启动异常时我倾向于先只刷uboot和kernel分区保留system分区不动。这样能快速判断异常到底出在引导阶段还是文件系统阶段而不是一把梭整包重烧把所有现场都抹掉后面想定位都无从下手。3.2 RKDevTool中配置分区列表Windows端RKDevTool在升级固件页里通常有一个可编辑的分区列表默认加载的是update.img解出来的完整分区配置。想只烧某个分区只要在列表里勾选对应行并指定镜像文件路径。这些配置最终会落到工具目录下的config.ini文件里。典型内容类似[LIST] 00x000020000x00004000,uboot,uboot.img 10x000020000x00006000,misc,misc.img 20x000100000x00008000,boot,boot.img格式大致是偏移长度,分区名,镜像路径。如果对格式不熟悉不建议手写这个文件。我实际操作时的做法是先加载完整update.img让列表自动生成然后删掉不需要的分区行只保留要刷的分区再勾选执行。这样比手写配置稳妥得多。有个细节容易踩坑分区名必须和parameter.txt里定义的一致。如果改了名字烧录时可能报错甚至写进去后系统找不到对应分区启动直接失败。所以改配置前先打开parameter.txt对照一遍。3.3 Upgrade_Tool的命令行分区写入Linux端的分区烧录命令更直接# 写uboot分区 sudo ./upgrade_tool di -b uboot.img # 写kernel分区 sudo ./upgrade_tool di -k kernel.img # 写resource分区 sudo ./upgrade_tool di -r resource.img # 更新parameter分区表 sudo ./upgrade_tool di -p parameter.txt不同版本参数可能有差异但di表示download image这个大方向是一致的具体以--help为准。单独烧分区时有个非常容易载的坑目标分区必须已存在且大小足够。如果parameter.txt里定义的分区尺寸比新镜像小写入会失败或产生越界错误。所以我在单独烧录前会先确认parameter分区表没有变化。如果分区表变了必须先更新parameter再按新分区表烧镜像顺序绝对不能反。4. 技巧三脚本化批量烧录把重复刷机交给命令行4.1 为什么批量场景必须脚本化如果你只需要烧一块板子手动敲命令或点界面都无所谓。但当你面对二十块、五十块板子或者每块板子烧完还要自动记录序列号、输出产测日志时手动流程完全撑不住。批量产线的核心诉求是稳定、可重复、可追溯命令行脚本天然适合干这件事。Linux环境还能配合SSH远程操作开发人员不必坐在产线机器前。有些团队甚至把烧录流程集成到CI/CD系统里固件构建完自动触发烧录验证。RKDevTool虽然也支持一些命令行参数但跨平台、可集成能力明显不如Upgrade_Tool。4.2 一个可落地的刷机脚本示例下面是我在产线实际使用的批量烧录脚本简化版逻辑很直白检测设备、烧录、复位、落日志。#!/bin/bash set -e IMG_PATH/opt/images/update.img LOG_DIR/var/log/rk_flash_logs mkdir -p $LOG_DIR flash_one() { local serial$1 local stamp$(date %Y%m%d_%H%M%S) local logfile$LOG_DIR/flash_${serial}_${stamp}.log echo [$stamp] start flashing $serial | tee -a $logfile # 烧全量固件 sudo ./upgrade_tool uf $IMG_PATH $logfile 21 local ret$? if [ $ret -eq 0 ]; then echo flash success $serial | tee -a $logfile else echo flash FAILED $serial, ret$ret | tee -a $logfile return 1 fi # 复位设备 sudo ./upgrade_tool td $logfile 21 sleep 2 echo reboot done | tee -a $logfile } if [ $# -lt 1 ]; then echo usage: $0 serial exit 1 fi flash_one $1脚本本身不复杂真正重要的有两点。第一每台设备一个独立日志文件序列号和时间戳都体现在文件名里后续追溯问题非常方便。第二所有命令的退出码都要检查set -e能帮助在第一条失败命令处停下来避免出错后继续往下跑最后误报成功。4.3 USB HUB与多设备选择一个容易忽略的并发限制用Upgrade_Tool刷多台设备时有个限制容易被忽略同一时间它通常只认一台设备。如果你的电脑通过USB HUB同时挂着好几块板子直接跑脚本可能会报错甚至刷到错误的目标上。我的做法有两种。第一种是串行物理隔离使用带独立电源开关的USB HUB脚本每轮只开启一个通道刷完一块再开下一块。这是最笨但最可靠的方式绝不出错。第二种是按设备编号指定如果工具版本支持通过ld返回的设备列表选择目标脚本可以根据参数指定操作哪一台。这种方式对工具版本有要求我在产线上更信任物理开关隔离。另外提醒一句一拖多USB HUB供电是大坑。eMMC烧录过程中电流波动明显供电不足会导致设备在写入中段掉线表现就是固定百分比必失败。尽量选带外部供电的HUB线材要短、要粗不要用那种一盘几十米的细线。5. 技巧四读日志和返回码问题定位别靠玄学5.1 从RKDevTool日志窗口里能看到什么很多人用RKDevTool只盯着进度条烧卡住了就换线、换镜像、重新拔插靠玄学排查。实际上工具界面的日志区域会打印一长串通信过程仔细读能判断卡在哪个环节。典型的日志顺序类似这样版本不同细节有差异Loading firmware... Downloading loader... Reset device... Downloading parameter... Downloading boot...如果日志反复停在Downloading loader...说明设备在加载loader阶段就不稳定多半是驱动问题、线材问题或者loader镜像本身不匹配。如果卡在分区写入阶段更可能是分区表尺寸或eMMC物理状态有问题。日志就是在告诉你我走到哪一步了这是排查的定位器。还有一个技巧即使Windows图形工具底层打印和Linux工具也是同源的很多关键报错信息能互相参照。所以不要只在一个平台上积累经验两边的日志都看看往往能提供互补信息。5.2 Upgrade_Tool的输出与返回码Linux命令行最方便的一点是一切皆可解析。每次执行upgrade_tool脚本可以用$?直接拿到返回码输出文本也可以重定向到日志文件。实际项目里我不只看返回码是0还是非0还会看输出里有没有ERROR、failed、timeout这类关键字。以下是几个典型的异常状态对照输出/返回状态可能原因建议处理方式设备未找到没进Loader/MaskROM、USB识别失败检查模式、线材、驱动或权限loader下载失败loader镜像与芯片不匹配、供电不稳更换loader、换线、检查供电分区写入越界parameter分区表与镜像不匹配先刷parameter再刷分区超时/设备丢失USB连接不稳、eMMC异常换短粗线、低格后重试不要盲目认为返回码非0就是固件坏了。从我统计的情况看烧录失败中USB物理链路问题占了很大比例真正的eMMC坏块反而少见。所以每条失败都要先排除连接问题再去怀疑镜像和硬件。5.3 一次真实失败定位过程分享一次真实的排查经历。有块板子烧录到约40%时必现失败我换了三根USB线、两个镜像文件都没用。后来把日志重定向到文件里仔细对比发现失败总是发生在写入system分区中段并且每次失败前的最后一条日志都是bulk write error。根据这条线索我判断问题大概率不在镜像内容而在数据链路的稳定性。最后排查出是电脑前置USB口老化换到主板后置USB口后问题消失。如果一开始只盯着固件和工具版本折腾这个坑能踩一整天。这件事教会我异常必现时先把日志慢速读一遍比盲目重试高效得多。6. 技巧五双平台交叉校验防止刷完假成功6.1 为什么要做交叉校验很多人认为烧录工具提示成功就是真的成功。但实际工作中由于USB传输偶发错误、eMMC缓存写入策略、工具对校验结果的处理差异偶尔会出现工具报告成功但实际数据并不一致的情况。更隐蔽的是有些问题不会立刻爆发而是设备使用一段时间后才暴露出来。交叉校验的核心思想是不把鸡蛋放在同一个篮子里。Windows刷完Linux再读一遍关键分区做哈希比对或者反过来。两个平台、两套驱动链路同时出错的概率要低得多。对于出货产品来说这一道额外校验能拦截掉大量隐性返工。6.2 切实可行的校验手段最简单有效的校验是回读关键分区并比对哈希。Linux端Upgrade_Tool通常提供读取设备信息或分区的功能基本用法# 读取设备信息和当前状态 sudo ./upgrade_tool ld # 回读boot分区内容到本地不同版本命令有差异 sudo ./upgrade_tool rd -b boot.img读回来的boot.img和本地镜像做一次md5sum对比一致说明这条链路的数据传输没有问题。Windows端也能用RKDevTool的读取功能导出分区数据再做同样比较。第二种校验是从系统层面验证。刷完镜像让设备正常启动进入系统后用dmesg看内核启动日志用cat /proc/cmdline看启动参数用mount检查根文件系统挂载情况再和镜像内容做对应。这个办法不依赖烧录工具能直接从能否正常引导这个最终结果反向验证烧录是否成功。我个人的实践组合是产线用脚本化回读加哈希比对做主流程开发阶段用启动日志检查做辅证。两道关卡都过了再谈批量出货或者继续下一轮开发。7. 烧录高频坑位与完整排查链路7.1 设备枚举不到这是最常见的坑。排查顺序我固定为先确认设备到底有没有进入Loader/MaskROM模式看电源指示灯、串口打印这些硬件层面的信号再检查USB口、线材是否可靠最后查驱动和权限。Windows下打开设备管理器如果出现未知设备或带感叹号的Rockchip设备优先重装驱动并确认驱动签名问题已处理。Linux下用lsusb查看有没有Rockchip对应的VID/PID如果没有回头查硬件连接别急着装什么依赖包。7.2 烧录中断与卡死烧录过程中断通常绕不开供电和线材两个因素。eMMC烧录的瞬时电流不小线材过长会带来压降设备在写入关键区域时掉电表现就是固定百分比必失败。另一个容易被忽略的点是USB口自身供电能力不足尤其笔记本的某些便携HUB口。遇到这种情况建议先换带屏蔽的短粗线优先插主板后置USB口。如果开发板支持独立电源尽量用独立电源供电。重试仍然失败再考虑低格和换镜像。这个顺序不要反过来否则可能白折腾半天。7.3 刷完启动黑屏或反复重启刷完不能正常启动时不要急着重刷整包。先看一眼启动打印。完全没有打印重点检查loader有没有刷进去以及eMMC里boot分区是否正常启动打印卡在kernel阶段大概率是内核镜像和设备树不匹配优先重新烧boot或resource分区。还有一类隐蔽问题板子上原来有量产数据新镜像分区表改动后RPMB区域的数据没清理导致安全校验失败。这种问题重烧整包也没用低格后通常能解决。回到开头说的那块板子它最终就是通过MaskROM低格加点耐心活过来的。双平台烧录说到底只有一个原则对烧录结果保持怀疑直到验证通过。RKDevTool和Upgrade_Tool都只是工具真正让项目稳定的是对模式、分区表、日志、校验这些底层逻辑的理解。我后来在产线把脚本化烧录、回读校验、日志归档这套流程全跑通后返工率降了不止一半。你再遇到刷不进、刷完起不来的问题建议把心态从换个镜像再试试转成先看清楚卡在哪一步、为什么卡。好的工具加上正确的排查思路比手里多囤几个固件版本管用得多。