I have noticed very rare cases (~1/50) of the ethernet phy on the Beaglebone Black not being detected on boot, and requiring a hard reset (as opposed to calling ‘reset’ from the command line) to get it to work/be detected again.
This problem has been mentioned in a couple of other threads (below) concerning different topics (i.e. problems getting the BBB to boot, and the ethernet phy ‘dying’ some time after initially working fine), with no solution/workaround for this specific problem being suggested - so I thought I’d start a thread specifically for it.
In the first thread mlc/Mike discussed his response to the problem as follows:
"I had issues with the network not coming up on boot, and it was traced
down to problems with the SYS_RESETn line.
I had a level translator connected to SYS_RESETn, to drive a 5V chip.
It was powered by a 5V rail. If the 5V rail powered up “differently”
than the 3.3V rail (not sure of the exact relationship), I guess it
pulled the SYS_RESETn line to weird levels that affected the network
chip but not the main processor. I’m now using a GPIO to drive the
external 5V chip now, instead of the SYS_RESETn line.
Anyway, the moral is be very, very careful with SYS_RESETn, because it
can cause hard-to-trace problems with networking."
I see that the A6 Revision of the Beaglebone Black has some changes to the SYS_RESETn line:
“Based on notification from TI, in random instances there could be a glitch in the SYS_RESETn signal from the processor where the SYS_RESETn signal was taken high for a momentary amount of time before it was supposed to. To prevent this, the signal was ORed with the PORZn (Power On reset).” (http://elinux.org/Beagleboard:BeagleBoneBlack#Revision_A6_.28Production_Version.29)
Is it likely that this modification will improve/resolve the issue I am seeing with the ethernt phy not resetting/powering-up correctly?, seeing as the SYS_RESETn signal also feeds into the nRST pin on the ethernet phy (The SYS_RESETn line is left untouched in my application).
Some additional observations from dmesg concerning this use:
On a good phy boot I see the following:
[ 2.810749] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[ 2.817206] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[ 2.833517] libphy: 4a101000.mdio: probed
[ 2.837871] davinci_mdio 4a101000.mdio: phy: device 4a101000.mdio:00, driver unknown
Followed later by:
[ 21.286920] net eth0: initializing cpsw version 1.12 (0)
[ 21.301166] net eth0: phy found : id is : 0x7c0f1
On a ‘bad phy’ boot I see the following (differences highlighted):
[ 2.806763] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[ 2.813213] davinci_mdio 4a101000.mdio: detected phy mask fffffffb
[ 2.829512] libphy: 4a101000.mdio: probed
[ 2.833875] davinci_mdio 4a101000.mdio: phy: device 4a101000.mdio:02, driver unknown
Followed later by:
[ 21.346861] net eth0: initializing cpsw version 1.12 (0)
[ 21.354379] libphy: PHY 4a101000.mdio:00 not found
[ 21.359469] net eth0: phy 4a101000.mdio:00 not found on slave 0
So it looks like the ‘davinci_mdio_reset’ function see the phy in both instances, but reports differently on the bad boot. I am not sure what to make of this.
I am using the Debian 7.2 Rootfs and the ‘RobertCNelson’ kernel ‘3.12.0-bone8’.