1. 项目概述
在嵌入式系统开发领域,调试环境的搭建是验证硬件与软件协同工作的关键环节。Arm Total Compute(TC)平台作为面向移动计算和AI应用的先进解决方案,其调试环境的配置具有典型的多核异构系统特征。本文将基于TC2参考平台,深入讲解如何搭建完整的调试环境,并重点分析Runtime Security Subsystem(RSS)作为硬件信任根(Root of Trust)的启动流程和安全机制。
TC平台的核心价值在于提供了一套完整的参考软件栈,包含从底层固件到上层操作系统的全栈组件。其中RSS子系统采用Cortex-M55核心设计,通过物理隔离的执行环境提供硬件级安全保护,承担着安全启动、加密服务、固件更新等关键功能。理解其启动流程对于开发安全关键型应用(如支付系统、身份认证等)具有重要参考意义。
2. 调试环境搭建全流程
2.1 硬件与工具准备
搭建调试环境前需要准备以下基础组件:
- 宿主机器:推荐Ubuntu 20.04 LTS系统,确保具备足够的计算资源(建议16GB以上内存)
- 仿真平台:TC2 Fixed Virtual Platform(FVP)版本11.23.17,这是Arm提供的功能完备的虚拟化参考模型
- 开发工具:Arm Development Studio最新版,这是支持多核调试的专业IDE环境
- 软件栈:完整的TC2软件构建产物,包括:
- RSS固件(BL1_1/BL1_2/BL2)
- SCP系统控制固件
- AP应用处理器固件(TF-A)
- Hafnium安全分区管理器
- Linux内核与根文件系统
关键提示:所有工具链建议通过Arm官方渠道获取,确保版本兼容性。特别是FVP模型与Arm DS的版本需要严格匹配,否则可能出现无法识别的CPU类型错误。
2.2 FVP模型导入Arm DS
由于TC2 FVP不属于Arm DS内置模型,需要手动导入配置:
- 通过
File > New > Other > Configuration Database > Model Configuration打开向导 - 创建新的配置数据库存放TC2模型定义
- 选择Iris作为模型接口协议(这是Arm调试架构的标准通信协议)
- 在模型选择界面定位到FVP二进制文件(通常位于
/opt/arm/models/...) - 完成导入后,在Project Explorer中验证模型是否正常显示
典型问题排查:
- 若出现CPU类型识别错误,需升级Arm DS到最新版本
- 导入失败时可检查文件权限,确保对FVP二进制有可执行权限
2.3 启动FVP与调试服务器
标准启动命令需要添加调试服务器参数:
bash复制./run-scripts/tc2/run_model.sh -m <model_path> -d <distro> -- -I -p
其中-I启用Iris调试服务器,-p打印服务器端口号(默认为7100)。
为改善终端体验,可替换默认xterm为GNOME终端:
bash复制-C css.terminal_uart1_ap.terminal_command="gnome-terminal -t %title -- telnet localhost %port" \
-C css.terminal_uart_ap.terminal_command="gnome-terminal -t %title -- telnet localhost %port" \
-C soc.terminal_s0.terminal_command="gnome-terminal -t %title -- telnet localhost %port" \
-C soc.terminal_s1.terminal_command="gnome-terminal -t %title -- telnet localhost %port"
成功启动后会显示关键端口信息:
code复制Iris server started listening to port 7100
terminal_uart_ap: Listening on port 5006 # AP主串口
terminal_s0: Listening on port 5008 # 安全域串口
2.4 多核调试配置
TC平台包含三类可调试核心:
- 应用处理器(AP):Cortex-A520集群,运行Linux/Android
- 系统控制处理器(SCP):Cortex-M3,负责电源管理
- 安全子系统(RSS):Cortex-M55,实现硬件信任根
配置步骤:
- 在Arm DS中创建
Generic Arm C/C++ Application调试配置 - 选择对应核心类型:
- AP选择
Cortex-A520X4 SMP Cluster 0 - SCP选择
Cortex-M3 - RSS选择
Cortex-M55
- AP选择
- 连接方式选择
Connect to running model,地址127.0.0.1,端口7100
调试技巧:
- 为每个核心创建独立的调试配置,便于单独控制
- 使用
Debug Control视图管理多个调试会话 - 优先启动RSS调试会话,因为其引导早于其他子系统
3. RSS固件启动深度解析
3.1 固件架构与安全设计
RSS采用分层安全启动架构,每层都有明确的信任边界:
| 固件层级 | 存储位置 | 功能描述 | 安全特性 |
|---|---|---|---|
| BL1_1 (ROM) | 掩膜ROM | 生命周期检测、BL1_2加载 | 物理不可修改 |
| BL1_2 (CM) | OTP存储器 | BL2验证与加载 | 硬件加密存储 |
| BL2 (MCUboot) | Flash | 固件验证与更新 | RSA-3072签名 |
| SPE Runtime | Flash | 安全服务提供 | 隔离执行环境 |
关键安全机制:
- 防回滚:使用OTP中的计数器验证固件版本
- 密钥分级:
- HUK(硬件唯一密钥)用于派生设备专属密钥
- GUK(全局唯一密钥)用于跨设备通信
- 双阶段验证:BL1验证BL2,BL2验证运行时固件
3.2 调试符号加载策略
不同启动阶段需要加载对应的符号文件:
bash复制# BL1阶段
add-symbol-file /path/to/bl1_1.axf
add-symbol-file /path/to/bl1_2.axf
# BL2阶段
add-symbol-file /path/to/bl2.axf
# 运行时
add-symbol-file /path/to/tfm_s.axf # SPE安全环境
add-symbol-file /path/to/tfm_ns.axf # NSPE非安全环境
DWARF调试信息处理:
当遇到DWARF version 5 is not supported错误时,需启用LLVM解析器:
- 进入
Window > Preferences > Arm DS > Debugger > Dwarf Parser - 勾选
Use LLVM DWARF parser - 重新加载符号文件
3.3 启动流程关键节点
3.3.1 BL1_1 ROM执行阶段
- 硬件复位后从ROM起始地址0x00000000执行
- 读取OTP中的生命周期状态:
CM_PROV:等待芯片制造商配置DM_PROV:等待设备制造商配置SECURED:正常启动流程
- 根据状态跳转到对应处理流程
调试技巧:
- 在
rss_rom_init()函数设断点 - 监控
RSS_OTP_LCS寄存器值(地址0x5003_0000)
3.3.2 BL1_2加载阶段
- 从OTP中读取加密的BL1_2映像
- 使用CM密钥解密(AES-256-CTR模式)
- 验证签名(ECDSA-P256)
- 跳转到SRAM中解压后的BL1_2
典型问题:
- 签名失败会导致系统进入Trap状态
- 可通过
rss_provisioning_metadata_t结构体检查密钥信息
3.3.3 BL2验证流程
基于MCUboot的安全启动实现:
c复制int boot_verify_image(uint8_t *img_data, size_t img_size) {
// 1. 验证镜像头格式
if (hdr->ih_magic != IMAGE_MAGIC) return -1;
// 2. 计算SHA-256哈希
crypto_hash_update(&ctx, img_data + hdr_data_size, img_size);
// 3. RSA-PSS签名验证
rc = crypto_sig_verify(pk, sig, hash);
// 4. 版本检查
if (img_ver < sec_counter) return -1;
}
安全增强建议:
- 在
bootutil_verify_sig()函数设断点监控验证过程 - 检查
MCUBOOT_IMAGE_NUMBER配置确保双镜像备份生效
4. 多子系统协同调试
4.1 RSS与SCP的交互
通过MHUv2(Message Handling Unit)通信:
- RSS完成自检后发送
SCP_BOOT_REQ消息 - SCP回复
SCP_BOOT_ACK确认 - RSS通过MHU传输SCP固件到共享内存
- 触发SCP的CPU复位向量
调试方法:
- 在
mhu_v2_send_data()函数设断点 - 监控MHU寄存器组(基地址0x45400000)
4.2 RSS与AP的启动协调
- RSS验证AP的BL1镜像(TF-A)
- 通过AP MHU通道发送启动命令
- 等待AP返回状态报告
- 记录启动度量值到安全存储
性能优化点:
- 调整
rss_ap_boot.c中的超时参数 - 优化镜像传输的DMA配置(使用TrustZone地址空间)
5. 生产环境考量
5.1 安全配置清单
- [ ] 确保OTP中的HUK已正确编程
- [ ] 验证所有调试接口在量产固件中已禁用
- [ ] 检查反回滚计数器的初始值设置
- [ ] 确认供应链各阶段的密钥交接流程
5.2 调试与量产差异
| 特性 | 调试版本 | 量产版本 |
|---|---|---|
| 调试接口 | JTAG/SWD全开放 | 仅保留授权访问 |
| 固件签名 | 使用测试密钥 | 正式签发密钥 |
| 错误报告 | 详细日志输出 | 最小化信息泄露 |
| 启动时间 | 允许较长的超时 | 严格时间限制 |
6. 进阶调试技巧
6.1 安全异常处理
当触发安全异常时,可通过以下方式定位问题:
- 检查
RSS_FAULT_STATUS寄存器组(0x5002_0000) - 分析
tf-M的崩溃日志(通过安全UART输出) - 使用Arm DS的异常追踪功能
6.2 功耗管理调试
RSS在低功耗模式下的行为调试:
- 在
psa_irq_handler()中监控电源状态转换 - 测量VDD_RSS电源域的电压曲线
- 检查唤醒源配置寄存器(0x5002_0A00)
6.3 实时性能分析
使用Arm DS的Streamline功能:
- 配置ETM跟踪单元捕获执行流
- 分析函数调用热点
- 优化关键路径(如加密算法加速)
通过上述完整的调试环境搭建和RSS启动流程分析,开发者可以深入理解Arm Total Compute平台的安全架构设计,为构建高安全等级的嵌入式系统奠定基础。实际开发中建议结合具体应用场景,重点验证硬件信任链的完整性和抗攻击能力。
