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.

[参考译文] TDA4VH-Q1:A72 Linux 中收到错误的 DDR_SHARED_MEM_ADDR

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1456063/tda4vh-q1-wrong-ddr_shared_mem_addr-is-getting-received-in-a72-linux

器件型号:TDA4VH-Q1
主题中讨论的其他器件:TDA4VH、TDA4VM

工具与软件:

尊敬的 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