Zynq-7000自定义板核0切换至非安全域异常求助

针对Zynq-7000双核心安全域配置问题的排查方向 #

从你的描述来看，你在尝试给Zynq-7000的双核心分配不同安全域时遇到了FSBL挂起和数据中止错误，下面是几个具体的排查方向，结合Zynq的安全架构特性来分析：

• 检查FSBL中安全状态切换的时机与内存访问权限
  Zynq-7000的Cortex-A9核心修改安全配置寄存器（SCR，也就是你代码中操作的c1,c1,0寄存器）后，CPU0会进入非安全域，但此时FSBL本身的代码或数据如果位于安全专属的内存区域（比如未开放非安全访问的OCM、DDR区域），就会触发DATA_ABORT错误（0xA304）。

  • 首先确认FSBL的链接脚本：查看FSBL的代码段、数据段是否被链接到了安全内存区域。如果是，切换到非安全域后CPU0无法访问这些区域，必然会挂起。你需要调整链接脚本，将FSBL的关键代码/数据放到已经通过TZ寄存器开放非安全访问的区域，或者在切换安全状态前先配置好TZ寄存器。
  • 注意切换操作的执行阶段：FSBL在启动过程中会初始化很多硬件组件，建议在完成所有必要的硬件初始化（尤其是内存控制器、TZ寄存器配置）之后，再执行CPU0的安全状态切换，避免因硬件未就绪导致的访问错误。

• 验证TZ寄存器配置的顺序与正确性
  你配置的TZ寄存器用于划分安全/非安全内存区域，但这里有两个关键点需要确认：

  • 配置顺序：必须先完成所有TZ寄存器的配置，再修改CPU0的SCR寄存器。因为一旦CPU0进入非安全域，就无权修改安全相关的TZ寄存器了，后续的配置操作会直接触发权限错误。
  • 寄存器位定义：核对Xilinx官方手册中TZ寄存器的位映射，比如TZ_DDR_RAM的0x0000ffff是否对应你预期的非安全DDR区域范围。如果FSBL或后续U-Boot/Linux的镜像加载地址落在未开放的安全DDR区域，切换非安全域后必然会访问失败。另外，TZ_OCM_RAM0/1设置为0xffffffff意味着开放整个OCM的非安全访问，这部分是合理的，但要确保FSBL确实运行在OCM中。

• 确认CPU1的安全状态不受CPU0操作的影响
  Zynq-7000的两个A9核心拥有独立的CP15寄存器，CPU0的SCR修改不会直接影响CPU1，但需要确保FSBL在启动CPU1时的逻辑正确：

  • 检查FSBL中启动CPU1的代码，确保没有误修改CPU1的SCR寄存器，保持其安全域状态。通常FSBL会通过CPU1_RST_CTRL等寄存器启动CPU1，要确认启动时CPU1的初始状态是安全特权模式。
  • 如果双核心有共享内存区域，需要配置对应的TZ寄存器，确保安全域的CPU1和非安全域的CPU0都能正常访问各自权限内的共享区域，避免跨域访问错误。

• 调试DATA_ABORT错误的具体触发点
  0xA304错误码指向数据中止，你可以通过以下方式定位具体原因：

  • 使用JTAG调试工具连接开发板，在FSBL中执行切换汇编代码的位置设置断点，切换后查看CPU0的DFSR（数据故障状态寄存器）和DFAR（数据故障地址寄存器），明确是访问哪个地址时触发的中止，判断是权限问题还是地址无效。
  • 尝试简化FSBL代码：先注释掉其他初始化逻辑，只保留TZ寄存器配置和CPU0安全状态切换，看是否还会触发错误，逐步排查是哪部分逻辑导致的冲突。

• 参考Xilinx官方安全配置示例
  Xilinx在Zynq-7000的官方文档（比如《UG826 Zynq-7000 SoC Software Developer's Guide》）和SDK示例中提供了安全域配置的参考代码，你可以对比官方示例的操作流程，检查自己的代码是否遗漏了关键步骤（比如某些安全寄存器的解锁、内存区域的正确映射）。

内容的提问来源于stack exchange，提问作者Khurram