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, <alexschneider...@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/to >>>>>>> pic/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/to >>>>>> pic/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 > <javascript:_e(%7B%7D,'cvml','beagleboard%2bunsubscr...@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.
