企业官网建设流程全解析

1. 为什么“check chip失败”不是报错，而是固件打包流程的生死线

瑞芯微RK系列芯片——从早年的RK3288、RK3399，到如今主力的RK3568、RK3588，再到边缘端新秀RV1106——其固件打包机制从来就不是简单的文件压缩合并。它是一套融合了硬件信任链起点、BootROM校验逻辑、烧录协议约束与芯片物理ID绑定的强耦合系统。很多人第一次遇到check chip failed时，下意识以为是工具版本不对、USB线接触不良，或者干脆重装一遍RKDevTool了事。我试过三次：第一次重装工具，第二次换线，第三次重刷驱动——结果全在同一个地方卡住，直到我把RK3568的SDK包解压到D盘根目录，用管理员权限运行mkimage.exe，才看到控制台里一行被滚动刷掉的提示：[ERROR] chip id mismatch: expected 0x3568, got 0x0000。

这行日志才是真相。所谓“check chip失败”，本质是打包工具在生成固件镜像（.img）前，必须完成一次芯片身份预检：它会读取你指定的chip.ini或rk3568.ini中声明的芯片型号，再比对当前工程所用的MiniLoaderAll.bin（即一级引导程序）头部嵌入的芯片ID字段。如果二者不一致，工具直接终止打包，连临时文件都不生成。这不是软件bug，而是瑞芯微BootROM硬编码的防护策略——防止你把为RK3399编译的Loader误烧进RK3568芯片，导致整机变砖。

这个机制带来的连锁反应远超想象。比如你在RK3568项目里混用了RV1106的trust.img模板，打包工具不会报“文件格式错误”，而是静默跳过该段校验，最终生成一个Loader能启动、但ATF（ARM Trusted Firmware）无法加载的固件——设备上电后卡在U-Boot logo界面，串口只输出Starting kernel ...就再无下文。这种“半成功”状态比直接报错更难排查，因为日志里没有任何异常提示。

再比如最近社区高频出现的RK3568设备树适配问题。很多人把rk3568-evb.dts直接复制进自己的板子工程，修改compatible = "rockchip,rk3568"后就执行打包。但没注意到rk3568-evb.dtsi里有一行关键定义：/include/ "rk3568-opp.dtsi"。而rk3568-opp.dtsi中CPU频率表依赖于rockchip,rk3568a这个特定revision ID。如果你的芯片是早期流片的RK3568（revision B），而固件里强制加载A版OPP表，Loader在解析设备树阶段就会因校验失败丢弃整个DTB，最终U-Boot fallback到默认配置，导致PCIe、GPU等模块不可用——此时你看到的现象是“系统能起来，但网卡识别不了”，根本不会联想到固件打包环节出了问题。

所以，“check chip失败”从来就不是打包流程的终点，而是整个RK固件可信链的起点警报。它提醒你：从芯片ID声明、Loader匹配、TrustZone镜像签名，到设备树revision兼容性，所有环节必须形成闭环。漏掉任意一环，后续的烧录、启动、功能验证都会变成一场耗时数天的盲人摸象。

提示：瑞芯微官方文档《RK3568_Firmware_User_Guide》第4.2节明确指出：“check chipis not a validation of physical chip, but a consistency check between declared chip type and loader binary header.” 这句话翻译过来就是：它校验的不是你手里那颗真实芯片，而是你告诉工具“我要打什么芯片的包”和你实际提供的Loader二进制头信息是否一致。

2. 固件打包四大核心文件的物理结构与校验逻辑拆解

RK固件打包不是把一堆文件zip压缩，而是按严格字节偏移拼接成一个符合BootROM解析规范的二进制镜像。这个镜像（通常为update.img或loader.img）内部有清晰的分区布局，每个分区都承担特定职责，且彼此间存在强校验依赖。理解这些分区的物理结构，是绕过“打包错误”的唯一路径。

2.1 MiniLoaderAll.bin：芯片启动的第一道门禁

这是整个固件链的基石，由瑞芯微提供，不可修改。它的作用是在芯片上电后，由BootROM直接加载并执行，完成DDR初始化、时钟配置、基本外设使能，并为后续加载U-Boot或ATF做准备。其文件头包含关键字段：

当你执行rkdeveloptool ld命令烧录Loader时，工具首先读取此文件头的chip_id，并与你配置的chip.ini中CHIP_ID=0x3568进行比对。若不一致，立即报check chip failed。注意：这个比对发生在打包前，而非烧录时。很多开发者误以为只要Loader能烧进去就万事大吉，殊不知打包阶段的校验失败，意味着你生成的固件根本不会包含这个Loader——后续所有步骤都是空中楼阁。

