DM8168 KSZ9031MNX Gig Phy

Chris Fadeley1

I have a custom DM8168 board using the Micrel KSZ9031MNX gigabit PHY chip.

I have the most recent Micrel linux phy driver on the system and the driver attaches without issue. I then use the generic davinci emac driver to attach the mac.

But I am having issues getting the gigabit ethernet to work.

I am aware of the errata (copied below) and have tried implementing it to no avail.

I have followed the errata as closely as possible. So far my process is:

uboot boots without phy connected (i hold it in reset)
Linux boots and i pull the phy out of reset
Linux MDIO probe finds the PHY device and attaches the micrel driver
Rootfs network script initializes MAC.
On first "set_phy_config" from davinci_emac.c, force Phy Control register to be 100Mb/s no autoneg.
emac_stop is called.
emac_start is then called
This time set_phy_config knows it is not the first time and it sets it to 1000Mb/s autoneg.
Reports that micrel driver attached successfully
No link is detected.

When using ethtool to set the speed and autoneg enable/disable, setting the device to 100Mb/s autoneg off results in a link up and i am able to ping and everything. I then switch it to autoneg on speed 1000Mb/s, and nothing works.

Can anyone please provide some sample code or reccommendations on how to properly implement this errata? Is there anything on the hardware we can look for? We quickly sampled the EMACs output clock and it was only 25MHz even when switching to 1Gig. Obviously the clock should be 125MHz for gig.

Any direction/help would be greatly appreciated.

DM8168 Gigabit PHY Errata Software Workaround

EMAC requires a clock on EMAC_TXCLK only on initialization.
Enable EMAC as PHY (can be written only via MDIO), then disable auto-negotiation and
force 100-Mbps full-duplex GMII copper mode so that the PHY starts outputting the clock
on EMAC_TXCLK. Then restart the EMAC so it is reinitialized while the clock is running.
After that, auto-negotiation is enabled by the generic driver and the Ethernet works in
both U-Boot and Linux in all modes.

over 9 years ago

0 Chris Fadeley1 over 9 years ago

Intellectual 305 points

I enabled the GIGFORCE (bit 17) and GIG (bit 7) registers on MACCONTROL and then the GMTCLK switched to 125MHz.

Hence I don't know if the errata is the issue. it seems whenever I enable auto-negotiation I get no link. If the gig clock wasn't working properly, then it should still auto-negotiate to 100Mbps. Instead it just reports speed 100 and no link in ethtool.

Does anyone have any idea why autonegotiation won't complete?

0 Pavel Botev over 9 years ago in reply to Chris Fadeley1

TI__Guru**** 170625 points

Chris,

Are you using DM816x EZSDK? If yes, can you try with the latest u-boot code base:

http://arago-project.org/git/projects/u-boot-omap3.git?p=projects/u-boot-omap3.git;a=shortlog;h=refs/heads/ti81xx-master

In what mode you are using the PHY (MII or GMII)? Can you provide full boot up console log? If you are booting from EMAC, see also this silicon errata advisory 2.1.39. See also advisory 2.1.40.

See if the below wiki page will be in help:

http://processors.wiki.ti.com/index.php/TI81xx_PSP_Porting_Guide#Ethernet_Driver_-_Adding_Custom_Ethernet_Phy

BR
Pavel

0 Pavel Botev over 9 years ago in reply to Pavel Botev

TI__Guru**** 170625 points

See also if the below e2e threads will be in help:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/231135.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/245301.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/153423.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/128095.aspx

BR
Pavel

0 1330hayacool7102 over 9 years ago in reply to Chris Fadeley1

Guru 10655 points

Chris Fadeley1 said:

I enabled the GIGFORCE (bit 17) and GIG (bit 7) registers on MACCONTROL and then the GMTCLK switched to 125MHz.

Hence I don't know if the errata is the issue. it seems whenever I enable auto-negotiation I get no link. If the gig clock wasn't working properly, then it should still auto-negotiate to 100Mbps. Instead it just reports speed 100 and no link in ethtool.

