we're using a custom board with the i.mx287 based on the i.mx28-evk with debian linux (jessie 8.2) and a kernel based on mainline linux 3.18.0.
On the i.mx28 evk it is possible to shutdown the ethernet phys (to save energy) with a mosfet, on our cumston board the phys are directly connected to the 3.3 V power supply.
Also we're using different plugs for the ethernet connection (the ones used on the evk are pretty expensive).
Linux Network configuration
- eth0 is configured via NetworkManager to use dhcp (ipv4) and is connected to our local network (with a windows 2012 server dhcp server).
- eth1 uses a static network configuration via /etc/network/interfaces and is connected to a laser device which also has a static address (ipv4).
There are sporadic problems on both network interfaces.
When the system starts up, it *sometimes* failes to get an ip address on eth0.
Also on eth1 the system *sometimes* fails to communicate with the laser device.
When the error occurs and I try to ping the dhpc server (on eth0) or the laser device (on eth1) the resulting message is "Destination host unreacheable".
The errors on the interfaces are independent of each other, so sometimes the error occurs on eth0 only, sometimes it occurs on eth1 only.
When the interfaces work properly after bootup, they continue to work properly and the problem doesn't appear until the system is rebooted.
All the descriptions below refer to eth0, I haven't done any test on eth1 because that's more difficult (because of the device connected).
Workaround: Re-plug network cable
Usually every time the network cable is removed and plugged in again the problem disappeares (for both interfaces).
Wireshark: No packets from eth0
I've attached a hub in between the eth0 interface and our main switch to look at the network traffic with wireshark. When the problem occurs, there's no package at all transmitted from the network interface. After re-plugging the cable wireshark shows the normal dhcp traffic (and the device eth0 gets an ipv4 address).
Switch vs. Hub
Apparently the behaviour also depends on the device used at the other end of the cable. When using a relatively new Netgear Switch GS108, the problem occurs about 1 of 5 times after bootup. When using the older Netzgear DS108 Hub, the problem occured much more often, about 4 out of 5 times. Also, re-plugging the cable didn't always solve the problem and I had to restart the system (and re-plug the cable).
Checking proper phy reset with an Oscilloscope
We suspected that the phy might be reset by turning on the supply voltage (with the mosfet that was removed on our custom board). I checked the voltage on the the gpio that was originally connected to the mosfet, but there's no change (it's always high) during bootup.
Then I checked the reset pin (phy pin no. 15). It get's properly reset (taken down from 3,3 to 0 V) during bootup for a little more than 100 ms.
Checking with the original evk board
I've not yet been able to check with the original evk because we shipped it to an extern software developer. I've already ordered it back and I'll probable be able to check if the problem also happens with the i.mx28 evk hardware on friday.