工具与软件：
您好！
我们将使用 j784s4 SoC 设计电路板。
在 Jacinto SoC 上、我们将使用在其上运行的 Linux 的 ARM 内核、以及用于某些应用的 C7x DSP 内核。 两种类型的处理器都将使用 LPDDR4、我们想评估每种处理器在并发访问 LPDDR4期间使用 LPDDR4的能力、而不影响其他处理器的性能。 实际上、在我们将要设计的定制电路板上、我们计划具有2个 LPDDR4存储体、我们想要单独使用每个存储体、一个用于 ARM 内核、一个用于 C7x 内核。
我们的目的是尝试在 EVM 上获取与定制电路板类似的配置、并确保在访问 LPDDR4时 ARM 内核不会影响 DSP 内核性能。
对于该测试、我们使用了 J784S4XEVM。 对于 Linux、使用的 SDK 是 ti-processor-sdk-linux-adas-k784S4-evm-09_00_00_08；对于 C7x 应用程序、使用的 SDK 是 ti-processor-sdk-rtos-j784S4-evm_09_01_00_06。
为了配置 LPDDR4组、我们使用了 SPRACU8B_Jacinto7_DDRSS_RegConfigTool 和 SPACU8B 数据表、其中介绍了如何使用该工具。
我们将描述所执行的测试之一、该测试看起来最简单、但我们还尝试了其他一些配置、结果始终相同。
使用的配置如下：
我们对该配置的理解是、该工具将2 DDRSS 0和1配置为在 DDRSS0上与0.5GB 和在 DDRSS1上与8GB 一起使用。
在 DDRSS0和 DDRSS1之间配置的交错大小为1GB、粒度为512MB。 我们的理解是、通过此配置、我们可以在 DDRSS0和 DDRSS1之间没有交错。
借助该工具、我们可以生成 k3-j784s4-ddr-evm-lp4-4266.dtsi 文件来更新 u-boot、并生成 board_ddrRegInit.h 文件来更新 C7x 应用程序的 LPDDR4映射。
我们要做的是在 Linux 端使用 LPDDR4的前0、5GB、在 c7x 端使用 LPDDR4的其余部分。
dtsi 文件已在 U-boot 中替换、并且所有 u-boot 组件都已重建。
在 U-boot 中、为了将 LPDDR4的 Linux 使用限制为前0、5GB、我们通过添加 mem=512M 配置了 u-boot 环境变量 args_all
在 Linux 引导后、我们实际上可以观察到所使用的存储器是 LPDDR4从0x80000000变为0x9FFFFFFF 的前512 MB。
此配置完成后、我们编译了将在 Linux 上运行以进行 LPDDR4访问的"流"基准测试。
现在已配置 Linux 端、并且我们拥有可使用流基准测试通过 Linux 对 LPDDR4进行多次访问的基准测试、因此我们还需要能够访问 LPDDR4的 DSP 应用程序。
为此、我们在 packages/ti/drv/udma/examples 中使用了 RTOS-SDK 中的 udma_dru_direct_tr_test。
此测试已经过修改、可在每次测试通过后记录带宽结果。
在首先为第一个内核重建二进制文件之前、我们将 pdk/packages/ti/board/dsp4/j784s4_evm/include/LPDDR4 board_ddrRegInit.h 配置工具生成的二进制文件替换成了 src。
我们还检查了 pdk/packages/ti/build/j784S4中的文件 linker_c7x_freertos.cmd、以及 C7x DDR 的 DDR0_allocated 变量、应为0xA0000000：
#define DDR0_ASSIGNED_START 0xA0000000
编译后、会生成 udma_dru_direct_tr_testapp_freertos_c7x_1_release.xe71并将其复制到/lib/firmware/vision_apps.中的电路板
已删除所有其他 c7x 应用程序、仅运行第一个 c7x 内核。
最后、当电路板启动时、我们会自动启动在 c7x 第一个内核上运行的 DSP 应用。
当我们在 Linux 上启动 STREAM 应用程序时、我们便可直接看到对 c7x 内核测量的带宽的影响。 这意味着通过 ARM 端访问 LPDDR4会影响和降低 访问 LPDDR4的 DSP 性能。
您是否知道我们的测试可能有什么问题？
感谢你的帮助。
