☰
RK3588卡刷救砖指南:SDDiskTool制作启动卡全流程
2026/9/28 17:07:54 网站建设 项目流程

1. 为什么说卡刷包是RK3588开发中最该备好的“救生圈”

做RK3588开发的朋友,十有八九都遇到过这种场景:板子刚从包装里拿出来,USB线一插,驱动没装上,设备管理器里一片黄叹号,烧录工具死活识别不到Loader设备。或者固件刷到一半断电,eMMC里的系统彻底没起来,再想通过USB方式补救,发现根本进不了烧录模式。我前前后后帮人处理过很多块“变砖”的RK3588板子,最后的解决方案几乎都落到了同一个工具上:SDDiskTool。

卡刷包听起来像手机ROM圈子的说法,但在RK3588平台上,它的意义更实在:先用SDDiskTool_v1.78把固件写进一张SD卡,再让板子从SD卡启动,把系统刷进eMMC或者直接从SD卡运行系统。这套方案不需要板子进入Loader模式,不需要折腾USB驱动,也不需要拆机短接,只需要一张SD卡和一个读卡器。

这篇文章不是写给我自己看的笔记,而是把整个流程按步骤拆开。从SDDiskTool_v1.78的下载选择、update.img的解析思路、SD卡的准备细节、开始创建前后的注意事项,到配合SDK用的打包脚本和验证脚本,全部展开。适合正在做RK3588项目、需要量产烧录、或者经常把板子刷死的开发者和运维朋友参考。

2. 准备阶段容易踩的坑:工具版本、固件形态和SD卡选择

2.1 SDDiskTool_v1.78不是“随便下一个就能用”的工具

先说工具本身。SDDiskTool是瑞芯微官方发布的SD卡固件烧写工具,专门用来把固件写进SD卡,或者把SD卡恢复成普通存储卡。v1.78这个版本我用了很长时间,最大的优点是支持RK3588、RK3568这些较新芯片,界面上也没有太多花哨的干扰项。

下载渠道不用我多说,搜SDDiskTool_v1.78就能找到。但有个细节必须提醒:下载下来的通常是一个压缩包,解压后里面包含exe可执行文件和驱动目录,第一次运行前最好先看看有没有安装说明。有些版本需要手动安装驱动,否则后面切到“开始创建”时会卡在设备枚举阶段,报错内容还很模糊,容易让人摸不着头脑。

运行的时候右键选择“以管理员身份运行”。这不是仪式感,是Windows权限隔离导致的实际情况。SDDiskTool要向SD卡写入底层扇区,涉及磁盘驱动层的访问,普通权限下经常出现“打开设备失败”或者“写扇区失败”。我见过不少人换了三个读卡器、换了四五张卡都在报同一个错,结果用管理员权限一点就通了。

2.2 update.img到底是个什么东西,为什么不能直接写进SD卡

很多第一次用SDDiskTool的新手会有一个直觉:把update.img像刻录镜像一样直接写进SD卡,插到板子上就能启动。这个直觉是错的。

RK3588的update.img不是一个普通的单分区镜像文件,它是一个“打包了整机固件结构”的复合文件。里面至少包含:

  • MiniLoaderAll.bin:一级引导loader,负责初始化DDR和基础外设
  • parameter.txt:分区表描述,定义了每个分区的大小和起始位置
  • uboot.img:二级引导程序
  • boot.img:Linux内核和设备树
  • rootfs.img:根文件系统
  • misc、recovery、vbmeta等辅助分区

这些内容如果不做重新排布,直接平铺写入SD卡,RK3588从SD卡启动时根本找不到对应的引导信息。SDDiskTool做的事情,就是把这些内容按照SD卡引导的规则重新组织,包括在特定扇区位置写入IDB(Initial Data Block)、生成对应的分区结构、写入对应偏移位置。这才是“制作卡刷包”的本质。

