It appears that the issue is known for a long time: several registers of the LAN8710A Ethernet transceiver sometimes get wrong values at power-up, in spite of correct pin strapping configurations. One of those wrong values is PHYAD (PHY address in the Special Modes Register), which is erroneously initialized to 2, while the processor expects it to be 0. This makes it impossible for the processor to communicate with the transceiver and override those wrong values.
Here <http://e2e.ti.com/support/arm/sitara_arm/f/791/t/335017.aspx>, they suggest that this issue is inherent in the LAN8710A by Microchip, and may be caused by some interference from the clock signal. However, Microchip did not admit that. The messages within this topic propose 3 main solutions: 1) Rebuilt the device tree to make it somehow work with a PHY address that can take on 0 or 2, or probably some other values 2) Remove C24 capacitor (this is not safe) 3) Change the file drivers/net/ethernet/ti/davinci_mdio.c and rebuild the Linux (this patch, as far as I understand, will update the device tree in such a way that other, non-zero PHY addresses, will become also acceptable) I have tried to do another thing: to rewrite wrong register values with U-Boot, using commands like "mdio write 2 18 0xe0", and I managed to make the content of those registers looking like that of a successfully started transceiver (including the PHYAD and MODE). However, to successfully apply these changes, a reset with RESET button is required. And if I just run "reset" command in U-Boot, the transceiver doesn't work properly after reboot, even though it already has the right PHY address: 0. In this case the registers look like as if the auto-negotiation fails, and as if the link partner (i.e. the processor) doesn't have auto-negotiation ability (the Auto Negotiation Expansion Register contains 0). If that worked, it would be possible to append all required "rewriting commands" into "bootcmd" variable, thus forcing U-Boot to rewrite wrong values automatically. But there is another obstacle on this way: the U-boot I have (2014.10-dirty) does not have "saveenv" command, for some reason. So, I cannot save any changes in environmental variables there. If anyone solved this problem by modifying the device tree or by some U-Boot script, please share the details. On Monday, November 24, 2014 8:18:31 AM UTC+1, Jerin George wrote: > > As suggested in this discussion i moved to 3.14.1 kernel and everything > went well for the first 48 hours. > After that i could see that the ETH stopped responding for close to 10 > seconds. > Then it came back. > > Test set up:- > I'm using BBB for Data acquisition thru ETH. For testing i have connected > BBB and 2 PC in a switch. One PC is running a data acquisition software to > collect data from BBB. Another PC is running the software "Total Network > Monitor" and it keeps on logging the Network status by pinging to both BBB > & the other PC. > > After 48 Hours :- > I could see that the Total Network monitor reported that link to BBB was > lost for close to 10 seconds. > > Is this a known issue ? Is there any fix to this. > > regards, > Jerin > > On Saturday, 22 November 2014 14:25:03 UTC+5:30, alexschn...@gmail.com > wrote: >> >> But the SW can do that only when the transceiver chip is always in a >> "writable" state, which is unfortunately not the case. >> >> On Saturday, November 22, 2014 1:38:54 AM UTC+1, Gerald wrote: >>> >>> All the SW has to do itvwrite to the registers and not rely on the >>> straps. Hmm I have been saying that for 3+ years now. >>> >>> Gerald >>> >>> On Friday, November 21, 2014, <alexschn...@gmail.com> wrote: >>> >>>> Hi Gerald, >>>> >>>> I meant "strap values", not connections on the board. As far as I >>>> understand it, correct strappings alone cannot always ensure correct bits >>>> in the respective registers of the transceiver chip. The power-on and >>>> reset >>>> timing is also important, and this timing, unlike strappings, is different >>>> at least for some revisions. >>>> >>>> In my experiments, a reset performed with RESET button never resolved >>>> the "phy not found" problem. A power-on reset as well as a reset with >>>> POWER >>>> button helped, but not always. Cannot the transceiver sometimes enter into >>>> some unresponsive state, which makes it impossible for the processor to >>>> override the strappings? >>>> >>>> Alex >>>> >>>> On Thursday, November 20, 2014 9:50:56 PM UTC+1, Gerald wrote: >>>>> >>>>> If you have what you think are he correct trappings, let me know. They >>>>> are the same for all revisions. >>>>> >>>>> Also, if you reset the board after it is up, the strappings are >>>>> overridden by the states on those pins from the processor that override >>>>> the >>>>> strapping options. >>>>> >>>>> Gerald >>>>> >>>>> >>>>> On Thu, Nov 20, 2014 at 12:39 PM, <alexschn...@gmail.com> wrote: >>>>> >>>>>> >>>>>> 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/un >>>>>>>>>> subscribe. >>>>>>>>>> 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...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Gerald >>>>> >>>>> ger...@beagleboard.org >>>>> http://beagleboard.org/ >>>>> http://circuitco.com/support/ >>>>> >>>> -- >>>> 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. >>>> >>> >>> >>> -- >>> Gerald >>> >>> ger...@beagleboard.org >>> http://beagleboard.org/ >>> http://circuitco.com/support/ >>> >>> -- 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.
