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.

[参考译文] AM67A:如果定期打开/关闭 V4L 流式传输、e5010 会导致高 SoC 负载下的 JPEG 图像损坏和阻尼 JPEG 图像

Guru**** 2836540 points

Other Parts Discussed in Thread: AM67A

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1629525/am67a-e5010-causes-corrupted-jpeg-images-under-high-soc-load-and-damped-jpegs-if-v4l-streaming-is-switched-on-off-periodically

器件型号: AM67A

你好

到目前为止、我们使用了 e5010 jpeg 编码器和 debian 12 Linux sysem。 在切换到基于 Debian 13 的操作系统后、我们观察到、如果 AM67A 处理器在整体高负载级别 (GPU + CPU + e5010) 下运行、则会生成损坏的 JPEG 图像。 在密集测试之后、似乎是由内存管理系统(负责 mmap 内存区域)的竞争条件导致图像损坏的原因。 我们不确定提供的 NV12 编码输入数据是否未正确传递到 e5010 内核模块、或者生成的 JPEG 二进制数据在执行 select (FD + 1、&read_FDS、...) 后是否与用户空间中的 mmap 内存不同步。 在使用 debian 12 时,我们没有得到完全相同工作负载的损坏图像。

我们设法找到了一种解决方法,至少为我们提供了技术上正确的 JPEG 图像。 我们通过在每次选择呼叫之前为 V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE 和 V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE 执行 VIDIOC_STREAMON、然后在涉及的 V4L 缓冲区出队后执行 VIDIOC_STREAMOFF 来实现这一点。 但是、使用 e5010 这样会导致创建具有整体阻尼强度水平的 JPEG 图像。 请查看随附的说明问题的示例图像。 我们可以做些什么来消除这个问题吗?

此外、我们希望切换回之前的 V4L 呼叫序列 (stream-start -> queue -> Dequeue ->...-> queue -> Dequeue -> Stream-stop)、而不是启动和停止每个 e5010 编码的流、因为这会增加整个过程的延迟。 是否可以修复竞态条件错误?

此致

Richard Arndt

00_grayscale_input_image.png01_grayscale_jpeg_image_with_damped_intensity.png02_colored_jpeg_image_with_damped_intensity.png

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

    尊敬的 Richard:

    您能给我指一下您正在尝试验证的 SDK、以便我在我这边复制这个问题吗?

    是否还会看到 Yocto 生成的默认映像存在问题。

    https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-NQjfZVt1aJ/11.00.00.08/tisdk-edgeai-image-j722s-evm.wic.xz

    此致

    Suren

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

    您好、Richard

    https://www.beagleboard.org/distros/beagley-ai-debian-13-2-2025年11月25日 image-xfce-v6-1-x-ti 您正在验证此映像吗?

    此致

    Suren

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

    您好、Suren、

    我们构建自己的基于 Debian 的自定义映像。

    我们依赖于 TI 内核树 (ti-linux-kernel - ti-linux-6.12.y)、通过主要禁用未使用的驱动程序、当然还为定制电路板添加 dts 文件、略微修改了正常的 TI 内核配置 (ti_arm64_prune.config)。

    最初,我们认为这个问题会连接到 Debian 和它的用户空间应用程序,因为像 v4l-utils 这样的软件包及其库的版本变化较大 (1.22.x-->1.1.1.30)。
    我们认为这可能会与内核驱动程序结合产生问题。

    深入探究后、我们认为此问题可能与 JPEG 内核驱动程序有关。

    在以前的(稳定)系统中、我们依赖于标记为的内核状态 11.01.03. (基于 v6.12.33)、现在我们依赖于标记为的状态 11.02.11. (基于 v6.12.57)。
    在这两个版本之间,e5010 驱动程序发生了重大变化,似乎影响了内存管理 — 最明显的是在以下两个提交:
     

    [ee7431636c6265d0eb341033ab95e3448f8e9dDA](https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/media/platform/imagination?h=ti-linux-6.12.y&id=ee7431636c6265d0eb341033ab95e3448f8e9dda)
    [da1f9930da34da8756b0d69d43c51df984a30b0f](https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/media/platform/imagination?h=ti-linux-6.12.y&id=da1f9930da34da8756b0d69d43c51df984a30b0f)

    特别是第二次提交中的以下句子吸引了我们的注意:“从 VIDEOBUF2_DMA_CONTIG 切换到 VIDEOBUF2_DMA_SG 以支持散聚内存“

    我们考虑切换到 ti-linux-6.18.y、但它似乎尚未准备就绪或正式发布。

    我希望这些信息有助于缩小原因范围。

    此致

    Martin Hoehn 和 Richard Arndt

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

    尊敬的 Richard:

    我将在内部与我的软件开发团队讨论此问题。 请允许我几天回来。 如果您在下周初未收到回复、请向我发送 ping。

    此致

    Suren

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

    尊敬的 Richard:

    从当前设置恢复这些提交是否可以解决问题?

    此致

    Suren

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

    您好、Suren、

    我们现在已经进行了一项测试、其中我们恢复了以下三次提交、所有这些都是在检测到问题之前完成的。

    恢复“待定:介质:Imagination:e5010:将基础架构添加到支持 MMU “
    这将恢复提交 ee7431636c6265d0eb341033ab95e3448f8e9dda。

     

    恢复“media:Imagination:e5010:启用 MMU 支持“    
    这将恢复提交 da1f9930da34da8756b0d69d43c51df984a30b0f。

     

    恢复“待处理:介质:想象:e5010:确保在 init_device 期间开机“
    这将返回提交 42accb71d4a289a1dc332e55512a212e2fdf5a93。

     

    这样、问题似乎已解决。

    现在,我们可以恢复这些提交,但从长远来看,如果你也可以检查这一点,会很好。

    我假设您已停止处理 ti-linux-6.12.y 分支并正在准备基于 ti-linux-6.18.y 的版本
    这是正确的吗? 如果是、是否有这方面的时间表?

    此致

    Martin Hoehn 和 Richard Arndt