搞清楚这一点,再看SDDiskTool的操作逻辑就不迷糊了。它不是在“复制文件”,而是在给SD卡建立一套可以被RK3588 BootROM识别的引导布局。

2.3 SD卡和读卡器的选择,直接决定成功率和速度

关于SD卡,这里有三个硬性建议。

容量方面,不要低于4GB。RK3588的完整系统镜像动不动就几个GB,特别是带桌面环境或者Ubuntu根文件系统的,8GB起步比较稳妥。如果只做救砖用,4GB也够,但稍微大一点的固件就装不下。

速度等级方面,至少C10或者U1,优先选U3/V30的卡。SDDiskTool写卡是连续大块写入,低速卡会把时间拖得非常长。一张32GB的卡写满8GB镜像,U1卡大概需要十五分钟到二十分钟,U3卡可能只需要五六分钟。更关键的是,写卡过程中如果SD卡写入不稳定,很可能出现校验失败,前功尽弃。

品牌方面,千万不要用那种来路不明的“扩容卡”。我踩过一次,一张标称32GB的卡,实际只有8GB,写到一半数据就乱了,SDDiskTool报错之后,整个分区表彻底损坏。这种问题不是你操作的问题,是卡本身的问题,换张正规渠道的卡立刻就好了。

读卡器优先选USB3.0接口的,尤其是写大镜像的时候,USB2.0读卡器的速度瓶颈非常明显。另外尽量别用那种十几块钱的劣质读卡器,接触不良会导致写卡中途识别不到设备,非常痛苦。

2.4 写卡之前,SD卡要做什么处理

SD卡在写卡之前,不需要做格式化,SDDiskTool会在写卡过程中重建分区结构。但有一个操作我建议做一下:用Windows自带的磁盘管理或者diskpart,把SD卡上的所有分区全部清掉,把它变成一块“未分配”的磁盘。

原因是SDDiskTool在创建卡刷包时,会对SD卡进行整盘覆盖写入。如果卡上残留了之前的分区表,某些版本的SDDiskTool可能会因为识别到已有分区而弹出提示,或者直接在创建中途卡住。提前清理干净,相当于给工具一个干净的画布,能避开很多奇怪的问题。

如果你不想用命令行,也可以在Windows的“磁盘管理”里一步步删除卷,把卡变成未分配空间。注意千万别把电脑的硬盘分区顺手删了,选盘之前确认容量和盘符,这个错误我听说过不止一次。

3. SDDiskTool_v1.78制作卡刷包的核心流程,一步步拆开讲

3.1 先看懂主界面的几个区域,别急着点“开始创建”

SDDiskTool_v1.78的主界面并不复杂,但新上手的人容易在模式选择上搞混。

主界面通常会分成几个区域:左侧或上方是设备列表,显示当前电脑识别到的SD卡;中间是烧录配置区,包含镜像文件选择、烧录模式等选项;下方是日志输出窗口,工具会把每一步操作的结果和错误信息打印在这里。

设备列表里的SD卡,一般会以磁盘编号的形式出现,同时显示容量和盘符。这里一定要对着容量核对是不是你的SD卡,特别忌讳机器上插着U盘、移动硬盘还开着SD卡工具。容量差不多的设备很容易选错,一旦选错,后果就是U盘里的数据全部消失。我自己的习惯是,准备写卡之前先把其他USB存储设备拔掉,只保留目标SD卡和读卡器。

3.2 选择烧录模式和固件路径,这一步决定了SD卡做出来是“启动卡”还是“升级卡”

在SDDiskTool_v1.78的烧录配置区,会有烧录模式相关选项,不同版本的叫法可能有细微差异,一般会包含“SD启动”“固件升级”“量产烧录”之类的大类。命名上的差异不用太纠结,理解每个模式的用途更重要。

如果你想把SD卡做成一个可以让RK3588直接启动系统的卡,那就选择类似“SD启动”的模式;如果你想把SD卡当作一个“烧录中介”,让板子从SD卡启动后把固件写入eMMC,那就需要选择支持升级烧录的模式,然后加载对应的固件。

