I also believe the issue mentioned here : http://e2e.ti.com/support/arm/sitara_arm/f/791/t/366351.aspx is the same as we are facing in bbb.
Regards, Pratik On Monday, 24 November 2014 21:12:50 UTC+5:30, alexschn...@gmail.com wrote: > > 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/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 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.
