cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
2,077 Views
Registered: ‎05-08-2018

ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

The Context:

Hello,

We're doing a Linux BSP for a custom ZynqMP based target. Ethernet 3 and 4 have TI dp83867 phys over MDIO/EMIO as you can see in the example screenshot from Vivado project:

 

Vivado ConfigurationVivado Configuration

Following is our device tree configuaration over zynqmp.dtsi for both GEMs:

&gem2 {
    status = "okay";
    phy-handle = <&phy5>;
    phy-mode = "sgmii";
    local-mac-address = [00 0a 35 00 00 02];
    xlnx,ptp-enet-clock = <0x0>;
    phy5: phy@5 {
        reg = <0x5>;
        device_type = "ethernet-phy";
        ti,rx-internal-delay = <0x8>;
        ti,tx-internal-delay = <0xa>;
        ti,fifo-depth = <0x1>;
    };
};
&gem3 {
    status = "okay";
    phy-handle = <&phy9>;
    phy-mode = "sgmii";
    local-mac-address = [00 0a 36 01 01 03];
    xlnx,ptp-enet-clock = <0x0>;
    phy9: phy@9 {
        reg = <0x9>;
        device_type = "ethernet-phy";
        ti,rx-internal-delay = <0x8>;
        ti,tx-internal-delay = <0xa>;
        ti,fifo-depth = <0x1>;
    };
};

The Problem:

Despite these seemingly correct configs, and that fact that both phys are discovered and GEM2 and GEM3 configured in the same way, only GEM2 works

root@zynqmp:~# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 5
        Transceiver: internal
        Auto-negotiation: on
        Link detected: no
root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 9
        Transceiver: internal
        Auto-negotiation: on
        Link detected: no

Link change is always detected, but there are no interrupts on GEM3.

root@zynqmp:~# grep eth /proc/interrupts 
 31:        167          0          0          0     GICv2  93 Level     eth0, eth0
 32:          0          0          0          0     GICv2  95 Level     eth1, eth1

I've also verified the configuration registers for both GEMs which are exactly the same, as expected. The status registers however differ in that pcs_link_state is always shown 0 for GEM3, despite auto-negotiation being 'on'.

root@zynqmp:~# devmem2 0xFF0D0004 w                                                                                                                                                                     
/dev/mem opened.
Memory mapped at address 0x7f9f41e000.
Read at address  0xFF0D0004 (0x7f9f41e004): 0x092EAC4A
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xFF0E0004 w                                                                                                                                                                     
/dev/mem opened.
Memory mapped at address 0x7f87fce000.
Read at address  0xFF0E0004 (0x7f87fce004): 0x092EAC4A
root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xFF0D0008 w                                                                                                                                                                     
/dev/mem opened.
Memory mapped at address 0x7fb4377000.
Read at address  0xFF0D0008 (0x7fb4377008): 0x00000007
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xFF0E0008 w                                                                                                                                                                     
/dev/mem opened.
Memory mapped at address 0x7f88cef000.
Read at address  0xFF0E0008 (0x7f88cef008): 0x00000006

What could be the reason for no connectivity on GEM3?

0 Kudos
25 Replies
Highlighted
Moderator
Moderator
2,051 Views
Registered: ‎09-12-2007

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Mommon MDIO is added in 2019.1. Please update your devicetree as shown in the wiki below:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver

0 Kudos
Highlighted
Visitor
Visitor
2,043 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Hi. Thanks for your quick response. However, I believe there's some misunderstanding. I'm not using a common MDIO bus for two PHYs. Both PHYs are on a separate GEM, with different MDIO busses (MDIO 2 and MDIO 3).

0 Kudos
Highlighted
Moderator
Moderator
2,014 Views
Registered: ‎09-12-2007

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

So, just to clarify. You cannot ping on eth1.

 

If you disable the GEM2 in the system-user.dtsi does this work? Im trying to see if the issue is due to two PHY,

or the second PHY isnt working at all

0 Kudos
Highlighted
Visitor
Visitor
2,012 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Yes, I've already tried disabling GEM2 but that doesn't change anything for GEM3

0 Kudos
Highlighted
Moderator
Moderator
2,002 Views
Registered: ‎09-12-2007

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Are you using SGMII, or RGMII?

