cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ian@lang
Contributor
Contributor
7,487 Views
Registered: ‎01-11-2019

Gmii-to-Rgmii driver

Jump to solution

I have posted on this problem before but unfortunately I got no responses.  Therefore, I'm posting again in the hope of getting a suggestion, or even just some clues as to what I should try next.   

I have an image with one MIO based Ethernet connection a second EMIO based Ethernet connection that uses the Gmii-to-Rgmii IP between the PS and the Ethernet PHY.  The MIO Ethernet works well but the EMIO link doesn't seem to be properly recognised by u-boot/Linux, even though, as far as I can tell, the hardware is working correctly. 

1)  I can set the link speed register inside the gmii to rgmii and read it back. 

Zynq> mii device eth1 

Zynq> mii read 0xa 

0000 

Zynq> mii write 0xa 10 0x0040 

Zynq> mii read 0xa 

0040  

2)  I can read the PHY status over the MDIO and see that the link is up. 

Zynq> mii device eth1 

Zynq> mii dump 7 1 

  1. (796d)                 -- PHY status register --

  (8000:0000) 1.15    =     0    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:0000) 1.10    =     0    100BASE-T2 full duplex able 

  (0200:0000) 1. 9    =     0    100BASE-T2 half duplex able 

  (0100:0100) 1. 8    =     1    extended status 

  (0080:0000) 1. 7    =     0    (reserved) 

  (0040:0040) 1. 6    =     1    MF preamble suppression 

  (0020:0020) 1. 5    =     1    A/N complete 

  (0010:0000) 1. 4    =     0    remote fault 

  (0008:0008) 1. 3    =     1    A/N able 

  (0004:0004) 1. 2    =     1    link status 

  (0002:0000) 1. 1    =     0    jabber detect 

  (0001:0001) 1. 0    =     1    extended capabilities  

3)  I can even ping through the link if I disconnect the other Ethernet.

Zynq> setenv ipaddr 192.168.0.235 

Zynq> ping 192.168.0.234 

ethernet@e000b000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! 

Using ethernet@e000c000 device 

host 192.168.0.234 is alive   

But for some reason U-BOOT doesn't seem to be able to attach a driver: 

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

macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 28 (00:0a:35:00:22:01) 

libphy: MACB_mii_bus: probed 

xgmiitorgmii e000c000.ethernet-ffffffff:0a: Couldn't find phydev 

macb: probe of e000c000.ethernet failed with error –16 

And of course, Linux sees only one Ethernet link. 

As far as I know, my device tree is ok.  But I have been unable to figure out the meaning of error –16.  Is there a place I can find out?  Or do I somehow need to try to debug the boot?   And if so how? 

0 Kudos
1 Solution

Accepted Solutions
ian@lang
Contributor
Contributor
5,566 Views
Registered: ‎01-11-2019

I said to @kwy4262  that I'd post a solution to this thread, when/if I ever found one.  Not least, because so many threads on this site don't seem to reach a successful conculsion, which can be very frustrating.  Anyway, finally, I got there!

So, as @nanz said, above, it was indeed something very small.  But enough to keep me stuck for a long time.  So what was it?  Well actually, kind of nothing.  As I said above, ifconfig was not reporting eth1, even though it could be found in u-boot using mii.   This led me to believe that Linux was not recognising the interface:

root@os:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0A:35:00:22:01
inet6 addr: 2a02:8388:6901:c300:20a:35ff:fe00:2201/64 Scope:Global
inet6 addr: fe80::20a:35ff:fe00:2201/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:304 (304.0 B) TX bytes:1766 (1.7 KiB)
Interrupt:28 Base address:0xb000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 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)

However, an additional -a argument was all it took to reveals the other link:

root@os:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0A:35:00:22:01
inet addr:192.168.0.59 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: 2a02:8388:6901:c300:20a:35ff:fe00:2201/64 Scope:Global
inet6 addr: fe80::20a:35ff:fe00:2201/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1502 (1.4 KiB) TX bytes:3014 (2.9 KiB)
Interrupt:28 Base address:0xb000

eth1 Link encap:Ethernet HWaddr E2:93:DE:A1:8B:5E
BROADCAST MULTICAST 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:29 Base address:0xc000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 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)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 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)

And a simple ifup eth1 brings the link up immediately:

root@os:~# ifup eth1
IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
udhcpc: started, v1.29.2
udhcpc: sending discover
macb e000c000.ethernet eth1: unable to generate target frequency: 125000000 Hz
macb e000c000.ethernet eth1: link up (1000/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
udhcpc: sending discover
udhcpc: sending select for 192.168.0.227
udhcpc: lease of 192.168.0.227 obtained, lease time 3600
RTNETLINK answers: File exists
/etc/udhcpc.d/50default: Adding DNS 192.168.0.1
root@os:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0A:35:00:22:01
inet addr:192.168.0.59 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: 2a02:8388:6901:c300:20a:35ff:fe00:2201/64 Scope:Global
inet6 addr: fe80::20a:35ff:fe00:2201/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2280 (2.2 KiB) TX bytes:3942 (3.8 KiB)
Interrupt:28 Base address:0xb000

eth1 Link encap:Ethernet HWaddr E2:93:DE:A1:8B:5E
inet addr:192.168.0.227 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::e093:deff:fea1:8b5e/64 Scope:Link
inet6 addr: 2a02:8388:6901:c300:e093:deff:fea1:8b5e/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1392 (1.3 KiB) TX bytes:1404 (1.3 KiB)
Interrupt:29 Base address:0xc000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 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)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 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)

