[参考译文] SK-AM62P-LP：通过运行 Linux (使用和不使用 IPC)的 A53加载 R5

尊敬的专家：
1->当我使用 IPC 做同样的事情时、您能告诉我原因吗？


我们又遇到了1个问题、我们阅读了 IPC 文档、他们告诉我们在 linker.cmd 停止工作后、在它中做一些内存映射。
https://software-dl.ti.com/mcu-plus-sdk/esd/AM62PX/10_00_00_14/exports/docs/api_guide_am62px/IPC_GUIDE.html

这是我们在阅读该文档后更新的内容。

Update linker command file

    When IPC RP Message is enabled, a shared memory is used to exchange packet buffers between different CPUs. This shared memory MUST be mapped to the same address across all CPUs.
    This is done via the linker command file as shown in below snippet taken from IPC RP Message Echo example

/* specify the memory segment */
MEMORY
{
    ...
 
    /* shared memories that are used by RTOS/NORTOS cores */
    /* On R5F,
    * - make sure there is a MPU entry which maps below regions as non-cache
    */
    USER_SHM_MEM            : ORIGIN = 0x701D0000, LENGTH = 0x00004000
    LOG_SHM_MEM             : ORIGIN = 0x701D4000, LENGTH = 0x00004000
    RTOS_NORTOS_IPC_SHM_MEM : ORIGIN = 0x701D8000, LENGTH = 0x00008000
}
 
 
/* map the shared memory section to the memory segment */
SECTION
{
    ...
 
    /* General purpose user shared memory, used in some examples */
    .bss.user_shared_mem (NOLOAD) : {} > USER_SHM_MEM
    /* this is used when Debug log's to shared memory are enabled, else this is not used */
    .bss.log_shared_mem  (NOLOAD) : {} > LOG_SHM_MEM
    /* this is used only when IPC RPMessage is enabled, else this is not used */
    .bss.ipc_vring_mem   (NOLOAD) : {} > RTOS_NORTOS_IPC_SHM_MEM
}

我们看到 linker.cmd 在默认情况下已经设定的

/* this is used only when IPC RPMessage is enabled, else this is not used */
    .bss.ipc_vring_mem   (NOLOAD) : {} > DDR_IPC_VRING_RTOS
    GROUP {
        /* This is the resource table used by linux to know where the IPC "VRINGs" are located */
        .resource_table: {} palign(1024)
    } > DDR_IPC_RESOURCE_TABLE_LINUX

您好、Nick。
听得不错。 让我浏览一下这些链接、我会很快告诉您。

请记住、即使 remoteproc0在一次启动时与特定内核关联、下次重新启动处理器时它也可能与其他内核关联！

但我不会这么做。 因为根据我的理解、remoteproc0用于 R5、remoteproc1用于 wakeupR5。

此致、
去巴希

Debashis、您好！

您的理解是错误的。 确保与正确内核通信的唯一方法是检查 remoteproc*/name 值。

remoteproc#和远程内核之间的关联可以为每个引导更改。 Remoteproc#未静态分配给特定内核。 而是按照 Linux 知道内核的顺序分配这些数字、这并不是确定性的。

在具有大量内核的处理器上、这意味着您往往会看到一般模式(例如、在 AM64x 上、M4F 通常是 remoteproc0-1、R5F 内核通常是 remoteproc0-4、PRU 子系统内核通常是更高的数字)、但确切的数字仍会更改每个启动。

此致、

Nick

Debashis、您好！

请花更多时间浏览  多内核模块的"远程内核上的应用开发"部分。

此处介绍的2个概念(以及一系列其他概念)：
https://dev.ti.com/tirex/explore/node?node=A__AWp5ySyLZuhSwoIuT2efPQ__AM62P-ACADEMY__fp5YxRM__LATEST

1) 1)将资源表放置在 Linux devicetree 文件中的哪个位置、以匹配 MCU+ SDK 位置？

2) 2)如何确保 Linux 不会覆盖远程内核使用的 DDR 和 SRAM 存储器位置？

此致、

Nick