[参考译文] AM2432：GPMC

您好、Mari、

在 example.syscfg 中、GPMC 存储器地址空间(0x50000000)的 MPU 设置是什么？

此致、

Ming

您好、Ming、  

我要附加 SysConfig 文件、但他们不确定具体要显示哪些设置。 由于 SysConfig 没有任何 GPMC 设置、如果链接的文件未向您提供正确的信息、您是否可以更具体？

e2e.ti.com/.../K9704JF_5F00_PERI_5F00_0719.syscfg

此致、
Mari

您好、Mari、

您的*。syscfg 中根本没有 MPU 设置。 为了使 GPMC 存储器高效工作、必须将以下 MPU 区域添加到您的*。syscfg 中：

 

请参阅 MCU+ SDK 示例中常见 MPU 区域的 example.syscfg

此致、

Ming  

您好、Ming、

下面是他们在 SysConfig 上看到的内容的图像。 他们可以在哪里更改您指示的 GPMC 设置？  

此致、

Mari

您好、Ming、

没关系、我明白您的意思。  

感谢您的支持。 我会告诉他们。

此致、

Mari Tsunoda

您好、Mari、

在 MPU ARMv7中添加新的 CONFIG_MPU_REGION6：

此致、

Ming

您好、Ming、

即使在设置 MPU 区后、问题仍然存在。 您认为这与勘误表 i2313相关吗？  

另外、在 MPU 区的设置方面、应如何决定要设置的区？ 他们遵循该示例、但不确定是否必须为每个存储器和外设设置该示例。  

此致、

Mari

您好、Mari、

他们是否可以使用32位读取？ 至少、为了证明它与勘误表 i2313相关。

此致、

Ming  

您好、Mari、

他们是否还可以共享其修改的*。syscfg 文件？

此致、

Ming

您好、Ming、

明天我会在会议期间向他们提问。 除了新的 sycfg 文件和使用32位读取之外、我还应该要求其他任何东西吗？

此致、

Mari

您好、Mari、

否 这两项是我们目前所需要的。

此致、

Ming

您好、Mari、

ARM MPU 区域按顺序设置。 较晚的区域会覆盖先前的区域。 例如、CONFG_MPU_REGION0是默认值、涵盖2GB 起始地址0x0。 它被设置为"Supervisor RD+WR、User RD"和"严格排序"。 它适用于所有外设的 MMR。

CONFG_MPU_REGION1用于 TCMA 32KB、起始地址为0x0。 由于区域1被覆盖区域0、因此32KB 起始地址0x0变为  "Supervisor RD+WR、User RD"、"Cached"和"Allow Code Execution "、其余的2GB 仍与区域0中定义的相同。

CONFG_MPU_Region2用于 TCMB 32KB、起始地址为0x41010000。 由于 Region2被覆盖区域0和区域1、所以32KB 起始地址0x41010000变为  "Supervisor RD+WR、User RD"、"Cached"和"Allow Code Execution "、其余2GB 仍然与区域0中定义的相同。

CONFG_MPU_Region3用于 OCRAM 2MB、起始地址 为0x70000000。 由于区域3被覆盖区域0、区域1和区域2、因此2MB 起始地址 0x70000000变为  "Supervisor RD+WR、User RD"、"Cached"和"Allow Code Execution "、其余2GB 仍与区域0中定义的相同。

CONFG_MPU_REGION5用于从地址 0x8000000开始的 DDR 2GB。 由于区域5被覆盖区域0、区域1、区域2 和区域3、因此2GB 起始地址 0x8000000变为  "Supervisor RD+WR、User RD+WR"、"Cached"和"Allow Code Execution "、其余2GB 仍与区域0中定义的相同。

他们需要添加的是 CONFG_MPU_REGION6、它用于从地址 0x50000000开始的 GPMC 8MB。 由于区域6被覆盖区域0、区域1、区域2、区域3和区域5、因此8MB 的起始地址 0x50000000变为  "Supervisor RD+WR、User RD+WR"、"Cached"和"Allow Code Execution "、其余2GB 仍与区域0中定义的相同

此致、

Ming