&gem3 {
    status = "okay";
    phy-handle = <&phy9>;
    phy-mode = "sgmii";
    local-mac-address = [00 0a 36 01 01 03];
    xlnx,ptp-enet-clock = <0x0>;
    phy9: phy@9 {
        reg = <0x9>;
        device_type = "ethernet-phy";
        ti,rx-internal-delay = <0x8>;
        ti,tx-internal-delay = <0xa>;
        ti,fifo-depth = <0x1>;
    };

Those TI phy tuning properties are for RGMII:

https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/net/ti%2Cdp83867.txt

0 Kudos
Highlighted
Visitor
Visitor
2,000 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Using SGMII. Those got copied over from GEM 0 and 1which are operating in RGMII mode.

0 Kudos
Highlighted
Moderator
Moderator
1,995 Views
Registered: ‎09-12-2007

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Can you do a mii dump 0x9 0-5.

Can you send a screenshot of the clocks?

0 Kudos
Highlighted
Visitor
Visitor
1,916 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

> Can you do a mii dump 0x9 0-5.

I figure you mean to run this command in U-Boot; I've not configured these interfaces in U-Boot.

> Can you send a screenshot of the clocks?

I've requested for this information internally, and will share as soon as I get it.

0 Kudos
Highlighted
Moderator
Moderator
1,910 Views
Registered: ‎09-12-2007

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Yes, this is a uboot utility (similar to ethtool). Can you try this please?

0 Kudos
Highlighted
Visitor
Visitor
1,879 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

To run this, I've configured these PHYs in U-Boot device-tree. Here's the dump that you requested:

ZynqMP> mii dump 0x9 0-5
0.     (ffff)                 -- PHY control register --
  (8000:8000) 0.15    =     1    reset
  (4000:4000) 0.14    =     1    loopback
  (2040:2040) 0. 6,13 =   b11    speed selection = 10 Mbps
  (1000:1000) 0.12    =     1    A/N enable
  (0800:0800) 0.11    =     1    power-down
  (0400:0400) 0.10    =     1    isolate
  (0200:0200) 0. 9    =     1    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0080) 0. 7    =     1    collision test enable
  (003f:003f) 0. 5- 0 =    63    (reserved)

1.     (ffff)                 -- PHY status register --
  (8000:8000) 1.15    =     1    100BASE-T4 able
  (4000:4000) 1.14    =     1    100BASE-X  full duplex able
  (2000:2000) 1.13    =     1    100BASE-X  half duplex able
  (1000:1000) 1.12    =     1    10 Mbps    full duplex able
  (0800:0800) 1.11    =     1    10 Mbps    half duplex able
  (0400:0400) 1.10    =     1    100BASE-T2 full duplex able
  (0200:0200) 1. 9    =     1    100BASE-T2 half duplex able
  (0100:0100) 1. 8    =     1    extended status
  (0080:0080) 1. 7    =     1    (reserved)
  (0040:0040) 1. 6    =     1    MF preamble suppression
  (0020:0020) 1. 5    =     1    A/N complete
  (0010:0010) 1. 4    =     1    remote fault
  (0008:0008) 1. 3    =     1    A/N able
  (0004:0004) 1. 2    =     1    link status
  (0002:0002) 1. 1    =     1    jabber detect
  (0001:0001) 1. 0    =     1    extended capabilities

2.     (ffff)                 -- PHY ID 1 register --
  (ffff:ffff) 2.15- 0 = 65535    OUI portion

3.     (ffff)                 -- PHY ID 2 register --
  (fc00:fc00) 3.15-10 =    63    OUI portion
  (03f0:03f0) 3. 9- 4 =    63    manufacturer part number
  (000f:000f) 3. 3- 0 =    15    manufacturer rev. number

4.     (ffff)                 -- Autonegotiation advertisement register --
  (8000:8000) 4.15    =     1    next page able
  (4000:4000) 4.14    =     1    (reserved)
  (2000:2000) 4.13    =     1    remote fault
  (1000:1000) 4.12    =     1    (reserved)
  (0800:0800) 4.11    =     1    asymmetric pause
  (0400:0400) 4.10    =     1    pause enable
  (0200:0200) 4. 9    =     1    100BASE-T4 able
  (0100:0100) 4. 8    =     1    100BASE-TX full duplex able
  (0080:0080) 4. 7    =     1    100BASE-TX able
  (0040:0040) 4. 6    =     1    10BASE-T   full duplex able
  (0020:0020) 4. 5    =     1    10BASE-T   able
  (001f:001f) 4. 4- 0 =    31    selector = ???

