• 状态 Resolved
  • 已锁定 已锁定
  • 个回复 9 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 357 次查看
  • 用户 0 名在线用户
选项
选项
相关

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.

[参考译文] TDA4VM：对 MCU R5F 的 Remoteproc 支持

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1028682/tda4vm-remoteproc-support-for-mcu-r5fs

器件型号：TDA4VM

Karan/Gunter、您好！

我发布这篇文章是为了清楚了解 TDA4VM MCU 岛可以实现的功能。 我们的所有要求都是能够将处理器启动固件完全远程到 MCU 岛 R5F 中。 考虑到 SDK 7.1 (我使用的是 SDK 7.3)的变化、有一组 DMSC 已转移到 MCU R5F、例如电源管理、资源管理、Sciserver、我想知道我们如何向 MCU R5F 提供 Linux 完全远程处理器控制？

我获得以下引导日志、指示 MCU R5F 已启动、仅在仅 IPC 模式下运行。 在 MCU R5F 上加载 ROM 的引导过程中、这是合理的。

[ 12.738925] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 12.745563] [drm] No driver support for vblank timestamp query.
[ 12.758442] [drm] Initialized tidss 1.0.0 20180215 for 4a00000.dss on minor 1
[ 12.766871] [drm] Cannot find any crtc or sizes
[ 12.915085] platform 41000000.r5f: R5F core may have been powered on by a different host, programmed state (0) != actual state (1)
[ 13.058331] platform 41000000.r5f: configured R5F for IPC-only mode
[ 13.197488] platform 41000000.r5f: assigned reserved memory node r5f-dma-memory@a0000000
[ 13.289958] remoteproc remoteproc3: 41000000.r5f is available
[ 13.414318] remoteproc remoteproc3: loading /lib/firmware/j7-mcu-r5f0_0-fw failed with error -22
[ 13.423916] platform 41400000.r5f: R5F core may have been powered on by a different host, programmed state (0) != actual state (1)
[ 13.435701] remoteproc remoteproc3: Direct firmware load for j7-mcu-r5f0_0-fw failed with error -22
[ 13.444758] remoteproc remoteproc3: powering up 41000000.r5f
[ 13.450456] remoteproc remoteproc3: loading /lib/firmware/j7-mcu-r5f0_0-fw failed with error -22
[ 13.465569] remoteproc remoteproc3: Direct firmware load for j7-mcu-r5f0_0-fw failed with error -22
[ 13.477577] remoteproc remoteproc3: request_firmware failed: -22
[ 13.652250] platform 41400000.r5f: configured R5F for IPC-only mode
[ 13.757735] platform 41400000.r5f: assigned reserved memory node r5f-dma-memory@a1000000
[ OK ] Created slice system-systemd\x2dfsck.slice.
[ 13.890109] remoteproc remoteproc4: 41400000.r5f is available
[ 14.019953] remoteproc remoteproc4: Direct firmware load for j7-mcu-r5f0_1-fw failed with error -2
[ 14.030786] remoteproc remoteproc4: powering up 41400000.r5f
[ 14.036493] remoteproc remoteproc4: Direct firmware load for j7-mcu-r5f0_1-fw failed with error -2
[ 14.053905] remoteproc remoteproc4: request_firmware failed: -2

下面的日志来自我对 Uboot 所做的一些更改、这些更改用于在分离模式下操作 MCU R5F。 我看到两个 rproc 句柄-似乎 MCU 是拆分的。 但是、为什么第二个内核仍以仅 IPC 模式启动？ 如何从 Linux 中释放第二个内核以实现完全的 Remoteproc 控制？

是否可以在 core0上运行通常在锁步 MCU R5F 上运行的所有内容并为 remoteproc 释放 core1？

最好了解可能的情况和限制、因为我没有找到文档来帮助理解这一点。

谢谢