So there you are, who would have thought it?  There is also another red herring that threw me of course.  And that is, as far as I can tell, that there is no need of any mention of the xlnx,gmii-to-rgmii-1.0 in the device tree.  Even when I remove all trace of it, the PHY is initialised correctly.  But the "couldn't find phydev" message appears as ever, apparently not causing a problem.  That had me very confused:

libphy: MACB_mii_bus: probed
Marvell 88E1510 e000b000.ethernet-ffffffff:00: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=e000b000.ethernet-ffffffff:00, irq=POLL)
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 28 (00:0a:35:00:22:01)
libphy: MACB_mii_bus: probed
xgmiitorgmii e000c000.ethernet-ffffffff:1f: Couldn't find phydev
Marvell 88E1116R e000c000.ethernet-ffffffff:07: attached PHY driver [Marvell 88E1116R] (mii_bus:phy_addr=e000c000.ethernet-ffffffff:07, irq=POLL)
macb e000c000.ethernet eth1: Cadence GEM rev 0x00020118 at 0xe000c000 irq 29 (e2:93:de:a1:8b:5e)

My working device tree looks like as follows:

/include/ "system-conf.dtsi"
/ {
};


&gem1 {
phy-handle = <&phy1>;

status = "okay";
xlnx,ptp-enet-clock = <0x4f790d8>;
ps7_ethernet_1_mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
phy1: phy@7 {
/* compatible = "marvell,88e1510,88e1118r"; */
device_type = "ethernet-phy";
phy-mode = "rgmii-id";
reg = <7>;
};
};
};

One last surprise:  if I switch to an Ubuntu root file system, it is not even necessary to do ifup eth1; the link comes up automatically.

I sincerly hope this answer is of help to other people having difficulties getting the gmii-to-rgmii IP working with Linux.  It does seem to be the subject of very many posts.  I particularly recommend taking a look at the attached working transcript.

Ian Lang

View solution in original post

Tags (1)
33 Replies
nanz
Moderator
Moderator
7,100 Views
Registered: ‎08-25-2009

Hi ian@lang ,

What does your DTS look like?

Here is an exmample:

mdio {
    #address-cells = <1>;
    #size-cells = <0>;
    phy: ethernet-phy@0 {
        ......
    };
    gmiitorgmii: gmiitorgmii@8 {
        compatible = "xlnx,gmii-to-rgmii-1.0";
        reg = <8>;
        phy-handle = <&phy>;
    };
};

Have you tried in Linux rather than in UBOOT?

 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
7,061 Views
Registered: ‎05-27-2019

Hi Nanz,

Thank you very much for the reply.  I've not yet had a chance to try your changes to the device tree (hopefully later today).  But here's the device tree that I'm using presently:

&gem1 { 

       phy-handle = <&phy1>; 

       gmii2rgmii-phy-handle = <&gmiitorgmii>; 

       phy-mode = "rgmii-rxid"; 

       status = "okay"; 

       xlnx,has-mdio = <0x1>; 

       ps7_ethernet_1_mdio: mdio { 

                                 phy1: phy@7 { 

                                             compatible = "marvell,88e1118r"; 

                                             device_type = "ethernet-phy"; 

                                             reg = <7>; 

                                             }; 

                                 gmiitorgmii: gmiitorgmii@10 { 

                                             compatible = "xlnx,gmii-to-rgmii-4.0"; 

                                             reg = <10>; 

                                             phy-handle = <&phy1>; 

                                             }; 

                                 }; 

       }; 

However, I have a couple of questions regarding the numbers in the device tree above:

1)  The gmii-to-rgmii is configured to MIDIO address 10.  Is it correctly configured as shown green above?  Or does the number mean something else?

2) The PHY is hard coded on the PCB to MDIO address 7.  Is it correctly configured as shown red above?

Other than that, my device tree looks similar to yours.

As for the trying the same thing in Linux, as far as I understand it, mii read and mii write are u-boot commands.  How is the same thing achieved in Linux?

If I do ifconfig in Linux, I see only eth0 but not eth1:

root@os:~# ifconfig 

eth0      Link encap:Ethernet  HWaddr 00:0A:35:00:22:01 

          inet addr:192.168.0.59  Bcast:192.168.0.255  Mask:255.255.255.0 

          inet6 addr: 2a02:8388:6901:c300:20a:35ff:fe00:2201/64 Scope:Global 

          inet6 addr: fe80::20a:35ff:fe00:2201/64 Scope:Link 

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 

          RX packets:5 errors:0 dropped:0 overruns:0 frame:0 

          TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 

          collisions:0 txqueuelen:1000 

          RX bytes:1456 (1.4 KiB)  TX bytes:3316 (3.2 KiB) 

          Interrupt:28 Base address:0xb000 

  

