[参考译文] TDA4VP-Q1：R5F.CPU5：通过配置 R5F 控制寄存器 (SCTRL) 来配置 R5F CPU 以陷阱非法指令

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1554921/tda4vp-q1-r5f-cpu5-configuring-the-r5f-cpu-to-trap-illegal-instructions-by-configuring-the-r5f-control-register-sctrl

工具/软件：

我正在使用以下代码片段启用零分频异常：

静态空 CSL_armR5EnableDZ_SCTLR (void)
｛
_ASM__ volatile (
“MRC P15、0、r0、C1、c0、 0\n“//读取 SCTLR
“Orr r0、r0、#(1 << 19)\n“//设置 DZ 位
“MCR P15、0、r0、C1、c0、 0\n“//写回 SCTLR
“BX LR\n“//返回
)；

静态空 CSL_armR5EnableExceptions_FPSCR (void)
｛
_ASM__ volatile (
“VMRS r0、FPSCR\n“//读取 FPSCR
“BIC r0、r0、#(0x1F << 8)\n“//将位 8 清零至 12
“VMSR FPSCR, r0\n“//写回 FPSCR
“BX LR\n“//返回
)；

我们有两个观察结果

案例 1： 这部分代码是 最初添加了 r5_startup.asm 和调用的函数。 不幸的是,在启动过程中,我们观察到异常并中止启动文件的闪烁,尤其是当刷新 tispl 文件时。  下面添加了异常的 PFA