Does anyone have any idea why autonegotiation won't complete?

1. What's the machine you connect DM8618 to? And what's the settings( negotiation? duplex? speed?) in the your connected machine?

2. Could you download ethtool and show us the result when setting 10/100/1000 with auto negotiation on/off in your machine?

Show the status after your each setting. Thanks

Note: please set your DM8168 with auto negotiation without speed limit (basically it should be default state when boot up)...

0 Chris Fadeley1 over 9 years ago in reply to 1330hayacool7102

Intellectual 305 points

All. apologies on the late reply. I was at a trade show.

I will look into all these responses and will get back to you with more information in the coming days. I appreciate the help.

0 zanget over 9 years ago in reply to Chris Fadeley1

Expert 2150 points

Hi Chris,

Were you able to get the KSZ9031 Ethernet PHY working with the DM8168 processor?

we are facing the same issue and kindly ask if you get any progress.

regards, Mike

0 Chris Fadeley1 over 9 years ago in reply to zanget

Intellectual 305 points

Ive unfortunately been very busy on other items. Ill post here when i find something though. Should be back on this in a day or so

0 Chris Fadeley1 over 9 years ago in reply to Chris Fadeley1

Intellectual 305 points

All.

Seeing how doing the errata in linux was giving me grief, I decided to attempt the errata in U-Boot to confirm.

Was able to get the errata successfully working via the following addition to davinci_emac_initialize(void) after it creates the phy device.

	printf("Ethernet PHY: %s\n", phy.name);
	u_int16_t phy_data;
	debug_emac("Silicon Errata Work\n");
	davinci_eth_phy_read(active_phy_addr, PHY_BMCR, &phy_data);
	debug_emac("BMCR Original: 0x%x\n", phy_data);
	phy_datar = (1 << 8) | (1 << 13);	
	debug_emac("Writing 0x%x to BMCR\n", phy_data);
	davinci_eth_phy_write(active_phy_addr, PHY_BMCR, phy_data);
	davinci_eth_phy_read(active_phy_addr, PHY_BMCR, &phy_data);
	debug_emac("BMCR After: 0x%x\n", phy_data);

	udelay(500000);

	int count_er=0;
	while ((!phy.get_link_speed (active_phy_addr)) && count_er<250) {
		count_er++;
		udelay(5000000);	
	}

	if(count_er==250){
		debug_emac("Failed to get a link at 100MB/full....\n");
	}
	else{
		debug_emac("Link Reported up at 100MB/full\n");
	}

	debug_emac("Emac Soft Reset\n");
	/* Reset EMAC module and disable interrupts in wrapper */
	writel(1, &adap_emac->SOFTRESET);
	while (readl(&adap_emac->SOFTRESET) != 0) ;
#if defined(DAVINCI_EMAC_VERSION2)
	writel(1, &adap_ewrap->softrst);
	while (readl(&adap_ewrap->softrst) != 0) ;
#else
	writel(0, &adap_ewrap->EWCTL);
	for (cnt = 0; cnt < 5; cnt++) clkdiv = readl(&adap_ewrap->EWCTL);
#endif

	debug_emac("Mdio re-enable\n");
	davinci_eth_mdio_enable();

Using this addition we were able to get the 125MHz clock out from the MAC, yet gigabit still fails to work and something strange is definitely going on. I do not know if this is related to the DM8168 or the KSZ9031MNX. What i can see that happens though is the following:

Phy Found
Errata Request to set it to no autoneg, 100 full duplex
Wait and then link comes up
Reset MAC & MDIO and re-enable autoneg + gig
Run DHCP
Gigabit gets negotiated.
Link goes down for a few seconds
Comes back up with a few settings changed
Never gets a response from DHCP

Note if i set it to 100Mb i do get a response from DHCP so i know the request is possible, gigabit just isn't working.

Also note the switch I am plugged into is confirmed capable of running at a gig (other devices are plugged in and the switch states a 1gig link). At no time does the switch ever state that this is a 1gig link to our DM8168 based device though. The link indicator on the switch is working fine though and correlates with what prints to our console.

