cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Voyager
Voyager
821 Views
Registered: ‎05-30-2017

Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hello,

I'm working with 2019.2 tools and UltrazedEV carrier card + SOM. I followed the flow from impleting to building petalinux images of ultrazed vcu trd 2019.2 design and it works. I editedthe vivado project adding the SDI RX part from zcu106 vcu trd design and I edited device tree adding the emtries for sdi rx part and I added V4L2 driver in petalinux kernel. But in petalinux running on the board I can't find the sdi rx devices. What's I'm wrong?

Thank you very much.

https://xterra2.avnet.com/xilinx/zedboard/ultrazed-ev/vcu-trd-ports/rdf0428-uz7ev-vcu-trd-2019-2

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Voyager
Voyager
368 Views
Registered: ‎05-30-2017

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hello @clivewmwalker ,

I observed that for v_proc_ss  it is not mandatory to add all fields because device tree for it is automatically generated by petalinux tool. In fact as you can see in system.dts there all the fields.  However to avoid ambiguity you can insert all the fields also in system-user.dtsi.

Looking at your device tree the "problem" even if I think it's a bug is here:

 

      clock-names = "aclk_axis", "aclk_ctrl";

      clocks = <&zynqmp_clk 72>, <&zynqmp_clk 72>;

If you convert system.dtb in system.dts you will see that after "clocks =" you will have four values because zynq generated clocks need each two values to be identified and I think thare is a bug in vpss driver that always expects two values. (I found same bug also in sdi tx). Open vivado and try to connect a pll clock or anyway a clock that only need a single numeric value to be identified (for example a 300 MHz clock) and connect it to "aclk_axis" and "aclk_ctrl"  . Then import new xsa (or hdf), modify device-tree and then rebuild linux. 

View solution in original post

0 Kudos
13 Replies
Highlighted
Mentor
Mentor
803 Views
Registered: ‎06-16-2013

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hi @pierlum 

 

Would you share the followings ?

 

- boot log

- Device Tree Source File

 

Also, refer the following URL to investigate the route cause.

 

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842396/Xilinx+V4L2+SDI+Rx+driver

 

Best regards,

Highlighted
Voyager
Voyager
773 Views
Registered: ‎05-30-2017

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hi @watari ,

thank you very much for the help. I attached the files.

Thanks.

0 Kudos
Highlighted
Mentor
Mentor
715 Views
Registered: ‎06-16-2013

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hi @pierlum 

 

It seems clock stability issue or something.

Would you make sure stability of cpu0 on ZynqMP and axi clock on SDI Rx IP ?

 

Best regards,

Highlighted
Voyager
Voyager
671 Views
Registered: ‎05-30-2017

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hello @watari,

thanks for the help. What do you mean with cpu stability? What is the part of the boot log that helped you understand where my problems were?

Thank you.

0 Kudos
Highlighted
Voyager
Voyager
631 Views
Registered: ‎05-30-2017

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

HI @watari ,

I modified device-tree and added reset-gpios for v_proc_ss and v_frmbuf_wr. Now v_frmbuf is good but video pipe is still broken. I have this strange problem with v_proc_ss clocks

[ 6.449429] xlnx,scaler-bridge a0080000.v_proc_ss: failed to get axi lite clk -517
[ 6.449450] xlnx,scaler-bridge a0080000.v_proc_ss: parse_of failed

I have also this error:

[ 6.466114] xilinx-video amba_pl@0:vcap_sdi: /amba_pl@0/vcap_sdi/ports/port@0 initialization failed
[ 6.466129] xilinx-video amba_pl@0:vcap_sdi: DMA initialization failed
[ 6.466182] xilinx-video amba_pl@0:vcap_sdi1: /amba_pl@0/vcap_sdi1/ports/port@0 initialization failed
[ 6.466197] xilinx-video amba_pl@0:vcap_sdi1: DMA initialization failed

But I think that this one is only a result of the previous error.

I can't understand this error. As you can in BD attached in PDF (SDI.pdf) and in device tree v_frmbuf_wr and v_smpte_uhdsdi_rx_ss   have same clock in BD and in device tree but there is clock error only for v_proc_ss.

Could anyone help me?

Thank you.

0 Kudos
Highlighted
Voyager
Voyager
595 Views
Registered: ‎05-30-2017

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

I solved vcap_sdi problem. There was a label error in system-user.dtsi. The vpss clock problem I solved using a workaround. As you can in dts file clock-names has two values but clocks has three values because I connected to aclk_ctrl pl clock 0 generated from zynq. It seems that this clock need two parameter in clocks. One identify that is a zynq pl clock and one identify which zynq pl clock is. I think that for vpss this is a problem. In fact connecting to aclk_ctrl  a clock that needs only a value in clocks it works. I think that this is a bug of vpss driver.

Highlighted
Adventurer
Adventurer
457 Views
Registered: ‎03-21-2013

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hello Pierlum. I'm interested in the device tree syntax you used to fix the vpss clock problem. Could you share it?

Thanks

 

Clive

 

0 Kudos
Highlighted
Voyager
Voyager
430 Views
Registered: ‎05-30-2017

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hello @clivewmwalker ,

I attached system-user.dtsi and system.dts(decompiled system.dtb).

Highlighted
Adventurer
Adventurer
392 Views
Registered: ‎03-21-2013

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Thanks Pierlum.

Sorry to bug you again.

