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
Please provide additional information:
1) binary image of the RCW being used
2) SerDes reference clocks connection and frequencies
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
When SRDS_PRTCL_S1=0x6B only PLL1 is used and PLL2 should be explicitly powered down in the RCW.
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
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
Please provide (as attachment) dump of all SerDes registers (offset range E_A000 - E_A8FF) after U-Boot booting.
Please provide dumps for the DTSEC2 and DTSEC3.
Please check the U-Boot sources, it looks like DTSEC3 is expected to use RGMII interface.
Please create a Technical Case:
I have created a ticket for this. The case number is "Case 00170709".
Thank you,
Ram Krishnan