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.

[参考译文] RTOS/AM5728:从 IPU 访问外设寄存器

Guru**** 2560320 points
Other Parts Discussed in Thread: AM5728

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/611525/rtos-am5728-peripheral-registers-access-from-ipu

器件型号:AM5728

工具/软件:TI-RTOS

我在 AM5728的 Cortex A15内核上运行 Linux、并希望在 IPU1上运行 SYS/BIOS。 我的 IPU1应用需要访问 UART。 我一直在尝试使用 TI-RTOS UART 驱动程序来实现此目的、但无法使它们正常工作。 我已经在 Linux 器件树文件中禁用了相应的 UART、因此我假设 Linux 端不应尝试控制它。 但是、每次我要配置 UART 时、我的应用程序都会崩溃。

在进行一些挖掘后、我的 IPU 似乎无法访问任何外设寄存器;尝试访问会导致硬故障异常。 我甚至无法访问本地的 UNICACHE 或 MMU 寄存器;每当我尝试通过"Registers"视图访问它们时、CCS 都会报告"Error: Unable to Read"。 尝试访问 CCS 存储器浏览器中的位置0x5508 0000 (TRM 表7-10中显示的 IPU1_UNCAHE_CFG 寄存器)只显示问号。  

我猜测某处(Linux 或 Cortex M4/IPU 侧)正在配置 MMU 以阻止访问这些寄存器、但我不知道在哪里查找。 我的 SYS/BIOS 应用程序已设置为内置 AMmu 配置、但我无法确认其设置是否正确、因为我无法读回相应的寄存器。

有人可以提供任何帮助吗?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    请查看此 wiki 页面的以下部分:

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

    我尝试使用 CCS 中的存储器浏览器在您提供的链接上手动转换和查看表后的地址、但没有结果。 例如、根据 TRM 中的表7-10、IPU1_MMU 寄存器的地址为0x5508 0800。 wiki 页面指出地址0x5400 0000被转换为0x7400 0000范围、但最高只能转换为16MB、这意味着它在0x7500 0000处停止、从而使 IPU1_MMU 地址超出转换范围。 我尝试使用调试器和 CCS 浏览 IPU1、但未显示任何内容。

    同样、我尝试访问 UART5 (根据表24-182、基址为0x4806 6000)。 您引用的 wiki 页面指示应将其转换为0x6800 0000范围2MB、这意味着0x6806 6000应处于转换范围内。 同样、CCS 拒绝从该位置访问存储器。 实际上、如果我尝试通过代码访问该范围内的某个位置(例如、读取 UART 寄存器)、我的程序会崩溃。 即使我使用 TI-RTOS UART 驱动程序尝试配置 UART、也是如此;我可以单步执行驱动程序代码、直到它尝试访问 UART 寄存器、此时会引发硬故障异常。

    作为参考、我使用 IpuAmmu.cfg 文件在我的 IPU 应用程序中设置我的 Ammu:
    C:\ti\ipc_3_46_00_02\examples\DRA7XX_linux_elf\ex02_MessageQ\ipu1\IpuAmmu.cfg

    这是否是用于 IPU 的"错误"配置? 我怀疑这可能至少是问题的一部分、因为它指定的转换地址与 wiki 页面显示的地址不匹配。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 USER="Scott Jackson7">同样,我尝试访问 UART5 (根据表24-182,基址为0x4806 6000)。 您引用的 wiki 页面指示应将其转换为0x6800 0000范围2MB、这意味着0x6806 6000应处于转换范围内。 同样、CCS 拒绝从该位置访问存储器。 实际上、如果我尝试通过代码访问该范围内的某个位置(例如、读取 UART 寄存器)、我的程序会崩溃。 即使我使用 TI-RTOS UART 驱动程序尝试配置 UART、也是如此;我可以单步执行驱动程序代码、直到它尝试访问 UART 寄存器、此时会引发硬故障异常。

    在访问该范围之前、您需要首先通过 PRCM 启用 UART5时钟。  我在 wiki 页面上添加了一些更多详细信息:

    http://processors.wiki.ti.com/index.php/Linux_IPC_on_AM57xx#Cortex_M4_IPU_Access_to_Peripherals

    (如果您从上次开始仍然打开该页面、请刷新该页面!)

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

    谢谢! 我在该页面上找到了提及启用 UART5时钟的更新说明。 启用时钟似乎可以解决 IPU 无法读取 UART 寄存器的问题(还可以防止 Linux 端的 rproc 驱动程序在我尝试查看寄存器内容时出现投诉)。

    但是、用于 MMU 和 UNICACHE 等设备的 IPU1本地寄存器似乎仍然不可读。

    现在、我有两个后续问题:

    1) 1)这些地址转换是在哪里设置的、如何设置的? 浏览 wiki 和 IPC 资源自定义表页面、它看起来像是嵌入在 RTOS SDK 中某个位置的标题中。 然而、我还不清楚的是、这些值用于设置处理器内部的存储器映射。 我本来以为这一切都是通过阿姆穆完成的,但情况似乎不是这样。

    2) 2)如何告知 TI RTOS UART 驱动程序在何处查找 UART 寄存器? 虽然资源表映射看起来是作为整个 xdctools 混乱的一部分进行设置的、但 UART 驱动程序(xdctools 也管理该驱动程序)仍在查看未转换的物理地址、我在 CCS 中使用调试器对其进行了验证。 这种访问最终会导致硬件崩溃、大概是因为 UART 驱动程序试图在错误的位置查找。


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

    1)在哪里以及如何设置这些地址转换? 浏览 wiki 和 IPC 资源自定义表页面、它看起来像是嵌入在 RTOS SDK 中某个位置的标题中。 然而、我还不清楚的是、这些值用于设置处理器内部的存储器映射。 我本来以为这一切都是通过阿姆穆完成的,但情况似乎不是这样。
    [/报价]

    AMmu 翻译由 IpuAmmu.cfg 处理、如 wiki 页面中所述。  这个只是执行直通式映射。  为您带来改变的是 IOMMU。  该映射定义为资源表的一部分。  对该表进行任何更改时、应通过单独页面中讨论的"自定义资源表"来处理:

    http://processors.wiki.ti.com/index.php/IPC_Resource_customTable

    [引用 USER="Scott Jackson7]2)如何告知 TI RTOS UART 驱动程序它应该在哪里查找 UART 寄存器? 虽然资源表映射看起来是作为整个 xdctools 混乱的一部分进行设置的、但 UART 驱动程序(xdctools 也管理该驱动程序)仍在查看未转换的物理地址、我在 CCS 中使用调试器对其进行了验证。 这种访问最终会导致硬件崩溃、大概是因为 UART 驱动程序试图在错误的位置查找。
    [/报价]

    我已经询问了 RTOS 团队对此问题的一些反馈。  让我们看看他们的建议。

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

    Brad、


    感谢您的回复! 在阅读您的回答并深入了解 TRM 之后、我认为我现在的理解要好得多。 总之、似乎有两个有效的翻译级别:

    1)儿童基金会 MMU (或 IOMMU)

    2) Ammu

    这两种方式共同决定了 IPU 内核使用的虚拟寻址、不过、正如您指出的、在这种情况下、IOMMU 可以有效地完成所有这些寻址、因为 AMmu 不会对这些地址进行任何转换。 这有助于我了解幕后发生的事情、因此我非常感谢您的反馈。