05-25-2019 09:24 PM
What is the current status of 1000BASE-X support using the PS-GTR? It is called out in the TRM and other documentation, however, posts in the forum from 2018 state that the support for GEM through PS-GTR is only SGMII. Has there been any update to fully support 1000BASE-X?
We would like to connect two Zynq Ultrascale+ through a network connection and would rather do it via a point-to-point like utilizing the PS-GTR rather than instantiating the PCS/PMA core in the PL and using the GTH section of the PL.
09-12-2019 05:20 AM
we have the same configuration i.e. ZynqMP/PS-GTR to SFP+/1000base-X and we use Vivado 2019.1. Could you please provide the device tree snippet that needs to be added?
09-12-2019 08:35 AM
I am Ralf Spiwoks, working with Paschalis. We did add the snippet to the device tree as follows:
speed = <1000>;
Then we rebooted the ZynqMP and got the messages as in the print out added below, see xxx.log.
After boot we used ethtool and ifconfig to configure the eth2 interface, see yyy.log.
Unfortunately, the Ethernet interface does not get correctly connected. Ping does not
work (see yyy.log). The other end (a regular Linux PC with an interface we had tested
beforehand to work correctly) does not see
[root@pcphl1ct07 mpsoc]# ethtool p4p2
Settings for p4p2:
Link detected: no
Could you please advise us on what other tests to do? Any hint with the issue is
Thanks a lot for your help.
09-16-2019 06:51 AM
Here are some updates:
1) The "ethtool" seems to be completely unconnected to the hardware. Whenever we disable the
autonegotiation using "eth -s eth2 speed 1000 duplex full autoneg off", we see it correctly announced
by "ethtool eth2". However, it is still enabled as we can see from the GEM PCS control register at
2) With my colleagues, including S. Haas and P. Vichoudis, we managed to enable the ethernet finally
by running the following sequence:
ifconfig eth2 down
ifconfig eth2 192.168.2.10
poke 0xff0d0200 0x8140 # disable GEM2 autonegation and soft reset
poke 0xff0d0200 0x0140 # desassert soft reset
testGPIO -n 23 -d 1 -v 1 # assert hard reset of the SFP
testGPIO -n 23 -d 1 -v 0 # deassert hard reset of the SFP
After that sequence the ethernet link comes up and is functional, i.e. we can ping the other end,
and be pinged by the other end.
For us, this is acceptable as a solution of how to get the ethernet link running, although we would
have thought that the disabling of the autoneg and the (soft) resetting of the SFP should have been
done in the kernel by the corresponding PHY driver ....
09-18-2019 02:28 AM
just a small clarification concerning the previous message - it is the SFP "TXDIS" control signal that is referred-to as "hard reset of the SFP".
08-24-2020 07:08 AM
can you please share how you connected the rest of the SFP IOs to the Zynq? The PS-GTR lanes for receive and transmit data are obvious, but the I2C and other status pins interest me.