V4L2 YUV4:2:2 Video Capture Pipeline in Petalinux 2019.2 not Working.

[badegoke_f1]

Hi,

I use a custom Zynq Ultrascale SoM and Carrier. I have been able to adapt SDI-Rx from the ZCU106 TRD. I have an SDI-Rx subsystem connected to a framebufferWrite IP. The SDI input is connected to an SDI camera with video format 10bit YUV422 @1080p .

I have tested the video pipeline using the SDI-Rx standalone firmware example code and it detects change in video formats correctly although with intermittent loss of lock. In petalinux 2019.2 I cannot seem to capture a frame to test the pipeline using V4L2. 

Any help on how to get it capturing is appreciated.The commands and logs are sown below:

root@wrapper_2GB_rsts:~# v4l2-ctl -V
Format Video Capture Multiplanar:
        Width/Height      : 1920/0
        Pixel Format      : 'YUYV'
        Field             : None
        Number of planes  : 0
        Flags             :
        Colorspace        : sRGB
        Transfer Function : Default
        YCbCr/HSV Encoding: Default
        Quantization      : Default

root@wrapper_2GB_rsts:~# media-ctl –d /dev/video0 -p
Media controller API version 4.19.0

Media device information
------------------------
driver          xilinx-video
model           Xilinx Video Composite Device
serial
bus info
hw revision     0x0
driver version  4.19.0