在固件选择区域,点击浏览按钮,选中你准备好的update.img。选完之后,界面上通常会显示镜像的大小和相关信息。这个阶段建议确认一下镜像大小是否和你预期的固件一致,避免选错文件。

还有个细节:路径中尽量不要包含中文和特殊字符。Windows版本的SDDiskTool对路径的处理有一些本地化问题,路径里有中文时偶发找不到文件。把固件放到一个纯英文路径下,比如D:\rk3588_fw\update.img,能省去很多麻烦。

3.3 点击“开始创建”之后,等待期间别干什么

所有配置确认无误之后,点击“开始创建”。工具会进入写卡阶段,进度条开始滚动。这个阶段耗时和SD卡速度、固件大小直接相关,中途不要做这几件事:

第一,不要拔卡。哪怕进度条看起来卡住不动了,也有可能是底层在写大文件,耐心等。

第二,不要打开其他磁盘工具。Windows资源管理器如果正在访问SD卡,写入动作可能会被系统锁住,导致写卡失败。

第三,不要强行关闭SDDiskTool。如果等了很长时间,比如二十分钟以上进度条几乎没动,你可以考虑任务管理器结束进程,然后把SD卡重新插拔一次,再清理分区重来。强杀进程虽然不优雅,但至少不会让卡一直处于写保护状态。

写卡完成之后,工具会给出成功提示。这时候先别急着拔卡,点击任务栏的安全删除硬件,等系统提示设备可以安全移除后再拔出SD卡。

3.4 做完SD卡之后,先做一道快速验证再上板

SDDiskTool提示创建成功,不代表就万事大吉了。我在实际使用中养成了一个习惯:拔出SD卡之前,先在电脑上对卡做一次快速读取验证。

最简单的验证方式是重新插拔SD卡,看系统能否识别到一个带分区的磁盘。如果Windows弹出“需要格式化”的提示,这是正常的,因为SD卡上的分区不是Windows能识别的常规文件系统结构。别点格式化,直接忽略就行。

更可靠的验证方式是,用我后面会给出的验证脚本,在Linux环境下检查SD卡是否具备RK3588启动结构。这个方法可以看到关键扇区内容是否写入成功,比Windows下的“能识别”要严谨得多。

4. 附完整脚本:打包固件和验证SD卡的一套自动化操作

标题里说了附完整脚本,这里兑现。整个卡刷包制作流程中,有两类重复且容易出错的步骤最值得自动化:一类是SDK编译产物打包成update.img,另一类是SD卡写完之后的启动结构验证。下面这两个脚本是我实际在用的,按自己的环境改一改路径就能用。

4.1 脚本一:SDK产物一键打包生成update.img

RK3588的SDK编译流程比较长,编译完产物之后,把各个img按分区表打包成update.img是最后一步关键操作。大部分SDK自带mkimage.sh,但这个脚本直接调用更顺手,适合批量处理和多版本固件共存。

