1. 烧录之前，先搞明白update.img到底是什么
做RK3588开发绕不开烧录这一步。很多人第一次接触这个芯片时，手里拿到的往往是编译好的out目录、零散的镜像文件，或者一个打包好的update.img，却搞不清楚这几者之间到底是什么关系，也不知道为什么网上教程都在说“用RKDevTool烧update.img”。
先把概念理清楚。RK3588这套平台里，所谓的“烧录固件”其实包含两层意思：一是把单个分区镜像（比如boot.img、rootfs.img）单独烧到设备上，二是把这些镜像打包成一个完整的update.img，一次性烧录整个系统。日常调试时我们可能只改了一个内核，直接单独烧boot.img就行；但如果你要交付给产线、或者要给别人的板子刷一套完整系统，那就必须制作整包update.img。
update.img本质上就是一个“集装箱”，它把uboot、kernel、dtb、根文件系统、userdata等所有分区镜像，连同分区表配置一起封装成一个文件。烧录工具拿到这个包之后，会先解析里面的分区布局，再按照配置把各个镜像写到对应位置。
这里要特别强调一个容易被忽视的点：update.img不是一个简单的文件拼接。它包含了专门的头部结构、分区描述信息、镜像数据块，并且要满足瑞芯微烧录工具能识别的格式规范。如果只是拿cat命令把几个镜像强行拼在一起，烧录工具根本不会认。这个格式规范由瑞芯微的打包工具链保证，具体就是afptool和RKImageMaker两个工具配合完成。
另外还有一个常见的认知误区：很多人以为烧录就是把文件“复制”到设备里。实际上，RK3588的烧录过程是直接对存储介质（eMMC或NVMe SSD）进行块的读写操作，烧录工具通过USB向设备发送协议指令，设备端的loader程序接收指令后把数据写入对应的物理地址。这意味着烧录过程中绝对不能断电、不能拔USB线，否则轻则系统损坏，重则把bootloader区域写坏，导致设备没法正常启动。
1.1 RK3588的分区布局：看懂parameter文件，烧录就成功了一半
不管是打包update.img，还是用RKDevTool单独烧录，都绕不开一个文件——parameter。它是整个固件布局的灵魂，记录了设备上存储空间的分配方案。
RK3588的parameter文件通常长这样：
FIRMWARE_VER: 1.0 MACHINE_MODEL: RK3588 MACHINE_ID: 007 MANUFACTURER: Rockchip MAGIC: 0x5041524B ATAG: 0x00200800 MACHINE: 0xffffffff CHECK_MASK: 0x80 PWR_HLD: 0,0xA,0x01,0x00 CMOS_BL: 0x00000000 DDR_SIZE: 0x0 LOADER_ENTRY: 0x2000 ... CMDLINE: mtdparts=rk29xxnand:0x00002000@0x00004000(uboot),0x00002000@0x00006000(misc),0x00010000@0x00008000(boot),0x00010000@0x00018000(recovery),0x00010000@0x00028000(backup),0x00020000@0x00038000(rootfs),0x00040000@0x00058000(userdata),-@0x00098000(metadata)这段配置看起来像天书，但它的逻辑非常清晰。CMDLINE里的mtdparts字段定义了一个个分区：分区的名字、起始地址、大小。后面打包工具和烧录工具都是靠解析这个字段来知道“哪个镜像该写到哪”。
举个例子，0x00002000@0x00004000(uboot)表示uboot分区从偏移0x4000处开始，大小0x2000个扇区（RK平台的一个扇区通常是512字节）。也就是说，uboot镜像实际写入的位置是0x4000 * 512 = 0x200000这个字节偏移处。理解了这个换算关系，你在用RKDevTool单独烧某个分区时，才能正确地填写烧录地址。
1.2 打包工具链：afptool、RKImageMaker、package-file各自扮演什么角色
瑞芯微的固件打包流程是一套固定的流水线，核心工具是rockdev目录下的脚本，而脚本背后调用的是afptool和RKImageMaker这两个可执行文件。
先说package-file。它是一份清单文件，内容是“逻辑分区名 -> 实际镜像文件”的映射关系，例如：
# NAME Relative path package-file package-file parameter parameter.txt uboot Image/uboot.img misc Image/misc.img boot Image/boot.img recovery Image/recovery.img rootfs Image/rootfs.img userdata Image/userdata.img这个文件的作用是告诉打包工具：整包里要包含哪些分区镜像，每个镜像在包内叫什么名字。打包时，afptool会读取这份清单，把所有文件按规则组装成一个固件包，再通过RKImageMaker加上头部信息，生成最终的update.img。
整个打包流程通常不需要你手动去敲afptool那行命令，SDK里自带了mkupdate.sh脚本，直接运行就会自动完成。但理解背后的原理很重要，因为当你需要定制系统（比如裁剪掉recovery分区、增加一个私有分区）时，你得知道问题出在哪一层：是package-file写错了，还是parameter分区表没对应上。
注意：修改package-file的同时，必须同步修改parameter里的分区表。两者如果不一致，烧录时工具要么报错，要么会把镜像写到错误的位置，造成系统无法启动。
1.3 为什么Windows下烧录要用RKDevTool，它到底做了什么
RKDevTool是瑞芯微官方提供的Windows烧录工具，全称是Rockchip Development Tool。它通过USB与设备通信，需要设备端的loader（引导程序）配合。
设备端有两种工作模式：Loader模式和Maskrom模式。Loader模式是正常的烧录模式，设备里的bootloader代码还在，能响应工具指令；Maskrom模式则是把bootloader区域也清掉或损坏后，芯片内部ROM里的一段固化代码在USB枚举时呈现的“最底层”状态，用于救砖。
RKDevTool的核心功能有三个：驱动管理、烧录配置、烧录执行。驱动管理解决的是USB识别问题；烧录配置解决的是“烧什么、烧到哪”的问题；烧录执行则是真正把数据写入设备。理解这三层职责，很多烧录失败的问题就能快速定位：设备不识别，先查驱动；烧录报地址错误，先查配置；烧到一半卡死，再查线和供电。
2. 从零制作update.img：完整打包流程与配置细节
我自己第一次打包RK3588固件时，踩了不少坑。当时拿着SDK编译完Android源码，以为直接运行mkimage.sh就能出包，结果发现还需要整理镜像、确认parameter、跑mkupdate.sh。这个流程虽然不算复杂，但每一步都有细节，漏掉一个就前功尽弃。
开始动手前，先明确你手上的材料。完整的update.img制作需要以下几类东西：
- 编译产物：uboot.img、boot.img（包含kernel和dtb）、rootfs.img或super.img（Android系统镜像）
- 配置文件：parameter.txt、package-file
- 打包工具：afptool、RKImageMaker（SDK的rockdev目录下自带）
有一部分板卡厂商（比如正点原子这类开发板厂家）会直接提供打好包的完整SDK，你第一次编译之后，在rockdev/目录下就能看到Image文件夹和打包脚本。如果你是裸板开发，没有SDK，只要拿到了对应芯片的源码包，也能找到这套工具链。
2.1 制作update.img的准备：先理清镜像产物，不然打包就是空谈
先用一个表格来梳理RK3588平台常见的分区镜像及其作用，方便对照核查：
| 分区名 | 镜像文件 | 作用 | 是否可以裁剪 |
|---|---|---|---|
| uboot | uboot.img | 引导加载程序，负责初始化硬件并加载内核 | 必须保留 |
| misc | misc.img | 系统模式切换标记（如recovery模式） | 可以裁剪，但会影响OTA升级 |
| boot | boot.img | 内核、设备树、ramdisk | 必须保留 |
| recovery | recovery.img | 恢复模式系统 | 可以裁剪，不建议裁剪 |
| backup | 无 | 备用分区，用于OTA失败回滚 | 可以裁剪 |
| rootfs | rootfs.img | 根文件系统（Linux）或super.img（Android） | 必须保留 |
| userdata | userdata.img | 用户数据分区 | 可以裁剪为空 |
实际操作中，如果你只是做一个精简的Linux系统（比如rk3588移植Ubuntu），可能只需要uboot.img、boot.img、rootfs.img三个镜像就够了。但如果你的板子还需要支持Android的recovery机制、OTA升级、出厂数据预置等能力，那每个分区就都得保留。
我的习惯是打包前先列一份需求清单：这个固件是给谁用的？产线量产用的，需要一次烧录完整镜像，全部保留；个人调试用的，只保留uboot、boot、rootfs，userdata留空就行；做OTA测试用的，misc、recovery、backup必须保留，否则升级流程没法走通。
2.2 编写package-file：每一行都对应一个分区，格式错误寸步难行
package-file是整个打包流程的“导航图”。它的每一行规定了包内文件与目标分区名的对应关系。我拿一份实际使用过的RK3588 Linux固件package-file来做说明：
# NAME Relative path package-file package-file parameter parameter.txt uboot Image/uboot.img boot Image/boot.img rootfs Image/rootfs.img userdata Image/userdata.img几个关键点：
第一，package-file和parameter这两行是固定的，打包工具需要读取它们本身来获取配置信息，不能删除。
第二，Relative path是相对于打包脚本所在目录的路径。比如Image/uboot.img指的就是rockdev/Image/uboot.img。如果你手动把镜像放在了其他目录，这里要对应调整。
第三，分区名的顺序和数量不需要跟parameter完全一致，打包工具只认名字，不认顺序。但是有一点要注意：你写进package-file里的每个分区名，必须在parameter文件里有对应的定义，否则解包时会报错。
写package-file容易犯的一个错误是手滑多打了一个空格、或者用了Windows记事本特有一些的不可见字符。这个问题虽然低级，但相当隐蔽，会导致打包脚本永远报错“Can not found file”。建议直接用VS Code或者Notepad++编辑，开启显示空格和制表符，保存为LF换行格式。
2.3 修改parameter文件：分区偏移量和大小怎么算，才不会挤出问题
parameter文件的修改是打包流程里技术含量最高的部分，也是出错概率最高的地方。你需要动它的时候，通常是以下场景：增加一个私有数据分区、扩大rootfs分区、删除掉recovery分区的空间等。
以一个实际需求为例：假设板子上有64GB eMMC，默认parameter把rootfs分成4GB，你觉得不够用，想扩到16GB。这时候要修改rootfs分区的大小。原配置是：
0x00020000@0x00038000(rootfs)0x00020000是rootfs的大小，按512字节一个扇区换算就是0x20000 * 512 = 0x4000000字节，即64MB？不对，这只是一个举例。实际RK3588的rootfs分区通常是几个GB的量级，在parameter里就要写0x200000甚至更大的数值。
换算方法很简单：分区大小（字节）= 扇区数 × 512。
修改时要注意分区之间的地址连续性。RK3588的parameter要求每个分区的起始地址必须和上一个分区的末尾地址衔接，不能重叠，也不建议留大段空洞。如果你把rootfs改大了，后面跟的userdata、metadata这些分区的起始地址都要跟着顺延，否则烧录工具写入时会出错。
我的建议是：修改前先用Python或计算器把每个分区的起始地址、结束地址列成一张表，确认没有重叠和错位，再写回parameter文件。这种一次性的计算，重复核对几遍不亏。
2.4 执行打包脚本：mkupdate.sh背后发生了什么，如何确认产物正确
材料准备好、package-file和parameter都确认无误后，就可以执行打包了。进入rockdev目录，运行：
./mkupdate.sh这个脚本的核心动作有两步。第一步，调用afptool把所有分区镜像打包成一个不带头部信息的临时固件包；第二步，调用RKImageMaker给这个包加上头部信息，生成最终的update.img。
脚本执行完，会在rockdev目录下生成update.img。判断打包是否成功，不要只看有没有生成文件，还要看脚本输出的日志里有没有错误和警告。常见的错误有：
Can not find Image/uboot.img：镜像文件缺失，检查路径或编译产物parameter is error：parameter文件格式解析失败，检查分区配置Failed to pack update.img：打包过程出错，多半是磁盘空间不足或文件被占用
生成update.img之后，建议做一次解包验证。用RKDevTool自带的“固件”菜单或者afptool -unpack命令，把update.img解开，看看里面的文件列表是否和package-file一致，分区镜像是否能正常读取。这一步花不了两分钟，但能避免烧录到一半才发现包是坏的。
2.5 生产环境打包：Windows下也能制作update.img，不需要Linux
很多人的认知是“瑞芯微的固件打包必须在Linux下做”，这话对也不对。标准SDK的打包流程确实是在Linux下跑的，但如果你是产线环境、或者手头只有Windows电脑，直接用RKDevTool也能制作整包固件。
RKDevTool的“升级固件”页面里有一个“固件”按钮，选择任意一个已有的update.img，工具会把它解包，展示里面的分区镜像列表。你可以勾选需要的分区、替换成自己编译的镜像文件，然后再点“打包”生成新的update.img。这个功能本质上就是调用了同款打包逻辑，只是帮你把命令行操作封装成了图形界面。
这个功能我自己用过多次，替换内核镜像做批量测试时很方便，不用每次都在Linux打包机前排队。需要注意的是，用这种方式制作的update.img，分区表仍然是基于原固件的parameter，如果你修改了镜像但是分区布局不匹配（比如rootfs大小变了），必须同步修改分区配置再打包。
3. Windows下RKDevTool烧录实战：从驱动到跑条的完整流程
进入烧录阶段，很多人的噩梦从驱动安装开始。特别是Win10、Win11时代，系统对驱动签名要求严格，瑞芯微的驱动如果没有正确安装，设备管理器里永远是黄色感叹号。
整套烧录流程可以拆成四个阶段：驱动安装、设备进入Loader模式、配置烧录参数、执行烧录。每个阶段都有对应的坑，下面逐一展开。
3.1 驱动安装：Win10/Win11下没有官方签名驱动怎么办
打开RKDevTool工具包里的DriverInstall目录，你会看到一个DriverInstall.exe程序。以管理员身份运行，界面里有两个按钮：驱动安装、驱动卸载。
正常情况，点击“驱动安装”，程序会把Rockchip USB驱动装到系统里。但很多人在Win11下会遇到一个问题：驱动装不上，提示“安装失败”或者设备管理器里显示“设备无法启动”。
这通常是驱动签名策略导致的问题。瑞芯微官方驱动在新版Windows下偶尔会触发签名校验失败。解决思路有两个：
第一个思路是临时禁用驱动签名强制。Windows的“高级启动”菜单里有一个“禁用驱动程序强制签名”的选项，选择后重启，再装驱动，成功率很高。这个方法适合一次性烧录，但缺点是重启后签名强制策略会恢复，下次烧录又得重新设置。
第二个思路是使用64位签名版本驱动。较新版本的RKDevTool（比如2.96及以上）自带的驱动已经做了签名处理，Win10 1803之后的系统一般可以直接安装。如果你手头的驱动包比较老，建议先从官网下载最新版RKDevTool再试。
装完驱动后，先别急着插设备，打开设备管理器，确认没有残留的错误设备。如果有感叹号，右键卸载设备并勾选“删除此设备的驱动程序软件”，然后再重装一次。这一步很多人会忽略，导致后续怎么查都识别不了设备。
3.2 进入Loader模式：按住Recovery还是Maskrom，别等设备坏了才学
驱动没问题之后，下一步是把设备切换到Loader模式。
RK3588开发板上通常会有两个按键：RECOVERY和MASKROM（有的板子叫MASK或ROM）。进入Loader模式的标准操作是：先按住RECOVERY键不放，用USB线连接电脑（如果板子已有电源，直接按一下RESET），保持几秒钟，然后松开RECOVERY。
这时候打开RKDevTool，在设备列表区域应该会显示“发现一个LOADER设备”。如果显示的是MASKROM设备，说明设备里的bootloader没有正常加载，这种情况通常属于异常状态，但同样可以用来烧录（救砖场景）。
RECOVERY键的原理是通过硬件拉低某个GPIO引脚，让bootloader启动时进入下载模式。不同板卡厂商对这个按键的定义可能略有区别，有的板子没有单独的Firmware键，而是在Type-C接口旁留了一个镀金焊盘，需要拿镊子短接。拿到一块新板子时，先看原理图或者板卡丝印，别上来就乱按。
Maskrom模式则不一样，它不需要板子里的bootloader参与，直接由SoC内部的ROM代码引导USB枚举。进入Maskrom的条件通常是：eMMC里完全没有可引导的代码，或者你短接了Maskrom引脚强制跳过外部存储启动。
3.3 RKDevTool配置烧录参数：地址和分区名怎么填才不错
设备识别成功后，RKDevTool主界面的右侧会列出所有可烧录的分区。默认情况下，工具已经自动从parameter文件里读出了分区布局。
你需要做的操作是：勾选要烧录的分区，点击每个分区对应的路径，选择本地镜像文件。这里有两个容易出错的地方：
第一，不要随便改动“地址”列的数字。工具已经根据parameter自动填好了每个分区的烧录地址，强行修改只会导致数据写到错误位置。如果你确实需要手动指定分区地址（比如parameter里没有定义某个新分区），建议先在parameter里加上对应的分区表项，让它自动识别。
第二，分区名和镜像的对应关系，以parameter里的分区名为准，不是以文件名为准。举例来说，你有一个编译好的boot_linux.img，但它最终要烧到boot分区，那在工具里应该勾选“boot”这一行，给它指定boot_linux.img这个文件路径。如果你勾选了别的行，即使镜像文件内容是正确的，烧录后系统也起不来。
烧录模式的选择也很关键。RKDevTool提供“擦写模式”“强制擦写模式”“普通模式”等选项。正常情况下选普通模式就行；如果你希望烧录后userdata被清空（恢复出厂状态），可以勾选“烧录时擦除userdata”；如果设备里还有旧固件的残留导致烧录异常，用强制擦写模式能绕开部分校验。
3.4 烧录执行：从点“升级”到进系统的完整过程记录
配置完成后，点“升级”按钮，工具开始执行烧录。以下是正常烧录过程中你会在界面下方进度条看到的阶段：
第一阶段是“准备IDB”，工具会向设备发送擦除和初始化指令，清空一部分关键区域，这个过程很快，几秒钟就完成。
第二阶段是“上传Boot”，工具会把一个烧录专用的loader传输到设备内存中运行，跑起来之后设备会重新枚举USB，界面上可能短暂显示设备断开又重新连接。
第三阶段是“烧录”，按配置逐一分区写入。每个分区写入时进度条会跳动，写入速度取决于USB带宽和镜像大小。一个2GB的镜像，在USB 3.0下大约需要2到3分钟。
第四阶段是“校验并重启”，写入完成后工具会读取部分关键数据校验，然后自动发送重启指令。设备应该正常重启进入新系统。
整个烧录过程中，务必保持USB连接稳定，不要触碰到连接头，不要给设备断电。我不止一次遇到过因为Type-C线松动导致烧录中断的案例，轻则重新烧一遍，重则bootloader损坏需要进Maskrom救砖。建议使用原装或质量可靠的USB线，避免用那种“能充电但数据线芯不完整”的劣质线。
3.5 单分区烧录：调试场景下没必要整包重刷
特别说明一个日常开发中最常用的场景：你只改了内核代码，重编了boot.img，完全没必要把整个update.img重烧一遍，直接单独烧boot分区就行。
操作步骤是：设备进入Loader模式，在RKDevTool里只勾选boot这一行，选择新的boot.img，点击“升级”。工具只会擦写boot分区，其他分区的数据完整保留。
这个功能在调试阶段能节省大量时间。我参与rk3588部署yolov8模型时，经常要反复调试内核驱动和硬件编解码，每次改动只是一小部分代码，整包重刷一次10多分钟，单分区烧录不到1分钟。开发效率差距非常明显。
不过单分区烧录也有前提：新镜像必须和现有系统保持兼容。比如你改了内核配置，导致新的dtb和旧的根文件系统不匹配，那单独烧boot分区可能会起不来。遇到这种情况，别急着怀疑烧录过程，先想想系统内部的一致性。
4. 常见问题与排查技巧实录
下面整理的是我实际烧录RK3588板子过程中遇到的典型问题，每个都踩过坑、花过时间排查，分享出来希望对你有帮助。
4.1 设备不识别、驱动感叹号，怎么一步步排查
症状：设备插入后，RKDevTool显示“没有发现设备”，设备管理器里能看到一个未知设备或者带有黄色感叹号的Rockchip设备。
排查思路从三个维度展开：
第一，更换USB口。有些电脑的前置USB口供电不稳定，或者USB Hub存在兼容性问题。直接使用主板背板的USB 3.0口通常更可靠。
第二，检查驱动安装。设备管理器里把那个感叹号设备卸载，拔掉USB线，重装驱动，再插上设备。如果还是不行，试试前面说的禁用驱动签名强制。
第三，确认设备状态。按住RECOVERY键再接USB，看是否能在设备管理器里看到设备枚举变化。如果还是不行，把RECOVERY键操作换成Maskrom模式，排除是bootloader没有启动导致设备无法进入下载模式。
4.2 烧录到一半卡住、进度条不动，怎么定位故障点
这是个非常典型的问题，经常发生在“上传Boot”之后的“准备IDB”阶段。
先说结论：90%的情况是设备端loader在擦写eMMC或NVMe时卡住了，或者USB通信不稳定导致数据流中断。
实际排查时，先等5分钟，有些时候是擦写慢，不是真的卡死。如果5分钟后进度条还是纹丝不动，直接把设备断电重启从头烧一遍，大概率能过。
如果反复在同一个地方卡住，重点怀疑两个原因：一是旧的parameter里包含了一个大分区（比如userdata 30GB），擦写时耗时较长；二是eMMC或NVMe存在坏块，擦写到某个区域时一直重试失败。
对于前者，可以试试在配置里勾选“擦写”但只烧关键分区，或者把userdata去掉不烧录。对于后者，只能尝试进入Maskrom模式，用底层方式擦除整个存储，再重新烧录。如果Maskrom模式下依然卡住，建议查一下硬件供电是否稳定、eMMC芯片是否虚焊，这个就属于硬件维修范畴了。
4.3 烧错固件变砖了，怎么用Maskrom救回来
“变砖”这个说法听着吓人，但在RK3588平台上大多数变砖都可以救回来。因为芯片内部ROM里的代码是不可擦除的，它永远在那里，只要板子供电正常，就一定能识别成Maskrom设备。
救砖步骤：
- 设备断电，短接（或按住）Maskrom引脚/按键。
- 接USB线到电脑，等待设备管理器出现新设备，或者RKDevTool显示“发现一个MASKROM设备”。
- 在RKDevTool里选择“升级固件”页签，加载一个你确信能正常工作的update.img。
- 点击“升级”，工具会通过Maskrom模式把完整的固件写到存储设备里。
- 烧录完成后断电，取消短接，重新上电启动。
需要注意，Maskrom模式下工具不会区分分区，它直接把整个固件包写入存储的起始地址，相当于彻底重建了存储布局。因此必须使用完整的update.img，不能只选部分分区。
如果你手头连一个可用的update.img都没有，那就比较麻烦了。需要从官方拿到最小可启动固件，或者用另一台正常的同型号设备，通过dd命令把整个eMMC镜像备份出来，再烧回去。这也是为什么我一直强调：拿到新板子第一件事，先备份原厂固件。这个习惯能让你在之后的折腾中立于不败之地。
4.4 烧录成功但无法开机，怎么区分是系统问题还是烧录问题
设备烧录完成后，工具显示成功，但设备上电后黑屏，或者卡在logo界面反复重启。
这种问题不要第一时间怀疑烧录过程，而是先判断系统本身能不能工作。我的排查顺序是：
先看串口日志。RK3588开发板一般都有调试串口，连接后重新上电，观察bootloader输出。如果串口完全没有输出，说明uboot没有正确加载，问题出在uboot分区或eMMC启动配置。
如果串口能看到uboot启动信息，但在加载kernel时报错，重点检查boot.img里的内核版本、设备树是否匹配。rk3588的dtb如果和板型不匹配，最常见的结果就是启动到一半屏幕闪烁或者死在某个驱动初始化上。
如果内核起来了但挂载不了根文件系统，优先确认rootfs分区烧录的镜像是否正确、parameter里的rootfs地址是否与镜像实际大小匹配。
另一个很容易忽略的问题是存储介质选择。有些板子同时支持eMMC和NVMe启动，你在RKDevTool里烧到了eMMC，但板子的启动拨码开关却设置成了NVMe优先，结果自然是找不到系统。遇到“烧完起不来”的情况，先检查板卡的启动介质选择，这个检查只需要几秒钟，比折腾一堆软件配置要快得多。
4.5 关于烧录工具选型的补充说明
市面上还有一些第三方烧录工具（比如Etcher、balenaEtcher），它们也能把镜像写入存储卡或USB设备。但用在RK3588这种板级烧录场景时，我不推荐用这类通用工具。原因是它们适合烧写“整卡镜像”（类似树莓派的img文件），而RK3588的分区烧录协议、Loader模式通信、校验机制都需要专用工具配合。
如果你做的是企业级量产，瑞芯微官方还有专门的工厂烧录工具和生产测试方案，支持一拖多同时烧录、序列号写入、MAC地址烧写等功能。这些工具通常由方案商提供，个人开发者一般接触不到。个人开发者和产线小批量生产，用RKDevTool完全够用。
4.6 日常维护：如何备份和还原一台RK3588设备
最后想说说备份。前面提过拿到新板子第一步就是备份原厂固件，这里详细说一下怎么操作。
在Linux主机上，设备正常启动后，可以用dd命令把eMMC的整个内容导出为一个镜像：
sudo dd if=/dev/mmcblk0 of=backup.img bs=4M status=progress然后用瑞芯微的upgrade_tool或Linux下的rkdeveloptool，把这个备份镜像烧录到其他设备上，就能实现整机克隆。实测在批量部署时非常有用：你只需要调试好一台设备的系统和环境，然后把它做成镜像，批量烧录到其他设备上，能在很大程度上节省重复配置时间。
在Windows下做完整备份也有办法。用RKDevTool进入Loader模式，在“设备分区表”页面可以逐个分区导出镜像，导出后再用“固件”打包功能合成一个update.img，相当于做了整包备份。这个方法适合不熟悉Linux操作的用户。
从我个人的经验来看，备份原厂固件的价值怎么强调都不过分——RK3588方案千奇百怪，不同板卡的外设配置、DDR初始化参数、电源管理策略都不同。官方出厂固件是你排查问题时最重要的对照物。很多疑难杂症，只要把原厂固件烧回去，就能确认是软件改动问题还是硬件故障，直接帮你在排查时节省大量时间。
