[参考译文] Linux/processor-SDK-AM57X：Remoteproc 资源表问题

很抱歉耽误你的时间。 我们将尽快为您提供一些信息。

Ronb、

提前感谢！

Tim、

我使用 M4做了一些工作：M4 SYSBIOS 端内置了一个资源表；Linux 通过 Remoteproc 将 M4代码下载到 IPU1；M4使用 OCMC 内存。 我认为这也适用于您使用 DSP 的情况。

附件是原始和修改后的资源表。 我关注了这个 wiki：

您可以看到添加了条目 devmem14、其中包含"type_CARVEOUT"、而不是"type_DEVMEM"。

然后、我有一个 config.bld、它定义了我修改后的存储器映射和代码放置、以将代码/数据保存到 OCMC 中。 我使用了 evmDRA7XX_ExtMemMapIpu1、因为您应该是 evmDRA7XX_ExtMemMapDsp。 文件也会附加。

最后、我重建了 M4 SysBIOS 应用程序并复制到/lib/firmware.中 Linux 能够下载并运行。

此致、Eric

e2e.ti.com/.../Common.zip

Eric、

 感谢您的努力-很抱歉、我最近几天没有去办公室。

您提供的资源表与我从您那里获得的资源表非常相似。 不幸的是、这些也不会有所帮助。 是否确定 IPU POV 的0x60400000处映射的存储器实际上是 OCMC？ 处理镂空的 Remoteproc 代码不关心提供的物理地址。 我怀疑它将映射除 Linux 器件树中定义的 CMA 区域中的标准内存以外的任何内容。

请参见 linux-rt-sdk 3.1.0.6中的 remoteproc 代码片段 driver/remoteproc_core.c：701 ff。

/**
* rproc_handle_carveout()-处理 phys contg 内存分配请求
*@rproc：rproc handle
*@RSC：资源条目
*@ave:可用数据大小(用于映像验证)
*
*此函
数将处理用于分配物理*连续内存区域的固件请求。
*
*这些请求条目应首先出现在固件的资源表中，
*因为其他固件条目可能会请求将其他数据对象放置在
这些内存区域内*(例如数据/代码段、跟踪资源条目...)。
*
*以这种方式分配存储器有助于更
有效地利用保留的物理存储器*(例如 CMA)、还可以最大限度地减少
映射该存储器所需的 TLB 条目数*(如果@rproc 使用 IOMMU)。 降低 TLB
*压力很重要；它可能会对性能产生重大影响。
*/
static int rproc_handle_carveout (struct rproc *rproc，
struct fw_rsc_carveout *rSC，
int offset，int avail)
{
struct rproc_mem_entry *carveout，*mapping；
struct device *dev =&rsc->dev；
dma_addr_t dma；




t rait (如果是)，则为 void，'rus_ret_ret_ret_eout'

，则为 void；{*ret_ret_ret_ret_eout}

/*确保保留的字节为零*/
if (RSC->reserved){
DEV_ERR(dev,"carveout RSC 具有非零保留字节\n")；
return -EINVAL；
}

DEV_dbg (Dev,"carveout RSC: da %x, PA %x, len %x, flags %x\n",
rsc->da->rsc" rsc->pA、rsc->len、rsc->flags)；

carveout = kzalloc (sizeof (* carveout)、gfp_kernel)；
如果(！carveout)
返回-ENOMEM；

va = dma_alloc_相干(dev->parent、Rsc->len、&dma、GFP_kernel)；
如果(!va){dev_er(dev->parent,
"dma_alloc_相干 er:%d\n", RSC->len);
ret =-ENOMEM;
转到 free_carv;
}

DEV_dbg (dev、"分割 va %p、DMA %pad、len 0x%x\n"、va、
&DMA，RSC->len)；

/*
确定，这是非标准的。
*
*有时我们不能依赖基于 iommu 的通用 DMA API
*来动态分配器件地址、然后
相应地设置 IOMMU *表、因为某些远程处理器可能
*需要_我们使用其
*固件编译时使用的硬编码器件地址。
*
*在本例中、我们必须直接使用 IOMMU API、并将
*内存映射到远程
*处理器所需的器件地址。
*
*显然、不应配置此类远程处理器器件
*以使用基于 iommu 的 DMA API：在
这种情况下、我们期望"dma"包含*物理地址。
//
if (rproc->domain){
映射= kzalloc (sizeof (*映射)、gfp_kernel)；
if (！mapping){
dev_err (dev、"kzalloc 映射失败\n");
ret=-ENOMEM；
转至 dma_free；
｝

ret= iommu_map (rlen-> domain、rsc->dma
、rsc->dma)；rret =-ENOMEM、rsc->dma、rsc->flags
如果(RET)｛
DEV_ERR (dev、"iommu_map failed：%d\n"、ret)；
转至 free_mapping；
｝

//*
稍后我们将在需要取消映射
*所有内容(例如关闭时)时需要此信息。
*
我们不能相信远程处理器不会更改
*资源表，因此我们必须独立维护此信息。
*/
mapping－>da = RSC->da；
mapping－>len = RSC->len；
list_add_tail (&mapping－>node，&rproc->映射)；

dev_dbg (dev， "caveout 映射0x%x 至%pad\n"、
RSC->da、&dma);
}//*


一些远程处理器可能需要知道 PA
*即使它们位于 IOMMU 之后。 例如、OMAP4
的*远程 M3处理器需要此功能、以便它能够控制
*
不在 IOMMU 后面的*片上硬件加速器、因此必须知道 PA。
*
*通常我们不想公开物理地址
*如果我们不必(远程处理器通常
是*不受信任的)，所以我们可能只想针对
*必须拥有此功能的*远程处理器(例如 OMAP4
的*双 M3子系统)进行此操作。
*
*非 IOMMU 处理器也可能希望拥有此信息。
*在本例中、设备地址和物理地址
*是相同的。
*/
RSC->PA = DMA；

carveout->va = va；
carveout->len = RSC->len；
carveout->DMA = DMA；
carveout->da = RSC->da；

list_add_tail (&carveout->node、&rproc->carveouts)；

return 0；

free_mapping：
kfree (映射)；
dma_free：
dma_free (dev->parent、 rsc->len、va、dma)；
free_carv：
kfree (carveout)；
return；
｝

RSC->PA 是您 在资源表中使用 L3_OCMC_RAM (0x40400000)初始化的结构成员。 它不会被读取、但最终会被 CMA 区域 remoteproc 映射的物理地址覆盖。

这个问题仍然没有解决办法。 我认为这主要是一个 Linux 问题- Remoteproc 只是不支持来自几个不同存储器区域的分割-我认为它永远不会被从 CPU 控制物理存储器地址。 尽管这是一个有效的用例、但我很确定我不是唯一想要在不同存储器类型/区域中分割位置的人。

最棒的

   Tim

PS.：按照资源表、如何在 devmem 段之后放置分割线是一种不好的习惯、将分割线放入 devmem 子结构中有点误导...  我的看法