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.

[参考译文] AM62A7-Q1:是否可以增大 edgeai_shared_region

Guru**** 2805425 points

Other Parts Discussed in Thread: SYSCONFIG

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1614743/am62a7-q1-is-it-possible-to-increase-the-edgeai_shared_region

器件型号: AM62A7-Q1
主题: SysConfig 中讨论的其他器件

您好、

我们有一个复杂的 gstreamer 流水线、其中 ISP、LDC、多个多标量器、两个编码器和 edgeai 推理、可在 4K 传感器上工作。

我们遇到的问题是、我们正在耗尽 edgeai_shared_region DMAable 存储器。

是否可以增加 edgeai_shared_region 的大小(也许可以降低 Linux、CMA 大小并移动 edgeai_core_堆)?

我已经了解 了 AM62A7:这是 Edgeai 内存分配查询 — 处理器论坛-处理器 — TI E2E 支持论坛 的一部分、可以减少内存分配。

此致、

Bas Vermeulen

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

    雷斯 ·格里姆斯利,当你参与的主题,我的基础上这个问题。

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

    尊敬的 Bas:

    问得好。 是、可以增加此存储器区域的大小。 应根据存储器映射更新来修改 gen_linker_mem_map.py 脚本[1]。 将计算新地址、大小等、并针对随后将重建的相应固件、库和设备树修改相应的文件。

    您主要对 DDR_SHARED_mem [2]部分感兴趣。 固件构建器文档中概述了一些大小/对齐限制。 该脚本负责对齐、但不一定涉及大小限制

    这要求 AM62A 固件构建器来实施这些变更、因为 DM R5 固件(也运行引导加载程序;引导分区中的 tiboot3.bin)和 C7x NPU 固件(运行具有/usr/lib/firmware 中 TIDL 的 AI 模型)将会修改。 否则、必须在 Linux ROOTFS 中更新/usr/lib/libtivision_apps.so

    [1] https://git.ti.com/cgit/processor-sdk/vision_apps/tree/platform/am62a/rtos/gen_linker_mem_map.py 

    [2] https://git.ti.com/cgit/processor-sdk/vision_apps/tree/platform/am62a/rtos/gen_linker_mem_map.py#n213 

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

    尊敬的 Reese Grimsley :

    我获得了固件构建器、无需更改即可进行构建。 进一步研究 gen_linker_mem_map.py 时、它提到即使我们有 2GB 的存储器、存储器映射也只考虑 1GB。

    在第 118 行中、还显示共享内存可使用的最大内存为 515 MB。 我可以增加这个值吗? 当前固件已经使用了 512 MB、我想在此基础上再添加 212 MB(将 ddr_shared_mem_size 从 172*MB 更改为 384*MB;300 MB 也可以使用)。 这不符合当前的约束。

    是否允许将 DDR_mem_size_2 从 515 * MB 更改为 727 * MB 等内容来执行此操作?

    此致、

    Bas Vermeulen

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    它提到内存映射仅考虑 1GB、即使我们有 2GB 的内存

    我认为这意味着只有 1 GB 的内存映射用于这些显式区域、其余的可以用于 Linux 等高级操作系统。  

    AM62A SoC 的存储器映射为 DDR 映射了 0x8000 0000 到 0xFFFF FFFF、除 0x8 8000 0000 之外的任何内容都是从 0x8 8000 0000 开始(这需要在 32 位 R5 内核上进行一些地址转换,因此我们可以避免这种情况)。

    第 118 行还指出、可用于共享内存的最大内存为 515 MB。 我可以增加这个值吗? 当前固件已经使用了 512 MB、我想在此基础上再添加 212 MB(将 ddr_shared_mem_size 从 172*MB 更改为 384*MB;300 MB 也可以使用)。 这不符合当前约束。

    其他区域(标称 Linux)从该点开始(Linux CMA 从 0xc0000 0000 [1]开始)、因此必须在 DTS 中更改... 此处的 python 脚本未覆盖该区域。 我相信如果 DTS 发生更改、可以进一步增加 DDR_SHARED 和类似的区域。 我认为、这样、您可以增加 ddr_mem_size_2。  

    [1] git.ti.com/.../k3-am62a7-sk.dts

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

    感谢您的澄清、我马上讲一下。

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

    尊敬的 Reese Grimsley :

    我正在构建固件、并进行了以下修改:

    gen_linker_mem_map.py:

    --- ti-firmware-builder-am62axx-evm-11_01_00_05.orig/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py     2025-07-29 06:12:07.000000000 +0000
    +++ ti-firmware-builder-am62axx-evm-11_01_00_05/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py  2026-02-11 13:07:06.987916604 +0000
    @@ -115,7 +115,7 @@
     ddr_mem_size_1  = 80*MB
    
     ddr_mem_addr_2 = 0xA0000000;
    -ddr_mem_size_2 = 515*MB
    +ddr_mem_size_2 = 727*MB
    
     #
     # Other constant sizes
    @@ -210,7 +210,7 @@
    
     # Shared memory for Buffers/ION allocator
     ddr_shared_mem_addr     = tiovx_log_rt_mem_addr + tiovx_log_rt_mem_size;
    -ddr_shared_mem_size     = 172*MB;
    +ddr_shared_mem_size     = 384*MB;
     carveout_size += ddr_shared_mem_size
    
     ddr_viss_config_heap_addr = ddr_shared_mem_addr + ddr_shared_mem_size;

    我还修改了 k3-am62a7-sk.dts、以确保一切正确:

    --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
    +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
    @@ -52,7 +52,7 @@ linux,cma {
                            compatible = "shared-dma-pool";
                            reusable;
                            size = <0x00 0x24000000>;
    -                       alloc-ranges = <0x00 0xc0000000 0x00 0x24000000>;
    +                       alloc-ranges = <0x00 0xcd400000 0x00 0x24000000>;
                            linux,cma-default;
                    };
    

    我可以构建固件、但当我在 EVM 上运行一致性测试时、我在 tivxInternalNode.innestiveTestNodeReplicate 中收到错误、之后某个地方会出现死锁。

    [运行 0020 ] tivxInternalNode.NegantiveTestNodeReplicate...
    1332.823992 s:vx_zone_error:[vxReplicateNode:2348]无效的引用类型
    1332.824032 s:vx_zone_error:[vxReplicateNode:2348]无效的引用类型
    1332.824052 s:vx_zone_error:[ownAddReferenceToContext:422]无法锁定
    环境中
    1332.824063 s:vx_zone_error:[ownCreateReference:830]添加对续的引用
    Ext 失败
    1332.824077 s:vx_zone_error:[ownCreateReference:840]无法添加到 reso
    urces 表
    1332.824088 s:vx_zone_error:[ownGetErrorObject:55]无法锁定上下文
    1332.824099 s:vx_zone_error:[vxGetStatus:1250]引用为空
    1332.824109 s:vx_zone_error:[vxReplicateNode:2382]参数 0 为空!
    1332.824421 s:vx_zone_warning:[vxReleaseContext:1439]找到了参考 0x
    ffffff920aa750 类型 00000804 在外部计数 1、内部计数 0、释放
    很好
    1332.824437 s:vx_zone_warning:[vxReleaseContext:1441]释放引用
    (name=org.khronos.openvx.box_3x3) 现在作为垃圾回收 1332.824449 s 的一部分: vx_zone_warning:[vxReleaseContext:1468]一个内核名称为 o
    Rg.khronos.openvx.box_3x3 未被移除、可能是由于内核模块未被卸载。
    1333.162415 s:vx_zone_warning:[vxReleaseContext:1469]作为器件移除
    f 垃圾收集
    1333.162435 s:vx_zone_error:[vxRemoveKernel:258]内核已锁定
    【完成】tivxInternalNode.NodeTestNodeReplicate

    找出问题所在的最佳程序是什么? 我是在 Ubuntu 20.04 chroot 中构建的。 如果需要、我可以向您发送用于设置内容的脚本。

    此致、

    Bas Vermeulen

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

    尊敬的 Bas:

    您能否发送完整的符合性测试日志? 系统在此之后是否锁定或挂起? 我想这就是您所说的死锁、但请确认。

    像“负 TestNodeReplicate“这样的测试是负面测试、这意味着它们预计会失败

    当您重建固件时、您是否还更新了引导加载程序和/usr/lib/libtivision_apps.so? 转换器

    我在这个新常见问题解答中提供了更多有关存储器映射更新的一般信息[1]

    [1] 【常见问题解答】AM62A7:如何更新 AM62A 存储器映射?  

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

    尊敬的 Reese:

    系统在此之后挂起、看起来像是在 R5F 代码中获取的一个锁、未释放。

    我使用 make linux_fs_install_sd 将固件和库安装到使用创建的 SD 卡中  sudo sdk_builder/scripts/mk-linux-card.sh /dev/sda 和  ./sdk_builder/scripts/install_to_sd_card.sh

    这应该会导致 libtivision_apps.so 和固件被正确复制。

    完成新的运行后、我将添加另一个包含日志的回复。

    Bas

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

    e2e.ti.com/.../conformance_5F00_core.log.gz

    Attached 是 conformance_core 运行的 (gzipped) 日志。

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

    Reese Grimsley 

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

    我在修改后的软件上缺少一些 rpmsg 设备:

    - virtio0.ti.ipc4.ping-pong.1.13
    - virtio1.rpmsg_chrdev.–1.13
    - virtio1.ti.ipc4.ping-pong.–1.21

    这可能与它失败的原因有关。 有什么想法,如何确保他们出现?

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

    尊敬的 Bas:

    日志在这里很有用。 许多测试尝试运行、但只是失败了。 这可能确实是 RPMSG / IPC 驱动程序的结果。

    发生故障时、您是否可以运行以下操作并共享输出?  

    cat /sys/kernel/debug/dma_buf/bufinfo # Shows DDR SHARED MEM allocations
    /opt/vision_apps/vx_app_heap_stats.out  # shows per-heap allocations on remote cores

    您在此符合性测试期间是否看到了 linux/dmesg 日志? 我预计 RPMsg 会产生错误。

    以下是通过还是失败?

    rpmsg_char_simple  -r 0 -n 10 #MCU R5; not used for TIOVX
    rpmsg_char_simple  -r 8 -n 10 #C7x
    rpmsg_char_simple  -r 15 -n 10 #DM / WKUP R5; used by TIOVX

    此处[1]提供了有关此 IPC 的文档、用于 IPC 示例。 这也会失败吗?

    我不知道为什么此时测试失败了。 我们尚未大致尝试此更改、即用户空间存储器/CMA 存储器的一部分压入 0xC000 0000 以上(同样,DDR_SHARED_REGION 会跨越此地址)。 我在引导时看到了这样的问题、并在下次重新引导时解决了问题。 我需要检查是否知道此问题的解决方案/根本原因。

    [1] https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AYEyuCg.JDdHqpTk3sF27g__AM62A-ACADEMY__WeZ9SsL__LATEST 

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

    有没有机会你可以尝试类似的东西? 我需要至少 64 MB 以上,但更好。

    通过减小 C7x 的暂存区、或许能够实现这一点、但在使用 edgeai 时不想让我们麻烦。

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

    新日志: e2e.ti.com/.../conformance_5F00_core.2.log.gz

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

    我还在 DM-R5 上看到了以下消息:

    (出于某种原因,邮件不想发布)

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

    尊敬的 Bas:

     您最近的评论是否不正确? DM-R5 消息没有出现。  

    看起来实际上是相同的错误日志。 许多基本一致性测试内核都未注册、但这应该是在 引导 DMR5 内核时注册的。 `/opt/vx_app_arm_remote_log.out`应该有这样的历史,像这样:  

    [MCU1_0]      0.037978 s: CIO: Init ... Done !!!
    [MCU1_0]      0.038038 s: APP: Init ... !!!
    [MCU1_0]      0.038060 s: UDMA: Init ... !!!
    [MCU1_0]      0.038173 s: UDMA: Init ... Done !!!
    [MCU1_0]      0.038215 s: MEM: Init ... !!!
    [MCU1_0]      0.038234 s: MEM: Created heap (DDR_LOCAL_MEM, id=0, flags=0x00000004) @ af000000 of size 16777216 bytes !!!
    [MCU1_0]      0.038287 s: MEM: Created heap (DDR_CACHE_WT_ME, id=7, flags=0x00000000) @ adc00000 of size 4194304 bytes !!!
    [MCU1_0]      0.038322 s: MEM: Init ... Done !!!
    [MCU1_0]      0.038337 s: IPC: Init ... !!!
    [MCU1_0]      0.038365 s: IPC: 3 CPUs participating in IPC !!!
    [MCU1_0]      0.038670 s: IPC: Waiting for HLOS to be ready ... !!!
    [MCU1_0]      0.043211 s: Sciserver Version: v2025.07.0.0-REL.MCUSDK.K3.11.01.00.16+
    [MCU1_0]      0.045983 s: ##RM_PM_HAL Version: v11.01.02
    [MCU1_0]      0.048930 s: ##Starting Sciserver..... PASSED
    [MCU1_0]     13.669783 s: IPC: HLOS is ready !!!
    [MCU1_0]     13.669872 s: IPC: Init ... Done !!!
    [MCU1_0]     13.669896 s: APP: Syncing with 2 CPUs ... !!!
    [MCU1_0]     14.056967 s: APP: Syncing with 2 CPUs ... Done !!!
    [MCU1_0]     14.057012 s: REMOTE_SERVICE: Init ... !!!
    [MCU1_0]     14.057195 s: REMOTE_SERVICE: Init ... Done !!!
    [MCU1_0]     14.057226 s: FVID2: Init ... !!!
    [MCU1_0]     14.057256 s: FVID2: Init ... Done !!!
    [MCU1_0]     14.057275 s: VHWA: VPAC Init ... !!!
    [MCU1_0]     14.057291 s: SCICLIENT: Sciclient_pmSetModuleState module=219 state=2
    [MCU1_0]     14.057413 s: SCICLIENT: Sciclient_pmSetModuleState success
    [MCU1_0]     14.057475 s: VHWA: LDC Init ... !!!
    [MCU1_0]     14.057571 s: VHWA: LDC Init ... Done !!!
    [MCU1_0]     14.057595 s: VHWA: MSC Init ... !!!
    [MCU1_0]     14.058126 s: VHWA: MSC Init ... Done !!!
    [MCU1_0]     14.058147 s: VHWA: VISS Init ... !!!
    [MCU1_0]     14.059958 s: VHWA: VISS Init ... Done !!!
    [MCU1_0]     14.059994 s: VHWA: FC Init ... !!!
    [MCU1_0]     14.060034 s: VHWA: FC Init ... Done !!!
    [MCU1_0]     14.060098 s: VHWA: VPAC Init ... Done !!!
    [MCU1_0]     14.060220 s:  VX_ZONE_INFO: Globally Enabled VX_ZONE_ERROR
    [MCU1_0]     14.060243 s:  VX_ZONE_INFO: Globally Enabled VX_ZONE_WARNING
    [MCU1_0]     14.060266 s:  VX_ZONE_INFO: Globally Enabled VX_ZONE_INFO
    [MCU1_0]     14.060767 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.test_kernels.cmd_timeout_test on target MCU1-0
    [MCU1_0]     14.060842 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.test_kernels.tiovx_overhead on target MCU1-0
    [MCU1_0]     14.060902 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.capture.scalar_sink on target MCU1-0
    [MCU1_0]     14.060957 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.capture.scalar_source on target MCU1-0
    [MCU1_0]     14.061012 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.capture.scalar_sink2 on target MCU1-0
    [MCU1_0]     14.061068 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.capture.scalar_source2 on target MCU1-0
    [MCU1_0]     14.061124 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.capture.scalar_intermediate on target MCU1-0
    [MCU1_0]     14.061181 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.test_kernels.scalar_intermediate_2 on target MCU1-0
    [MCU1_0]     14.061240 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.test_kernels.scalar_source_error on target MCU1-0
    [MCU1_0]     14.061298 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.test_kernels.scalar_source_obj_array on target MCU1-0
    [MCU1_0]     14.061356 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.test_kernels.scalar_sink_obj_array on target MCU1-0
    [MCU1_0]     14.061415 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.test_kernels.pyramid_intermediate on target MCU1-0
    [MCU1_0]     14.061473 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.test_kernels.pyramid_source on target MCU1-0
    [MCU1_0]     14.061531 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.test_kernels.pyramid_sink on target MCU1-0
    [MCU1_0]     14.061587 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.test_kernels.test_target on target MCU1-0
    [MCU1_0]     14.061642 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.capture.image_intermediate on target MCU1-0
    [MCU1_0]     14.061704 s:  VX_ZONE_INFO: [ownAddTargetKernelInternal:189] registered kernel com.ti.ext.obj_array_split on target MCU1-0
    

    固件构建器中是否修改了任何源代码? 除了 vision_apps/platform/am62a/RTOS 中的存储器映射文件外、即  

    否则、我建议查看特定内核的 example.syscfg 和子文件夹中生成的/DPL 文件、即/vision_apps/platform/am62a/rtos/ {c7x_1、mcu1_0}。 首先检查 syscfg 文件中的区域大小和地址是否都正确 — 这用于生成“generated(生成)“子文件夹。

    我担心、将 DDR_SHARED 区域和类似区域增加到 1GB DDR 以上的自定义更改可能未由此处播放的脚本完全处理。 这不是典型的用例、恐怕我们在这里可能会遇到错误。  

    我可以通过缩小 C7x 的暂存区来实现这一点、但不希望在使用 edgeai 时让我们陷入麻烦。

    默认情况下、C7x 的暂存区未被利用。 可能可以减小空间。 如果禁用了 TIDL 占先、则会更多地利用暂存区(更准确地说,C7x 堆中的分配会被移动到暂存区、因为它们不再需要进行维护。

    • 我们在这一问题上提供有限的支持、但可以通过在 /c7x-mma-tidl/arm-tidl/tiovx_kernels/tidl/dsp/vx_tidl_target.c 中定义`#define DISABLE_Preming`来禁用抢占

    您是否更改了固件构建器中的任何源代码?

    P.S.将您的回答标记为“已解决“是意外的。 我已删除、但请忽略任何通知。  

    BR、
    Reese

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    是否修改了固件构建器中的任何源代码? 除了 vision_apps/platform/am62a/RTOS 中的存储器映射文件外、即  [/报价]

    我所做的唯一更改是我之前发布的修补程序。 我尝试用修补程序完成所有操作、每次都要重建构建环境。

    我担心、您为将 DDR_SHARED 和类似区域增加到 1GB DDR 以上而进行的自定义更改可能未由此处的脚本完全处理。 这不是一个典型的用例、恐怕我们在这里可能会遇到错误。

    我懂了。 我可以做些什么来解决这个问题吗? 如果我知道如何解决问题、那么手动修复就可以了。

    首先、我将 C7x 暂存区从 112MB 减少到 32MB、以保留分配给此闪存的 512MB。 这为我提供了额外的 80MB 的 DDR_SHARED_REGION、这将解决我当前的问题。

    如果我们能找到一种方法将其增加到超过 512 MB 的区域、这是理想的做法、那么我可以肯定、我不会干扰启用或禁用占先的 EdgeAI。

    此致、

    Bas Vermeulen

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

    我在这里似乎出错了;此迭代减少了 C7X 暂存区、增加了 DDR_SHARED 区域(但低于 0xC0000000)、也会以与其他迭代类似的方式崩溃。

    我当前复制的内容:

    tispl.bin 启动
    libtivision_apps.so.11.1.0 更改为/usr/lib
    vx_app_rtos_linux_c7x_1.out 更改为  /usr/lib/firmware/ti-ipc/am62axx/dsp_edgeai_c7x_1_release_strip.out

    是否还需要复制其他内容才能正常工作? 我正在使用释放 tisdk-edgeai 映像作为基址。

    此致、

    Bas Vermeulen

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

    我没有复制所有内容、这使事情失败了。 可能安全固件不存在(这是由 make linux_fs_staging 创建的,我当时还没有执行该操作)导致了问题。

    我现在复制了所有内容、这样就可以将 80MB 从 C7x 暂存存储器移动到 DMA_SHARED。

    所有一致性测试均适用 (vx_app_conformation.out、vx_app_conformation_core.out、vx_app_conformation_hwa.out 和 vx_app_conformation_tidl.out)。

    这应该可以解决我目前的问题,但如果我们可以检查我们如何能够使用超过 512 MB 的总,这仍然会帮助我很多。

    此致、

    Bas Vermeulen

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

    尊敬的 Bas:

    抱歉、未收到您的更新通知。  

    tispl.bin to boot
    [/报价]

    是的、这可能是不完整步骤的一部分。 tiboot3.bin 将包含固件构建器创建的 R5F 二进制文件 — 它在该 R5 内核上运行 ISP 和 TIOVX 组件。 存储器映射发生变化时、必须更新 tiboot3.bin。  

    我看到您比我能更快地了解到这部分内容!

    [引述 userid=“590891" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1614743/am62a7-q1-is-it-possible-to-increase-the-edgeai_shared_region/6237440

    这应该可以解决我目前的问题,但如果我们可以检查我们如何能够使用超过 512 MB 的总,这仍然会帮助我很多。

    [/报价]

    因此、如果在 shared_MEM 和堆超过 0xC000 0000 的情况下重复相同的过程、仍然没有生成功能构建?

    手动检查(全部来自 vision_apps/platform/am62a/RTOS)位于 c7x_1 和 mcu1_0 的两个目录中。 example.syscfg 文件 非常重要、后跟 am62_linker_freertos_mcuplus.cmd 文件。 有多个 linker.cmd 类型文件;请确保查看这个文件、但通常情况下。 在编译过程中还会创建一个“generated(生成)“目录、它将根据 SYSCFG 内容为器件移植层 (DPL) 生成 C 代码。  

    CMA 在 0xC000 0000 的主要用户是视频和 JPEG 编解码器、它们应该是内核模块 wave5 和 e5010_jpeg_enc

    [1] https://git.ti.com/cgit/processor-sdk/vision_apps/tree/platform/am62a/rtos/c7x_1/am62a_linker_freertos_mcuplus.cmd?h=main&id=d3bfc6217ad7983b132d2c891bb7aa1a86b53448 

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

    尊敬的 Reese Grimsley :

    除此之外、我还在 am62axx-EVM 上运行了修改后的固件。 但是、当我开始将其移至我们自己的硬件和软件(phytecs SDK + meta-edgeai;未修改的构建通过了一致性测试)时、情况就会破裂。

    我有:

    • 使用以下补丁修改了 gen_linker_mem_map.py:
      --- ti-firmware-builder-am62axx-evm-11_01_00_05/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py.orig     2026-02-18 08:55:14.459605828 +0000
      +++ ti-firmware-builder-am62axx-evm-11_01_00_05/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py  2026-02-18 08:55:58.263314319 +0000
      @@ -210,7 +210,7 @@
      
       # Shared memory for Buffers/ION allocator
       ddr_shared_mem_addr     = tiovx_log_rt_mem_addr + tiovx_log_rt_mem_size;
      -ddr_shared_mem_size     = 172*MB;
      +ddr_shared_mem_size     = 252*MB;
       carveout_size += ddr_shared_mem_size
      
       ddr_viss_config_heap_addr = ddr_shared_mem_addr + ddr_shared_mem_size;
      @@ -238,7 +238,7 @@
       carveout_size += c7x_1_ddr_local_heap_size
      
       c7x_1_ddr_scratch_addr     = c7x_1_ddr_local_heap_addr + c7x_1_ddr_local_heap_size;
      -c7x_1_ddr_scratch_size     = 112*MB;
      +c7x_1_ddr_scratch_size     = 32*MB;
       carveout_size += c7x_1_ddr_scratch_size
      
       assert carveout_size <= ddr_mem_size_2
    •  在 Yocto 中构建 ti-vision-apps 时、我还会使用此补丁修改 ti-vision-apps 中的 vision_apps。 这些是 gen_linker_mem_map.py 对 vision_apps 所做的更改。
      e2e.ti.com/.../1537.ti_2D00_vision_2D00_apps.patch.txt
    • 我使用脚本创建 Ubuntu 20.04 的 chroot 环境、并设置所有内容以正确构建固件:
      e2e.ti.com/.../3441.firmware_2D00_builder.sh.txt
    • 我已经修改了我的构建、以从 ti-bench firmware 中获取二进制文件、而不是从 ti-firmware/ti-dm-FW/ti-ipc-FW 中获取二进制文件。

    在尝试访问 VPAC 时、由于某种原因我看不到内核:

    e2e.ti.com/.../3441.vx_5F00_app_5F00_viss.log

    EVM 上也是如此。

    我已经确保保留存储器的器件树在 EVM 和我自己的版本之间是相同的。 我已经验证了固件文件(md5 和匹配)。 TI-sysfw 在两个编译之间也是相同的。

    是否知道接下来要检查什么?

    此致、

    Bas Vermeulen

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

    尊敬的 Bas:

    Reese 本周就要离开了。 请预计响应会有所延迟。

    此致、

    建中

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

    针对固件构建器的一些注释/问题:

    1. make 固件不会去除 C7x 固件。 这会导致在安装由 make 固件生成的固件时出现问题、因为它太大。 剥离由 linux_fs_stage 完成。 在制作固件时、这样做会很有帮助、可能会使未剥离和剥离的版本彼此相邻。
    2. 更改内存映射会修改内存映射 python 脚本中任何更改都不会触及的内存区域的 SysConfig MCU 值。 我目前正在研究这是否是我问题的原因。 查看我在上一篇文章中发布的 vision_apps 的差异。

    此致、

    Bas Vermeulen

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

    现在、我有一些功能可以正常工作:

    1. vx_app_mactivity_tidl.out 正在按预期运行。
    2. vx_app_conformance_core.out 也按预期运行。
    3. vx_app_conformance_hw.out 在 DM-R5 上使 sysfw 崩溃。

    这是通过固定的(不变的) vision_apps/platform/am62a/rtos/mcu1_0/example.syscfg 实现的。

    我正在尝试了解为什么 vx_app_security_hwa.out 会使 DM-R5 崩溃。

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

    vx_app_conformance_hw.out 在 VISS 测试上崩溃:

    [     DONE ] tivxHwaVpacMscPyramid.GraphProcessing_UYVY/0/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC1/VX_SCALE_PYRAMID_HALF                       [950/1906]
    [ RUN 0096 ] tivxHwaVpacMscPyramid.GraphProcessing_UYVY/1/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC2/VX_SCALE_PYRAMID_HALF ...
    [     DONE ] tivxHwaVpacMscPyramid.GraphProcessing_UYVY/1/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC2/VX_SCALE_PYRAMID_HALF
    [ RUN 0097 ] tivxHwaVpacMscPyramid.GraphProcessing_UYVY_input_Y_output/0/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC1/VX_SCALE_PYRAMID_HALF ...
    [     DONE ] tivxHwaVpacMscPyramid.GraphProcessing_UYVY_input_Y_output/0/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC1/VX_SCALE_PYRAMID_HALF
    [ RUN 0098 ] tivxHwaVpacMscPyramid.GraphProcessing_UYVY_input_Y_output/1/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC2/VX_SCALE_PYRAMID_HALF ...
    [     DONE ] tivxHwaVpacMscPyramid.GraphProcessing_UYVY_input_Y_output/1/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC2/VX_SCALE_PYRAMID_HALF
    [ RUN 0099 ] tivxHwaVpacMscPyramid.GraphProcessingChecksum_NV12/0/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC1/VX_SCALE_PYRAMID_HALF ...
    [     DONE ] tivxHwaVpacMscPyramid.GraphProcessingChecksum_NV12/0/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC1/VX_SCALE_PYRAMID_HALF
    [ RUN 0100 ] tivxHwaVpacMscPyramid.GraphProcessingChecksum_NV12/1/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC2/VX_SCALE_PYRAMID_HALF ...
    [     DONE ] tivxHwaVpacMscPyramid.GraphProcessingChecksum_NV12/1/checksum/VX_BORDER_UNDEFINED/TIVX_TARGET_VPAC_MSC2/VX_SCALE_PYRAMID_HALF
    [ -------- ] 100 tests from test case tivxHwaVpacMscPyramid
    
    [ -------- ] tests from tivxHwaVpacViss
    [ RUN 0001 ] tivxHwaVpacViss.NodeCreation/0/target/TIVX_TARGET_VPAC_VISS1 ...
    [     DONE ] tivxHwaVpacViss.NodeCreation/0/target/TIVX_TARGET_VPAC_VISS1
    [ RUN 0002 ] tivxHwaVpacViss.GraphProcessingFile/0/target/TIVX_TARGET_VPAC_VISS1 ...
    [ 2987.033145] ti-sci 44043000.system-controller: Mbox timedout in resp(caller: sci_clk_set_rate+0x48/0x54)
    [ 2987.042691] ti-sci 44043000.system-controller: Mbox send fail -110
    [ 2988.025130] ti-sci 44043000.system-controller: Mbox timedout in resp(caller: ti_sci_cmd_put_device+0x18/0x24)
    [ 2988.035097] ti-sci 44043000.system-controller: Mbox send fail -110
    [ 2988.057124] ti-sci 44043000.system-controller: Mbox timedout in resp(caller: sci_clk_recalc_rate+0x4c/0xac)
    [ 2988.066898] ti-sci 44043000.system-controller: Mbox send fail -110

    继续我的调查,看看哪里出了问题。

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

    当我调用 vx_app_viss.out 0 5(它设置了东西,但没有调用 vxProcessGraph ()) 时,这个问题不会发生。 当我调用 vx_app_viss.out 1 5(或除 0 之外的任何内容)时、将调用 vxProcessGraph 且 DM R5 崩溃。

    我还将固件构建在 am62axx-EVM 上、一切都正常;我们的定制电路板使用 phytecs SOM、并具有 2GB RAM 而不是 4GB、但这不会有任何影响。 ti-sysfw、ti-dm 和 ti-ipc 固件都相同、我还尝试使用固件构建器 libtivision_apps.so.11.1.0。

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

    尊敬的 Bas:

    感谢您的更新。 很遗憾、我们必须等待 Reese 下周回来继续提供支持。

    此致、

    建中

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

    尊敬的 Bas:

    同时、您是否会检查可正常工作的 EVM 和故障定制电路板的 mcu1_0 初始化日志?

    root@am62axx-EVM:/opt/vision_apps ./vx_app_arm_remote_log.out  

    这应该会告诉我们是否正确创建了 TIOVX 节点、也会告诉我们电路板之间初始化的差异。  

    此致、

    Qutaiba

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

    尊敬  的 Qutaiba Saleh  , Reese Grimsley ,

    首先、我知道 Reese 本周不在。 我现在不希望收到回复、只是用我的发现更新主题。

    我现在有一个正常运行的固件、所有一致性测试均按预期成功。

    除了我之前一篇回复中的要点外、 gen_linker_mem_map.py 还没有更改 mcu1_0/example.syscfg 中的 DDR_DM_R5F_VISS_CONFIG_HEAP 的基地址。 修改 mcu1_0/example.syscfg 以考虑到这一点并删除应用的不必要的脚本更改后、事情将按预期开始运行。

    步骤如下:

    1. 根据 ti-firmware-builder-am62axx-evm-11_01_00_05-docs_only/psdk_rtos/docs/user_guide/Getting Started_am62a.html#Understanding-and-updating-the-memory-map 中的过程运行 gen_linker_mem_map.py
    2. 恢复 mcu1_0/example.sysconfig 中低于 0xA0000000 的存储器区域大小的额外更改
    3. 更改存储器区域后、检查 mcu1_0/example.syscfg 中的所有存储器区域、以确保基地址和大小正确。
    4. 根据入门过程构建固件。

    最好修改固件构建器 gen_linker_mem_map.py 脚本以自动执行此操作。 这将节省人们使用它很多时间和头痛Slight smile

    此致、

    Bas Vermeulen

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

    嘿、Bas、

    哇、你在上周有效了。

    DDR_DM_R5F_VISS_CONFIG_HEAP  将是我要研究的结果、但您自己找到了。 我们在 11.1 SDK 版本中添加了这一点、看起来我们错过了负责更新此更新的代码块。 我会在这里跟进、将来避免出现这种情况。  

    你留下了真正有用的面包屑给下一个人跑进这个。 我希望所有的门票都有这样好的更新,就像在这个线程,所以让我真诚地感谢你!

    我现在关闭该线程

    编辑以供将来查看者使用 :这已经在上游 vision_apps 中修正,在这里提交[1]。 通过“REL.psdk.analysis.AM62A.11.02.00.1"标签“标签、可以修复该问题(在修复了另一个相关问题后)。 但是、此提交不在 11.1 固件构建器中。 我建议未来的观看者在我提到的标签处克隆 vision_apps 存储库、并以此方式替换 vision_apps(或者至少替换 platform/am62a/RTOS 目录及其子目录)

    [1] https://git.ti.com/cgit/processor-sdk/vision_apps/commit/platform/am62a/rtos/gen_mcu1_0_syscfg.py?h=main&id=56c90e83407a016f2286d1ec7083bd60e19087e5 

    BR、
    Reese

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

    尊敬的 Reese Grimsley :

    是否也可以让固件去除构建的映像? Yocto 方法可以对它们签名而不会出现问题、但无法去除二进制文件。 它目前仅在 make install_fs_stage 中完成。 在 make 固件中执行该操作意味着可以直接使用 make 固件的结果。

    不是很重要、但在不构建完整的 SDK 时、这是我所理解的情况。 应该是一个相对容易的生活质量提高。

    此致、

    Bas Vermeulen