LAN8720A on i.MX28 unstable link

cancel
Showing results for 
Search instead for 
Did you mean: 

LAN8720A on i.MX28 unstable link

Jump to solution
8,895 Views
dennisp
Contributor I

Dear community,

I have made a custom iMX28 board based on the mx28evk board using the SMSC LAN8720A Ethernet PHY and for a long time everything seemed to work as intended - at least until I started experience that the ethernet connection was unstable. The link is coming up for 1-2 seconds, then goes down again for a couple of second, comes up and so on... going on forever. Sometimes a reset helps, sometimes it doesn't. If the link comes up in the first try it stays up and the connection is rock stable.

I think I can rule out bad hardware because starting up with u-boot and downloading the kernel through TFTP works perfect every time. This never failed but as soon as Linux tries to start up the ethernet it fails again.

PHY registers are set to reasonable values, reset timing is correct, signals look fine... I compared how things are done in u-boot and Linux and see no differences concerning the phy setup.

I have struggled with this for several days now and I'm getting no where. Has anyone seen something similar? Or can somebody give me a hint on something to look for?

Help much appreciated,

Dennis

Labels (2)
0 Kudos
1 Solution
1,300 Views
MarekVasut
Senior Contributor I

These DT props might be interesting for you:

- phy-reset-gpios : Should specify the gpio for phy reset

- phy-reset-duration : Reset duration in milliseconds.  Should present

  only if property "phy-reset-gpios" is available.  Missing the property

  will have the duration be 1 millisecond.  Numbers greater than 1000 are

  invalid and 1 millisecond will be used instead.

See Documentation/devicetree/bindings/net/fsl-fec.txt in upstream kernel. I'm sure there's similar options for non-DT case.

View solution in original post

0 Kudos
14 Replies
1,300 Views
MarekVasut
Senior Contributor I

Try this patch first:

http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=b629820d18fa65cc598390e...

If you're brave and care for the LPM, try this on top of the above one:

http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=4223dbffed9f89596177ff2...

It's a bug in the LAN8720A, where enabling the low-power mode will cause the PHY to crap up. We use Micrel PHYs on our boards and they just work as expected.

0 Kudos
1,300 Views
dennisp
Contributor I

Hi Marek

Thanks for your reply. I already tried the above patch without any luck.

However I have managed to fix the problem. It seems that some conditions are not met during the hardware reset of the PHY. When the FEC driver loads it calls enet_gpio_init() which asserts the RESETn pin for 50ms. From what I can see on a scope my theory is that the clock is unstable during this reset. So I added the hardware reset routine during the PHY lan87xx_config_init() and now it works perfectly.

I am still to find out why the reset from the FEC driver does not work on my board when it works on the evaluation board. I have observed on both boards that ENET_CLK is idling at 25 MHz during the reset and when the FEC is enabled the clock runs at 50 MHz (which is should).

0 Kudos
1,300 Views
olistudent
Contributor I

We solved the problem through keeping the PHY in reset while the fec restarts. I will post a link to the patch when it is available.

0 Kudos
1,300 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Oliver,

The fix you did is for what kernel version?

0 Kudos
1,300 Views
olistudent
Contributor I

Hi.

@Raana

Dennis and I are using a LAN8270A on a mx28 board. So I doubt it's the same issue. You will have to adopt the fix for your board...

@Fabio

The fix is for fsl 2.6.35. It includes some backports (fec fixes) from mainline and the mentioned workaround. It's not written by me. I will try to follow the kernel patch submit guideline and send it in the next few days.

Regards

Oliver

0 Kudos
1,300 Views
jrtigerlee
Contributor III

Hi Oliver :

I also have the same problem , when I connection with two LAN port,

And plug out one port then plug in again , two LAN port will reset and unstable

How's your solution ? and can you advise me .

thanks lot

0 Kudos
1,300 Views
olistudent
Contributor I

Hi Jrtiger.

I don't know if you can compare the situations because we only use one lan port. Perhaps there is only one clock for both ports!? And when you plug out/in the other port the clock changes/halts like written above? The proper solution would be to use an external crystal for ref clock I think.

I'm attaching the patches we wrote anyhow. Perhaps you can use them to fix your case.

Regards

Oliver

0 Kudos
1,300 Views
jrtigerlee
Contributor III

Hi Oliver :

Thanks for your patch although it's not helpful to me .

I found it's hardware limitation
https://community.freescale.com/docs/DOC-94983

0 Kudos
1,300 Views
Raana
Contributor III

Hi Oliver,

I am also facing the same unstable Link issue (same like Dennis issue) on ksz9021 smsc phy

Chip Name : i.MX6DL/Solo

please Advice me to solve this issue

Thanks in Advance

Regards,

J.P.Raja

0 Kudos
1,300 Views
olistudent
Contributor I

Hi Dennis.

We are observing the same behaviour. During the MAC reset the clock runs with only 25 MHz (mii mode) instead of 50 MHz (rmii mode) for a short time. This sometimes confuses the PHY so it will not respond to link changes anymore. The only way ist to reboot the device.

Did you get any further with this problem until now?

You are talking about a hardware reset routine? I assume you are triggering the gpio pin directly to reset the PHY?

Regards

Oliver

0 Kudos
1,300 Views
MarekVasut
Senior Contributor I
0 Kudos
1,300 Views
olistudent
Contributor I

Hi Marek.

We switched from smsc to generic phy driver during our tests. The generic version doesn't support the power management feature. So this should not be the problem.

Regards

Oliver

0 Kudos
1,300 Views
MarekVasut
Senior Contributor I

Why is that so, the smsc phy driver seems to be more fitting and advanced.

0 Kudos
1,301 Views
MarekVasut
Senior Contributor I

These DT props might be interesting for you:

- phy-reset-gpios : Should specify the gpio for phy reset

- phy-reset-duration : Reset duration in milliseconds.  Should present

  only if property "phy-reset-gpios" is available.  Missing the property

  will have the duration be 1 millisecond.  Numbers greater than 1000 are

  invalid and 1 millisecond will be used instead.

See Documentation/devicetree/bindings/net/fsl-fec.txt in upstream kernel. I'm sure there's similar options for non-DT case.

View solution in original post

0 Kudos