• 状态 Resolved
  • 已锁定 已锁定
  • 回复 18 回复
  • 订户 0 订户
  • 视图 2 视图
  • 用户 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.

[参考译文] AM62A7：使用 SDK-11 组件为定制电路板时的流式传输问题

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board

器件型号： AM62A7

尊敬的 TI 团队：

我们使用基于 AM62A-SK EVM 的定制电路板设计。 我们能够在定制板上通过 Yocto SDK-09.01.00 和 SDK-10.01.00 使用所有流功能。

我们的要求是使用自定义元图层来包括设备的 rootfs 中的所有文件系统组件。 在这里、我们使用的是具有 SDK-11 中的 meta-edgeai 层的自定义元层。 在本例中、我们观察到使用 tiovxisp 插件时存在流式传输问题。

我们使用的是 Linux 内核、U-boot 组件 和 “/lib/firmware “ 构建的。 和自定义元图层中的 rootfs 组件（包）。 接下来、我们能够启动电路板、并能够通过提及的更改启动所需的接口。


但当我们使用 ISP 从摄像头传感器进行流式传输时、摄像头流挂起。 以下是日志。

启动后的 dmesg 日志：
kernel-6.12.35-logs.txt 

media-ctl 命令输出：
media-ctl-command.txt 

R5F 和 C7x 内核启动日志：

remote-core-logs.txt 

启用 tiovx 日志的 ISP 流水线：

tiovxisp-pipeline-logs.txt 


用于捕获原始帧的流水线工作正常、而不会出现问题。 下面是流水线。 

gst-launch-1.0 -v v4l2src device=/dev/video2 ! video/x-bayer, width=1920, height=1200, framerate=30/1, format=rggb10  ! fakesink

ISP 的流水线挂起、未提供任何图像： 

gst-launch-1.0 -v v4l2src device=/dev/video2 io-mode=dmabuf-import ! video/x-bayer, width=1920, height=1200, framerate=60/1, format=rggb10 ! tiovxisp sink_0::device=/dev/v4l-subdev2 dcc-isp-file=/opt/imaging/ar0235/dcc_viss_10bit_1920x1200.bin sink_0::dcc-2a-file=/opt/imaging/ar0235/dcc_2a_10bit_1920x1200.bin format-msb=9 sink_0::ae-mode=2 ! video/x-raw, format=NV12, width=1920, height=1200, framerate=60/1 ! fakesink sync=false silent=false

您能帮助我们确定可能导致流式传输问题的组件吗？

此致、
Jay

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

    尊敬的 Jay：  

    远程内核（运行 VPAC/ISP 的 Mcu1_0 和运行深度学习加速的 C7x_1）的存储器映射或固件是否有任何变化？

    这些远程内核的每个内核堆的这种分割比我们在 SDK 中使用的要小得多、这是我首先要关注的问题 

    Yours:
[    0.000000] OF: reserved mem: 0x00000000adc00000..0x00000000b27fffff (77824 KiB) nomap non-reusable edgeai-core-heap-memory@adc00000


TI SDK: 
[    0.000000] OF: reserved mem: 0x00000000adc00000..0x00000000bfffffff (299008 KiB) nomap non-reusable edgeai-core-heap-memory@adc00000

    media-ctl、tiovxisp-pipeline、远程内核的日志看起来不错。 这是奇怪的,考虑到你的经验挂起.   

    对于 Yocto 构建、您是否从 11.1 基线开始并从那里添加自定义层？ 我很好奇,是否有一些建筑神器或冲突版本挂在过去。  

    当您的程序挂起时、我很好奇是否从 edgeai_shared-Memas（即 DDR_SHARED_MEM）分配了 DMA 缓冲区。 您`cat /sys/kernel/debug/dma_buf/bufinfo`并在该程序挂起时共享日志吗？

    BR、
    Reese

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

    尊敬的 Reese：

    感谢您的答复。

    这些远程内核的核心堆的这种分割比我们在 SDK 中使用的要小得多、这是我的第一个关注问题

    我们已经尝试使用与 SDK-11 EVM 304MiB 相同的“edgeai-core-heap"。“。 但在这方面、我们也有同样的问题。

    流挂起时、以下是文件“/sys/kernel/debug/dma_buf/bufinfo “的输出： 

    ~ # cat /sys/kernel/debug/dma_buf/bufinfo

Dma-buf Objects:
size            flags           mode            count           exp_name        ino             name
03457024        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000025        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

03457024        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000024        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00028672        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000023        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00004096        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000022        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00012288        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000018        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00057344        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000017        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00057344        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000016        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00036864        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000015        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00004096        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000014        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00004096        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000013        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00212992        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000012        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00004096        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000011        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00008192        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000010        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00016384        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000008        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

00004096        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000007        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

04608000        00000002        00080007        00000004        carveout_edgeai_shared-memories 00000006        <none>
        Attached Devices:
        4e230000.dma-controller
        remoteproc0
Total 2 devices attached

04608000        00000002        00080007        00000004        carveout_edgeai_shared-memories 00000005        <none>
        Attached Devices:
        4e230000.dma-controller
        remoteproc0
Total 2 devices attached

04608000        00000002        00080007        00000004        carveout_edgeai_shared-memories 00000004        <none>
        Attached Devices:
        4e230000.dma-controller
        remoteproc0
Total 2 devices attached

04608000        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000003        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

04608000        00000002        00080007        00000003        carveout_edgeai_shared-memories 00000002        <none>
        Attached Devices:
        remoteproc0
Total 1 devices attached

04608000        00000002        00080007        00000004        carveout_edgeai_shared-memories 00000001        <none>
        Attached Devices:
        4e230000.dma-controller
        remoteproc0
