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]> 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]. > 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.