注意： BL31：v2.11.0（发行版）：v2.11.0-906-g58b25570c
通知： BL31：建造时间：2025 年 2 月 18 日 16:22:30
错误：  等待线程 SP_RESPONSE 填充时超时
错误：  线程 SP_RESPONSE 验证失败（–60)
错误：  消息接收失败（–60)
错误：  获取响应失败（–60)
错误：  传输发送失败（–60)
错误：  无法查询固件功能（–60)
I/O TC：
I/GNU：OP-TEE 版本：4.4.0 (gcc 版本 11.3.1 20220712 (TC Toolchain 11..Rel1))#1 星期二 2 月 18 日 15:21：35 UTC 2025 Aarch64
I/OP-TEE：警告：此 TC 配置可能不安全！
TC：警告：请访问 https://optee.readthedocs.io/en/latest/architectureporting_guidelines.html
I/O：主 TC 初始化
I/GIC：未提供 TC 转销商基地址
I/GIC：假定默认的 TC 组状态和修饰符
E/队 列：0 k3_sec_proxy_verify_thread：108 TC 正忙
e / TC：0 k3_sec_proxy_recv：196 线程 SEC_proxy_response_thread 验证失败。 RET =–65523
E/ESP TC：0 ti_sci_get_response：101 消息接收失败（–65523)
E/sci_do_xfer TC：150 获取响应失败（–65523)
e/ti_sci_init TC：486 无法与控制固件通信（–65523)
E/0x00070038：0 do_init_calls：22 eary_initcall __text_start + TC 失败
I/UL：已激活 TC 设备
E/队 列：0 k3_sec_proxy_verify_thread：108 TC 正忙
e / TC：0 k3_sec_proxy_recv：196 线程 SEC_proxy_response_thread 验证失败。 RET =–65523
E/ESP TC：0 ti_sci_get_response：101 消息接收失败（–65523)
E/sci_do_xfer TC：150 获取响应失败（–65523)
E/队 列：0 k3_sec_proxy_verify_thread：108 TC 正忙
e / TC：0 k3_sec_proxy_recv：196 线程 SEC_proxy_response_thread 验证失败。 RET =–65523
E/ESP TC：0 ti_sci_get_response：101 消息接收失败（–65523)
E/sci_do_xfer TC：150 获取响应失败（–65523)
E/TRNG：0 sa2ul_init：106 无法更改 TC 防火墙所有者
e/0x0000 do_init_calls：22 service_initcall __text_start + TC 0x000703a0 失败
E/队 列：0 k3_sec_proxy_verify_thread：108 TC 正忙
e / TC：0 k3_sec_proxy_recv：196 线程 SEC_proxy_response_thread 验证失败。 RET =–65523
E/ESP TC：0 ti_sci_get_response：101 消息接收失败（–65523)
E/sci_do_xfer TC：150 获取响应失败（–65523)
E/队 列：0 k3_sec_proxy_verify_thread：108 TC 正忙
e / TC：0 k3_sec_proxy_recv：196 线程 SEC_proxy_response_thread 验证失败。 RET =–65523
E/ESP TC：0 ti_sci_get_response：101 消息接收失败（–65523)
E/sci_do_xfer TC：150 获取响应失败（–65523)
E/队 列：0 k3_sec_proxy_verify_thread：108 TC 正忙
e / TC：0 k3_sec_proxy_recv：196 线程 SEC_proxy_response_thread 验证失败。 RET =–65523
E/ESP TC：0 ti_sci_get_response：101 消息接收失败（–65523)
E/sci_do_xfer TC：150 获取响应失败（–65523)
E/HUK：0 TEE_OTP_GET_HW_UNIQUE_KEY：103 无法获取 TC
E/0x000703c8：0 do_init_calls：22 service_initcall __text_start + TC failed
E/SupportAssist TC：0 0
E/0x14 TC：0 地址处的内核数据中止（转换故障）
E/ESR：0 0 TC 0x96000005 tbr0 0x9e8a5000  tbr1 0x00000000  CIDR 0x0
E/CPUR：0 0 TC #0         CPSR 0x600003c4
E/x0 TC：0 x0 000000009e874000 x1 000000000000
E/00000000 TC：0 x2 0000000000000000 x3 0000000000000000  
e / TC：0 x4 0000000000000030 x5 000000009e873da8  
e/x6 TC：0 0 x6 000000009e85bb58 x7 00000000ffffffff  
E/x8 TC：0 x8 0000000000000008 x9 000000009e8af140  
E/00000008 TC：0 x 10 00000000000004ac x 11 0000000000000008
E/X12：0 0 x12 0000000000000020 TC 13 000000009e8af0d0
E/00000000：0 x 14 TC 000000000000 x 15 0000000000000000
E/X17 0000000000000000：0 x16 000000009e81be9c TC
E/00000000 TC：0 x 18 000000000000 x 19 000000009e8af420
e / TC：0 x 20 000000009e8af428 x 21 000000009e874000
E/000000 TC：0 x 22 000000009e874000 x 23 000000009e874ed8
E/00000000 TC：0 x 24 000000009e873de0 x 25 000000000000
E/00000000：0 x 26 0000000000000000 TC 27 0000000000000000
E/00000000 TC：0 x 28 0000000000000000 x 29 000000009e8af390
E/ELR：0 TC：0 X30 000000009e81667b0 ELR 00009e8166c0
e/0 TC sp_el0 00009e8af390
E/TEE：0 TC 加载地址@ 0x9e800000
E/Call Stack：0 0 TC：
E/0x9e8166c0：0 TC  
E/0x9e807c90：0 0 TC  
E/8219a4 TC：0 0x9e8219a4
E/ARK/ARM/kernel/abort.c TC：582 处出现紧急“未处理的可分页中止“
E/TEE：0 TC 加载地址@ 0x9e800000
E/Call Stack：0 0 TC：
E/0x9e8080 TC：0 0 0x9e80ac
E/0x9e81e414 TC：0 0 0x9e81e414
E/0x9e807858：0 TC：0 0x9e807858
E/0x9e804a6c TC：0 0 0x9e804a6c

案例 2： 当代码被移动时  从 asm 到 c 文件  、它在 AppInit 之后和 appRun 之前调用。 我看到 tiboot3、tispl 文件已刷写、但会阻止我们刷写 uboot。  

问题：

我们的关注：

1. 是否应在启动代码期间通过 asm 文件或 c 文件（当前实现）启用它？
2. 为什么在任何一种情况下引导文件中止刷新的原因可能是什么？

如果需要考虑任何执行问题、请向我们提出建议。