cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
kieucua1503
Participant
Participant
2,950 Views
Registered: ‎03-13-2016

Xapp1305 Block lock issue.

Hi guys,

I'm trying Xapp1305 pl ethernet 10G on zcu102-rev1.1. I'm have two problem need help:

1. Prebuild work fine. But i'm test throughput by iperf3 between Server with Intel 10G card and zcu102, speed only ~ 1.73Gbits per second.

2. When I try to rebuild project with vivado 2019.1 (i don't have vivado 2018.3 as guide), I'm run into "block lock" issue:

root@zcu102_10g:~# ifconfig eth1 down
root@zcu102_10g:~# ifconfig eth1 192.168.2.5
[ 1097.222373] xilinx_axienet 80010000.ethernet eth1: XXV MAC block lock not complete! Cross-check the MAC ref clock configuration

 

Thanks for any advise,

10 Replies
simon.beaudoin
Adventurer
Adventurer
2,895 Views
Registered: ‎05-08-2018

Just in case someone else stumble across this post.

As the message of the error says, the block lock mechanism never succeded so the bit never raised. If I'm not mistaken, the block lock is a self test mechanism performed when the subsystem resets (ifconfig eth* up for exemple). The self test puts the GT in loopback mode and checks that it is able to lock to a frame and detect it. If it can't, the driver init prints this message. The error message explains it all in fact : the refclock of the GT if not configured correctly. In most cases, the 156.25MHz frequency will be chosen as it is the default frequency (never tried anything else in fact). So you have to provide a 156.25MHz to the refclk pin of the Quad on the board. There is a SI570 programmable clock generator on the board. It is controled via I2C. You must add it's corresponding note in the device tree for the kernel to configure it at boot time. Please add the following to your dtsi. Don't forget to add a MAC address too, but since you can see your interface with ifconfig, it must be set

&xxv_ethernet_0 {
	local-mac-address = [00 0a 35 00 00 00];
};


&i2c1 {
    status = "okay";
    clock-frequency = <400000>;
    i2c-mux@74 { /* u34 */
        compatible = "nxp,pca9548";
        #address-cells = <1>;
        #size-cells = <0>;
        reg = <0x74>;
        i2c@3 { /* i2c mw 74 0 8 */
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <3>;
            si570_2: clock-generator3@5d {
                #clock-cells = <0>;
                compatible = "silabs,si570";
                reg = <0x5d>;
                temperature-stability = <50>;
                factory-fout = <156250000>;
                clock-frequency = <156250000>;
            };
        };
    };
};

 

alexkeys
Contributor
Contributor
2,546 Views
Registered: ‎05-24-2018

Hi. On the Xapp1305 page, for 10G, they specify a 300MHz frequency to use in the device tree. But it seems the 156.25MHz is what was used in my hardware so I changed to that, hoping that would solve the problem. However, I keep getting the same message. So, I replaced your device tree with mine (not a good idea) and lo and behold it did not work. I don't know what I am doing wrong so I am going to paste my device tree here and the mac block frequency setting in the settings as well. Most of it is from the wiki page linked to above with changes to the status and clock frequencies. Kindly let me know if there is a wrong configuration somewhere.

/include/ "system-conf.dtsi"
/ {
};
&i2c1 {
    status = "okay";
    pinctrl-names = "default", "gpio";
    pinctrl-0 = <&pinctrl_i2c1_default>;
    pinctrl-1 = <&pinctrl_i2c1_gpio>;
    scl-gpios = <&gpio 16 0>;
    sda-gpios = <&gpio 17 0>;

    /* FIXME PL i2c via PCA9306 - u45 */
    /* FIXME MSP430 - u41 - not detected */
    i2c-mux@74 { /* u34 */
        compatible = "nxp,pca9548";
        #address-cells = <1>;
        #size-cells = <0>;
        reg = <0x74>;
        i2c@0 { /* i2c mw 74 0 1 */
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <0>;
            /*
             * IIC_EEPROM 1kB memory which uses 256B blocks
             * where every block has different address.
             *    0 - 256B address 0x54
             * 256B - 512B address 0x55
             * 512B - 768B address 0x56
             * 768B - 1024B address 0x57
             */
            eeprom: eeprom@54 { /* u23 */
                compatible = "at,24c08";
                reg = <0x54>;
            };
        };
        i2c@1 { /* i2c mw 74 0 2 */
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <1>;
            si5341: clock-generator1@36 { /* SI5341 - u69 */
                compatible = "si5341";
                reg = <0x36>;
            };

        };


        i2c@2 { /* i2c mw 74 0 4 */
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <2>;
            si570_1: clock-generator2@5d { /* USER SI570 - u42 */
                #clock-cells = <0>;
                compatible = "silabs,si570";
                reg = <0x5d>;
                temperature-stability = <50>;
                factory-fout = <156250000>;
                clock-frequency = <156250000>;
            };
        };
        /delete-node/ i2c@3;

        i2c@4 { /* i2c mw 74 0 10 */
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <4>;
            si5328: clock-generator4@69 {/* SI5328 - u20 */
                compatible = "silabs,si5328";
                reg = <0x69>;
                /*
                 * Chip has interrupt present connected to PL
                 * interrupt-parent = <&>;
                 * interrupts = <>;
                 */
            };
        };
        /* 5 - 7 unconnected */
    };
};




Capture.PNG

 

0 Kudos
simon.beaudoin
Adventurer
Adventurer
2,497 Views
Registered: ‎05-08-2018

Hi @alexkeys ,

Let's see. If you operate a 10GigE design, stick with 156.25MHz clock. Even though the scroll menu offers you different frequencies, stick with that one, but I will admit I never tried anything else. 156.25MHz is the 'natural' frequency that data will output the core at 100% theorical usage (10 000 000 000 bits/sec / 64 bits wide axi stream = 156.25 Mhz). Now, I see that that's the frequency you used. You must then use a 156.25 MHz clock on the refclk differential input.

In my experience, (I'm a mere mortal, don't mark my words as absolute truth here), you have to use refclk0 differential pair. Our first attempt at getting the 10gig core working with the 156.25MHz clock tied to refclkc1 did not work. In fact, no where in the vivado gui can you specify the input clock (refclk0 or refclk1) contrary to the aurora core, for exemple. Now, I think you are working with the zcu102, so the si570 is connected to refclk0, so you're ok. (Just for the record, I tried to make the core work with the zcu102 using refclk1 to confirm, or infirm my point when troubleshooting our custom bcp, because there is another clock generator chip hooked to refclk1 input. Result where negative)

The frequency you put in the vivado xxv_ethernet gui must match what you provide. Please, make sure with a oscilloscope that you indeed see a 156.25MHz clock going out of the SI570 chip. If you don't see it, then the problem is getting it configured properly.

If you do see a nice clock, then the problem will be somewhere else.

Still about our custom board design, it took us quite some time to get the core working. The pcb traces on the board where not quite up to spec, so we had signal integrity problems. Try putting an in system IBERT core in your design and check it. In our case, the block lock messgae still appears at each boot-up of our board, but by consifuring the pre and post emphasis, we managed to still have a working link. It is a little bit buggy from time to time, but we'll do a respoin of our boards to get it working. Now, in your case you work with the zcu102, so PCB has been tested and is very probably ok.

Please tell me whether or not you can probe the 156.25M clock, well see from there

 

0 Kudos
alexkeys
Contributor
Contributor
2,404 Views
Registered: ‎05-24-2018

Hello @simon.beaudoin ,

Sorry for taking so long to reply. I checked the frequency using the xilinx board interface test program. The si570 chip seems ok. I even set the boot frequency to 156.25MHz, rebooted and checked again, and it displayed the same frequency. With the software, I guess I don't have to use the scope. The problem still persists. 

0 Kudos
simon.beaudoin
Adventurer
Adventurer
2,384 Views
Registered: ‎05-08-2018

Hi! Sorry to hear it still doesn't work...

Have you tried changing the kernel configs? If I recall correctly, you have to change them like this too :

CONFIG_XILINX_PHY=y
# CONFIG_XILINX_DMA is not set

Try that and let me know

0 Kudos
alexkeys
Contributor
Contributor
2,352 Views
Registered: ‎05-24-2018

Hello @simon.beaudoin , 

I just checked and realized those settings exist in my kernel file. Is there a way to verify the clock frequencies from the Linux console? 

 

0 Kudos
simon.beaudoin
Adventurer
Adventurer
2,334 Views
Registered: ‎05-08-2018

I think there is a way to mess with clock frequencies of CCF(common clock framework) clock provider from console, but I don't remember how to do it. Anyway, if you made sure with a scope that the clock freqnency of the oscillator connected to mgt_refclk0 is indeed 156.25MHz, then that's it, no need for further investigation.

On the connected pc on the other end of your sfp+ cable, does a activity light lights up?

I don't remember, are you using a zcu102 board already?

Just in case, here is how my working design is connected. It's basically the Xapp1305 reworked a bit, but you can see that we have an in system IBERT always connected in order to caracterise the board. Try hooking one up like us and play with the GT settings like pre and post emphasis.

My XXV_Ethernet hierarchyMy XXV_Ethernet hierarchyMy 'DMA' hierarchyMy 'DMA' hierarchyMy 'Core' hierarchyMy 'Core' hierarchyEnable additional GT Control/Status and DRP PortsEnable additional GT Control/Status and DRP Ports

alexkeys
Contributor
Contributor
2,295 Views
Registered: ‎05-24-2018


Try hooking one up like us and play with the GT settings like pre and post emphasis.


 Thanks a lot for your effort. I really appreciate it. I will go ahead hook up the IBERT and try other things as well to see what works. Thanks also for showing your design. I will compare it with mine. In any case, whenever I am able to get this working, I will update this thread. Thanks once again @simon.beaudoin 

0 Kudos
alexkeys
Contributor
Contributor
2,218 Views
Registered: ‎05-24-2018

Hello @simon.beaudoin , 

The issue has been solved. It was because of the sfp connectors. Both were faulty. I changed them and now, I am able to ping. That means everything works well right - talking about Tx and Rx?

simon.beaudoin
Adventurer
Adventurer
1,977 Views
Registered: ‎05-08-2018

Yes indeed. You could try to use iperf to test the performances. In my experience, you should be able to get around 3 to 3.5 Gbs. I think nobody got above 4 or 5, even though it should be a 10Gbs link..

0 Kudos