Hi Pratik, As I studied the latest kernel code (3.8.13-bone67), I noticed that the patch <https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ> mentioned by "Jay @ Control Module Industries" is already there, but apparently it doesn't help.
After a lot of experiments with U-Boot, I'm more convinced that the problem cannot be solved with U-Boot only. Actually, I included those "rewriting" commands I mentioned earlier <https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/1FuI_i5KW10J> in the "bootcmd" variable and rebuilt the U-Boot. But that didn't work at all, i.e. the required registers of LAN8710A <http://ww1.microchip.com/downloads/en/DeviceDoc/8710a.pdf> transceiver weren't rewritten (maybe some delay is required before and after those commands). I also tried rewriting them "manually" in U-Boot command line, as I mentioned earlier, but this time I tried various combinations of "Soft Reset", "Power Down" and "Restart Auto-Negotiate" commands afterwards. It was all futile. Even when transceiver settings like PHY address, mode, etc. are correct (as a result of rewriting them manually), the processor doesn't recognize the transceiver after reset command by U-Boot. And the state of some transceiver registers, containing info about its link partner, indicates that this is the problem of the link partner, i.e. the processor. And in this case, only a power-on or "button" reset can bring the processor to the state where it can detect the transceiver. Also, I read the processor Ethernet Subsystem registers in U-Boot, both when the transceiver is detected and when it is not. And the difference seems to be in the way the processor uses the content of MDIOALIVE register (the PHY acknowledge status register), because in both cases that content is correct. For example, if the the transceiver powers up with PHY address 0 then the bit 0 of MDIOALIVE is set to 1, if the transceiver powers up with PHY address 2, the bit 2 of MDIOALIVE is set to 1, etc. So, this means that the processor gets the acknowledge from PHY with address 2 after trying to access it, according to the page 2212 of AM335x Sitara Processors Manual <http://www.ti.com/lit/ug/spruh73k/spruh73k.pdf>, and knows that a transceiver with PHY address 2 is around. But then, may be some time later, the processor fails to get the data from the transceiver, because it tries to read by a wrong PHY address, which is reflected by the state of the MDIOUSERACCESS0 register (page 2216 of AM335x manual). When the PHY address is 0, the content of MDIOUSERACCESS0 is 0x23e01058, which means that the data 0x1058 (bits 15-0) was read from the PHY address 0 (bits 20-16), from the PHY register 31 (bits 25-21) and PHY acknowledged the read transaction (bit 29). When the PHY address is 2, the content of MDIOUSERACCESS0 is 0x0020ffff, i.e. the processor attempted to read from PHY address 0 (despite of the content of MDIOALIVE suggesting that PHY address is 2) and, of course, failed. This failure happens somewhere in U-Boot code (I guess, in drivers/net/davinci_emac.c), of course, but the same seems to happen in the kernel code (drivers/net/ethernet/ti/davinci_mdio.c) in spite of that patch, whose purpose is to update the device tree using the content of MDIOALIVE register. Maybe all this happens because the step 4 of the MDIO module initialization procedure, mentioned on page 1972 of AM335x manual, is not present in the code? In that step, it is necessary to save the PHY address in the MDIOUSERPHYSEL0 register, to monitor the the link status of the respective PHY. Alex On Saturday, November 29, 2014 5:54:34 PM UTC+1, rathod....@gmail.com wrote: > > Hi Alex, > > What I tried to say that the fix I applied had same logic which was > described by "Jay @ Control Module Industries" in this discussion. Since > I can not use device tree features of latest kernels, I made the changes > which can fit in kernel 3.2 which is supplied by TI Android code. In my > tests (which included many resets) it seem to be working fine. > > I also believe that rebuilding the kernel is not dangerous as long as we > know what we are doing. :) > > Regards, > Pratik > > > On Saturday, 29 November 2014 21:52:21 UTC+5:30, alexschn...@gmail.com > wrote: >> >> to myersco...@gmail.com: >> >> Hi, >> >> I noticed that simply pushing RESET button actually helps sometimes, in >> my recent experiments. At the same time, pushing POWER button may not help >> sometimes. I have an impression that this issue is a bit different by >> different people. >> >> Have you tried resetting the board by means of RESET button many times, >> without "init 1" command, to see whether RESET button alone can help? >> >> Regards, >> Alex >> >> On Friday, November 28, 2014 11:43:15 PM UTC+1, myersco...@gmail.com >> wrote: >>> >>> Ok, so this just happened to me. What I think ultimately caused it in my >>> case is the OS hung on shutdown, so I had to hard-power-off the board with >>> the power button. When it came back up, no network :/ Connected via the >>> serial terminal and was seeing the same things as others had reported. I >>> have a rev. C board, and this was the first problem I've had with it, >>> running 24x7 since it arrived back in July :) >>> >>> Linux envmon 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l >>> >>> From what I gleaned from what some folks commented a few posts above, >>> this is what I did, and so far it seems to have worked for me: >>> >>> - Logged in as root to the board via the serial terminal >>> - ran the command "init 1" to take the OS into emergency maintenance >>> mode. (I wanted to be in single-user mode because of what I was about to >>> do.) >>> - Once there, I pressed the reset button on the board once. >>> >>> When the board rebooted, I had network again :) >>> >> -- 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.
