AnsweredAssumed Answered

T1042 RGMII EC2 not working with SerDes option 0x8E

Question asked by Stefan Lange on May 12, 2016
Latest reply on Jun 7, 2016 by Stefan Lange

Hello NXP team,

 

 

we have a design with a custom NXP T1042 PowerPC Module located on a custom baseboard. 

Both module and baseboard are new designs.

 

 

I here have a support request regarding the SerDes options, especially the behaviour of the RGMII interfaces in some configurations.

 

 

Our design is implemented in such a way that multiple SerDes options can be used.

T1040 reference manual shows Figure 31-1 Supported SerDesOptions SRDS_PRTCL_S1_RCW.

Two of the SRDS_PRTCL_S1_RCW options we use are 0x86 and 0x8E.

 

 

Setting the RCW to option 0x86, all SerDes and both RGMII interfaces work as expected.

Setting the RCW to option 0x8E, all SerDes interfaces work as expected. However the FMAN MAC5 EC2 RGMII does not work anymore.

(Neither does the EC1, but this is understood as indicated in Figure 31-1)

In my understanding of Figure 31-1, EC2 RGMII should work in configuration 0x8E.

 

 

Following dump shows the full RCW that we have configured:

 

 

Reset Configuration Word (RCW):

       00000000: 0c10000e 0e000000 00000000 00000000

       00000010: 8e000000 00000001 ec027000 01000000

       00000020: 00000000 00000000 00000000 0002a800

       00000030: 00000000 11fe5005 00000000 00000000

      

Have we overlooked something or done anything wrong with the RCW?

As the interface works correctly in a different RCW, I am confident that the malfunction is not due to the hardware.

 

 

Following dump shows the register values of the EMAC5:

 

 

=> md 0xfe4e8300      

 

 

(if connected to Gigabit Switch):                                                (emac5)

fe4e8300: 00005006 0000d000 00000000 00000000    ..P.............

GB, RGMII mode, GMII mode

1 - a valid link is established by the RGMII PHY (if it supports the optional in-band signaling)

10 - 1 Gbps (either controlled by in-band RGMII PHY status or by forced speed settings)

1 - RGMII full duplex link is established (bit is valid if PHY supports the optional in-band signaling)

 

 

(if connected to 100MB Switch):

fe4e8300: 00001002 0000b000 00000000 00000000               

100MBit, non RGMII mode, GMII mode?

1 - a valid link is established by the RGMII PHY (if it supports the optional in-band signaling)

01 - 100 Mbps (either controlled by in-band RGMII PHY status or by forced speed settings)

1 - RGMII full duplex link is established (bit is valid if PHY supports the optional in-band signaling)

 

 

Register values are a little bit irritating, showing 100MBit: non RGMII mode, GMII mode?

Apart from this, register values seem ok.

Also the phy's MAC/RGMII-relevant register values look correct. An MDI link is established.

 

 

 

 

Has anybody ever tried SerDes configuration 0x8E?

It was not included in the Uboot source files (both denx git and SDK), so I added this configuration manually to arch/powerpc/cpu/mpc85xx/t1040_serdes.c

 

 