In the system-user.dtsi file, you have removed the "clocks" and "clock-names" entries completely from the v_proc instance:

                SDI_sdi_rx_input_v_proc_ss_0: v_proc_ss@a0080000 {
                     reset-gpios = <&gpio_resets_axi_gpio_resets 3 0 1>; 
                 //compatible = "xlnx,v-proc-ss-2.2", "xlnx,v-vpss-scaler-1.0", "xlnx,vpss-scaler";
       //compatible = "xlnx,v-proc-ss-2.2";
                       compatible = "xlnx,v-vpss-scaler-2.2";
    
     scaler_ports1: ports {

.....

Was this intentional?

I tried doing this, but it didn't work for me - I'm still having problems with the "failed to get axi lite clk -517" error.

I'm currently trying:

   ch1_v_proc_ss_0: v_proc_ss@a02c0000 {

      clock-names = "aclk_axis", "aclk_ctrl";

      clocks = <&zynqmp_clk 72>, <&zynqmp_clk 72>;

      compatible = "xlnx,vpss-scaler";

      reg = <0x0 0xa02c0000 0x0 0x40000>;

      reset-gpios = <&gpio 94 1>;

      xlnx,colorspace-support = <0>;

      xlnx,csc-enable-window = "true";

      xlnx,enable-csc = "true";

      xlnx,h-scaler-phases = <64>;

      xlnx,h-scaler-taps = <6>;

      xlnx,max-height = <2160>;

      xlnx,max-num-phases = <64>;

      xlnx,max-width = <3840>;

      xlnx,num-hori-taps = <6>;

      xlnx,num-vert-taps = <6>;

      xlnx,pix-per-clk = <2>;

      xlnx,samples-per-clk = <2>;

      xlnx,scaler-algorithm = <2>;

      xlnx,topology = <0>;

      xlnx,use-uram = <0>;

      xlnx,v-scaler-phases = <64>;

      xlnx,v-scaler-taps = <6>;

      xlnx,video-width = <8>;

      scaler_ports1: ports {

         #address-cells = <1>;

         #size-cells = <0>;

         scaler_port01: port@0 {

            reg = <0>;

            xlnx,video-format = <XVIP_VF_RBG>;

            xlnx,video-width = <8>;

            ch1_v_proc_scaler_in: endpoint {

               remote-endpoint = <&ch1_dmaengine_crtc>;

            };

         };

         scaler_port11: port@1 {

            reg = <1>;

            xlnx,video-format = <XVIP_VF_RBG>;

            xlnx,video-width = <8>;

            ch1_v_proc_scaler_out: endpoint {

               remote-endpoint = <&encoder_hdmi_port_ch1_v_hdmi_tx_ss_0>;

            };

         };

      };

   };

Clive

 

0 Kudos
Highlighted
Voyager
Voyager
369 Views
Registered: ‎05-30-2017

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hello @clivewmwalker ,

I observed that for v_proc_ss  it is not mandatory to add all fields because device tree for it is automatically generated by petalinux tool. In fact as you can see in system.dts there all the fields.  However to avoid ambiguity you can insert all the fields also in system-user.dtsi.

Looking at your device tree the "problem" even if I think it's a bug is here:

 

      clock-names = "aclk_axis", "aclk_ctrl";

      clocks = <&zynqmp_clk 72>, <&zynqmp_clk 72>;

If you convert system.dtb in system.dts you will see that after "clocks =" you will have four values because zynq generated clocks need each two values to be identified and I think thare is a bug in vpss driver that always expects two values. (I found same bug also in sdi tx). Open vivado and try to connect a pll clock or anyway a clock that only need a single numeric value to be identified (for example a 300 MHz clock) and connect it to "aclk_axis" and "aclk_ctrl"  . Then import new xsa (or hdf), modify device-tree and then rebuild linux. 

View solution in original post

0 Kudos
Highlighted
Adventurer
Adventurer
350 Views
Registered: ‎03-21-2013

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hello pierlum

Thanks for this suggestion. It has moved me onto the next problem!

In my design, the 2 clocks originated from the PS. One for video, the other for axi-lite. I did not want to actually connect the v_proc to a new PLL as you seemed to suggest. So I left the design as it was. However, your idea made me think that the connectivity in the device tree doesn't necessarily need to reflect the actual connectivity in the design - provided it passes through the DTG. So I found, in the pl.dtsi file, a PLL that I already had in the design (for the VCU in fact). I found one of the clocks the DTG had generated for that PLL, and used that in my new system-user.dtsi:

   ch1_v_proc_ss_0: v_proc_ss@a0040000 {
      clock-names = "aclk_axis", "aclk_ctrl";
      clocks = <&misc_clk_3>, <&misc_clk_3>;

I no longer get the -517 issue!

Hopefully there will be no side effects of fooling the VPSS parser in this way. 

Now my pipeline fails to work for other reasons, but that's a different story.

Thanks for the help!

 

Clive

 

 

 

In my system-user.dtsi

 

0 Kudos
Highlighted
Voyager
Voyager
230 Views
Registered: ‎05-30-2017

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hi @clivewmwalker ,

to avoid problems I think that device tree must match with your Vivado design. For example you could use the pll clock that feeds vcu to feed VPSS if the frequency is good.

0 Kudos
Highlighted
Adventurer
Adventurer
211 Views
Registered: ‎03-21-2013

Re: Ultrazed vcu trd port 2019.2 porblem adding SDI RX

Jump to solution

Hi

So this would mean changing the clock domains for both axi-stream and axi lite on the v_proc. This implies also changing the clock domains on all components in the AXI-Stream domain upstream and downstream from the v_proc. This includes the AXI-MM connection to the PS (via interconnect) fpr DDR.

Sure I can do this, I have the VCU PLL running 300 MHz. It's a fairly dramatic workaround though, isn't it?!! 

In my case, I currently only have the FrameBuffer-read and PS DDR interface (upstream) and the HDMI TX (downstream) but I will be adding other IP blocks in later iterations.

Clive

 

 

0 Kudos