1. 先把fastboot在RV1106G3调试里的定位摆清楚手头这块RV1106G3板子在改内核参数的时候被我刷成了一块“砖”——uboot正常内核起不来ADB完全没法用。这种情况下能救我的只有fastboot。很多刚接触这颗芯片的人会把fastboot当成一个烧录小工具实际上在RV1106G3的日常调试里fastboot是个关键的系统级调试入口它不止能刷固件还能检查分区、擦数据、控制启动流程配合串口log基本能覆盖从uboot到内核启动之间所有让人头秃的问题。1.1 它工作在系统还没起来之前RV1106G3这颗芯片属于瑞芯微视觉产品线Cortex-A7单核加一块低功耗NPU跑Linux小系统。很多人听说“能跑Linux”就觉得和普通服务器一样SSH进去什么都不怕。但嵌入式板卡不一样最麻烦的不是应用层而是uboot阶段和内核启动早期。这个阶段没有文件系统、没有网络、没有SSH串口只能敲命令看打印你要真想对存储分区做点什么就只能依赖bootloader里实现的fastboot协议。fastboot是Google在Android时期推广的协议本质上是开发机通过USB与bootloader通信对设备的分区进行读、写、擦除、控制启动模式。瑞芯微的uboot基本都集成有这套实现RV1106G3也不例外。它工作在内核拉起之前所以哪怕你的rootfs已经全毁了只要uboot还在fastboot就还能帮你把rootfs重新刷回去。这是它在调试链路里最独特的位置。1.2 那到底什么样的问题才该找fastboot我自己的判断准则很简单系统完全起不来ADB/SSH用不了怀疑是内核或rootfs的问题就走fastboot刷对应分区。只想清掉用户数据、恢复出厂状态用fastboot erase数据分区。想临时切换启动参数验证某个改动用fastboot里的OEM命令修改启动参数或直接重刷uboot环境。纯应用层逻辑报错、进程崩溃、NPU推理结果不对不该找fastboot而是ADB加日志的方式。分清“该不该用fastboot”能省很多时间。很多人一卡机就喊“要进fastboot重刷”结果发现是应用配置问题白白把环境拆了重建。反过来也有人遇到分区损坏还在操作系统里折腾半天其实早就该进fastboot把system分区刷干净。提示fastboot能做的事都有一个共同前提——uboot本身是完好的。如果uboot分区也被写坏了fastboot这个入口也没了那就只能走瑞芯微的MaskRom模式配合专用工具重新烧uboot。这个边界要心里有数别等uboot刷坏了才来找fastboot那已经晚了。2. 进fastboot前先把这三件环境事处理好有过调试经验的人应该都体会过代码层面的问题往往能查到最气人的是环境问题——明明该进入fastboot电脑就是认不到设备折腾两个小时发现是USB线不对。RV1106G3这块板子在这方面的坑也不浅我每次换新电脑都要重新踩一遍所以单独拎出来讲。2.1 串口线和USB线不能混为一谈RV1106G3开发板上一般有两个接口你天天要用一个是调试串口通常是杜邦线引出或者Type-C转UART另一个是USB OTG口fastboot就是从这里进出。很多人用一根只有充电功能的Micro-USB或Type-C线连上OTG口结果fastboot devices死活看不到设备。这里强调一下连fastboot的线必须是带数据信号的线充电线只走了电源的VBUS和GND数据脚的D/D-根本没接。即便你确认线材是数据线我也建议直接连电脑的原生USB口尽量跳过USB HUB尤其是那种多口供电不足的HUB。RV1106G3在枚举瞬间如果供电纹波大很容易枚举失败。开发板调试时最好用一个独立电源给板子供电USB线只负责数据不要指望电脑的USB口把板子整个带起来——特别是外设带了摄像头模组的时候电流需求会明显上升。2.2 Windows下的驱动与Linux下的udev如果你用的是Windows连接RV1106G3跑fastboot前建议先装好Rockchip的DriverAssitant驱动助手。注意这个驱动覆盖两种运行状态的设备一种是MaskRom/Loader模式下的设备一种是fastboot模式下的设备。有的板卡在设备管理器里显示为“Rockchip ADB Interface”或“Rockchip USB”就是驱动没识别好。装完驱动后设备管理器里应该能看到对应设备再执行fastboot命令才有意义。如果你在Linux下开发驱动这块其实更省心内核自带usb驱动不需要额外装。但权限问题经常挡路非root用户执行fastboot devices大概率返回空列表。我一般在/etc/udev/rules.d/下新建一个规则文件比如51-rockchip-fastboot.rules内容就两行SUBSYSTEMusb, ATTR{idVendor}2207, MODE0666, GROUPplugdev SUBSYSTEMusb, ATTR{idVendor}18d1, MODE0666, GROUPplugdev然后执行sudo udevadm control --reload-rules sudo udevadm trigger重新插拔设备再执行lsusb看看。2.3 供电稳定性是真容易被忽略的一环RV1106G3在uboot和fastboot阶段外设基本还没初始化整体功耗不算高但也有例外如果你的板子上带了屏幕、摄像头模组或者WiFi模块而且这些外设由板子统一供电那么fastboot烧录过程中遇到大文件写Flash时的瞬间电流会明显抖一下。电脑USB口如果本身供电弱或者HUB分担很多设备就可能在这瞬间把总线电压拉低造成USB断连。我的建议调试台上常备一个5V/2A以上的稳压电源给板子单独供电USB只走数据。另外烧录过程中把电脑的休眠、屏保关掉尤其是笔记本合盖自动睡眠这种一旦电脑睡眠USB会话直接断轻则报超时重则把分区表写到一半留下一个不完整状态。这类坑不处理后面所有经验都排不上用场。3. RV1106G3上进入fastboot的三种路径与状态确认环境准备好之后接下来就是怎么把板子弄进fastboot。RV1106G3进入fastboot的方式其实不止一种但网上资料经常把“Loader模式”“MaskRom模式”“fastboot模式”混在一起讲实际操作的时候很容易走弯路。3.1 在uboot命令行随时拉起fastboot最直接、可控性最高的方式是在uboot命令行里手动执行拉起命令。上电后在串口终端里快速敲空格或回车具体按键取决于SDK配置很多瑞芯微板卡默认是空格或回车进入uboot提示符比如rv1106g3#然后输入fastboot usb 0如果uboot编译时使能了fastboot这条命令会启动USB device控制器并进入fastboot循环等待。执行后串口会打印类似“USB device mode enabled”之类的信息之后在上位机fastboot devices就能看到设备。不同SDK版本的命令名可能略有差异。有的版本把fastboot挂成子命令形式有的叫fastboot 0或者直接在rockusb工具里为fastboot另开了端口。稳妥的做法是先敲help在帮助列表里搜“fastboot”“usb”相关条目。不要照着我这里的命令硬套我见过有的板子多了个udev初始化步骤必须先把OTG控制器配好才能起fastboot串口log里会有明确提示。3.2 recovery按键、loader模式和fastboot的纠葛很多瑞芯微开发板上有物理recovery按键上电前按住这个键再上电uboot会检测到并进入Loader模式。Loader模式是瑞芯微烧录工具RKDevTool的工作模式不是标准fastboot。这两者共享USB通道但协议不通用的上位机也不同。所以如果你想用fastboot命令按recovery键进的不一定是fastboot得在uboot源码里确认recovery回调的动作是进了loader协议还是fastboot协议。RV1106G3的SDK里这两种都可能存在不能一概而论。实际操作时最快的判断标准插上线后上位机fastboot devices能不能认到。认不到但RKDevTool能看到设备说明进的是Loader模式如果两个都看不到那可能就是驱动或线材的问题了。我一般不会依赖recovery按键进fastboot因为按下时机和长短都影响结果不如串口里敲命令稳定。recovery按键更适合那种“系统已经完全起不来也进不了uboot”的极端情况但那种时候走的也是MaskRom模式而不是fastboot。3.3 判断“已经进入”fastboot的三个信号进了fastboot之后你不能只盯着板子上的灯看要确认三个信号少一个都可能是假象串口终端有fastboot相关的打印信息比如枚举成功、进入fastboot loop的提示。上位机执行fastboot devices能列出设备格式一般是设备序号加fastboot关键字。设备管理器Windows或lsusbLinux里出现Vendor ID为0x2207的设备。如果你只确认了第三个信号那可能是Loader模式只确认了前两个说明fastboot确实活了。三者都确认就可以放心执行后续命令了。4. 高频使用且真正有调试价值的fastboot指令网上一搜“fastboot指令大全”会出现一大串但很多指令在RV1106G3这种单系统Linux板卡上根本用不上比如刷bootloader和刷recovery还有各种Android分区操作。这里只讲我在实际调试中反复用到的几组以及每条命令背后的判断逻辑。4.1 fastboot devices与getvar all先确认身份再动手进入fastboot后第一件事永远是执行这条fastboot devices正常输出会像1234567890ab fastboot。如果列表为空不要继续往下跑任何flash命令直接回到上一节的排查流程。这里有个小技巧瑞芯微平台有时候设备的VID不是默认的电脑不认识我习惯用下面的命令指定VIDfastboot -i 0x2207 devices0x2207是瑞芯微的USB Vendor ID。如果这样能看到设备说明设备本身没问题只是fastboot工具的默认VID列表里没有瑞芯微而已。确认设备在线之后执行fastboot getvar all这条命令会返回很多变量包括分区名、当前slot、serialno、max-download-size等。这里面我最在意的有两个partition-type系列能确认当前烧录镜像的类型分配max-download-size它决定了上位机单次传输数据块的上限。如果镜像很大而max-download-size很小fastboot会自动分包但有些老版本上位机在这个环节会超时。了解这个上限对后面写脚本反复烧写很有帮助。4.2 flash、erase、reboot刷写动作的参数逻辑刷分区的基本语法很简单fastboot flash boot boot.img但“boot”这个分区名必须和bootloader里定义的分区表完全一致不能想当然。我见过太多人把kernel.img往boot分区里刷结果板卡起不来。RV1106G3的SDK里分区名一般有uboot、boot、kernel、rootfs、misc、recovery这些具体要看parameter.txt或在getvar all里的分区类型输出。烧录前先确认分区名而不是确认镜像名这是刷机和改代码最大区别的一个习惯。擦除操作在调试里也很常用fastboot erase cache fastboot erase misc有些系统起不来是因为启动参数或标志位写坏了erase掉对应的分区往往比重刷整个rootfs快得多。注意erase和flash不可混用尤其不要对uboot分区随便erase一旦没电中断uboot没了就只能走MaskRom救砖了。刷完后重启fastboot reboot如果希望重启后直接进入某个指定流程有的uboot版本支持在重启前设置启动标识可以查一下SDK里是否实现了fastboot oem reboot2loader这样的扩展命令。没有的话就用串口在uboot阶段手动控制。4.3 瑞芯微的oem扩展指令与解锁逻辑瑞芯微的fastboot实现里还有一批OEM厂商扩展指令常见的有fastboot oem unlocked解锁等。这里要提醒和Android手机不同RV1106G3这种嵌入式Linux板卡通常默认就没有锁也不存在强制校验签名的流程所以“解锁”更像是一个流程概念不一定真的需要执行。真正常用的OEM指令反而是那些和烧录状态有关的比如查看当前eMMC或NAND信息fastboot oem get_device_info这类命令输出的内容在不同SDK版本里差异很大唯一正确的使用方式是在uboot源码里搜一下oem命令表。但不管命令如何变调试逻辑是一样的先用查询类指令拿信息再决定要不要执行写操作避免在信息不足的情况下盲目刷分区。5. 连不上、烧一半、校验错三个现场的真实排查记录这部分是全文最值钱的经验全都是我在调试RV1106G3时真实遇到甚至翻过车的问题。每类问题我都按照实际排查顺序记录下来你可以照着走一遍。5.1 连不上从线材、驱动、权限到VID的完整排查当fastboot devices为空时我建议按以下顺序排查不要跳步换一根确定支持数据的USB线尽量短直接插电脑原生USB口。在设备管理器或lsusb里找设备。如果完全没有新设备出现大概率是硬件枚举没成功检查板卡供电和OTG ID脚电平。如果能看到设备但fastboot devices为空先试fastboot -i 0x2207 devices。能看到说明是VID问题配置udev规则或加-i参数。如果是Windows确认Rockchip DriverAssitant装好并且设备管理器里显示的不是感叹号。驱动不匹配时一切命令都会像打在空气上。如果还是不行回串口看打印。uboot里其实会把USB枚举失败的原因打印出来比如没有检测到VBUS、dwc2控制器初始化失败等。第三步里加-i 0x2207这个参数是我觉得最容易被忽略的一步。很多教程默认设备是Google的VID 18d1结果在瑞芯微平台上永远找不到设备。我见过一个情况设备管理器里显示的是“USB Composite Device”但就是没法用fastboot连最后发现是板卡插到了一个雷电坞上雷电坞的USB转发逻辑对device模式的枚举不太友好。换到笔记本自带的口立即就好了。这类环境问题没有统一解法只能靠系统性的排除法。现象可能原因优先处理动作上位机无任何设备出现线材只供电无数据 / OTG未使能换数据线直连原生口确认OTG ID脚电平lsusb能看到2207但fastboot devices为空上位机未识别瑞芯微VID使用fastboot -i 0x2207 devices并配置udev规则设备管理器中出现感叹号驱动不匹配重装Rockchip DriverAssitant换原生USB口板卡串口输出反复重启供电不足或启动镜像损坏换独立电源先串口看细节再决定烧录5.2 烧录中途断开先查时序再查工具烧录到一半突然报FAILED (remote: timeout)或者上位机提示USB device disconnect这种问题在RV1106G3上有几个常见根因。第一个是供电时序。前面说过大文件写Flash时电流会波动如果供电余量不足USB控制器可能先失联。解法是换独立电源并且不要用那种5V/1A的小电源适配器尽量2A以上。第二个是上位机或工具的问题。命令行版本的fastboot在传输大文件时如果host的USB控制器有节能策略也可能出现等待超时。Linux笔记本上可以临时把USB autosuspend关掉echo -1 | sudo tee /sys/bus/usb/devices/2-1/power/autosuspend_delay_ms把2-1替换成实际总线地址。Windows下就把“USB选择性暂停”关掉。第三个是镜像本身太大了超过max-download-size导致分包处理出问题。这时可以看看上位机版本换用平台配套的烧录工具或者直接用SDK里的升级脚本它们对分包和大文件的处理通常比裸fastboot命令更健壮。这也是为什么很多产线烧录不用fastboot而用RKDevTool的原因速度快而且容错好。但调试阶段我仍然偏爱fastboot因为它透明、可脚本化、出错时能精确知道是哪一步断了。5.3 烧进去却起不来分区表与镜像尺寸的问题比“烧不进去”更难受的是“烧进去了却还是起不来”。这类问题十有八九出在两个地方。一是分区名对不上。fastboot flash时分区名写错烧进去的位置其实不是你想覆盖的区域。举一个我自己踩过的例子我把rootfs镜像写进了kernel分区板卡启动时显然起不来串口打印的地址全是错的。排查时看串口log其实能发现端倪但前提是你得先知道分区表。所以刷任何镜像之前先fastboot getvar all拿一遍分区信息看懂了再动手。二是镜像尺寸和分区容量不匹配。rootfs做大了超出分区大小fastboot会报类似partition too small的错误多数情况会被工具拒掉。但有些uboot版本在这个问题上并不严格写到最后直接截断表面显示成功实际上数据是残缺的。判断方法很简单烧完后不要急着重启用fastboot getvar all再确认一次分区信息或者在串口log里看uboot校验是否通过。这类问题一旦没发现后续排查会非常痛苦因为问题根本不在代码在于镜像已经残了。6. 串口加ADB加fastboot一个可复用的调试闭环最后这节整理一下把RV1106G3调试中最常见的三个工具串成一个使用链路串口看日志、fastboot动分区、ADB看运行态。这套顺序我用了很久基本能覆盖日常90%的问题。6.1 串口log永远放在第一步不论你接下来要进fastboot还是进系统先把串口终端打开波特率对准。RV1106G3常见默认波特率是1500000部分模板可能是115200用错波特率会看到乱码。打开串口后按复位键能看到uboot完整启动流程这一步能确认板卡当前到底卡在哪。实际遇到问题我从来不会直接插USB进fastboot刷机一定先看串口。因为一旦进入fastbootuboot的行为和正常启动不同如果你连正常启动都走不通那烧录后能起来的概率也不高。串口log里能看到uboot是否正常加载、内核镜像的起始地址、分区挂载失败的具体报错这些信息会让fastboot操作更有方向。6.2 什么时候留在fastboot什么时候退回ADB很多人容易把fastboot和ADB搞混或者把两者对立起来。其实分工很清楚ADB工作在Linux/Android用户态要求系统内核已经能起来fastboot工作在bootloader阶段不依赖系统。所以在调试时我会这样判断板子能进系统只是某个应用崩溃、服务起不来就留在ADB看logcat或dmesg不要进fastboot。板子起不来怀疑内核或rootfs坏了就用fastboot刷对应分区。板子能进uboot但每次启动到内核就reset先用串口抓log再用fastboot把内核换成带调试信息的版本。内核起来了但用户态rootfs挂载失败用fastboot重刷rootfs必要时erase数据分区再重启。记住这些场景之后你就不会再有“一遇到问题就重刷”的粗暴行为。重刷是最后手段不是第一反应。6.3 用脚本把编译、烧录、日志采集串起来当调试进入反复修改、反复验证阶段手动敲命令的效率就太低了。我会写一个简单的shell脚本把编译、进入fastboot、烧录、重启、串口日志采集绑定在一起#!/bin/bash PARTITION$1 IMAGE$2 PORT$3 echo Flashing ${IMAGE} to ${PARTITION} ... fastboot -i 0x2207 flash ${PARTITION} ${IMAGE} if [ $? -ne 0 ]; then echo !!! flash failed exit 1 fi fastboot -i 0x2207 reboot sleep 5 # 打开串口日志文件持续采集 cat ${PORT} /tmp/boot_$(date %Y%m%d_%H%M%S).log LOG_PID$! sleep 20 kill ${LOG_PID} echo Done. log saved.脚本逻辑很简单但有个好处——每次烧录后会自动记录一份启动log方便回看对比。手工操作时几乎没人会记得保存每次的log真出问题时往往缺证据。脚本化之后至少log是自动留档的。串口工具也可以用命令行版本的picocom或microcom替代图形工具方便嵌入脚本。我之前总是手动开串口助手去截日志现在直接在脚本里起一个串口采集子进程结束再杀掉全程不需要人守着。这套流程跑通之后RV1106G3的烧录调试基本就是“一条命令的事”。如果你是在产线环境更多人会直接用RKDevTool做批量烧录那把fastboot换成工具对应的命令行接口就行思路是一样的先环境排查再信息确认然后操作最后留档。
