1. 项目背景：RV1106G3平台的fastboot调试到底是怎么回事
做嵌入式Linux开发的人，应该对瑞芯微（Rockchip）的方案不陌生。RV1106系列是瑞芯微面向安防IPC（网络摄像头）、智能门铃、低功耗AI视觉设备推出的一条产品线，集成了ARM Cortex-A7单核CPU（部分型号是双核）、0.5TOPS算力的NPU，以及一颗自带3A（自动曝光、自动白平衡、自动对焦）能力的ISP，主打的就是低成本、低功耗、高集成度。RV1106G3则是这个家族里的一个具体型号，后缀G3通常对应某类DDR（内存）配置或封装版本，本质上还是同一套SoC平台，调试思路是通用的。
那fastboot在这类平台上扮演什么角色？简单说，fastboot是一种基于USB的底层刷机协议，在设备还没有完全启动到Linux系统的时候，由bootloader（在瑞芯微平台上通常是U-Boot）提供的一个调试烧录通道。通过fastboot协议，你可以直接往设备的eMMC（或者SPI NOR/NAND Flash）里写分区镜像，也可以在系统起不来的时候执行一些底层命令，把机器救回来。它是“设备变砖”之后最后一道防线，也是产线烧录、固件升级的核心通道之一。
我做这个项目的时候，手里拿到的是RV1106G3的开发板，跑的是瑞芯微官方SDK里的Linux系统。最开始接触这个平台，习惯性地以为fastboot就是一条命令打进机器里，后来实际搞起来才发现，瑞芯微平台在fastboot的使用上和其他平台（比如高通、联发科）有一些不太一样的细节，尤其是「分区表匹配」和「loader与fastboot的共存关系」这两个点，踩坑踩得非常深。这篇文章把我从环境搭建到分区烧录再到疑难杂症排查的完整过程记录下来，所有内容都是基于RV1106G3实际调试中验证过的操作，应该能帮后面拿到类似板子的朋友少走不少弯路。
2. 先把底子打好：RV1106G3的fastboot环境搭建
2.1 硬件连接和驱动准备工作
调试fastboot，第一件事不是敲命令，而是把硬件环境搞对。RV1106G3开发板上一般有一个USB Device接口（也叫USB OTG口），这个口就是用来做fastboot/adb烧录调试的，千万别拿它跟普通的USB Host口搞混。有些板子上会把烧录口标注为“USB Download”或者“USB DEBUG”，用Type-C口居多，少数是Micro-B口。
连接方式如下：
- 开发板先不要上电，用USB线把电脑和开发板的烧录口连起来；
- 按住开发板上标注为“RECOVERY”或“DOWNLOAD”的按键（有的板子是拨码开关，有的板子还需要配合某个GPIO拉低，具体看原理图）；
- 保持按键按下，给开发板上电（DC电源或者USB供电都行）；
- 上电后等待1~2秒，松开按键。
这一步操作的原理是：RV1106G3的片上ROM（BootROM）在上电后会先检测烧录引脚的状态，如果检测到烧录模式被触发，ROM就会进入下载模式，枚举出一个USB设备。这个模式叫做Maskrom模式或Loader模式，是所有底层烧录操作的基础。实测下来，按住按键上电基本都能稳定进入，比软件命令切换可靠得多。
连接好后，在电脑上打开设备管理器（Windows）或者运行lsusb（Linux），如果看到一个未知设备，或者出现“Rockchip USB”之类的字样，说明硬件链路是通的。如果完全没反应，先换USB线——很多USB线只支持充电不支持数据传输，这个坑我一开始就踩过，排查了半天最后发现是线的问题。
2.2 瑞芯微平台驱动和fastboot工具的选型
驱动问题在Windows下是重灾区。RV1106G3进入下载模式后，Windows默认不认这个设备，需要安装瑞芯微的USB驱动。目前最常用的是两个：
- Rockchip USB Driver（也叫DriverAssitant，瑞芯微官方的驱动安装工具，会把Maskrom、Loader、ADB等模式下的驱动一次性装好）；
- 如果你平时做Android开发，装了Google的USB Driver，有些情况下也能顶上，但不保证全覆盖。
Linux下就简单很多，不需要装驱动，内核自带的usbfs和usb-storage驱动就能识别Rockchip设备。用lsusb确认一下，能看到类似“ID 2207:350b”这样的设备。2207是瑞芯微的USB Vendor ID，不同模式下Device ID会有区别，比如Maskrom模式下是350a，Loader模式下是350b，ADB模式下是0006。记住这个规律对后面区分设备状态非常有用。
fastboot工具本身，推荐直接用Google官方发布的Android Platform Tools里面的fastboot，Linux和Windows都有对应版本。不建议用别的第三方工具，兼容性问题遇到过一次就够头疼了。另外，瑞芯微官方烧录工具RKDevTool里面也集成了一套fastboot工具，但那个主要配合瑞芯微自己的协议使用，和标准的fastboot还是有点区别。我这里讲的都是标准fastboot指令，和Android生态完全通用。
2.3 先验证一条基础命令：fastboot devices
环境准备到位后，先跑一条最基础的命令试试水：
fastboot devices正常情况下会输出一行设备信息，类似：
C3D2E1F4090B fastboot输出格式是“设备序列号 + 状态”。如果能列出设备，说明驱动器、USB链路、协议栈都是通的，可以从这一步开始正式调试。如果这条命令没有任何输出，那后面所有的烧录操作都无从谈起，需要回到驱动和连接上排查。
注意：Linux下执行fastboot命令一般需要root权限，或者给USB设备配置udev规则。否则会出现“no permissions (user in plugdev group)”之类的报错。最简单的做法是sudo执行，想省事的可以写一条udev规则，允许普通用户访问Rockchip的USB设备。
3. 核心操作：RV1106G3分区烧录与fastboot指令实战
3.1 分区布局认知：瑞芯微平台的特定烧录思路
fastboot烧录逻辑很简单：往指定的分区写入镜像。但分区叫什么名字、每个分区对应什么内容，不同平台差别巨大。RV1106G3这块板子的分区布局和Android手机不一样，跟其他嵌入式平台也不同，必须先用瑞芯微的parameter分区表对齐。简单说，parameter文件就是一份分区布局清单，记录了每个分区在eMMC里的起始位置、大小、名字。
以下是典型的RV1106G3分区布局（实际以SDK版本为准，这里是示意）：
| 分区名称 | 起始偏移 | 大小 | 内容说明 |
|---|---|---|---|
| loader | 0x0 | 4MB | 一级引导代码（U-Boot SPL） |
| parameter | 4MB | 4MB | 分区表描述文件 |
| uboot | 8MB | 4MB | U-Boot主体镜像 |
| misc | 12MB | 4MB | 系统启动控制信息 |
| boot | 16MB | 32MB | 内核 + initramfs |
| rootfs | 48MB | 剩余空间 | Linux根文件系统 |
这里最关键的一点是：瑞芯微平台的uboot镜像和俄bootloader是分离的，loader分区由芯片ROM直接加载，uboot分区才是完整的U-Boot程序。fastboot功能就实现uboot里面，所以如果uboot坏了，fastboot也没了，机器只能进Maskrom模式用瑞芯微的升级工具恢复。这也是为什么有的朋友反映系统起不来、想用fastboot救砖却连不上，很可能就是uboot分区已经损坏了。
烧录之前一定要搞清楚当前SDK对应的parameter文件，不要拿A版本的烧B版本。分区名字对不上，最容易出现的就是“fastboot flash xxx unknown partition”这类报错，后文会详细说。
3.2 标准烧录流程：从擦除到写入的完整命令顺序
确认设备能被fastboot识别之后，我习惯按以下顺序操作，这个顺序是经过多次实践总结出来的，能最大限度避免烧出半砖：
第一步，查当前设备信息：
fastboot getvar version fastboot getvar product一般会输出：
version: 0.4 product: rv1106这个步骤的目的有两个：一是确认设备通信正常，二是确认uboot的fastboot版本和SDK预期一致，避免出现版本不匹配导致的低级问题。
第二步，必要时擦除分区：
fastboot erase uboot fastboot erase boot fastboot erase rootfs这里要注意，erase操作是把整个分区清成0xFF或0x00，属于破坏性操作。如果当前固件还能用，只是想更新某个分区，就没必要擦除。擦除存在的意义是在分区内数据格式错误、写入新镜像可能造成冲突时才需要。比如boot分区里之前写了一个损坏的内核，直接改写分区有时候会因为剩余数据残留在某些文件系统场景下出问题，先erase一遍更干净。
第三步，烧录镜像：
fastboot flash loader loader.img fastboot flash parameter parameter.img fastboot flash uboot uboot.img fastboot flash boot boot.img fastboot flash rootfs rootfs.img每条flash指令背后干的事情是：把本地镜像文件通过USB传输到设备端的fastboot缓冲区，由uboot负责写入指定的eMMC分区偏移地址。写入完成后设备会回一个“OKAY”状态，终端上显示“Finished. Total time: X.XXXs”。
这里有个瑞芯微平台的特定细节：loader、parameter这两个分区在正常烧录时建议先烧，因为uboot启动时会去读parameter来获取分区表，如果parameter是旧的，新烧的uboot可能因为分区信息不一致而出问题。我遇到过一次先烧uboot后烧parameter，中间设备重启了一次，结果uboot起不来，只能重新进Maskrom救。
第四步，重启设备验证：
fastboot reboot重启后如果系统能正常起来，说明烧录成功。这个命令本质上是让uboot执行重启指令，不经过操作系统，非常直接。
3.3 单分区更新与产线快速迭代技巧
不是每次调试都需要全量烧录。实际开发中大部分时间是只改了内核或者只改了应用层脚本，这时候全量烧录纯属浪费时间。我常用的做法是：
- 改了内核dts或驱动，只烧boot分区：
fastboot flash boot boot.img； - 改了文件系统内容，只烧rootfs分区：
fastboot flash rootfs rootfs.img； - 改了U-Boot配置，只烧uboot分区：
fastboot flash uboot uboot.img。
这里有几个实操经验值得分享一下：
第一，boot.img在瑞芯微SDK里往往是内核和dtb打包在一起的，改完内核用SDK的编译脚本生成新的boot.img，烧进去生效。如果只改了设备树，极端情况下可以用fastboot flash dtb dtb.img单独烧dtb分区，但前提是parameter里定义了单独的dtb分区，否则还是老老实实烧boot。
第二，rootfs分区如果用的是ext4格式，烧写后第一次启动时文件系统可能会自动做一次resize，这个过程需要几秒钟，属于正常现象，不用慌。如果用的是squashfs这种只读文件系统，就不存在这个问题，但临时修改文件系统内容就很麻烦，所以调试阶段我都用ext4。
第三，产线或者快速迭代场景下，不要频繁做erase操作。eMMC的擦除会消耗P/E周期，虽然现在的eMMC寿命已经很长，但每次全量擦除+重写对存储介质总归是磨损。只做flash写入、跳过erase，大多数情况下没问题。
4. 实战解析：RV1106G3调试中遇到的典型报错与排查方案
4.1 “fastboot连不上”类问题：设备枚举失败的常见原因
这是所有fastboot调试中出现频率最高的问题。现象是：设备已经按流程进入下载模式，但fastboot devices死活不认，或者干脆设备管理器里就看不到设备。我归纳下来有四个高频原因：
驱动没装对或没生效。这个问题在Windows上最常见。解决办法是打开设备管理器，如果看到带感叹号的未知设备，右键更新驱动，手动指定到Rockchip Driver的安装目录。注意装完驱动后要重新插拔USB线，或者重启电脑，否则驱动状态不会更新。
USB线是充电线，不支持数据。别笑，真的有一半以上的“连不上”是这个原因。普通USB线内部只有电源线，没有数据线。建议备两根短线、质量好的数据线作为调试专用线，能省下大量排查时间。
USB口选错或者供电不足。台式机优先用机箱背板的USB口，不要用前置扩展口，尤其是那种通过排线转接的前置口，信号质量差很容易导致高速USB枚举失败。笔记本的话尽量用直连的口，不要经过扩展坞。RV1106G3开发板部分场景下需要外部供电，如果只靠USB口供电，电流不够会导致设备反复枚举、断开、再枚举，现象看起来就是“时好时坏”。
设备其实没进fastboot，而是一个黑屏或者半死状态。RV1106G3进了fastboot之后屏幕（如果有HDMI或MIPI屏）一般会停留在uboot的logo，或者完全黑屏，只靠外观判断很容易误判。最可靠的方式是看USB枚举出来的设备ID：Maskrom是2207:350a，Loader是2207:350b，ADB是2207:0006。如果看到350b，说明uboot起来了，fastboot应该就在；如果看到350a，说明uboot没起来，正在Maskrom，此时只能走瑞芯微升级工具，标准fastboot是进不去的。
4.2 “unknown partition”报错：分区名不匹配的根本原因与对策
``fastboot flash unlock unknown partition`这条错误在搜索热词里出现了，显然很多朋友在烧录时都撞到过。这个报错翻译过来就是“烧录目标分区不存在”。原因几乎都是同一个：parameter分区表里的分区名和你在fastboot命令里写的分区名对不上。
RV1106G3这套平台，出现unknown partition的高发场景是：
- 手里有个通用fastboot烧录脚本，脚本里写的是Android平台的分区名（比如system、vendor、bootloader），直接拿来烧瑞芯微平台，必然报错；
- SDK版本更新后分区布局改了，老参数和新镜像不匹配；
- 直接
fastboot flash unlock想解锁OEM锁，但瑞芯微平台压根没有独立的unlock分区概念，这命令自然找不到目标。
排查思路很清晰：先通过串口或者烧录工具拿到当前设备的parameter分区表，查看实际的分区名列表。可以在uboot命令行里输入parameter print或print partition，能看到类似这样的输出：
partitions: loader:0x0:0x400000:raw, parameter:0x400000:0x400000:raw, uboot:0x800000:0x400000:raw, ...这份输出就是设备当前真实的分区布局，照着这里的名字去执行fastboot flash就绝对不会报unknown partition。
如果手头没有串口，也可以在PC端用瑞芯微的parameter文件比对，比如SDK里有个parameter-emmc.txt，打开看分区定义，跟你要烧的分区名对齐。生产环境中，我见过有人为了省事把脚本里的分区名写了一个统配的“all”，这在其他平台上可以一次烧全部分区，但瑞芯微平台的fastboot不认这种写法，老老实实逐个分区烧最靠谱。
提示：瑞芯微平台烧录时，有些文件不是直接对应分区名的。比如parameter分区烧的是parameter.img，但里面封装的内容其实是parameter的文本描述加校验信息。不建议用fastboot flash这个方式去改parameter，更稳妥的是在Maskrom模式下用升级工具统一处理。
4.3 烧录中断或校验失败：传输层的隐性坑
还有一种现象是烧录过程中报写入失败或者校验不通过，类似“FAILED (remote: write failed)”或者“(remote: verify failed)”。这种多半不是分区的问题，而是USB传输不够稳定，或者镜像文件本身有问题。
USB传输稳定性的坑，我的经验是这个平台的fastboot工作在高带宽模式下，对USB信号质量比较敏感。如果连接线过长（超过1米）、线材过细、或者USB口扩展过多，镜像文件超过几十MB之后传输就容易出错。解决办法是用短线、直接拔插主机USB口、不要在烧录的同时跑大量USB带宽应用。
镜像文件校验失败的话，先在本机重新解压或重新编译一次镜像，确认文件大小和md5和原始产物一致。之前遇到过SD卡拷贝过程中镜像被截断的情况，烧进去之后系统起不来，后来用ls -l对比文件大小才发现镜像本身就缺尾巴。养成烧录前检查文件完整性的习惯能省很多事。
另外，如果某次烧到一半被中断，设备状态可能变成一种“半烧状态”。此时不要慌，按住烧录键重新上电进Maskrom模式，用瑞芯微升级工具全量烧回一个基础固件，再进fastboot继续调试。虽然没有fastboot那么轻量，但能兜底，这是每个做瑞芯微平台的人必须掌握的后手。
5. 进阶技巧与效率工具：让fastboot调试一天省出两小时
5.1 把常用烧录流程固化成脚本
实际开发中，每天烧录几次甚至十几次是常态。每次都手动敲那几条fastboot命令既慢又容易出错。我一般会把常用流程写成一个shell脚本，放工位上随便调。一个最基础的全量烧录脚本长这样：
#!/bin/bash # 全量烧录脚本，适用于RV1106G3标准分区布局 set -e echo "等待设备连接..." fastboot devices echo "开始烧录loader" fastboot flash loader loader.img echo "开始烧录parameter" fastboot flash parameter parameter.img echo "开始烧录uboot" fastboot flash uboot uboot.img echo "开始烧录boot" fastboot flash boot boot.img echo "开始烧录rootfs" fastboot flash rootfs rootfs.img echo "烧录完成，重启设备" fastboot rebootset -e的作用是：任何一条命令失败就立即退出，不会继续执行后面的烧录，避免在错误状态下造成更严重的固件损坏。这个细节很重要。
如果是单分区更新，可以给脚本加参数，通过$1传入要烧的分区名，灵活调用。长年累月用下来，这个脚本帮我省了太多重复劳动，也避免了手动敲错分区名的低级事故。
5.2 善用fastboot getvar和oem命令做状态诊断
除了烧录，fastboot还能用来做设备状态诊断。RV1106G3的uboot实现了不少getvar变量，常用的是：
fastboot getvar all会输出一长串变量，包括product、serialno、partition-size等。通过partition-size可以确认某个分区的实际大小，比如：
fastboot getvar partition-size:boot如果返回的大小和你预期不符（比如parameter里定义了64MB但返回显示只有32MB），多半是parameter没生效，可以从这个点入手排查。
部分uboot还支持fastboot oem开头的厂商自定义命令，可以用来做复位、进入Maskrom等操作。具体支持哪些命令，进入uboot命令行后敲fastboot oem help查看。这类命令没有统一标准，不同SDK版本差异大，但作为调试入口非常有用。比如某些版本支持fastboot oem reboot2loader，一条命令就能让设备重启进loader模式，不用再手动按键，对自动化测试非常有帮助。
5.3 日志与双通道调试：串口配合fastboot的黄金组合
fastboot模式下的调试信息并不多，因为它是一个精简的协议栈，不会输出太多log。真正在系统起不来的时候，光靠fastboot很难定位问题根因。我的习惯是：连接fastboot的同时，一定把UART串口线也接上。串口线一头接开发板的调试串口（通常是UART0，TTL电平，波特率1500000——瑞芯微平台默认这个波特率，比其他平台常见的115200要高），另一头接USB转串口模块，电脑上用minicom或SecureCRT打开。
烧写完镜像重启设备时，串口会打出完整的启动日志，从BootROM到U-Boot再到kernel，每一阶段的打印都有。如果系统起不来，串口最后的打印就是判断问题的关键线索。比如：
- 如果串口停在
DDR Version打印之后，说明DDR初始化失败或loader不匹配； - 如果停在
U-Boot 2017.09的banner之后没有继续，说明uboot在定位parameter或env的时候出了问题； - 如果kernel解压后panic，说明boot分区里的内核和设备树不匹配。
fastboot负责“把镜像送进去”，串口负责“看镜像跑起来之后发生了什么”。两者配合起来才是完整的调试闭环，单靠任何一边都是瘸腿走路。我在项目前期的教训是：图省事只接fastboot不接串口，结果boot烧进去之后反复重启，瞎猜了一天，最后接上串口一看，是内核设备树里DDR容量配置和实际板载DDR不一致，三分钟定位完成。
6. 产线与量产场景下的fastboot批量烧录心得
6.1 产线模式识别：从“Gree已进入fastboot下载模式”说起
搜索结果里有一条“gree已进入fastboot下载模式请用usb连接电脑进行软件升级”，这个其实是格力家电产品（比如空调、风扇的控制面板或联网模块）的升级提示。家电类产品用瑞芯微方案，通过fastboot做固件升级，这个操作在消费电子产线上太常见了。它跟我们开发板调试的逻辑是一模一样的：设备端进入fastboot下载模式，PC端发送固件。
这个场景给我们的启示是：fastboot不只是开发者用来调试的工具，它同时也是量产产线烧录和售后维修升级的通道。所以遇到这种“进入下载模式请连接USB”的提示，别当成系统bug，这其实是设备运行正常、固件需要升级的标准动作。对应的PC端操作，依然是驱动安装、设备识别、镜像推送这套流程。
6.2 批量烧录的产线落地要点
产线批量烧录和开发板调试有几个明显区别，这些区别决定了产线的流程设计：
第一是尽量不依赖人手按键触发。产线工人一天要烧几十上百台设备，每一台都去按键进fastboot不现实。实践中一般通过治具（夹具）在上电时自动拉高/拉低烧录引脚，让设备一上电就自动进入烧录模式。RV1106G3的烧录引脚在硬件设计时需要预留出来，接到治具的继电器或者电子开关上。
第二是脚本要有失败重试和良率统计。产线的烧录脚本和开发用的快速脚本不一样，要记录每一台设备的烧录结果、耗时、失败原因。可以基于fastboot命令的返回值做判断，配合扫码枪实现SN和设备一一绑定，确保每一台烧进去的镜像版本可控可追溯。我见过最简单的产线方案就是PC上跑一个Python脚本，调subprocess执行fastboot指令，把输出重定向到日志文件，再结合条形码解析自动归档。
第三是固件包要做好版本校验。产线经常出现不同批次产品用不同版本固件的情况，一旦烧错版本，轻则功能异常，重则整批返工。最有效的办法是在固件包名字里带上清晰的版本号和适用硬件型号，脚本里做一次关键字匹配，不匹配就终止烧录。这属于流程上的防呆，比任何技术手段都管用。
6.3 售后升级场景：面向用户侧的fastboot按钮
如果产品已经进入了用户手里，需要远程或本地升级，通常的做法是OTA，但当OTA失败或者用户设备变砖时，就必须靠用户手动进入fastboot模式来恢复。这也是为什么很多带屏设备的系统设置里会有“本地升级”“恢复模式”这样的菜单，本质就是让用户触发uboot的fastboot模式或者recovery模式，然后通过USB线连接电脑，用PC工具推送固件恢复系统。
这个场景里需要注意的坑是：用户在Windows下装驱动是一个巨大痛点。瑞芯微官方驱动对小白用户并不友好，经常出现安装失败或者被安全软件拦截的情况。所以面向售后场景，很多厂商会把fastboot重封装成一个集成安装驱动的exe工具，用户双击运行，工具自动装驱动、自动检测设备、自动推送固件、自动重启，全程不要用户敲任何命令。我在做RV1106G3的方案时，就专门做过一个这样的简易升级工具，打包了驱动静默安装、设备自动识别、固件一键推送、日志自动上传这几个模块，售后反馈效率提升非常明显。
7. 从一个报错说起：fastboot调试中的整体排查思路演练
以标题相关的搜索热词“sprocomm@sprocomm-thinkstation-p300:~$ fastboot flash unlock unknown partiti”为例，这个场景很有代表性：在Ubuntu工作站上执行fastboot flash unlock，报错unknown partition。
这个场景经过前文的分析，是一条非常典型的“命令写错+分区名不匹配”组合问题。我们来走一遍完整的排查流程：
首先，确认设备是否真的在fastboot模式。执行fastboot devices，如果列不出设备，说明问题在驱动或者USB连接，跟unlock命令报错无关。如果设备能列出来，进入下一步。
然后，查一下设备分区表。可以执行fastboot getvar all，或者在串口uboot命令行里打印partition信息，找一下有没有一个叫“unlock”的分区。正常情况下，RV1106G3平台不会有一个专门叫unlock的分区，所以报unknown partition是正常的——不是设备的问题，而是命令目标就不存在。
接着，明确你到底想干什么。如果是想“解锁bootloader”，在标准Android平台上会有对应的分区或者OEM锁机制，但瑞芯微的RV1106G3默认不开启针对fastboot的锁分区机制，开发调试阶段不需要解锁这个概念。如果是为了产线烧录，直接烧你想要覆盖的分区即可，分区名照着parameter走：loader、uboot、boot、rootfs，哪个不对烧哪个。
最后，如果确实需要执行某些厂商特殊命令，去查这个SDK版本的U-Boot源码，里面fastboot命令实现处会列出所有支持的命令和分区。源码比任何文档都靠谱。
这个案例告诉我们一个通用的排查逻辑：报错信息只是结果，不要急着在报错表面找对策，先确认设备状态，再确认分区表，再确认命令目标，最后确认协议版本。按这个顺序排查，多数fastboot问题都能在十分钟内定位。
8. 我在RV1106G3的fastboot调试中踩过的坑与最终心得
最后聊几句实操层面偏个人化、但对后来者很有用的一些体会。
第一个体会是：做单片机、或者普通ARM Linux开发出身的朋友，第一次碰瑞芯微平台时最需要转变的一个观念是——复位和启动流程里，“下载模式”不是额外的软件功能，而是BootROM里的固有代码。你把烧录引脚拉低，设备上电后ROM就必然跑一段下载代码，进Maskrom，不需要任何软件参与。fastboot则是uboot这一层才提供的，所以“uboot坏了fastboot就没法用”是在瑞芯微平台上要学会接受的事实。遇到这种局面，不要再跟fastboot较劲，老老实实进Maskrom用升级工具恢复，十分钟搞定比研究一下午更快。
第二个体会是：调试这种底层玩意儿，环境因素占比远高于技术难度。我前前后后遇到的上百次fastboot连不上的情况中，大概有一半原因是USB线质量问题，三成是驱动和USB口问题，只有两成才是真正的协议或固件问题。所以，给调试环境备两条高质量短线，把驱动装好，在设备管理器里确认设备ID，然后用串口当辅助判断，节奏就对了。被“fastboot连不上adb”这类问题卡住的时候，先怀疑物理层，再怀疑驱动层，最后才考虑软件协议层，这个顺序能帮你省下大把时间。
第三个体会是：流程化、脚本化是提高嵌入式调试效率最快的方式。手动敲fastboot命令没有技术含量，但特别耗时，特别容易在敲错分区名这种低级错误上翻车。写一个可靠的脚本，从设备检测到分区烧录到重启验证一气呵成，不光省时间，关键是每个烧录动作可复现、可记录，遇到问题往回追溯的时候非常方便。这套做法我在RV1106G3项目里用得很顺手，后来换到别的芯片平台，思路也照样能复制。
RV1106G3这个平台本身性能不算亮眼，但它在成本和功能之间的平衡做得很好，尤其适合安防和AIoT类产品。fastboot调试这一关过了，后续的启动流程分析、驱动调试、OTA升级都会顺很多。希望这篇踩坑记录能让你在这条路上少走几个弯路，踏踏实实把设备跑起来。
