News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

TE0720 2nd ethernet port slow RX.

Started by ZKJohan, October 28, 2020, 01:50:56 PM

Previous topic - Next topic

ZKJohan

Hello,

We've designed a custom carrierboard for the TE0720-module, based on the TE0706-carrier board. For the second ethernet-port, we've implemented the Marvell 88E1512 ethernet PHY, which is copied from the TE0706-board.

During the board-bringup, we noticed that the PHY is working:
Net:   ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id
eth0: ethernet@e000b000ZYNQ GEM: e000c000, phyaddr 0, interface gmii

Warning: ethernet@e000c000 (eth1) using random MAC address - 6e:3a:1c:22:aa:5f
, eth1: ethernet@e000c000
U-BOOT for petalinux

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


When inserting a cable:
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


According to some sources on the internet, the "unable to generate target frequency"-message can be ignored.
The PHY on board of the SOM works without problems; both RX and TX work at maximum frequencies. However, the second phy (on our custom board) doesn't work as expected.
When we test the phy with iperf, we get the following results:

root@petalinux:~# iperf3 -c 10.0.10.100
Connecting to host 10.0.10.100, port 5201
[  5] local 10.0.10.101 port 55480 connected to 10.0.10.100 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.02   sec  43.1 MBytes   355 Mbits/sec    0    192 KBytes
[  5]   1.02-2.02   sec  46.0 MBytes   386 Mbits/sec    0    218 KBytes

(...)

root@petalinux:~# iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.0.10.100, port 61897
[  5] local 10.0.10.101 port 5201 connected to 10.0.10.100 port 61898
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   171 KBytes  1.40 Mbits/sec
[  5]   1.00-2.00   sec  24.2 KBytes   199 Kbits/sec


As you can see, receiving on the Petalinux-side is very, very slow. It works, but it's nowhere near the 1000Mbps.

Some details about our implementation:
- On the FPGA-side, we use the GMII-to-RGMII-block, connected to generic FPGA-pins. This implementation is copied from a reference-design from Trenz.
- This GMII-to-RGMII-block is connected to GMII_ETHERNET_1 on the ZYNQ.
- Vivado version is 2019.1
- Petalinux version is 2019.1


Device tree looks as following:

&gem0 {
    phy-handle = <&phy0>;
    mdio {
        #address-cells = <1>;
        #size-cells = <0>;
        phy0: phy@0 {
            compatible = "marvell,88e1510";
            device_type = "ethernet-phy";
            reg = <0>;
        };
    };
};
&gem1 {
    phy-handle = <&phy1>;
    mdio {
        #address-cells = <1>;
        #size-cells = <0>;
        phy1: phy@0 {
            compatible = "marvell,88e1510";
            device_type = "ethernet-phy";
            reg = <0>;
        };
    };
};


On the hardware-side, it all looks fine; voltage-rails are stable and within specs, all clocks are stable and within specs.

With this Petalinux-package, comes a "macb-gmii2rgmii.patch". When removing this patch and recompling, the phy doesn't work at all. This makes us think that it's a driverproblem in Linux.

Is there something we're missing? Has anybody else experienced this problem or a problem like this?

Thank you!

With kind regards,

ZKJohan

Oleksandr Kiyenko

Hello,
at first look, your Petalinux configuration looks normal except for the PHY address
address 0 is a reserved address, it causes problems in past (with old drivers) but now it should work.
Please check your network statistic, are you see an error or drooped packets?
As for hardware configuration, you can try to play with Skew and External clock in "Gmii to Rgmii".
Also, you can try to change "phy-mode" in driver settings.
But if you don't see error packets, it's probably a software/driver problem.

Best regards
Oleksandr Kiyenko

ZKJohan

Hello mr Kiyenko,

Thank you for your response!
Your suggestion to look at the network-statistics was quite valuable; it turned out, there are a lot of RX-errors. This probably explains the incredibly low received packages.
To investigate this further, I got my hands on a very high bandwith, high samplerate oscilloscope. I found out that the TX-clock, generated by the FPGA on the TE0720 looks pretty decent. The RX-clock, however, generated by the phy, has a lot of jitter and is pretty malformed. This led to measuring the power-rails, and we found out that the 1V8-rail is pretty noisy as well. Even though stable, they're noisy. This might explain the noisy RX-clock.

As mentioned before, we copied the PHY-implementation from the TE0706-board, with one exception; we've placed R27 instead of R28. We've done this because of this line in the datasheet:

QuoteWhen internal regulator option is preferred, both 1.0V and 1.8V regulators must be used. Supplying 1.0V internally and 1.8V externally (or vice versa) is not supported.

So we've used the internal regulators for the 1V8 and 1V0, we're not supplying this externally. However, this is not how Trenz has implemented it. Is this because you've had similar issues in the past or..?

Martin R.

Hello,
we checked our revision history about the issue you have reported.
On the first revision of this board we implemented the use of both internal regulators, but an external for VDDO. This worked well.
For actual revision only R28 assembled and R27 not fitted is used, which ignores the note in the datasheet you pointed out. We never used the implementation of suppling both VDDO and AVDD18 from the internal 1.8V regulator.
Although it is written in the datasheet, that AVDD1.8_OUT could be used for VDDO in the case of VDDO=1.8V, it should only be done if one takes care a lot about decoupling (maybe use more capacitors, and additional Ferrit, e.g. compare with evaluation board Schematics).
So we think your problem could be related to this. Just change the jumper resistors, if you have implemented them. Otherwiese try to add additional and larger decoupling caps, maybe this already helps.
Best regards
Martin