[引用 userid="15702" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum 1127059/am2432-GPMC/4182173#4182173]]他们需要添加的是 CONFG_MPU_REGION6、它用于从地址 0x50000000开始的 GPMC 8MB。 由于区域6被覆盖区域0、区域1、区域2、区域3和区域5、因此8MB 的起始地址 0x50000000变为  "Supervisor RD+WR、User RD+WR"、"Cached"和"Allow Code Execution "、其余2GB 仍与区域0中定义的相同

鉴于所描述的问题是连接到  GPMC 的 FPGA 所看到的不必要的额外读取、是否应 将 CONFG_MPU_REGION6设置 为"严格排序"而不是"缓存"？

如果该区域被标记为"缓存"、则 CPU 可能会产生推测 性读取、这可能会在程序中的读取之外产生对 FPGA 的额外读取。

切斯特、您好！

非常感谢您的更正、是的、它应该是"严格排序"而不是"缓存"

此致、

Ming

您好、Chester、Ming、

感谢您的输入。 我也要求他们发送32位读取的结果、 并将在稍后跟进一些其他信息、包括新的 syscfg 文件。 如果他们从16位器件读取、那么32位读取是否会产生与他们在这里看到的16位读取问题类似的波形？ 如果是这样、它们就不能将32位读取与16位器件一同使用。

此致、

Mari

您好、Mari、

在 MPU 设置正确的情况下、它们不应再看到两次访问的情况。

此致、

Ming

您好、Ming、

感谢您的回复。 遗憾的是、似乎他们仍然看到两次访问。 我要附加 syscfg 文件。 是否有任何其他可能的原因导致此问题、例如开头提到的勘误表？

e2e.ti.com/.../K9704JF_5F00_PERI_5F00_0719_5F00_mcur_5F00_r1.syscfg

此致、

Mari Tsunoda

您好、Mari、

Region6的起始地址缺少一个"0"。 它应该是0x50000000。

此致、

Ming

您好、Ming、

谢谢、我们会要求他们解决问题。

最棒的

Mari

您好、Ming、

即使在他们修复了地址之后、他们也看到了相同的结果。 我已按如下方式连接了波形。 还有其他可能的问题吗？ 这是否与原始主题中提到的勘误表有关？

最棒的

Mari

您好、Mari、

我与 AVV 团队进行了交谈。 他们回来的地方是：

----

我看了波形、幻象周期是由于向 GPMC 发出的请求中的屏蔽字节使能以及从64位 CBA 总线到32位 OCP 总线的转换。

例如、在波形中、写入 GPMC 的 A CBA 之一是

               ADDR = 0x1000_0000、bytecnt = 0x10

字节= 0xF0、数据= 0x0000_0001_0000_0000 (64位 CBA 总线上的第一个数据阶段)

               字节= 0x0F、DATA = 0x0000_0000_0000_0002 (64位 CBA 总线上的第2个数据阶段)

这将转换为 OCP 写入

               ADDR = 0x1000_0000、BURST_Len = 0x4

字节= 0x0、数据= 0x0000_0000 (32位 OCP 总线上的第一个数据阶段)

字节= 0xF、数据= 0x0000_0001 (32位 OCP 总线上的第二个数据阶段)

字节= 0xF、数据= 0x0000_0002 (32位 OCP 总线上的第三个数据阶段)

字节= 0x0、数据= 0x0000_0000 (32位 OCP 总线上的第4个数据阶段)

这将转换为后续16位存储器

               ADDR = 0x0、BIE_n = 0x1、WE_n = 0x1、DATA = 0x0000 (未写入第1个16位数据–幻象周期)

               ADDR = 0x2、be _n = 0x1、WE_n = 0x1、数据= 0x0000 (未写入第2个16位数据–幻象周期)

               ADDR = 0x4、BIE_n = 0x0、WE_n = 0x0、DATA = 0x0001 (写入第3个16位数据)

               ADDR = 0x6、BIE_n = 0x0、WE_n = 0x0、DATA = 0x0000 (写入第4个16位数据)

               ADDR = 0x8、BIE_n = 0x0、WE_n = 0x0、数据= 0x0002 (写入第5个16位数据)

               ADDR = 0xA、BIE_n = 0x0、WE_n = 0x0、DATA = 0x0000 (写入第6个16位数据)

               ADDR = 0xC、BIE_n = 0x1、WE_n = 0x1、DATA = 0x0000 (未写入第7个16位数据–幻象周期)

               ADDR = 0xE、BE_n = 0x1、WE_n = 0x1、DATA = 0x0000 (第8个16位数据未写入–幻象周期)

 ------

由于幻象读取/写入是由16位访问引起的、因此他们可能会尝试使用32位访问。

此致、

Ming

您好、Ming、

如果他们不能使用32位访问、还有哪些其他解决方案可以解决此问题？

此致、

Mari Tsunoda

您好、Mari、

AVV 团队认为、无法摆脱16位访问的幻象周期。 它们是由 CBA/OCP 总线(从64位 CBA 总线到32位 OCP 总线)上的低效传输造成的。

此致、

Ming

您好、Ming、

在今天与他们讨论之后、32位访问将是一个巨大的变化、并将延长他们的计划。 因此、很显然、这不是我们可以很容易地向他们提出的问题。 在我这么做之前、我想确保这对他们来说绝对必要、那么您能回答下面对我的问题吗？

1. 我的理解是、这与勘误表 i2313无关、因此在器件从修订版1更改为修订版2时无法解决。 我的理解是否正确？ 如果不是、您能否说明这是否会在新版本中解决？
2. 是否支持16位访问？ 如果这是一个问题，似乎没有得到充分支持。

此致、

Mari Tsunoda

您好、Ming、

感谢您参加今天的讨论。 如果客户有任何后续问题、将进行更新。

此致、

Mari