Here is the full log of what happens. I have bolded the important parts:

davinci_eth_phy_detect(), ALIVE = 0x00000080
Ethernet PHY: GENERIC @ 0x07
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x1140
0x1: 0x7949
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0x0
0x6: 0x4
0x7: 0x2001
0x8: 0x0
0x9: 0x300
0xa: 0x0
0xb: 0x0
0xc: 0x0
0xd: 0x0
0xe: 0x0
0xf: 0x3000
0x10: 0x0
0x11: 0xf4
0x12: 0x0
0x13: 0x78
0x14: 0x7000
0x15: 0x0
0x16: 0x0
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x0
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x300 1000BaseT-Slave mode, half duplex, jabber counter enabled
--------------------------------
Silicon Errata Work
BMCR Original: 0x1140
Writing 0x2100 to BMCR
Davinci_Phy_Write reg 0x0 val 0x2100
BMCR After: 0x2100

Now Waiting for Link:
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x7949
BMSR: 0x794d

100Mb link up

Emac Soft Reset
Mdio re-enable

DaVinci EMAC
Hit any key to stop autoboot: 3 0
TI8168_EVM#dhcp
+ emac_close
+ emac_ch_teardown
- emac_ch_teardown
+ emac_ch_teardown
- emac_ch_teardown
- emac_close
+ emac_open
Davinci_Phy_Write reg 0x0 val 0x3100 (autoneg on, duplex full)
Davinci_Phy_Write reg 0x9 val 0x200 (tells it to advertise 1000Base-T)
Davinci_Phy_Write reg 0x4 val 0x1e1 (tells it to advertise 10 & 100)
Davinci_Phy_Write reg 0x0 val 0x3300 (restart autoneg, autoneg on, duplex full)
get_link: 0x796d