5.     (ffff)                 -- Autonegotiation partner abilities register --
  (8000:8000) 5.15    =     1    next page able
  (4000:4000) 5.14    =     1    acknowledge
  (2000:2000) 5.13    =     1    remote fault
  (1000:1000) 5.12    =     1    (reserved)
  (0800:0800) 5.11    =     1    asymmetric pause able
  (0400:0400) 5.10    =     1    pause able
  (0200:0200) 5. 9    =     1    100BASE-T4 able
  (0100:0100) 5. 8    =     1    100BASE-X full duplex able
  (0080:0080) 5. 7    =     1    100BASE-TX able
  (0040:0040) 5. 6    =     1    10BASE-T full duplex able
  (0020:0020) 5. 5    =     1    10BASE-T able
  (001f:001f) 5. 4- 0 =     31    selector = ???
0 Kudos
Highlighted
Visitor
Visitor
1,801 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Hi,

Any update considering the mii dump?

You can find the GEM clock configuration that we're using, below.Selection_195.png

0 Kudos
Highlighted
Visitor
Visitor
1,777 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Hello,

Is there an update on this?

0 Kudos
Highlighted
Moderator
Moderator
1,755 Views
Registered: ‎09-12-2007

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

So, according to the mii dump you are reading all f's. So, either the Phy Address is incorrect (ie not 0x9), or there is an issue with the PHY itself and it cannot be read.

Can you verify that the PHY address is correct?

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/145031176/Reading+PHY+registers+over+MDIO+via+the+PHY+Management+GEM+Register

Is the PHY held in reset?

0 Kudos
Highlighted
Visitor
Visitor
1,689 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Both PHYs are readable under Linux:

root@zynqmp:~# ip link set dev eth0 down
[   67.707281] macb ff0d0000.ethernet: gem-ptp-timer ptp clock unregistered.
root@zynqmp:~# 
root@zynqmp:~# ip link set dev eth1 down                                                                                                                                                                
[   73.007230] macb ff0e0000.ethernet: gem-ptp-timer ptp clock unregistered.
root@zynqmp:~# [   73.408005] macb ff0e0000.ethernet eth1: link down

root@zynqmp:~# 
root@zynqmp:~# dmesg | grep PHY
[    3.394146] ahci-ceva fd0c0000.ahci: couldn't get PHY in node ahci: -517
[    3.502403] TI DP83867 ff0d0000.ethernet-ffffffff:05: attached PHY driver [TI DP83867] (mii_bus:phy_addr=ff0d0000.ethernet-ffffffff:05, irq=POLL)
[    3.538523] TI DP83867 ff0e0000.ethernet-ffffffff:09: attached PHY driver [TI DP83867] (mii_bus:phy_addr=ff0e0000.ethernet-ffffffff:09, irq=POLL)
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0e0000 w 0x00000010
/dev/mem opened.
Memory mapped at address 0x7fb1ac5000.
Read at address  0xFF0E0000 (0x7fb1ac5000): 0x00000000
Write at address 0xFF0E0000 (0x7fb1ac5000): 0x00000010, readback 0x00000010
root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0e0034 w 0x1A420000          # This is GEM3 PHY at addr 1001 (011010010000100000000000000000)                                                                                                                                                                                                                                                                                                                
/dev/mem opened.
Memory mapped at address 0x7f87677000.
Read at address  0xFF0E0034 (0x7f87677034): 0x54820800
Write at address 0xFF0E0034 (0x7f87677034): 0x1A420000, readback 0x1A420000
root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0e0034 
/dev/mem opened.
Memory mapped at address 0x7f9f253000.
Read at address  0xFF0E0034 (0x7f9f253034): 0x1A420000
root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0d0000 w 0x00000010          
/dev/mem opened.
Memory mapped at address 0x7f93542000.
Read at address  0xFF0D0000 (0x7f93542000): 0x00000000
Write at address 0xFF0D0000 (0x7f93542000): 0x00000010, readback 0x00000010
root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0d0034 w 0x19420000          # This is GEM2 PHY at addr 1010 (011001010000100000000000000000)                                                                                                                                                                                                                                                                                                                                                                                                                                                               
/dev/mem opened.
Memory mapped at address 0x7f8e2dd000.
Read at address  0xFF0D0034 (0x7f8e2dd034): 0x629201E1
Write at address 0xFF0D0034 (0x7f8e2dd034): 0x19420000, readback 0x19420000
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0d0034 
/dev/mem opened.
Memory mapped at address 0x7f9dbd9000.
Read at address  0xFF0D0034 (0x7f9dbd9034): 0x19420000