lo        Link encap:Local Loopback 

          inet addr:127.0.0.1  Mask:255.0.0.0 

          inet6 addr: ::1/128 Scope:Host 

          UP LOOPBACK RUNNING  MTU:65536  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) 

I look forwards to your further response.

Regards,

Ian

nanz
Moderator
Moderator
7,019 Views
Registered: ‎08-25-2009

Hi ian.lang@elektrobit.com ,

Yes, the MDIO PHY regsiters are correctly set for both external PHY and GMII2RGMII. Can you please send the complete linux log file to take a look?

Regarding the PHY mode, I just want to make sure in your case the internal RX delay is provided by the PHY but not on the TX side as you have "rgmii-rxid"? Are you able to access GMII2RGMII and external PHY's register space?

 

 

 

 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
6,992 Views
Registered: ‎05-27-2019

Hi Nanz,

Great that you are taking the time to help with this issue, thank you.  Please find answers to your questions below.

Ok, I presume, by the Linux log file, you mean the boot transcript.  I've attached that.  I've also attached the (user) device tree file and a screenshot of the IP customization GUI for the Gmii to Rgmii module.  You can see that I've ticked "Skew added by PHY", which I believe is correct for phy-mode = "rgmii-rxid".

As for the PHY register space, yes, I can dump the contents of the registers from within u-boot:

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

1. (7949) -- PHY status register --
(8000:0000) 1.15 = 0 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:0000) 1.10 = 0 100BASE-T2 full duplex able
(0200:0000) 1. 9 = 0 100BASE-T2 half duplex able
(0100:0100) 1. 8 = 1 extended status
(0080:0000) 1. 7 = 0 (reserved)
(0040:0040) 1. 6 = 1 MF preamble suppression
(0020:0000) 1. 5 = 0 A/N complete
(0010:0000) 1. 4 = 0 remote fault
(0008:0008) 1. 3 = 1 A/N able
(0004:0000) 1. 2 = 0 link status
(0002:0000) 1. 1 = 0 jabber detect
(0001:0001) 1. 0 = 1 extended capabilities

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

3. (0e40) -- PHY ID 2 register --
(fc00:0c00) 3.15-10 = 3 OUI portion
(03f0:0240) 3. 9- 4 = 36 manufacturer part number
(000f:0000) 3. 3- 0 = 0 manufacturer rev. number

4. (01e1) -- Autonegotiation advertisement register --
(8000:0000) 4.15 = 0 next page able
(4000:0000) 4.14 = 0 (reserved)
(2000:0000) 4.13 = 0 remote fault
(1000:0000) 4.12 = 0 (reserved)
(0800:0000) 4.11 = 0 asymmetric pause
(0400:0000) 4.10 = 0 pause enable
(0200:0000) 4. 9 = 0 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:0001) 4. 4- 0 = 1 selector = IEEE 802.3

5. (0000) -- Autonegotiation partner abilities register --
(8000:0000) 5.15 = 0 next page able
(4000:0000) 5.14 = 0 acknowledge
(2000:0000) 5.13 = 0 remote fault
(1000:0000) 5.12 = 0 (reserved)
(0800:0000) 5.11 = 0 asymmetric pause able
(0400:0000) 5.10 = 0 pause able
(0200:0000) 5. 9 = 0 100BASE-T4 able
(0100:0000) 5. 8 = 0 100BASE-X full duplex able
(0080:0000) 5. 7 = 0 100BASE-TX able
(0040:0000) 5. 6 = 0 10BASE-T full duplex able
(0020:0000) 5. 5 = 0 10BASE-T able
(001f:0000) 5. 4- 0 = 0 selector = ???

I've also checked that I can write registers.   So, for example, if I write to the reset bit (mii write 7 0 0x9000) I can see that the link goes down and then in a few seconds comes back up to full duplex (because I have LEDs decoded from the Gmii to Rgmii outputs as shown below).  The clock_speed LED indicates 1000Mbit/s.

LED <= OFF & OFF & OFF & OFF;

if mmcm_locked_out = '1' then
LED(1 downto 0) <= GREEN;
else
LED(1 downto 0) <= RED;
end if;

if link_status = '1' then
if duplex_status = '0' then -- Half Duplex
LED(3 downto 2) <= ORANGE;
else -- Full Duplex
LED(3 downto 2) <= GREEN;
end if;
else
LED(3 downto 2) <= RED;
end if;

case speed_mode is
when "11" => LED(5 downto 4) <= OFF;
when "00" => LED(5 downto 4) <= RED; -- 10 Mbit/s
when "01" => LED(5 downto 4) <= ORANGE; -- 100 Mbit/s
when "10" => LED(5 downto 4) <= GREEN; -- 1000 Mbit/s
when others =>
end case;

