跳转至

SGS TrustZone Debug SOP

Revision History

Revision NO.
Description
 Data
1.0 Initial release 06/25/2025

1. 概述

在使用TrustZone的系统中，针对IP(RIU bank/register)，IMI，以及DRAM会有硬件等级的保护功能。本文提供这些硬件等级保护的调试方式。

一般最常遇到的问题是，在未开启TrustZone的系统中某个功能可以正常运作，而一旦TrustZone开启后功能就会出错，本文提供排查是否为TrustZone所导致的程序。

2. 相关硬件

  • TZSP（TrustZone Security Property）：TZSP实现IP硬件等级的保护机制。本文介绍排查是否为非法访问IP register而造成的问题。

  • TZIMI（TrustZone Internal Memory Interface）：TZIMI实现IMI硬件等级的保护机制。本文介绍排查是否为非法访问IMI而造成的问题。

  • TZEMI（TrustZone External Memory Interface）：TZEMI实现DRAM硬件等级的保护机制。本文介绍排查是否为非法访问DRAM而造成的问题。

3. 问题排查流程

3.1. 排查流程图


流程图

3.2. 步骤说明

流程节点
节点说明
 出口 需提供的分析数据
A 确认TZ开关 B
H		 -
B 检查UART Log是否有OPTEE的TZ IP打印消息 C
E		 TZ access violation
C 在没有OPTEE消息的情况下，可以用T32来查看bank/register D -
D 分析bank/register是否有非法访问 E
H		 TZ access violation
E 分析非法访问的消息并交由IP owner排除问题 F -
F 看是否能定位出非法访问的原因 G
I		 -
G 非法访问的特殊案例 I -
H 非TZ IP的问题 - -
I 修正错误并结案 - -

4. 确认TrustZone是否开启

TrustZone是开启的开关在OTP_TZ是否有烧录。OTP_TZ默认值为0，即关闭。当OTP_TZ烧录为1时，即开启。可以通过OTP_TZ的mirror register bank 0x101F_30[9]来确认。在OTP_TZ=0的系统上，硬件及软件驱动程序都不会开启，则问题与TrustZone无关。

5. TZSP的问题排查

5.1 记录消息的RIU_DBG bank

当RIU host在RIU bank中的register出现非法访问时，TZSP会将相关消息记录在RIU bank所属的在RIU_DBG bank中，如下表：

RIU bridge RIU_DBG bank
DIG bridge 0x1001
CMD bridge 0x1201
ISP0 bridge 0x1678
PM bridge 0x0001

5.2 RIU master的ID

发生非法访问的RIU host, 其在每个RIU bridge中的代码会被记录下来，如下表：

RIU host RIU bridge and corresponding ID
RISV DIG/CMD/ISP0/PM：1
CA7 DIG/CMD/ISP0：2，PM：3
CMDQ0 DIG/CMD/ISP0：3
CMDQ1 DIG/CMD/ISP0：4
VEN1 DIG/CMD：5
DBUS DIG/CMD/ISP0/PM：7

5.3 RIU_DBG bank中的消息

  • 执行非法访问的RIU master
    • RIU_DBG bank 0x41[15:12]
    • 每个RIU master的编号可由4.2的表来查询对应关系
  • 非法访问是read或write
    • read：IU_DBG bank 0x41[9], write：RIU_DBG bank 0x41[8]
  • 非法访问的种类
    • Error type1：RIU_DBG bank 0x41[11], Error type2：RIU_DBG bank 0x41[10]
    • Error type1为NS RIU master存取S RIU bank
    • Error type2为TZ相关的bank被非S-CPU访问
  • 被非法访问的bank
    • RIU_DBG bank 0x41[7:0] | 0x40[15:8]
  • 被非法访问的地址
    • RIU_DBG bank 0x40[7:1]
    • 格式为16-bit RIU addr

5.4 OPTEE收到TZSP非法访问的打印消息

当OPTEE已经初始化完毕，下来发生的TZSP非法访问，会打印消息，如下图：


OPTEE TZSP Message

6. TZIMI的问题排查

6.1 记录消息的bank

当IMI client在IMI中出现非法访问时，TZIMI会将相关消息记录在（TZIMI bank 0x11DE）中

6.2 IMI client的ID

可由下列两个表格来查询代码与IMI client ID的对应关系

  • IMI client table
  • optee_os/core/drivers/sgs/tz/$(CHIP)/hal_tzimi.h中的enum imi_client