//We can confirm at this point in time the clock is outputting 125MHz to the PHY (we looked at it on a scope)
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100 (autoneg on, duplex full)
0x1: 0x796d (link is up)
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xf
0x7: 0x2001
0x8: 0x4806
0x9: 0x200
0xa: 0x830 (bits 0-7 == idle error count) (Link Parter is capable of 1000Base-T Full duplex [not half though]) Also claims "remote receiver not OK" & "Local Receiver not OK". PHY is configured as Slave
0xb: 0x0
0xc: 0x0
0xd: 0x0
0xe: 0x0
0 0xc7e
0x14: 0x4102
0x15: 0x0
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x2d
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x349 (Link Status Check Failed [because this is prior to negotiating], Slave Mode, Full Duplex, 1000Base-T
--------------------------------
eth_open : gigabit negotiated
- emac_open

//At this point gigbit has been negotiated the DM8168 now sends out DHCP requests
BOOTP broadcast 1
get_link: 0x796d
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100
0x1: 0x796d
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xd
0x7: 0x2001
0x8: 0x4806
0x9: 0x200
0xa: 0x800 (Same as before but now there are no idle errors)
0xb: 0x0
0xc: 0x0
0xd: 0x0
0xe: 0x0
0xf: 0x3000
0x10: 0x0
0x11: 0xf4
0x12: 0x0
0x13: 0x6
0x14: 0x4082
0x15: 0x0
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x0
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x348 Same but now link status check is good
--------------------------------
get_link: 0x796d
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100
0x1: 0x796d
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xd
0x7: 0x2001
0x8: 0x4806
0x9: 0x200
0xa: 0x800
0xb: 0x0
0xc: 0x0
0xd: 0x0
0xe: 0x0
0xf: 0x3000
0x10: 0x0
0x11: 0xf4
0x12: 0x0
0x13: 0x6
0x14: 0x4082
0x15: 0x0
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x0
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x348 Link says down
--------------------------------
BOOTP broadcast 2
get_link: 0x7949

//At this point in time the Link goes down for a few iterations. I dont know why
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100
0x1: 0x7949 (no link )
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xf
0x7: 0x2001
0x8: 0xe80a
0x9: 0x200
0xa: 0x800
0xb: 0x0
0xc: 0x0
0xd: 0x0
0xe: 0x0
0xf: 0x3000
0x10: 0x0
0x11: 0xf4
0x12: 0x0
0x13: 0x3840
0x14: 0x7002
0x15: 0x0
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x2e
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x300 back to Slave mode, half duplex, jabber counter enabled
--------------------------------
WARN: emac_send_packet: No link
BOOTP broadcast 3
get_link: 0x7949
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100
0x1: 0x7949 (no link again...)
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xf
0x7: 0x2001
0x8: 0xe00a
0x9: 0x200
0xa: 0xff
0xb: 0x0
0xc: 0x0
0xd: 0xf4
0x12: 0x0
0x13: 0x3c78
0x14: 0x7002
0x15: 0x0
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x2f
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x300
--------------------------------
WARN: emac_send_packet: No link
BOOTP broadcast 4

//Then the Link comes back up
get_link: 0x796d
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100
0x1: 0x796d Link is back
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xf
0x7: 0x2001
0x8: 0x4006
0x9: 0x200
0xa: 0x40ff //you will then see here that once it gets out of this "no link state" for a few iterations the 1000BaseT Status register states the Master-Slave configuration has now switched and the PHY is now resolved to be the master. Also it no longer claims the link partner is capable of 1000Base-T
0xb: 0x0
0xc: 0x0
00xf4
0x12: 0x0
0x13: 0x801
0x14: 0x5802
0x15: 0x0
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x29
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x328 Link is up, but it is now reporting a speed of 100Base-tx, 1000BaseT-Slave Mode, Full Duplex
--------------------------------
get_link: 0x796d
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100
0x1: 0x796d
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xd
0x7: 0x2001
0x8: 0x4006
0x9: 0x200
0xa: 0x4000
0xb: 0x0
0xc: 0x0
0xd: 0x0
0xe: 0x0
0xf: 0x3000
0x10: 0x0
0x11: 0xf4
0x12: 0x0
0x13: 0x801
0x14: 0x5802
0x15: 0x0
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x0
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x328
--------------------------------
BOOTP broadcast 5
get_link: 0x796d
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100
0x1: 0x796d
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xd
0x7: 0x2001
0x8: 0x4006
0x9: 0x200
0xa: 0x4000
0xb: 0x0
0xc: 0x0
0 //accidental break in printf (uart didnt keep up)
0xe: 0x0
0xf: 0x3000
0x10: 0x0
0x11: 0xf4
0x12: 0x0
0x13: 0x801
0x14: 0x5802
0x15: 0x0
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x0
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x328
--------------------------------
get_link: 0x796d
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100
0x1: 0x796d
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xd
0x7: 0x2001
0x8: 0x4006
0x9: 0x200
0xa: 0x4000
0xb: 0x0
0xc: 0x0
0xd: 0x0
0xe: 0x0
0xf: 0x3000
0x10: 0x0
0x11: 0xf4
0x12: 0x0
0x13: 0x801
0x14: 0x5802
0x15: 0x0
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x0
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x328
--------------------------------
BOOTP broadcast 6
get_link: 0x796d
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100
0x1: 0x796d
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xd
0x7: 0x2001
0x8: 0x4006
0x9: 0x200
0xa: 0x4000
0xb: 0x0
0xc: 0x0
0
0x10: 0x0
0x11: 0xf4
0x12: 0x0
0x13: 0x801
0x14: 0x5802
0x15: 0x0
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x0
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x328
--------------------------------
get_link: 0x796d
KSZ9031MNX PHY Register Dump
--------------------------------
0x0: 0x3100
0x1: 0x796d
0x2: 0x22
0x3: 0x1622
0x4: 0x1e1
0x5: 0xcde1
0x6: 0xd
0x7: 0x2001
0x8: 0x4006
0x9: 0x200
0xa: 0x4000
0xb: 0x0
0xc: 0x0
0xd: 0x0
0xe: 0x0
0xf: 0x3000
0x10: 0x0
0x11: 0xf4
0x12: 0x0
0x13: 0x801
0x14: 0x5802
0x15: 0x0 (RX error counter is still 0)
0x16: 0x20
0x17: 0x200
0x18: 0x0
0x19: 0x0
0x1a: 0x0
0x1b: 0x0
0x1c: 0x0
0x1d: 0x0
0x1e: 0x0
0x1f: 0x328
--------------------------------
+ emac_close
+ emac_ch_teardown
- emac_ch_teardown
+ emac_ch_teardown
- emac_ch_teardown
- emac_close

0 Chris Fadeley1 over 9 years ago in reply to Chris Fadeley1

Intellectual 305 points

We just hooked up our LEDS to the KSZ9031 LED output pins and saw the following:

At this point in my dump:

eth_open : gigabit negotiated
- emac_open

The phy indicator LED flashes very briefly stating it is 1000Link/No Activity.

The switch we are plugged into says no Link

Then the link goes down (as seen in the dump) and all LEDs are off.

At which point the LED indicates it is in 100Mb/with activity.

The switch also states there is a link, but not a gigabit link.

If you look at the log you will also see it is at this point the link partner no longer claims it is capable of 1000Base-T.

Don't know why the DHCP request then continues to still fail though. It is as if it attempts Gigabit and then fails (for a reason I do not know) and then tries to continue on and never gets a response from DHCP.

0 1330hayacool7102 over 9 years ago in reply to Chris Fadeley1

Guru 10655 points

The switch we are plugged into says no Link
> Could you provide the model name, brand of the switch?

The switch also states there is a link, but not a gigabit link.
> it looks like something wrong in auto negotiation. Did FAE of Micrel KSZ9031MNX give you any suggestion?

0 Chris Fadeley1 over 9 years ago in reply to 1330hayacool7102

Intellectual 305 points

It is a standard gigabit switch. This one: http://trendnet.com/products/proddetail.asp?prod=510_TEG-S50G

We are currently working with the FAE and hope for some insight soon. I will keep you all updated.

I was able to setup and run the basic PHY loopback tests and it seems the loopbacks between the PHY & MAC are working fine. So I think the DM8168 & KSZ9031 communication may be working ok now that the errata is in.

I am now working on properly diagnosing the PHY-->Switch chain. Will take some time I am sure.

0 Chris Fadeley1 over 9 years ago in reply to Chris Fadeley1

Intellectual 305 points

All. I believe i finally got to the bottom of this. It was a multitude of issues causing the problem. Here is the rundown:

1. Gigabit Errata in U-Boot had to be applied as i documented previously. This then allowed the 125MHz clock to be fed in.

2. Our board has a custom connector for ethernet. This resulted in the cable not being a twisted pair. We believe this to be the issue. Seems like this created a signal integrity issue which only allowed 10/100mbps to work. We then hard soldered a shielded twisted pair cable onto the board and the gigabit link was retrieved in U-Boot. This caused the issue with autonegotiation not being completed after the Errata (my long previous post).

3. Gigabit was then confirmed working in U-Boot, but i still could not get it to work in Linux. I ported the errata used in U-Boot to the emac driver and it still didn't work. I then noticed (by sleeping in between calls) that the gigabit link was actually established, but would then break once genphy_config_advert() was called followed by genphy_restart_autoneg().
I then discovered that when "Symmetric & Asysmmetric pause (local device)" was enabled in Phy register 0x4 0x10/0x11 the link would go down. I am not even close to being an expert in ethernet & autonegotiation, so I don't really know why this causes the link to fall off, but it does.

I simply set 4.11:10 to [0,0] (No Pause) and the gigabit link worked without issue. This register being set to [1,1] is what was causing autonegotiation to not work at all in Linux (regardless of speed). If anyone has any insight as to why this is, that would be great.

The only thing i am still confused on (besides why Sym/Asm pause breaks the link) is the fact that i then removed the errata from both U-Boot & Linux, but i still was able to get the gigabit clock. Anyone have any idea why?

Thanks for all the assistance. Hope this helps someone down the line.

Processors

Processors forum

DM8168 KSZ9031MNX Gig Phy