实操中一个高频坑是：从不同SDK版本中混用MiniLoader。比如你用RK3568 Android 11 SDK里的MiniLoaderAll.bin，却搭配RK3568 Linux SDK里的parameter.txt。由于Android SDK Loader头中version字段为0x02，而Linux SDK期望0x01，打包工具在解析parameter时会因版本不匹配拒绝加载，最终报错parse parameter failed。这个错误看似是parameter问题，根源却是Loader版本不匹配。

2.2 parameter.txt：固件的“宪法性文件”

这个纯文本文件定义了整个固件镜像的逻辑分区布局，是mkimage工具生成update.img的蓝图。它的格式极其严格，任何空格、换行、注释符号位置错误都会导致打包失败。典型内容如下：

FIRMWARE_VER: 8.1 MACHINE_MODEL: RK3568 MACHINE_ID: 007 MANUFACTURER: RK TRUST_ZONE: 0 MAGIC: 0x5041524B ATAG: 0x00200800 MACHINE: 3568 CHECK_MASK: 0x80 # name addr size flag bootloader 0x00000000 0x00040000 0x00000001 parameter 0x00040000 0x00004000 0x00000001 trust 0x00044000 0x00008000 0x00000001 misc 0x0004c000 0x00004000 0x00000001 resource 0x00050000 0x00010000 0x00000001 kernel 0x00060000 0x00400000 0x00000001 boot 0x00460000 0x00100000 0x00000001 recovery 0x00560000 0x00100000 0x00000001 backup 0x00660000 0x00100000 0x00000001 cache 0x00760000 0x00200000 0x00000001 system 0x00960000 0x01000000 0x00000001 metadata 0x01960000 0x00010000 0x00000001

关键点在于：

• MACHINE: 3568必须与MiniLoaderAll.bin头中的chip_id低16位完全一致（即0x3568→3568），否则打包工具在解析parameter时直接退出；
• 分区addr必须严格递增，且不能重叠。例如bootloader结束于0x00040000，则parameter起始地址必须≥0x00040000。我曾见过有人把parameter写成0x0003ffff，工具报错partition overlap，但错误信息极不友好，只显示error code -1；
• flag字段决定该分区是否参与CRC32校验。0x00000001表示校验，0x00000000表示不校验。若你把trust分区flag设为0，而实际trust.img又未签名，Loader在启动时会因校验失败跳过该分区，导致Secure Boot失效。

2.3 trust.img：安全世界的“宪法解释者”

这是ARM TrustZone实现的核心，包含BL31（ATF）、OP-TEE OS等。其生成过程最易出错。标准流程是：

1. 编译ATF源码，生成bl31.elf；
2. 用arm-trusted-firmware/tools/fiptool/fiptool将bl31.elf打包为trust.img；
3. trust.img头部需嵌入芯片ID和签名证书。

常见错误：

• 证书不匹配：使用RK3399的rk3399.pem私钥去签名RK3568的bl31.elf，fiptool会静默生成文件，但Loader在启动时校验签名失败，直接跳过trust分区；
• ELF段地址错误：ATF编译时PLAT_ROCKCHIP_BASE=0x00044000必须与parameter.txt中trust分区addr完全一致。若parameter写0x00044000而ATF配置为0x00045000，Loader加载后跳转到错误地址，设备黑屏；
• 未启用Secure Boot：trust.img必须用--soc-fw-config参数指定soc_fw_config.dtb，否则ATF无法获取芯片安全配置，启动后dmesg | grep -i secure无输出。

2.4 resource.img与boot.img：用户空间的“双生子”

resource.img包含设备树（DTB）、logo、splash等资源；boot.img包含内核镜像（zImage/Image）和initramfs。二者必须严格对应：

• resource.img中的rk3568-evb-linux.dtb必须与boot.img中内核编译时指定的CONFIG_DEFAULT_DEVICE_TREE="rk3568-evb-linux"完全一致；
• 若你修改了设备树文件名（如改为myboard.dtb），必须同步修改resource.img打包脚本中的dtb_name变量，否则Loader加载resource.img后找不到对应DTB，U-Boot fallback到rockchip/rk3568.dtb，导致GPIO、I2C等外设驱动无法匹配。

