Pratik, Thank you very much for sharing you experience with this issue. Could you please provide more details on what and how you changed in cpsw platform data?
Actually, rebuilding the kernel sounds a bit dangerous to me, because it may have some side effects, in my opinion. For instance, that "dynamical fix" you mentioned results in the situation when the processor communicates to the transceiver chip using some other address, not the default 0. OK, now everything works, it's fine. But what if some piece of code unknown to you still relies on that default address 0, and it gets executed some time later, under certain conditions? Theoretically, it could cause something even worse than this current issue. Regards, Alex On Tuesday, November 25, 2014 6:00:16 AM UTC+1, rathod....@gmail.com wrote: > > Well, may be you can add your mdio command inside u-boot source code's > default bootcmd and rebuild the u-boot. > In my case, I updated my cpsw platform data (I use 3.2 kernel, so no > device tree) inside kernel dynamically to fix this problem. It seems to be > working for me. > > 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.
