最近在调一块RV1106G3核心板系统跑起来不难真正麻烦的是每次固件更新和bootloader调试都要在烧录流程上反复折腾。把fastboot这套链路彻底捋顺之后效率提升非常明显。这篇就把RV1106G3的fastboot调试全过程从头到尾记录一遍从环境搭建、指令使用、分区表理解到各种报错排查尽量踩过的坑都摊开讲。RV1106G3是瑞芯微RV1106系列下的一个视觉处理方案常用于IPC摄像头、智能门铃、边缘AI盒子这类产品板载NPU有0.5TOPS算力支持H.264/H.265编解码。G3一般是模组厂或核心板厂商的型号后缀板上启动介质通常是eMMC或SPI NOR。这类板子的调试痛点很集中固件分区分得细、烧写工具五花八门、进入下载模式的方式各不相同如果不弄懂fastboot到底工作在哪个环节很容易出现设备认不到、分区找不到、烧完起不来这类问题。这篇文章适合刚拿到RV1106G3开发板、想把系统稳定烧起来的朋友也适合被fastboot各种玄学报错折磨过、想系统梳理一遍的人。我会把fastboot在RV1106G3启动链中的位置讲清楚再给出一套可以直接照着操作的流程。1. 项目概述fastboot调试到底在解决什么问题1.1 RV1106G3平台的基本面貌在聊fastboot之前得先认识一下RV1106G3这套环境。芯片本身是瑞芯微针对IPC场景推出的视觉处理芯片内置DDR也就是说内存颗粒是封装在SoC里的板上不需要外挂DDR电路设计和PCB布线能省不少事。这种单芯片方案很适合小型摄像头模组但调试时有个特点片上DDR的初始化必须由芯片内部loader完成系统上电后跑的第一段代码不是U-Boot而是瑞芯微的MiniLoaderAll.bin。这个细节很关键。很多人把fastboot理解成“万能烧写入口”拿到板子直接敲fastboot flash结果发现设备根本识别不到原因就是还停留在loader阶段PC端枚举出来的设备是Rockusb Device而不是fastboot设备。RV1106G3的启动流程大致是BootROM → MiniLoaderAll.bin初始化DDR和存储→ U-Boot → kernel → rootfs。fastboot通常挂在U-Boot这一层也就是说系统从存储介质加载到U-Boot之后你才有机会进入fastboot模式。所以做RV1106G3调试至少要分清楚两套协议一套是Rockusb协议对应瑞芯微的loader下载模式用来烧MiniLoaderAll.bin和parameter分区表另一套才是fastboot协议用来烧U-Boot、kernel、rootfs这些上层分区。两套协议不能混着用这是我一开始踩得最深的坑。1.2 fastboot调试要解决的核心问题那我为什么还要用fastboot直接用RKDevTool整包烧写不就行了这个问题在开发阶段和产线阶段答案不一样。RKDevTool升级工具适合整包烧写一次把loader、parameter、uboot、boot、rootfs全写进去操作简单适合产线。但开发阶段频繁改的是kernel和rootfs每次都用整包烧写一是烧写时间长二是会把不需要动的分区也擦一遍增加变砖风险。fastboot的好处是精确到分区操作。我只改了kernel那就只烧boot分区几秒钟完成只改了根文件系统那就只烧rootfs分区不用碰其他区域。再加上fastboot命令本身就是Android生态的标准调试接口脚本化非常方便我可以把一整套测试流程写成shell脚本编译完自动烧写、自动重启、自动抓log效率比手动打开图形工具高太多。另外fastboot阶段是排查启动异常的绝佳位置。U-Boot跑起来之后、kernel起来之前这个阶段如果出问题串口log往往一闪而过很难抓。通过fastboot可以在U-Boot下主动停住系统手动控制启动流程逐个分区验证定位是kernel没烧进去、dtb不匹配还是rootfs挂载失败。这是fastboot作为调试入口最有价值的地方。2. 调试思路拆解fastboot在启动链里的角色和选择逻辑2.1 RV1106G3典型启动流程与loader、fastboot的分工把RV1106G3的启动流程画成时间线的话大致是这样板上电后BootROM先运行从eMMC或SPI NOR的固定偏移读取MiniLoaderAll.bin加载到片上SRAM和DDR里执行。MiniLoaderAll.bin负责初始化DDR控制器、时钟和存储介质然后加载U-Boot。U-Boot起来之后根据环境变量和分区表读取boot分区里的kernel和dtb最后挂载rootfs启动系统。在这个链条里MiniLoaderAll.bin对应的就是Rockusb下载模式。你在PC上看到的设备是“Rockusb Device”用的工具是RKDevTool或upgrade_tool。而fastboot对应的是U-Boot层的下载模式。U-Boot里实现了USB Device Controller的fastboot协议后执行fastboot usb 0PC端才会枚举出fastboot设备。这里有个容易忽略的问题如果MiniLoaderAll.bin本身没烧好或者DDR初始化失败系统根本到不了U-Bootfastboot自然不可能用。所以第一次拿到RV1106G3板子正确的做法先用Rockusb模式把loader和基础固件铺好确保系统能正常开机再去配置fastboot调试环境。反过来如果只是日常迭代kernel和rootfs那fastboot就够用了没必要动不动就进Rockusb模式全量烧写。2.2 为什么选择fastboot作为日常调试入口选择fastboot不是因为它比Rockusb更高级而是贴合日常开发的实际需求。Rockusb模式需要让板子进入下载状态通常要按住按键再上电或者短接eMMC时钟引脚操作一次两次还行每天几十次就很折磨人。fastboot模式下板子已经在U-Boot里跑着我只需要通过串口输入一条命令或者让系统重启后自动进入就能随时烧写整个流程不需要反复拔线、短接。再就是分区操作的灵活性。RKDevTool虽然也支持按分区烧写但图形界面的自动化能力比较弱命令行参数也不够统一。fastboot天然就是命令行工具我可以把分区名、镜像路径、校验逻辑全部封装成脚本CI构建完直接触发烧写板子重启后自动跑回归测试全程无人值守。这个优势在做内核驱动调试、硬件接口验证的时候特别明显一次改动从编译到上板验证能压缩到几分钟内。当然fastboot也有局限。它解决不了loader层的问题也绕不开存储介质本身的物理故障。如果eMMC坏块太多fastboot反复写入失败最终还是得回到Rockusb模式做低级格式化或重新分区。所以我的思路是loader层用Rockusb兜底系统层用fastboot做日常迭代两者结合才能覆盖完整的调试链路。3. 环境准备驱动、工具链与USB连接一次到位3.1 两种宿主机环境下的工具链安装先讲Linux环境这也是我主力开发环境。Ubuntu/Debian系直接安装Android平台工具包fastboot和adb会一起装上sudo apt update sudo apt install android-tools-fastboot android-tools-adb装完先验证一下版本fastboot --version如果发行版本较新工具包名称可能变成了fastboot和adb用apt search查一下实际包名就行。另外记得把当前用户加入plugdev组或者配置udev规则否则fastboot会拿不到USB设备访问权限。常见的做法是在/etc/udev/rules.d/51-android.rules里加一条厂商ID匹配规则SUBSYSTEMusb, ATTR{idVendor}2207, MODE0666注意瑞芯微的USB Vendor ID是2207全志是1f3a高通是05c6不要照抄别人的规则导致匹配不上。Windows环境也不复杂但比Linux多一步驱动安装。RV1106G3在Rockusb模式下会枚举为“Rockusb Device”在fastboot模式下会枚举为“Android Fastboot Interface”或“Android ADB Interface”。Windows默认认不了需要安装瑞芯微驱动助手DriverAssistant装完在设备管理器里能看到对应的接口。fastboot工具的获取路径很多可以用Android SDK自带的platform-tools也可以直接用瑞芯微SDK里携带的版本我建议直接用SDK里的版本和固件匹配度最好。3.2 连接链路排查USB枚举、设备口与线材环境工具装好之后连接这块反而最容易出问题。RV1106G3核心板一般只有一个USB Device口用于烧写调试通常标注为OTG或USB_DOWNLOAD不要插到USB Host口上。Host口是给UVC摄像头、U盘这类外设用的插上去PC不会有任何反应。线材也是个坑。fastboot调试必须用真正的数据线不是所有USB线都带数据引脚。有些线只能充电插上后PC完全识别不到设备排查了半天驱动最后发现是线的问题。建议多备两条质量可靠的USB-A to USB-C数据线或者直接用原装线缆排除这个变量。连接顺序也有讲究。先把USB线插到PC端再给板子上电或者先按住BOOT按键再上电。上电后立刻在PC端看枚举情况。Linux下用lsusb查看lsusb如果看到Bus xxx Device xxx: ID 2207:xxxx说明设备已经被识别剩下的就是驱动和权限问题。Windows下打开设备管理器如果出现带感叹号的未知设备右键更新驱动手动指向DriverAssistant安装目录即可。如果是fastboot模式设备会显示为“Android”相关接口但驱动的使用方法和Rockusb模式一致。提示fastboot模式和Rockusb模式在设备管理器里的名字不一样不要因为只认Rockusb Device而误判设备没进入状态。可以在设备管理器里反复拔插USB线观察设备名的变化确认板子当前处于哪个阶段。4. 实操全记录fastboot指令、分区表与烧写流程4.1 fastboot指令全景速查fastboot的指令集不大但每条指令背后都有使用场景。我把RV1106G3调试中最常用的指令整理成一张表照着用就行。指令作用示例fastboot devices列出当前连接的fastboot设备fastboot devicesfastboot getvar all读取设备全部变量包含分区信息fastboot getvar allfastboot getvar partition-type:xxx查询指定分区类型fastboot getvar partition-type:bootfastboot flash 分区名 镜像文件烧写镜像到指定分区fastboot flash boot boot.imgfastboot erase 分区名擦除指定分区fastboot erase userdatafastboot reboot重启设备fastboot rebootfastboot reboot-bootloader重启后重新进入fastbootfastboot reboot-bootloaderfastboot oem unlock解锁bootloader视固件实现fastboot oem unlockfastboot devices这条命令虽然简单却是整个调试流程的第一步。执行后如果看到类似2207d1c00123xxx fastboot的输出说明设备连接正常。长期只返回空行先去查驱动和线材不要急着怀疑板子。getvar all可以一次性把设备的分区信息、芯片型号、bootloader版本全部抓出来拿到板子先跑一遍这条命令能省下很多猜谜的时间。这里专门提醒一下fastboot和adb是完全不同的两套协议。adb工作在kernel起来之后、系统正常运行的状态而fastboot工作在U-Boot阶段。很多人在fastboot模式里敲adb devices发现列表为空就以为设备连不上实际上这是正常现象。判断当前该用哪套工具只需要看板子处于什么启动阶段。4.2 RV1106G3分区布局与parameter的理解RV1106G3的分区表由parameter文件定义。这个文件在瑞芯微平台里是一个文本格式的分区描述Rockusb模式下会用到一个很重要的二进制版本叫parameter.img但核心内容仍然是分区表信息。一个典型的RV1106参数分区表长这样FIRMWARE_VER: 1.0 MACHINE_MODEL: RV1106G3 MACHINE_ID: 007 MANUFACTURER: Rockchip CMDLINE: mtdpartsrk29xxnand:0x000020000x00004000(uboot),0x000020000x00006000(misc),0x000100000x00008000(boot),0x000100000x00018000(recovery),0x000400000x00028000(rootfs),0x000400000x00068000(userdata)我把这段参数拆开解读一下。每个分区的格式是sizeoffset(name)size和offset的单位都是512字节扇区。uboot分区大小0x2000个扇区也就是4MB偏移地址在0x4000扇区处。misc分区也是4MB紧跟在uboot后面。boot分区0x10000扇区也就是32MB存放kernel和dtb。之后是recovery、rootfs和userdata分区。在fastboot模式下分区名直接沿用parameter表里的name字段。所以烧写时分区名必须写uboot、boot、rootfs不能自己发明名字也不能把大小写搞错。很多报错unknown partition本质就是分区表里根本不存在你输入的那个名字。调试前先通过getvar确认实际分区表这样能了解到板上固件是否和SDK里的parameter一致。命令是fastboot getvar all输出结果里会列出类似partition-type:boot、partition-size:boot这样的变量通过这些可以反推分区名。注意不同方案商可能改过分区表比如把rootfs改名叫system或者新增一个oem分区务必以实际输出为准。4.3 从零开始的一次完整烧写步骤以一块已经烧好工具链和基础固件的RV1106G3板子为例我梳理一次完整的分区烧写流程。这一步的目标是把新编译的kernel和根文件系统刷进板子并且确认系统能正常启动。第一步串口连接板子。我习惯用USB转串口模块接板子的调试串口波特率通常是115200或1500000具体看方案商文档。串口不是烧写必需但强烈建议接上因为烧完后能不能起来只有串口log能告诉你真话。第二步让板子进入fastboot模式。RV1106G3的进入方式主要有三种一是在U-Boot命令行里执行fastboot usb 0二是系统正常运行后通过adb执行adb reboot fastboot三是按下板子上的特定按键组合上电具体看板卡原理图。我用的开发板是第一种最稳因为U-Boot起来后就可以控制。第三步确认PC识别设备fastboot devices看到类似输出的设备ID就说明fastboot链路已经通了。第四步烧写boot分区和rootfs分区fastboot flash boot boot.img fastboot flash rootfs rootfs.img烧写过程中屏幕上会显示进度条一个分区几十秒到几分钟不等主要看镜像大小和USB传输速度。boot分区一般只有十几MBrootfs看文件系统大小可能在100MB以上。第五步重启板子fastboot reboot同时盯住串口输出确认kernel能正常解压、根文件系统能正常挂载。如果卡在某个环节按第五部分的排查思路处理。整个流程看起来很简单但实际调试中每一步都可能埋雷。比如boot分区里既有kernel又有dtbdtb和kernel版本不匹配会导致启动后外设初始化失败rootfs的分区大小如果小于镜像实际大小写入过程可能报错还有erase操作会清空分区数据操作前一定要确认分区名是否正确不要一上来就erase整个userdata。注意第一次调试阶段不建议用fastboot烧写uboot分区。U-Boot是fastboot功能本身的宿主如果烧写过程中断或者镜像损坏fastboot模式可能直接失效板子只能回到Rockusb模式救砖。先把kernel和rootfs都验证通了再考虑动uboot而且uboot镜像尽量用官方或方案商提供的版本。5. 常见问题与排障实录5.1 fastboot devices看不到设备怎么办这是出现频率最高的问题。我接到过不少朋友的求助说板子明明上电了fastboot devices就是什么都看不到。排查顺序应该是先确认板子是不是真的在fastboot模式再看USB枚举最后查驱动权限。板子状态的确认最好用串口log。如果U-Boot已经执行了fastboot usb 0串口上会打印类似USB download mode的信息。没有串口的话看板上LED和屏幕提示有些设备会显示“已进入fastboot下载模式请用USB连接电脑进行软件升级”之类的提示语这也是判断依据之一但本质上这类提示说明bootloader已经在等待USB通信了。USB枚举这块Linux用lsusb确认是否有2207开头的设备。如果没有大概率是USB线或接口问题换线重插。有设备但fastboot还是看不到就要检查udev规则和权限。Windows下看设备管理器如果设备带黄色感叹号手动装一下驱动。还有一个小细节很多主板的USB口供电不稳尤其是前置USB口接板子时尽量插后置口避免电压波动导致设备反复掉线。另外要注意的是fastboot和Rockusb的设备名不同。在fastboot模式下Linux的lsusb仍会显示2207的Vendor ID但设备名可能是Device 001: ID 2207加一个具体产品ID。Windows下是“Android Fastboot Interface”不要因为看不到“Rockusb Device”就误判。5.2 unknown partition到底是谁的锅热词里有一条很典型fastboot flash unlock unknown partition。这个报错的场景我太熟悉了新人在执行解锁或者重置时直接在命令行敲了fastboot flash unlock结果fastboot认为unlock是一个分区名去分区表里查不到就报了unknown partition。这里要先看清楚flash指令的语法fastboot flash 分区名 镜像文件两个参数缺一不可。如果只给了分区名没给镜像路径fastboot会把后面不存在的参数当成分区名的一部分自然是找不到的。真正的bootloader解锁指令在Android生态里一般是fastboot oem unlock或fastboot flashing unlock瑞芯微平台具体支持哪条要看U-Boot实现。在RV1106G3上如果执行fastboot flashing unlock提示unknown command说明固件压根没实现这个功能不用纠结这套平台通常默认不锁bootloader。还有一种情况是分区名写错。比如把uboot写成u-boot把boot写成kernel把rootfs写成system。我建议每拿到一块新板子先执行fastboot getvar all把实际分区名抓下来对照着抄不要凭记忆敲。对于不存在的分区fastboot的报错信息一般都很明确直接照着提示改分区名就好。还有一部分unknown partition是parameter表本身的问题。方案商改了分区名但SDK里的烧写脚本没有同步更新生成镜像时的分区名和板上不一致。这种情况下最简单的做法是按照板上parameter重新整理烧写脚本或者用Rockusb模式重新写一份统一的parameter表让分区名和调试脚本对齐。5.3 烧写成功后无法启动、反复进fastboot这个问题的表现是fastboot烧写提示成功reboot之后系统却起不来或者启动到一半又退回fastboot。先说启动退不回来的情况。RV1106G3如果misc分区里写了特殊的启动标志或者U-Boot的环境变量设置了进入下载模式那么每次开机都会停在fastboot等待USB连接看起来就像“反复进fastboot”。解决思路是先看看misc分区的内容有时候是旧系统在关机前写入了recovery或者fastboot标志。用fastboot把misc分区清掉再重启fastboot erase misc fastboot reboot如果还不行进U-Boot命令行通过env命令检查fastboot相关的环境变量把不想要的标志位清掉。另一种情况是kernel起不来。烧写成功后设备重新枚举成Linux设备或者卡在黑屏这时排查重点在dtb和kernel的匹配度。RV1106G3同一个芯片会有多个板型变体DDR容量、屏幕型号、外设接口都不一样boot分区里的dtb必须和板子硬件对上。只更新kernel不更新dtb或者两者版本差距过大经常是外设初始化失败表现就是启动到一半卡死。我的排查习惯是先在U-Boot命令行手动启动kernel观察串口输出停在哪一行。如果卡在CPU相关信息输出之后优先怀疑dtb问题如果卡在文件系统挂载优先怀疑rootfs分区大小或者文件系统格式不匹配。这些log在量产阶段几乎不会看到但在调试阶段就是救命稻草。6. 实操心得与经验沉淀6.1 建议的稳妥调试顺序调试顺序直接影响心态。我建议拿RV1106G3板子按这个顺序推进先用Rockusb模式把MiniLoaderAll.bin、parameter和原始固件完整烧写一遍确认板子能正常开机。这一步建立了最底层的安全网就算后面fastboot折腾坏了至少知道怎么回到正常状态。然后再配置fastboot环境测试kernel和rootfs的分区烧写。最后才考虑用fastboot更新uboot分区而且务必先备份原厂uboot镜像。配一个自己固定的工作目录把MiniLoaderAll.bin、parameter.img、uboot.img、boot.img、rootfs.img这些镜像按版本归档每次调试用到的文件都放进去不要散落在各个下载目录里。fastboot烧写脚本也放在同一目录脚本里做一步校验确认镜像文件存在再执行烧写避免文件路径写错导致烧了空文件。6.2 容易被忽略的细节最后分享几个不写在文档里、但实操中非常影响体验的细节。第一电源质量比想象中重要。RV1106G3核心板电流需求不大但USB供电和独立电源供电在烧写大镜像时的稳定性差别很大。如果烧写过程中频繁出现传输中断、超时先别怀疑工具和驱动换一个带独立供电的USB HUB或者直接给板子接一个干净的5V电源电流最好在1A以上问题往往就消失了。第二备份原厂固件是最高优先级。拿到板子第一件事应该把整片eMMC或者NOR Flash的镜像备份出来而不是急着烧新系统。瑞芯微的RKDevTool和upgrade_tool都支持读取备份备份文件放到安全的地方。我遇到过很多次调试过程中把板子搞到无法启动都是靠备份固件快速恢复才没耽误项目进度。第三fastboot的报错信息要看成是有价值的线索而不只是“失败”。它说unknown command就是当前U-Boot实现里没有这个指令它说cannot load image就是镜像解析有问题它在某个地址校验失败就是传输过程丢数据或者镜像本身损坏。养成看完整报错的习惯比瞎猜有用得多。第四串口log和fastboot终端不要混用。fastboot的USB通道和串口是独立的两条链路串口打出的信息不会出现在fastboot里fastboot的烧写进度也不会打到串口上。调试时开两个终端窗口一个盯串口一个操作fastboot才能把两侧信息完整对照起来。RV1106G3的fastboot调试本质上就是摸清U-Boot下载模式的工作方式把它的能力边界搞清楚。loader层交给Rockusb系统层交给fastboot两层协同日常开发调试的整个链路就会顺畅很多。如果你现在正被某一块板子的烧写问题卡住照着这篇文章把环境、命令和排查思路过一遍应该能少走不少弯路。
RV1106G3 Fastboot调试全流程：环境搭建、分区烧写与常见报错排查
最近在调一块RV1106G3核心板系统跑起来不难真正麻烦的是每次固件更新和bootloader调试都要在烧录流程上反复折腾。把fastboot这套链路彻底捋顺之后效率提升非常明显。这篇就把RV1106G3的fastboot调试全过程从头到尾记录一遍从环境搭建、指令使用、分区表理解到各种报错排查尽量踩过的坑都摊开讲。RV1106G3是瑞芯微RV1106系列下的一个视觉处理方案常用于IPC摄像头、智能门铃、边缘AI盒子这类产品板载NPU有0.5TOPS算力支持H.264/H.265编解码。G3一般是模组厂或核心板厂商的型号后缀板上启动介质通常是eMMC或SPI NOR。这类板子的调试痛点很集中固件分区分得细、烧写工具五花八门、进入下载模式的方式各不相同如果不弄懂fastboot到底工作在哪个环节很容易出现设备认不到、分区找不到、烧完起不来这类问题。这篇文章适合刚拿到RV1106G3开发板、想把系统稳定烧起来的朋友也适合被fastboot各种玄学报错折磨过、想系统梳理一遍的人。我会把fastboot在RV1106G3启动链中的位置讲清楚再给出一套可以直接照着操作的流程。1. 项目概述fastboot调试到底在解决什么问题1.1 RV1106G3平台的基本面貌在聊fastboot之前得先认识一下RV1106G3这套环境。芯片本身是瑞芯微针对IPC场景推出的视觉处理芯片内置DDR也就是说内存颗粒是封装在SoC里的板上不需要外挂DDR电路设计和PCB布线能省不少事。这种单芯片方案很适合小型摄像头模组但调试时有个特点片上DDR的初始化必须由芯片内部loader完成系统上电后跑的第一段代码不是U-Boot而是瑞芯微的MiniLoaderAll.bin。这个细节很关键。很多人把fastboot理解成“万能烧写入口”拿到板子直接敲fastboot flash结果发现设备根本识别不到原因就是还停留在loader阶段PC端枚举出来的设备是Rockusb Device而不是fastboot设备。RV1106G3的启动流程大致是BootROM → MiniLoaderAll.bin初始化DDR和存储→ U-Boot → kernel → rootfs。fastboot通常挂在U-Boot这一层也就是说系统从存储介质加载到U-Boot之后你才有机会进入fastboot模式。所以做RV1106G3调试至少要分清楚两套协议一套是Rockusb协议对应瑞芯微的loader下载模式用来烧MiniLoaderAll.bin和parameter分区表另一套才是fastboot协议用来烧U-Boot、kernel、rootfs这些上层分区。两套协议不能混着用这是我一开始踩得最深的坑。1.2 fastboot调试要解决的核心问题那我为什么还要用fastboot直接用RKDevTool整包烧写不就行了这个问题在开发阶段和产线阶段答案不一样。RKDevTool升级工具适合整包烧写一次把loader、parameter、uboot、boot、rootfs全写进去操作简单适合产线。但开发阶段频繁改的是kernel和rootfs每次都用整包烧写一是烧写时间长二是会把不需要动的分区也擦一遍增加变砖风险。fastboot的好处是精确到分区操作。我只改了kernel那就只烧boot分区几秒钟完成只改了根文件系统那就只烧rootfs分区不用碰其他区域。再加上fastboot命令本身就是Android生态的标准调试接口脚本化非常方便我可以把一整套测试流程写成shell脚本编译完自动烧写、自动重启、自动抓log效率比手动打开图形工具高太多。另外fastboot阶段是排查启动异常的绝佳位置。U-Boot跑起来之后、kernel起来之前这个阶段如果出问题串口log往往一闪而过很难抓。通过fastboot可以在U-Boot下主动停住系统手动控制启动流程逐个分区验证定位是kernel没烧进去、dtb不匹配还是rootfs挂载失败。这是fastboot作为调试入口最有价值的地方。2. 调试思路拆解fastboot在启动链里的角色和选择逻辑2.1 RV1106G3典型启动流程与loader、fastboot的分工把RV1106G3的启动流程画成时间线的话大致是这样板上电后BootROM先运行从eMMC或SPI NOR的固定偏移读取MiniLoaderAll.bin加载到片上SRAM和DDR里执行。MiniLoaderAll.bin负责初始化DDR控制器、时钟和存储介质然后加载U-Boot。U-Boot起来之后根据环境变量和分区表读取boot分区里的kernel和dtb最后挂载rootfs启动系统。在这个链条里MiniLoaderAll.bin对应的就是Rockusb下载模式。你在PC上看到的设备是“Rockusb Device”用的工具是RKDevTool或upgrade_tool。而fastboot对应的是U-Boot层的下载模式。U-Boot里实现了USB Device Controller的fastboot协议后执行fastboot usb 0PC端才会枚举出fastboot设备。这里有个容易忽略的问题如果MiniLoaderAll.bin本身没烧好或者DDR初始化失败系统根本到不了U-Bootfastboot自然不可能用。所以第一次拿到RV1106G3板子正确的做法先用Rockusb模式把loader和基础固件铺好确保系统能正常开机再去配置fastboot调试环境。反过来如果只是日常迭代kernel和rootfs那fastboot就够用了没必要动不动就进Rockusb模式全量烧写。2.2 为什么选择fastboot作为日常调试入口选择fastboot不是因为它比Rockusb更高级而是贴合日常开发的实际需求。Rockusb模式需要让板子进入下载状态通常要按住按键再上电或者短接eMMC时钟引脚操作一次两次还行每天几十次就很折磨人。fastboot模式下板子已经在U-Boot里跑着我只需要通过串口输入一条命令或者让系统重启后自动进入就能随时烧写整个流程不需要反复拔线、短接。再就是分区操作的灵活性。RKDevTool虽然也支持按分区烧写但图形界面的自动化能力比较弱命令行参数也不够统一。fastboot天然就是命令行工具我可以把分区名、镜像路径、校验逻辑全部封装成脚本CI构建完直接触发烧写板子重启后自动跑回归测试全程无人值守。这个优势在做内核驱动调试、硬件接口验证的时候特别明显一次改动从编译到上板验证能压缩到几分钟内。当然fastboot也有局限。它解决不了loader层的问题也绕不开存储介质本身的物理故障。如果eMMC坏块太多fastboot反复写入失败最终还是得回到Rockusb模式做低级格式化或重新分区。所以我的思路是loader层用Rockusb兜底系统层用fastboot做日常迭代两者结合才能覆盖完整的调试链路。3. 环境准备驱动、工具链与USB连接一次到位3.1 两种宿主机环境下的工具链安装先讲Linux环境这也是我主力开发环境。Ubuntu/Debian系直接安装Android平台工具包fastboot和adb会一起装上sudo apt update sudo apt install android-tools-fastboot android-tools-adb装完先验证一下版本fastboot --version如果发行版本较新工具包名称可能变成了fastboot和adb用apt search查一下实际包名就行。另外记得把当前用户加入plugdev组或者配置udev规则否则fastboot会拿不到USB设备访问权限。常见的做法是在/etc/udev/rules.d/51-android.rules里加一条厂商ID匹配规则SUBSYSTEMusb, ATTR{idVendor}2207, MODE0666注意瑞芯微的USB Vendor ID是2207全志是1f3a高通是05c6不要照抄别人的规则导致匹配不上。Windows环境也不复杂但比Linux多一步驱动安装。RV1106G3在Rockusb模式下会枚举为“Rockusb Device”在fastboot模式下会枚举为“Android Fastboot Interface”或“Android ADB Interface”。Windows默认认不了需要安装瑞芯微驱动助手DriverAssistant装完在设备管理器里能看到对应的接口。fastboot工具的获取路径很多可以用Android SDK自带的platform-tools也可以直接用瑞芯微SDK里携带的版本我建议直接用SDK里的版本和固件匹配度最好。3.2 连接链路排查USB枚举、设备口与线材环境工具装好之后连接这块反而最容易出问题。RV1106G3核心板一般只有一个USB Device口用于烧写调试通常标注为OTG或USB_DOWNLOAD不要插到USB Host口上。Host口是给UVC摄像头、U盘这类外设用的插上去PC不会有任何反应。线材也是个坑。fastboot调试必须用真正的数据线不是所有USB线都带数据引脚。有些线只能充电插上后PC完全识别不到设备排查了半天驱动最后发现是线的问题。建议多备两条质量可靠的USB-A to USB-C数据线或者直接用原装线缆排除这个变量。连接顺序也有讲究。先把USB线插到PC端再给板子上电或者先按住BOOT按键再上电。上电后立刻在PC端看枚举情况。Linux下用lsusb查看lsusb如果看到Bus xxx Device xxx: ID 2207:xxxx说明设备已经被识别剩下的就是驱动和权限问题。Windows下打开设备管理器如果出现带感叹号的未知设备右键更新驱动手动指向DriverAssistant安装目录即可。如果是fastboot模式设备会显示为“Android”相关接口但驱动的使用方法和Rockusb模式一致。提示fastboot模式和Rockusb模式在设备管理器里的名字不一样不要因为只认Rockusb Device而误判设备没进入状态。可以在设备管理器里反复拔插USB线观察设备名的变化确认板子当前处于哪个阶段。4. 实操全记录fastboot指令、分区表与烧写流程4.1 fastboot指令全景速查fastboot的指令集不大但每条指令背后都有使用场景。我把RV1106G3调试中最常用的指令整理成一张表照着用就行。指令作用示例fastboot devices列出当前连接的fastboot设备fastboot devicesfastboot getvar all读取设备全部变量包含分区信息fastboot getvar allfastboot getvar partition-type:xxx查询指定分区类型fastboot getvar partition-type:bootfastboot flash 分区名 镜像文件烧写镜像到指定分区fastboot flash boot boot.imgfastboot erase 分区名擦除指定分区fastboot erase userdatafastboot reboot重启设备fastboot rebootfastboot reboot-bootloader重启后重新进入fastbootfastboot reboot-bootloaderfastboot oem unlock解锁bootloader视固件实现fastboot oem unlockfastboot devices这条命令虽然简单却是整个调试流程的第一步。执行后如果看到类似2207d1c00123xxx fastboot的输出说明设备连接正常。长期只返回空行先去查驱动和线材不要急着怀疑板子。getvar all可以一次性把设备的分区信息、芯片型号、bootloader版本全部抓出来拿到板子先跑一遍这条命令能省下很多猜谜的时间。这里专门提醒一下fastboot和adb是完全不同的两套协议。adb工作在kernel起来之后、系统正常运行的状态而fastboot工作在U-Boot阶段。很多人在fastboot模式里敲adb devices发现列表为空就以为设备连不上实际上这是正常现象。判断当前该用哪套工具只需要看板子处于什么启动阶段。4.2 RV1106G3分区布局与parameter的理解RV1106G3的分区表由parameter文件定义。这个文件在瑞芯微平台里是一个文本格式的分区描述Rockusb模式下会用到一个很重要的二进制版本叫parameter.img但核心内容仍然是分区表信息。一个典型的RV1106参数分区表长这样FIRMWARE_VER: 1.0 MACHINE_MODEL: RV1106G3 MACHINE_ID: 007 MANUFACTURER: Rockchip CMDLINE: mtdpartsrk29xxnand:0x000020000x00004000(uboot),0x000020000x00006000(misc),0x000100000x00008000(boot),0x000100000x00018000(recovery),0x000400000x00028000(rootfs),0x000400000x00068000(userdata)我把这段参数拆开解读一下。每个分区的格式是sizeoffset(name)size和offset的单位都是512字节扇区。uboot分区大小0x2000个扇区也就是4MB偏移地址在0x4000扇区处。misc分区也是4MB紧跟在uboot后面。boot分区0x10000扇区也就是32MB存放kernel和dtb。之后是recovery、rootfs和userdata分区。在fastboot模式下分区名直接沿用parameter表里的name字段。所以烧写时分区名必须写uboot、boot、rootfs不能自己发明名字也不能把大小写搞错。很多报错unknown partition本质就是分区表里根本不存在你输入的那个名字。调试前先通过getvar确认实际分区表这样能了解到板上固件是否和SDK里的parameter一致。命令是fastboot getvar all输出结果里会列出类似partition-type:boot、partition-size:boot这样的变量通过这些可以反推分区名。注意不同方案商可能改过分区表比如把rootfs改名叫system或者新增一个oem分区务必以实际输出为准。4.3 从零开始的一次完整烧写步骤以一块已经烧好工具链和基础固件的RV1106G3板子为例我梳理一次完整的分区烧写流程。这一步的目标是把新编译的kernel和根文件系统刷进板子并且确认系统能正常启动。第一步串口连接板子。我习惯用USB转串口模块接板子的调试串口波特率通常是115200或1500000具体看方案商文档。串口不是烧写必需但强烈建议接上因为烧完后能不能起来只有串口log能告诉你真话。第二步让板子进入fastboot模式。RV1106G3的进入方式主要有三种一是在U-Boot命令行里执行fastboot usb 0二是系统正常运行后通过adb执行adb reboot fastboot三是按下板子上的特定按键组合上电具体看板卡原理图。我用的开发板是第一种最稳因为U-Boot起来后就可以控制。第三步确认PC识别设备fastboot devices看到类似输出的设备ID就说明fastboot链路已经通了。第四步烧写boot分区和rootfs分区fastboot flash boot boot.img fastboot flash rootfs rootfs.img烧写过程中屏幕上会显示进度条一个分区几十秒到几分钟不等主要看镜像大小和USB传输速度。boot分区一般只有十几MBrootfs看文件系统大小可能在100MB以上。第五步重启板子fastboot reboot同时盯住串口输出确认kernel能正常解压、根文件系统能正常挂载。如果卡在某个环节按第五部分的排查思路处理。整个流程看起来很简单但实际调试中每一步都可能埋雷。比如boot分区里既有kernel又有dtbdtb和kernel版本不匹配会导致启动后外设初始化失败rootfs的分区大小如果小于镜像实际大小写入过程可能报错还有erase操作会清空分区数据操作前一定要确认分区名是否正确不要一上来就erase整个userdata。注意第一次调试阶段不建议用fastboot烧写uboot分区。U-Boot是fastboot功能本身的宿主如果烧写过程中断或者镜像损坏fastboot模式可能直接失效板子只能回到Rockusb模式救砖。先把kernel和rootfs都验证通了再考虑动uboot而且uboot镜像尽量用官方或方案商提供的版本。5. 常见问题与排障实录5.1 fastboot devices看不到设备怎么办这是出现频率最高的问题。我接到过不少朋友的求助说板子明明上电了fastboot devices就是什么都看不到。排查顺序应该是先确认板子是不是真的在fastboot模式再看USB枚举最后查驱动权限。板子状态的确认最好用串口log。如果U-Boot已经执行了fastboot usb 0串口上会打印类似USB download mode的信息。没有串口的话看板上LED和屏幕提示有些设备会显示“已进入fastboot下载模式请用USB连接电脑进行软件升级”之类的提示语这也是判断依据之一但本质上这类提示说明bootloader已经在等待USB通信了。USB枚举这块Linux用lsusb确认是否有2207开头的设备。如果没有大概率是USB线或接口问题换线重插。有设备但fastboot还是看不到就要检查udev规则和权限。Windows下看设备管理器如果设备带黄色感叹号手动装一下驱动。还有一个小细节很多主板的USB口供电不稳尤其是前置USB口接板子时尽量插后置口避免电压波动导致设备反复掉线。另外要注意的是fastboot和Rockusb的设备名不同。在fastboot模式下Linux的lsusb仍会显示2207的Vendor ID但设备名可能是Device 001: ID 2207加一个具体产品ID。Windows下是“Android Fastboot Interface”不要因为看不到“Rockusb Device”就误判。5.2 unknown partition到底是谁的锅热词里有一条很典型fastboot flash unlock unknown partition。这个报错的场景我太熟悉了新人在执行解锁或者重置时直接在命令行敲了fastboot flash unlock结果fastboot认为unlock是一个分区名去分区表里查不到就报了unknown partition。这里要先看清楚flash指令的语法fastboot flash 分区名 镜像文件两个参数缺一不可。如果只给了分区名没给镜像路径fastboot会把后面不存在的参数当成分区名的一部分自然是找不到的。真正的bootloader解锁指令在Android生态里一般是fastboot oem unlock或fastboot flashing unlock瑞芯微平台具体支持哪条要看U-Boot实现。在RV1106G3上如果执行fastboot flashing unlock提示unknown command说明固件压根没实现这个功能不用纠结这套平台通常默认不锁bootloader。还有一种情况是分区名写错。比如把uboot写成u-boot把boot写成kernel把rootfs写成system。我建议每拿到一块新板子先执行fastboot getvar all把实际分区名抓下来对照着抄不要凭记忆敲。对于不存在的分区fastboot的报错信息一般都很明确直接照着提示改分区名就好。还有一部分unknown partition是parameter表本身的问题。方案商改了分区名但SDK里的烧写脚本没有同步更新生成镜像时的分区名和板上不一致。这种情况下最简单的做法是按照板上parameter重新整理烧写脚本或者用Rockusb模式重新写一份统一的parameter表让分区名和调试脚本对齐。5.3 烧写成功后无法启动、反复进fastboot这个问题的表现是fastboot烧写提示成功reboot之后系统却起不来或者启动到一半又退回fastboot。先说启动退不回来的情况。RV1106G3如果misc分区里写了特殊的启动标志或者U-Boot的环境变量设置了进入下载模式那么每次开机都会停在fastboot等待USB连接看起来就像“反复进fastboot”。解决思路是先看看misc分区的内容有时候是旧系统在关机前写入了recovery或者fastboot标志。用fastboot把misc分区清掉再重启fastboot erase misc fastboot reboot如果还不行进U-Boot命令行通过env命令检查fastboot相关的环境变量把不想要的标志位清掉。另一种情况是kernel起不来。烧写成功后设备重新枚举成Linux设备或者卡在黑屏这时排查重点在dtb和kernel的匹配度。RV1106G3同一个芯片会有多个板型变体DDR容量、屏幕型号、外设接口都不一样boot分区里的dtb必须和板子硬件对上。只更新kernel不更新dtb或者两者版本差距过大经常是外设初始化失败表现就是启动到一半卡死。我的排查习惯是先在U-Boot命令行手动启动kernel观察串口输出停在哪一行。如果卡在CPU相关信息输出之后优先怀疑dtb问题如果卡在文件系统挂载优先怀疑rootfs分区大小或者文件系统格式不匹配。这些log在量产阶段几乎不会看到但在调试阶段就是救命稻草。6. 实操心得与经验沉淀6.1 建议的稳妥调试顺序调试顺序直接影响心态。我建议拿RV1106G3板子按这个顺序推进先用Rockusb模式把MiniLoaderAll.bin、parameter和原始固件完整烧写一遍确认板子能正常开机。这一步建立了最底层的安全网就算后面fastboot折腾坏了至少知道怎么回到正常状态。然后再配置fastboot环境测试kernel和rootfs的分区烧写。最后才考虑用fastboot更新uboot分区而且务必先备份原厂uboot镜像。配一个自己固定的工作目录把MiniLoaderAll.bin、parameter.img、uboot.img、boot.img、rootfs.img这些镜像按版本归档每次调试用到的文件都放进去不要散落在各个下载目录里。fastboot烧写脚本也放在同一目录脚本里做一步校验确认镜像文件存在再执行烧写避免文件路径写错导致烧了空文件。6.2 容易被忽略的细节最后分享几个不写在文档里、但实操中非常影响体验的细节。第一电源质量比想象中重要。RV1106G3核心板电流需求不大但USB供电和独立电源供电在烧写大镜像时的稳定性差别很大。如果烧写过程中频繁出现传输中断、超时先别怀疑工具和驱动换一个带独立供电的USB HUB或者直接给板子接一个干净的5V电源电流最好在1A以上问题往往就消失了。第二备份原厂固件是最高优先级。拿到板子第一件事应该把整片eMMC或者NOR Flash的镜像备份出来而不是急着烧新系统。瑞芯微的RKDevTool和upgrade_tool都支持读取备份备份文件放到安全的地方。我遇到过很多次调试过程中把板子搞到无法启动都是靠备份固件快速恢复才没耽误项目进度。第三fastboot的报错信息要看成是有价值的线索而不只是“失败”。它说unknown command就是当前U-Boot实现里没有这个指令它说cannot load image就是镜像解析有问题它在某个地址校验失败就是传输过程丢数据或者镜像本身损坏。养成看完整报错的习惯比瞎猜有用得多。第四串口log和fastboot终端不要混用。fastboot的USB通道和串口是独立的两条链路串口打出的信息不会出现在fastboot里fastboot的烧写进度也不会打到串口上。调试时开两个终端窗口一个盯串口一个操作fastboot才能把两侧信息完整对照起来。RV1106G3的fastboot调试本质上就是摸清U-Boot下载模式的工作方式把它的能力边界搞清楚。loader层交给Rockusb系统层交给fastboot两层协同日常开发调试的整个链路就会顺畅很多。如果你现在正被某一块板子的烧写问题卡住照着这篇文章把环境、命令和排查思路过一遍应该能少走不少弯路。