case clock_speed is
when "11" => LED(7 downto 6) <= OFF;
when "00" => LED(7 downto 6) <= RED; -- 10 Mbit/s
when "01" => LED(7 downto 6) <= ORANGE; -- 100 Mbit/s
when "10" => LED(7 downto 6) <= GREEN; -- 1000 Mbit/s
when others =>
end case;

Finally, yes, I can also read and write the GMII2RGMII register:

Zynq> mii read 0xA 10
0000
Zynq> mii write 0xA 10 0x0040
Zynq> mii read 0xA 10
0040
Zynq>

The above write results in the speed_mode LED going to green (1000Mbit/s), whereupon all four LEDs are green.  So I've checked everything I know how to check.  But still u-boot and Linux stubbornly refuse to recognize the link.

Gmii to Rgmii customization.png
0 Kudos
nanz
Moderator
Moderator
6,929 Views
Registered: ‎08-25-2009

Hi ian@lang ,

Could you please try with phy-mode = "rgmii-id" instead? I assume there are some additional RGMII tunning that need to be done. It looks like regsiters accessing to GMII2RGMII is correct and the registers are updated when AN with the external RGMII PHY.

For the bootlog, I'd like to see after Linux is booted from the SD card, all the output in the console. Could you please screenshot that and attach it?

 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
ian@lang
Contributor
Contributor
6,924 Views
Registered: ‎01-11-2019

Hello @nanz 

Thank you for your reply.  As for the transcript, I think I've already attached everything that is output to the transcript when booting from SD - from power up to logging into Linux and typing ifconfig.  The file is called transcript.txt and is already attached (see above).  Is there some other output that I could add?

I will try rgmii-id and see if it changes things.

As a question, are you suggesting that timing problems on the RGMII interface might cause u-boot/Linux to not recognise the link?  Or would that happen if it were not able to access the appropriate registers?

Ian

0 Kudos
nanz
Moderator
Moderator
6,914 Views
Registered: ‎08-25-2009
Could you try with phy-mode="gmii" actually as for GEM1 it's using GMII and connecting to GMIi2RGMII PHY.
Sorry I missed the transcript and only saw the devicetree attachment.

-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
ian@lang
Contributor
Contributor
6,905 Views
Registered: ‎01-11-2019
No worries; the transcript was a little lost among everything else. Thanks for the quick reply. I'll try out phy-mode="gmii" and get back to you with the result.
Ian
0 Kudos
6,886 Views
Registered: ‎05-27-2019

Hi @nanz ,

I tried out phy-mode="gmii" and the transcript is attached.  It didn't help unfortunately.

Regards

Ian

 

0 Kudos
nanz
Moderator
Moderator
6,784 Views
Registered: ‎08-25-2009

Hi ian@lang ,

Which kernel version are you using? Could you please take a look at the following post and see if this helps?

https://forums.xilinx.com/t5/Embedded-Linux/GMII2RGMII-Ethernet-gem1-with-Kernel-4-19-not-working-with/td-p/993620

 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
6,694 Views
Registered: ‎05-27-2019

Hi @nanz ,

Thank you for your reply. The kernel version is as follows:

root@os:~# uname -a
Linux os 4.19.0-xilinx #1 SMP PREEMPT Sun Oct 6 22:10:48 UTC 2019 armv7l GNU/Linux

However, I'm not sure that the kernel is the cause because I have managed to get a build to attach the driver for eth1, but by using the gmii2rgmii core as an encapsulated example design, rather than instantiated vanilla. I don't yet understand why that made  a difference and I'm working on getting to the bottom of it:

Marvell 88E1510 e000b000.ethernet-ffffffff:00: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=e000b000.ethernet-ffffffff:00, irq=POLL)
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 28 (00:0a:35:00:1e:53)
libphy: MACB_mii_bus: probed
Marvell 88E1116R e000c000.ethernet-ffffffff:07: attached PHY driver [Marvell 88E1116R] (mii_bus:phy_addr=e000c000.ethernet-ffffffff:07, irq=POLL)
macb e000c000.ethernet eth1: Cadence GEM rev 0x00020118 at 0xe000c000 irq 29 (c2:92:1b:ee:5a:8e)

Moreover, the driver still doesn't seem correct because I can see, using my LEDs, that when it gets attached, it is causing the link to go from link up to link down!  This seems very strange, unless perhaps it is programming the PHY timing incorrectly. Does this sound likely?

I will come back to you when I have done some further investigation.

Thanks, Ian

0 Kudos
6,689 Views
Registered: ‎05-27-2019
Additionally, eth1 is still not reported by ifconfig. So progress but no cigar :)
0 Kudos
nanz
Moderator
Moderator
6,642 Views
Registered: ‎08-25-2009

Hi ian@lang ,

For eth1, it should not be Marvel PHY driver but gmii2rgmii? 