我踩过最深的坑是：在resource.img中同时打包了rk3568-evb.dtb和rk3568-evb-linux.dtb两个文件，parameter.txt里resource分区size只写了0x00010000（64KB），但实际两个DTB加起来超过70KB。打包工具没有报错，而是静默截断了resource.img后半部分。结果设备启动后，U-Boot能加载DTB，但解析时发现文件损坏，最终/proc/device-tree为空——所有外设驱动都加载失败，ls /sys/class/gpio返回空。查了两天串口日志，才发现dmesg里有一行被忽略的OF: fdt: Invalid dtb header。

注意：mkimage工具对resource.img大小不做校验，只检查parameter.txt中声明的size字段。因此务必用du -h resource.img确认文件大小小于等于parameter.txt中对应size值。

3. 从零构建可复现的RK3568固件打包环境：避坑清单与实操验证

搭建一个稳定、可复现的RK固件打包环境，远比编译一个Linux内核更考验细节把控能力。我经历过三轮环境重建：第一轮用Windows 10 + Cygwin，第二轮用Ubuntu 20.04虚拟机，第三轮用WSL2 + Docker。最终确定的黄金组合是：Windows 10 专业版 + WSL2 Ubuntu 22.04 + 独立SDK目录 + 全路径硬编码脚本。下面是我整理的逐项避坑清单，每一条都来自血泪教训。

3.1 操作系统与工具链：为什么必须用WSL2而不是纯Windows

瑞芯微官方打包工具mkimage、rkdeveloptool、rkcrc等，其Linux版本比Windows版本更新更及时，错误提示更详细。例如mkimage在Windows下报error -5，在Linux下会明确提示[ERR] invalid parameter file line 12: addr overflow。更重要的是，parameter.txt中的路径分隔符在Windows下是\，在Linux下是/，而mkimage工具在解析resource.img打包指令时，会将parameter.txt中resource分区的addr值与resource.img的实际文件路径拼接。若你在Windows下用反斜杠，工具会尝试访问C:\path\to\resource.img，而实际文件在/mnt/c/path/to/resource.img，导致file not found错误。

WSL2完美解决了这个问题：它让Linux工具直接访问Windows文件系统，路径映射透明。实测对比：

• 纯Windows环境：mkimage执行成功率约65%，主要失败在resource.img路径解析和trust.img签名验证；
• WSL2 Ubuntu 22.04：成功率98%，剩余2%是人为配置错误。

安装步骤（必须严格按顺序）：

1. 在Windows功能中启用“适用于Linux的Windows子系统”和“虚拟机平台”；
2. 重启后，Microsoft Store安装“Ubuntu 22.04 LTS”；
3. 启动Ubuntu，创建用户（不要用root）；
4. 执行sudo apt update && sudo apt install -y build-essential git python3-pip device-tree-compiler；
5. 将RK3568 SDK解压到/home/username/rk3568_sdk（绝对路径，不能有空格或中文）；
6. 将Windows下的D:\rk3568\映射为/mnt/d，确保SDK路径可访问。

关键经验：所有打包脚本中的路径必须使用/mnt/d/rk3568/这样的WSL格式，而非D:/rk3568/。我曾因在脚本中写错一个斜杠，导致连续3次打包生成的update.img都无法启动，最后用hexdump -C update.img | head -20发现parameter分区数据全是0x00——根源是mkimage根本没读取到parameter.txt文件。

3.2 SDK目录结构净化：删除所有“看起来有用”的冗余文件

官方SDK包里充斥着大量历史遗留文件，它们不会报错，但会悄悄污染打包流程。必须手动清理以下目录：

• /tools/linux/Linux_Pack_Firmware/rockdev/：删除除package-file外所有.sh脚本。mkimage.sh会自动调用mkimage，但若存在旧版mkimage.sh，它可能覆盖环境变量RKTOOLS_PATH，导致调用错误版本的rkcrc；
• /tools/linux/Linux_Driver/：彻底删除。这个目录里的rkflashkit是图形化烧录工具，与打包无关，且其依赖的python-gi库会与pyserial冲突，导致rkdeveloptool串口通信失败；
• /kernel/：只保留arch/arm64/configs/rk3568_linux_defconfig和drivers/子目录，删除所有samples/、tools/等无关目录。mkimage在扫描kernel/目录时，若发现tools/build等子目录，会尝试递归解析，消耗大量内存并可能超时。

清理后，你的SDK目录应只包含：

rk3568_sdk/ ├── bootloader/ # MiniLoaderAll.bin在此 ├── device/ # 设备树、configs等 ├── kernel/ # 内核源码（精简后） ├── tools/ # rkdeveloptool, mkimage等 ├── rockdev/ # parameter.txt, package-file等 └── build.sh # 自定义打包脚本

