[参考译文] J784S4XEVM：J784S4 上的 Lauterbach 脚本

我想我使用的安全字用于 TI J784S4 EVM 板、HS：FS 可能会使用不同的模式来写入？

DATA.SET EAXI:0x44135120 %LE %LONG 0x4658FC21；在 HS 上、如果验证失败、此操作将中止
Data.Set EAXI：0x44135124 %LE %LONG 0x3AC4F102

如果 HS：FS 器件没有通用公共模式、您是否有可由 Lauterbach 脚本加载以解锁和停止 HS：FS 器件上的安全看门狗的小映像？

您好、Jim、

有 GP 和 HS 型器件。 另一个线程中提到的脚本适用于一些不同的使用场景。  使用 WIR 模式的裸机测试可与关注的硬件检查结合使用、可以使用 x_GEL_to_Cmm 下的脚本（如_J784S4_DDR_TEST.cmm）对 GP 或 HS 完成。   pdk_rtos_test 中找到类似 FreeRTOS 测试、要求固件仅适用于 NOBOOT + GP 器件。  HS 器件没有可用作安全服务的纯 JTAG 负载兼容方法（不提供用于 fs-enc.bin 解密等操作）。   在 HS-R5 FS（或 HS-SE）器件上进行调试时需要在 Cortex-R5 上延迟连接~μ s。  调试此问题的常用方法是在引导加载程序中提前一段时间 (1)（通常在 DDR 初始化之前）、然后连接 PC 并设置 PC、以便调试早期代码。  对于该 场景、您可以直接使用 _J784S4_r5.cmm 来连接 R5。  然后您将加载符号。  这本质上是执行 pdk_launch_saferrtos_r5.cmm 中的操作 、减去 pdk_launch_js_common.cmm 标注中的 JTAG 固件加载。

没有用于 R5 的引导加载程序。 我只在主器件侧设置 u-boot。 在这种情况下、我是否可以直接使用 _J784S4_r5.cmm 来连接到 R5 内核并加载符号？

我没有完全关注... 但是、是的、您可以直接热连接和加载符号。  通常、这意味着使用“system.attach"而“而不是“system.up"（“（具有（具有复位功能）、并确保仅加载符号（不是符号和代码）“ data.load.elf myappelf.out /nocode“。

我正在开发“NOBOOT + HS：FS “电路板。  我在 没有 pdk_launch.js_common.cmm 的情况下使用了 pdk_launch_freertos_r5.cmm。  看起来存储器 0x41C40000 未正确初始化、存储器中的初始化变量为随机数据。 我附上了我使用的脚本。 似乎仍然需要脚本来设置时钟和 RAM

e2e.ti.com/.../4201.support.zip

HS 器件不支持 NOBOOT、这仅适用于 GP 器件。  从 JTAG 初始化的角度来看、HS 器件的主要问题是安全服务不会被固件导出、因此无法进行解密等操作。  有一个可~的 DEVBOOT 模式、但这需要一个 μ A 混合流程、即部分引导、然后连接。  脚本没有这样做的结构。  最好以后期连接和调试为目标、因为这很简单。

我按照您的建议、使用 u-boot 启动电路板、并运行 _J784S4_r5.cmm 以执行后期连接。 但我需要连接到 MCU R5F0_1。 我按如下所示更改了脚本：

&parameter=“r5_mcu AMP1“-->&parameter=“r5_mcu AMP2“

一切都很好、但执行 system.Mode attach 命令时出现总线错误

有什么想法为什么它失败?   

感谢您发送编修。

可能有几个原因：

-如果 MCU 在锁步模式下运行、则只能访问 AMP1。  AMP2 将中止。

-->尝试 AMP1 并查看它是否有效。

-如果 MCU 已关闭（派单后关闭）、则连接可能会如您所见失败。