Marvell 88E1116R e000c000.ethernet-ffffffff:07: attached PHY driver [Marvell 88E1116R] (mii_bus:phy_addr=e000c000.ethernet-ffffffff:07, irq=POLL)
macb e000c000.ethernet eth1: Cadence GEM rev 0x00020118 at 0xe000c000 irq 29 (c2:92:1b:ee:5a:8e)

Are you connecting this Marvel PHY to GMII2RGMII? Are there any printout in your bootlog to check gmii2rgmii driver? I am a bit confused. 

 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
6,618 Views
Registered: ‎05-27-2019

Hi @nanz ,

Many thanks once again for your reply.  Initially, I was confused also by it.  However, your question gave me a bit of a lead (hence the kudo).   And here's how:

When I did my initial petalinux-build, I received the following error (patalinux-build log file attached):

system-top.dtb: ERROR (phandle_references): /amba/ethernet@e000c000: Reference to non-existent node or label "phy1"system-top.dtb: ERROR (phandle_references): /amba/ethernet@e000c000/mdio/i_schematic_bd_wrapper_schematic_bd_i_gmii_to_rgmii_0@31: Reference to non-existent node or label "phy1"

And that is what led me to modify system-user.dtsi (attached earlier up this thread).  By such means, I was able to get the build to run to completion.  But maybe that is also the cause of my problem.  Because, I just took a look at the auto-generated device tree files and, lo and behold, in pcw.dtsi (attached), I found that a device-tree reference to the gmii_to_rgmii already exists.  So presumably, I didn't need to add it again?  But if I take it out, of course, the build will fail.  So the question I now think I need to solve is how do I get the build to run without generating the above error?  Ideas gratefully received.

Kind regards,

Ian

0 Kudos
nanz
Moderator
Moderator
6,423 Views
Registered: ‎08-25-2009

Hi ian.lang@elektrobit.com ,

There is no problem for you to add GMII2RGMII node in the DTS. So that is fine. 

I am just confused by why a Marvel PHY is attached on GEM1 as all seems setup well in system-user.dtsi. In one of your logs earlier on, I can see xgmii2rgmii even though it seems the driver is not found. Are you sure the driver has been probably enabled in the kernel? What changes have you made so that another marvel PHY is attached to GEM1 in the log? 

 

 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
6,415 Views
Registered: ‎05-27-2019

Hi @nanz 

Thanks for going through the logs.  I think my understanding here might be a bit out.  As I understand it, the gmii-to-rgmii block is allowing the GEM1 MAC inside the Zync to communicate with the external PHY.  So wouldn't I expect a PHY driver to get attached?  Or should I expect it to attach some sort xgmii2rgmii driver?  Would an xgmii2rgmii driver know how to program a Marvel PHY?  What should I be expecting to see in the log?

As for whether the drivers are properly enabled in the Kernel, it is entirely possible that they are not.   Because I am learning how to do this as I go along.  For information, during petalinux-config -c kernel, I have enabled everything I can find referring to "Marvell devices", "Marvell MDIO interfaces support" and also "Xilinx GMII2RGMII converter driver".  Maybe there is something else that I have missed.  I haven't explicitly tried to change anything.

Incidentally, I have now managed to get petalinux-build to complete, although I didn't do anything except re-generate from clean.  But currently, no driver is being attached to GEM1.  GEM0 continues to work without problems.  I feel somehow sure that I have missed something very simple.  But what it is, I do not know.

Ian

0 Kudos
nanz
Moderator
Moderator
6,394 Views
Registered: ‎08-25-2009

Hi ian.lang@elektrobit.com ,

At least I would expect to see something like this when booting:

libphy: Fixed MDIO Bus: probed
libphy: mdio_driver_register: xgmiitorgmii

...

Do you see this when booting?

I also feel like it might be sth very simple missing. When GEM1 is attached to PHY, can you use MII interface to access the registers?

 


-------------------------------------------------------------------------------------------

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
stephenm
Moderator
Moderator
6,349 Views
Registered: ‎09-12-2007

A sample DT is shown below 

https://github.com/fpgadeveloper/ethernet-fmc-zynq-gem/blob/master/PetaLinux/src/ports-012-/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi

 

so, as you know, the petalinux (DTG) will add the gmii2rgmii node, but you would modify this in the system-user.dtsi to add your external phy.

i use this fmc a bit, i can boot and send the bootlog to compare on monday

 

6,312 Views
Registered: ‎05-27-2019

Thanks for your replies @nanz and @stephenm.  I've taken hints from both.

Firstly, as far as the device tree is concered, I took the auto-generated gem1 entry fromn pcw.dtsi and added the phy to it and it seems to build correctly.  So now I have:

&gem1 {
phy-handle = <&phy1>;
phy-mode = "gmii-rxid";
gmii2rgmii-phy-handle = <&i_dgrm_wrapper_dgrm_i_gmii2rgmii_0>;
status = "okay";
xlnx,ptp-enet-clock = <0x4f790d8>;
ps7_ethernet_1_mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
phy1: phy@7 {
/* compatible = "marvell,88e1510,88e1118r"; */
device_type = "ethernet-phy";
reg = <7>;
};
i_dgrm_wrapper_dgrm_i_gmii2rgmii_0: i_dgrm_wrapper_dgrm_i_gmii2rgmii_0@31 {
compatible = "xlnx,gmii-to-rgmii-1.0";
device_type = "ethernet-phy";
phy-handle = <&phy1>;
reg = <31>;
};
};
};

