I know our company appreciates the cape support, so thanks for supporting it :-)
Been watching this thread anxiously for a while. So glad to see a fix was made, but we are using an Ubuntu 12.04 build for ARM (we really wanted to use Ubuntu to be consistent with our other field deployments). Rob, can you point us to the source changes that were made for this issue so that we can patch our kernel or whatever needs to be patched so we can get a fix in? On Thursday, March 20, 2014 11:47:12 AM UTC-4, Gerald wrote: > > A cape. I hate capes. Maybe on the next revision I will just disable all > of them! > > Thanks! > > Gerald > > > > On Thu, Mar 20, 2014 at 10:32 AM, Kees k <[email protected]<javascript:> > > wrote: > >> Haha, I was looking at the wrong file (BB white A6). Sorry for the >> trouble; it seems our cape causes this difference between A5C and A6. >> >> On Tuesday, November 26, 2013 11:22:42 PM UTC+1, 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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]. For more options, visit https://groups.google.com/d/optout.