6.3 TZIMI bank中的消息

  • 执行非法存取的IMI client

    • bank 0x11DE_0x44，每一个bit代表一个IMI client，例如 bit[0]即代表client 0
    • 每个IMI client的编号表如下, 可查询对应关系
    RIU host RIU bridge and corresponding ID
    RISV DIG/CMD/ISP0/PM：1
    CA7 DIG/CMD/ISP0：2，PM：3
    CMDQ0 DIG/CMD/ISP0：3
    CMDQ1 DIG/CMD/ISP0：4
    VEN1 DIG/CMD：5
    DBUS DIG/CMD/ISP0/PM：7
    - 非法存取是read或write
    - bank 0x11DE_0x47[0]，0为read，1为write
    - 被非法存取的region，0或1
    - bank 0x11DE_0x47[2]，0为region 0，1为region 1
    - 非法存取的 IMI client的security属性，S或NS
    - bank 0x11DE_0x47[1]，0为S，1为NS
    - 被非法存取的地址，此为IMI offset
    - bank 0x11DE_0x45~0x46，只会记录地址的前28 bits，后4 bits必为0
    - 记录的地址 =（fail access addr - IMI base）& 0xFFFFFFF0
    - 当存取超过IMI大小的地址时，TZIMI会拦截（先前没有TZIMI 的情况下，硬件会绕回），而此时记录fail的region为0

6.4 OPTEE收到TZIMI非法访问的打印消息

当OPTEE已经初始化完毕，下来发生的TZIMI非法访问，会打印消息，如下图：


OPTEE TZIMI Message

7. TZEMI的问题排查

7.1 记录消息的bank

当MIU client在DRAM中出现非法访问时，TZEMI会将相关消息记录在（TZEMI bank 0x1618）中

7.2 MIU client的ID

可由下列两个表格来查询代码与MIU client ID的对应关系

  • MIU client table
  • optee_os/core/drivers/sgs/tz/$(CHIP)/hal_tzemi.h中的enum miu_wr_client或enum miu_rd_client

7.3 TZIMI bank中的消息

  • 执行非法存取的MIU client

    • write client：bank 0x1618_0x7A[8:0]，read client：bank 0x1618_0x7B[8:0]，bit[8:4]为group，bit[3:0]为group中的client

  • 非法存取是 read或write

    • write flag：bank 0x1618_0x7A[10]，read flag：bank 0x1618_0x7B[10]
  • 被非法存取的 region，0 ~ 16
    • write region：bank 0x1618_0x7A[15:11]，read region：bank 0x1618_7B[15:11]
  • 非法存取的MIU client的security属性，S或NS
    • write security：bank 0x1618_0x7A[9]，read security：bank 0x1618_0x7B[9]
  • 被非法存取的地址，此为 MIU offset
    • write address：bank 0x1618_0x7C~0x7D，read address：bank 0x1618_0x7E~0x7F
    • 此处记录的地址以32 bytes为单位
    • 记录的地址 = (((fail access addr - MIU base) & 0xFFFFFFE0) >> 4)
  • 当存取超过region 0大小的地址时，TZEMI 会拦截（先前没有TZEMI的情况下，硬件会绕回），而此时记录fail的region为0

7.4 OPTEE收到TZEMI非法访问的打印消息

当OPTEE已经初始化完毕，下来发生的TZEMI非法访问，会打印消息，如下图：


OPTEE TZEMI Message

8. 非法访问的特殊案例

8.1 Case 1：U-Boot cache line prefetch issue

TZEMI 拦截到非法的存取，存取失败的消息为，Client 0x72为CPU，Region 0x1为TF-A，由NS-CPU进行非法读取，Address为0xFC47E/0xFC3FE/0xFC0D2/0xFC0D4/0xFC390/0xFC0D0...


DRAM CPU Prefetch
  • 原因
    • 经debug后发现，一旦打开d-cache enable，就会立刻发生此消息，因此与cache有关系
    • 这是因为d-cache enable后，CPU H/W就会自动进行cache line prefetch
    • 而先前在执行TF-A时，CPU中已经有了TF-A的page table entry
  • 解法
    • 在U-Boot将TF-A的region设为non-cacheable，如此CPU H/W就不会自动进行cache line prefetch

8.2 Case 2：IMI access out-of-bound address issue

TZIMI拦截到非法的存取，存取失败消息为Read fail，Client 0x0为CPU，NS=0x1由NS-CPU进行非法读取，Region 0x0，Addr=0x0a3340由于此chip的IMI size为128KB，若addr大于128KB且region为0，此类型为越界存取


IMI CPU Prefetch
  • 原因
    • 关掉Linux VM后，仍会发生此状况，因此可知此问题发生在RTOS中
    • MI及image pipeline都不会让CPU去存取IMI
    • RTOS中的IMI的MMU属性为MEM_TYPE_MEMORY | MEM_TYPE_RW | MEM_TYPE_SECURE | MEM_TYPE_INIT_NORMAL，此为cacheable memory area
    • 目前MMU page table设定单位为1MB，因此会超出IMI真实的大小
    • 由于CPU在cache enable的情况下，H/W就会自动行进cache line prefetch，一旦对超出IMI 大小的地址prefetch，TZIMI就会发出错误消息
  • 解法
    • 修改RTOS中的IMI MMU属性，由MEM_TYPE_MEMORY改为MEM_TYPE_NON_CACHEABLE，如此CPU H/W就不会对IMI自动进行cache line prefetch