The boot transcript is attached and now contains the desired text:

libphy: Fixed MDIO Bus: probed
libphy: mdio_driver_register: xgmiitorgmii

But, unfortunately, I am also getting:

xgmiitorgmii e000c000.ethernet-ffffffff:1f: Couldn't find phydev

Moreover, "mii device" now reports only eth0.  It was previously reporting both.  So it seems one step forward and one step back.

0 Kudos
stephenm
Moderator
Moderator
6,273 Views
Registered: ‎09-12-2007

I have tried this on my end with 4 gmii2rgmii on my zcu102 (using the ethernet fmc daughter card which has 4 Marvel 88e1510).

I had to patch the DTG as it didnt create the node correct info (wasnt incrementing the phy-handle), but this should affect you, as you just have the

one gmii2rgmii.

hw.PNG

I booted, as far as uboot and done a mii dump 0x0 2-3 to make sure that the PHY ID was read:

mii_dump.PNG

You can also do this manually:

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

manual_read.PNG

Note: we only care about bits 0-15 here.

 

We can cross check the ID against the ID used in Linux:

https://github.com/Xilinx/linux-xlnx/blob/8807ecf79df2330d273b65e4a655d7f19a04aef8/include/linux/marvell_phy.h

phy_id.PNG

If I boot linux, I can see that the Marvel PHY is detected:

phy_detect.PNG

 

 

stephenm
Moderator
Moderator
6,266 Views
Registered: ‎09-12-2007

by the way here is my DT node:

 

&gem0 {
 phy-handle = <&phy0>;
 phy-mode = "gmii";
 status = "okay";
 xlnx,ptp-enet-clock = <0x0>;
 psu_ethernet_0_mdio: mdio {
  #address-cells = <1>;
  #size-cells = <0>;
  phy0: phy0@0 {
   device-type = "ethernet-phy";
   reg = <0>;
  };
  gmii_to_rgmii_0: gmii_to_rgmii_0@8 {
   compatible = "xlnx,gmii-to-rgmii-1.0";
   phy-handle = <&phy0>;
   reg = <8>;
  };
 };
};

stephenm
Moderator
Moderator
6,262 Views
Registered: ‎09-12-2007

Can you try do a read (in uboot, or linux) of the phy management register:

for example, in u-boot:

  • mw 0xff0c0034 0x638a0000
  • md 0xff0c0034 1
  • mw 0xff0c0034 0x638e0000
  • md 0xff0c0034 1

So, this is 0110 <phy addr> <phy reg> 10 <bit 15 - 0>

So, assuming your phy address is correct 0x7, we can read phy reg 2, and 3 to read the phy id:

0110 <00111> <00010> 10 <bit 15 - 0>

0110 <00111> <00011> 10 <bit 15 - 0>

If this is read correctly, then the issue (and I suspect this) is the DT node.

 

Also, is your PHY address set to 31? This should match the HW:

For example, I have this set to 8

phy_addr_hw.PNG

&gem0 {
 phy-handle = <&phy0>;
 phy-mode = "gmii";
 status = "okay";
 xlnx,ptp-enet-clock = <0x0>;
 psu_ethernet_0_mdio: mdio {
  #address-cells = <1>;
  #size-cells = <0>;
  phy0: phy0@0 {
   device-type = "ethernet-phy";
   reg = <0>;
  };
  gmii_to_rgmii_0: gmii_to_rgmii_0@8 {
   compatible = "xlnx,gmii-to-rgmii-1.0";
   phy-handle = <&phy0>;
   reg = <8>;
  };
 };
};

 

 

 

 

6,120 Views
Registered: ‎05-27-2019

Hi @stephenm ,

Thank you very much for the work you have put into your replies.  Sorry for the slow response but I have been trying to make further progress myself before getting back to you.

So, in answer to your questions, yes, I can do an mii dump on PHY1:

Zynq> mii dump 0x7 2-3
2. (0141) -- PHY ID 1 register --
(ffff:0141) 2.15- 0 = 321 OUI portion

3. (0e40) -- PHY ID 2 register --
(fc00:0c00) 3.15-10 = 3 OUI portion
(03f0:0240) 3. 9- 4 = 36 manufacturer part number
(000f:0000) 3. 3- 0 = 0 manufacturer rev. number

Note that the PHY is hard-wired on the PCB to address 0x7.  I can also read the registers manually.  Note also that I have a Zynq, not Zynq Ultrascale, so the addresses are different.  The first write was necessary to enable the MDIO.

Zynq> mw 0xe000c000 0x00000010
Zynq> mw 0xe000c034 0x638a0000
Zynq> md 0xe000c034 1
e000c034: 638a0141 A..c
Zynq> mw 0xe000c034 0x638e0000
Zynq> md 0xe000c034 1
e000c034: 638e0e40 @..c

