Hi Pratik,
As I studied the latest kernel code (3.8.13-bone67), I noticed that the patch 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 in the “bootcmd” variable and rebuilt the U-Boot. But that didn’t work at all, i.e. the required registers of LAN8710A 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, 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
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 
Seems i sell this board and getting a RPI for that.