DP83867ERGZ-S-EVM: RFSoC (Ultrascale+) DP83867ERGZ-S-EVM Link Up but No Traffic (Ping). No SGMII Auto-negotiation

Alejandro Martin

Tool/software:

Hello,

I openend this case some weeks ago, but unfortunately I could not make the measurement in time and case was closed after some days.

The original case was DP83867ERGZ-S-EVM: RFSoC (Ultrascale+) DP83867ERGZ-S-EVM Link Up but No Traffic (Ping)

I finally made a measurement, but the scope was 1GHz BW limited and the signals are very limited.

In this capture, the yellow corresponds to the diferential output of the evaluation board DP83867ERGZ-S-EVM (SO_P-SO_N). The green output is the output from the FPGA (PS-GTR3, GEM3).

The amplitud from the eval board seems to be ok, about 800mV over a differential impedance from 100Ohms. The amplitud from the RF-SoC seems to be ok, with a differential P-P amplitude of 1500mv aprox.

The register 0x0037 keeps on 0 value, which meas that the SGMII Autonegotiation was not done,

in U-BOOT

ZynqMP> mii write 0x00 0x0D 0x001F
ZynqMP> mii write 0x00 0x0E 0x0037
ZynqMP> mii write 0x00 0x0D 0x401F
ZynqMP> mii read 0x00 0x0E
0000

an in linux

Reg: 0x0000     Value: 0x1140
Reg: 0x0001     Value: 0x796D
Reg: 0x0002     Value: 0x2000
Reg: 0x0003     Value: 0xA231
Reg: 0x0004     Value: 0x09E1
Reg: 0x0005     Value: 0xCDE1
Reg: 0x0006     Value: 0x006F
Reg: 0x0007     Value: 0x2001
Reg: 0x0008     Value: 0x4006
Reg: 0x0009     Value: 0x0300
Reg: 0x000A     Value: 0x3C00
Reg: 0x000D     Value: 0x401F
Reg: 0x000E     Value: 0x1111
Reg: 0x000F     Value: 0x3000
Reg: 0x0010     Value: 0x5848
Reg: 0x0011     Value: 0xAC02
Reg: 0x0012     Value: 0x0000
Reg: 0x0013     Value: 0x1C02
Reg: 0x0014     Value: 0x2BC7
Reg: 0x0015     Value: 0x0000
Reg: 0x0016     Value: 0x0000
Reg: 0x0017     Value: 0x0040
Reg: 0x0018     Value: 0x6150
Reg: 0x0019     Value: 0x4440
Reg: 0x001A     Value: 0x0002
Reg: 0x001E     Value: 0x0202
Reg: 0x001F     Value: 0x0000
Reg: 0x0031     Value: 0x1111
Reg: 0x0032     Value: 0x00D3
Reg: 0x0033     Value: 0x0000
Reg: 0x0037     Value: 0x0000
Reg: 0x0043     Value: 0x07A0
Reg: 0x006E     Value: 0x8820
Reg: 0x006F     Value: 0x0110
Reg: 0x0086     Value: 0x0057
Reg: 0x00C6     Value: 0x0000
Reg: 0x00D3     Value: 0x0000
Reg: 0x00FE     Value: 0xE721
Reg: 0x0134     Value: 0x1000
Reg: 0x0135     Value: 0x0000
Reg: 0x016F     Value: 0x0015
Reg: 0x0170     Value: 0x0C12
Reg: 0x0172     Value: 0x0000
Reg: 0x01D5     Value: 0xF500

Autonegotiation from PHY is ok, and everything from PHY seems to be ok