So, according to the lookup table, the PHY matches #define MARVELL_PHY_ID_88E1116R 0x01410e40, which is correct:

20191010_205129.jpg

Going to the boot, both PHYs are being reported:

libphy: MACB_mii_bus: probed
Marvell 88E1510 e000b000.ethernet-ffffffff:00: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=e000b000.ethernet-ffffffff:00, irq=POLL)
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 28 (00:0a:35:00:22:01)
libphy: MACB_mii_bus: probed
xgmiitorgmii e000c000.ethernet-ffffffff:1f: Couldn't find phydev
Marvell 88E1116R e000c000.ethernet-ffffffff:07: attached PHY driver [Marvell 88E1116R] (mii_bus:phy_addr=e000c000.ethernet-ffffffff:07, irq=POLL)
macb e000c000.ethernet eth1: Cadence GEM rev 0x00020118 at 0xe000c000 irq 29 (e2:93:de:a1:8b:5e)

But, as you can see, it seems to be complaining about the phydev at 0x1f, which I presume is the register within the gmii-to-rgmii.  Note that the PHY address is set to 31 (0x1f):

image.png

But I can write to the gmii-to-rgmii register from u-boot:

Zynq> mii device eth1
Zynq> mii read 0x1f 0x10
0000
Zynq> mii write 0x1f 0x10 0x0040
Zynq> mii read 0x1f 0x10
0040

And I can see, by means of the LEDs mentioned further up the thread, that the write is succeeding.  Nevertheless, when I boot to Linux, ifconfig does not report eth1.  It seems to vanish between u-boot and Linux.  The full transcript is attached.

For information, I did try to write to the gmii-to-rgmii register manually using mw 0xe000c034 0x5faa0040 but that didn't work whereas mii write 0x1f 0x10 0x0040 did.  I was also unsuccessful reading the PHY registers from within Linux:

root@os:~# devmem 0xe000c000 32 0x00000010
root@os:~# devmem 0xe000c034 32 0x638a0000
root@os:~# devmem 0xe000c034
0x00000000

Whether that provides any kind of clue, I don't know. 

And here is my current system-user.dtsi, for reference:

/include/ "system-conf.dtsi"
/ {
};

&gem1 {
phy-handle = <&phy1>;
phy-mode = "gmii";
gmii2rgmii-phy-handle = <&i_dgrm_wrapper_dgrm_i_gmii2rgmii_1>;
status = "okay";
xlnx,ptp-enet-clock = <0x4f790d8>;
ps7_ethernet_1_mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
phy1: phy@7 {
/* compatible = "marvell,88e1510,88e1118r"; */
device_type = "ethernet-phy";
reg = <7>;
};
i_dgrm_wrapper_dgrm_i_gmii2rgmii_1: i_dgrm_wrapper_dgrm_i_gmii2rgmii_1@31 {
compatible = "xlnx,gmii-to-rgmii-1.0";
phy-handle = <&phy1>;
reg = <31>;
};
};
};

Further ideas would be most welcome.

Ian

 

0 Kudos
kwy4262
Contributor
Contributor
6,044 Views
Registered: ‎01-25-2016

Hi Stephen:

I am a bit confused in the above message, there's a link for the system-user.dtsi that has phy-mode="rgmii-id" to provide skew on both tx and rx.

However, in the working one, phy-mode="gmii"

I was searching in the forum to get my gmii-to-rgmii IP working also. Hence, I going through the thread in here. Mine seems to autonegotiate, but the tx_clk is always 20% faster than it supposed to be.

 

Thanks,
CK

0 Kudos
5,993 Views
Registered: ‎05-27-2019

Hi @kwy4262 ,

Yes, I think there are a lot of people who have had problems with the gmii2rgmii interface, for example this one: https://forums.xilinx.com/t5/Embedded-Linux/Petalinux-2017-2-dts-node-for-GMII-to-RGMII-ip/td-p/807905, which is very similar to my own and also, as far as I can tell, unresolved.  When/if I ever get this PHY working in PetaLinux, I will cumulate this thread with a detailed description of the steps required. Hopefully, it helpwill  future people with the same issue.

Regards,

Ian

0 Kudos
ccasanova
Observer
Observer
5,933 Views
Registered: ‎03-13-2019

Hi ian.lang@elektrobit.com.

 

I have the same issue, have you got any update?

 

My topic is : https://forums.xilinx.com/t5/Ethernet/Zynq-7010-with-ETH1-EMIO/td-p/1037599

 

0 Kudos
5,927 Views
Registered: ‎05-27-2019

HI @ccasanova,

No, not yet.  I'll let you know if I do.

Ian

0 Kudos
5,752 Views
Registered: ‎05-27-2019

I would like to ask everybody out there one question please:  does anybody know how to get rid of, or debug, the message:

    xgmiitorgmii e000c000.ethernet-ffffffff:1f: Couldn't find phydev