-->如果在 AMP2 上运行代码、请提前放置一个 while 循环。  这将是一个干净的连接点。  如果它中止、则可能不会执行每个操作。  这种 while 循环可以执行一些操作、例如写入数据模式一些共享地址、让您知道它甚至正在运行。

如果添加了一些表明没有调试权限的证书、也可能会发生这种情况。  

我昨天试过 AMP1、结果正常。 但我的应用与系统固件存在资源冲突、因此我必须使用 AMP2 切换到 R5F0_1

我对  _J784S4_r5.cmm 中的以下代码有疑问：

如果&param_smp
SYSTEM.CONFIG 核心&corenum 1。
暴露
SYSTEM.CONFIG CORE (&corenum+&subnum-1) 1。

如果&param_smp
CORE.ASSIGN 1 2.
暴露
core.assign (&subnum)

subnum 是“AMP"后面“后面的数字

在  脚本 _J784S4_r5.cmm 中：

AMP1、代码为  

对于 R5 对、有效的“core.assign"值“值为“1"，“，"2"、"2"或“或"1“"1 2"“ 2"。“。   0 不是有效选项。   “ core.assign (&subnum)“行应仅为 1 或 2。  您可以在宏调试器中调试脚本的步骤、因此您可以查看这些值是否符合预期。  除非在调试实验过程中发生了更改、否则它们应该是空的。   “system.config core“需要唯一、用于通过该工具对跟踪进行排序。  对于单核调试、甚至不需要对其进行设置。  

使用 _J784S4_r5.cmm、我能够连接到 R5F0_0、但不能连接到 R5F0_1。 这可能不是安全原因。 u-boot 一直循环到那里。  是否错过了 R5F0_1 的任何步骤？

我切换回了 TI EVM 板、并尝试将代码加载到 R5F0_1。 我将 AMP1 更改为 AMP2

在使用 EVM 板进行测试时、我遇到以下问题：

MCU1_0 不执行、我需要将 Sciserver 加载到 MUC1_0 并在那里执行。

R5F0_1 上的 TCMA (0~0x8000) 在执行过程中发生了更改。

您是否有脚本可以在 MCU1_0 上成功执行系统固件和 SciServer、并且应用可以在 EVM 板上的 MCU1_1 上运行？

谢谢、

Jim

如果是 GP、固件和裸机将运行。  在仅 HS 运行 WIR + Baremetal 时、HS 固件会在加载 JTAG 时自行停止运行。   需要将“NULL SBL“映像（具有 while 1 循环的固件）放置在 SD 卡或闪存中、以运行需要固件服务的测试 引导程序、它包含固件。

我正在使用带有 GP 芯片的 TI EVM 电路板上工作、并使用与您提供的相同脚本。

未为 R5F0_2 启用 TCM (MCU R5F 代码 2)。 您能给我展示如何启用 TCM 存储器、MCU_TIMER 调试冻结模式和 GTC 寄存器访问吗？

对于 R5F0_1、我们有以下代码可启用这些功能：

Data.Set EAPB：0x9D3001A8 %LE %LONG (0x10000|17)
data.set EAPB：0x9D3001ac %LE %long (0x10000|17)
DATA.SET EAPB：0x9D300004 %LE %LONG (0x10000|17)
DATA.SET EZAXI：0x00A90000 %LE %LONG 0x3
data.set 0x61000000++0x7fff %LE %LONG 0x0；将 MCU-R5F0 ATCM 归零以初始化 ECC
Data.Assembly SR:0x61000000 b 0x61000038；跳转到循环点
Data.Assembly SR:0x61000038 b 0x61000038；循环

如果 R5F0_2 需要相同的设置代码、相似的设置代码是什么？

我们需要更新 pdk_launch.js_common.cmm 以重新配置 MCU 防火墙 、允许 R5F0_2 配置 MCU_CTRL_MMR_CFG0、MCU 计时器、RTI 计时器、GTC。 您是否有脚本来进行此更改？

谢谢、

 理查德·伍德拉夫 新年快乐！  关于上述问题的任何更新？

