2 Replies Latest reply on Jan 12, 2021 1:54 PM by ejubenville

    Cannot get second Ethernet port working with PicoZed

    ejubenville

      We have a custom board that uses a PicoZed Z7030 SOM and two Ethernet ports.  The first port handled by the PicoZed works fine, but we are unable to get the second Ethernet port working.  For the second PHY (on our board), we use the same Marvell PHY as the PicoZed but we strapped its CONFIG line to come up as address 1.  In the Vivado block design, the Zynq is configured to use EMIO for the second Ethernet port MDIO and the MDIO lines are routed from the SOM to the external PHY.   The Linux phytool shows us valid information about both PHYs, so we believe the MDIO bus is working properly.

       

      We are using Xilinx kernel 2018.3 and the Cadence MACB Gem driver.  At boot, everything looks fine:

       

      ...kern.info kernel: libphy: MACB_mii_bus: probed

      ...kern.info kernel: macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 28 (80:1f:12:ee:67:9e)

      ...kern.info kernel: Marvell 88E1510 e000b000.ethernet-ffffffff:00: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=e000b000.ethernet-ffffffff:00, irq=POLL)

      ...kern.info kernel: macb e000c000.ethernet: invalid hw address, using random

      ...kern.info kernel: libphy: MACB_mii_bus: probed

      ...kern.info kernel: macb e000c000.ethernet eth1: Cadence GEM rev 0x00020118 at 0xe000c000 irq 29 (ae:09:2e:e3:28:8b)

      ...kern.info kernel: Marvell 88E1510 e000c000.ethernet-ffffffff:01: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=e000c000.ethernet-ffffffff:01, irq=POLL)

       

      We have a MAC address chip for u-boot to read the MAC address for eth0, but eth1 is being assigned a random address.  As expected, the two PHYs are shown as addresses :00 and :01 respectively.

      The first symptom that something is wrong is the following error message when the links come up:

       

      ...kern.info kernel: macb e000b000.ethernet eth0: link up (100/Full)

      ...kern.info kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

      ...kern.warn kernel: macb e000c000.ethernet eth1: unable to generate target frequency: 125000000 Hz

      ...kern.info kernel: macb e000c000.ethernet eth1: link up (1000/Full)

      ...kern.info kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

       

      The "unable to generate target frequency" error is coming of the macb_main.c file of the macb driver where it is computing a clock error to verify it is under 50 ppm, so I thought the problem must be related to the clocks used in the device tree.  Based on guidance elsewhere, I added in two lines to the clkc node:

           clocks = <&clk_phy1 0>;

           clock-names = "gem1_emio_clk";

      and created a fixed-clock node for the above lines to reference:

           clk_phy1: clock@125 {

                compatible="fixed-clock";

                #clock-cells=<0>;

                clock-frequency=<125000000>;

           };

      I also referenced the clock node as the tx_clk of the ethernet node:

           clocks = <&clkc 0x1f &clkc 0x1f &clk_phy1 0>;

           clock-names = "pclk", "hclk", "tx_clk";

       

      That got rid of the "unable to generate target frequency" message when connected to a Gigabit switch, but the error still comes up when connected to a 10/100 switch, albeit warning about 25000000 instead of 125000000.  In neither case am I actually able to transfer or receive packets at a high level, e.g., I cannot ping the device.  The "ifconfig eth1" command shows an increasing RX packet count over time.  The TX packet count is stuck at zero.  During one or more of my iterations of hacking the device tree, I was able to see both RX and TX packet counts increase, and I could use Wireshark on a PC to see that packets were being received from the device.

       

      Intuitively, it seems like using a "fixed-clock" of 125 MHz might work for a gigabit link, but won't work for a 100 mbps link which needs a 25 MHz clock.  The driver code in macb_main may be reporting the problem because the clock isn't adjustable, so is this telling me that the second ethernet port cannot be configured to handle multiple speeds?

       

      The latest iteration of my devicetree DTS file is attached for reference.  What needs to change in the devicetree configuration, driver configuration, Zynq configuration, etc., to get the second ethernet port working?

        • Re: Cannot get second Ethernet port working with PicoZed
          drozwood90

          Hi there,

           

          I don't think we ever went down that path.  We used to have a board that had the physical hardware to do that in PS, but it was revised that lost that feature before a solution was created.  The best advice I have is to use something like the Opsero FMC card operating using the PL or head over to the Xilinx forums.  I am sorry to say that I do not have anything here to help you out with running dual ethernet.

           

          --Dan

          • Re: Cannot get second Ethernet port working with PicoZed
            ejubenville

            The problem is essentially solved.  The magic configuration is:

            • Device tree has a node for the gmii2rgmii IP core included in the Zynq PL design, the fixed-clock node was removed, and the ethernet 1 node TX_CLK was reverted to the gem1 clock.
            • Kernel is built with CONFIG_XILINX_GMII2RGMII=y to enable that driver.

             

            When moving the ethernet cable from a 1000 mbps link to a 100 mbps link, the Cadence MACB driver in the kernel still reports the error shown below, but it seems to be benign.  Everything seems to work fine despite that warning.

             

              macb e000c000.ethernet eth1: unable to generate target frequency: 25000000 Hz

            2 of 2 people found this helpful