I am just now looking at this issue. The A6 revision was not put in place to fix this issue.
Gerald On Tue, Nov 26, 2013 at 4:22 PM, AndrewTaneGlen <andrewtaneg...@gmail.com>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. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
