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.

AM335x SGX CPU Locks

Other Parts Discussed in Thread: AM3354

We started working with EZSDK 8 and the 3.14.26 Kernel.  We are using TI's RFS for our custom board using AM3354, including SGX drivers.

We are also using Qt 5.1.0 with Qt-GStreamer package.  When streaming video from USB UVC sticks thorugh Qt-GStreamer, we often get high CPU usage from the Qt application, and eventually a near system freeze (console is extremely slow...sometimes it's possible to kill the application).

We did not have any trouble with this setup using the EZSDK 6 (3.2 Kernel and SGX 04.09.00.01 release).  Could this be related to any changes in the graphics SDK or Kernel?

I'm not sure how to localize the issue to Qt, Qt-GStreamer, or SGX.

  • Have you checked the both QT versions from both SDKs (SDK6 and SDK8) ?
    Same or different.
    Also please check the release notes of both SDK versions.
  • Hello,

    Thanks for your reply.

    We are not using Qt 4.x since it does not well support the SGX usage. All Qt 4 rendering, except explicit OpenGL widget containers, are still rendered 2D in the backend, so animations and graphical effects are extremely slow compared to Qt 5.

    However, I believe we've narrowed down the issue to Kernel and/or gstreamer. I can start a uvcvideo stream from a hub-connected video source, and after about 30 seconds the stream gets very slow. I see high CPU usage in gst-launch and in kernel softirqs. In this case, we are 100% software rendering to the framebuffer, so I don't think the issue is necessarily related to SGX.

    Please note, we have seen issues with softirqs going high cpu usage in multiple cases with the 3.14 kernel. Do you know of a way to prevent/reduce these? I've seen various posts regarding DCAN and CPSW, though I haven't seen clear fixes (the Ethernet one suggested turning off debug options, but we already had those options turned off).