#!/bin/bash #==================================================================== # make_rk3588_fw_pkg.sh # 用途:RK3588 SDK编译结束后,自动收集产物并生成update.img # 用法:./make_rk3588_fw_pkg.sh [SDK目录] #==================================================================== set -euo pipefail SDK_ROOT="${1:-$PWD}" OUT_DIR="${SDK_ROOT}/rockdev" IMAGE_DIR="${SDK_ROOT}/rockdev/Image-rk3588" TIMESTAMP=$(date +%Y%m%d_%H%M%S) BACKUP_DIR="${OUT_DIR}/backup_${TIMESTAMP}" if [ ! -f "${SDK_ROOT}/build.sh" ]; then echo "[-] 当前目录不是RK3588 SDK根目录,请检查参数" exit 1 fi cd "${SDK_ROOT}" # 1. 如果有 mkfirmware.sh,先执行它,把产物同步到 rockdev if [ -f "${SDK_ROOT}/mkfirmware.sh" ]; then echo "[*] 执行 mkfirmware.sh,刷新 rockdev 目录产物" ./mkfirmware.sh fi # 2. 确认关键产物存在 REQUIRED_FILES=(parameter.txt MiniLoaderAll.bin uboot.img boot.img rootfs.img) for f in "${REQUIRED_FILES[@]}"; do if [ ! -f "${IMAGE_DIR}/${f}" ] && [ ! -f "${OUT_DIR}/${f}" ]; then echo "[-] 缺少关键文件: ${f},先检查编译或 mkfirmware 是否成功" exit 1 fi done # 3. 打包前备份旧产物 if [ -d "${OUT_DIR}" ] && [ -n "$(ls -A "${OUT_DIR}" 2>/dev/null)" ]; then echo "[*] 备份旧产物到: ${BACKUP_DIR}" mkdir -p "${BACKUP_DIR}" cp -r "${OUT_DIR}"/Image-rk3588 "${BACKUP_DIR}/" 2>/dev/null || true cp -f "${OUT_DIR}"/parameter.txt "${BACKUP_DIR}/" 2>/dev/null || true cp -f "${OUT_DIR}"/update.img "${BACKUP_DIR}/" 2>/dev/null || true fi # 4. 调用 SDK 自带的 mkimage.sh 生成 update.img if [ -f "${SDK_ROOT}/mkimage.sh" ]; then echo "[*] 执行 mkimage.sh 生成 update.img" ./mkimage.sh fi FW="${OUT_DIR}/update.img" if [ ! -f "${FW}" ]; then echo "[-] update.img 生成失败,请查看上方日志" exit 1 fi # 5. 生成校验文件 md5sum "${FW}" > "${FW}.md5" sha256sum "${FW}" > "${FW}.sha256" echo "[*] 固件打包完成:" ls -lh "${FW}" cat "${FW}.md5"

这个脚本的核心逻辑是先确认SDK环境,再执行SDK自带的mkfirmware和mkimage,最后把新生成的update.img做好校验和备份。第3步备份旧产物是我后来加上去的,原因是项目版本迭代频繁,经常需要回退到上一版固件,没有备份就只能重新编译,太浪费时间。

4.2 脚本二:验证一张SD卡是否具备RK3588启动结构

SD卡用SDDiskTool写完之后,如果想验证是否真正具备启动能力,可以把卡插到一台Linux电脑上,跑下面的脚本。它不会直接验证“能不能启动”,但能检查关键结构的完整性——IDB信息是否存在、分区表是否能被识别、各分区文件系统能否挂载。

#!/bin/bash #==================================================================== # verify_rk3588_sdcard.sh # 用途:检查一张SD卡是否为有效的RK3588启动卡 # 用法:sudo ./verify_rk3588_sdcard.sh /dev/sdb # 注意:会尝试挂载SD卡分区,请确保目标设备正确 #==================================================================== set -euo pipefail DEV="${1:-}" if [ -z "${DEV}" ] || [ ! -b "${DEV}" ]; then echo "用法: sudo $0 /dev/sdX" echo "示例: sudo $0 /dev/sdb" exit 1 fi echo "===== 1. 设备基本信息 =====" lsblk -d -o NAME,SIZE,MODEL,TRAN "${DEV}" echo echo "===== 2. 分区表检查 =====" fdisk -l "${DEV}" || true echo echo "===== 3. IDBLoader 关键标记检查 =====" IDB_MARK=$(dd if="${DEV}" bs=512 skip=64 count=32 2>/dev/null | strings | grep -m1 -i "RKNS" || true) if [ -n "${IDB_MARK}" ]; then echo "[OK] 在扇区偏移64处找到IDB标记: ${IDB_MARK}" else echo "[WARN] 扇区偏移64处未找到IDB标记,可能不是有效RK3588启动卡" fi echo echo "===== 4. 分区挂载测试 =====" MOUNT_POINT=$(mktemp -d /tmp/rk_sd_check.XXXXXX) for part in "${DEV}"*; do if [ -b "${part}" ]; then if mount "${part}" "${MOUNT_POINT}" 2>/dev/null; then echo "[OK] 分区 ${part} 挂载成功,内容如下:" ls -lh "${MOUNT_POINT}" | head -20 umount "${MOUNT_POINT}" else echo "[INFO] 分区 ${part} 无法挂载,可能为启动分区或未知文件系统" fi fi done rm -rf "${MOUNT_POINT}" echo echo "===== 验证完成 ====="

