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 <javascript:>> 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/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. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Gerald > > ger...@beagleboard.org <javascript:> > 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.