3.3 构建可验证的打包脚本：从build.sh到verify.sh

一个合格的打包流程，必须包含自验证环节。我编写的build.sh核心逻辑如下（已脱敏）：

#!/bin/bash # build.sh - RK3568固件打包主脚本 set -e # 任何命令失败立即退出 SDK_ROOT="/home/user/rk3568_sdk" TOOLS="$SDK_ROOT/tools/linux/Linux_Pack_Firmware" ROCKDEV="$SDK_ROOT/rockdev" echo "[INFO] 正在清理旧固件..." rm -f "$ROCKDEV"/update.img "$ROCKDEV"/loader.img echo "[INFO] 校验MiniLoaderAll.bin芯片ID..." CHIP_ID_HEX=$(xxd -p -l2 "$SDK_ROOT/bootloader/MiniLoaderAll.bin" | tr -d '\n' | sed 's/../& /g' | awk '{print $2$1}') echo "检测到芯片ID: 0x$CHIP_ID_HEX" if [ "$CHIP_ID_HEX" != "3568" ]; then echo "[ERROR] MiniLoader芯片ID不匹配！期望0x3568，得到0x$CHIP_ID_HEX" exit 1 fi echo "[INFO] 生成resource.img..." cd "$SDK_ROOT/device/rockchip/rk3568/" && \ ./mk-resource.sh -d rk3568-evb-linux.dtb -l logo.bmp -s splash.bmp echo "[INFO] 打包update.img..." cd "$TOOLS" && \ ./mkimage -d "$ROCKDEV/package-file" "$ROCKDEV/update.img" echo "[INFO] 打包loader.img..." cd "$TOOLS" && \ ./mkimage -d "$ROCKDEV/package-file-loader" "$ROCKDEV/loader.img" echo "[SUCCESS] 固件打包完成！"

这个脚本的关键在于set -e和芯片ID校验。set -e确保任何一步失败，脚本立即终止，避免生成半成品固件。而芯片ID校验用xxd直接读取二进制头，比依赖rkdeveloptool更底层、更可靠。

打包完成后，必须运行verify.sh进行四重验证：

#!/bin/bash # verify.sh - 固件验证脚本 UPDATE_IMG="/home/user/rk3568_sdk/rockdev/update.img" echo "[VERIFY 1] 检查update.img文件大小..." SIZE=$(stat -c "%s" "$UPDATE_IMG") if [ "$SIZE" -lt 10000000 ]; then # 小于10MB视为异常 echo "[FAIL] update.img过小，可能打包不完整" exit 1 fi echo "[VERIFY 2] 解析parameter分区..." dd if="$UPDATE_IMG" of=/tmp/param.bin bs=1 skip=262144 count=16384 2>/dev/null if ! strings /tmp/param.bin | grep -q "RK3568"; then echo "[FAIL] parameter分区未包含RK3568标识" exit 1 fi echo "[VERIFY 3] 检查trust分区CRC..." TRUST_OFFSET=$(strings /tmp/param.bin | grep "trust" | awk '{print "0x"$2}') TRUST_SIZE=$(strings /tmp/param.bin | grep "trust" | awk '{print "0x"$3}') dd if="$UPDATE_IMG" of=/tmp/trust.bin bs=1 skip=$TRUST_OFFSET count=$TRUST_SIZE 2>/dev/null if ! rkcrc -v /tmp/trust.bin; then echo "[FAIL] trust.img CRC校验失败" exit 1 fi echo "[VERIFY 4] 检查resource分区DTB完整性..." RESOURCE_OFFSET=$(strings /tmp/param.bin | grep "resource" | awk '{print "0x"$2}') dd if="$UPDATE_IMG" of=/tmp/resource.bin bs=1 skip=$RESOURCE_OFFSET count=65536 2>/dev/null if ! fdtdump -s /tmp/resource.bin 2>/dev/null | grep -q "rockchip,rk3568"; then echo "[FAIL] resource.img中DTB不包含RK3568兼容性字符串" exit 1 fi echo "[PASS] 所有验证通过！"

这个验证脚本模拟了Loader启动时的真实校验逻辑：读取parameter分区、定位trust和resource分区、执行CRC和DTB解析。只有全部通过，才代表固件可烧录。我坚持每次打包后必跑verify.sh，三年来从未出现过烧录后无法启动的情况。

