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.

[参考译文] DRA821U:Cortex-R5F 固件作为 DM-Firmware 时的 IPC 问题

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1636242/dra821u-ipc-issue-with-mcu-r5f-firmware-as-dm-firmware

器件型号: DRA821U
主题: DRA821 中讨论的其他器件

您好 TI、

我们正在使用 DRA821 J7200 为定制板开发一个 Cortex-R5F 固件。
因此、我们将 FREERTOS-J7200(版本 11.01.00.02)与 PROCESSOR-RTOS-SDK 配合使用。

对于 PROCESSOR-LINUX-SDK、我们将 Linux-J7200(版本 10.00.07.03)与 linux-ti-staging-rt_6.6 内核配合使用。

我们的 Cortex-R5F 固件用作 DM-Firmware、在 A72 引导过程开始后由 SPL 加载该 DM-Firmware。

对于与 Linux 和 EthFw 的处理器间通信、我们实现了以下函数来初始化 IPC:

STATIC UINT32 Ipc_RemoteProc[] =
{
   IPC_MPU1_0, IPC_MCU1_0, IPC_MCU2_0, IPC_MCU2_1,
};

STATIC CONST UINT32 Ipc_NumRemoteProc = sizeof(Ipc_RemoteProc) / sizeof(Ipc_RemoteProc[0]);

STATIC UINT8 Ipc_VDevMonStackBuf[IPC_TASK_STACKSIZE] STACK(8);

STATIC UINT8 Ipc_RPMessageTaskBuf[IPC_TASK_STACKSIZE] STACK(8);

STATIC UINT8 Ipc_RPMessageBuf[IPC_RPMSG_DATA_SIZE] __attribute__ ((section("ipc_data_buffer"), aligned(8)));

STATIC UINT8 Ipc_VirtIOBuffer[IPC_VIRTIO_BUF_SIZE] __attribute__ ((section("ipc_data_buffer"), aligned(8)));

RESULT_TYPE Ipc_Init(UINT32 selfProcId)
{
   RESULT_TYPE result = RES_ERR;
   INT32 status;
   Ipc_InitPrms initPrms;

   /* Step 1: Initialize the multiproc with a list of all cores that are required to participate in the communication */
   status = Ipc_mpSetConfig(selfProcId, Ipc_NumRemoteProc, Ipc_RemoteProc);
   if (status == IPC_SOK)
   {
      /* Initialize params with defaults */
      IpcInitPrms_init(0U, &initPrms);
      initPrms.printFxn = &Ipc_Print;

      /* Step 2: Init IPC driver */
      status = Ipc_init(&initPrms);
      TRACE_ERR_IF((status != IPC_SOK), status, "Error setting up RemoteProc (Core : %s) \r\n", Ipc_mpGetSelfName());
   }

   if (status == IPC_SOK)
   {
      /* Step 3: Load resource table */
      status = Ipc_loadResourceTable((void *)&ipc_remoteproc_ResourceTable);
   }

   if (status == IPC_SOK)
   {
      /* Step 4: Initialize VirtIO */
      Ipc_VirtIoParams virtIoParam;

      virtIoParam.vqObjBaseAddr = (void*) Ipc_VirtIOBuffer;
      virtIoParam.vqBufSize = Ipc_NumRemoteProc * Ipc_getVqObjMemoryRequiredPerCore();
      virtIoParam.vringBaseAddr = (void*) IPC_VRING_BASE_ADDRESS;
      virtIoParam.vringBufSize = IPC_VRING_BUFFER_SIZE;
      virtIoParam.timeoutCnt = IPC_VIRTIO_TIMEOUT;
      status = Ipc_initVirtIO(&virtIoParam);
      TRACE_ERR_IF((status != IPC_SOK), status, "Failed to init virtIO");
   }

   if (status == IPC_SOK)
   {
      /* Step 5: Init RPMessage */
      /* Initialize the param and set memory for HeapMemory for control task */
      RPMessage_Params cntrlParam;

      RPMessageParams_init(&cntrlParam);
      cntrlParam.buf = &Ipc_RPMessageBuf;
      cntrlParam.bufSize = IPC_RPMSG_DATA_SIZE;
      cntrlParam.stackBuffer = &Ipc_RPMessageTaskBuf;
      cntrlParam.stackSize = IPC_TASK_STACKSIZE;
      status = RPMessage_init(&cntrlParam);
      TRACE_ERR_IF((status != IPC_SOK), status, "Failed to init RPMsg");
   }

   if (status == IPC_SOK)
   {
      /* Step 6: Create RPMessage monitor task */
      Ipc_CreateMonitorTask();
      result = RES_OK;
   }

   return result;
}


