[参考译文] AM625：PRU1 SBBO 对 FS 的写入在 PocketBeagle 2 (HS-DDR) 上静默丢弃—在 SK-AM62 上工作

您好：

请共享用于执行存储器写入的 PRU 测试代码。

此致、

Nick

我还想让您像在 SK-AM62 板上的 pocketbeagle 上运行一样运行测试、看看 PRU 子系统是否显示在 sudo k3conf show hosts 下。 到目前为止、我还没有看到 PRU 内核无法写入 DDR、但我也没有尝试在 pocketbeagle 上对 PRU 进行编程。

您确实要确保 pocketbeagle 板使用启用了 PRU 子系统的 AM62x 器件型号 — 请参阅数据表>器件命名约定>特性代码 G（无 PRUSS）和 C（启用 PRUSS）

此致、

Nick

您好、Nick、

器件确认为 ti,am625 （启用 PRUSS、而不是 G 型号）。

我们没有 SK-AM62。 BeagleBoard.org 在不和的基础上确认、他们只使用主线 U-Boot、而不是 ti-u-boot：

tiboot3.bin：U-Boot SPL 2026.01-gef03e3548837（2026 年 1 月 30 日）

您可以查看 k3conf show hosts SK-AM62 以进行比较吗？

谢谢！

Minjae

您好、Nick、

这是  PRU 测试代码的相关部分。 在启动时、main() 通过设置为 resourceTable.rpmsg_DDR.pa以下的指针、通过 64 次连续写入将 DDR 分割为零：

 0xDEADBEEF 在加载固件之前、Arm 向分割 PA 写入数据。 PRU1 启动并运行此循环后、ARM 0xDEADBEEF 原封不动地读回、并且所有 64 次写入都被静默丢弃。

Minjae Bae

此内存区域是否缓存？ 是否有任何防火墙配置为阻止 A 内核以外的访问？

您好：

关于缓存： DDR 分割 (PA ~0xb0f00000) 是来自 ARM 侧的标准可缓存 DDR。 为了测试缓存的一致性、从 ARM 写入 0xDEADBEEF 并重新启动 PRU1 后、我们丢弃了 ARM 页缓存 (echo 3 > /proc/sys/vm/drop_caches) 并重新读取、它仍然是 0xDEADBEEF。

这会排除高速缓存的稳定性；PRU 写入不会到达物理 DDR。

关于防火墙：未应用明确的 CBASS/防火墙配置。 我们使用随附的默认 boardcfg：

BeagleBoard.org Debian Trixie IOT Image 2026年01月30日
主线 U-Boot SPL 2026.01-gef03e3548837
内核：6.18.32-arm64-k3-r39

谢谢、
Minjae Bae

你好、Minjae、

1) 我没有尝试过你使用的特定 sharedMem 结构。 让我们使用我测试过的确切命令来运行一个实验、以确保结构的定义方式或地址传递到 PRU 没有任何问题。

2) AM62x 上没有 OCP 端口。 AM335x 您必须启用 OCP 端口以允许 PRU 内核到达 PRU 子系统外部、但在 AM62x PRU 内核上、默认情况下可以访问整个地址空间。 删除“// OCP 主站端口已启用“的代码

根据我针对 PRU 入门实验室测试的代码、这是我要使用的测试代码：
https://github.com/TexasInstruments/open-pru/blob/main/academy/getting_started_labs/c_code/solution/firmware/main.c 

/* check that PRU code is running with local address & DDR address */
/* replace with actual DDR address */
#define local_addr  (*((volatile unsigned int *)0x110))
#define ddr_addr  (*((volatile unsigned int *)0x90000000))

...
local_addr = 0xAAAAAAAA;
ddr_addr = 0xAAAAAAAA;

然后、您可以使用 devmem2 从 Linux 验证值（或连接 CCS）。

有关更多信息、请参阅 AM62x PRU Academy > PRU 入门实验>实验 5：如何调试 PRU 固件
https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AejrmUhg02z05nG9WJ3TVQ__AM62-ACADEMY__uiYMDcq__LATEST 

此致、

Nick

您好！

感谢您的答复！ 我已删除对 OCP 主站端口的引用。  

对于测试、我运行了与实际 DDR 地址 (0xB0F00000) 一起提供的确切代码。

我通过从 Linux 读取 Shared RAM PA 字段、确认 PRU1 运行了新固件：

devmem2 0x30050038→0xB0F00000

你好、Minjae、

感谢您跟进您的解决方案！ 我以前从未见过这样的东西,所以我和你一起学习。 您最终是需要修改任何文件、还是像在 SDK 文档中讨论的那样重建 U-boot 文件一样简单？

如果在该 DDR 区域上有防火墙、那么我会预计 PRU 的 DDR 访问会失败。 但是、如果没有配置防火墙、我仍然 不清楚阻止从 PRU 写入 DDR 的确切机制。

此致、

Nick

您好、Nick、

只是为了澄清 U-Boot 的方方面面： 我运行的是由 BeagleBoard.org 维护的基于主线的 U-Boot 树、而不是 TI SDK fork (ti-u-boot)。 具体的工作引导加载程序版本字符串为：U-Boot SPL 2026.01-gef03e3548837（2026 年 2 月 10 日）。 我认为问题归结为一个事实、即 1 月初 eMMC 映像上提供的快照尚未为 ICSSG 子系统启用必要的防火墙配置/节点。

更新为 2 月份封装构建、以正确的电路板配置拉取、从而为 PRU 打开 CBASS 互连路径。 我这边不需要修改源代码； 我认为、这完全归功于上游主线配置、能够赶上 TI 内部分支中的防火墙设置！

谢谢您、

Minjae Bae