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:1GB DDR 的保留存储器映射变化

Guru**** 2885260 points

Other Parts Discussed in Thread: AM62A7

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr

器件型号: AM62A7

我们将 SDK-11.01.00 用于基于 AM62A7 处理器的电路板。 我们的电路板具有 1GB 的 DDR。 因此、我们知道我们必须更改电路板的保留存储器映射、因为它具有 1GB DDR、而不是 4GB DDR。

我们按照固件生成器 SDK 中的说明进行了保留存储器映射更改。 下面是我们更改的存储器映射的屏幕截图。

固件构建程序 SDK 中的 vision_apps/platform/am62a/rtos/gen_linker_mem_map.py 文件更改

diff --git a/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py b/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py
index 2b00d6220..a1ee9e135 100755
--- a/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py
+++ b/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py
@@ -218,27 +218,27 @@ ddr_viss_config_heap_size = 4*MB;
 carveout_size += ddr_viss_config_heap_size

 mcu_r5f_ddr_local_heap_addr  = ddr_viss_config_heap_addr + ddr_viss_config_heap_size;
-mcu_r5f_ddr_local_heap_size  = 16*MB;
+mcu_r5f_ddr_local_heap_size  = 4*MB;
 carveout_size += mcu_r5f_ddr_local_heap_size

 dm_r5f_ddr_local_heap_addr  = mcu_r5f_ddr_local_heap_addr + mcu_r5f_ddr_local_heap_size;
-dm_r5f_ddr_local_heap_size  = 16*MB;
+dm_r5f_ddr_local_heap_size  = 4*MB;
 carveout_size += dm_r5f_ddr_local_heap_size

 c7x_1_ddr_local_heap_non_cacheable_addr  = dm_r5f_ddr_local_heap_addr + dm_r5f_ddr_local_heap_size;
-c7x_1_ddr_local_heap_non_cacheable_size  = 16*MB;
+c7x_1_ddr_local_heap_non_cacheable_size  = 4*MB;
 carveout_size += c7x_1_ddr_local_heap_non_cacheable_size

 c7x_1_ddr_scratch_non_cacheable_addr     = c7x_1_ddr_local_heap_non_cacheable_addr + c7x_1_ddr_local_heap_non_cacheable_size;
-c7x_1_ddr_scratch_non_cacheable_size     = 16*MB;
+c7x_1_ddr_scratch_non_cacheable_size     = 4*MB;
 carveout_size += c7x_1_ddr_scratch_non_cacheable_size

 c7x_1_ddr_local_heap_addr  = c7x_1_ddr_scratch_non_cacheable_addr + c7x_1_ddr_scratch_non_cacheable_size;
-c7x_1_ddr_local_heap_size  = 112*MB;
+c7x_1_ddr_local_heap_size  = 28*MB;
 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     = 28*MB;
 carveout_size += c7x_1_ddr_scratch_size

 assert carveout_size <= ddr_mem_size_2

arch/arm64/boot/dts/ti/k3-am62a7-sk-edgeai.dtso 内核器件树文件更改

// SPDX-License-Identifier: GPL-2.0
/*
 * DT overlay for AM62A edgeAI carveouts
 * Copyright (C) 2023-2025 Texas Instruments Incorporated - https://www.ti.com/
 */

/dts-v1/;
/plugin/;

&{/reserved-memory} {
        #address-cells = <2>;
        #size-cells = <2>;
        ranges;

        edgeai_memory_region: edgeai-dma-memory@a1000000 {
                compatible = "shared-dma-pool";
                reg = <0x00 0xa1000000 0x00 0x02000000>;
                no-map;
        };

        edgeai_shared_region: edgeai_shared-memories {
                compatible = "dma-heap-carveout";
                reg = <0x00 0xa3000000 0x00 0x0ac00000>;
        };

        edgeai_core_heaps: edgeai-core-heap-memory@adc00000 {
                compatible = "shared-dma-pool";
                reg = <0x00 0xadc00000 0x00 0x4c00000>;
                no-map;
        };
};

注意:在 DTS 上方仅“edgeai_core_watches“节点发生变化。  

此外、我们仅将 CMA 内存保留为 200MB。 根据我的理解、无需对 CMA 存储器进行固件生成器 SDK 更改。  

更改存储器映射后、我们遵循了固件构建器文档中提到的所有步骤、并生成了 vx_app_rtos_linux_mcu1_0_strip.out(DMR5 固件)和 vx_app_rtos_linux_c7x_1.out(c7x 固件)。 此外、我们还使用了 vx_app_rtos_linux_mcu1_0_strip.out(DMR5 固件)固件来生成 tispl.bin 二进制文件。