Total 2 devices attached


Total 21 objects, 35012608 bytes

    对于 Yocto 版本、您是否从 11.1 基准开始并从那里添加自定义层？ 我很好奇,是否有一些建筑神器或冲突版本挂在过去。  [/报价]

    是的、我们已经从 SDK-11 开始、并从 SDK-11 中添加了用于流式传输的最低软件包。  

    请告知我们所需的任何其他信息。

    此致、
    Jay

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

    尊敬的 Jay：

    bufinfo 日志看起来很好。 他们明确分配了所需的数据（在底层的 TIOVX 部分中发生）

    我们已经尝试使用与 SDK-11 EVM 304MiB 相同的“edgeai-core-heap"。“。 但在这方面、我们也有同样的问题。
    [/报价]

    因此、这意味着您已经使用默认存储器映射尝试了 Yocto 构建的相同流水线、但仍然会遇到相同的问题。

    在您过去的构建中、相同的管道是否起作用？ 11．1 SDK 版本？ 我正在尝试找出您所观察到的最小变化导致出现此问题。 我想知道与 v4l2 与 TIOVX 之间的接口相关的任何内容是否引发了问题、或者说总体 TIOVX 相关。

    • 我还没有看到指示 TIOVX 明显故障的日志、因此我预计 该接口附近会出现问题。  

    您能否与其他 TIOVX 插件（如 tiovxmultiscaler）运行示例流水线？ 您可以使用 videotestsrc 或从图像文件解码。   

    我还注意到、您有一个管道设置为以 30FPS 运行、另一个设置为以 60 运行。 可能是一个小细节、但值得确认、这不会影响此行为

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

    尊敬的 Reese：  

    因此、这意味着您已经使用默认存储器映射尝试了 Yocto 构建的相同流水线、但仍然会出现相同的问题？

    是、使用默认存储器映射时、仍会观察到问题。

    您以前的构建中是否使用了相同的管道？ 在库存 11.1 SDK 版本中？

    使用库存 11.01.07 SDK 版本时、流水线工作正常、没有任何问题。

    您能否使用其他 TIOVX 插件（如 tiovxmultiscaler）运行示例流水线？

    我们已经尝试使用多标量插件与  videotestsrc 并正常工作。 流水线如下所示： 

    gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1200 !  tiovxmultiscaler ! video/x-raw, format=NV12, width=640, height=380, framerate=30/1 ! fakesink

    同样、我们尝试了使用 videotestsrc 使用 tiovxisp 流水线、因此我们看到了相同的挂起问题。 流水线如下所示： 

    gst-launch-1.0 videotestsrc ! video/x-bayer,width=1920,height=1200, format=rggb ! tiovxisp sensor-name=SENSOR_SONY_IMX219_RPI dcc-isp-file=/opt/imaging/imx219/linear/dcc_viss_1920x1080.bin sink_0::dcc-2a-file=/opt/imaging/imx219/linear/dcc_2a_1920x1080.bin sink_0::device=/dev/v4l-subdev2 ! video/x-raw,format=NV12 ! fakesink

    我还注意到您有一个管道设置为以 30 FPS 运行、另一个设置为以 60 FPS 运行。 可能是一个小细节、但值得确认、这不会影响此行为

    是的、我们尝试了更改 fps (30fps 和 60fps)、但这种更改不起作用。

    我们在执行流水线时发现了一个问题。 每当我们运行流水线时、器件都会创建 4 个新的/dev/rpmsgX 字符器件、即使在停止流水线后、字符器件仍然存在。 因此、每次在板上执行流水线时创建 4 个新的/dev/rpmsgX 器件。  

    我们的构建设置：

    U-boot (tiboot3.bin、tispl.bin、u-boot.img)、Linux 内核 (linux-ti-staging-RT)、整个“/lib/firmware 二进制文件和“meta-edgeai"层“层来自 SDK-11、此协议没有变化。

    我们使用自定义 rootfs 软件包、而不是 SDK - 11 中的这些软件包。

    ----------------------------------------------------------------------------------------------------

    您能否为我们提供调试 ISP (tiovxisp) 的步骤？ 因此、我们可以检查流流水线可能中断的位置。

    此致、
    Jay

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

    这些信息很有用、谢谢 Jay。  

    多标量正在运行、这一事实告诉我 TIOVX 以及与运行 MSC（和 VISS (ISP) 的内核进行的总体通信... 和 LDC) 正在工作。 我想知道是否有任何 AEWB 或类似的传感器反馈可能无法正常工作。 dmesg 日志中没有活动、对吧？ 我在您最初发送的内容中没有看到任何内容、但日志看起来像是在您完成僵尸操作后关闭的。 您能否添加在启动应用程序/流水线时开始的 dmesg 日志？

    [引述 userid=“603086" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board/6209783


    我们的构建设置：

    U-boot (tiboot3.bin、tispl.bin、u-boot.img)、Linux 内核 (linux-ti-staging-RT)、整个“/lib/firmware 二进制文件和“meta-edgeai"层“层来自 SDK-11、此协议没有变化。

    [/报价]

    如果没有更改存储器映射、那么这应该没问题。 请确定您正在为 SDK 11.1 修改/lib/firmware 和其他更改。 不存在 11.0 或 11.2、因此这可能是一个莫须点。 是否从 SDK 中手动获取这些资源、或者是否在 Yocto 构建中执行这些操作？

    您能否为我们提供调试 ISP (tiovxisp) 的步骤？ 因此、我们可以检查流流水线可能中断的位置。
    [/报价]

    给我一两天时间来提供建议。 也许将 GST_DEBUG 设置为记录所有插件信息的流水线会提供信息、但我从 tiovxisp 中看不到很多信息来告诉这个问题。

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

    嗨、Jay、 感谢您提供这些日志。  

    我想知道问题是否与 2A DCC 相关（适用于自动曝光和自动白平衡，这需要反馈给传感器本身）。

    这与“Sink_0 ：：dcc-2a-file=/opt/imaging/imx219/linear/dcc_2a_1920x1080.bin Sink_0：：device=/dev/v4l-subdev2 的 tiovxisp Sink_0 提到的内容相关

    应保留 DCC-ISP-FILE 和 FORMAT-MSB 设置。  

    因此、请尝试删除这些 sink_0：：部分、让我们看看这是否与挂起问题有关。 如果这些子开发条目不存在/不起作用、则可能是导致挂起的原因

    [引述 userid=“603086" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board/6211091

    wave521c_k3_codec_fw.bin => JPEG 编码器固件

     am62a-C71_0-fw => C7x DSP 固件

    am62a-mcu-R5f0_0-fw => MCU R5F 固件（应用层）

    [/报价]

    这是正确的、尽管 MCU R5 固件用于附加 R5、而这个 R5 通常用作系统/安全监视器。 在视觉应用中不起作用的应用。  

    运行 ISP（和 VPAC）的 R5 称为 WKUP 或 DM R5、因为它管理整个处理器状态。 此固件作为引导加载程序的一部分加载、自 Linux 之前启动以来、关联的 Remoteproc 将显示为“attached"。“。  

    C71 文件将是指向您要更新的实际固件二进制文件的软链接。  

    [引述 userid=“603086" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board/6211091

    目前、我们正在从已构建库存 SDK-11.01.07 Yocto SDK 中手动获取它。 解决此问题后、我们将创建/添加必要的配方。 我猜我们使用了三个主要固件、它在构建时不会与其他封装相关联。 我的理解是否正确？  

    [/报价]

    正确、这些文件是独立的。 只有 C7x 应对存储器映射变化敏感。 同样、只要您对/usr/lib/libtivision_apps.so 和引导加载程序中存在的 DM-R5 固件 (tiboot3.bin) 使用默认存储器映射、使用默认值就没问题

    BR、

    Reese

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

    尊敬的 Reese：

    因此、请尝试删除这些 sink_0：：部分、让我们看看这是否与挂起问题有关。 如果这些子开发条目不存在/不起作用、则可能导致挂起

    我们尝试从属性中删除“sink0 ::“  dcc-2a-file 和  频率 ,但它无法识别属性。 还在流水线中添加了“FORMAT-MSB"属性“属性。 请检查以下日志： 

    gst-launch-1.0 videotestsrc ! video/x-bayer,width=1920,height=1200, format=rggb ! tiovxisp sensor-name=SENSOR_SONY_IMX219_RPI dcc-isp-file=/opt/imaging/imx219/linear/dcc_viss_1920x1080.bin dcc-2a-file=/opt/imaging/imx219/linear/dcc_2a_1920x1080.bin device=/dev/v4l-subdev2 format-msb=7 ! video/x-raw,format=NV12 ! fakesink
WARNING: erroneous pipeline: no property "dcc-2a-file" in element "tiovxisp"

    此外、尝试从流水线中删除整个属性“sink_0：：dcc-2a-file“和“sink_0：：device“、但这也不起作用。 请检查以下日志： 

    gst-launch-1.0 videotestsrc ! video/x-bayer,width=1920,height=1200, format=rggb ! tiovxisp sensor-name=SENSOR_SONY_IMX219_RPI dcc-isp-file=/opt/imaging/imx219/linear/dcc_viss_1920x1080.bin  format-msb=7 ! video/x-raw,format=NV12 ! fakesink
APP: Init ... !!!
 59634.762331 s: MEM: Init ... !!!
 59634.762392 s: MEM: Initialized DMA HEAP (fd=5) !!!
 59634.762525 s: MEM: Init ... Done !!!
 59634.762551 s: IPC: Init ... !!!
 59634.781672 s: IPC: Init ... Done !!!
REMOTE_SERVICE: Init ... !!!
REMOTE_SERVICE: Init ... Done !!!
 59634.786277 s: GTC Frequency = 200 MHz
APP: Init ... Done !!!
 59634.786428 s:  VX_ZONE_INFO: Globally Enabled VX_ZONE_ERROR
 59634.786450 s:  VX_ZONE_INFO: Globally Enabled VX_ZONE_WARNING
 59634.786524 s:  VX_ZONE_INFO: Globally Enabled VX_ZONE_INFO
 59634.787312 s:  VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-0
 59634.787524 s:  VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-1
 59634.787687 s:  VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-2
 59634.787821 s:  VX_ZONE_INFO: [tivxPlatformCreateTargetId:169] Added target MPU-3
 59634.787846 s:  VX_ZONE_INFO: [tivxInitLocal:202] Initialization Done !!!
 59634.787858 s:  VX_ZONE_INFO: Globally Disabled VX_ZONE_INFO
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstTIOVXISP:tiovxisp0: Unable to init TIOVX module
Additional debug info:
/usr/src/debug/edgeai-gst-plugins/1.0.0-r0_edgeai_0/gst-libs/gst/tiovx/gsttiovxmiso.c(1541): gst_tiovx_miso_negotiated_src_caps (): /GstPipeline:pipeline0/GstTIOVXISP:tiovxisp0
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
 59634.848594 s:  VX_ZONE_WARNING: [vxReleaseContext:1439] Found a reference 0xffff86200a90 of type 00000816 at external count 1, internal count 0, releasing it
 59634.848641 s:  VX_ZONE_WARNING: [vxReleaseContext:1441] Releasing reference (name=user_data_object_88) now as a part of garbage collection
 59634.848752 s:  VX_ZONE_WARNING: [vxReleaseContext:1439] Found a reference 0xffff86200cd8 of type 00000816 at external count 1, internal count 0, releasing it
 59634.848773 s:  VX_ZONE_WARNING: [vxReleaseContext:1441] Releasing reference (name=user_data_object_89) now as a part of garbage collection
 59634.848833 s:  VX_ZONE_WARNING: [vxReleaseContext:1439] Found a reference 0xffff862c5e98 of type 00000813 at external count 1, internal count 0, releasing it
 59634.848853 s:  VX_ZONE_WARNING: [vxReleaseContext:1441] Releasing reference (name=object_array_91) now as a part of garbage collection
 59634.848882 s:  VX_ZONE_WARNING: [vxReleaseContext:1439] Found a reference 0xffff86201168 of type 00000816 at external count 1, internal count 0, releasing it
 59634.848899 s:  VX_ZONE_WARNING: [vxReleaseContext:1441] Releasing reference (name=user_data_object_92) now as a part of garbage collection
 59634.848979 s:  VX_ZONE_WARNING: [vxReleaseContext:1439] Found a reference 0xffff862c6050 of type 00000813 at external count 1, internal count 0, releasing it
 59634.849002 s:  VX_ZONE_WARNING: [vxReleaseContext:1441] Releasing reference (name=object_array_93) now as a part of garbage collection
 59634.849029 s:  VX_ZONE_WARNING: [vxReleaseContext:1439] Found a reference 0xffff8620f050 of type 00000817 at external count 1, internal count 0, releasing it
 59634.849046 s:  VX_ZONE_WARNING: [vxReleaseContext:1441] Releasing reference (name=raw_image_94) now as a part of garbage collection
 59634.849077 s:  VX_ZONE_WARNING: [vxReleaseContext:1439] Found a reference 0xffff862c6208 of type 00000813 at external count 1, internal count 0, releasing it
 59634.849102 s:  VX_ZONE_WARNING: [vxReleaseContext:1441] Releasing reference (name=object_array_95) now as a part of garbage collection
 59634.849127 s:  VX_ZONE_WARNING: [vxReleaseContext:1439] Found a reference 0xffff862013b0 of type 00000816 at external count 1, internal count 0, releasing it
 59634.849143 s:  VX_ZONE_WARNING: [vxReleaseContext:1441] Releasing reference (name=user_data_object_96) now as a part of garbage collection
 59634.849168 s:  VX_ZONE_WARNING: [vxReleaseContext:1439] Found a reference 0xffff862c63c0 of type 00000813 at external count 1, internal count 0, releasing it
 59634.849184 s:  VX_ZONE_WARNING: [vxReleaseContext:1441] Releasing reference (name=object_array_97) now as a part of garbage collection
 59634.849209 s:  VX_ZONE_WARNING: [vxReleaseContext:1439] Found a reference 0xffff862355e8 of type 0000080f at external count 1, internal count 0, releasing it
 59634.849226 s:  VX_ZONE_WARNING: [vxReleaseContext:1441] Releasing reference (name=image_98) now as a part of garbage collection
APP: Deinit ... !!!
REMOTE_SERVICE: Deinit ... !!!
REMOTE_SERVICE: Deinit ... Done !!!
 59634.854514 s: IPC: Deinit ... !!!
 59634.855152 s: IPC: DeInit ... Done !!!
 59634.855202 s: MEM: Deinit ... !!!
 59634.855212 s: DDR_SHARED_MEM: Alloc's: 5 alloc's of 4625477 bytes
 59634.855223 s: DDR_SHARED_MEM: Free's : 5 free's  of 4625477 bytes
 59634.855232 s: DDR_SHARED_MEM: Open's : 0 allocs  of 0 bytes
 59634.855246 s: MEM: Deinit ... Done !!!
APP: Deinit ... Done !!!

    每当我们运行流水线时、电路板都会创建 4 个新的/dev/rpmsgX 字符设备节点、即使在停止流水线后、字符设备仍然存在（rpmsg 端点没有正确关闭、并且每次都创建新的 4 个节点）。 根据我们的研究结果、这些节点用于 R5F 内核 A53 内核之间的通信。 它可能有任何问题吗？


    此致、
    Jay

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

    尊敬的 Jay：

    嗯、移除 AEWB/2A 部分不会更改、然后。   

    [引述 userid=“603086" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board/6213122

    此外、尝试从流水线中删除整个属性“sink_0：：dcc-2a-file“和“sink_0：：device“、但这也不起作用。 请检查以下日志：

    [/报价]

    是的,这就是我的评论的意图。  

    只是无法初始化该插件。 当您运行此流水线时、/opt/vx_app_arm_remote_log.out 中是否有任何活动？ 在您过去的打印输出中、我没有看到以下内容 

    ERROR: from element /GstPipeline:pipeline0/GstTIOVXISP:tiovxisp0: Unable to init TIOVX module

    我不确定这是否与缺少来自前一个节点的缓冲池/dma-import 有关。 您还可能会使用来自 IMX219 的 1920x1200 输入和 1920x1080 DCC 文件

    每当我们运行流水线时、Board 会创建 4 个新的/dev/rpmsgX 字符设备节点、即使在停止流水线后、字符设备仍然存在（rpmsg 端点没有正确关闭、每次都创建新的 4 个节点）。 根据我们的研究结果、这些节点用于 R5F 内核 A53 内核之间的通信。 它是否有任何问题？

    我的直觉是、这是问题的症状、而不是原因。 当您停止管道时、这些 RPMSG 接口可能不会被取消初始化、并且它们会挂起。 tiovxmultiscaler 节点正常工作这一事实证明与该内核的一般通信正常工作。  

    我们需要更深入地探究、以找出原因。  

    我们来尝试对处理所有 IPC 到 R5F 内核的 TIOVX 进行这些诊断。 请与我分享每个打印输出。  

    cd /opt/vision_apps

source ./vision_apps_init.sh # set some env variables and run TIOVX logger in the background

./vx_app_heap_stats.out #print all the heap allocations for remote cores

./vx_app_arm_ipc.out # test IPC to the remote cores, including basic memory allocation and a timer test

././vx_app_arm_mem.out # test memory allocation into the DDR_SHARED_MEM region. I expect this one is not the problem

    • 请参阅[1]了解另一个 VISS 基本测试、我们可以使用该测试来阐明此处哪个层发生故障。  

    我应该在前面提出一个问题 :在您的编译中,您是使用 edgeai-app-stack 的库/编译,还是自己重建组件? 如果您确实进行了重建、是否可以确认执行此操作时所使用的存储库版本/发行标签？ 我假设这是通过 Yocto 实现的、但如果我弄错了、请进行更正。

    [1] https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j722s/latest/exports/docs/vision_apps/docs/user_guide/group_apps_utilities_app_thermal_load_viss.html 

    BR、
    Reese

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

    尊敬的 Jay：

    这有助于缩小距离。 感谢您运行这些诊断程序。 问题似乎更接近 IPC  

    您在运行这些基本 RPMsg 测试时是否看到类似的行为？ 

    rpmsg_char_simple  -r 15 -n 10
rpmsg_char_simple  -r 8 -n 10
rpmsg_char_simple  -r 0 -n 10

    • 可能与线程[1]相关、但该线程用于修改存储器映射。
      • 您指出存储器映射完全不变、这意味着 C7x、R5F 和设备树采用了默认/usr/lib/libtivision_apps.so 和固件。 请确认、因为我怀疑问题与此更接近。  
    edgeai-app-stack libraries

    您这边更新了哪些库？ edgeai-app-stack 中的任何内容都不应导致会使 IPC 中断的更改

    当我们在设备上运行命令时、它会在下面打印后卡住。 但在具有库存 SDK 的 EVM 上、它会在几秒钟后成功退出。
    [/报价]

    这`s您已提取/opt/vision_apps 下的 test_data (SecureResources firmware-builder 文件上的 tarball) 并获取 vision_apps_init.sh 脚本（` source<eps> 很重要、因为脚本将设置一些 ENV 变量）。  

    [1]  AM62A7-Q1：[AM62A]自定义存储器映射问题：调整 shared_memory 和 c7x 存储器时算法失败  

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

    尊敬的 Reese：

    感谢您的答复。

    [报价 userid=“360457" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board/6216364

    您在运行这些基本 RPMsg 测试时是否看到类似的行为？

    全屏
    [/报价]

    在基本 rpmsg 命令之上使用时、我们看不到错误。 命令运行成功。 请参阅以下输出： 

    ~ # rpmsg_char_simple  -r 15 -n 10
Created endpt device rpmsg-char-15-960, fd = 3 port = 1026
Exchanging 10 messages with rpmsg device rpmsg-char-15-960 on rproc id 15 ...

Sending message #0: hello there 0!
Received message #0: round trip delay(usecs) = 96790
hello there 0!
Sending message #1: hello there 1!
Received message #1: round trip delay(usecs) = 107235
hello there 1!
Sending message #2: hello there 2!
Received message #2: round trip delay(usecs) = 71395
hello there 2!
Sending message #3: hello there 3!
Received message #3: round trip delay(usecs) = 69810
hello there 3!
Sending message #4: hello there 4!
Received message #4: round trip delay(usecs) = 69690
hello there 4!
Sending message #5: hello there 5!
Received message #5: round trip delay(usecs) = 68230
hello there 5!
Sending message #6: hello there 6!
Received message #6: round trip delay(usecs) = 71770
hello there 6!
Sending message #7: hello there 7!
Received message #7: round trip delay(usecs) = 89275
hello there 7!
Sending message #8: hello there 8!
Received message #8: round trip delay(usecs) = 71500
hello there 8!
Sending message #9: hello there 9!
Received message #9: round trip delay(usecs) = 115685
hello there 9!

Communicated 10 messages successfully on rpmsg-char-15-960

TEST STATUS: PASSED
~ #
~ #
~ #
~ # rpmsg_char_simple  -r 8 -n 10
Created endpt device rpmsg-char-8-962, fd = 3 port = 1026
Exchanging 10 messages with rpmsg device rpmsg-char-8-962 on rproc id 8 ...

Sending message #0: hello there 0!
Received message #0: round trip delay(usecs) = 124380
hello there 0!
Sending message #1: hello there 1!
Received message #1: round trip delay(usecs) = 84725
hello there 1!
Sending message #2: hello there 2!
Received message #2: round trip delay(usecs) = 88505
hello there 2!
Sending message #3: hello there 3!
Received message #3: round trip delay(usecs) = 91330
hello there 3!
Sending message #4: hello there 4!
Received message #4: round trip delay(usecs) = 83090
hello there 4!
Sending message #5: hello there 5!
Received message #5: round trip delay(usecs) = 83795
hello there 5!
Sending message #6: hello there 6!
Received message #6: round trip delay(usecs) = 118955
hello there 6!
Sending message #7: hello there 7!
Received message #7: round trip delay(usecs) = 83635
hello there 7!
Sending message #8: hello there 8!
Received message #8: round trip delay(usecs) = 79165
hello there 8!
Sending message #9: hello there 9!
Received message #9: round trip delay(usecs) = 84120
hello there 9!

Communicated 10 messages successfully on rpmsg-char-8-962

TEST STATUS: PASSED
~ #
~ #
~ #
~ #
~ #
~ # rpmsg_char_simple  -r 0 -n 10
Created endpt device rpmsg-char-0-971, fd = 3 port = 1028
Exchanging 10 messages with rpmsg device rpmsg-char-0-971 on rproc id 0 ...

Sending message #0: hello there 0!
Received message #0: round trip delay(usecs) = 111235
h
Sending message #1: hello there 1!
Received message #1: round trip delay(usecs) = 130860
h
Sending message #2: hello there 2!
Received message #2: round trip delay(usecs) = 84940
h
Sending message #3: hello there 3!
Received message #3: round trip delay(usecs) = 83760
h
Sending message #4: hello there 4!
Received message #4: round trip delay(usecs) = 129615
h
Sending message #5: hello there 5!
Received message #5: round trip delay(usecs) = 86450
h
Sending message #6: hello there 6!
Received message #6: round trip delay(usecs) = 81900
h
Sending message #7: hello there 7!
Received message #7: round trip delay(usecs) = 77365
h
Sending message #8: hello there 8!
Received message #8: round trip delay(usecs) = 80340
h
Sending message #9: hello there 9!
Received message #9: round trip delay(usecs) = 83515
h

Communicated 10 messages successfully on rpmsg-char-0-971

TEST STATUS: PASSED

    可能是相关的线程[1]、但这用于修改存储器映射。
    • 您指出存储器映射完全不变、这意味着 C7x、R5F 和设备树采用了默认/usr/lib/libtivision_apps.so 和固件。 请确认、因为我怀疑问题与此更接近。  
    [/报价]

    我们使用 1GB RAM 而不是 4GB RAM。 因此、我们必须修改 2 个存储器区域： 1 ) edgeai_core_堆 2) Linux、CMA 。  
    但是、如果我们使用 SDK-11 中的 rootfs、使用这个修改后的区域时、流式传输效果很好。 因此、我们认为修改存储器区域大小不应该是问题。 以下是从我们的 DTS 文件中更改的保留存储器映射： 

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

        /* global cma region */
        linux,cma {
            compatible = "shared-dma-pool";
            reusable;
            size = <0x00 0xc800000>;
            alloc-ranges = <0x00 0xb2800000 0x00 0xc800000>;
            linux,cma-default;
        };

        c7x_0_dma_memory_region: c7x-dma-memory@99800000 {
            compatible = "shared-dma-pool";
            reg = <0x00 0x99800000 0x00 0x100000>;
            no-map;
        };

        c7x_0_memory_region: c7x-memory@99900000 {
            compatible = "shared-dma-pool";
            reg = <0x00 0x99900000 0x00 0xf00000>;
            no-map;
        };

        mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@9b800000 {
            compatible = "shared-dma-pool";
            reg = <0x00 0x9b800000 0x00 0x100000>;
            no-map;
        };

        mcu_r5fss0_core0_memory_region: r5f-dma-memory@9b900000 {
            compatible = "shared-dma-pool";
            reg = <0x00 0x9b900000 0x00 0xf00000>;
            no-map;
        };

        wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9c800000 {
            compatible = "shared-dma-pool";
            reg = <0x00 0x9c800000 0x00 0x100000>;
            no-map;
        };

        wkup_r5fss0_core0_memory_region: r5f-dma-memory@9c900000 {
            compatible = "shared-dma-pool";
            reg = <0x00 0x9c900000 0x00 0x1e00000>;
            no-map;
        };

        secure_tfa_ddr: tfa@9e780000 {
            reg = <0x00 0x9e780000 0x00 0x80000>;
            alignment = <0x1000>;
            no-map;
        };

        secure_ddr: optee@9e800000 {
            reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */
            alignment = <0x1000>;
            no-map;
        };

        rtos_ipc_memory_region: ipc-memories@a0000000 {
            compatible = "shared-dma-pool";
            reg = <0x00 0xa0000000 0x00 0x01000000>;
            no-map;
        };
    };


/* k3-am62a7-sk-edgeai.dtso change */
&{/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;
    };
};

    您这边更新了哪些库？ edgeai-app-stack 中的任何内容都不应导致会使 IPC
    中断的更改

    大多数基础 Linux 的库都已更改（除了 edgeai-app-stack 之外）。 以下是可能影响流式传输的几个软件包名称：

    systemd、glibc、glib-2.0、base-files、gstreamer、1.0 及其插件、busybox、ffmpeg、v4l2-utils、util-linux 等

    软件包 “ti-librpmsg-dma"在“在流式传输问题中是否可以发挥任何作用？

    我们可以通过调用来远程调试这个问题吗？

    此致、

    Jay

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

    尊敬的 Jay：

    [引述 userid=“603086" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board/6217502

    在基本 rpmsg 命令之上使用时、我们看不到错误。 命令运行成功。 请参阅以下输出：

    [/报价]

    你是对的；这里没有问题。 可能仍然与存储器映射有某种关系、但对于基本 IPC 可能没有关系、因为根据您的 DTS、这些区域未被更改。

    我们使用的是 1GB RAM、而不是 4GB RAM。 因此、我们必须修改 2 个存储器区域： 1 ) edgeai_core_堆 2) Linux、CMA 。  
    但是、如果我们使用 SDK-11 中的 rootfs、使用这个修改后的区域时、流式传输效果很好。 因此、我们认为修改存储器区域大小不应该是问题。 [/报价]

    我  在这里几乎是一致的、但让我在存储器映射中谈谈以下内容：  

    您是否在不更改固件或 libtivision_apps.so 的情况下修改了 DTS 中的这些内容？ Linux-CMA 只能从 DTS 修改、但核心堆不仅应该是 DTS 修改。

    我可以看到这对于一个简单的应用程序 (v4l2->isp->fakesink) 是如何工作的--这些核心堆的默认 DDR 映射由您所展示的 DTS 涵盖的。 Linux 不涉及内核堆、但 R5/VPAC 固件和 C7x 固件将涉及内核堆。 Linux 不需要接触该存储器、远程内核只需要该物理存储器即可存在。 C7x 存储器位于整个分割区的较高侧、  

    从 0xb280 0000 启动 CMA 可能会与 C7x 堆冲突。 在 TIOVX 日志中、请参阅：

    [C7x_1 ]  1233.354769 s：MEM：创建的堆 (DDR_LOCAL_MEM、id=0、flags=0x00000004)@ b2000000、大小为 117440512 字节！！

    该堆大小（以及未在日志中打印的 DDR_C7X_1_scratch） 将与启动 0xb280 0000 的 CMA 池冲突。 我不确定这是否与手头的问题有关、 在 TIDL / AI 模型加载到 C7 之前、堆只会有少量分配。 默认情况下有一些分配、可能存在冲突。 我不确定 CMA 是否会为您显示的管道分配任何分配。  

    编辑：Gstreamer 可能正在使用 CMA 池进行部分分配。 您能否在挂起之前和之后检查`cat /proc/meminfo | grep -i CMA`的输出? 这一地区的冲突是相关的。 不过、您仍然会说 rootfs 和 Yocto 构建在同一流水线上具有不同的行为、即使对于相同的 DTS ...

    更有意义的是、您说相同的 DTS 存储器映射适用于 rootfs... 虽然上述评论是相关的,但它们可能是切变的,更重要的以后。

    [引述 userid=“603086" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board/6217502

    大多数基础 Linux 的库都已更改（除了 edgeai-app-stack 之外）。 以下是可能影响流式传输的几个软件包名称：

    systemd、glibc、glib-2.0、base-files、gstreamer、1.0 及其插件、busybox、ffmpeg、v4l2-utils、util-linux 等

    [/报价]

    最好将 Yocto 构建中的其中一些库替换为 SDK 构建中的库、从最接近 gstreamer 和 v4l2 的库开始（因此 v4l2 utils、gstreamer 1.0、插件（从 TI 插件开始）。 我可能需要在这里提供一些额外的帮助 — 我对 Yocto 的了解较少。

    [引述 userid=“603086" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board/6217502

    软件包 “ti-librpmsg-dma"在“在流式传输问题中是否可以发挥任何作用？

    [/报价]

    值得调查、是的。 我建议也更换该元件

    [引述 userid=“603086" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board/6217502

    我们可以通过调用来远程调试这个问题吗？

    [/报价]

    现在让我们使用上述方法，我们可以安排电话来深入了解细节 — 我认为下周需要。 让我找出另一位能在我的知识差距所在处提供帮助的工程师。 我更习惯了内存映射、TIOVX 本身和远程内核构建系统... Yocto 等

    BR、
    Reese

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

    尊敬的 Jay：

    感谢您的持续努力和耐心。 我想我们现在可以排除 CMA 作为根本原因。 在 DTS 中、我可以使用一般存储器映射。  

    • 11.1 中的一项更改是用于 DDR_DM_R5F_VISS_CONFIG_HEAP 的额外 DDR 分割/堆、但这一更改似乎会在您的系统中得到考虑。 我看到 vx_app_heap_stats.out 实用程序的第二个堆条目、以及 DTS 中内核堆的启动也反映了该堆（几个堆中的第一个）开始的位置

    由于您使用默认的 tiboot3.bin（其中包含管理 ISP 的 R5 固件）、该内核上的存储器映射也应该正确。 为了进行公平比较、我想确保二进制文件（以及引导分区的其他部分）与 TI 11.1 SDK 中的相同。 然后、我们可以排除固件中的任何差异、并仅关注 Linux/Yocto

    有趣的是、VISS / ISP 会失败、但多标量/ MSC 不能...

    此外、我们还检查了“ti-librpmsg-dma

    好的、我们也可以超越这个范围。

    现在有两个获取更多信息的请求：  

    您`运行 T Ü V GST-CHECK-1.0 tiovxisp`并将输出报告给我吗？ 我想将其与 SDK 的打印输出进行完全比较

    您能否提供修改后的 Yocto 层或其他相关配方？ 请告知这是 meta-edgeai 的编辑版本还是完全自定义的版本

    我认为运行 TIOVX 一致性测试也是值得的、尤其是对于 /opt/vision_apps/vx_app_conformance_hwa.out. 在运行一致性之前、您需要提取测试数据集并获取 vision_apps_init.sh。  

    ./vx_app_conformance_hwa.out --filter=*VISS*

    我们还可以将 VISS 替换为“MSC"或“或“LDC"，“，以、以测试同一内核上的其他相关加速器

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

    尊敬的 Jay：  

    我将对您提供的内容进行一些分析、并在明天或下周初回来。  

    在一致性测试中、我看到多次通过测试、但通常失败是由于缺少输入文件所致。 这些是否存在于/opt/vision_apps/test_data 下的文件词干中、例如/opt/vision_apps/test_data/output/viss_out.yuv？  

    数据集已保存在我的安全文件中（以及 TI 的 CGIT 中的存储库）、但为了方便起见、我还将附加到此线程。

    e2e.ti.com/.../psdk_5F00_rtos_5F00_ti_5F00_data_5F00_set_5F00_11_5F00_01_5F00_00.tar.gz

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

    尊敬的 Jay：

    我在 tiovxisp gst-check 中看不到提示我解决问题的任何内容。 这似乎很好...

    [引述 userid=“603086" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1610088/am62a7-streaming-issue-using-sdk-11-component-for-custom-board/6221380

    我使用 VISS、MSC 和 LDC 进行了符合性测试。 以下是相同的日志。

    comformance_test_VISS.txt

    conformance_test_log_LDC.txt

    conformance_test_log_MSC.txt

    如果有任何其他形式的信息、请告知我们

    [/报价]

    我不是很担心 MSC 或 LDC（未经过测试，但应该与 MSC 一样）、MORESOO VISS。 大多数测试用例需要测试数据、但至少最简单的测试不需要文件 IO、因此行为正常（第一次测试和 NegativeGraph 测试）。 也可能存在测试数据、但未设置正确的 ENV 变量。  

    $ source /opt/vision_apps/vision_apps_init.sh
$ env | grep DATA
TIAP_DATABASE_PATH=/opt/vision_apps/test_data_ptk
VX_TEST_DATA_PATH=/opt/vision_apps/test_data

    您使用的 gstreamer 版本是多少？ 我建议使用您的构建创建一个图像、但将所有 gstreamer 库替换为 SDK rootfs 版本。 您可以从替换 TI 库/usr/lib/gstreamer-1.0/libgsttiovx.so（和 libgstti.so）开始、但非 tiovx 插件不是问题所在）

    我想以更高的调试级别查看 GST-launch-1.0 的一些日志记录、例如 6=log、应该会显示每帧日志记录。 您可以运行如下所示的操作吗？ 让我们限制为仅几个帧；它可能会在您的系统中之前挂起。  

    GST_DEBUG=2,*tiovx*:6 gst-launch-1.0 videotestsrc num-buffers=10 ! \
video/x-bayer,width=1920,height=1200, format=rggb ! \
tiovxisp sensor-name=SENSOR_SONY_IMX219_RPI dcc-isp-file=/opt/imaging/imx219/linear/dcc_viss_1920x1080.bin sink_0::dcc-2a-file=/opt/imaging/imx219/linear/dcc_2a_1920x1080.bin sink_0::device=/dev/v4l-subdev2 format-msb=7 ! \
video/x-raw,format=NV12 ! fakesink
    尽管不是 v4l2src、并且类似地、使用 tiovxisp 的 dma-bufs 输入、我假设您在系统中看到了此错误行为

    BR、
    Reese

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

    尊敬的 Reese：

    感谢您就此问题提供支持。  

    我们找到了在流式流水线中使用 tiovxisp 插件时导致问题的根本原因。 

    ---
 src/tiovx_viss_module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/tiovx_viss_module.c b/src/tiovx_viss_module.c
index acd5636..dd84e20 100644
--- a/src/tiovx_viss_module.c
+++ b/src/tiovx_viss_module.c
@@ -71,7 +71,7 @@ static vx_status tiovx_viss_module_configure_params(vx_context context, TIOVXVIS

     obj->params.sensor_dcc_id       = sensorObj->sensorParams.dccId;
     obj->params.use_case            = 0;
-    obj->params.fcp[0].ee_mode      = TIVX_VPAC_VISS_EE_MODE_OFF;
+    obj->params.fcp[0].ee_mode      = TIVX_VPAC_VISS_EE_MODE_Y8;
     obj->params.fcp[0].chroma_mode  = TIVX_VPAC_VISS_CHROMA_MODE_420;

     if(obj->output_select[0] == TIOVX_VISS_MODULE_OUTPUT_EN)
--
2.34.1

    在 edgeai-tiovx-modules 封装中、我们启用了边缘增强功能、该功能与 SDK-9 和 SKD-10 配合使用非常正常。 但这不能用于 SDK-11。 上述变化导致流水线卡住。  

    删除此项后、流水线工作正常。 我们将检查是否检查 SDK-11 中的边缘增强功能。 但流水线与 tiovxisp 插件正常工作。  

    再次感谢您对此主题的支持。

    此致、

    Jay  

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

    尊敬的 Jay：

    很高兴您发现了这个问题。 好的工作；这是一个艰难的工作。

    此更改是否是您自己实施的补丁、或者上述补丁是否解决了默认 Yocto 源中的问题？ 我在默认分支中看不到、因此我想您已经添加到您的一侧。

    tiovxisp 还有一个“ee 模式“设置、该设置将通过 gstreamer 插件参数公开该设置。  

    BR、
    Reese

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

    是的、GStreamer 插件“tiovxisp"支持“支持在 SDK 11.1 中将 ee 模式更改为 Y8： 

    root@am62axx-evm:/opt/edgeai-gst-apps# gst-inspect-1.0 tiovxisp
...
...
  ee-mode             : Flag to set Edge Enhancement mode.
                        flags: readable, writable, controllable, changeable only in NULL or READY state
                        Enum "GstTIOVXISPEEModes" Default: 0, "EE_MODE_OFF"
                           (0): EE_MODE_OFF      - EE mode off
                           (1): EE_MODE_Y12      - Edge Enhancer is enabled on Y12 output (output0)
                           (2): EE_MODE_Y8       - Edge Enhancer is enabled on Y8 output (output2)

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

    尊敬的 Reese：  

    当我们在 SDK9 和 SDK10 中添加此补丁时、我们已经在我们这边添加了此补丁。 但正如建中提到的、SDK11 在默认情况下具有这种支持。

    此致、

    Jay