Not sure what's the issue in U-Boot as it seems the other PHY for GEM2 is also not readable there; I just added the same Linux device tree changes as above, to U-Boot device tree.

Net:   ZYNQ GEM: ff0d0000, phyaddr 5, interface sgmii
Could not get PHY for eth2: addr 5
No ethernet found.

I did this just to get mii dump, otherwise we don't need this Ethernet supported in U-Boot.

0 Kudos
Highlighted
Visitor
Visitor
1,625 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Can you let me know what could be inferred from pcs_link_state shown 0 in GEM3 status register.

0 Kudos
Highlighted
Visitor
Visitor
1,564 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

ping!

0 Kudos
Highlighted
Moderator
Moderator
1,457 Views
Registered: ‎12-04-2016

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Hi @ahussain 

If you haven't tried, Can you please check if GEM3 works with the LWIP application project that comes with SDK?

If this fails here, then probably we will have to revisit the GEM3 configuration in the design.

 

Best Regards

Shabbir

0 Kudos
Highlighted
Moderator
Moderator
1,442 Views
Registered: ‎09-12-2007

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Looks like the PHY is getting read correctly over the MDIO:

 

[    3.502403] TI DP83867 ff0d0000.ethernet-ffffffff:05: attached PHY driver [TI DP83867] (mii_bus:phy_addr=ff0d0000.ethernet-ffffffff:05, irq=POLL)
[    3.538523] TI DP83867 ff0e0000.ethernet-ffffffff:09: attached PHY driver [TI DP83867] (mii_bus:phy_addr=ff0e0000.ethernet-ffffffff:09, irq=POLL)

Can you dump the GEM registers:

GEM2 Base  ff0d0000

GEM3 Base ff0e0000

  • Network Control (offset 0x0)
  • Network Config (offset 0x4)
  • Network Status (offset 0x8)
  • PCS Control (offset 0x200)
  • PCS Status (offset 0x204)

https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html

 

0 Kudos
Highlighted
Visitor
Visitor
1,416 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Here's the dump:

GEM2
----

root@zynqmp:~# devmem2 0xff0d0000
/dev/mem opened.
Memory mapped at address 0x7fbdb63000.
Read at address  0xFF0D0000 (0x7fbdb63000): 0x0010001C
root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0d0004
/dev/mem opened.
Memory mapped at address 0x7f90a69000.
Read at address  0xFF0D0004 (0x7f90a69004): 0x092EAC4A
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0d0008
/dev/mem opened.
Memory mapped at address 0x7f99977000.
Read at address  0xFF0D0008 (0x7f99977008): 0x00000007
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0d0200
/dev/mem opened.
Memory mapped at address 0x7f80cb2000.
Read at address  0xFF0D0200 (0x7f80cb2200): 0x00001140
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0d0204
/dev/mem opened.
Memory mapped at address 0x7fa9f8e000.
Read at address  0xFF0D0204 (0x7fa9f8e204): 0x00000129



GEM3
----

root@zynqmp:~# devmem2 0xff0e0000
/dev/mem opened.
Memory mapped at address 0x7faa416000.
Read at address  0xFF0E0000 (0x7faa416000): 0x0010001C
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0e0004
/dev/mem opened.
Memory mapped at address 0x7fbb46b000.
Read at address  0xFF0E0004 (0x7fbb46b004): 0x092EAC4A
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0e0008
/dev/mem opened.
Memory mapped at address 0x7f82c63000.
Read at address  0xFF0E0008 (0x7f82c63008): 0x00000006
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0e0200 
/dev/mem opened.
Memory mapped at address 0x7fa3cb9000.
Read at address  0xFF0E0200 (0x7fa3cb9200): 0x00001140
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0e0204
/dev/mem opened.
Memory mapped at address 0x7f93a7e000.
Read at address  0xFF0E0204 (0x7f93a7e204): 0x00000109
0 Kudos
Highlighted
Moderator
Moderator
1,408 Views
Registered: ‎09-12-2007

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Next is to test the clocks. We can use the GT Loopback and look at the rx/rx packet counters in ifconfig