完成所有更改后、我们使用新的 tispl.bin(用于生成 tispl.bin 的新 vx_app_rtos_linux_mcu1_0_strip.out(DMR5 固件)和 vx_app_rtos_linux_c7x_1.out(c7x 固件)引导了电路板。

之后、我们运行“TIOVX 一致性测试“以验证存储器相关更改是否正确完成。 我们使用 psdk_rtos_ti_data_set_11_01_00.tar.gz 和 psdk_rtos_ti_data_set_11_01_00_am62a.tar.gz 数据集进行了固件构建器文档中提到的一致性测试。 但我们设备上的一致性测试失败(提供分段故障)。 以下是符合性测试的最后日志。

TIOVX-Conformance-Test-1GB-DDR-Result.txt 

但“TIDL 符合性测试“ 也在我们的电路板上进行。

“TIOVX 一致性测试“可能有什么问题? 请告知我们需要提供的任何其他信息。

 

此致、

Jay

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

    尊敬的 Jay:

    您通过的日志中的一些测试是“负面测试“。 这些应该失败并抛出 Vx_zone_error 消息(就像 FYI 一样)

    但是、这并不适用于这里的所有场景。 我看到了一些类似的消息  

    [ RUN 0001 ] tivxRemap.GraphProcessing/0/random/sz=18x18/VX_BORDER_CONSTANT=1/VX_INTERPOLATION_NEAREST_NEIGHBOR/VX_MAP_RANDOM ...
     15397.375429 s: MEM: ERROR: /dev/remoteproc0 open failed !!!
     15397.375655 s: MEM: ERROR: memory alloc of size = 256 bytes, failed with status = -1 !!!
     15397.375803 s: DDR_SHARED_MEM: Alloc's: 160767 alloc's of 14277472894 bytes
     15397.375887 s: DDR_SHARED_MEM: Free's : 160261 free's  of 14277143758 bytes
     15397.375959 s: DDR_SHARED_MEM: Open's : 506 allocs  of 329136 bytes
     15397.376041 s: MEM: ERROR: Failed to translate dmaBufFd [1023]

    这不是预期的错误类型 — 负值测试应该失败,因为给出了无效参数,而不是导致 IPC 机制失败。  

    您能告诉您系统中的哪个内核是/dev/remoteproc0 吗? Remoteproc #不一致。 请共享`cat /sys/class/remoteproc/remoteproc0/name`和 `cat /sys/class/remoteproc/remoteproc0/state`的输出。 我预计 DM R5 的状态是 78000000.r5f、并且应该将状态显示为“Attached“。

    您正在运行哪组一致性测试? 单数 vx_app_security.out 也将涵盖_core、_hwa 和_tidl 中的所有测试。 我通常建议一开始只进行“_core“测试。 测试是核心的一部分

    此外、我们还使用了 vx_app_rtos_linux_mcu1_0_strip.out(DMR5 固件)固件来生成 tispl.bin 二进制文件。

    R5F 二进制文件由 tiboot3.bin 传递。 您是否更新了此组件? 这可能是根本问题。 我认为 tispl.bin 不需要更新内存映射。  

    我对`/opt/vision_apps/vx_app_arm_ipc.out`和`/opt/vision_apps/vx_app_arm_mem.out`等命令的输出很好奇

    如果问题仍然存在、请同时共享您的引导日志和`/opt/vision_apps/vision_apps_init.sh`的输出(启动后不久)。 我建议先进行下电上电、以便清除环缓冲区中包含 TIOVX 日志的 DDR 区域(否则,该记录器将转储来自最后一个引导/运行时应用的一些消息)

    BR、
    Reese

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

    尊敬的 Reese:

    请在下面查找您的问题的答案:

    您能告诉您系统中哪个内核是/dev/remoteproc0 吗?

    有关所有 Remoteproc 名称和状态信息、请查看以下命令输出。 它显示了 remoteproc0 处的 79000000.r5f。

    ~ # cat /sys/class/remoteproc/remoteproc0/name
    79000000.r5f
    ~ # cat /sys/class/remoteproc/remoteproc0/state
    running
    ~ # cat /sys/class/remoteproc/remoteproc1/name
    7e000000.dsp
    ~ # cat /sys/class/remoteproc/remoteproc1/state
    running
    ~ # cat /sys/class/remoteproc/remoteproc2/name
    78000000.r5f
    ~ # cat /sys/class/remoteproc/remoteproc2/state
    attached

    您正在运行哪组一致性测试?

    我们使用“./vx_app_conformat_core.out“命令在器件上运行特定于内核的一致性测试。 请查找随附的 vx_app_conformance_core.log 文件以获取完整的日志信息。

    R5F 二进制文件由 tiboot3.bin 携带。 您是否更新了此组件?

    是的、我们还更新了在替换 Yocto 构建系统中 提供的固件构建器“dm_edgeai_mcu1_0_release_strip.out“后、会在 Yocto 构建系统上生成的 tiboot3.bin 文件、但问题仍然存在。

    还请共享您的引导日志和`/opt/vision_apps/vision_apps_init.sh`
    的输出(启动后不久)。

    请查找随附的 boot.log 文件和 vision_apps_init.log、它们是在器件下电上电后生成的。

    谢谢、

    Jay

    e2e.ti.com/.../4540.boot.loge2e.ti.com/.../3750.vision_5F00_apps_5F00_init.loge2e.ti.com/.../vx_5F00_app_5F00_arm_5F00_ipc.loge2e.ti.com/.../vx_5F00_app_5F00_arm_5F00_mem.loge2e.ti.com/.../vx_5F00_app_5F00_conformance_5F00_core.log

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

    尊敬的 Jay:  

    感谢您分享这些内容并确认 DM R5 固件不是问题。  

    让我记下到目前为止在共享日志中看到的内容。  

    IPC 和 MEM 日志正常。 IPC 运行良好、A53 在 DDR_SHARED_MEM 中的存储器分配工作。  


    1) 您的 DTSO(在上面共享)与引导日志之间存在差异

    引导时、我会看到以下关键行:  

    [    0.000000] OF: reserved mem: failed to allocate memory for node 'linux,cma': size 200 MiB
    ...
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000adc00000, size 148 MiB
    [    0.000000] OF: reserved mem: initialized node edgeai-core-heap-memory@adc00000, compatible id shared-dma-pool
    [    0.000000] OF: reserved mem: 0x00000000adc00000..0x00000000b6ffffff (151552 KiB) nomap non-reusable edgeai-core-heap-memory@adc00000
    

    CMA 未能分配所需的大小。 我认为这不是有意的、可能与它下面的线条有关。  

    在您的 DTS 中、  

    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr edgeai_core_堆:edgeai-core-heap-memory@adc00000{ compatible =“shared-dma-pool“; REG =<0x00 0xadc00000 0x00 0x4c00000>;[/quot]

    这需要 76 MB 的请求。 这与您编辑的 HTML 屏幕截图保持一致 — 包括 VISS_CONFIG_HEAP、所有堆总共为 76 MB。  

    在日志中、它请求 148 MB。

    我会注意到 DTSO 和引导日志之间的其他区域(我认为您没有接触到)匹配。  

    我们来仔细检查设置/更新这些区域的 DTS/ DTSO。 我们通常传递包含这些区域的.dtbo(过去,这些区域是.dts 主目录的一部分、但我们在 11.1 SDK 中对此进行了更改)。 DTSO 变为 BOOTFS/dtb/ti/k3-am62a7-sk-edgeai.dtbo。 我们的区域要大得多、因此我认为您不会意外使用默认设置。  


    2) 发热板显示出意想不到的尺寸

    在 vision_apps_init.sh 日志输出中、我们可以看到来自远程内核的启动序列。 我会在几行中磨练。 使用 MCU1_0 表示 DM r5(也称为 78000000.r5f)和 C7x_1 均为 7e000000.dsp 器件。 另一个 MCU 内核 (79000000.r5f) 在这里没有发挥特定作用(那么,remoteproc0 为什么会出现错误? 我猜这是副作用)

    我希望你的 system_memory_map.html 有信心,但我的意见:  

    [MCU1_0] 0.037351 s: MEM: Created heap (DDR_LOCAL_MEM, id=0, flags=0x00000004) @ ae800000 of size 8388608 bytes !!!
    [MCU1_0] 0.037411 s: MEM: Created heap (DDR_CACHE_WT_ME, id=7, flags=0x00000000) @ adc00000 of size 4194304 bytes !!!
    ...
    [C7x_1 ] 7.936926 s: MEM: Created heap (DDR_LOCAL_MEM, id=0, flags=0x00000004) @ b0000000 of size 58720256 bytes !!!

    这里有很多奇怪的地方
    • 0xadc0 0000 是 VISS_CONFIG_HEAP。 这看起来是正确的。  
    • 0xae80 0000 不对应于 MCU1_0 上地图的某个区域、也不应是 8MB。 如果是 4MB、则它应该从 0xae40 0000 开始、因为前面的 DDR_MCU_R5F_LOCAL_HEAP 区域也应该是 4MB
    • 0xb000 0000 注册为 DDR_C7X_1_LOCAL_HEAP 的起始地址、我认为该地址是正确的(此处未显示非高速缓存堆)。 但是、大小显示为 56 MB、这也不正确
    SDK 中的等效日志如下所示:  
    [MCU1_0]   2756.426844 s: MEM: Created heap (DDR_LOCAL_MEM, id=0, flags=0x00000004) @ af000000 of size 16777216 bytes !!!
    [MCU1_0]   2756.426901 s: MEM: Created heap (DDR_CACHE_WT_ME, id=7, flags=0x00000000) @ adc00000 of size 4194304 bytes !!!
    ...
    [C7x_1 ]   2770.123317 s: MEM: Created heap (DDR_LOCAL_MEM, id=0, flags=0x00000004) @ b2000000 of size 117440512 bytes !!!

    从此处前往:  
    1. 确认 已在您的构建中正确应用包含这些存储器区域的 DTS/DTSO、因为日志与您显示的 DTS 代码不匹配
    2. 导致堆与您的配置不匹配的根本原因
      1. 我们还使用`/opt/vision_apps/vx_app_heap_stats.out 实用程序`来监视堆--它将显示所有堆的大小和利用率。 请共享输出。 如果问题持续存在、我们可以考虑在运行一致性测试时对此进行监控
        1. 请注意、这没有显示 DDR_SHARED_MEM Utilization --为此运行`cat /sys/kernel/debug/dma_buf/bufinfo`--尽管我怀疑这个区域是您的问题
    3. 如果上述内容不够、我们将查看 SYSCFG 文件和“生成的“代码、以确认 C7_1 和 mcu1_0 镜像您在 python 脚本中设置的区域大小。  

    我仍然认为这里提到 remoteproc0(基于该内核的“名称“、它不是贡献的 MCU 内核)很奇怪。 我希望一些缓冲区正在被分配但未被释放、并且开放的 DMA-FD 的数量不断增加、直到达到某个软限制(dmaBufFd [1023]表明这一点)。 您可以使用--filter arg 来设置要运行的测试、如果我在这里是正确的、那么它是关于  失败前将运行的测试的数量、与特定测试失败相比。  

    我可能还会要求您共享 vision_apps/platform/am62a/rtos 目录 、以便看到“生成的“代码、尤其是 generated /ti_DPL_config.c我过去看到了一个错误、在该错误中、Python 脚本中更新了一个区域、但一些下游文件没有正确更新。 gen_linker_mem_map.py 应修改子目录中的 example.syscfg 文件、这些 SYSCFG 文件将用于生成 DPL C 代码、然后是固件。  

    BR、
    Reese

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

    尊敬的 Reese:  

    感谢您的答复。

    确认 在您的构建中正确应用了包含这些内存区域的 DTS/DTSO、因为日志与您显示的 DTS 代码不匹配

    我们更正了保留存储器映射。 请检查随附的启动日志。 如 DTS/DTSO 文件中所述、“Linux,CMA“被分配 200MB、“所有堆总和“被分配 76MB。

    我们还使用`/opt/vision_apps/vx_app_heap_stats.out 实用程序来监视堆`--它将显示所有堆的大小和利用率。 请共享输出。 如果问题持续存在、我们可以考虑在运行一致性测试时对此进行监控
    1. 请注意、这没有显示 DDR_SHARED_MEM Utilization --为此运行`cat /sys/kernel/debug/dma_buf/bufinfo`--尽管我怀疑这个区域是您的问题
    [/报价]

     当一致性测试正在运行时、我/opt/vision_apps/vx_app_heap_stats.out 每 5 秒执行一次“cat utility“和“cat /sys/kernel/debug/dma_buf/bufinfo 命令。 请参阅随附的“heap_usage_logs.txt“文件。

    我也可以要求您共享 vision_apps/platform/am62a/RTOS 目录 、以便看到“生成的“代码、特别是 generated /ti_DPL_config.c

    我随附了 vision_apps/platform/am62a/RTOS 目录的 tar 文件以供您参考。

    您可以使用--filter arg 来设置要运行的测试、如果这里是正确的、则说明  在失败前将运行的测试数量、与特定测试失败相比。

    --有过滤器选项。 您能否为我们提供有关如何运行特定数量的测试的更多信息。 因此、我们也可以检查该选项。

    请告知我们是否需要任何其他信息。

    以下是日志文件:
    启动日志:

    e2e.ti.com/.../bootup_2D00_log.txt

    vision_apps_init.sh 日志

    e2e.ti.com/.../2804.vision_5F00_apps_5F00_init_5F00_logs.txt

    vx_app_arm_ipc.out 日志

    e2e.ti.com/.../vx_5F00_app_5F00_arm_5F00_ipc_5F00_logs.txt

    vx_app_arm_mem.out 日志

    e2e.ti.com/.../vx_5F00_app_5F00_arm_5F00_mem_5F00_logs.txt

    vx_app_conformance_core.out 日志

    e2e.ti.com/.../vx_5F00_app_5F00_conformance_5F00_core_2D00_1.txt

    堆监视日志

    e2e.ti.com/.../heap_5F00_usage_5F00_logs.txt

    执行“vision_apps/platform/am62a/platform/am62a/rtos/gen_linker_mem_map.py“脚本后的 vision_apps/platform/am62a/RTOS 方向源。

    e2e.ti.com/.../rtos.tar.gz

    我们将 edgeai 的以下封装用于我们的板。 如果除了这些软件包之外、我们还需要使用任何其他软件包、请告知我们。

        ti-vision-apps-dev \
        edgeai-tiovx-kernels-dev \
        edgeai-apps-utils-source \
        edgeai-tiovx-apps-dev \
        edgeai-tiovx-apps-source \
        edgeai-tiovx-modules-dev \
        edgeai-gst-plugins-dev \
        edgeai-dl-inferer-staticdev \
        ti-rpmsg-char \
        ti-vision-apps-dev \
        ti-tidl-dev \
        ti-tidl-osrt \
        ti-rtos-echo-test-fw \
        cnm-wave-fw \
        edgeai-tiovx-apps \
        edgeai-dl-inferer \
        edgeai-gst-plugins \
        edgeai-tiovx-kernels \
        edgeai-tiovx-modules \
        edgeai-apps-utils \

    此致、

    Jay

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

    尊敬的 Jay:  

    再次感谢您通过所有这些测试。  

    • Linux 的引导日志看起来与您的区域分割成正比
    • TIOVX 设置日志显示了预期的堆区域。 MCU1_0 上的 2 个 4MB 区域、C7x_1 上的 1 个 28MB 区域
      • vx_app_heap_stats.out 中显示的堆的大小也正确(TIOVX 输出日志中未显示某些堆,但此实用程序会显示所有堆)。 它们看起来也是正确的
    • IPC、基本存储器分配实用程序会显示预期结果

    因此、看起来堆都已配置完毕、并更新远程内核以使用这些堆。

    但问题依然存在。 实际上、现在的问题要低一些  

    [ RUN 0002 ] tivxPyramidNode.IntermediateNodeCreation/1/streaming/TIVX_TARGET_MCU1_0 ...
    83357.975898 s: VX_ZONE_ERROR: [ownTargetKernelInstanceAlloc:149] kernel com.ti.test_kernels.pyramid_intermediate has not been registered on this CPU
    83357.975908 s: VX_ZONE_ERROR: [ownTargetKernelInstanceAlloc:150] Please register this kernel on the appropriate target core
    83357.975914 s: VX_ZONE_ERROR: [ownTargetNodeDescNodeCreate:970] target_kernel_instance is NULL
    83357.975950 s: VX_ZONE_ERROR: [ownContextSendCmd:1001] Command ack message returned failure cmd_status: -7
    83357.975958 s: VX_ZONE_ERROR: [ownNodeKernelInit:704] Target kernel, TIVX_CMD_NODE_CREATE failed for node node_103
    83357.975963 s: VX_ZONE_ERROR: [ownNodeKernelInit:705] Please be sure the target callbacks have been registered for this core
    83357.975968 s: VX_ZONE_ERROR: [ownNodeKernelInit:706] If the target callbacks have been registered, please ensure no errors are occurring within the create callback of this kernel
    83357.975975 s: VX_ZONE_ERROR: [ownGraphNodeKernelInit:793] kernel init for node 0, kernel com.ti.test_kernels.pyramid_intermediate ... failed !!!
    83357.975987 s: VX_ZONE_ERROR: [ graph_92 ] Node kernel init failed
    83357.975991 s: VX_ZONE_ERROR: [ graph_92 ] Graph verify failed

    此外、remoteproc0 是否真的是位于 0x79000000 的 MCU R5F? bufinfo 日志表明缓冲区已连接到此 remoteproc0、但我想知道这是否只是硬编码。 在我这边、我运行一个示例应用、所有缓冲区都附加到 remoteproc0(当我读取 remoteproc0/name 时、C7 0x7e0000000.dsp)。 我认为我们默认/dev/remoteproc0 访问某些共享数据区域、无论该内核是否用于处理、因此这可能不是一个重要的细节。   


    --filter option where. 您能否为我们提供有关如何运行特定数量的测试的更多信息。 因此、我们也可以检查该选项。
    [/报价]

    是、--filter [1]接受通配符 (*) 来选择要运行的测试、例如

    [ RUN 0001 ] tivxPyramidNode.IntermediateNodeCreation/0/streaming/TIVX_TARGET_MPU_0 ...
    [     DONE ] tivxPyramidNode.IntermediateNodeCreation/0/streaming/TIVX_TARGET_MPU_0
    [ RUN 0002 ] tivxPyramidNode.IntermediateNodeCreation/1/streaming/TIVX_TARGET_MCU1_0 ...

    您只能使用`./vx_app_conformance_test_core.out --filter=“tivxPyramidNode*“`运行 PyramidNode 测试

    同样、您只能使用 `./vx_app_conformance_test_core.out --filter=“*TIVx_target_MCU1_0“`目标 MCU1_0

    或使用  `./vx_app_conformance_test_core.out --filter=“*stream*“`进行“流式“测试

    这同样适用于其他 vx_app_Factivity 应用


    回到原始问题。  

    我查看了您的 RTOS 目录(感谢其中包含)、很遗憾我没有看到您的系统无法通过这些一致性测试的明确原因。  您现在看到的问题类型使我认为有一些更基本的方面在发挥作用、例如主 TIOVX 区域 (TIOVXobj_DESC_MEM、IPC_VRing_MEM )... 但这些甚至不会被你们的改变所触动。  

    我现在正在抓紧一些。。。 您是否使用构建的输出更新了一致性测试或/opt/vision_apps 目录? 我不认为这些都依赖于内存映射、但我在这个阶段已经放弃了假设。   

    可能有必要恢复您的一些更改、尤其是对于 MCU 内核堆、并在我们确定问题时获得功能性(但不是最优)存储器映射。 C7 堆可能仍会减少、但最好完全恢复并进行流量冲洗

    无需其他软件包、BTW。 TIOVX 一致性测试具有相对较少的依赖性----主要是远程内核固件和/usr/lib/libtivision_apps.so

    ReFS:

    [1] https://github.com/TexasInstruments/tiovx/blob/main/CONTRIBUTING.MD#test-application 

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

    尊敬的 Reese:  

    感谢您确认更改后的存储器区域现在已正确反映。

    另外、remoteproc0 是否真正是位于 0x79000000 的 MCU R5F?

    remoteproc0 是电路板的 DSP 内核。  远程处理 1 用于 Cortex-R5F。 请检查电路板上的以下日志:

    ~ # cat /sys/class/remoteproc/remoteproc0/name
    7e000000.dsp
    ~ # cat /sys/class/remoteproc/remoteproc0/state
    running
    ~ # cat /sys/class/remoteproc/remoteproc1/name
    79000000.r5f
    ~ # cat /sys/class/remoteproc/remoteproc1/state
    running
    ~ # cat /sys/class/remoteproc/remoteproc2/name
    78000000.r5f
    ~ # cat /sys/class/remoteproc/remoteproc2/state
    attached

    我们还需要在这里确认一点。 我们使用SDK-09.02.00 中的“ti-tidl-osrt“软件包、因为 SDK-11.01.00 中的“ti-tidl-osrt“与 Yocto 的 glibc 软件包版本兼容。 这可能是问题吗?

    ti-tidl-osrt 子组件的源 URL:

    software-dl.ti.com/.../dlr-1.13.0-py3-none-any.whl;name=dlr;
    software-dl.ti.com/.../tflite_runtime-2.12.0-cp310-cp310-linux_aarch64.whl;name=tflite;
    software-dl.ti.com/.../onnxruntime_tidl-1.14.0-cp310-cp310-linux_aarch64.whl;name=ort;
    software-dl.ti.com/.../tflite_2.12_aragoj7.tar.gz;name=tfl_lib;
    software-dl.ti.com/.../onnx_1.14.0_aragoj7.tar.gz;name=ort_lib;
    https://software-dl.ti.com/jacinto7/esd/tidl-tools/09_02_00_00/OSRT_TOOLS/ARM_LINUX/ARAGO/opencv_4.2.0_aragoj7.tar.gz;name=opencv;

    如果需要、请从我们这边告知我们。

    此致、

    Jay

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

    尊敬的 Jay:

    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6319200

    我们还需要在这里确认一点。 我们使用SDK-09.02.00 中的“ti-tidl-osrt“软件包、因为 SDK-11.01.00 中的“ti-tidl-osrt“与 Yocto 的 glibc 软件包版本兼容。 这可能是问题吗?

    ti-tidl-osrt 子组件的源 URL:

    software-dl.ti.com/.../dlr-1.13.0-py3-none-any.whl;name=dlr;
    software-dl.ti.com/.../tflite_runtime-2.12.0-cp310-cp310-linux_aarch64.whl;name=tflite;
    software-dl.ti.com/.../onnxruntime_tidl-1.14.0-cp310-cp310-linux_aarch64.whl;name=ort;
    software-dl.ti.com/.../tflite_2.12_aragoj7.tar.gz;name=tfl_lib;
    software-dl.ti.com/.../onnx_1.14.0_aragoj7.tar.gz;name=ort_lib;
    https://software-dl.ti.com/jacinto7/esd/tidl-tools/09_02_00_00/OSRT_TOOLS/ARM_LINUX/ARAGO/opencv_4.2.0_aragoj7.tar.gz;name=opencv;

    [/报价]

    这稍后很重要、但并不是 TIOVX 一致性测试的一个因素。 即使是/opt/vision_apps 中的 TIDL 一致性测试也不依赖于这些封装。 这些软件包不应对我们今天关注的测试产生任何影响。  

    使用更高级别的抽象(即 ONNXRuntime、TFLite 等运行时)将依赖于这些软件包。

    感谢您确认现在已更改的存储器区域得到了正确反映。
    [/报价]

    是的、但仍有一些问题、使得内核显示为“未注册“、即使 TIOVX 日志显示为何时注册。 我`m您执行全新的编译 (`make SDK_scrub`然后` ake SDK)。  

    • 理想情况下、在 gen_linker_mem_map.py 之后执行此操作、并修改 use16MB 最小内核堆(恢复该更改)、以便我们可以流式刷新。 可以减少大型 C7x 堆
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    仅供参考、这里是另一个使用 1 GB 内存映射的用户的线程。 我们简化了一些步骤并实施了一些 bug 修复、但一般方法是相同的:  

     AM62A7:有关边缘 AI 演示应用程序的查询 

    检查 vision_apps/out/AM62A/R5F/freertos/release/vx_app_rtos_linux_mcu1_0.out.map 可能值得  、包括 g_target_kernel_table(您看到的错误可能是因为未填充此表,或者互斥量无法从 tiovx/source/framework/vx_target_kernel.c 获取)。  应在 DDR_DM_R5 区域中

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

    尊敬的 Reese:

    感谢您的答复。

    [报价 userid=“360457“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6319296

    是的、但仍有一些问题、使得内核显示为“未注册“、即使 TIOVX 日志显示为何时注册。 我`m您执行全新的编译 (`make SDK_scrub`然后` ake SDK)。  

    • 理想情况下、在 gen_linker_mem_map.py 之后执行此操作、并修改 use16MB 最小内核堆(恢复该更改)、以便我们可以流式刷新。 可以减少大型 C7x 堆
    [/报价]

    正如您所建议的、我保留了最小内核堆大小为 16MB、并且只减少了大型 C7X 堆。 以下是“gen_linker_mem_map.py“文件的变更:

    diff --git a/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py b/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py
    index 2b00d6220..3bdf5e482 100755
    --- a/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py
    +++ b/vision_apps/platform/am62a/rtos/gen_linker_mem_map.py
    @@ -234,11 +234,11 @@ c7x_1_ddr_scratch_non_cacheable_size     = 16*MB;
     carveout_size += c7x_1_ddr_scratch_non_cacheable_size
    
     c7x_1_ddr_local_heap_addr  = c7x_1_ddr_scratch_non_cacheable_addr + c7x_1_ddr_scratch_non_cacheable_size;
    -c7x_1_ddr_local_heap_size  = 112*MB;
    +c7x_1_ddr_local_heap_size  = 56*MB;
     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     = 56*MB;
     carveout_size += c7x_1_ddr_scratch_size
    
     assert carveout_size <= ddr_mem_size_2

    在执行“gen_linker_mem_map.py“脚本后、我执行了命令“makesdk_scrub“、然后执行您提到的“make sdk -j 5“。 但我们仍然在观察到分段故障问题。 以下是所需的日志:

    e2e.ti.com/.../bootup_2D00_logs.txt

    e2e.ti.com/.../vision_5F00_apps_5F00_init_2D00_logs.txt

    e2e.ti.com/.../vx_5F00_app_5F00_arm_5F00_ipc_2D00_logs.txt

    e2e.ti.com/.../vx_5F00_app_5F00_arm_5F00_mem_2D00_logs.txt

    e2e.ti.com/.../vx_5F00_app_5F00_heap_5F00_stats_2D00_utility_2D00_logs.txt

    e2e.ti.com/.../0841.vx_5F00_app_5F00_conformance_5F00_core.log


    remoteproc0 仍是 DSP 内核。

    /opt/vision_apps # cat /sys/class/remoteproc/remoteproc0/name
    7e000000.dsp
    /opt/vision_apps # cat /sys/class/remoteproc/remoteproc0/state
    running
     

    此致、

    Jay

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

    尊敬的 Jay:  

    我不确定导致此问题的原因。 使用远程处理、内存分配、IPC 等的基线功能都完全正常运行、但 TIOVX 应用则完全失败。 有趣的是,第一次你分享的日志显示在这个意义上更好。  

    由于我们仍然看到这些基本类型的错误、因此我倾向于建议我们后退一步、恢复为 A) 完全默认存储器映射或 B) 在 TI EVM 上复制、 我在我这边进行重现

    如何将文件更新到终端系统? 您是否使用 Make Targets 来暂存/安装文件、手动复制等? 显然、这些更改中的大多数正在生效...

    我认为 tispl.bin 不需要更新内存映射。  [/报价]

    剥离假设、我们确保 tispl 和 tiboot3 都在 BOOTFS 中进行更新。

    如果您已恢复与 DM R5(此时已恢复)相关的存储器映射、我很好奇、使用原始 DMR5 固件是否会产生与您重建的结果不同的结果(为此,请将重建的固件替换为原始固件,并确保 uboot 和文件系统更新 make-target 运行)。  

    当 IPC_VRING 等存储器被错误修改(example.syscfg 和生成的 DPL 文件的某些部分未由 python 脚本自动更新)时、我遇到了类似的问题、但该区域在此处保持不变。

    另一种选择是开始分析代码、以了解内核为什么显示为未注册、以及故障模式是否告诉我们此处存在故障的内存。

    这是一个具有挑战性的问题、但我们将解决这个问题!

    BR、Reese

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

    尊敬的 Reese:

    感谢您的答复。

    a) 完全默认内存映射

    我们已尝试此选项、但仍看到分段故障问题。 完全将内存映射保持为默认值没有任何帮助。

    B) 在 TI EVM 上复制、 

    在此选项中、我们从 Yocto 构建系统中获取了引导加载程序、内核和内核模块(即整个内核)。 仅从 TI SDK-11.01.00 中创建 rootfs(使用 tisdk-edgeai-image 创建)。 在此图中、一致性测试顺利通过、没有任何失败。  

    那么、哪些 rootfs 封装会影响一致性测试? 我们知道“ti-vision-apps“提供符合性测试所需的可执行文件和库。 但是、是否有任何其他封装会影响一致性测试? 因此、我们也可以检查这些封装。

    如何将文件更新到最终系统? 您是否使用 Make Targets 来暂存/安装文件、手动复制等? 显然、这些更改中的大多数都在生效。

    我们会更改固件 构建器 SDK、并在我们的 Yocto 固件 (vision_apps/out/AM62A/R5F/freertos/release/vx_app_rtos_linux_mcu1_0_strip.out) 和 c7x 固件 (vision_apps/out/AM62A/C7504/freertos/release/vx_app_rtos_linux_c7x_1.out) 中使用、并在脚本和引导加载程序(tiboot3.bin 中生成 tispl 和固件)。 然后、我们在电路板上使用这些引导加载程序和 rootfs 刷写我们的电路板。


    如果需要我们一方提供任何其他信息、请告知我们。

    此致、

    Jay

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

    尊敬的 Jay:

    感谢您尝试这些建议

    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6322732

    我们已尝试此选项、但仍看到分段故障问题。 完全将内存映射保持为默认值没有任何帮助。

    [/报价]

    我假设您已恢复对 gen_linker_mem_map.py 的所有更改以执行此操作。 问题持续存在表明问题不是您设置的内存映射固有的问题。 假设您在“RTOS“目录中除 gen_linker_mem_map.py 之外、没有进行其他手动更改

    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6322732

    在此选项中、我们从 Yocto 构建系统中获取了引导加载程序、内核和内核模块(即整个内核)。 仅从 TI SDK-11.01.00 中创建 rootfs(使用 tisdk-edgeai-image 创建)。 在此图中、一致性测试顺利通过、没有任何失败。  

    [/报价]

    您使用 SDK 的 ROOTFS、因此我假设这是默认存储器映射。 使用引导加载程序、内核和模块的好调用——这是否意味着您的引导加载程序使用的是由固件构建器生成的 DM R5 固件、还是使用的也是默认的?

    • 否则、仍然通过一致性测试这一事实令人鼓舞、因为您的 Yocto 构建(主要是内核部分)不同

    我们对固件构建器 SDK 进行更改、并使用生成的 DMR5 固件 (vision_apps/out/AM62A/R5F/freertos/release/vx_app_rtos_linux_mcu1_0_strip.out tiboot3.bin) 和 c7x 固件 (vision_apps/out/AM62A/C750/releas/release/vx_ 然后、我们在电路板上使用这些引导加载程序和 rootfs 刷写我们的电路板

    您是否使用 vision_apps.so(包含在 vision_apps/out/AM62A/a53/linux/release/中)的构建输出?

    创建 rootfs 时、您是否曾经使用适用于 linux_fs_stage 或 linux_fs_install 的 sdk_builder make 目标将所有文件复制/安装到使用 linuxfs 目录结构的区域中? 阶段目标会将文件分别放入/tmp/中的这样一个结构中(对于 bootfs 和 rootfs)、`install` target 将转到固件编译器工作区域中的类似 targetfs 和 bootfs。

    • 我注意到固件构建器还具有 Yocto_build 和 Yocto_install 目标、但它们的用法并不明显。 看起来它尝试更接近主 Linux SDK 安装

    我现在正在考虑 Yocto 的角色、但我承认 不太熟悉 Yocto。 您显然可以使用自己生成的固件、因为更新反映了您在远程内核日志上所做的更改。 ti-vision-apps-dev 层最可疑... 层/封装对于更高的软件抽象层起着作用。

    我们还可以从以下角度进行操作:我们已经确定您的图像与 TI ROOTFS 一起工作-->更新 EVM ROOTFS 中的固件和 libtivision_apps、并断言固件和核心 TIOVX 库+一致性测试对 1GB 内存映射起作用。 然后、我们可以重点关注在 Yocto 创建文件系统时这些输出发生的情况

    BR、
    Reese

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

    尊敬的 Reese:

    感谢您的答复。

    我假设您已恢复对 gen_linker_mem_map.py 的所有更改来执行此操作。 问题持续存在表明问题不是您设置的内存映射固有的问题。 假设您除了 gen_linker_mem_map.py
    之外、没有在“RTOS“目录中进行其他手动更改

    我们对 “边沿增强模式“进行了一次更改、以修复 SDK-11.01.00 中的错误。 下面是我有关 EE 模式问题的线程:
    主题: AM62A7:Yocto SDK-11:ee-mode=2 (EE_MODE_Y8) 无法正常工作
    解决方案: https://git.ti.com/cgit/processor-sdk/imaging/commit/kernels/hwa/vpac_viss/vx_vpac_viss_target_drv.c?h=main&id=3e540d2b482ca9b88ffb40c624883c5a680fb2c1

    仅在存储器映射更改旁边进行更改。

    我假设这是使用默认存储器映射的、因为您使用的是 SDK 的 ROOTFS。 使用引导加载程序、内核和模块的良好调用——这是否意味着您的引导加载程序正在使用由固件构建器生成的 DM R5 固件、还是使用默认设置?

    在我们更改存储器映射时、引导加载程序会使用 由 firmware-builder SDK 生成的 DM R5 固件。 但当我们使用 默认存储器映射时、DM-R5 和 C7x 固件是默认的。  

    您是否使用 vision_apps.so 的构建输出(包含在 vision_apps/out/AM62A/A53/linux/release/中) ?[/quot]

    我们已经尝试替换 vision_apps/out/AM62A/a3/linux/release/中包含的 libtivision_apps.so、 在更改存储器映射时。 即使在替换  libtivision_apps.so 后、我们也注意到一致性测试仍然失败。

    创建 rootfs 时、是否使用 SDK_builder 为 linux_fs_stage 或 linux_fs_install 创建目标来将所有文件复制/安装到使用 linuxfs 目录结构的区域? 阶段目标会将文件分别放入/tmp/中的这样一个结构中(对于 bootfs 和 rootfs)、`install` target 将转到固件编译器工作区域中的类似 targetfs 和 bootfs。

    我们只  使用了 DMR5 固件 (vision_apps/out/AM62A/R5F/freertos/release/vx_app_rtos_linux_mcu1_0_strip.out) 和 c7x 固件 (vision_apps/out/AM62A/C7504/freertos/release/vx_app_rtos_linux_c7x_1.out) 并使用了固件  构建器 SDK 中的 libtivision_apps.so。 如果我们必须为 A53 (Linux) 使用任何其他可执行文件、请告知我们。

    下面是我们可以采用的另一个角度:我们已经确定您的图像与 TI ROOTFS 一起正常工作->更新 EVM ROOTFS 中的固件和 libtivision_apps、并断言固件和内核 TIOVX 库+一致性测试对于 1GB 内存映射正常工作。 然后、我们可以重点关注在 Yocto 创建文件系统
    时这些输出发生的情况。

    我们将选中此选项并在此处提供日志。  

    此致、

    Jay

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

    尊敬的 Reese:

    下面是我们可以采用的另一个角度:我们已经确定您的图像与 TI ROOTFS 一起正常工作->更新 EVM ROOTFS 中的固件和 libtivision_apps、并断言固件和内核 TIOVX 库+一致性测试对于 1GB 内存映射正常工作。 然后、我们可以重点关注在 Yocto 创建文件系统
    时这些输出发生的情况。

    正如您所建议的、我们已经尝试过这种方法。 Yocto 项目中的引导加载程序+内核、以及 TI SDK-11.01.00 中的 rootfs。  借助这种方法、当我们运行 tiovx 一致性测试时、一致性测试滞留在最后阶段的某个位置、具体打印如下。 在此之后、一致性测试 doest 提供任何日志、必须通过按 CTRL+C 停止  

    “[MCU1_0]  1375.694622 s:断言:1375.543785s:freertos-Kernel/queue.c:xQueueGiveMutexRecursive:763:(uint32_t)(pxMutex) failed!!!“

    以下是我们的内存映射更改和所需日志:

    “gen_linker_mem_map.py“脚本和相关文件更改:

    e2e.ti.com/.../5775.gen_5F00_linker_5F00_mem_5F00_map.txt


    启动日志:
    e2e.ti.com/.../6278.bootup_5F00_logs.txt


    e2e.ti.com/.../0003.vision_5F00_apps_5F00_init_2D00_logs.txt


    e2e.ti.com/.../0003.vx_5F00_app_5F00_arm_5F00_ipc_2D00_logs.txt


    运行“vx_app_arm_ipc.out“时、我注意到电路板上的 dmesg 中有以下日志。 但“vx_app_arm_ipc.out“日志显示了所有通过的测试。


    e2e.ti.com/.../vx_5F00_app_5F00_arm_5F00_ipc_2D00_dmesg_2D00_logs.txt


    e2e.ti.com/.../7331.vx_5F00_app_5F00_arm_5F00_mem_2D00_logs.txt


    e2e.ti.com/.../vx_5F00_app_5F00_heap_5F00_stats_2D00_logs.txt


    e2e.ti.com/.../vx_5F00_app_5F00_conformance_5F00_core.txt

    除此之外、如果还需要任何其他信息、请告知我们。

    此致、

    Jay

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

    尊敬的 Jay:  

    每个内核和 Linux 的引导日志看起来都很好--我很感激您每次都提供这些信息。 请继续

    IPC 消息与我无关——核心测试通过了、除一致性测试外、所有其他基本机制都通过了。  

    我在符合性测试中看到、MPU1_0 测试正在通过、但在运行 FreeRTOS 的远程内核上、失败的方式与此相同--内核被检测为“未注册“

    • 但是、当它们在日志中注册时、您可以看到它们的名称显示、例如 `[MCU1_0] 6.584817 s:vx_zone_info:[AddownTargetKernelInternal:189]目标 MCU1-0 上的注册内核 com.ti.test_kernel.Pyramide_intermediate`
    • 在 tiovx/source/framework/vx_target_kernel_instance.c 中 的 ownTargetKernelInstanceAlloc 内 、调用失败。  tiovx/source/framework/vx_target_kernel.c 中对 ownTargetKernelGet 的调用有几种失败模式: a) 无法锁定互斥量、B) 无法将请求的字符串与 g_target_kernel_table 中的字符串匹配
      • 互斥锁是我的猜测、因此内核显示在先前的日志中已注册并且与 SDK 一致

    您能否使用--filter=“*MPU“运行符合性测试? 我们来证明、TIOVX 在 Arm-A 内核上没有被破坏、这意味着全局使用的核心机制和存储器分割是正确的  


    这是有趣的:

    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6326554

    正如您所建议的、我们已经尝试过这种方法。 Yocto 项目中的引导加载程序+内核、以及 TI SDK-11.01.00 中的 rootfs。  借助这种方法、当我们运行 tiovx 一致性测试时、一致性测试滞留在最后阶段的某个位置、具体打印如下。 在此之后、一致性测试 doest 提供任何日志、必须通过按 CTRL+C 停止  

    “[MCU1_0]  1375.694622 s:断言:1375.543785s:freertos-Kernel/queue.c:xQueueGiveMutexRecursive:763:(uint32_t)(pxMutex) failed!!!“

    [/报价]

    它支持我的假设、即互斥量调用失败。 您是否 比此更早在 vision_apps_init.sh / vx_app_arm_remote_log.out 输出中看到过此消息? 我只看到了这个实用程序的启动时日志、但也许我们已经错过了这里看起来像一个吸烟枪的东西。  我以前没有遇到过这个问题  

    还将解释为什么 DSP 和 MCU1 目标器件都以相同的方式失效。 我知道您已经完成了 SDK_scrub、  原本会清理这个 MCU_PLUS_SDK 组件。  

    • 在这里使用了 TI 的 rootfs。 您是否也使用了 TI 的 C7x 二进制文件以及引导加载程序? 请阐明是否使用了任何原始 TI 固件、或者您是否使用了所构建的固件。 我想知道原始固件是否会出现这种互斥问题、并确定这是否与整个系统有关、或是否仅限于您构建的固件。

    我不确定什么会导致这种情况对您来说失败、但我要通过分析代码、以便在代码到达各种点和指向它们的关键变量/指针(例如,状态值,互斥量/句柄位于哪个内存区域)时打印代码来解决此问题。 互斥量本身的实现应来自 MCU_PLUS_SDK 组件

    firmware-builder 中的调用栈如下所示:  

    • tiovx/source/framework/vx_target_kernel.c:ownTargetKernelGet ()-> tivxMutexLock ()
    • tiovx/source/platform/board/rtos/tivx_mutex.c:tivxMutexLock ()-> appRthosSemaphorePend ()
    • app_utils/utils/rtos/rtos/app_rtos_MCU_PLUS_SDK.c src:appRTosSemaphorePend ()-> SemaphoreP_Pend ()
    • mcu_plus_sdk_am62ax_11_01_00_16/source/kernel/freertos/dl/common/Semaphore_freertos.c:Semaphore_pend  ()-> xSemaphoreTakeRecursive ()-> xQueueGiveMutexRecursive () 的宏  
    • mcu_plus_sdk_am62ax_11_01_00_16/source/kernel/freertos-Kernel/queue.c:xQueueGiveMutexRecursive ()-> 断言调用失败

    也许还值得打印 tiovx/source/framework/vx_target_kernel.c 中的一些数据: ownTargetKernelGet (){ g_target_kernel_table },只是为了验证它是否确实包含多个内核的名称/ ID。 这将进一步确认互斥量是问题的一部分

    我们还来启用信息级 OpenVX 消息。

    此外、我还需要一些与 FreeRTOS 端口相关的其他专业知识、以便确定您是否因某种已知原因会遇到这样的错误。 我再次想知道在 TI 提供的固件中是否出现此错误、从而可能导致系统级配置触发此错误。  

    BR、
    Reese

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

    需要澄清的另一点是:

    我们 Yocto 项目中的引导加载程序+内核和 TI SDK-11.01.00 的 rootfs。  采用这种方法时、当我们运行 tiovx 一致性测试时、一致性测试滞留在最后一个阶段、具体打印如下。

    互斥量问题导致此问题失败、这可能是与未注册内核问题相似的根本原因。  

    这 发生在您的硬件上?

    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6322732
    b) 在 TI EVM 上复制、  

    在此选项中、我们从 Yocto 构建系统中获取了引导加载程序、内核和内核模块(即整个内核)。 仅从 TI SDK-11.01.00 中创建 rootfs(使用 tisdk-edgeai-image 创建)。 在此图中、一致性测试顺利通过、没有任何失败。  

    [/报价]

    这在 TI 硬件上确实如此。


    这一切就像是一个软件问题。 这些测试用例是否在某种程度上不同于硬件。 我想您必须为您的硬件构建引导加载程序。 它是否使用了 TI 库存固件或您的固件构建器输出? 对于 TI 硬件、您是否使用了您构建的任何形式的固件?

    我倾向于说 Linux 内核在这里无关。 同样、libtivision_apps 也不相关。  

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

    尊敬的 Reese:

    感谢您的答复。

    您能否使用--filter=“*MPU“运行符合性测试? 我们来证明 TIOVX 在 Arm-A 内核上没有被破坏、这意味着全局使用的核心机制和存储器分割是正确的 [/报价]

    vx_app_conformance_core.out --filter=“*mpu*“测试(总共 105 个测试)正在通过、没有任何错误。 以下是日志(内存映射和其他参数与我上次回复中的相同):

    e2e.ti.com/.../vx_5F00_app_5F00_conformance_5F00_core_2D00_for_2D00_mpu.txt

    您是否 比此更早在 vision_apps_init.sh / vx_app_arm_remote_log.out 输出中看到过此消息?

    之前未观察到此错误。 运行“vision_apps_init.sh“时未观察到此错误消息。 我已经检查过。  

    我看到、您在此处使用了 TI 的 rootfs。 您是否也使用了 TI 的 C7x 二进制文件以及引导加载程序? 请阐明是否使用了任何原始 TI 固件、或者您是否使用了所构建的固件。 我想知道原始固件是否会遇到这样的互斥问题,并确定这是否与整个系统有关,或者是否仅限于您构建的固件。[/报价]

    我们更改了存储器映射并使用 DM-R5 固件生成了引导加载程序。 信号。 我们使用了从固件构建器 SDK 生成的 C7x 固件。 对于 C7x 固件、我们将板载“C7x“上的默认固件替换/lib/firmware/ti-ipc/am62axx/dsp_edgeai_c7x_1_release_strip.out 为从固件构建器生成的 C7x 固件。 据我们 所知、C7x 固件 在启动时从路径/lib/firmware/ti-ipc/am62axx/dsp_edgeai_c7x_1_release_strip.out 加载到 C7x 内核上。 如果这种理解有误、请纠正我们。 还使用了从固件构建器 SDK 中生成的 libtivision_apps.so。 在更改存储器映射时、我们使用固件构建器 SDK 中提到的工件。

    [报价 userid=“360457“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6327107

    firmware-builder 中的调用栈如下所示:  

    • tiovx/source/framework/vx_target_kernel.c:ownTargetKernelGet ()-> tivxMutexLock ()
    • tiovx/source/platform/board/rtos/tivx_mutex.c:tivxMutexLock ()-> appRthosSemaphorePend ()
    • app_utils/utils/rtos/rtos/app_rtos_MCU_PLUS_SDK.c src:appRTosSemaphorePend ()-> SemaphoreP_Pend ()
    • mcu_plus_sdk_am62ax_11_01_00_16/source/kernel/freertos/dl/common/Semaphore_freertos.c:Semaphore_pend  ()-> xSemaphoreTakeRecursive ()-> xQueueGiveMutexRecursive () 的宏  
    • mcu_plus_sdk_am62ax_11_01_00_16/source/kernel/freertos-Kernel/queue.c:xQueueGiveMutexRecursive ()-> 断言调用失败
    [/报价]

    是否建议在互斥量或信标锁定之前和之后启用上述功能中的打印?

    这 是在您的硬件上吗?

    是的、这是我们的硬件。

    、这完全是在 TI 硬件上实现的。

    这也是我们的硬件。 我们有 2 种电路板型号。 1) 1GB DDR 型号、2) 2GB DDR 型号。 此测试是我们使用 2GB 型号完成的唯一一项测试、我们不需要更改内存映射。 这里默认使用 DM-R5、C7x 和其他伪影。 (注意;以上所有失败结果均来自 1GB DDR 型号。 1GB DDR 型号是我们目前的最高优先级)。

    我们的最终目标:

    最后、我们希望 在我们的电路板上运行 edgeai-tidl-tools SDK (github.com/.../edgeai-tidl-tools) 的示例、并确保所有模型在电路板上正常运行。

    如果 edgeai-tidl-tools SDK 中的示例在电路板上运行正常、那么我们是否需要执行符合性测试以验证存储器映射?

    此致、

    Jay

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

    尊敬的 Jay:

    我现在更好地了解硬件情况、感谢您的澄清。 2 GB 主板可以使用默认内存映射、工作正常、但 1 GB 需要更改、到目前为止没有配置工作。  

    • 这是您在 2 GB 主板上运行的唯一测试? 您已经在此主板上测试了固件构建器输出、是还是否? 我预计您的固件会导致相同的问题 2 GB 主板,否则相同的软件

    并且未确认 MPU 端问题;仅远程内核未通过测试。


    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6328138

    如果 edgeai-tidl-tools SDK 中的示例在电路板上运行正常、那么我们是否需要执行符合性测试以验证存储器映射?

    [/报价]

    如果一致性测试失败、那么我有疑问的 edgeai-tidl-tools 示例也会运行-- TIDL 软件在后台使用 TIOVX、VPAC 中的 ISP 组件(由 DM R5 内核运行)也是如此。

    运行一致性测试时、您没有在 vison_apps_init.sh / vx_app_arm_remote_log.out 上看到任何其他消息? 重申一下、我没有看到引导时日志消息的问题、但可能有一些运行时日志提供了有用的信息。 根据您所说的、我必须假定此记录器在启动后是静默的。 可能最好在单独的终端中运行、或者转储/TEE 到日志文件

    • 我在 tiovx/.../tivx_init.c 中建议进行的代码更改之一将使这些远程内核日志更加详细。  

    TIDL 有一个符合性测试二进制文件、它将直接在 DSP 上测试完全相同的 TIOVX 内核、如果这样会给出类似的功能错误、那么 edgeai-tidl-tools 也会这样。 您可以尝试_tidl.out 和_hw.out 一致性测试、但我预计您将看到相同的错误。  

    • 如果 tidl 工具示例正在运行、那么我们需要验证它们是否提供了合理/正确的结果、并且它实际上在 C7x 上运行、而不是回退到 CPU

    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6328138

    是否建议在互斥量或信标锁定之前和之后启用上述功能中的打印?

    [/报价]

    是的、请在我提到 abov 的电话之前和之后附上照片。 请确保它还打印了函数名称/文件以实现可追溯性。 对于已记录函数调用后的打印、请打印可能已返回的任何状态/返回值


    对于 C7x 固件、我们将“C7x“上的默认固件替换/lib/firmware/ti-ipc/am62axx/dsp_edgeai_c7x_1_release_strip.out 为从固件构建器生成的 C7x 固件。 据我们 所知、C7x 固件 在启动时从路径/lib/firmware/ti-ipc/am62axx/dsp_edgeai_c7x_1_release_strip.out 加载到 C7x 内核上。 如果此理解错误、请更正我们

    是、对于 C7x、仅需要在 rootfs 中使用二进制文件进行更改。 您对位置正确无误。 确切地说、有一个设置完整路径的软链接。 否则、假定路径是/usr/lib/firmware/am62a-c71_0-fw、由 DTS 的一部分指定。  

    root@am62axx-evm:/opt/edgeai-gst-apps# file /usr/lib/firmware/am62a-c71_0-fw
    /usr/lib/firmware/am62a-c71_0-fw: symbolic link to /usr/lib/firmware/ti-ipc/am62axx/dsp_edgeai_c7x_1_release_strip.out
    


    因此、我想总结一下我们目前的情况:

    1. 需要 1GB 的内存映射、该方法仅更改 DM R5 和 C7x 的堆
    2. 存储器映射更新已成功引导、内核显示正确的堆、在 TIOVX 记录器 (vx_app_arm_remote_log.out) 和 dmesg / Linux 内核引导日志中执行分割。
      1. DTS 和固件在存储器分割上是一致的
    3. /opt/vision_apps 通过的基本 IPC、存储器分配等测试
    4. TIOVX 一致性测试失败  
      1. MPU (A53) 测试通过
      2. MCU1_0(运行 VPAC 的 DM R5)和 DSP1 (C7 NPU) 未通过所有一致性测试
    5. 恢复 DM R5 堆以匹配原始堆仍会导致此内核上出现错误。 即使原始存储器映射也会失败
    6. 采用 TI 的 ROOTFS、包括固件、并使用 2GB 板上的默认存储器映射即可符合性。 如果 C7x 固件和 DMR5 固件(在引导加载程序中)使用固件构建器输出进行更新、则相同的 ROOTFS 失败

    以上都是真的吗? 如果我误传了任何内容、请更正。 如果都是真的,那么我会重申生成的固件是关键的分析。  

    BR、
    Reese

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

    我已经和同事一起查看了这个问题、并有另一种调试方法:

    假设默认固件起作用、我们尝试将 firmware-builder 中的 vision_apps 组件恢复为其原始状态、并使用要测试的默认存储器映射构建固件(在 1Gb 或 2GB 板上)。 这是一项健全性检查。

    这里提醒我、发布后对 vision_apps 实施了一些 bug 修复、以涵盖与固件构建和 example.syscfg 相关的错误案例。 我不认为它们会适用于你,因为你只改变堆,但让我们也考虑这条道路

    • 我建议从标签“REL.PSD.analytics.AM62A.11.01.00.04“或提交“2e5e8f029634cc44f2d0927ce1e60e2341c8fbab“中提取此存储库[1]
    • 请验证这在默认内存映射上是否起作用、然后实现与最初相同的堆大小更改

    [1] https://git.ti.com/cgit/processor-sdk/vision_apps 

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

    尊敬的 Reese:

    请在您的疑问中从我们这边找到以下更新信息。

    这是您在 2 GB 主板上运行的唯一测试吗? 您已在此主板上测试固件构建器输出、是或否?

    是的、这是我们在 2GB 电路板上执行的唯一测试。 我们尚未在 2GB 主板上测试固件构建器输出、因为我们的优先事项是解决 1GB 设备的问题。

    我在 tiovx/.../tivx_init.c 中建议的其中一个代码更改将使这些远程内核日志更加详细。

    我们将在后台的单独终端中使用 vx_app_arm_remote_log.out 二进制文件执行建议的更改和捕获日志。

    如果 tidl 工具示例正在运行、则我们需要验证它们是否提供了合理/正确的结果、以及它是否实际在 C7x 上运行、而不是回退到 CPU

    更改器件上由固件编译器生成的二进制文件后、edgeai-tidl-tools 示例在 1GB 器件上运行。 我们如何确认它是在 C7x 还是 CPU 上运行?

    是的、请在我提到的电话前后提供照片。 请确保它还打印函数名称/文件以实现可追溯性

    我们将从最后开始检查并提供结果。

    以上都是真的吗? 如果我有任何错误陈述、请更正。

    以下是给定点的一些附加信息、其余信息是 正确的。

    需要 1GB 的内存映射、该方法仅更改 DM R5 和 C7x
    的堆

    正确、此方法需要针对 1GB 器件的 DM R5 和 C7x 堆进行更改。 目前、我们更改了这些段、因为它们位于存储器区域的末尾部分。 如果需要、我们可以在这些地区进行调整。

    恢复 DM R5 堆以匹配原始堆仍会导致此内核上出现错误。 即使原始内存映射失败

    对于 1GB 设备、我们尚未通过将 DM R5 堆恢复到原始堆进行测试。 我们将对此进行检查。 对于 2GB 设备、此注释正确。

    采用 TI 的 ROOTFS、包括固件、并使用 2GB 板上的默认存储器映射、符合性测试。 如果 C7x 固件和 DMR5 固件(在引导加载程序中)使用固件构建器输出进行了更新、则相同的 ROOTFS 失败

    是、对于 2GB 器件、它通过 TI rootfs 和默认存储器映射。 在 rootfs 中更新了固件编译器二进制文件的 1GB 器件上、相同的 ROOTFS 失败。

    谢谢、

    Jay

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

    尊敬的 Jay:  

    这很有帮助、并总结了当前的情况、现在就更清楚了(并且将使我的同事更容易提供帮助,而我下周的回应速度较慢)。  

    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6329829

    更改器件上由固件编译器生成的二进制文件后、edgeai-tidl-tools 示例在 1GB 器件上运行。 我们如何确认它是在 C7x 还是 CPU 上运行?

    [/报价]

    我们可以通过几种方式进行检查:

    • 在/opt/edgeai-gst-apps/scripts/perf_stats 中,有一个小的应用程序(必须建立)将测量核心利用率。 如果 C7x 的百分比为非零、则表示正在使用[1]
    • 从示例应用程序的日志中提取;如果有任何关于回退到 CPUExecutionProvider 或 XNNPACK 的消息、则它可能在 CPU 上而不是 C7x 上运行

    我们还可以检查 TIDL 特定的一致性测试(该测试的一些输入数据位于固件构建器安全资源 TI.com 页面上的不同压缩包中)

    同样、您也可以尝试以“_hwa.out “结尾的符合性测试。 这将测试 VPAC 内的 ISP 和其他图像预处理加速器。 我曾假设如果内核一致性测试成功、这些测试可能会失败、但如果 TIDL 测试正常工作、也可能如此。  


    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6329829

    是、对于 2GB 器件、它通过 TI rootfs 和默认存储器映射。 在 rootfs 中更新了固件编译器二进制文件的 1GB 器件上、相同的 ROOTFS 失败。

    [/报价]
    1. 我懂了。 这是运行比较的好点、因为我们只应因固件、设备树和 libti_vision_apps.so 而有所不同。 设备树和 libtivision_apps 在最近的更换中未给出任何问题原因。  

    我的建议是:  

    1. 全新安装固件构建器并重新构建固件。 将其用于 2GB 板、无需对健全性测试进行其他更改
    2. 如果以上测试通过、请为 2 GB 主板尝试 1 GB 内存映射。
      1. 由于我们在每个 C7x 和 DM R5 上看到相同的问题、因此我建议先仅更改 C7x、确保任一内核都不会出现性能下降
      2. 如果先前的要点未通过、则我建议使用我之前(就在这之前)的建议来提取更新的 vision_apps。 我们在 11.1 公开发布后修补了其中的几个问题

    [1] https://software-dl.ti.com/processor-sdk-linux/esd/AM62AX/11_01_07_05/exports/docs/edgeai/measure_perf.html 

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

    尊敬的 Reese:  

    感谢您的答复。  

    重新安装固件构建器并重新构建固件。 将其用于 2 GB 主板、无需对健全性测试进行其他更改

    根据您的建议、我使用了全新的 firmware-builder(并且没有进行任何保留的内存更改)并构建了 DM-R5 和 C7x 固件。 使用 firmware-builder build DM-R5、C7x 固件、libtivision_apps.so 并运行符合性测试 1 ) vx_app_conformance_core.out 2) vx_app_conformance_tidl.out、然后进行传递。

    由于我们看到每个 C7x 和 DM R5 上都存在相同的问题、因此我建议先仅更改 C7x、并确保任一内核均不会降级

    对于存储器映射更改、我只更改 C7x 本地堆 (DDR_C7X_1_LOCAL_HEAP) 和 C7x 暂存堆 (DDR_C7X_1_SCRATCH)、并将其设置为 56MiB 的一半。 并在 2GB DDR 电路板上运行符合性测试。 但在 2GB 电路板上、TIOVX 一致性测试失败。

    如果先前的点没有通过、那么我建议遵循我之前的建议(在此之前)、提取更新的 vision_apps。 我们在 11.1 公开发布后修补了其中的几个问题

    我已从提交 ID “2e5e8f029634cc44f2d0927ce1e60e2341c8fbab“中查看了 vision_apps、并使用了第一个具有默认存储器映射的已编译固件构建器、使用了 DM-R5 和 C7x 固件、确实有效(符合性测试通过)。 之后、我更改了内存映射(与上述相同)、并编译了固件构建器并运行符合性测试。 但内存映射更改后、Conformace 测试无法再次运行。  


    看起来、只要发生任何 存储器映射更改、一致性测试就会失败。 以下是 vision_apps 提交 ID 为“2e5e8f029634cc44f2d0927ce1e60e2341c8fbab“时的内存更改失败日志。

    e2e.ti.com/.../7853.bootup_2D00_logs.txt

    e2e.ti.com/.../7853.vision_5F00_apps_5F00_init_2D00_logs.txt

    e2e.ti.com/.../6215.vx_5F00_app_5F00_heap_5F00_stats_2D00_utility_2D00_logs.txt

    e2e.ti.com/.../6215.vx_5F00_app_5F00_arm_5F00_ipc_2D00_logs.txt

    e2e.ti.com/.../6215.vx_5F00_app_5F00_arm_5F00_mem_2D00_logs.txt

    e2e.ti.com/.../0820.vx_5F00_app_5F00_conformance_5F00_core.log

    您能否确认更改存储器映射会导致一致性测试失败的行为?

    此致、

    Jay

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

    尊敬的 Jay:

    本周我暂时无法进行测试、但我正在跟踪问题并要求同事在此处提供帮助。  

    测量值是一个有用的数据点。 确认开箱即用配置以提供功能构建输出、但一旦您运行该 linker...py 脚本、它就会生成不起作用的固件。  

    我看到 MCU1 测试也失败。 您是否使用这个只改变 C7x 区域的临时存储器映射更新了 uboot / DM R5 固件?

    • 在为默认存储器映射构建时、您是否运行了 Python 脚本? 我对由此产生的差异很好奇。  

    感谢您尝试使用较新的 vision_apps 版本、但了解它带来了相同的问题。  

    我知道此提交中还有其他相关修复[1]、因此我也想提供此修复

    [1] https://git.ti.com/cgit/processor-sdk/vision_apps/commit/?h=REL.PSDK.ANALYTICS.AM62A.11.02.00.03&id=dc07ac00a83dc45295e1b2645236ab10d07080c0  

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

    尊敬的 Reese:

    您是否使用这个仅改变 C7x 区域的临时存储器映射更新了 uboot / DM R5 固件?

    是的、当只有 C7x 区域发生变化时、我更新了 uboot / DM R5 固件

    在为默认内存映射进行构建时、您是否运行了 Python 脚本? 我对由此产生的差异很好奇。  [/报价]

    编号 构建固件时、我尚未运行 python 脚本。 我采用了全新的构建并直接编译了它。 我的另一个观察结果:运行 python 脚本以更改内存映射时、如果我要使用默认内存映射并运行 python 脚本以更改默认内存映射、则生成的固件将不起作用。 再说一次、我必须创建新的构建。

    [报价 userid=“360457“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6332495

    我知道此提交中还有其他相关修复[1]、因此我也想提供此修复

    [1] https://git.ti.com/cgit/processor-sdk/vision_apps/commit/?h=REL.PSDK.ANALYTICS.AM62A.11.02.00.03&id=dc07ac00a83dc45295e1b2645236ab10d07080c0  

    [/报价]

    我已经尝试了这个 vision_apps。 更改存储器映射时、该操作也会失败。  

    此致、

    Jay

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

    尊敬的 Jay:  

    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6332886

    是的、当只有 C7x 区域发生变化时、我更新了 uboot / DM R5 固件

    [/报价]

    您能否尝试仅针对 C7x 固件和 DTS 实现更改后的存储器映射? 我们恢复了全新的固件构建器、运行 gen_linker_mem_map.py、并仅在我们的 EVM 上更新了 C7 固件。 它仍在通过一致性测试。 这是一个健全性测试

    我想知道 MPU(存储器保护单元,即, 不是 MPU:=A53) 是根本原因  

    运行 gen_linker_mem_map.py 脚本后、我会在 MCU1 和 C7X_1 的 example.syscfg 中看到更改。 我更担心 mcu1_0/example.syscfg 中的增量(也许您只能恢复该文件并重试构建)。 其他修改过的文件与我无关。

    以下是我的比较原始文件 (a) 与 python 脚本运行后生成的 example.syscfg (b)

    diff --git a/vision_apps/platform/am62a/rtos/mcu1_0/example.syscfg b/vision_apps/platform/am62a/rtos/mcu1_0/example.syscfg
    index 093f7e4c..1953db26 100644
    --- a/vision_apps/platform/am62a/rtos/mcu1_0/example.syscfg
    +++ b/vision_apps/platform/am62a/rtos/mcu1_0/example.syscfg
    @@ -64,7 +64,7 @@ mpu_armv75.tex = 5;
    mpu_armv75.isCacheable = false;
    
    mpu_armv76.baseAddr = 0x9C800000;
    -mpu_armv76.size = 21;
    +mpu_armv76.size = 20;
    mpu_armv76.$name = "IPC_VRING_RESOURCE_TABLE_LINUX";
    mpu_armv76.attributes = "CUSTOM";
    mpu_armv76.tex = 0;
    @@ -88,7 +88,7 @@ mpu_armv78.isCacheable = false;
    mpu_armv78.isBufferable = false;
    mpu_armv78.tex = 0;
    mpu_armv78.baseAddr = 0xA1000000;
    -mpu_armv78.size = 24;
    +mpu_armv78.size = 18;
    
    mpu_armv79.$name = "TIOVX_RUN_TIME_LOGGING2";
    mpu_armv79.allowExecute = false;
    @@ -97,7 +97,7 @@ mpu_armv79.isCacheable = false;
    mpu_armv79.isBufferable = false;
    mpu_armv79.tex = 0;
    mpu_armv79.baseAddr = 0xA2000000;
    -mpu_armv79.size = 24;
    +mpu_armv79.size = 22;
    
    mpu_armv710.$name = "DDR_DM_R5F_VISS_CONFIG_HEAP";
    mpu_armv710.size = 22;

    我建议恢复 mcu1_0/example.syscfg 中的更改、但保留与修改后的堆区域相关的 C7x 映射中的更改。 我认为  0xA1000000 时的 mpu_armv78 是最可能的原因。 此处调整大小会导致 该内核上的 MPU 忽略 TIOVX OBJ_DESC(来自 0xA1040000)区域。  

    [引述 userid=“603086“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6332886

    我已经尝试了这个 vision_apps。 更改存储器映射时、该操作也会失败。  

    [/报价]

    感谢您试用。 我不知道已实施的任何其他更改、我希望这些更改可以解决您的问题。

    此外、我必须纠正我刚才所说的话。 我有这些混合。 tispl.bin 将携带应用程序级 DMR5 固件(以及存储器映射详细信息)、tiboot3.bin 仅处理系统的初始化。 参考资料: https://docs.u-boot.org/en/stable/board/ti/am62ax_sk.html  

    R5F 二进制文件由 tiboot3.bin 携带。 您是否更新了此组件? 这可能是根本问题。 我认为 tispl.bin 不需要更新内存映射。  [/报价]
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    通过重新运行 gen_linker_mem_map.py 脚本、我们得以重现此问题。

    • 我可以确认、VPAC 的 HWA 测试也失败、这意味着无法解决该问题、会导致 ISP 和类似的图像处理加速无法正常工作。  
    • 对于原始 tispl.bin 和更新的 C7x 固件、一致性测试都已通过、因此问题似乎局限于 MCU1_0

    当我们将此 MPU_arm78 大小修改为保持为 24(即 16MB)而不是调整为 18 (256KB) 时、符合性测试失败不再存在。  

    • 它是`mpU_armv78.$name =“TIOVX run_time_LOGG1“的区域;`μ s 位置 0xA100 0000

    未为此更改设备树和 libtivision_apps.so

    请在您这边尝试并确认功能;我们可以继续生成 bugfix

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

    我还会注意到、一位同事提到、这里的提交[1]应该已经解决了我们在这里看到的问题、并且该更改将通过标签包含在[2]中。

    从该标签运行 gen_linker_mem_map.py 确实会产生预期的 example.syscfg、但我会看到由于缺少引用而导致 libtivision_apps 构建失败(软件版本未对齐,因此我不会感到惊讶)。

    运行 gen_linker_mem_map.py 并重建固件(忽略 libtivision_apps 构建过程中的故障)后、将该 R5 固件编译 到生成的 tispl.bin 中会通过一致性测试

    以下提交被推送到该标签[2]和 11.1 发行版中使用的版本之间的 am62a/platform/RTOS 目录中:


    #from tag  REL.PSDK.ANALYTICS.AM62A.11.02.00.03:
    $> git log  2e5e8f029634cc44f2d0927ce1e60e2341c8fbab..HEAD platform/am62a/rtos/
    commit 389c5b7edb684657f536ad934ebf20aabb49998e
    commit d3bfc6217ad7983b132d2c891bb7aa1a86b53448
    commit daac64d93a3beed55e02a5551fed39ba614dceda
    commit dc07ac00a83dc45295e1b2645236ab10d07080c0
    commit cc1a76e80af092a55e504997e0940427c6bd2c5a
    commit 94b01572c321878e1e1fb2ce1715c2e055158bcd
    commit 56c90e83407a016f2286d1ec7083bd60e19087e5
    commit 1827458cd95042f0d79821e554a8f4baed1f245d
    commit 75e691b0985b049c456f74d0564bf6bac489564b
    commit 0a8dab60837421c6f7f934b1ea4cce780b9013bb

    [1] https://git.ti.com/cgit/processor-sdk/vision_apps/commit/?h=main&id=d3bfc6217ad7983b132d2c891bb7aa1a86b53448 

    [2] https://git.ti.com/cgit/processor-sdk/vision_apps/tag/?h=REL.PSDK.ANALYTICS.AM62A.11.02.00.03 

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

    尊敬的 Reese:  

    通过仅更改 C7x 固件的方法、我们也能够使用 rootfs 通过一致性测试。

    [报价 userid=“360457“ url=“~/support/processors-group/processors/f/processors-forum/1637622/am62a7-reserved-memory-map-changes-for-1gb-ddr/6335038

    [1] https://git.ti.com/cgit/processor-sdk/vision_apps/commit/?h=main&id=d3bfc6217ad7983b132d2c891bb7aa1a86b53448 

    [2] https://git.ti.com/cgit/processor-sdk/vision_apps/tag/?h=REL.PSDK.ANALYTICS.AM62A.11.02.00.03 

    [/报价]

    我们将检查此 vision_apps 提交以确认 DM-R5F 保留存储器映射更改。  

    非常感谢您在这个问题上的帮助。

    此致、

    Jay