So far we have 2 workarounds that seem effective... 1) Connect a GPIO pin to the SYS_RESETN pin (P9-10). Make sure the GPIO pin in set to be an input only with pull-up at boot time in the DT. After boot, have a script or service grep dmseg for the telltail `detected phy mask *fffffffb' *message. If the message is found, then set the GPIO pin to output and drive low and the board will reboot and (eventually) win the race and have a functional ethernet port.
2) Add an additional external micro-usb power supply. I've had good luck with the 2A ones sold for the raspberry pi. I haven't had time to look at all the signal, but the extra power source seems to effect the rise time of the reset signal RC circuit enough to practically always win the race. -josh On Tuesday, November 26, 2013 at 5:22:42 PM UTC-5, AndrewTaneGlen wrote: > > Hello, > > 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. > https://groups.google.com/forum/#!msg/beagleboard/Vp4pxwHm8BU/Iaw3p5xm0MoJ > https://groups.google.com/forum/#!topic/beagleboard/aXv6An1xfqI > > 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[0]: 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[2]: 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'. > > > > Regards, > Andrew. > > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/6a7f3bba-7fcc-4502-ace0-f89475b15485%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
