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.

[参考译文] TMDX654IDKEVM:禁用通过 Remoteproc 加载的 R5F 固件上的缓存导致固件崩溃/停止

Guru**** 2553260 points
Other Parts Discussed in Thread: SYSBIOS

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/997404/tmdx654idkevm-disable-caching-leads-to-firmware-crash-stop-on-r5f-firmware-loaded-via-remoteproc

器件型号:TMDX654IDKEVM
Thread 中讨论的其他器件:SYSBIOS

我们目前正在尝试根据 RTOS SDK 中的 IPC 示例代码为 R5F 处理器设置示例应用。

通过此示例代码、我们希望在 A53上运行的主应用程序和在 R5F 上运行的应用程序之间实现共享存储器握手。

执行时、此握手在 R5F 上的 IPC ECHO_TEST_BareMetal 应用程序上工作

CSL_armR5CacheEnableDCache (0);      /*禁用 D-cache */

我们在 R5F 上操作的基于 BIOS 的 ECHO_TEST 应用调用函数

CSL_armR5CacheEnableDCache (0);      /*禁用 D-cache */

导致断言或崩溃、至少应用程序在调用后停止运行。

缺少一些初始化、无法无误地调用函数、但我不知道:

int main (空)

IPC_initSciclient();
IPC_boardInit();// für UART_printf *
UART_printf ("UART 已初始化!\n");

ipc_loadResourceTable ((void*)&ti_ipc_remoteproc_ResourceTable);

UART_printf ("LoadResourceTable =%p\n"、&ti_ipc_remoteproc_ResourceTable);

CSL_armR5CacheEnableDCache (0);         -->崩溃

UART_printf ("CSL_armR5CacheEnableDCache \n");

(笑声)

也许有人可以帮助我们禁用 D 缓存所缺少的功能。

非常感谢

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    在 SYSBIOS 中运行时、缓存应由 SYSBIOS 初始化。 应在 SYSBIOS 配置文件中配置缓存。

    SYSBIOS 还为缓存维护操作提供缓存 API。

    有关更多详细信息、请参阅 SYSBIOS 文档。

    此致、
    斯坦利

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

     我们使用

    PROCESSOR-SDK-LINUX-RT-AM65X  

    作为操作系统基础进行构建。

    我们刚刚安装的 RTOS SDK、以提供用于创建 R5F 固件的示例代码。 因此、我们使用了 RTOS SDK 的 IPC 示例代码。

    无论如何、我们的 AM65x 都可以在 Linux 和 Linux SDK 中的引导加载程序上运行。

    关于 R5F 和 A53之间的共享存储器处理、我们认识到两种不同的行为:

    1A)当我们使用 IPC_ECHO_TEST_BareMetal 作为示例代码的基础时、 可以调用 CSL_armR5CacheEnableDCache ()(在调用(IPC_ECHO_TEST ()-给定示例代码-之后)、并且地址0x81000000上 R5F 和 A53之间的 SHM 握手按预期工作。 但是:调用 CSL_armR5CacheEnableDCache () UART_printf()后,不再在控制台上打印  

    1b)当我们不调用 CSL_armR5CacheEnableDCache ()时,在0x81000000处从 A53写入的内容不会被传输或可以从 R5F 中读取(R5F 仍然看到初始"0",而不是 A53写入的值)。 另一方面、UART-printf 打印输出可以正常工作并传输到控制台。

    2)  在尝试清除整个 IPC 示例应用程序代码并仅将我们自己的代码放入 main()时,R5F 应用程序在调用 CSL_armR5CacheEnableDCache ()时挂起或崩溃。

    如果 SYSBIOS 是禁用缓存的正确位置:我查看  了 system-firmware-image-gen repro 以查找有关禁用 DCache 的配置位置、但未找到它们:

    /ti-processor-sdk-linux-rt-am65xx-evm-07_01_00_18/board-support/k3-image-gen-2020.08b/socs/am65x/evm/board-cfg.c 等。

    我可以在哪个配置文件中启用/禁用 DCache? 据我所知、SYSBIOS 文档依赖于 RTOS SDK。

    如果有可能通过调用我们的 R5-application 的 main()中的 CSL_armR5CacheEnableDCache ()来禁用 DCache (这种可能性存在,因为它在运行之前的某些默认 IPC_ECHO_TEST 示例代码时起作用) 如果不禁用 UART、这将是我们的首选解决方案、因为我们只想在握手时禁用缓存。   

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="459468" URL"~/support/processors/f/processors-forum/997404/tmdx654idkevm-disable-caching-leads-to-firmware-crash-stop-on-r5f-firmware-loaded-via-remoteproc "]我们在 R5F 上操作的基于 BIOS 的 ECHO_TEST 应用程序调用函数[/quot]

    我假设您基于上述语句在 SYSBIOS 上运行应用程序。

    如果正确、您的 R5固件构建应具有*。cfg 文件以配置 SysBIOS。

    我不清楚您是如何构建 R5固件的。

    如果您要在 RTOS SDK 中从 PDK 构建它、则 SYSBIOS 配置文件位于 pdk/packages/ti/build/am65xx/sysbios_r5f.cfg 中。

    在此文件中、您可以通过以下链接找到已启用的高速缓存。

    cache.enableCache = true;

    此致、
    斯坦利

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Stanley、

    非常感谢、这解决了我们的问题。 现在、R5F 和 A53应用程序之间的存储器握手工作。

    不管我是怎么实现的、因为我通过设置禁用了缓存

    cache.enableCache = false;
    在中  
    /opt/ti-processor-sdk-rtos-am65xx-evm-07_01_00_14/pdk_am65xx_07_01_00_55/packages/ti/drv/ipc/examples/common/am65xx/sysbios_r5f.cfg
    UART 仍然工作,但会阻塞地从 UART_printf()发送数据,这意味着并非每个 UART_print()都能立即打印输出(就像缓存.enableCache = true 之前那样),但以某种方式从内部缓冲区中的 UART_printf()调用中收集所有数据, 有时会在缓冲区已满时打印出来。
    我的 observations 是否合理?如果是、UART 输出如何连接到此处的高速缓存?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    没有内部缓冲、打印函数会将每个字符写入 UART 寄存器。

    我可以想到的一种可能性是程序运行速度较慢、并且禁用高速缓存、因此可能会被其他更高优先级的任务取代 UART_printf()。

    此致、
    斯坦利

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    非常感谢您对行为的解释、这是有道理的!