4. 真实排错案例：RK3568设备树修改后“check chip失败”的根因定位全过程

去年为某工业客户定制RK3568主板，需求是增加一路PCIe x1接口并启用NVMe SSD。我按常规流程修改设备树：在rk3568-evb.dts中添加&pcie0节点，配置num-lanes = <1>，编译生成rk3568-custom.dtb，替换resource.img中的原DTB，然后执行打包。结果mkimage报错：

[ERROR] check chip failed: chip id mismatch

这很奇怪——我用的MiniLoaderAll.bin是官方RK3568 SDK提供的，parameter.txt里MACHINE: 3568也正确。按理说不应该报这个错。我开始了一套标准化的根因排查流程，全程记录，现在复盘给你看。

4.1 第一层排查：确认基础环境一致性

首先排除环境干扰：

• 检查MiniLoaderAll.bin：xxd -p -l2 bootloader/MiniLoaderAll.bin | cut -c3-6→ 输出3568，正确；
• 检查parameter.txt：grep "MACHINE:" rockdev/parameter.txt→ 输出MACHINE: 3568，正确；
• 检查mkimage版本：./tools/linux/Linux_Pack_Firmware/mkimage --version→v2.51，与SDK文档要求一致。

基础环境无问题，错误必然出在“非显性”环节。

4.2 第二层排查：追踪mkimage的内部调用链

mkimage是shell脚本封装，其核心是调用rkcrc和rkpack。我修改mkimage脚本，在关键位置添加echo调试：

# 在mkimage脚本中找到调用rkpack的行，前面加上： echo "[DEBUG] Calling rkpack with: $RKTOOLS_PATH/rkpack $PARAM_FILE $OUTPUT_FILE" $RKTOOLS_PATH/rkpack $PARAM_FILE $OUTPUT_FILE

重新打包，控制台输出：

[DEBUG] Calling rkpack with: /home/user/rk3568_sdk/tools/linux/Linux_Pack_Firmware/rkpack /home/user/rk3568_sdk/rockdev/package-file /home/user/rk3568_sdk/rockdev/update.img

进入tools/linux/Linux_Pack_Firmware/目录，手动执行该命令：

./rkpack /home/user/rk3568_sdk/rockdev/package-file /tmp/test.img

报错依旧。此时我意识到问题在rkpack二进制本身。查阅rkpack的man页（./rkpack --help），发现它有一个-v参数用于详细日志：

./rkpack -v /home/user/rk3568_sdk/rockdev/package-file /tmp/test.img

输出关键行：

[INFO] Loading parameter file: /home/user/rk3568_sdk/rockdev/package-file [INFO] Parsing parameter file... [ERROR] Failed to parse parameter file: invalid chip id in loader

注意：这里说的是invalid chip id in loader，而非in parameter。问题指向MiniLoaderAll.bin，但之前已确认其ID正确。

4.3 第三层排查：深入package-file的隐式依赖

package-file是mkimage的输入蓝图，其格式为：

loader MiniLoaderAll.bin parameter parameter.txt trust trust.img resource resource.img ...

我检查package-file，一切正常。但突然想到：rkpack在解析loader行时，是否会读取MiniLoaderAll.bin的完整文件？于是用hexdump查看该文件末尾：

hexdump -C bootloader/MiniLoaderAll.bin | tail -5

输出：

0003ff0 0000 0000 0000 0000 0000 0000 0000 0000 * 0004000 3568 0000 0000 0000 0000 0000 0000 0000 0004010 0000 0000 0000 0000 0000 0000 0000 0000 *

0004000地址处赫然出现3568！这说明MiniLoaderAll.bin文件被追加了额外数据。我回忆起来：为了调试PCIe，我曾用rkdeveloptool的db命令（download binary）向Loader内存中写入过一段调试代码，并保存为debug_loader.bin。后来误将debug_loader.bin重命名为MiniLoaderAll.bin覆盖了原文件！

这才是真正的根因。rkpack在读取MiniLoaderAll.bin时，不仅检查文件头，还会扫描整个文件寻找芯片ID签名。当它在文件末尾发现3568时，误判为这是一个“双芯片ID”Loader，从而触发校验失败。

4.4 最终修复与预防措施

修复步骤：

1. 从原始SDK包中恢复正确的MiniLoaderAll.bin；
2. 用sha256sum校验其哈希值，与SDK文档提供的值比对；
3. 重新打包，check chip通过。

预防措施（已写入团队规范）：