如果我通过存储器中的调试器将 Cortex-R5F 固件与 EthFw 一起加载并通过调试器启动该固件、则此初始化很有效。

但是、如果我设置了与 DM-Firmware 相同的 Cortex-R5F 固件并让其从 SPL 开始、则会从 RPMessage_init () 中收到数据中止异常、并显示消息:
image.png

您能提供一些此错误和行为可能来自哪里的信息吗?
为什么只有从 SPL 开始才会发生这种情况?

此致、
Frank

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

    您好 Frank、

    我们的 Cortex-R5F 固件用作 DM-Firmware、在 A72 引导过程开始后由 SPL 加载。

    无论 MCU1_0 内核上运行的其他应用软件如何、TDA4 器件上的所有 MCU R5F 固件都必须提供 DM 固件 (SciServer) 功能。

    如果我通过内存中的调试器将 Cortex-R5F 固件与 EthFw 一起加载并通过调试器启动、则此初始化很好。

    EthFw 在不同的 MCU2_0 内核右侧运行。 您应该能够独立运行 MCU R5F 固件、通常这是正在运行的系统上的绝对最小配置。

    但如果我设置与 DM-Firmware 相同的 Cortex-R5F 固件并让其从 SPL 开始、则会从 RPMessage_init () 中收到数据中止异常、并显示消息:

    您在这里使用的具体固件是什么? 您是从头开始构建自己的固件、还是从 PDK 提供的现有固件/示例参考开始?

    您能提供一些此错误和行为可能来自哪里的信息吗?

    从布线中可以看到您实际已引导 MCU R5F 内核、因此这不是 MCU R5F 本身的引导加载逻辑问题。

    为什么只有从 SPL 开始才会发生这种情况?

    这是否意味着当与其他一些引导加载程序 (->类似于 SBL) 一起使用时、同一个固件会引导?

    此致

    Suman

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

    您好 Frank、

    因此、我们将 FREERTOS-J7200(版本 11.01.00.02)与 PROCESSOR-RTOS-SDK 配合使用。

    对于 PROCESSOR-LINUX-SDK、我们将 Linux-J7200(版本 10.00.07.03)与 linux-ti-staging-rt_6.6 内核配合使用。

    此外、请勿混搭不同版本的 Linux SDK 和 RTOS SDK。 TI 不支持或验证任何混合版本 SDK。  

    10.0 SDK 已旧、我们不再支持此 SDK。  11.2 SDK 是最新的 SDK、也是 LTS SDK、其将提供 1 年维护版本。 因此、建议您从 这个 11.2 SDK 开始。  

    此致

    Suman

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

    您好、Suman、

    无论 MCU1_0 内核上运行的其他应用 s/w 如何、TDA4 器件上的所有 MCU R5F 固件都必须提供 DM 固件 (SciServer) 功能。

    我们已经在 MCU-R5F-FW 上实现了 SciServer。

    EthFw 在不同的 MCU2_0 内核右侧运行。 通常、您应该能够独立运行 MCU R5F 固件、这是正在运行的系统上的绝对最小配置。

    通过使用调试器加载 MCU1_0 内核、我们能够独立运行 MCU-R5F-FW。

    您在这里使用的具体固件是什么? 您是从头开始构建自己的固件、还是从 PDK 提供的现有固件/示例参考开始?

    我们基于 SDK 中的不同示例实现、具体取决于所需功能。
    对于 IPC 初始化、我们引导了 ipc_echo_testb_freeRTOS。

    这是否意味着当与其他一些引导加载程序一同使用时、这个相同的固件是否会引导->像 SBL 一样?

    抱歉、我没有正确地表述。 否、我们不使用 SBL 等其他引导加载程序。  我的意思是、如果我通过调试器启动并启动固件、为什么不会发生这种情况?

    此致、
    Frank

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

    尊敬的 Suman:

    10.0 SDK 已旧、我们不再支持此 SDK。  11.2 SDK 是最新的 SDK、也是 LTS SDK、其将提供 1 年维护版本。 因此、建议您从 这个 11.2 SDK 开始。  [/报价]

    我很抱歉,我在这一点上不是很谨慎。 我们使用 PROCESSOR-SDK-LINUX-RT  和实时内核 J7200。
    在 TI 网站上、我注意到、 
      2024 年 12 月 18 日的版本 10.01.08.01 是最新版本、并且版本 10.00.07.03 和 10.01.08.01 之间的版本说明差异不会使我的更改变得很重要。

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

    您好 Frank、

    我们基于 SDK 中的不同示例实施、具体取决于所需的功能。
    对于 IPC 初始化、我们引导了 ipc_echo_testb_freeRTOS。

    是的、这是使用 Linux 进行引导时的正确示例。 Linux SPL 不会执行 MCU R5F 的复位、因此 ATCM 将保持禁用状态、因此您需要使用利用 BTCM 进行引导的固件 (testb -> b 反映 BTCM)。  

    我已经仔细研究了您的代码、但与参考示例相比、Linux 缺少一个步骤。 virtio 缓冲区是由 Linux 内核准备的、您需要等待此准备完成、然后才能在 RTOS 端初始化 RPMessage 堆栈。

    您需要利用  ipc_isRemoteReady () 此函数在进一步初始化之前等待资源表结构上 vdev 状态的同步点。 鉴于 MCU1_0 是在 R5 SPL 期间引导的、您基本上需要等到内核 remoteproc 和 rpmsg 驱动程序被探测到 MCU1_0、并将 virtio buffers/vdev 状态初始化为资源表。

    请参阅中的代码片段 /packages/ti/drv/ipc/examples/common src /ipc_testsetup.c

    使用 Linux 运行固件时、必须满足资源表和此 vdev 同步要求。

    此致

    Suman

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

    您好 Frank、

    [引用 userid=“648374" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1636242/dra821u-ipc-issue-with-mcu-r5f-firmware-as-dm-firmware/6309056 ]在 TI 网站上、我注意到  自 2024 年 12 月 18 日起的版本 10.01.08.01 是最新版本、并且版本 10.00.07.03 和 10.00.08.01 之间的版本说明差异对于我的更改不是很重要。

    10.01 SDK 是最后一个独立的 RT-Linux 版本。 这是因为 RT-patchset 与主线 Linux 内核分离。

    从 11.x SDK 开始、没有单独的 RT-Linux 内核分支、因为 RT 器件在同一 Linux 内核上可用。 因此、较新的 Linux SDK 是适用于常规 Linux 和 RT-Linux 的统一 SDK。

    在任何情况下、比较不在 10.00 和 10.01 之间。 您正在尝试 PROCESSOR-RTOS-SDK   将 11.01.00.02 J7200 与 10.01.08.01 PROCESSOR-SDK-LINUX-RT 和  J7200 配合使用。 如果您打算使用 10.01 RT-Linux、则应该继续使用等效的10.01 PROCESSOR-SDK-RTOS J7200

    此致

    Suman

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

    尊敬的 Suman:

    感谢你的帮助。
    这大大延迟了 MCU-R5F-FW、但有助于 IPC 通信。
    我还在代码中识别出数组 Ipc_Remote  

    static Uint32 Ipc_Remote Proc[]= { IPC_MPU1_0、IPC_MCU1_0、IPC_MCU2_0、IPC_MCU2_1、 };

    不允许包含正在运行内核的内核 ID(在本例中为 IPC_MCU1_0)、这会导致在此期间出现空指针异常  RPMessage_init(&cntrlParam);

    也感谢您对 SDK 版本和 RT-Linux 的提示:

    从 11.x SDK 开始、没有单独的 RT-Linux 内核分支、因为 RT 器件在同一 Linux 内核上可用。 因此、较新的 Linux SDK 是适用于常规 Linux 和 RT-Linux 的统一 SDK。

    到那时我才知道这个事实、我们将尽快切换 SDK 版本。


    With best regards,
    Frank