Device topology
- entity 1: vcap_sdirx output 0 (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
        pad0: Sink
                <- "80000000.v_smpte_uhdsdi_rx_ss":0 [ENABLED]

- entity 5: 80000000.v_smpte_uhdsdi_rx_ss (1 pad, 1 link)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
        pad0: Source
                [fmt:UYVY10_1X20/1920x1080@1000/50000 field:none]
                [dv.detect:BT.656/1120 1920x1080p50 (2640x1125) stds:CEA-861 flags:CE-video,has-cea861-vic]
                -> "vcap_sdirx output 0":0 [ENABLED]

root@wrapper_2GB_rsts:~# v4l2-ctl --device /dev/video0 --stream-mmap --stream-to=frame.raw --stream-count=1
[  205.949328] xilinx-video amba_pl@0:vcap_sdirx: swiotlb: coherent allocation failed, size=0
[  205.957595] CPU: 1 PID: 2246 Comm: v4l2-ctl Tainted: G           O      4.19.0-xilinx-v2019.2 #1
[  205.966363] Hardware name: xlnx,zynqmp (DT)
[  205.970529] Call trace:
[  205.972967]  dump_backtrace+0x0/0x148
[  205.976617]  show_stack+0x14/0x20
[  205.979917]  dump_stack+0x90/0xb4
[  205.983224]  swiotlb_alloc+0x160/0x168
[  205.986964]  __dma_alloc+0xa8/0x1e0
[  205.990438]  vb2_dc_alloc+0xc8/0x1c8
[  205.994004]  __vb2_queue_alloc+0x350/0x418
[  205.998084]  vb2_core_reqbufs+0x12c/0x3f0
[  206.002077]  vb2_ioctl_reqbufs+0x6c/0x98
[  206.005985]  v4l_reqbufs+0x48/0x58
[  206.009378]  __video_do_ioctl+0x23c/0x498
[  206.013372]  video_usercopy+0x144/0x518
[  206.017191]  video_ioctl2+0x14/0x1c
[  206.020664]  v4l2_ioctl+0x3c/0x58
[  206.023964]  do_vfs_ioctl+0xb8/0x8a0
[  206.027530]  ksys_ioctl+0x44/0x90
[  206.030829]  __arm64_sys_ioctl+0x1c/0x28
[  206.034736]  el0_svc_common+0x84/0xd8
[  206.038389]  el0_svc_handler+0x68/0x80
[  206.042122]  el0_svc+0x8/0xc
[  206.045009] xilinx-video amba_pl@0:vcap_sdirx: dma_alloc_coherent of size 0 failed

Thanks

[watari]

Hi @badegoke_f1 

Would you set proper parameter by xmedia-ctl or media-ctl on /dev/mediaX ?

Of cause, before execute (x)media-ctl, you must find proper media device name.

Best regards,

[badegoke_f1]

Hi @watari ,

Thanks for the reply. I am hoping I have set the parameter as you had suggested. Please see commands and logs attached. I can only stream using "videotestsrc" in VLC player via UDP I get streaming colour bars but when I change the source to the SDR-RX input, it still does not work and nothing is streamed in VLC player. I then repeatedly checked the status of the SDI-RX IP using v4l2-ctl:

• I noticed the "sdi_rx_crc_error_status" keeps changing(increasing).
• I am not sure why it also says "sdi_rx_active_streams: 2" when I have got a single SDI camera connected to the SDI input on the board.
• I also observed the  type V4L2 subdev subtype Unknown flags 0 is unknown. Is this an issue I have to address?
  
  To verify the SDI data from the camera, I probed the signals and GT reference clock, the clock and data eye look good and open.

Procedure used:
1. I reset the Loss of Lock Toggle,Framebuffer rstn, Vcu rstn
2. I set the parameters with v4l2
3. I check if parameters have been set.
4. I run videotestsrc which works
5. I run sdi pipeline which fails
6. I check the status of the SDI-Rx IP with v4l2

root@wrapper_2GB_rsts:~# devmem 0x80080000 32 0x7 && devmem 0x80040000 32 0x0; sleep 1; devmem 0x80080000 32 0x3 && devmem 0x80040000 32 0x1; sleep 3;

root@wrapper_2GB_rsts:~# v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat="XV20",field=none

root@wrapper_2GB_rsts:~# v4l2-ctl -V
Format Video Capture Multiplanar:
        Width/Height      : 1920/1080
        Pixel Format      : 'XV20' (Y/CrCb 4:2:2 10-bit)
        Field             : None
        Number of planes  : 0
        Flags             :
        Colorspace        : sRGB
        Transfer Function : Default
        YCbCr/HSV Encoding: Default
        Quantization      : Default
root@wrapper_2GB_rsts:~# media-ctl –d /dev/video0 -p
Media controller API version 4.19.0

Media device information
------------------------
driver          xilinx-video
model           Xilinx Video Composite Device
serial
bus info
hw revision     0x0
driver version  4.19.0

Device topology
- entity 1: vcap_sdirx output 0 (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
        pad0: Sink
                <- "80000000.v_smpte_uhdsdi_rx_ss":0 [ENABLED]

- entity 5: 80000000.v_smpte_uhdsdi_rx_ss (1 pad, 1 link)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
        pad0: Source
                [fmt:UYVY10_1X20/1920x1080@1000/50000 field:none]
                [dv.detect:BT.656/1120 1920x1080p50 (2640x1125) stds:CEA-861 flags:CE-video,has-cea861-vic]
                -> "vcap_sdirx output 0":0 [ENABLED]


root@wrapper_2GB_rsts:~# gst-launch-1.0 videotestsrc ! video/x-raw, format=NV16_10LE32,width=1920,height=1080,framerate=50/1,colorimetry=bt601  ! omxh264enc control-rate=low-latency target-bitrate=100000 num-slices=16 ! video/x-h264, alignment=nal ! mpegtsmux ! udpsink host=10.XX.70.XX port=5XXX
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
!! Warning : Adapting profile to support bitdepth and chroma mode
!! The specified Level is too low and will be adjusted !!
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:01:51.470420503
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
root@wrapper_2GB_rsts:~# gst-launch-1.0 v4l2src device=/dev/video0 io-mode=4 ! video/x-raw, format=NV16_10LE32,width=1920,height=1080,framerate=50/1  ! omxh264enc control-rate=low-latency target-bitrate=20000 num-slices=16 ! video/x-h264, alignment=nal ! mpegtsmux ! udpsink host=10.XX.70.XX port=5XXX
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ende[  692.298241] xilinx-video amba_pl@0:vcap_sdirx: s_stream off failed on subdev
d after 0:00:43.897291774
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
root@wrapper_2GB_rsts:~# gst-launch-1.0 v4l2src device=/dev/video0 io-mode=4 ! video/x-raw, format=NV16_10LE32,width=1920,height=1080,framerate=50/1  ! omxh264enc control-rate=low-latency target-bitrate=20000 num-slices=16 ! video/x-h264, alignment=nal ! mpegtsmux ! udpsink host=10.XX.70.XX port=5XXX
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ende[  780.513034] xilinx-video amba_pl@0:vcap_sdirx: s_stream off failed on subdev
d after 0:01:24.984435787
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
root@wrapper_2GB_rsts:~# while true; do  v4l2-ctl -d /dev/v4l-subdev0 -C sdi_rx_mode_detect_status,sdi_rx_crc_error_status,sdi_rx_ts_is_interlaced,sdi_rx_is_3gb,sdi_rx_active_streams; echo ""; sleep 0.1; donesdi_rx_mode_detect_status: 2
sdi_rx_crc_error_status: 2372415
sdi_rx_ts_is_interlaced: 0
sdi_rx_is_3gb: 0
sdi_rx_active_streams: 2

sdi_rx_mode_detect_status: 2
sdi_rx_crc_error_status: 5649215
sdi_rx_ts_is_interlaced: 0
sdi_rx_is_3gb: 0
sdi_rx_active_streams: 2

sdi_rx_mode_detect_status: 2
sdi_rx_crc_error_status: 11416383
sdi_rx_ts_is_interlaced: 0
sdi_rx_is_3gb: 0
sdi_rx_active_streams: 2

sdi_rx_mode_detect_status: 2
sdi_rx_crc_error_status: 8991551
sdi_rx_ts_is_interlaced: 0
sdi_rx_is_3gb: 0
sdi_rx_active_streams: 2

sdi_rx_mode_detect_status: 2
sdi_rx_crc_error_status: 1127231
sdi_rx_ts_is_interlaced: 0
sdi_rx_is_3gb: 0
sdi_rx_active_streams: 2

sdi_rx_mode_detect_status: 2
sdi_rx_crc_error_status: 865087
sdi_rx_ts_is_interlaced: 0
sdi_rx_is_3gb: 0
sdi_rx_active_streams: 2

sdi_rx_mode_detect_status: 2
sdi_rx_crc_error_status: 1979199
sdi_rx_ts_is_interlaced: 0
sdi_rx_is_3gb: 0
sdi_rx_active_streams: 2

sdi_rx_mode_detect_status: 2
sdi_rx_crc_error_status: 3552063
sdi_rx_ts_is_interlaced: 0
sdi_rx_is_3gb: 0
sdi_rx_active_streams: 2

sdi_rx_mode_detect_status: 2
sdi_rx_crc_error_status: 1717055
sdi_rx_ts_is_interlaced: 0
sdi_rx_is_3gb: 0
sdi_rx_active_streams: 2

Thanks 
Bade

[florentw]

HI @badegoke_f1 

You have errors on the SDI links. I encourage you to take a step back and start from a baremetal example design following PG290 chapter 5

Then if this is also not working, debug step by step (are the PLL locked, are you receiving data etc...). Make sure you follow the debugging section of the PG290

[badegoke_f1]

Hi @florentw ,

Thanks for responding. I originally created my project with the bare SDI-Rx Only standalone example and got it working(i.e. detecting video formats and displaying via the serial comms interface) before adding a FrameBufferWrire and VCU for the Petalinux build.

One thing I did notice in the standalone SDI-Rx Only example:Whilst running the example bare-metal firmware, there was constant intermittent Loss of lock reported in the console output. As I changed formats from 720 through 1080 to 4K, the frequency of Loss of Lock increased. I suppose this linked with the rx_CRC_error in my Petalinux log shown. I still notice the Loss of lock debug LED on my hardware flickering. I will go back to the standalone to debug this using the documents you suggested. I am using a custom hardware from Enclustra and not the ZCU106.

I also verified the reference clock for the GT was correct at 148.5MHz and data eye is opened. I will update the thread shortly.  

Many thanks

[florentw]

Hi @badegoke_f1 

Do you have any update on this? were you able to make any progress?

[badegoke_f1]

Hi @florentw ,
Not much progress. I am currently debugging my hardware, the only update I have is that it is the UHDSDI IP that intermittently cannot detect the transport stream. I have also adapted the VCU TRD project without any modifications and I still get rx_crc_status errors. I also verified the SDI input signal with WFM8300 analyser and confirmed data with no errors. I am currently following the debug guide in pg290 if I can spot the issue. 

I am also looking at  getting a ZCU106 to verify the TRD with my SDI hardware.



Thanks

[badegoke_f1]

Dear @florentw and @watari ,

A bit of update, I have now been able to get the SDI-Rx Streaming to an IP address's via VLC player for 2 SDI chains. The only way I could get this to work is by setting the SDI-Rx lock window to "0" using yavta commands.On doing this, it streams using gstreamer commands. 

The ISSUE:

1. I still get crc_status_errors increasing which is a cumulative count of errors on the ds[n] streams
   
   
2. I also get multiple thin visible horizontal glitch lines in the video displayed(very minimal in 1080p30 and more at 1080p60).

I have debugged the GT as per the data sheet recommendation and clocks, PLL Lock and RXOUTCLOCK etc are all good and stable. It seems the ds[n] streams in the UHDSDI-Rx IP constantly have CRC errors even when the video is streaming. I am beginning to think its a timing issue because I have probed the clock and data to the GT on a scope and the eye and amplitudes are looking good.

To help me debug this further, I'll be happy if you can confirm my intended approach is possible.

1. I intend to add an SDI-Tx sub-system to help debug. Is it possible to do a GT Loopback internally on the GT in the device? I want to be able to connect what is streaming out on the TX to the RX section without going out of the Zynq Ultrascale+ device. This will help validate if the issue if from my board or on the Zynq ultrascale+ device. I can also compare the performance with the physical BNC connector loopback on the board.
   
   
2. Is it possible to use a "gstreamer testsrc" to stream a test pattern source to an SDI-Tx subsystem for the above loopback test?
   
   
3. If the event that the gstreamer to SDI-Tx is not possible, does Xilinx have a Test pattern Generator type IP  which generates native SDI date that can be a source to to an SDI-Rx sub-system? Something similar to a TPG for AXI video stream. This way I can easily validate the GT and SDI performance separately.
   
   
4. The VCU TRD includes a TPG design, although the design does not show the use of the TPG as a source to the SDI-Tx subsystem. Is it possible to use the TPG as a source to the SDI-Tx sub-system? Can this be a direct connect without writing to memory by the TPG and the SDI-Tx sinking directly? ....a pipeline slightly different from the memory approach in the VCU TRD.

Thanks 
Bade

[watari]

Hi @badegoke_f1 

>2. Is it possible to use a "gstreamer testsrc" to stream a test pattern source to an SDI-Tx subsystem for the above loopback test?

Can you prepare and build drm driver for SDI-Tx in your linux ?

If yes, you can use "gstreamer videotestrc" as a test pattern source and use "gstreamer v4l2src" as a sink.

However, you might encounter performance issue...

Best regards,

[florentw]

Hi @badegoke_f1 

You will not be able to test the UHD-SDI RX with internal connection. You can use the UHD-SDI Tx subsystem as a source but with an external loop-back.

For the CRC error, this is what I would do, try with an external loopback. This way you could detect if the CRC errors are coming from the source.

And yes you can use the TPG as input for the UHD-SDI Tx subsystem.

If you look at the PG290, you will see that there is a loopback example for the UHD-SDI Rx/Tx subsystem. This is on KCU116 and using baremetal but this might be a good reference

[badegoke_f1]

Dear @florentw, @watari ,

I have been debugging my video pipeline and I seem to be narrowing it down to signal/data integrity which could be due to my carrier+SoM discontinuities just before the GT. I have been using the IBERT IP core to debug my transceiver RX eye pattern and it seems I need to tweak my RX termination voltage in the GT to match my external equaliser settings to get a decent eyescan. However these IO's(Rx termination voltage) are not exposed in the UHD-SDI GT IP. I have used the Tx to Rx Loop-back IBERT options with scan sweeps to find optimal settings for the Rx GT side. 

Please can you suggest how I can work around this? 

This leads me to my next question. I have tried using the GT Transceiver Wizard to generate the GT core instead of using the UHD-GT IP in my project. However I am unsure how to map the RX data from the transceiver generated GT core to the block design UHD-SDI IP for the following connections: S_AXIS_RX, S_AXIS_STS_SB_RX and M_AXIS_CTRL_SB_RX . These connections link the GT and The UHD-SDI IP.

Many thanks for your help and suggestions so far.

Regards

Bade

[florentw]

HI @badegoke_f1 

---

@badegoke_f1 wrote:

Dear @florentw, @watari ,

I have been debugging my video pipeline and I seem to be narrowing it down to signal/data integrity which could be due to my carrier+SoM discontinuities just before the GT. I have been using the IBERT IP core to debug my transceiver RX eye pattern and it seems I need to tweak my RX termination voltage in the GT to match my external equaliser settings to get a decent eyescan. However these IO's(Rx termination voltage) are not exposed in the UHD-SDI GT IP. I have used the Tx to Rx Loop-back IBERT options with scan sweeps to find optimal settings for the Rx GT side. 

Please can you suggest how I can work around this? 

Florent - The UHD-SDI GT is unencrypted so you can edit it to fine tune the GT wizard under it

This leads me to my next question. I have tried using the GT Transceiver Wizard to generate the GT core instead of using the UHD-GT IP in my project. However I am unsure how to map the RX data from the transceiver generated GT core to the block design UHD-SDI IP for the following connections: S_AXIS_RX, S_AXIS_STS_SB_RX and M_AXIS_CTRL_SB_RX . These connections link the GT and The UHD-SDI IP.

Many thanks for your help and suggestions so far.

---

Florent - Same answer, the UHD-SDI GT is unencrypted so you can just look at the HDL code for it to find your answers