10-29-2019 06:44 PM
10G on eth1 when enabled results in error: XXV MAC block lock not complete
I booted a zcu106 with prebuilt kernet+rootfs from rdf0428-zcu106-vcu-trd-2019-1_v2\images\vcu_10g
I'm trying to test the 10G port and connected it as shown in 1.1 Board Setup:
On boot, I check if 10G is there using 'ip a' command:
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
link/can
4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:0a:35:00:22:01 brd ff:ff:ff:ff:ff:ff
5: eth1: <BROADCAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0a:35:03:04:ff brd ff:ff:ff:ff:ff:ff
I try to enable:
ifconfig eth1 up
[ 1875.753065] xilinx_axienet b0001000.ethernet eth1: XXV MAC block lock not complete! Cross-check the MAC ref clock configuration
These are prebuilt boot images, so I assumed that device tree and ip port config files are in place. If not, please let me know how to configure the 10G port. Thanks in advance!
11-21-2019 04:37 AM
I had the same issue as OP, with precompiled image from rdf0428-zcu106-vcu-trd-2019-1_v2\images\vcu_10g:
root@zcu106_vcu_trd:~# ifconfig eth1 up
[ 52.861085] xilinx_axienet b0001000.ethernet eth1: XXV MAC block lock not complete! Cross-check the MAC ref clock configuration
It seems it has been fixed in rdf0428-zcu106-vcu-trd-2019-2\images\vcu_10g [UG1250 from 2019-10-31]: no more warning during ifup, and pinging from PC to ZCU106, and back is working as expected.
Not sure yet what has been modified between the versions.
B.R.,
Fred.
11-14-2019 01:30 AM
I have exactly the same problem but on a custom board. Have you made any progress on this yet?
I have copied exactly the reference design form xapp1305. There has been another thread on the forum with this issue:
https://forums.xilinx.com/t5/Ethernet/Xapp1305-Block-lock-issue/td-p/983861
There it was pointed out that it can be the GT reference clock. I have monitored the clock at gt_refclk_out and can confirm that it matches very well the configured 156.25 MHz. So there must be some other cuase.
I don't think it's the board as we have a partner who is using the same board and got the 10G interface working. I have their Vivado project and they also just copied the reference design. One difference is, however, that they are using Vivado 2019.1 and I already upgraded to 2019.2. I see that in 2019.2 the IP got a new reset input qpll_reset_in, which is not documented in the product guide, but I have already tried all possible ways to assert this reset.
11-14-2019 02:39 AM
11-14-2019 02:48 AM
The device tree for the 10G interface is just the autogenerated one:
ethernet_10g_sub_ethernet_axi_dma_0: dma@a00b0000 { #dma-cells = <1>; clock-names = "s_axi_lite_aclk", "m_axi_sg_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk"; clocks = <&zynqmp_clk 73>, <&zynqmp_clk 73>, <&misc_clk_0>, <&misc_clk_0>; compatible = "xlnx,eth-dma"; interrupt-names = "mm2s_introut", "s2mm_introut"; interrupt-parent = <&gic>; interrupts = <0 107 4 0 106 4>; reg = <0x0 0xa00b0000 0x0 0x10000>; xlnx,addrwidth = /bits/ 8 <0x20>; xlnx,include-dre ; }; misc_clk_0: misc_clk_0 { #clock-cells = <0>; clock-frequency = <156250000>; compatible = "fixed-clock"; }; ethernet_10g_sub_ethernet_xxv_ethernet_0: ethernet@a00c0000 { axistream-connected = <ðernet_10g_sub_ethernet_axi_dma_0>; axistream-control-connected = <ðernet_10g_sub_ethernet_axi_dma_0>; clock-frequency = <100000000>; clock-names = "rx_core_clk_0", "dclk", "s_axi_aclk_0"; clocks = <&misc_clk_0>, <&zynqmp_clk 73>, <&zynqmp_clk 73>; compatible = "xlnx,xxv-ethernet-3.1", "xlnx,xxv-ethernet-1.0"; device_type = "network"; local-mac-address = [00 0a 35 00 00 00]; phy-mode = "base-r"; reg = <0x0 0xa00c0000 0x0 0x40000>; xlnx = <0x0>; xlnx,add-gt-cntrl-sts-ports = <0x0>; xlnx,anlt-clk-in-mhz = <0x64>; xlnx,axis-tdata-width = <0x40>; xlnx,axis-tkeep-width = <0x7>; xlnx,base-r-kr = "BASE-R"; xlnx,clocking = "Asynchronous"; xlnx,core = "Ethernet MAC+PCS/PMA 64-bit"; xlnx,data-path-interface = "AXI Stream"; xlnx,enable-datapath-parity = <0x0>; xlnx,enable-pipeline-reg = <0x0>; xlnx,enable-preemption = <0x0>; xlnx,enable-preemption-fifo = <0x0>; xlnx,enable-rx-flow-control-logic = <0x0>; xlnx,enable-time-stamping = <0x0>; xlnx,enable-tx-flow-control-logic = <0x0>; xlnx,enable-vlane-adjust-mode = <0x0>; xlnx,family-chk = "zynquplus"; xlnx,fast-sim-mode = <0x0>; xlnx,gt-diffctrl-width = <0x4>; xlnx,gt-drp-clk = "100.00"; xlnx,gt-group-select = "Quad X0Y0"; xlnx,gt-location = <0x1>; xlnx,gt-ref-clk-freq = "156.25"; xlnx,gt-type = "GTH"; xlnx,gtm-group-select = "NA"; xlnx,include-auto-neg-lt-logic = "None"; xlnx,include-axi4-interface = <0x1>; xlnx,include-dre ; xlnx,include-fec-logic = <0x0>; xlnx,include-hybrid-cmac-rsfec-logic = <0x0>; xlnx,include-rsfec-logic = <0x0>; xlnx,include-shared-logic = <0x1>; xlnx,include-statistics-counters = <0x1>; xlnx,include-user-fifo = <0x1>; xlnx,ins-loss-nyq = <0x1e>; xlnx,lane1-gt-loc = "X1Y12"; xlnx,lane2-gt-loc = "NA"; xlnx,lane3-gt-loc = "NA"; xlnx,lane4-gt-loc = "NA"; xlnx,line-rate = <0xa>; xlnx,mii-ctrl-width = <0x4>; xlnx,mii-data-width = <0x20>; xlnx,num-of-cores = <0x1>; xlnx,ptp-clocking-mode = <0x0>; xlnx,ptp-operation-mode = <0x2>; xlnx,runtime-switch = <0x0>; xlnx,rx-eq-mode = "AUTO"; xlnx,rxmem = <0x40000>; xlnx,statistics-regs-type = <0x0>; xlnx,switch-1-10-25g = <0x0>; xlnx,tx-latency-adjust = <0x0>; xlnx,tx-total-bytes-width = <0x4>; xlnx,xgmii-interface = <0x1>; ethernet_10g_sub_ethernet_xxv_ethernet_0_mdio: mdio { #address-cells = <1>; #size-cells = <0>; }; };
The 156 MHz clock is coming in from a dedicated oscillator on the board, so there is no need to program a clock generator.
11-14-2019 02:57 AM
Hi @cone83
Just for debugging purposes, Can you try adding the attached device tree entries in system-user.dtsi and test if that changes the behavior?
Best Regards
Shabbir
11-14-2019 03:20 AM
Hi @shabbirk
I just tested. Still I get the same result:
root@petalinux:~# ifup eth1 [ 61.163140] xilinx_axienet a00c0000.ethernet eth1: XXV MAC block lock not complete! Cross-check the MAC ref clock configuration RTNETLINK answers: File exists
11-21-2019 04:37 AM
I had the same issue as OP, with precompiled image from rdf0428-zcu106-vcu-trd-2019-1_v2\images\vcu_10g:
root@zcu106_vcu_trd:~# ifconfig eth1 up
[ 52.861085] xilinx_axienet b0001000.ethernet eth1: XXV MAC block lock not complete! Cross-check the MAC ref clock configuration
It seems it has been fixed in rdf0428-zcu106-vcu-trd-2019-2\images\vcu_10g [UG1250 from 2019-10-31]: no more warning during ifup, and pinging from PC to ZCU106, and back is working as expected.
Not sure yet what has been modified between the versions.
B.R.,
Fred.
11-21-2019 01:22 PM
I confirm that I don't see the error and eth1 is up.
11-21-2019 05:39 PM
Hi. I am having the same issue on a zcu102 board. Do you have any suggestions on how I could fix that? Thanks.
11-22-2019 04:38 PM
xapp1305 covers the zcu102 board. The prebuilt boot binaries worked for us.
11-24-2019 05:53 PM
Thanks. I realized I was using the older version. I switched to the 2019.1 version and it works.
11-24-2019 11:17 PM
Did anyone yet successfully test it with 2019.2?
11-26-2019 02:12 PM
Yes, 2019.2 vcu trd 10g binaries worked with our zcu106 board. We're still trying to benchmark properly since the MTU is limiting measured thruput to 1.5G.
11-27-2020 10:44 PM
Hello @cone83
Did you solve your problem.
I have the same case, and also the reference clock is generated by external crystal oscillator.
Thanks.