或者以另一种方式： 您是否有经测试可在 R5F0_2（内核 2）上工作、且应用程序有权从 R5F0_2 或内核 2 访问外设寄存器？

我没有你测试的精灵。 我使用您的脚本尝试使用我的 elf 文件、加载 elf 时出现错误：

地址 SR：0x40F92000-–0x40F920FF 处总线错误

我的 elf 文件不使用此内存范围、更像是系统固件问题：

CPUn RAT 基地址： 0x40F9_0000

有什么想法为什么我不能加载程序?

Richard：

感谢您的快速答复。 添加  per.set.Simple C15：0x30F %long 0x4000003D 后、我正在取得进展

我遇到了另一个问题:第二个核心的 VIM 基地址是什么?

来自 TRM： MCU_R5FSS0 内每个 CPU 视图的基地址相同。 这意味着两个内核具有相同的 vim 基地址 0x40F80000H。

但 0x40F80000H 是物理存储器地址。 内核 0 和内核 1 的 VIM 寄存器是否具有相同的物理内存地址？  内核 0 和内核 1 是否共享相同的 vim 寄存器？  当然、它不应该是相同的。 如果它们不相同、那么核心 2 的正确 vim 基地址是什么？

谢谢、

Jim

e2e.ti.com/.../4578.support.zip

我下载了新脚本、将中断表加载到 VIM 时遇到问题。 0x40F82000~无法从 core2 访问存储器

我上载了 lds 文件和 elf 文件、如果您可以将此 elf 加载到内核 2、请帮助检查您一侧。

感谢您发送编修。

Richard：

我现在正在取得进展。 我的应用正在内核 2 上运行、唯一的问题是未发生中断。

当我将应用加载到内核 1 时、内核 1 上会触发中断

当我将应用加载到内核 2 时、不会触发中断：

MCU_timer0 中断信号似乎未路由到内核 2。

在 Lauterbach 脚本中、我使用以下代码将计时器信号连接到内核

Data.Set EAPB：0x9D3001A8 %LE %LONG (0x10000|17)
data.set EAPB：0x9D3001ac %LE %long (0x10000|17)
DATA.SET EAPB：0x9D300004 %LE %LONG (0x10000|17)

我们是否有类似的代码将 MCU 计时器中断路由到内核 2？

谢谢

几乎可以肯定的是“EAPB：0x9D3001A8  “不是正确的限定地址。   “EAPB"是“是调试配置总线。   如果该地址处于 SOC 级别、请使用“EAXI"。“。  如果地址是 R5 本地地址、请使用“SD：“  、您很可能需要“Data.set sd：0x9D3001A8 %LE %LONG (0x10000|17)“。   每当您进行脚本写入时、打开 data.dump 窗口以确保值卡滞和区域签名正确无误。   如果不坚持、则操作到了错误的位置或范围存在访问问题（已锁定或 MPU 阻止防火墙被阻止或未计时或处于重置或...）。  

这些脚本适用于内核 1、但不适用于内核 2。  我从另一位 TI 开发人员那里收到了这些脚本。

Data.Set EAPB：0x9D3001A8 %LE %LONG (0x10000|17)
data.set EAPB：0x9D3001ac %LE %long (0x10000|17)
DATA.SET EAPB：0x9D300004 %LE %LONG (0x10000|17)

我打开了另一个线程以获得帮助、从而将中断输出路由到内核 2。  我可能是外设信号输出路由和映射问题。 我将等待该线程的响应,并保持该线程打开,以验证它们的结果。

谢谢

Jim、

位于 EABP:0x9D3xxxxx 的挂起路由器控制在调试停止时计时器源是冻结还是自由运行。  The 17. 映射到 MCU-R50。  如果您希望对 MCU-R51 产生相同效果、则应使用 18。 （请参阅示例 CMM 中的 suspend-mapping.txt 文件）。