Vai

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

    您好、Vai、

    是的、您的理解是正确的 w.r.t 7.1+ SDK。 MCU R5F 现在运行一个 DM 固件、此固件与 TIS/DMSC 固件一起集成到系统功能中。  

    Linux R5 SPL 不会对 MCU R5F 执行任何复位、而是加载新的 DM 固件并分支到它。 MCU R5F 群集的默认模式与器件在上电复位时的默认模式相同。   

    锁步模式和分离模式功能由给定器件的电子保险丝决定。 锁步模式器件能够通过配置支持这两种模式、而分离模式器件只支持分离模式。 在锁步模式器件上、MCU R5F 继续保持在锁步模式、并以 R5 SPL 运行其固件、因此它将始终处于仅 IPC 模式、并且无法切换到远程处理器模式。 在仅支持分离模式的器件上、MCU R5F Core0将运行 DM 固件、并始终处于仅 IPC 模式、并且应该可以在 U-Boot 或内核中引导 Core1。

    您的器件具有什么功能？ 您应该能够通过查看从 ti_sci_proc_get_status()调用中检索到的状态位字段值来判断。  

    此致

    Suman

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

    尊敬的 Suman：

    我使用的是 TDA4VM -它具有可配置的 MCU 岛、因此可以在锁步或分离模式下运行。 这是否意味着、尽管 Uboot 器件配置发生更改且引导模式= 2 (SPLIT)、core0和 core1都将以仅 IPC 模式启动？

    或者是否有方法可以以不同的方式操作 core1并使用 Linux 内核/remoteproc 对其进行控制？

    此外、您能否向我发送一些有关这方面的详细文档以加深我的理解？

    谢谢

    Vai

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

    您好、Vai、

    请在 TRM 中查找寄存器 CTRLMMR_MCUSEC_CLSTR0_CFG。 对于锁步启用的器件、会设置 LOCSTEP_EN 位、这是由控制活动模式的锁步位继承的默认值。 加电时、任何支持锁步_EN 的 R5F 默认以锁步模式出现。 这是 R5 ROM 在引导 R5 SPL 时启动 MCU R5的模式、R5 SPL 继续以相同状态运行 DM 固件。

    模式只能在内核处于复位状态时更改。 因此、为了让您能够将 MCU R5F 更改为分离模式、您必须重置 MCU R5F、但这会破坏系统功能。 请参阅 TRM 章节"6.3.3.2 R5FSS Cortex-R5F 内核"、其中的描述不是很详细。  

    我不确定您对 U-Boot 进行了哪些更改以使其进入拆分模式。 执行此操作时、您确定正在运行7.1+ SDK 吗？

    当尝试在内核运行时更改模式时、此操作应该会发生错误。 仅在7.0和更早版本的 SDK 上才可能实现、如果 R5 SPL 尚未启用引导 MCU R5F、则启动 ATF 后将关闭、U-Boot 或内核可自由更改模式并相应地启动。

    此致

    Suman

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

    尊敬的 Suman：

    是的、我使用的是 SDK 7.3。

    我所做的更改是 R5 SPL、而不是 Uboot。 具体而言、我应用了以下补丁并使用了新的 tidboot3.bin。 我还对 Uboot 进行了几处器件树更改、以分别实例化每个 MCU R5FSS 内核、但这些都很重要。 当我使用新生成的 tispl.bin 时、是的、我确实从 A72 ATF 处获得了错误。 但旧版本(香草 SDK 7.3)没有抱怨。

    diff --git a/tools/k3_gen_x509_cert.sh b/tools/k3_gen_x509_cert.sh
    index b6d055f6f5..428abb7547 100755
    --- a/tools/k3_gen_x509_cert.sh
    +++ b/tools/k3_gen_x509_cert.sh
    @@ -204,6 +204,7 @@ if [ $BOOTCORE == 0 ]; then # BOOTCORE M3, loaded by ROM
    CERTTYPE=2
    elif [ $BOOTCORE == 16 ]; then # BOOTCORE R5, loaded by ROM
    CERTTYPE=1
    + BOOTCORE_OPTS=2
    else # Non BOOTCORE, loaded by SYSFW
    BOOTCORE_OPTS_VER=$(printf "%01x" 1)
    # Add input args option for SET and CLR flags.

    是的、我已经阅读了 TRM 的6.3.3部分、还了解了每一个引导步骤的执行情况。 我可能需要一些澄清。 您说的是、R5 ROM 在锁步模式下启动 MCU R5 (始终吗？) 它需要通过 SPL 关断放弃控制、然后才能重新配置为拆分模式。 我是否理解正确？ 这是否意味着在 SDK 7.1+ DMSC 上运行的情况下、它永远不会关断、因此我们无法在拆分模式下运行 MCU R5 (因为需要将其保持在复位状态才能配置 MMR Clstr CFG)？

    是否有任何可能的权变措施可在拆分模式下运行 MCU R5F？

    谢谢
    Vai

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

    您好、Vai、

    使用默认 SDK、R5 ROM 在支持锁步的器件上以锁步模式启动 MCU R5 (最常见的行为)。 您所做的更改将在分离模式下启动 MCU R5、Core0运行常规 SPL 代码、然后分支到 DM 二进制文件。 Core1 将被驻留在 WFI 中(arch/arm/mach-K3/lowlevel_init.S)。 ROM 确实使用复位周期来升高 R5 SPL、因此这是可行的(MCU R5从 ROM 级和 SPL 级之间完全不同的存储器运行)。 但是、如果 MCU R5F 与默认 SDK 一样以锁步模式启动、那么我们无法在不中断系统的情况下更改模式。

    U-Boot 代码当前缺少关闭这个 Core1的逻辑。  如果可以在 R5 SPL 中完成此操作、则 Core1 应可从 U-Boot 或内核进行配置。 请注意、由于 Core0 正在运行 DM 固件、因此不应关闭 Core0。  当在 R5 SPL 级未找到 MCU R5F 的固件时、在7.0 SDK 中可能会出现此行为。  

    此致

    Suman

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

    尊敬的 Suman：

    非常感谢您提供的详细信息。

    你们是否有 R5 SPL 的补丁、我可以使用它来关闭 core1？ 这对我们以及可能遇到相同瓶颈的其他人来说非常有用。 我们可以使用 TI 的一些帮助来实现此功能。

    谢谢
    Vai

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

    您好、Vai、

    不可以、没有现成的补丁可用于关闭 Core1。 这无疑需要 付出一些努力才能使该功能正常运行并彻底完成。

    此致

    Suman  

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

    尊敬的 Suman：

    谢谢。 有什么想法吗？ 这将真正帮助我们在 MCU 岛上更快地进行开发。

    谢谢

    Vai

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

    您好、Vai、

    这将是一个新功能请求/增强。  我们需要几周时间才能重新制定 计划。 我现在要关闭这个线程。

    此致

    Suman