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.

HDVPSS firmware debug

Hi, we are working on a dm8168 custom designed board , trying to capture an HD stream sent from a FPGA using OMX and EZSDK 5.04.00.11. All signals looks good, pinmux has been properly configures but I still doesn't get any "fillbufferdone" call back. Is there a way to make sure the HDVPSS is properly configuring the capture hardware and see if interrupts are generated ? 

I would imagine two ways to do that, either there is an arguments that can be passed when loading the hdvpss firmware to activate some kind of detailed log, or I need the source code of the firmware itself to trace it...

Can someone help me with that ?

  • Hello,

    Please have a look on these documents:

    ti-ezsdk_dm816x-evm_5_04_00_11/board-support/docs/TI81XX_Video_Capture_Driver_User_Guide.pdf and TI81XX_VPSS_Video_Driver_User_Guide.pdf

    Following example shows how to enable debug of V4L2:

    $ insmod ti81xxvin.ko debug=1

    The HDVPSS firmware source code is not delivered with the EZSDK, it has only HDVPSS binary. Please contact your local FAE for how to obtain the HDVPSS firmware source code.

    Regards,

    Pavel

  • Thanks for the answer. As I told in my first post, I'm working with omx capture so ti81xxvin.ko is not running. I did discovered and used the following mechanism: 

    http://processors.wiki.ti.com/index.php/OMX_Viewing_Media_Controller_Traces

    I have been able to get the capture running but for a reason that I ignore It seems to be limited to 288 lines of video. I'm doing 16-bit embedded sync capture directly, without tvp. Do I need a dummy tvp omx module to overcome the 288 lines limit ? To do so, do I need hsvpss firmware code ?

    P-O

  • Is it because its in interlaced mode? 288 -> 576/2. I'm just guessing.

  • It sure looks like that but the input signal is 1080p60 progressive signal and has been validated... Also the capture component has been configured correctly:

    OMX_INIT_PARAM (&paramPort);
    paramPort.nPortIndex = OMX_VFCC_OUTPUT_PORT_START_INDEX;

    paramPort.format.video.nFrameWidth = 1920*2;
    paramPort.format.video.nFrameHeight = 1080;
    paramPort.format.video.nStride = 1920*2;
    paramPort.nBufferCountActual = 5;
    paramPort.format.video.eCompressionFormat = OMX_VIDEO_CodingUnused;
    paramPort.format.video.eColorFormat = /*OMX_COLOR_FormatYUV420SemiPlanar*/ OMX_COLOR_FormatYUV422SemiPlanar; // Capture output in 422 format
    paramPort.nBufferSize = 1920*1080*2;
    eError = OMX_SetParameter(m_CaptureHandle, OMX_IndexParamPortDefinition, &paramPort); 

    and

    OMX_INIT_PARAM (&sHwPortParam);
    sHwPortParam.nPortIndex = OMX_VFCC_OUTPUT_PORT_START_INDEX;
    sHwPortParam.eCaptMode = OMX_VIDEO_CaptureModeSC_NON_MUX;
    sHwPortParam.eVifMode = OMX_VIDEO_CaptureVifMode_16BIT;
    sHwPortParam.eInColorFormat = OMX_COLOR_FormatYCbYCr;
    sHwPortParam.eScanType = OMX_VIDEO_CaptureScanTypeProgressive;
    sHwPortParam.nMaxHeight = 1080;
    sHwPortParam.nMaxWidth = 1920;
    sHwPortParam.nMaxChnlsPerHwPort = 1;
    eError = OMX_SetParameter(m_CaptureHandle, (OMX_INDEXTYPE) OMX_TI_IndexParamVFCCHwPortProperties, (OMX_PTR) & sHwPortParam);

    The only thing different from the examples I run on the evm is that I don't have any video decoder and that no omx control component is created... I have read about people making dummy tvp component, but i'm not sure of the exact purpose and if it is relevant to my case. Any insight ?

    P-O

  • I'm doing a similar project, capturing video with a custom board with an FPGA.  I've found that it's a lot easier to use the v4l2 capture code than the OMX capture components, because the driver source code is included in the ezsdk. I enabled the vpss debug flag, and also put a lot of printk statements in the driver code while debugging.  In my case, the saLoopBack application was the v4l2 example that got me up and running.  

  • Hi,

    Component detects the decoder chip , and limits the capture lines. Without TVP, it is mis-detecting the board and limiting the lines. Could you please try EZSDK 5.05.01.04 ? I believe this limitation should not be there.

    Regards

    Vimal

  • Hi,

    We are also facing similar problem using EZSDK 5.05.01.04.

    We are able to capture using ioctl calls using saLoopBack application. But when we use omx calls to hCap OMX module we see that the yuv captured is not proper (288 lines output observed)

    Please provide your inputs..

    Regards,

    SH

  • Hi,

    It seems "maxOutHeight" is set to VPS_CAPT_MAX_OUT_HEIGHT_288_LINES that is only 288 lines will be captured. I think your board is getting detected as VS and thats why its limiting the maxHeight to 288.

  • Hi P-O

    Have you fixed this problem?

    I have the same 288 lines problem when capture a 1920x1080 frame.

    Regards,

    Lei

  • Hi,

     

    There is an interface in the capture driver to set the 1080 as max height.

     

    Rgds,

    Brijesh

  • Hi Brijesh

    Thank you for your reply.

    Can you tell me more about the setting?

    you mean the set the param in OMX?

    Regards,

    Lei