UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor jpvrensburg
Visitor
3,588 Views
Registered: ‎08-17-2017

Zynq 7015: PS GEM Through EMIO - MDIO management

We trying to implement a Gigabit Ethernet interface with an optical SFP transceiver on the Zynq 7015 device. Our plan is to use the PS Ethernet block GEM1 through the EMIO interface, along with the 1G/2.5G Ethernet PCS/PMA IP core in 1000BASE-X mode (as described in the Xilinx application note XAPP1082 – see the blue coloured path in the image provided below). Our hardware set-up is as follows:
•   TE0715 – Zynq-7000 XC7Z015 SoM
•   TEBA0841 – Carrier with SFP cage
•    Avago AFCT-5715ALZ SFP Optical transceiver


For our software set-up we use version 2016.4 for both Vivado and Petalinux.

 

xapp1082_image.png

 

The PCS/PMA IP core is set for auto-negotiation and full-duplex mode via the configuration port and we have set the phyad to 6. On the PetaLinux side we disabled GEM0 in the device-tree, and we configure GEM1 in the system-top.dts file as follows:


&gem1 {
status = "okay";
local-mac-address = [00 0a 35 00 1e 59];
phy-mode = "gmii";
ethernet-phy@6 {
compatible = "Xilinx PCS/PMA PHY";
xlnx,phy-type = <0x5>;
reg = <0x6>;
};
};


We have managed to bring-up the link, but only with the ethtool as described in this post. Before running the ifup eth1 command and requesting the PHY status using the ethtool, we get the following output:


Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:    10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes:    10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: Unknown!
Duplex: Unknown! (255)
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Link detected: no


The link speed and duplex mode are shown to be unknown. Additionally, the PHYAD is set to 0 not 6. We also noticed that during start-up the mdio bus probe will find the PCS/PMA Xilinx PHY at address 6, but would then assign it an address of 0 – as shown below:


mdio_bus e000c000.etherne:06: mdio_device_register
macb e000c000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000c000 irq 148 (00:0a:35:00:22:01)
Xilinx PCS/PMA PHY e000c000.etherne:00: attached PHY driver [Xilinx PCS/PMA PHY] (mii_bus:phy_addr=e000c000.etherne:00, irq=-1)


If we then run the ifup eth1 command in the terminal we receive the following message:


macb e000c000.ethernet eth1: unable to generate target frequency: 2500000 Hz
macb e000c000.ethernet eth1: link up (10/Half)


We have probed the MDIO lines using an oscilloscope and we found that the address portion of the MDIO transaction is always 0. We then proceeded to read back the GEM1 network configuration register using devmem 0xE000C004, the value read back is 0x010EA140. This shows that the MAC is set-up for a 10Mbps link speed and half-duplex mode. We forced the network configuration register to enable Gigabit mode and full-duplex using devmem 0xE000C004 32 0x010EA542. This causes the link to be establish and we also receive an IP from the network. At this point we can send and receive data. If we then request the PHY status using the ethtool it still says the link speed is 10Mbps and half-duplex mode, which must be incorrect. We then patched the macb driver by hard-coding the network configuration register as 0x010EA542 in the macb_handle_link_change function. This also worked.

Obviously we would like a better solution for this issue. It appears as if the problem is caused by the driver not using the correct PHY address of 6. We also tried to apply this patch to enable MDIO support for multiple PHYs from a single MAC. We using PetaLinux 2016.4 and the patch is for 2017.1 so we had to manually include the changes. This resulted in the system crashing during start-up and we didn’t pursue this avenue further. This seems to be a recurring question in the forums, but I can’t seem to find an actual solution to the problem. Any suggestions would be appreciated.

0 Kudos
2 Replies
Voyager
Voyager
3,552 Views
Registered: ‎06-24-2013

Re: Zynq 7015: PS GEM Through EMIO - MDIO management

Hey @jpvrensburg,

 

It appears as if the problem is caused by the driver not using the correct PHY address of 6.

Any suggestions would be appreciated.

Here is my suggestion:

 

Try to modify the devicetree entry to explicitly specify the phy, like this:

&gem1 {
    status = "okay";
    local-mac-address = [00 0a 35 00 1e 59];
    phy-handle = <&phy1>;
    phy-mode = "gmii";

    phy1: ethernet-phy@6 {
        compatible = "Xilinx PCS/PMA PHY";
        device_type = "ethernet-phy";
        xlnx,phy-type = <0x5>;
        reg = <0x6>;
    };
};

 

Maybe this helps,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
Highlighted
Visitor jpvrensburg
Visitor
3,512 Views
Registered: ‎08-17-2017

Re: Zynq 7015: PS GEM Through EMIO - MDIO management

Hi Herbert

 

Thanks for the suggestion. I tried modifying the devicetree as you suggested, but unfortunately it doesn't fix the problem. The start-up messages for attaching the PHY driver remains unchanged:

 

gpiod_set_value: invalid GPIO
libphy: MACB_mii_bus: probed mdio_bus e000c000.etherne:06: mdio_device_register macb e000c000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000c000 irq 148 (00:0a:35:00:22:01) Xilinx PCS/PMA PHY e000c000.etherne:00: attached PHY driver [Xilinx PCS/PMA PHY] (mii_bus:phy_addr=e000c000.etherne:00, irq=-1)

I had a look at the macb and Xilinx PHY devicetree binding documentation. They don't explicitly specify a phy-handle property.  Could it be a reset issue? I'm trying to use a GPIO to reset the PCS/PMA IP core, and I receive an invalid GPIO error during start-up. So perhaps the phyad address specified for the IP core is uninitialised.

0 Kudos