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.

[参考译文] Linux/processor-SDK-AM57X:DSP 内部存储器使用情况

Guru**** 2587365 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/591441/linux-processor-sdk-am57x-dsp-internal-memory-usage

器件型号:PROCESSOR-SDK-AM57X

工具/软件:Linux

你好!

我目前正在测试 AM57xx SOC 上 Linux 和 C66x DSP 协处理器之间的 IPC。  

我需要有关 Linux 内核中的 Remoteproc 子系统的一些建议:

下面是 rsc_table_vayu_dsp.h 文件的代码片段、我将使用该代码片段进行测试:

{
TYPE_CARVEOUT、
DSP_MEM_TEXT、0、
DSP_MEM_TEXT_SIZE、0、0、"DSP_MEM_TEXT"、
}、

{
TYPE_CARVEOUT、
DSP_MEM_DATA、0、
DSP_MEM_DATA_SIZE、0、0、"DSP_MEM_DATA"、
}、

{
TYPE_CARVEOUT、
DSP_MEM_HEAP、0、
DSP_MEM_heap_size、0、0、"DSP_MEM_heap"、
}、 

如果我理解正确、则使用 DSP MMU 将 DSP 生成的整个代码映射到 AM57xx SOC 的主存储器。 是这样吗?

linker.cmd 文件确认这一点、因为所有段都映射到某种虚拟地址、而不是 映射到位于0x800000处的内部存储器:

内存
{
L2SRAM (rwx):org = 0x800000,len = 0x40000
OCMC_RAM1 (RWX):org = 0x40300000,len = 0x80000
OCMC_RAM2 (RWX):org = 0x40400000,len = 0x100000
OCMC_RAM3 (rwx):org = 0x4050000,len = 0x100000
EXT_code (rwx):org = 0x95000000,len = 0x100000
EXT_DATA (RW):org = 0x95100000,len = 0x100000
EXT_HEAP (RW):org = 0x95200000,len = 0x300000
trace_BUF (RW):org = 0x9f000000,len = 0x60000
EXC_DATA (RW):org = 0x9f060000,len = 0x10000
PM_DATA (rwx):org = 0x9f070000,len = 0x20000
}

段
{
.text:load >> EXT_code
.ti.decompress: load > EXT_code
.stack:加载> EXT_DATA
组:加载> EXT_DATA
{
.bss:
.neardata:
.rodata:
}
.cinit:加载> EXT_DATA
.pinit:加载>> EXT_DATA
init_array:load > EXT_data
.const:load >> EXT_DATA
.data:load >> EXT_DATA
.fardata:load >> EXT_DATA
.switch:load >> EXT_DATA
.sysmem:加载> EXT_DATA
far:load >> EXT_DATA
.args:load > EXT_DATA align = 0x4、fill = 0{_argsize = 0x64;}
.cio:加载>> EXT_DATA
.ti.handler_table:load > EXT_data
.c6xabi.exidx:加载> EXT_DATA
.c6xabi.extab:load >> EXT_DATA
tracebuf:load > trace_BUF
errorbuf:"加载">" EXC_DATA "
vecs:load > EXT_code
.resource_table:load >0x95000000、type = NOINIT
xdc.meta:加载> EXT_DATA、类型= COPY

} 

现在、问题是:如果我想按原样使用 IPC 示例、但使用 DSP 的专用内部存储器、我需要做什么?

我想我需要修改 linker.cmd 文件来将所有段映射到 L2SRAM、然后从资源表中删除所有 DSP_MEM_text、DSP_MEM_DATA 和 DSP_MEM_HEAP。 是这样吗?

出于好奇:如果我将 linker.cmd 文件更改为使用内部 L2SRAM 并在资源表中将 L2SRAM 地址添加为分割区、会发生什么情况?

从 Remoteproc 驱动程序的角度来看、elf Loader 似乎会将 DSP 固件放置在正确的物理 L2SRAM 位置、但 MMU 也会被配置为将地址 0x800000映射到主存储器。 那么、会出现什么行为? MMU 是否可以将地址 0x800000映射到主存储器?

感谢您的回答!

此致、
Franz

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    软件团队已收到通知。 他们将在这里作出回应。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Franz、

    在4.4+内核上、OMAP (AM57x) Remoteproc 驱动程序支持内部存储器加载、并且需要通过 DT 提供内部存储器区域。 较旧版本特别要求通过资源表提供 RSC_INTMEM 资源、并且需要 lists.infradead.org/.../270534.html 补丁。 如果 linker.cmd 被正确更新、你应该能够运行 INTMEM 中的所有内容。 我正在尝试找到一个演示用例的示例。

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

    你好,Garrett!

    感谢您的回答! 这是我已经预料到的。 因此、从 RSC 表中删除 type_CARVEOUT 条目(DSP_MEM_text、DSP_MEM_DATA 和 DSP_MEM_HEAP)并相应地调整 linker.cmd 文件应该足够了(在4.4+内核上)?  

    谢谢、此致、
    Franz

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

    是的、这应该已经足够了。 请注意、当前的 Remoteproc 基础结构不支持将 vring 或 vring 缓冲区放置在远程处理器的内部存储器中、因此用于 Virtio rpmsg 传输的 vring 和 vring 缓冲区仍需要使用外部 DDR。 资源表仍应包含 DSP_MEM_IPC_VRING 条目。 DSP_MEM_IPC_DATA 条目用于 remoteproc 跟踪、因此除非您还重新定位并将其链接到内部存储器、否则需要继续维护相应的资源表条目。

    关于您关于将 L2SRAM 添加为 CARVEOUT 的另一个问题、这将是不执行的 DSP MMU 确实涵盖了整个4 GB 空间、因此 Remoteproc 将分配 DDR 存储器并使用 L2SRAM 地址将该存储器映射到 MMU、但 DSP 的任何访问都不会使用该地址到达 MMU。 DSP CPU 地址视图仅通过从0x12000000开始的 XMC 接口显示。 remoteproc 驱动程序会首先使用 remoteproc 平台驱动程序的.da_TO_va() rproc 操作查找 DSP 器件地址的转换,以便在加载时仍能正确转换地址。

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

    感谢您的回答! 现在、我们已经对它进行了完美的说明!

    此致、
    Franz