• Loader文件加只读锁：chmod 444 bootloader/MiniLoaderAll.bin，禁止任何写操作；
• 所有调试二进制单独存放：建立/debug/目录，绝不与/bootloader/混用；
• 每次打包前强制校验：在build.sh中加入sha256sum -c bootloader/MiniLoader.sha256 2>/dev/null || { echo "Loader校验失败！"; exit 1; }。

这个案例揭示了一个残酷事实：RK固件打包的脆弱性，往往不在宏大的架构设计，而在一个被覆盖的二进制文件、一个被忽略的chmod命令、一行被遗忘的调试日志。所谓“避坑”，本质是把所有可能出错的环节，都变成可验证、可锁定、可审计的确定性动作。

经验总结：当check chip failed发生时，90%的情况根源在MiniLoaderAll.bin文件本身。不要急于修改parameter.txt或重装工具，先用xxd和sha256sum给Loader做一次“DNA鉴定”。

5. 从单板到量产：固件打包流程的工业化改造实践

当项目从实验室原型走向百台小批量，再到千台量产，固件打包不能再依赖手工执行build.sh。我主导过三个量产项目（RK3399工控机、RK3568边缘网关、RV1106 IPC摄像头），将打包流程改造成一套可审计、可回滚、可自动化的工业化系统。这套方案的核心不是引入多么高大上的CI/CD，而是用最朴素的Linux哲学：一切皆文件，一切可脚本，一切有日志。

5.1 版本化固件元数据：用firmware.json替代parameter.txt的人工维护

parameter.txt最大的问题是：它是纯文本，无法表达复杂依赖。比如trust.img的生成依赖于ATF版本、resource.img依赖于设备树commit hash、kernel.img依赖于内核config。人工维护极易出错。

我们创建firmware.json作为唯一真相源：

{ "project": "rk3568-gateway", "chip": "rk3568", "version": "2.3.1", "build_date": "2024-06-15T08:23:45Z", "components": { "loader": { "file": "bootloader/MiniLoaderAll.bin", "sha256": "a1b2c3...z9", "chip_id": "0x3568" }, "parameter": { "file": "rockdev/parameter.txt", "sha256": "d4e5f6...y8" }, "trust": { "file": "rockdev/trust.img", "sha256": "g7h8i9...x7", "atf_commit": "abc1234567890def", "cert": "certs/rk3568.pem" }, "resource": { "file": "rockdev/resource.img", "sha256": "j0k1l2...w6", "dtb_commit": "fedcba9876543210", "logo": "device/logo.bmp" } } }

build.sh不再硬编码路径，而是解析此JSON：

# 读取loader路径 LOADER_PATH=$(jq -r '.components.loader.file' firmware.json) # 校验sha256 if ! sha256sum -c <(jq -r '.components.loader.sha256 + " " + .components.loader.file' firmware.json); then echo "Loader校验失败！" exit 1 fi

这样，每次固件升级，只需更新firmware.json中的sha256和commit字段，打包脚本自动拉取对应版本的组件，杜绝“版本错配”。

5.2 自动化签名与证书管理：告别手动生成trust.img

trust.img签名是量产最大瓶颈。人工用openssl命令签名，容易输错密码、选错证书、漏掉--soc-fw-config参数。我们开发了sign-trust.sh：

#!/bin/bash # sign-trust.sh - 自动化trust.img签名 CERT_DIR="certs" ATF_BUILD_DIR="build/rk3568/release" # 1. 从firmware.json读取证书名 CERT_NAME=$(jq -r '.components.trust.cert' firmware.json | sed 's/certs\///') CERT_PATH="$CERT_DIR/$CERT_NAME" # 2. 生成soc_fw_config.dtb（自动注入芯片ID） dtc -I dts -O dtb -o "$ATF_BUILD_DIR/soc_fw_config.dtb" \ -b 0 -p 1024 device/soc_fw_config.dts # 3. 调用fiptool签名 fiptool create \ --soc-fw "$ATF_BUILD_DIR/bl31.bin" \ --soc-fw-config "$ATF_BUILD_DIR/soc_fw_config.dtb" \ --nt-fw "$ATF_BUILD_DIR/bl33.bin" \ --trusted-key-certificate "$CERT_PATH" \ --output "$ROCKDEV/trust.img" echo "trust.img已签名，证书：$CERT_NAME"

关键创新点：

• 证书路径从firmware.json动态读取，支持多项目共用同一套证书体系；
• soc_fw_config.dtb自动生成，确保芯片ID与parameter.txt严格一致；
• 所有命令带-v参数