To do this, can you boot as far a uboot, and do the following:

  • mw 0xfd41003c 0x00000011
  • boot

Then can you bring the GEM2, and GEM3 up and look at teh RX/TX packets:

ifconfig.PNG

You can also do a devmem of the pcs_status (twice) again to see the link_status

pce_status.PNG

 

0 Kudos
Highlighted
Visitor
Visitor
1,399 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

What register is at 0xfd41003c? I did the mw in U-Boot, but get no tx/rx packets on GEM2 or GEM3 in Linux; that is untill I connect the Ethernet cable. Even then I get the packets on GEM2 only.

pcs_status didn't change from my last run.

 

[  442.895533] macb ff0d0000.ethernet eth0: link up (1000/Full)

root@zynqmp:~# 
root@zynqmp:~# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0a:35:00:00:02  
          UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1328 (1.2 KiB)  TX bytes:1370 (1.3 KiB)
          Interrupt:30 

root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# [  457.221608] macb ff0d0000.ethernet eth0: link down

root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# [  463.375734] macb ff0e0000.ethernet eth1: link up (1000/Full)

root@zynqmp:~# 
root@zynqmp:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:0a:36:01:01:03  
          UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:31 

root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0d0008
/dev/mem opened.
Memory mapped at address 0x7fbbf1b000.
Read at address  0xFF0D0008 (0x7fbbf1b008): 0x00000007
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0d0008
/dev/mem opened.
Memory mapped at address 0x7fa0f33000.
Read at address  0xFF0D0008 (0x7fa0f33008): 0x00000007
root@zynqmp:~# 
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0e0008                                                                                                                                                                       
/dev/mem opened.
Memory mapped at address 0x7fa91aa000.
Read at address  0xFF0E0008 (0x7fa91aa008): 0x00000006
root@zynqmp:~# 
root@zynqmp:~# devmem2 0xff0e0008
/dev/mem opened.
Memory mapped at address 0x7f9cd19000.
Read at address  0xFF0E0008 (0x7f9cd19008): 0x00000006

By the way, we're running TSN Ethernet on GEM 0 and GEM 1, if this information helps.

0 Kudos
Highlighted
Moderator
Moderator
1,392 Views
Registered: ‎09-12-2007

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

This places the GT into loopback. You dont need to connect the cable. If you dont see the counters increase, then it could be a HW issue.

 

Can you send a screenshot of your Vivado settings for the Zynq Ultrascale PSU?

0 Kudos
Highlighted
Visitor
Visitor
1,389 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

>If you dont see the counters increase, then it could be a HW issue.

But GEM2 works for me as expected.

 

>Can you send a screenshot of your Vivado settings for the Zynq Ultrascale PSU?

I've shared both the PS and CLK settings from Vivado earlier in the thread. Do you need something else?

0 Kudos
Highlighted
Visitor
Visitor
1,376 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

> But GEM2 works for me as expected.

This is before I put the GT in loopback.

0 Kudos
Highlighted
Visitor
Visitor
1,111 Views
Registered: ‎05-08-2018

Re: ZynqMP, TI dp83867 on MDIO/EMIO, SGMII GEM through PS-GTR issue

Hello,

We've resolved the issue on our end. Without investigating into the details, this could be an issue with GTR PHY driver in Linux. We were using GTR lane 3 for ahci before design was updated for lane 3 to be used by GEM3:

 

&sata {
    phys = <&lane3 PHY_TYPE_SATA 1 1 125000000>;
}

 

In current configuration, after the PHY can't be assigned to SATA, it doesn't work for GEM3 either:

ahci-ceva fd0c0000.ahci: couldn't get PHY in node ahci: -517

That's why we don't get any packets on GEM3; removing the phys property from ahci node seems to fix the issue with GEM3.

Do we really need the phys property, if even without it the peripherals configured to use GTR continue to work fine?

0 Kudos