This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1123728/am6526-msmc-memory-access-question
尝试 从 A53内核访问 R/W 地址0x60000000 ~ 0x6CFFFFFF 会导致 CPU 异常。 这已通过基于 PDK7.3的软件进行确认。
是否提供了有关访问这些内存地址的文档/说明？ (如果不修改防火墙等，可能无法访问这些地址？)
如果由于某种原因 SYSFW (ETC)限制对这些位置的访问、 我们希望使用 MMU 和/或操作系统设置阻止 R/W 访问...
此致、 Darren
Darren、您好！
要确认、您是否在 AM65x A53内核上运行 TI-RTOS？
此致、
Nick
您好、Nick、
我正在确认如何构建软件、但它不是 Linux。 它是用于构建应用的基于 TI-RTOS 或裸机的代码；该应用无法从 A53内核读取上述寄存器。
您好 Darren、
感谢您提供更多信息。 我们将对此进行研究、并在下周再次与您进行讨论。
＿＿＿＿＿＿＿＿＿
您好、Jianzhong、
此主题是否有更新？ 同样、基于 PDK7.3 (裸机/RTOS)的软件无法从 A53内核向以下寄存器 R/W 进行读/写。
Compute _CLUSTER0_CPU0 0x0060000000 0x0060FFFFFF 16 MB Compute _CLUSTER0_CPU1 0x0061000000 0x0061FFFFFF 16 MB Compute _CLUSTER0_CPU2 0x0062000000 0x0062FFFFFF 16 MB Compute _CLUSTER0_CPU3 0x0063000000 0x0063FFFFFF 16 MB Compute _CLUSTER0_CPU4 0x0064000000 0x0064FFFFFF 16 MB Compute _CLUSTER0_CPU5 0x0065000000 0x0065FFFFFF 16 MB Compute _CLUSTER0_CPU6 0x0066000000 0x0066FFFFFF 16 MB Compute _CLUSTER0_CPU7 0x0067000000 0x0067FFFFFF 16 MB Compute _CLUSTER0_CPU8 0x0068000000 0x0068FFFFFF 16 MB Compute _CLUSTER0_CPU9 0x0069000000 0x0069FFFFFF 16 MB Compute _CLUSTER0_CPU10 0x006A000000 0x006AFFFFF 16 MB Compute _CLUSTER0_CPU11 0x006B000000 0x006BFFFFFF 16 MB Compute _CLUSTER0_CPU12 0x006C000000 0x006CFFFFFF 16 MB
尊敬的 Daren：
很抱歉、回复延迟、但我无法找到有关您的查询的帮助。 我们在支持 AM65xx 上 A53的裸机/TI-RTOS 方面的能力非常有限。 请参阅 此主题的响应。
很抱歉听到蜂鸣声、但标题让我很好奇、这可能会在将来的某个时候影响我们。
我认为这是一个硬件问题、而不是软件问题。 这些地址背后是什么？ TRM (spruid7e)中这些地址的最具体说明见表8-9。 MSMC 存储器区域。 例如、对于0x60000000、显示为"CC_ARMSS0的 MSMC 相干接口"。 我不知道在该地址是否有任何访问、因为如果 A53中的任何一个想要访问 MSMC (SRAM)、它应该使用0x70000000。
您的客户实际上想要做什么？
Dominic
尊敬的 Dominic：
我感谢后续行动。
Jianzhong、
我将尝试详细了解这些地址的写入原因。 但现在、让我们暂时从什么 S/W 转向什么？ 从硬件的角度来看、您能否确认这些寄存器是否为防火墙、或者在某种程度上默认阻止 R/W、或者它们是否需要访问任何特定的寄存器 R/W 序列？
您好 ，Jianzhong，
检查您是否对上述查询有一些输入？
Sreenivasa
起始地址为0x60000000，名为 compate_cluster_CPU0... 存储器映射中的 CPU12应在 AM65x TRM 中标记为保留。
对于背景、这些地址适用于具有与 MSMC3架构连接的 L2暂存区式 SRAM (如 TDA4 C71x DSP)的处理器。 请参阅 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1103661/tda4vm-c7x-l2-address-in-memory-map/4101085。
Pekka
尊敬的 Pekka：
我们了解 compuation_cluster_CPUx 存储器映射应该已标记为保留。 我们担心其他类似的寄存器不能为 R/W、但 TRM 中没有这样描述。
从"2.1主域存储器映射"：
表2-1中未显示的存储器位置是未分配的或保留的、未使用的。 不建议访问这些位置、应避免访问。
您能否确认表2-1 ~表2-6 (所有地址空间)中是否列出了任何未分配或保留的地址、以及是否不应写入这些地址？
一般来说、TRM、特别是存储器映射已经完成了发布过程和审查、但显然至少该错误已经解决。 与 MSMC3相关的存储器映射部分不包含其他错误、其处理方式不允许出现任何其他错误。 我想说、错误不一定直接与该部分存在的事实有关、但并未解释该部分背后的原因。 因此，像"compute _cluster_CPUn： memory region 用于写入连接 CPU 的 L2或 L1 SRAM 区域，如 C7x。 为 Cortex A53计算集群保留存储器。 我没有发现任何其他错误。
一般而言、我会扩大范围、说不会毫无理由地写入存储器映射中的段。 仅仅因为存储器映射中有一个区域并不意味着用户可以对其进行写入。 例如、存储器映射包含 用于 R5内核缓存的区域、写入该区域将产生意外后果。