Linux doesn't seem to be able to apply the driver for the gmii2rgmii, even though I know that the IP, as well as the PHY itself, is visible over the MDIO.  Is there some further requirement that I might have missed?

0 Kudos
ian@lang
Contributor
Contributor
5,567 Views
Registered: ‎01-11-2019

I said to @kwy4262  that I'd post a solution to this thread, when/if I ever found one.  Not least, because so many threads on this site don't seem to reach a successful conculsion, which can be very frustrating.  Anyway, finally, I got there!

So, as @nanz said, above, it was indeed something very small.  But enough to keep me stuck for a long time.  So what was it?  Well actually, kind of nothing.  As I said above, ifconfig was not reporting eth1, even though it could be found in u-boot using mii.   This led me to believe that Linux was not recognising the interface:

root@os:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0A:35:00:22:01
inet6 addr: 2a02:8388:6901:c300:20a:35ff:fe00:2201/64 Scope:Global
inet6 addr: fe80::20a:35ff:fe00:2201/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:304 (304.0 B) TX bytes:1766 (1.7 KiB)
Interrupt:28 Base address:0xb000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 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)

However, an additional -a argument was all it took to reveals the other link:

root@os:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0A:35:00:22:01
inet addr:192.168.0.59 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: 2a02:8388:6901:c300:20a:35ff:fe00:2201/64 Scope:Global
inet6 addr: fe80::20a:35ff:fe00:2201/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1502 (1.4 KiB) TX bytes:3014 (2.9 KiB)
Interrupt:28 Base address:0xb000

eth1 Link encap:Ethernet HWaddr E2:93:DE:A1:8B:5E
BROADCAST MULTICAST 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:29 Base address:0xc000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 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)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 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)

And a simple ifup eth1 brings the link up immediately:

root@os:~# ifup eth1
IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
udhcpc: started, v1.29.2
udhcpc: sending discover
macb e000c000.ethernet eth1: unable to generate target frequency: 125000000 Hz
macb e000c000.ethernet eth1: link up (1000/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
udhcpc: sending discover
udhcpc: sending select for 192.168.0.227
udhcpc: lease of 192.168.0.227 obtained, lease time 3600
RTNETLINK answers: File exists
/etc/udhcpc.d/50default: Adding DNS 192.168.0.1
root@os:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0A:35:00:22:01
inet addr:192.168.0.59 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: 2a02:8388:6901:c300:20a:35ff:fe00:2201/64 Scope:Global
inet6 addr: fe80::20a:35ff:fe00:2201/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2280 (2.2 KiB) TX bytes:3942 (3.8 KiB)
Interrupt:28 Base address:0xb000

eth1 Link encap:Ethernet HWaddr E2:93:DE:A1:8B:5E
inet addr:192.168.0.227 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::e093:deff:fea1:8b5e/64 Scope:Link
inet6 addr: 2a02:8388:6901:c300:e093:deff:fea1:8b5e/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1392 (1.3 KiB) TX bytes:1404 (1.3 KiB)
Interrupt:29 Base address:0xc000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 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)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 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)

So there you are, who would have thought it?  There is also another red herring that threw me of course.  And that is, as far as I can tell, that there is no need of any mention of the xlnx,gmii-to-rgmii-1.0 in the device tree.  Even when I remove all trace of it, the PHY is initialised correctly.  But the "couldn't find phydev" message appears as ever, apparently not causing a problem.  That had me very confused:

libphy: MACB_mii_bus: probed
Marvell 88E1510 e000b000.ethernet-ffffffff:00: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=e000b000.ethernet-ffffffff:00, irq=POLL)
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 28 (00:0a:35:00:22:01)
libphy: MACB_mii_bus: probed
xgmiitorgmii e000c000.ethernet-ffffffff:1f: Couldn't find phydev
Marvell 88E1116R e000c000.ethernet-ffffffff:07: attached PHY driver [Marvell 88E1116R] (mii_bus:phy_addr=e000c000.ethernet-ffffffff:07, irq=POLL)
macb e000c000.ethernet eth1: Cadence GEM rev 0x00020118 at 0xe000c000 irq 29 (e2:93:de:a1:8b:5e)

My working device tree looks like as follows:

/include/ "system-conf.dtsi"
/ {
};


&gem1 {
phy-handle = <&phy1>;

status = "okay";
xlnx,ptp-enet-clock = <0x4f790d8>;
ps7_ethernet_1_mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
phy1: phy@7 {
/* compatible = "marvell,88e1510,88e1118r"; */
device_type = "ethernet-phy";
phy-mode = "rgmii-id";
reg = <7>;
};
};
};

One last surprise:  if I switch to an Ubuntu root file system, it is not even necessary to do ifup eth1; the link comes up automatically.

I sincerly hope this answer is of help to other people having difficulties getting the gmii-to-rgmii IP working with Linux.  It does seem to be the subject of very many posts.  I particularly recommend taking a look at the attached working transcript.

Ian Lang

View solution in original post

Tags (1)