Migrating TCI6638K2H to Custom Board

Hi Bill,
Able to bring up your PHY in u-boot ?

Enable debug prints in drivers/net/ethernet/ibm/emac/phy.c and see "init" function get called or not and to verify that we passed info about PHY to driver.

Also, what was the issue on the K2HK EVM that forced it to use the use a software GPIO instantiation of MDIO?

Please refer to the following TI E2E post.

e2e.ti.com/.../1523649

Did you verify the hw connections ?
If not, you can use PDK examples (PA, NDK examples) from latest MCSDK.

Hi,

After double checking the hardware connections I found out that there was an issue with the clocks to the Phy. Now I am able to communicate with the Phy over MDIO, but I am unable to get the Link to come up. I am not using the PHY in u-boot so I am not initializing or trying to connect to it at all at that level. I am letting the kernel do all of the configuration. Is this a good idea? I do not see u-boot support for the Phy I am using which is why I have decided to leave it out.

Hi Bill,
Sorry for the delayed response on this.
I'm working on this, please let me update.
Thanks for your understanding.
Also update us if you have any further update.
Thank you.

Ok here is an update to my issue. So after getting in touch with the FAE from Marvell, it turns out that the driver within the Linux kernel is not sufficient to operate the Phy in the mode that we are trying to run it in. I decided to write my own Phy driver and I am able to successfully get a Link Up status and auto-negotiation has been configured (At least between the Phy and the phy in the other side of the link. My issue now is that the network drivers above my phy driver begins to start forwarding packets out of the network interface (ARP?) because it has been enumerated, but I do not actually get data to come out of the Phy. I have attached the Phy to a switch that allows me to monitor port status, and I see that the Switch is forwarding broadcast packets to the phy, but the receive interface statistics (ifconfig rx-packets) show that none of them make it.

That may not have been 100% clear so here is a brief recap. Phy driver seems to be working and a link up status is retrieved and passed along with the phydev struct to the higher level network layers.

The network stack identifies the interface and tries to send packets out (I assume ARP?). I can see this by doing ifconfig and looking at the Tx-packets.

Packets are not seen at the other end of the link. Packets sent into the phy from the link, are also not seen from ifconfig rx-packets.

My current assumption is that the SGMII interface between the Keystone and the Phy is not working. Where within the kernel does this transmit action occur? Could it be that the Keystone MAC did not set up auto-negotiation with the Phy?

Here is some of the outputs from ifconfig/ethtool


root@CAJUN-devel:~# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Current message level: 0x00000000 (0)

Link detected: yes

ifconfig:

eth0 Link encap:Ethernet HWaddr D4:F5:13:B8:86:EA
inet6 addr: fe80::d6f5:13ff:feb8:86ea/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:1112 (1.0 KiB)

eth1 Link encap:Ethernet HWaddr 02:18:31:7E:3E:6F
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:284 (284.0 B) TX bytes:284 (284.0 B)

Here is some further update.

I am now taking a look at the SGMII module within the Keystone assuming that my Phy is configured correctly. I putting it in MAC->Phy auto negotiation mode. By setting "link-interface" device tree value to a '1'. I put some debug in keystone_sgmii.c and am seeing in the SGMII status register that the auto-negotiation never completes (between mac and phy), and the link status is a 0. I assume that this is the source of my above issues. What could cause this? Any ideas on ways to debug this issue?

Hi, Bill,

The issue with MDIO is that we noticed the MDIO bus isn't stable after we enabled it. I am not familiar with 8e1112 PHY if it can be funcitonal without further configuration after powering up which 88e1111 can. If 88e1112 can, that means MDIO is not necessary and you may want to try setting link-interface to 4 (MAC_PHY_NO_MDIO) and see if the link comes up. the other possible cause of link not coming up is the SerDes configuration/Calibration. SerDes may need to calibrate on your board. With that, I will need HW Apps to help you if you need to.

Rex

Rex,

I do not see any issue with MDIO. I am able to continually read and write from the MDIO bus after boot. I can read the Link status bit from the the phy and it is seeing a link on the media side of the Phy. The problem seems to be with the SGMII port. I see that it (SGMII port) does not notice a link up and the auto-negotiate complete bit never goes high. I have also printed out the MAC status register, and I see that the MAC is in an idle state.

Hi, Bill,

The documents for GbE switch and SerDes can be found in TCI6638K2K page under technical documents tab in http://www.ti.com/product/TCI6638K2K/technicaldocuments.

TI does not support 125MHz and there isn't such platform to verify the configuration. Hence, I don't think the values for 125MHz cofniguration exist. The PLL multiplier and divider don't apply to ethernet switch either. I can check with Hardware Application team to see if there is such configuration for 125MHz. If not, then I don't see any way around it.

Rex

Hi, Bill,

Try with the attached file which contains 125MHz configuration.

Rex0245.keystone_serdes.c

Rex, as I mentioned above. I ported the CSL library 125MHz config into linux and it works. The 125MHz config that is in the attatched file is identical to that of the CSL library which I already ported.

Sorry, Bill. I didn't refresh my e2e screen and missed your reply. Glad that you got it working. Thanks for your patience.
Rex