root@sgmii:~# dmesg | grep macb
[    2.130847] macb ff0e0000.ethernet: Not enabling partial store and forward
[    2.147282] macb ff0e0000.ethernet eth0: Cadence GEM rev 0x50070106 at 0xff0e0000 irq 45 (00:0a:35:00:22:03)
[    7.663446] macb ff0e0000.ethernet eth0: PHY [ff0e0000.ethernet-ffffffff:00] driver [TI DP83867] (irq=POLL)
[    7.673253] macb ff0e0000.ethernet eth0: configuring for phy/sgmii link mode
[    7.685382] macb ff0e0000.ethernet: gem-ptp-timer ptp clock registered.
[   11.775311] macb ff0e0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control tx

Maybe could you help me to find out why I can't get the link and auto-negotiation between GEM and PHY over SGMII?

Thanks a lot.

10 months ago

0 Vivaan Jaiswal 10 months ago

TI__Expert 6405 points

Hi Alejandro,

I read through the last E2E and was also able to speak with my team member who assisted you with that a few weeks ago.

Thank you for the SGMII waveforms and for confirming that the MDI side auto-negotiation works as expected.

As you mentioned, judging from the waveforms and all the information here, and in the last E2E, all functionality on the PHY side looks good.

I suspect that the issue with the link is on the SoC side. You were able to repeatedly read register 0x37 as 0, which tells us that the SGMII page, a kind of acknowledgment used in the auto-negotiation process, was not received by the PHY after attempting auto-negotiation with the SoC. I believe this is the root cause of the problem. The only other thing we could try on the PHY side would be to disable auto-negotiation and force a SGMII and MDI link at gigabit speeds, however, doing so will make the system not be able to dynamically adjust link speed.

I would recommend contacting the SoC team for further assistance in debugging the MAC side.

Best Regards,

Vivaan

0 Alejandro Martin 10 months ago in reply to Vivaan Jaiswal

Prodigy 20 points

Hi Vivaan,

And thanks a lot for your support. I am the SoC (ZynqMP) developer too.

Well, I tried to fix the link, but without sucess.

The problem was the configuration of the PS-GTR in the netork node, I did following the guide of Atlassian Wiki, but not working wit version of Xilinx-Linux from 2022.1 (actually not with 2023.2, the current one I am using with Petalinux 2023.2).

I will provide with some information later, with my device-tree, and the registers we have to observe and analize, as well as the usefull documentation from Xilinx, for the next user with the same problem, ok?

0 Vivaan Jaiswal 10 months ago in reply to Alejandro Martin

TI__Expert 6405 points

Hi Alejandro,

Alejandro Martin said:
I will provide with some information later

Sounds good, this information may be useful for another person with a similar issue in the future.

Best,

Vivaan

0 Alejandro Martin 10 months ago in reply to Vivaan Jaiswal

Prodigy 20 points

Yes, I agree.

Only one question. I want to get the output clock at 125MHz.

I add in the device tree the parameters

     // Output clock selection
     
     ti,sgmii-ref-clock-output-enable;
     //ti,clk-output-sel = <DP83867_CLK_O_SEL_REF_CLK>;
     ti,clk-output-sel = <DP83867_CLK_O_SEL_CHN_A_RCLK_DIV5>;

But I ever obtain, in both cases (DP83867_CLK_O_SEL_REF_CLK or DP83867_CLK_O_SEL_CHN_A_RCLK_DIV5), the same clock, at 625MHz with a lot of jitter. In the second case should be at 125MHz (DVI5).

Registers in PHY are right configured, but ... output not. And jitter is from 610MHz to 650MHz ...

0 Vivaan Jaiswal 10 months ago in reply to Alejandro Martin

TI__Expert 6405 points

Hi Alejandro,

The DP83867 has 2 clocks, one for xMII and one for SGMII. I believe the clock output being modified is the xMII clk_out. Can you confirm which pin you are reading the signal from?

Since this clock is very high speed, it is possible that this jitter is measurement error. What kind of scope is being used for the measurement?

Best,

Vivaan

Interface

Interface forum

DP83867ERGZ-S-EVM: RFSoC (Ultrascale+) DP83867ERGZ-S-EVM Link Up but No Traffic (Ping). No SGMII Auto-negotiation