SERDES MDIO register reportinglinkup even if Ethernet cable is not attached.

[talhaimran]

I am confused about the MDIO interface present in the DPAA Fman controller. If we use the internal MDIO interface for each MAC we access the MDIO registers of SERDES (with address 0) it reports the the AN as complete and link status as up after some time, even if no cable is attached to port. While if we use the external MDIO interface and access the PHY for same MAC (with address mentioned in schematics) then we access the standard PHY register which reports correct link and auto negotiation status. So what link status are the SERDES MDIO registers referring to?

[ufedor]

You wrote:

> we use the internal MDIO interface for each MAC we access the

> MDIO registers of SERDES (with address 0) it reports the the AN as complete

Which processor in in question?

Which exactly registers are in question?

Please provide corresponding access log.

[talhaimran]

The processor in question is LS1046 and I am using a custom OS.

> Using internal MDIO interface: Link status bit 2 register SGMII_SR (index 1).

> Using external MDIO interface: Register 1 bit 2.

[ufedor]

In the RM it is written:

"The SGMII MDIO register space is selected when the associated SGMIInCR1[MDEV_PORT] matches the Ethernet MAC PHY address (MDIO_CTL[PHY_ADDR])."

Please confirm that you have considered this.

[talhaimran]

I am using the default SERDES settings done by Uboot. SERDES1 protocol configuration is 0x1133. I am supposing that uboot will configure the SERDES to work with SGMII.5 and SGMII.6. Is this supposition right or I have to configure the SERDES as well.

[cswarth]

Talha,

Did you figure out how the serdes was getting configured for MDIO access in uboot?  I think I'm having problems on the ls1046a around the same functions you were.  I assume uboot must configure the SERDES control registers (like SGMIIACR1) to hold an address before it can access the MAC via MDIO, but I actually see no evidence of that configuration in the uboot code. 

In fact I can rename the `struct ccsr_serdes` structure in arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h and recompile without an error - indicating that the uboot code does not use this structure at all.

Did you figure out how the SGMII MDIO register space is getting initialized in uboot?