Hello, This Ethernet trouble also happens with my BeagleBone Black boards, quite frequently on Rev C (PCB Rev B6), and very rarely on Rev A6 (PCB Rev B5). I tried various Linux kernels, including the latest one from here <https://eewiki.net/display/linuxonarm/BeagleBone+Black> (3.8.13-bone67), however that keeps happening anyway.
I read section 3.7 of the LAN8710A data sheet <http://ww1.microchip.com/downloads/en/DeviceDoc/8710a.pdf> (Configuration Straps) and I agree with Loren Amelang: the trouble may be really caused by incorrect strap values, which depend on voltage levels at the respective LAN8710A pins during reset. That assumption is backed by the observation that, whenever the "eth0: link not ready" thing happens, either both LEDs of the Ethernet Connector are off or only the yellow one (LED2) is off (and the green one is not blinking in both cases). Since these LEDs reflect the transceiver mode of operation, which is controlled by MODE[2:0] configuration straps, their strange behavior may indicate some wrong bit values loaded to MODE[2:0]. They are loaded when nRST pin is deasserted, and the timing is critical, according to subsection 5.5.3 of that data sheet (Power-On nRST & Configuration Strap Timing). Also, according to the subsection mentioned above, the time interval between when external power supplies reach 80% and nRST pin is deasserted must be no less than 25 ms. Without the capacitor C24 on the board, that time is around 20 ms, I measured that. So, removing C24 does not seem to be safe. Alex On Wednesday, November 5, 2014 7:03:21 AM UTC+1, Jerin George wrote: > > HI Andrew & John, > > Thank you for your reply. I guess that leaves me with no choice but to > tweak the hardware & also update the kernel to the latest version by > Robert. > Hopefully that will fix the issue for ever. > I will keep you posted on the status. > > regards, > Jerin > > On Wednesday, 5 November 2014 01:23:28 UTC+5:30, john3909 wrote: >> >> >> From: Andrew Glen <andrewt...@gmail.com> >> Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com> >> Date: Monday, November 3, 2014 at 11:36 PM >> To: "beagl...@googlegroups.com" <beagl...@googlegroups.com> >> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not >> Detected on Boot. >> >> Yes, and reading the thread even more fully you'll find my report of >> running thousands of automated test restarts with these parts removed, with >> a 100% success rate. >> >> We use these boards a lot, running 24-7 in this configuration, and have >> had zero hardware faults. With any luck we have nearly exhausted Murphy's >> law with our software. >> >> Hi Andrew, >> >> I accept that you have done these tests, but removing test two capacitors >> from the reset line means the device will come out of reset before the >> power supply has stabilized and without a capacitor, the reset switch will >> bounce several times. That is not a good idea. Perhaps you are just lucky >> given your setup, but removing C24 and C30 is a bad idea. Making these >> capacitors smaller may fix your problem but I suggest that you do have >> something there to delay the reset line. >> >> Regards, >> John >> >> Andrew. >> On 4/11/2014 7:26 PM, "John Syn" <john...@gmail.com> wrote: >> >>> >>> From: Andrew Glen <andrewt...@gmail.com> >>> Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com> >>> Date: Monday, November 3, 2014 at 9:42 PM >>> To: "beagl...@googlegroups.com" <beagl...@googlegroups.com> >>> Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not >>> Detected on Boot. >>> >>> As far as I know, and as already documented in this thread, the only >>> reliable fix is to remove C24 and C30. >>> >>> If you read the full thread, Gerald say that if you remove these >>> capacitors, the board may not start at all. >>> >>> Regards, >>> John >>> >>> On 4/11/2014 5:40 PM, "Jerin George" <george...@gmail.com> wrote: >>> >>>> Hi, >>>> I am using a BBB Rev C with latest Angstrom image and i have seen this >>>> issue with eth not getting detected at boot up. This came at the last >>>> stages of my project delivery. How can this be corrected. Does moving to >>>> the latest debian image solves this issue ? >>>> >>>> regards, >>>> Jerin George >>>> >>>> On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com wrote: >>>>> >>>>> >>>>> They phymask comes from a hardware register read by the davinci_mdio >>>>> driver, which gets passed to the linux phy libraries. The problem is that >>>>> the cpsw driver gets the value from device tree, which is hardcoded to >>>>> address 0. Usually the values are the same (address 0), but sometimes the >>>>> phy gets registered to a different address, usually in my case address 2. >>>>> You calculate the address using the phymask. If you changed the phymask >>>>> than, you pointing back to address 0, so that wouldn't help you. >>>>> >>>>> I rebuilt the dtb file. >>>>> >>>>> On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote: >>>>>> >>>>>> On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com >>>>>> wrote: >>>>>>> >>>>>>> The davinci mdio driver should report a phymask and that value is >>>>>>> used to update the device tree. >>>>>>> >>>>>> >>>>>> Back when I had this problem I tried hard to find out where the >>>>>> phymask comes from, and never succeeded. At that time people who >>>>>> received a >>>>>> phymask of fffffffe booted successfully, those with fffffffb failed. Do >>>>>> you >>>>>> know where the mask is found and how to change it? >>>>>> >>>>>> I also remove the second phy slave from the device tree. >>>>>>> >>>>>> >>>>>> That seems like a great idea, if only to stop all the useless >>>>>> messages about it never being found. Can that be done in the uEnv.txt, >>>>>> like >>>>>> when you disable HDMI, or do you have to rebuild the device tree binary? >>>>>> Would setting the phymask to ffffffff accomplish the same thing? >>>>>> >>>>>> Loren >>>>>> >>>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> --- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "BeagleBoard" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/beagleboard/9mctrG26Mc8/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> beagleboard...@googlegroups.com. >>>> 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 beagleboard...@googlegroups.com. >>> 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 a topic in the >>> Google Groups "BeagleBoard" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/beagleboard/9mctrG26Mc8/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> beagleboard...@googlegroups.com. >>> 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 beagleboard...@googlegroups.com. >> 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
