T1024 SGMII (SERDES) ISSUE

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

T1024 SGMII (SERDES) ISSUE

2,790 Views
ramkrishnan
Contributor III

We have a board in which the T1024  SRDS_PRTCL_S1 rcw is set to 0x6B. We have three SGMII lanes. Two lanes (SD1_TX/RX2 and SD1_TX/RX3) are connected to a Marvel Quad Phy 88E1340S. The third (SD1_TX/RX1) is connected to a Marvel 98DX167. The SGMII lanes going to the 881E340S work fine. One test is to put that serdes lane in loopback i.e (FE0EA8FC, FE0EA8BC) and see if the traffic comes back. In the above two cases it does come back. But in the third case if I put the lane in loopback nothing comes back. The third address is FE0EA87C which if I put in loopback , no traffic seems to come back. I have checked the SERDES registers and they seem to all indicate correct configuration. The two serdes PLL's are in locked state. I can talk to the 98DX167 using the MDDIO lines and see that the link-status for the port connected to the SGMII Lane 3 shows down.

The two questions I have are.

1. If I put the serdes lane in loopback and the traffic does not come back would that indicate a problem in the T1024 configuration or does it depend on external factor.

2. What else would I need to look at to isolate this issue ?

I have also contacted Marvell to see if they any suggestions. 

Thank you and any help is appreciated.

Ram Krishnan

Labels (1)
Tags (4)
0 Kudos
13 Replies

2,321 Views
ufedor
NXP Employee
NXP Employee

Please provide additional information:

1) binary image of the RCW being used

2)  SerDes reference clocks connection and frequencies

0 Kudos

2,325 Views
ramkrishnan
Contributor III

Attached is the rcw.bin file

This is the T1024 side of the SerDes connectivity for the clocks.

This is the clock source which is a 100M clock. The rcw was changed to

reflect the 100Mhz PLL source.

Please let me know if you need any more information.

Thank you,

Ram

0 Kudos

2,325 Views
ufedor
NXP Employee
NXP Employee

When  SRDS_PRTCL_S1=0x6B only PLL1 is used and PLL2 should be explicitly powered down in the RCW.

0 Kudos

2,325 Views
ramkrishnan
Contributor III

Powering down PLL2 did not seem to work.

This is the new rcw

Reset Configuration Word (RCW):

00000000: 0808000e 00000000 00000000 00000000

00000010: 35800003 00400002 ec027000 21000000

00000020: 00000000 00000000 00000000 00038810

00000030: 00000000 09025a08 00000000 00000006

These are the results. I have SGMII1 tied to FM1@DTSEC1 , SGMII2 tied

to FM1@DTSEC2 and SGMII3 tied to FM1@DTSEC3.

SGMII1 serdes loopback address is fe0ea8fc

SGMII2 serdes loopback address is fe0ea8bc

SGMII3 serdes loopback address is fe0ea87c

=> pri ipaddr

ipaddr=10.3.60.2

=> md.l fe0ea8fc 1

fe0ea8fc: 08000000 ....

=> mw.l fe0ea8fc 18000000

=> setenv ethact FM1@DTSEC1

=> ping 10.3.60.2

Using FM1@DTSEC1 device

host 10.3.60.2 is alive

=> md.l fe0ea8bc 1

fe0ea8bc: 08000000 ....

=> mw.l fe0ea8bc 18000000

=> setenv ethact FM1@DTSEC2

=> ping 10.3.60.2

Using FM1@DTSEC2 device

host 10.3.60.2 is alive

=> md.l fe0ea87c 1

fe0ea87c: 08000000 ....

=> mw.l fe0ea87c 18000000

=> setenv ethact FM1@DTSEC3

=> ping 10.3.60.2

Using FM1@DTSEC3 device

ARP Retry count exceeded; starting again

ping failed; host 10.3.60.2 is not alive

It fails for SGMII3 i.e FM1@DTSEC3.

Please let me know if you need any more information.

Thanks,

Ram

0 Kudos

2,325 Views
ramkrishnan
Contributor III

Fedor,

I was wondering if you had a chance to take a look to see what the failure cause might be. I tried shutting down the PLL2 and that did not work (details above). 

Thanks,

Ram

0 Kudos

2,325 Views
ufedor
NXP Employee
NXP Employee

Please provide (as attachment) dump of all SerDes registers (offset range E_A000 - E_A8FF) after U-Boot booting.

0 Kudos

2,324 Views
ramkrishnan
Contributor III

Attached is the register dump of all the registers for serdes. It is a

plain text file.

Ram

0 Kudos

2,324 Views
ufedor
NXP Employee
NXP Employee

Please provide dumps for the DTSEC2 and DTSEC3.

0 Kudos

2,324 Views
ramkrishnan
Contributor III

Attached are all the macsec registers for all the mac including the one

that is not working.

Thanks,

Ram

0 Kudos

2,324 Views
ufedor
NXP Employee
NXP Employee

Please check the U-Boot sources, it looks like DTSEC3 is expected to use RGMII interface.

0 Kudos

2,324 Views
ramkrishnan
Contributor III

It was my problem in marking the registers in the previous dump. Please

see the attached. I had started from fe4e2000 instead of fe4e000.

Attached is the updated set of registers.

Sorry for the mis-information.

Ram

0 Kudos

2,324 Views
ufedor
NXP Employee
NXP Employee

Please create a Technical Case:

https://community.nxp.com/thread/381898 

0 Kudos

2,324 Views
ramkrishnan
Contributor III

I have created a ticket for this. The case number is "Case 00170709". 

Thank you,

Ram Krishnan

0 Kudos