static u8 serdes_cfg_tbl[][SRDS_MAX_LANES] = {

..

  [0x8D] = {PCIE1, SGMII_SW1_MAC3, SGMII_SW1_MAC1, SGMII_SW1_MAC2,

  PCIE2, SGMII_SW1_MAC6, SGMII_SW1_MAC4, SGMII_SW1_MAC5},

  [0x8E] = {PCIE1, SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC1, SGMII_FM1_DTSEC2,

  AURORA, PCIE3, SGMII_FM1_DTSEC4, SATA1},

  [0x8F] = {PCIE1, SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC1, SGMII_FM1_DTSEC2,

  AURORA, NONE, SGMII_FM1_DTSEC4, SGMII_FM1_DTSEC5},

..

 

 

Is there anything else I can look at? Maybe you can shed some light.

 

 

Thanks and best regards,

Stefan

 

 

 

 

 

 

bootlog

########      

             

U-Boot 2015.07-00014-gdf0d8ea-dirty (May 12 2016 - 10:49:59 +0200)

 

 

CPU0:  T1042, Version: 1.1, (0x85200211)

Core:  e5500, Version: 2.1, (0x80241021)

Clock Configuration:

       CPU0:1400 MHz, CPU1:1400 MHz, CPU2:1400 MHz, CPU3:1400 MHz,

       CCB:600  MHz,

       DDR:800  MHz (1600 MT/s data rate) (Asynchronous), IFC:150  MHz

       QE:300  MHz

       FMAN1: 600 MHz

       QMAN:  300 MHz

       PME:   300 MHz

L1:    D-cache 32 KiB enabled

       I-cache 32 KiB enabled

Reset Configuration Word (RCW):

       00000000: 0c10000e 0e000000 00000000 00000000

       00000010: 8e000000 00000001 ec027000 01000000

       00000020: 00000000 00000000 00000000 0002a800

       00000030: 00000000 11fe5005 00000000 00000000

Board: TQMT1042

I2C:   ready

DRAM:  Initializing....using SPD

Detected UDIMM Fixed DDR on board

2 GiB (DDR3, 64-bit, CL=11, ECC on)

Flash: 128 MiB

L2:    256 KiB enabled

Corenet Platform Cache: 256 KiB enabled

Using SERDES1 Protocol: 142 (0x8e)

MMC:   FSL_SDHC: 0

QE microcode not found

PCIe1: Root Complex, no link, regs @ 0xfe240000

PCIe1: Bus 00 - 00

PCIe2: disabled

PCIe3: Root Complex, x1 gen1, regs @ 0xfe260000

  02:00.0     - 8086:10b9 - Network controller

PCIe3: Bus 01 - 02

PCIe4: disabled

In:    serial

Out:   serial

Err:   serial

Net:   Initializing Fman

Eth:   configuring FM1_DTSEC1 as SGMII

Eth:   configuring FM1_DTSEC2 as SGMII

Eth:   configuring FM1_DTSEC3 as SGMII

Eth:   configuring FM1_DTSEC4 as SGMII

Eth:   configuring FM1_DTSEC5 as RGMII

Fman1: Uploading microcode version 107.4.2

Phy 3 not found

PHY reset timed out

e1000: 00:1b:21:33:5c:5d

       FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5 [PRIME], e1000#0

Warning: e1000#0 MAC addresses don't match:

Address in SROM is         00:1b:21:33:5c:5d

Address in environment is  68:05:ca:37:92:88

Hit any key to stop autoboot:  0

 

 

=> ping $serverip

Using FM1@DTSEC5 device

ping failed; host 192.168.11.100 is not alive

=> mdio list

FSL_MDIO0:

1 - Generic PHY <--> FM1@DTSEC4

3 - Generic PHY <--> FM1@DTSEC2

5 - Generic PHY <--> FM1@DTSEC5

28 - Generic PHY <--> FM1@DTSEC3

29 - Generic PHY <--> FM1@DTSEC1

=> mii info

PHY 0x01: OUI = 0x80028, Model = 0x23, Rev = 0x01,  10baseT, HDX

PHY 0x05: OUI = 0x80028, Model = 0x23, Rev = 0x01, 100baseT, FDX

PHY 0x0E: OUI = 0x80028, Model = 0x23, Rev = 0x01,  10baseT, HDX

PHY 0x1C: OUI = 0x5043, Model = 0x1C, Rev = 0x00,  10baseT, HDX

PHY 0x1D: OUI = 0x5043, Model = 0x1C, Rev = 0x00,  10baseT, HDX

PHY 0x1E: OUI = 0x5043, Model = 0x1C, Rev = 0x00,  10baseT, HDX

PHY 0x1F: OUI = 0x5043, Model = 0x1C, Rev = 0x00,  10baseT, HDX

=>

Outcomes