We have a few Industrial Beaglebone Black from Element 14. Rev C(PCB revision is B6). The Ethernet not coming up on every boot is faced in this version too. The OS used is QNX & hence the Software fix provided in Linux Kernel could not be used. Is there a solution? -Geetha
On Wednesday, November 27, 2013 at 3:52:42 AM UTC+5:30 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ca52f021-a089-4e0f-9375-1ad45b7fadd8n%40googlegroups.com.