关于这个脚本里的检查点,我解释一下为什么是skip=64。RK3588从SD卡启动时,BootROM会在SD卡的特定扇区偏移处寻找IDB信息,扇区64是常见且广泛使用的偏移位置。SDDiskTool写入时,正常情况下会把这个位置的数据写进去。用strings抓一下里面的特征字符串,能确认这一区域确实有引导代码残留。

分区挂载测试的作用是确认系统盘和根文件系统分区是否可被正常识别。如果所有分区都无法挂载,有两种可能:一是这张卡是烧录专用的启动卡,分区结构本就是给BootROM看的,不是常规文件系统;二是写入过程确实出了问题,需要重新制作。

4.3 这两个脚本组合起来怎么用

我的典型工作流是:在Linux编译服务器上跑脚本一,生成update.img和对应的校验文件,然后把update.img拷贝到Windows机器上,用SDDiskTool_v1.78写进SD卡。写完之后,再把SD卡插回Linux机器上跑脚本二做验证。两个脚本一前一后,一个管“前端固件打包”,一个管“后端成品校验”,配合起来非常顺。

如果你是在纯Windows环境工作,脚本一用不到,但脚本二可以放到一台闲置的Linux小主机上跑,或者用Windows Subsystem for Linux也能执行大部分检查逻辑。SD卡验证这件事值得认真做,尤其是帮别人做卡刷包的时候,寄出去的卡不能在对方手上才发现是坏的。

5. 避坑实录:SDDiskTool_v1.78与RK3588卡刷高频故障排查

5.1 “设备忙”和“写扇区失败”,多半是权限或占用问题

SDDiskTool报“设备忙”的案例我见过很多,根因基本都是两个:一是没有以管理员身份运行,二是SD卡被其他进程占用。

被进程占用这个点经常被忽略。Windows资源管理器会自动索引U盘和SD卡,杀毒软件也会实时扫描可移动存储,这两个后台进程都可能导致写卡失败。我处理这类问题的方法是:先把杀毒软件实时防护临时关闭,然后在任务管理器里重启一下资源管理器,再重新试一次。如果依然报错,就把SD卡拔掉重插,让系统重新枚举一次设备。

还有种情况是系统里有多个分区和多个盘符,SD卡被识别成了“本地磁盘”,而SDDiskTool某些版本对这类设备的处理不够完善。遇到这种问题,可以用diskpart把SD卡的只读属性清掉再试。

5.2 写卡过程中断,SD卡好像“废了”,怎么救

写卡过程中拔卡或者断电,SD卡里的分区表可能变成一种半残状态,Windows识别为未初始化磁盘,容量显示为0。这时候不要急着宣布卡报废,先用Windows磁盘管理或者diskpart做一次彻底的清理。

在diskpart里执行clean命令,把整个磁盘置为空,然后初始化成GPT或MBR格式,再放入SDDiskTool重新制作。大多数情况下卡都能恢复正常。

如果你的SD卡之前做过启动卡,写进了一些特殊的引导扇区,换别的工具时会有“无法初始化”的提示。这种情况把卡插到Linux机器上,用fdisk或者parted把整块卡清零,命令逻辑大概是:把SD卡的前几百MB写入零,然后再格式化。清完就恢复普通SD卡身份了。

5.3 板子上电后并没有从SD卡启动,而是进了原系统或者黑屏