您的问题是、中断在运行时未触发。  此中断缺失问题~与您正在探索的暂挂路由器控制的暂挂状态无关。  如果有任何情况、由于未将暂停/冻结功能链接到 MCU1 (18)、中断源不会停止、无论调试状态如何都会发生。  您当前的中断问题不是针对调试器的问题、而是针对您尝试链接到内核的任何计时器的中断源代码设置问题。

是的、您是对的。 我更改为第二个内核的挂起 CPU 映射。

Data.Set EAPB：0x9D3001A8 %LE %long（0x10000|18。）
data.set EAPB：0x9D3001Ac %LE %long（0x10000|18。）
Data.Set EAPB：0x9D300004 %LE %long（0x10000|18。）

你对我的问题是正确的:中断不会触发,而不是无休止的中断。 我正在尝试获得帮助、以将计时器中断输出路由到第二个内核。

谢谢

VE 在应用程序内启用。 ve 位始终存在、但不会触发中断

好的。  关于 R5 中断流（非调试设置）的另一个 E2E 主题是讨论的合适位置。  一般而言、CPSR I/F + VE 需要正确设置。 然后 VIM 设置需要启用。 正如我在本主题中~的那样、将 VIM 中断设置像您提供的示例一样放入 ELF 文件中是非常不寻常的。  我想这些应该是运行时设置。 通常、类似的设置作为耦合初始化序列的一部分完成、而不是在 elf 加载点完成。  同样、我猜它之所以起作用、是因为时序控制是由 MCU0 上的 ROM 完成的、它需要成为您的应用程序初始化的一部分。 虽然我熟悉 R5 的各个方面、但我不熟悉您所使用的代码。   

我的中断出现问题。 在 SCTLR 中启用 D 高速缓存时、不会命中中断向量。 我必须在 SCTLR 中禁用数据缓存以命中中断矢量。

中断表位于基于 VIM 的 0x40F80000 内部。 我是否需要 MPU 区域才能执行中断向量？

该说明表示中断路径上缺少 dcache 刷新和/或 ICache 失效。   否则、您的代码会使用不应该缓存的内容重新设置 MPU 区域。  如果有一些自我建立的代码被复制到位,则数据可能没有从 dcache 中被清除,因此 ICache 有过时的数据。   如果复制了一些代码、请首先刷新 dcache、然后使 ICache 无效。  

您可以在代码运行了一段“ cache.flick.dc cache.ination.ic“后使用 lb 命令破解内容。  如果有所帮助、可以稍后将其添加到代码中。

Richard：

感谢您的答复！ 我将检查中断路径上的数据刷新。

674.j784s4_r5_coremak_dhry.cmm 将程序加载到第二个内核。 当我刚刚加载代码时、代码还没有启动。 我能够看到在 VIM 寄存器中触发了 MCU_timer0 中断。 我的代码使用 MCU_Timer1、但尚未配置。 我想系统固件会使用 MCU_TIMER0。  我感到困惑。 系统固件在哪里运行？ 它在第一个核心上运行、对吧？   第一个内核和第二个内核具有单独的 VIM、不应在第二个内核上可见。 看起来我的 VIM 由其他程序写入、并导致我的中断问题。

每个内核都有一个专用的 VIM 实例。  是的、timer0 可能已设置并由第一个 R5F 使用。  两个 VIMS 都将看到活动中断的状态。  只有其中一个可能未被屏蔽。  看到预期状态。  您应该检查代码以确保启用了 MCU VIM 上的 MCU 计时器中断。  如果我扫描映射、好像 MCU_timer0 位于 intr 38 上、MCU_Timer1 位于 inter 39 上。  如果启用了任何 MAIN R5、您应该确保其不使用它 (MAIN VIM 看起来在 MAIN_VIM intr 453 上有 MCU_Timer1)。  它也连接到 GIC_SPI 849 上的 A72。

我的问题是 GTC 没有滴答声

