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
已解决! 转到解答。
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.
Try this patch first:
If you're brave and care for the LPM, try this on top of the above one:
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.
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).
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
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
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
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
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
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
I observed something similar, try this patch:
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.