Keystone II Ethernet MAC reset issues

Bill

I am currently running a 3.8.4 Kernel on a TCI6638K2K Keystone II (I understand this part is only supported by FAE but this is a generic Keystone II question not part specific). I am using a Marvell 88e1112 Phy on a custom board and have wrote a custom Phy driver to run this phy in 1000 Base X mode. My question comes because when I boot up the kernel DHCP messages do not make it out on the wire. I have verified this by mirroring the port to my PC and using wireshark to check for packets on the wire. What I have found out is that if I remove the fiber cable, and the plug it back it, I get these messages as expected:

libphy: 2090300.mdio:00 - Link is Down

libphy: 2090300.mdio:00 - Link is Up - 1000/Full

And then I am able to call $udhcpc -i eth0 again and I start seeing DHCP messages on the wire and also am able to get an IP address for the interface.

The debugging that I have done has brought me to the writing of 0x00000000 to the mac control register when the Link goes down is the key to freeing up the interface and allowing me to send DHCP messages on the wire. This happens in drivers/net/ethernet/ti/keystone_ethss.c (_cpsw_adjust_link()).

As a work around I have added:

__raw_writel(0, &slave->sliver->mac_control);
slave->mac_control = 0;

at the bottom of 'cpsw_slave_open()'

This causes writing of the register to zero to occur before the interface is completely up and thus the DHCP call during init will let the DHCP messages hit the wire.

Is there any reason why this would be happening, or has anyone else seen this before?

over 8 years ago

0 Titusrathinaraj Stalin over 8 years ago

TI__Guru** 116100 points

Hi Bill,
Sorry for the delayed response on this.
We don't face this issue on K2H and K2E boards.
I think, it might be problem due to your own PHY driver implementation.

0 Christopher Peters over 8 years ago

Genius 3370 points

Bill, you might want to have a look at this thread.

e2e.ti.com/.../445093

Sound very much like the issue we had just running the demo code. The solution was to run the SetupPhy0 GEL script. Perhaps you can look at that and add whatever it does into your init code. Good luck.

0 Bill over 8 years ago in reply to Titusrathinaraj Stalin

Intellectual 645 points

Hi,

That was clearly my initial thought. But the Phy driver only configures the PHY device through the MDIO bus. It does not touch the MAC interface nor does it touch the SGMII interface. Its ability to pass back information to the MAC and to higher layers of the networking stack are through the stuct phy_device structure only, in which case it is properly setting Link status fields. Also, correct me if I am wrong, but the K2H board had some sort of issue with it, so it does not actually use the MDIO bus and thus, the phy_driver is really not configuring the Phy at all. http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Enabling_MDIO

0 Javier Malave-Bonet over 8 years ago in reply to Bill

TI__Expert 5805 points

Hi Bil,

Marvell 88E1112 provides HW auto-configuration. Our EVM's do not use a PHY driver as they rely on programming the PHY automatically out of reset via HW bootstrapped pins. You can download the schematics from advantech website ->

I don't recall out of the top of my head all the 88E1112 registers and fields, but this may be due to programming some mode we don't support? Recall that we don't support Half-Duplex 1G, only Full-Duplex. And if you are using Fiber, have you made sure the PHY is correctly getting the lasers on? Is the remote link side up? The PHY link to the MAC side may be ok, even if the Link side (i.e. FIber) is bad. That would be some of the things I would be in the look out.

I don't have a Fiber example for that PHY, I have only used RJ-45, so hard to pin-point right now what could be wrong for that specific PHY model using Fiber.

Kind regards,

Javier

Processors

Processors forum

Keystone II Ethernet MAC reset issues