[参考译文] TDA4VM：c7x 和 a72高速缓存一致性

Ryan、

我被要求查看您的问题。  这看起来已经等待了一段时间、我们或您没有提供任何更新。  很抱歉。  我将尝试添加一些注释、希望这些注释有助于加深理解。

该系统旨在与 MSMC 直接连接存储器(DDR 和 MSMC-SRAM)保持一致。 MSMC 中的逻辑将监控所有登录到这些存储器中的事务、并执行必要的操作来保持所有主器件同步。 如果您的应用需要硬件一致性、则需要使用这两个存储器端点之一。 其他 MSMC-cluster SRAM 将需要软件管理以确保一致性。

A72和 C7x 使用相同的 MMU 格式、因此简化视图 适用于 A72、适用于 C7x。  或许 ARM 将是您更熟悉的参考。 标有"复制后缓存内部"的内存是由硬件跟踪的内存。  属性+地址+安全状态(安全与非安全)用于跟踪事务。 可以调整事务之后的边带属性的实体需要确保这些设置不未对齐或一致性将丢失。 导致问题的一个示例是 R5群集。 它们都有一个寄存器、用于强制设置安全与非安全状态(USB 等其他实体具有相似的控制点)。 如果 R5设置为安全、但 A72或 C7x 的同一个存储器是非安全问题。

MSMC 存储器可设置为相干 SRAM 或相干 L3级缓存。   高速缓存和 SRAM 之间的最佳设置将取决于系统应用程序需求。 根据规范、L2CFG.M3CACHE 用于设置 C7x L2高速缓存为配置为高速缓存的区域分配或不分配 MSMC L3的能力。 0指示 UMC (统一存储器控制器)不分配、1指示 UMC 跟随边带(cmemtype 和 ccinner)决定是否分配。

Lauterbach 问题。 MAP.denyaccess 旨在使调试体验更加强大。 跟踪解码器可能需要读取存储器以重建跟踪。  在调试器端口完全成熟之前、有时会在运行过程中读取到错误位置。 根据 c7x 系统的状态、这可能会导致锁定、从而妨碍高效调试。 此映射拒绝是一种保护措施、可阻止用户或调试器发出可能的致命物理访问。 在当前的 TRACE32构建中、我没有发现这方面的任何问题、因此今天可能是针对用户在一个胡说的地方进行探测的保护。  如果您的应用程序在这些其他区域设置了有效的内容、您可以调整设置。

此致、

Richard W.

在启用 MMU 之前、c7x 能否访问64位 DDR 地址(如0x8_8000_0000)？ 在启用 MMU 且未设置 map.denyacess 之前、我已经看到 Lauterbach 在将代码加载到64位地址时挂起。

在几天内入住登记很差、但我相信 c7x 是安全模式、a72可能不是这样、这就是一致性不起作用的原因。

假设 R5不处于安全模式、它能否与 a72或其他 R5内核保持一致？

Ryan、

在启用 CMMU 之前、C7x 使用复位 uTLB 条目值进行访问。  它们默认为1-1映射、最多可为安全监控器提供16GB 的地址空间。 访问超过这个区域(如0x880000000中的高 DDR)将导致一个故障。  如果没有 MMU 和异常处理程序，这些访问将导致16GB 以上的锁定。 如果您使用 map.denyaccess 进行实验、您会发现您可以访问0x4_0000_0000 (16GB)、而不会折叠较低的地图空间。 其预期引导代码可以在低16 GB 的空间内运行。 在启用 MMU 之前、可以对其中一个 uTLB 条目进行重新编程、以便在必要时提供更高的访问。

是的、内核之间的混合安全状态会导致别名。 硬件不会使这些访问保持一致。 只有自然迁移，访问有时才可能是一致的。

对于 MSMC-SRAM 或 MSMC-DDR 中的通用访问、将存在交叉群集一致性。 安全状态必须保持一致。 在当地进入诸如透明度和建立信任措施或非 MSMC SRAM 之类的地区将是不一致的。

此致、

Richard W.  

将 CXM 设置为3根监控器(S)与5根(超级安全)、然后设置相应的 TCR、TBR、MAR、SCR_S 寄存器、以固定一致性。 谢谢。  

只能编程1 uTLB。 我可能需要同时访问0和0x8_8000_0000、以便可以从0跳转到高位地址。 猜我需要启用 MMU、然后跳转至0x8_8...  

指出 R5是否安全的位在哪里？

我还想知道外设(USB、CSI、eMMC、UDMA)的时间/时间。 使用 MSMC 或转到 DDR。 它们是读取还是写入分配？ 如果数据已经在 MSMC 中、则可能只使用 MSMC 缓存、否则请转到 DDR。 CPU 缓存刷新是否会导致数据进入 DDR 或仅进入 MSMC？ 什么是了解 MSMC 和 DDR 中的内容的好方法？ 我认为 Lauterbach E 复选框仅显示 MSMC。