1. 项目缘起一次看似简单的固件升级最近在折腾一块基于瑞芯微RV1126芯片的开发板核心任务是给它升级固件。这听起来是个常规操作对吧无非就是找个烧录工具选好镜像点一下“升级”按钮。但实际情况是从准备镜像、选择升级模式到处理升级过程中的各种“幺蛾子”每一步都可能藏着坑。RV1126作为一款面向视觉AI应用的SoC其固件升级流程相比一些简单的MCU要复杂得多它涉及到Bootloader、分区表、内核、文件系统等多个层面的协同工作。我这次的目标不仅仅是把新固件刷进去更是要彻底搞清楚整个升级链路的来龙去脉以及当升级失败时如何通过有限的调试手段比如串口快速定位问题。如果你也在玩RV1126、RK3568或者其他Rockchip平台的设备并且对“烧写镜像”、“OTA升级”、“串口调试”这些关键词感到既熟悉又头疼那么我踩过的这些坑和总结的经验或许能帮你省下不少折腾的时间。2. 升级前的“战备”工作工具与环境梳理在动手升级之前把工具和环境理顺了能避免至少一半的莫名其妙的问题。很多人一上来就急着连板子、开软件结果卡在第一步。2.1 核心工具三件套烧写、调试与镜像对于Rockchip平台尤其是RV1126下面这三个工具是你的必备武器RKDevTool / Upgrade Tool这是瑞芯微官方的烧录工具。不同芯片型号、不同版本的工具可能存在兼容性问题。一个常见的坑是你从某个论坛下载的“通用版”工具可能根本不识别你的RV1126板子。我的经验是优先从板卡供应商或方案商那里获取配套的工具。如果找不到可以去Rockchip的官方Wiki或开发者社区寻找对应芯片型号的专用版本。工具界面通常有“Loader”和“Maskrom”两种烧录模式这个我们后面会详细讲。串口调试助手这是你的“眼睛”和“嘴巴”。在升级过程中尤其是当系统无法正常启动时串口是获取Bootloader和内核日志的唯一通道。sscom、xcom、putty、minicom都可以。关键参数就三个波特率RV1126通常为1500000、数据位8、停止位1、无校验。这里有个细节一定要确保串口线的驱动正确安装并且在设备管理器中确认了正确的COM口号。我遇到过无数次因为COM口选错导致看着一片空白的终端发呆的情况。固件镜像文件通常是一个.img文件或者由多个分区镜像打包而成的update.img。你需要确认这个镜像是否与你的硬件版本如DDR型号、PMIC配置完全匹配。用不匹配的镜像轻则功能异常重则直接“变砖”。在拿到镜像后可以尝试用7zip或binwalk工具简单查看一下内部结构确认它包含boot.img、rootfs.img等关键分区。2.2 系统环境与驱动确认如果你的工作机是Windows那么DriverAssitant驱动助手这个工具必须安装。它包含了Rockchip芯片进入升级模式Maskrom或Loader时所需的USB驱动。安装后最好在设备管理器中手动检查一下当板子进入升级模式并连接USB后是否会正确识别为“Rockchip USB Device”或类似的设备。如果是Linux环境进行升级则需要配置udev规则让普通用户也能访问USB设备并且使用rkdeveloptool等命令行工具进行操作。这部分的坑在于权限和工具链的版本匹配。注意在连接板子之前先打开串口调试助手并设置好参数然后再给板子上电。这样你才能捕获到最完整的启动日志从Bootloader的第一行输出开始看起。这是判断板子状态的第一手资料。3. 深入RV1126的升级模式Loader与Maskrom的区别这是理解Rockchip平台升级的关键。很多升级失败根源就在于模式没选对。3.1 Loader模式常态化的升级入口当RV1126板子里的Bootloader通常是U-Boot正常运行时并且这个U-Boot支持rockusb或rkusb命令时就可以进入Loader模式。如何进入通常有两种方式在串口终端中在U-Boot的倒计时阶段按下任意键打断自动启动然后输入命令rkusb或rockusb。板子上可能有专门的“升级键”Recovery键在板上电瞬间按住此键U-Boot会检测到并自动进入Loader模式。表现进入Loader模式后串口可能会输出Enter rockusb mode之类的提示同时Windows电脑会识别到一个新的USB设备。此时在RKDevTool中设备列表会显示为一个“发现一个LOADER设备”。特点Loader模式依赖于板载Bootloader的正常工作。如果Bootloader本身损坏了这个模式就进不去了。3.2 Maskrom模式救砖的终极手段Maskrom是芯片内部固化的一段只读启动代码。当系统检测不到任何有效的可启动设备如eMMC、SPI Flash为空或损坏时或者通过特殊引脚强制触发时芯片会自动 fallback 到 Maskrom 模式。如何进入这是重点也是硬件操作。短路Flash找到板载eMMC或SPI Flash芯片的数据引脚通常是D0或CLK在上电瞬间将其与地GND短接。这模拟了Flash无法识别的状态迫使芯片进入Maskrom。这是最通用的方法但需要一定的硬件动手能力并要查询你板子的原理图。专用测试点有些开发板会设计一个标记为“Maskrom”或“M”的测试点将其在上电瞬间与地短接即可。按键组合极少数板子可能有通过按住多个按键上电的方式触发。表现进入Maskrom模式后芯片会等待主机通过USB发送下载指令。在RKDevTool中设备会显示为“发现一个MASKROM设备”。特点这是最底层的模式不依赖任何外部存储器的代码。只要芯片本身没坏就能通过Maskrom模式重新烧写Bootloader从而实现“救砖”。3.3 模式选择与实战策略理解了这两种模式你的升级策略就清晰了常规升级板子能正常启动到U-Boot或系统 - 优先尝试进入Loader模式进行升级。这种方式最安全、最方便。救砖/首次烧录板子无法启动、Flash为空、或升级中途失败导致Bootloader损坏 - 必须使用Maskrom模式。我遇到的一个典型场景是在Loader模式下升级中途因为USB线松动或电源波动导致升级中断结果Bootloader被写坏了一半。此时板子既无法正常启动也无法再次进入Loader模式。唯一的办法就是拆开机壳找到Flash引脚用镊子短接进入Maskrom模式重新烧写完整的固件。4. 固件镜像的构成与烧写流程拆解知道怎么连接板子了我们再来看看要烧写的“固件”到底是什么。一个完整的RV1126升级镜像通常不是单一文件而是一个遵循特定格式的包。4.1 标准update.img的解析使用RKDevTool烧写时我们常选择一个update.img文件。这个文件其实是一个容器里面打包了多个分区镜像和一份分区表信息。你可以使用Rockchip提供的afptool和img_unpack工具对其进行解包# 假设在Linux环境下 ./afptool -unpack update.img update/ ./img_unpack update.img rockimg/解包后你可能会看到如下关键组件parameter.txt分区表文件。这是升级的“地图”定义了eMMC上各个分区如bootrootfsuserdata的起始位置、大小和名称。升级前务必确认此分区表与板子原有分区布局兼容否则可能导致数据错乱。boot.img包含内核kernel.img和设备树resource.img或dtb等。负责启动Linux系统。rootfs.img根文件系统包含了操作系统的基础命令、库和你的应用程序。misc.img用于OTA升级时传递状态信息的分区。userdata.img用户数据分区。4.2 RKDevTool烧写步骤详解在RKDevTool中烧写流程是这样的工具读取update.img中的parameter.txt。根据分区表将boot.img、rootfs.img等逐个通过USB传输到板端的BootloaderLoader模式或Maskrom。Bootloader/Maskrom程序将这些镜像写入eMMC对应的物理地址。这里有一个至关重要的选项“擦除Flash”和“擦除IDB”。擦除Flash会清空整个存储设备eMMC的所有数据。相当于格式化整个硬盘。擦除IDBIDB是存储在Flash前几个块的信息块包含了Bootloader和分区表信息。擦除IDB会破坏Bootloader和分区表。实操心得首次烧录或彻底重刷可以勾选“擦除Flash”确保一个干净的状态。常规升级千万不要勾选“擦除Flash”特别是你的userdata分区里有重要数据时。标准的升级流程只会覆盖boot、rootfs等系统分区保留userdata分区。RKDevTool在加载update.img后通常默认只勾选需要更新的分区如bootrootfs这是安全的。“擦除IDB”要慎用只有在分区表损坏或需要彻底更换Bootloader类型如从旧版U-Boot换成新版时才使用。误操作会导致板子无法启动必须进Maskrom。4.3 命令行烧写更底层的控制在Linux主机上你可以使用rkdeveloptool进行更灵活的烧写。这对于自动化脚本或深入了解流程非常有帮助。# 1. 查看连接的设备 rkdeveloptool ld # 输出示例DevNo1 Vid0x2207,Pid0x350b,LocationID106 Maskrom # 2. 下载并运行Loader用于Maskrom模式初始化 rkdeveloptool db rkbin/RK1126_Loader.bin # 3. 烧写整个update.img rkdeveloptool wl 0 update.img # 4. 或者分别烧写各个分区更灵活 rkdeveloptool ppt # 查看分区信息 rkdeveloptool wl boot boot.img rkdeveloptool wl rootfs rootfs.img命令行工具让你对每个步骤都有清晰的控制当图形化工具出错时命令行输出的错误信息往往更直接。5. 串口调试当升级出错时你的诊断利器升级过程很少一帆风顺。当RKDevTool卡住、报错或者烧写成功后板子依然无法启动时串口调试终端就是你的救命稻草。你需要学会解读这些日志。5.1 Bootloader启动日志分析上电后串口最先输出的是BootloaderU-Boot的信息。健康的日志链是这样的U-Boot 2017.09 (Mar 01 2023 - 10:00:00 0800) Model: Rockchip RV1126 Evaluation Board DRAM: 1 GiB MMC: dwmmcffc50000: 1, dwmmcffc60000: 0 In: serial Out: serial Err: serial ... Hit any key to stop autoboot: 3如果在这里就卡住了比如DRAM初始化失败那可能是DDR配置不对镜像与板子硬件不匹配或者板子硬件有问题。5.2 内核启动日志与常见故障Bootloader之后会将控制权交给内核。内核启动日志非常详细能暴露大部分问题[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.19.111 (buildserver) ... [ 0.000000] Machine model: Rockchip RV1126 Evaluation Board ... [ 1.234567] dwmmc_ffc50000: voltage-ranges unspecified [ 1.234568] dwmmc_ffc50000: 1, dwmmc_ffc60000: 0 [ 1.567890] mmc0: new high speed SDHC card at address aaaa [ 1.567891] mmcblk0: mmc0:aaaa SL32G 29.7 GiB ... [ 2.345678] VFS: Mounted root (ext4 filesystem) on device 179:2. [ 2.345679] devtmpfs: mounted [ 2.456789] Freeing unused kernel memory: 1024K [ 2.456790] Run /sbin/init as init process常见错误及排查方向卡在Starting kernel ...之后没有任何输出最可能的原因设备树dtb错误。Bootloader加载了错误的内核或设备树文件导致内核无法识别硬件而崩溃。解决方法检查boot.img中的设备树是否与你的板型完全匹配。回退到已知正常的旧版本镜像进行对比。内核恐慌Kernel Panic[ 3.000000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)原因内核找不到根文件系统。可能是rootfs镜像损坏、分区表错误导致根文件系统分区位置不对、或者内核缺少对应的文件系统驱动如ext4。排查首先确认parameter.txt中rootfs分区的名称和编号是否正确。在U-Boot中使用mmc part或part list mmc 0命令查看实际分区表。确认内核配置包含了对应的文件系统支持。MMC/SD卡初始化失败[ 1.500000] dwmmc_ffc50000: error -110 whilst initialising MMC card原因存储设备初始化失败。可能是eMMC芯片虚焊、损坏或者内核驱动中的时序配置如dwmmc节点的clock-frequency与硬件不匹配。排查检查硬件连接。对比正常板子的内核设备树中MMC控制器的配置。5.3 文件系统挂载失败与Init进程问题即使内核启动成功也可能在挂载根文件系统或启动第一个用户进程init时失败。[ 2.500000] List of all partitions: [ 2.500001] ... (分区列表正常) ... [ 2.500002] VFS: Cannot open root device mmcblk0p5 or unknown-block(0,0): error -6 [ 2.500003] Please append a correct root boot option; here are the available partitions: ...这明确指出了根设备mmcblk0p5无法打开。你需要检查U-Boot的bootargs环境变量中root参数指定的设备是否正确例如root/dev/mmcblk0p5。对应的分区这里是第5分区是否存在且包含有效的文件系统镜像。如果挂载成功但最后卡在Run /sbin/init as init process然后没有下文通常是根文件系统里的/sbin/init链接通常指向systemd或busybox损坏或者文件系统本身不完整。这通常意味着rootfs.img在制作或烧写过程中出了问题。6. OTA升级远程部署的关键机制对于量产设备我们不可能每次都拆机短接用USB升级。OTAOver-The-Air升级是必须的。RV1126的OTA升级核心是recovery系统。6.1 Recovery系统与A/B分区一种常见的OTA方案是使用recovery分区。当系统需要升级时会重启进入recovery分区一个精简的Linux系统由recovery来完成对主系统分区boot,system,vendor等的更新。 Rockchip也支持A/B分区无缝更新方案即有两套完整的系统分区A槽和B槽当前运行A槽后台更新B槽下次启动时从B槽启动。这需要Bootloader如U-Boot和系统Android Things或某些Linux发行版的支持。6.2 制作OTA升级包OTA升级包ota_update.zip或update.zip不同于完整的update.img。它通常是一个差分包或全量包只包含需要更新的分区镜像并附带一个升级脚本updater-script用于Android兼容的recovery或自定义的更新逻辑。 制作OTA包通常需要使用SDK中的编译脚本例如build.sh或mkupdate.sh它会根据版本差异生成对应的包。6.3 OTA升级流程与调试下载设备从服务器下载OTA升级包到缓存分区如cache或数据分区。验证验证包的签名和完整性防止被篡改。进入Recovery系统重启Bootloader根据升级标志常存储在misc分区决定启动到recovery系统。安装更新recovery系统解压升级包根据脚本擦写对应的系统分区。重启更新完成后清除升级标志重启进入主系统。调试OTA的难点在于更新过程发生在recovery里而recovery的串口日志可能和主系统不同或者根本没有输出。你需要确保recovery镜像本身包含了串口驱动和输出功能。在recovery的初始化脚本如init.rc中确保console被正确设置到串口。仔细检查升级脚本的逻辑确保分区挂载、文件拷贝、权限设置的每一步都正确。我遇到过一个典型的OTA失败案例升级包制作时文件路径使用了绝对路径/system/bin/app但recovery环境下/system可能并未挂载导致文件拷贝失败。正确的做法是在脚本中先挂载system分区到某个临时目录如/tmp/system再进行操作。7. 进阶排查当基础手段都失效时如果串口没有任何输出或者输出乱码问题就更底层了。7.1 串口无输出排查硬件连接TX/RX线是否接反串口板如USB转TTL的电压是否是3.3VRV1126通常是3.3V电平地线是否接好波特率尝试最常见的1500000也试试115200。有些Bootloader早期阶段可能用低速波特率。Bootloader损坏如果完全无输出且确认串口硬件和设置无误那很可能是Bootloader代码区域IDB完全损坏。此时必须尝试Maskrom模式。7.2 使用示波器或逻辑分析仪对于更棘手的启动问题比如DDR无法初始化软件日志无能为力。这时需要硬件工具。测量时钟和电源用示波器检查核心电压如VDD_LOGIC、DDR电压是否稳定且在正确范围内。检查主晶振是否起振。抓取eMMC引脚波形在启动瞬间用逻辑分析仪抓取eMMC的CLK和CMD线波形看Bootloader是否在尝试读取Flash。如果没有读写活动说明芯片可能没跑起来或者BootROMMaskrom在更早阶段就失败了。7.3 利用TrustZone调试输出如果有RV1126的Arm Cortex-A7核心通常运行在非安全世界Linux而安全世界TrustZone可能运行着OP-TEE等安全OS。有些调试信息可能会输出到安全世界的UART上而这个UART可能和Linux使用的不是同一个物理串口。如果你的板子有多个UART接口可以尝试连接其他UART引脚看看是否有不同的输出。这需要查阅芯片的TRM技术参考手册和板子的原理图。整个RV1126的升级调试是一个从软件到硬件、从上层应用到底层硬件的全链路认知过程。最深刻的体会就是日志是你的第一线索理解流程是你分析线索的地图而硬件操作如Maskrom是你最后的保障。每次升级前做好备份确认镜像匹配理解你每一步操作的意义这样才能在遇到问题时从容不迫一步步缩小范围最终找到那个捣鬼的“小妖精”。