我手动执行了以下命令、但没有任何帮助

 DATA.SET EZAXI：0x00A80000 %LE %LONG 0x3

 DATA.SET EZAXI：0x00A90000 %LE %LONG 0x3

 DATA.SET EZAXI：0x00AA0000 %LE %LONG 0x3

有什么想法如何使 GTC 节拍在第二个核心?

语句“Data.Set EZAXI：0x00A90000 %LE %LONG 0x3“允许通过内核停止来停止 GTC。  如果你停下来去、GTC 会跳下去吗？  在调试窗口中看不到它的移动是不确定的。

此外... 无论如何、GTC 可能不会馈送 MCU_Timer1。  GTC 当然连接到 A72、C7x 和调试时间服务。  GPTIMER 等器件具有多种来源。  

GTC 本身根本不是直接读取的意思。  它旨在提供一个时间总线、由 IP 从其灰色编码形式分发和使用该时间总线。  SW 可以读取 GTC 的“调试“寄存器、这些寄存器显示该值的高/低 32 位快照、但用户需要手动检查是否存在翻转。  因为调试视图寄存器不会为您执行此操作。

您是否解决了 mcutimer VIM 问题、或者您是否转向另一个可能足够的时基？

这仍然是我面临的同一个问题。 我的应用中不会触发中断。 根本原因是：

在我的代码中、我正在执行以下操作：

禁用中断

读取 GTC 寄存器 以实现不可中断延迟

启用中断

问题 GTC 正确计时、但在首次读取 GTC_CFG2_CNTCVS_LO 和 GTC_CFG2_CNTCVS_HI 后会冻结、因此始终无法实现延迟、并且不会启用中断。

我的问题是为什么 GTC 在第一次阅读后冻结?  对于 GTC 分区： GTC_CFG0~2、应使用哪一个来读取 GTC 计数器？

是否要我为此问题打开一个新主题？

我没有看到 GTC 值与 R5 读取的关系、除非地址空间被标记为缓存、并且您获得 1 次读取、其余的来自缓存。

您应该在 MPU“停止“时转储 GTC 区域和 CR 寄存器。   在“停止“时、我要从调试启动器 data.dump eaxi 读取 GTC：

Richard：

以下是 MPU 区域：

PER.View GTC0_GTC_CFG1 寄存器已冻结

data.dump eaxi：0xA90000 窗口滴答。

我禁用了 SCTLR 中的 MPU、I-cache/D 缓存、并启用了缓存强制写入

有 15 个 MPU 区域寄存器、图片仅显示 7。  这些寄存器使得 15 为最高优先级、0 为最低。  如果区域重叠、则重叠区域将使用高优先级。  可能其中一个未同步的 MPU 区域有一个值。  您所展示的内容与其他原因不符。  也许如果你分享一个例子,可以发现一些东西。

很抱歉,我的错。 所有其他区域都被禁用、因此我没有上传：

我的代码中禁用了 MPU。 这里的区域将不会生效?

在 IO 寄存器读取之前、我是否需要进行调用缓存验证？ 如果我需要在每次读取寄存器时都执行此操作、那么在此 soc 中、数据缓存只是一个缺点

如果禁用 MPU、则会使用默认的 R5 架构存储器映射（请参阅 ARM Cortex-R5 TRM 中的表 7.1）。  代码的当前设置对于一般代码不安全。  应打开 MPU 以确保 SOC 中集成的安全运行。  目前的状态确实解释了这一点和您引用的其他观察。  如果 MPU 处于关闭状态但 C 位处于开启状态、则访问将被缓存、第一次访问将起作用、其余的将来自缓存。

我启用了 MPU、提供了 8 个存储器区域。 我使用的所有存储器区域都配置为不可缓存、已禁用的 I-cache 和 d-cache。  区域 0x8~0xF 全部禁用。 我特别添加了 VIM 存储区域 0x40f80000、因为它 不可缓存

GTC 寄存器值过时问题已消失。 但每一个都表示 IRQ 已触发、很遗憾、中断 ISR 未执行。

