Hi, I assume this happens because those older kernels cannot cope with the situation when the transceiver just gets a non-zero PHY address at reset. This is solved in recent kernels by updating the device <https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ> tree with actual PHY address.
But, as I wrote above <https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/PK6bxAszAkoJ>, that issue is different from what happens when PHY is not detected even with the latest kernel. You can see this when you set the PHY address to a non-zero value yourself, in U-Boot, and then run "reset" command there, and wait until the system starts. In this case everything works, even with a non-zero address. I'm pretty sure, if you repeat this experiment with those older kernels, PHY will not be detected. It looks like something else happens, when PHY is not detected with new kernels. Not only the PHY address is wrong (i.e. different from 0, set by the strappings on the board), but the transceiver chip remains in some strange, non-working state. So far, the only working solution seems to be removing C24 and C30 capacitors, which is not good for a variety of reasons, as was mentioned in some previous messages here. Regards Alex On Monday, December 15, 2014 2:01:55 PM UTC+1, Robert Kuhn wrote: > > Hi, > > I have 10 boards (newest rev. C). When I use some older Ubuntu with Ubuntu > and kernel Linux arm 3.13.6-bone7 eth0 is detected on one of the ten. When > I use the pre-configured image with Debian and kernel Linux beaglebone > 3.8.13-bone47 the eth0 is there all the time. > > Strange. > > Am Samstag, 13. Dezember 2014 17:02:56 UTC+1 schrieb Karl Karpfen: >> >> 2014-12-12 17:10 GMT+01:00 <alexschn...@gmail.com>: >>> >>> The topic starter there reported that a reboot via watchdog didn't work. >>> >> >> I tried the same (from within a bare-metal application) and noticed the >> same. Once the PHY is in this state also a watchdog-triggered reset does >> not help, my software was trapped in an endless loop where only toggling >> power did help. >> >> And the thread I linked earlier confirms this. >> >> >>> Another idea: the TPS65217C data sheet >>> <http://www.ti.com/lit/ds/symlink/tps65217.pdf> describes various ways >>> to perform the "power up sequence" (page 18), and it can be done from >>> ACTIVE state too, by setting the SEQUP bit of the SEQ6 register to 1. I'm >>> trying to understand now, whether this can cause a processor power cycle >>> (and thus, drive the nRESETIN_OUT low), because some power rails are not >>> affected by the "power up sequence". >>> >> >> Hm, I checked this manual some time a go and did not find such a >> possibility. May be I have overseen this, at least it worth's a try! >> >> Karl >> >> >> > -- 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/d/optout.
