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.
工具与软件:
尊敬的 TI 团队:
我们有了全新的 TDA4VH 板、并尝试了解 c7x 内核中的共享内存分配和运行内核。
作为活动的一部分、我们将介绍如何在 A72和 C7x 内核之间分配和使用共享存储器。
在 app utils ( app_mem_linux_dma_heap.c - appMemDmaHeapAlloc())的帮助下,我们通过使用 appMemGetVirt2PhyBufPtr ()函数转换为物理地址来分配共享内存并检查地址。
我们看到的地址为90000000、而不是0xC0000000。
( 0xC0000000是 DDR_SHARED_MEM_ADDR 的 VISION 应用中所有位置提到的地址)
我们验证了 dtsi 文件- k3-j784s4-rtos-memory-map.dtsi、该 basr 地址称为0x00000000、而不是0xC0000000。
vision_apps_shared_region:vision_apps_shared-memory{
compatible ="dma-heap-carveout";
REG =<0x09 0x00000000 0x00 0x3 c000000>;
};
我们的测试使用 SDK 版本09.02.00.05 (2024年4月08日)。
我们需要将 dtsi 文件 dma-heap-carveout 地址修改为0xC0000000并进行测试、或者我们会单独进行处理吗?
由于节假日、将从12月25日到1月2日推迟答复。 感谢您的耐心
您好!
我们需要将 dtsi 文件 dma-heap-carveout 地址修改为0xC0000000并进行测试、还是将单独处理?
0xC0000000是 DDR_SHARED_MEM 地址0x900000000的另一个虚拟映射。 适用于 R5 32位内核、而 C7x 和 A72 64位内核访问64位地址。
您可以在 vision_apps/platform/j784s4/rtos/文件夹中看到 system_memory_map.html 中的地址、还可以在 vision_apps/platform/j784s4/rtos/c7x_1/main.c 中看到 C7x 的 MMU 映射
此致、
Nikhil
您好、Nikhil:
感谢您的响应。
那么、在 C7x 中、我需要任何转换吗?
我将 从 A72通过 IPC 在 C7x 中获得正确的地址0x900000000 (在 A72中、我复制了该地址中的一些数据)、
当我尝试访问存储在该区域中的数据时、c7x 会崩溃、而如果我将该地址转换为虚拟地址 、即在 C0000000中、它可以在没有崩溃的情况下完美地工作。
从上面的注释可以看出、我好像不需要进行任何转换、我们应该只对 R5F 内核进行转换。
您好!
所以、在 C7x 中、我需要进行任何转换吗?
我将 从 A72通过 IPC 在 C7x 中获得正确的地址0x900000000 (在 A72中、我复制了该地址中的一些数据)、
当我尝试访问存储在该区域中的数据时、c7x 崩溃、而如果我将该地址转换为虚拟地址 、即在 C0000000中、它可以在没有崩溃的情况下完美地工作。
是的、这应该不是必需的。 我想知道您是如何访问此文件的吗?
您好、Nikhil:
我通过以下方式访问:
uint32_t m_free_list_offset =* reinterpret_使<uint32_t*>(m_pool);//其中 void* m_pool;
在 C7x 中、我 通过 IPC 接收 m_pool 地址、该地址为正确值 i.e: 0x900000000 、在 A72中为其分配 uint32_t 值。
如果我将 m_pool 转换为 C0000000、则上面的行能够很好地运行。
我在 MID 平台上测试的相同代码正常工作、因为在 TDA4VM 中、共享存储器使用32位寻址(0xB8000000)
在 TDA4VM 中、这一概念不存在。 DDR_SHARED_MEM 位于 DDR 的低2GB 区域。
在 TDA4VH 中、C7x 为 MMU_MAPPED 到较低区域、如下所示
此致、
Nikhil