大家好这里是触觉智能一家专注于瑞芯微RK平台的嵌入式方案商。本系列文章将分享开发五个环节(编译、烧录、升级、分区、启动)常见报错信息、根因分析和排査命令。上文分享编译和烧录相关内容即使是刚接触RK平台的新手这份手册都能帮你快速定位问题少走弯路。建议收藏备用。编译环境都装好了为什么一编译就报错别急着怀疑代码——这套SDK在动手编译前会先给环境做一次体检绝大多数报错信息里其实就写着答案。拿到RK3576 Linux6.1 SDK 后第一件事不是改代码而是先把编译环境对齐。这套 SDKK1 新一代布局内置了一套自动环境检查每次 ./build.sh 或 make 启动时都会先跑 check_sdk再按你选择的组件内核 / Debian / Buildroot / Yocto…分别跑对应的 check-*.sh。报错不是玄学而是这套检查脚本吐出来的结构化信息。报错信息里一般就带着解法装哪个包、换哪个版本、改哪个目录权限。这套 SDK 的先体检后编译机制入口在 device/rockchip/common/scripts/build.sh 的 main()1setup_environments导出全套 RK_* 环境变量SDK 目录、output 目录、芯片目录等2check_sdk先校验脚本路径没被搬错位置然后执行 check-sdk.sh并检测是否用 root 在编译3各组件脚本mk-kernel.sh / mk-rootfs.sh 等内部再调 check-kernel.sh / check-debian.sh / check-buildroot.sh / check-yocto.sh 等。这些 check-*.sh 全部位于 device/rockchip/common/scripts/ 下。所以排查编译报错的第一步是先读懂报错是哪个检查脚本吐出来的而不是直接去翻 Makefile。官方依据SDK 编译流程见 docs/cn/Rockchip_Developer_Guide_Linux_Software_CN.pdf 与根目录 README.mdQuick Start 五步make help → make rockchip_defconfig → make menuconfig → make → 烧 output/firmware/update.img环境检查机制以 device/rockchip/common/scripts/check-*.sh 源码为准。一张表看懂环境报错错误信息 → 原因 → 解法下表所有报错关键字 / 解法均直接摘自 SDK 源码check-sdk.sh、check-kernel.sh、check-debian.sh、check-package.sh、build.sh不是网上总结的通用经验。报错关键字含义解法摘自脚本给出的提示Current user is not the owner of SDK source!当前用户不是 SDK 源码属主常见于 sudo 或换用户后sudo chown -h -R $(id -un):$(id -un) $RK_SDK_DIR/或 su - $RK_OWNER 切回属主Please move SDK source code into an ext4 partition.源码所在分区不是 ext4/f2fs/btrfs如 NTFS、FAT、挂载盘把 SDK 移到 ext4 分区SDK 只认 ext*|f2fs|btrfsYour rsync/gcc/g is missing缺基础包check-package.sh 统一输出sudo apt-get install rsync gcc gYour python3 is too old for kernel: …python3 版本太旧内核 mkbootimg 跑不动升级 python3脚本会提示跑 install-python3.shYour lz4 is too old for kernel: …lz4 不带 favor-decSpeed内核压缩 Image 需要安装 lz4 v1.9.4源码 git clone …/lz4 -b v1.9.4sudo make install缺 openssl/ssl.h、gmp.h、mpc.h、ncurses.h 等头文件编译内核缺少 dev 开发包check-header.sh 检查sudo apt-get install libssl-dev libgmp-dev libmpc-dev libncurses-dev flexPlease remount to allow creating devices…分区以 nodev 挂载编 Debian 需要 mknodsudo mount -o remount,dev 挂载点Your mke2fs is too old: …e2fsprogs 太旧没有 -d 选项打 ext4 根文件系统用运行 install-e2fsprogs.sh 升级Your live-build doesnt support bookworm / Your debootstrap doesnt support bookwormlive-build / debootstrap 太旧不支持 Debian 12bookworm按脚本提示用 salsa 源码分支重装 live-build / debootstrapYour qemu-aarch64-static(qemu-user-static) is brokenchroot 模拟 arm64 环境的 qemu 坏了sudo apt-get install binfmt-support qemu-user-static --reinstallYour qemu-aarch64 doesnt work with Debian(bookworm)!qemu 版本与 bookworm 不兼容需 qemu-8.0用 SDK 自带 tools/x86_64/qemu-aarch64-static 替换后 rebootNo prebuilt GCC toolchain for …!SDK 预编译交叉工具链缺失get_toolchain() 在 prebuilts/gcc/linux-x86/arch 找不到 gcc检查 prebuilts/gcc/linux-x86/aarch64 目录是否完整必要时重新 repo syncDebian 源检查报错编译 Debian 时check-network.sh 验证镜像源 RK_DEBIAN_MIRROR 不可达本 SDK 默认 USTC 源确保能访问镜像源或改 RK_DEBIAN_MIRROR最容易踩的三个坑第一坑权限 / 目录不对脚本直接拒跑最典型的是用 sudo 或换用户编译。SDK 在 check-sdk.sh 里用 stat --format %U 取 SDK 属主再和当前用户对比不一致就报 Current user is not the owner of SDK source!。另外源码分区必须是 ext4/f2fs/btrfs——如果 SDK 解压在移动硬盘NTFS上会直接报请移到 ext4 分区。第二坑版本装了但太老这类报错最容易让人困惑包明明装了啊。SDK 的检查不是装了没而是验证关键能力例如lz4跑 lz4 -h | grep favor-decSpeed旧版没有这个特性就报错并建议装 v1.9.4python3直接拿 kernel/scripts/mkbootimg 试跑跑不动就报too oldmke2fs必须支持 -d 选项qemu-user-static要能配合 bookworm 的 ldconfig 跑起来否则提示换 qemu-8.0。第三坑只编译内核 vs 全量编译需要的包不一样只编内核检查的是 check-kernel.shflex、libssl-dev、libgmp-dev、libmpc-dev、libncurses-dev 等一旦加编 Debian 根文件系统就触发 check-debian.shdebootstrap、qemu-user-static、binfmt-support、live-build。很多人在内核编过后以为环境没问题结果 buildroot/debian 阶段又报新错——因为那是另一组检查脚本。Buildroot 还要 expectunbufferYocto 要 zstd。别等报错先主动自查# 1. 编译前先看帮助确认选择路径 make help make rockchip_defconfig # 或 ./build.sh rk3576:defconfig # 2. 关键包快速自查 which python3 rsync gcc g flex debootstrap fakeroot zstd unbuffer lz4 -h | grep favor-decSpeed # 看 lz4 能力 dpkg -l | grep -E libssl-dev|libgmp-dev|libmpc-dev|libncurses-dev|qemu-user-static|live-build # 3. 确认 SDK 属主与分区 stat -c %U . 2/dev/null # 应与当前用户一致 findmnt -fnu -o FSTYPE -T . # 应是 ext4/f2fs/btrfs如果环境检查和命令都对编译仍报错那才进入看构建日志阶段——日志统一在 output/log/ 与 output/sessions/ 下逐行看最终失败的命令。避坑提醒官方推荐 Ubuntu 22.04在 Ubuntu 24.04 上编译官方 SDK Note 特别说明 v1.1.0 增强了 Debian 编译环境的检查与提示、v1.0.1 修复了 24.04 的编译异常——升级 SDK 或用 LTS 系统能少踩很多坑依据docs/cn/RK3576/RK3576_Linux6.1_SDK_Note.md。本 SDK 默认 Debian 12bookwormarm64源码 debian/ubuntu-build-service/bookworm-xfce-arm64/换其它版本/架构前先看 check-debian.sh 是否支持。编译并行度由环境变量控制本机示例 NINJAJOBS48 / MAKEFLAGS-j48内存不够时先降并行度再谈其他。一编译就报错在RK3576 Linux6.1 SDK 里几乎都是环境检查拦截的结果不是代码问题。处理顺序① 看报错来自哪个 check-*.sh② 按脚本提示装包/换版本/改权限③ 用上文自查命令提前验证④ 全量编译前把 kernel rootfs 需要的包一次装齐。二、烧录一直失败是板子坏了还是工具不对绝大多数烧录失败不是板子坏了而是设备没进对模式或工具没找到设备。本文给你一张决策流程图。烧录的本质板子在Loader模式或MaskRom模式下通过USB的Rockusb协议与PC端工具通信。工具下载镜像到对应分区。所以判断烧录失败先回答三个问题① 工具找到设备了吗② 设备在哪个模式③ 烧的是不是和分区匹配的镜像工具位置Linux 用 tools/linux/Linux_Upgrade_Tool/Linux_Upgrade_Tool/upgrade_tool本 SDK 为 v2.44Windows 用图形工具 RKDevToolSDK Notev3.36或命令行 tools/windows/upgrade_tool_v2.44.zip。官方文档docs/cn/Linux/Recovery/Rockchip_Developer_Guide_Linux_Upgrade_CN.pdf。烧录失败决策流程图下面这张图是本文的核心按顺序走就能定位绝大多数问题工具的命令集实测输出直接在 SDK 里跑 upgrade_tool -h 就能看到完整命令。常用这几个命令用途LDListDevice 列设备——烧录前第一件事CD / SDChooseDevice / SwitchDevice——多设备时选择UL LoaderUpgradeLoader——烧 LoaderMaskRom 恢复的第一步UF FirmwareUpgradeFirmware——一键烧 update.img推荐免管分区DI -p|-uboot|-trust|-b|-r|-m|-oem|-userdata|-rootfs imgDownloadImage 按分区烧单镜像EF LoaderEraseFlash 擦除 Flash换分区/换存储前先擦RDResetDevice 重启设备PL / RCI / SFI分区表 / 芯片信息 / 固件信息——确认板型与固件匹配常见失败现象对照表现象 / 报错原因处理执行 DI/UF/UL 时报 No found any rockusb device,please plug device in!或 LD 显示 List of rockusb connected(0)工具没找到任何 Rockusb 设备先确认板子是否已进入 Loader/MaskRom 模式不是普通开机状态换线换口Type-C 必须用数据线上电后是正常开机画面不是下载模式板子没进 Loader 模式按住 RECOVERY下载键 RESET 再松开或用系统内 reboot loader 进下载模式Linux 下 LD 没权限 / 看不到设备USB 设备权限udev 规则或驱动问题确认用户有 USB 访问权限Windows 下安装/重装 Rockchip 驱动MaskRom 模式需专用驱动loader 被刷坏/清空后识别成MaskRom设备Loader 丢失芯片回落到 MaskRomMaskRom 模式先 UL MiniLoaderAll.bin 恢复 Loader再走正常流程烧 di -pparameter失败parameter 与设备存储/既有分区不匹配先 EF 擦除再烧确认烧的是同一板型的 parameter见 01.04烧到一半卡住 / 报错退出镜像与设备不符、USB 不稳定、存储异常换稳定 USB 口用 UF 烧整包 update.img必要时重进 Loader 再试注MaskRom与Loader 模式的进入方式、Windows 驱动安装细节以官方 Upgrade_CN.pdf 与 RKDevTool 文档为准模式机制属 RK 平台通用行为。SDK 自带的烧录脚本rkflash.shSDK已经把整包烧录流程写成了脚本 device/rockchip/common/scripts/rkflash.sh它直接调用上面的 upgrade_tool。全量烧录rkflash.sh 不带参数 all的执行顺序是upgrade_tool ul -noreset $LOADER # MiniLoaderAll.bin upgrade_tool di -p $PARAMETER # parameter.txt分区表 upgrade_tool di -uboot $UBOOT # uboot.img upgrade_tool di -trust $TRUST # trust.img upgrade_tool di -b $BOOT # boot.img upgrade_tool di -r $RECOVERY # recovery.img upgrade_tool di -m $MISC # misc.img upgrade_tool di -oem $OEM # oem.img upgrade_tool di -userdata $USERDATA # userdata.img upgrade_tool di -rootfs $ROOTFS # rootfs.img upgrade_tool rd # 重启支持只烧某一个./rkflash.sh boot、./rkflash.sh rootfs、./rkflash.sh loader、./rkflash.sh update一键烧 update.img、./rkflash.sh erase擦除。镜像在哪固件输出目录 output/firmware/即 rockdev。本 SDK 的 Loader是rk3576_spl_loader_v1.09.107.bin软链到 u-boot/boot.img 来自内核构建。实操排查步骤# 0. 工具与设备 cd tools/linux/Linux_Upgrade_Tool/Linux_Upgrade_Tool ./upgrade_tool LD # 看到 Rockusb 设备 连接成功 # 1. 看不到设备 → 强制进 Loader # 按住 RECOVERY 键 复位/上电然后再次 LD # 2. 进 MaskRom 后先恢复 Loader ./upgrade_tool UL SDK/rockdev/MiniLoaderAll.bin # 3. 正常烧录二选一 ./upgrade_tool UF SDK/rockdev/update.img # 整包最省事 # 或单分区 ./upgrade_tool DI -p SDK/rockdev/parameter.txt ./upgrade_tool DI -b SDK/rockdev/boot.img # 4. 烧完重启 ./upgrade_tool RD烧录失败先别怀疑板子先走完以下4个流程①用 upgrade_tool LD 看工具是否找到设备②找不到就强制进 LoaderRECOVERY 键再不行考虑进入MaskRomUL 恢复Loader③走rkflash.sh all 或 UF update.img 整包烧录最稳④仍未解决才考虑硬件换线/换口/换板。