SD卡本身做成功了,但板子上电后没动静,这是另一个高频问题。原因大多数不在SD卡,而在启动顺序。

RK3588的启动顺序不是固定的,很多板卡通过拨码开关、跳线帽或者GPIO电平来设置。有些板子默认的是eMMC优先,SD卡排第二,如果eMMC里还有系统,它就直接加载eMMC系统,根本不看SD卡。这种情况需要查阅自己板卡的硬件手册,找到启动模式设置说明,把启动顺序切换为SD卡优先,或者指定强制从SD卡启动。

还有一个记忆点:部分开发板支持按键进入刷机模式,比如按住板上的某个按键再上电,会强制进入SD卡烧录流程。这个按键的作用相当于手动覆盖默认启动顺序,非常实用。具体是哪个按键,不同品牌板卡不一样,建议拿到板卡先翻一下原理图或者用户手册,把启动模式相关的GPIO记录到自己的笔记里。

5.4 update.img的固件版本与板卡硬件不匹配,卡刷包做了也白做

这个问题容易被经验尚浅的朋友忽略:卡刷包做出来了,SD卡验证也通过了,板子也设置了SD启动,但上电后卡在logo或者反复重启。排查到最后,发现是update.img和板卡硬件型号不对版。

RK3588虽然芯片相同,但不同板卡的DDR颗粒、显示接口、以太网芯片、音频Codec都可能不一样,对应的设备树和驱动也必须匹配。你拿A厂商的update.img烧到B厂商的板卡上,绝大多数情况是启动不起来的。做卡刷包之前,一定要先确认板卡厂商提供的固件版本和你的硬件版本一致。这个问题在香橙派、大华的开发板上尤其明显,同一颗芯片,固件兼容性差异很大。

另外提醒一点,自己通过SDK编译的update.img,如果编译时没有选择对应的板卡配置,也会出现类似问题。遇到启动异常,先回头看设备树和板卡配置,这是排查方向的重中之重。

5.5 写卡成功但Windows提示格式化,和上板正常之间不矛盾

SDDiskTool写完的SD卡,插回Windows后系统弹窗提示“需要格式化才能使用”,这其实是个好消息,说明Windows确实识别到了这块卡,而且这个卡上的分区大概率不是Windows能读的常规文件系统。这种卡插到RK3588板子上,反而能正常启动。

但这里有个区别要分清:如果是“SD启动模式”下的启动卡,启动分区里可能是FAT32格式,Windows能读出来,能看到里面的资源文件;如果是烧录eMMC用的升级介质卡,Windows读不出来非常正常。明白这个区别之后,就不会因为Windows弹窗误判SD卡做失败了。

6. 关于SD卡刷机这个方案,最后一点个人建议

做RK3588开发这几年,我越来越体会到,SD卡刷机方法不是USB烧录的替代品,而是必要补充。USB烧录适合开发调试阶段的高频固件迭代,SD卡卡刷适合救砖、量产和一键交付。两种手段搭配起来,工作效率才会真正上去。

我自己有个习惯,每个项目稳定投产之后,都会用SDDiskTool_v1.78制作至少两张启动卡:一张做eMMC烧录用途,一张做SD直接启动用途,然后贴上标签放在防静电袋里,和对应的固件版本号写在同一个位置。这样即使过几个月板子出了问题,或者有同事接手项目,也能从“实体卡”这个角度快速恢复环境,不用从头折腾驱动和工具。

如果你刚开始接触RK3588卡刷,可以先拿一张便宜的SD卡,在闲置板子上把整个流程走一遍。哪怕整个过程顺利,也值得在写卡成功后主动做一次验证脚本跑一遍,看看关键扇区信息是否完整。多试两次,你对SDDiskTool的整个工作逻辑会非常清楚,后面再遇到各种稀奇古怪的报错,基本都能第一时间判断出问题出在卡、固件还是工具环境上。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询