未命中通用中断处理程序函数：

有什么想法为什么?

感谢您发送编修。

CPSR.I 是否未屏蔽且 SCTLR.VE=1

SCTLR.VE=1、CPSR.I =0、中断启用

缺少 VIM 内存的 init 导致错误？  这是初始化序列（设置基址，IRQ 位、FIQ 位，优先级位，使能）。

初始化时、应执行以下任务

1. 对 DED 向量地址（基地址+ 0x30）进行编程
2. 程序组 M 中断映射寄存器（基址+ 0x200 + M*0x20 + 0x18）
3. 程序组 M 类型映射寄存器（基址+ 0x200 + M*0x20 + 0x1C）
4. 编程中断 Q 优先级寄存器（基址+ 0x1000 + Q*0x4）
5. 编程中断 Q 矢量寄存器（基址+ 0x2000 + Q*0x4）
6. 通过启用组 M 中断的设置寄存器（基址+ 0x400 + M*0x20 + 0x08）启用中断

请注意、每个将启用的中断的中断 Q 矢量寄存器（基址+ 0x2000 + Q*0x4）必须在启用中断之前写入、即使软件不会使用该矢量也是如此。  每当中断具有优先级时、就会读取中断的 RAM 位置、如果该位置未初始化、则会报告 ECC 错误。  如果没有使用矢量、则可以通过向每个位置写入 0x0 来初始化 RAM。

我认为 VIM 已正确初始化。 将其加载到第一个内核时所起的作用。 从我之前加载并再次加载的图像中、现在我们可以找到：

寄存器中的所有寄存器

1：INT_EN_SET/INT_EN_CLR 正在启用/禁用 MCU_Timer1 位

2：IRQSTS/STS 指示 MCU_Timer1 已触发

3：INTMAP 为 0、指示 MCU_Timer1 是 IRQ 中断

4：INTTYPE 为 0、指示它是电平触发的中断

DEDVEC 正在保存默认的错误处理程序

IRQvec 会锁存 MCU_Timer1 的矢量地址

ACTIRQ 锁存 MCU_Timer1 中断 (IRQ 编号 0x27、优先级 0x2)

我注意到的问题是：   

在 PRIIRQ 寄存器中、它是 0x00020027、有效位未置位、这表示没有挂起的寄存器

 在 ACTIRQ 寄存器中、它是 0x80020027、有效位被设置、这意味着发生了中断并被锁存

我做了进一步测试：

清除 MCU_Timer1 IRQSTATUS

禁用 MCU_Timer1

完全删除了中断源

然后、通过向 INT_EN_CLR 写入 0x80、我从 VIM 清除 MCU_Timer1 IRQ 状态、验证组寄存器中的所有状态都已清除

已确认 MCU_Timer1（通过向 IRQvEC 写入 0x0）、并且 ACTIRQ 更改为 0x00020027、有效位不再设置

到目前为止、我禁用了中断源、在 VIM 中确认了 IRQ。 不应再次触发 MCU_Timer1。

但是、当我将 0x80 写入 INT_EN_SET 时、VIM 寄存器会进行更新、如下屏幕截图所示。 它看起来像是从其“内存“重新加载,即使源被完全禁用。

我通过将 0x80 写入  INT_EN_CLR、然后将 0x80 写入 INT_EN_SET 来重复该过程、 结果相同。 即使没有源、VIM 也检测到 MCU_Timer1 中断

测试应用 elf/map 已上传

e2e.ti.com/.../8787.test_5F00_app.zip

Richard：

我以前使用 Lauterbach 脚本、没有发生中断。 当我切换到您的脚本 674.j784s4_r5_coremark_dhry.cmm 时、会发生中断、但有时中断周期不正确、偶尔会复位。 脚本  674.j784s4_r5_coremare_dhry.cmm 不如您为内核 0 提供的脚本可靠。 可能仍有一些模块未在第二个内核脚本中正确设置