Hi Bill, Thank you for doing that experiment.
I run two automated tests with the "delayed PHY initialization", each one with 130 power-ups over 130 minutes (one power-up per minute), where I still saw a few "Phy 0 not found" messages. In the first test, BBB periodically reset itself by means of a MOSFET connecting nRESET_INOUT to the ground, each time after running Linux for one minute. Only one "Phy not found" happened. In the second test, BBB periodically disconnected itself from the power supply, by means of a relay, again, each time after running Linux for one minute. Seven "Phy not found" happened. So, it appears that 1s delay in U-Boot code doesn't always help. However, in these two tests, I never checked what happened with the network in Linux, after "Phy not found". Because in both tests BBB immediately reset itself by that MOSFET as soon as U-Boot could not read from the chip with PHY address 0 (I checked this in special test code in U-Boot). But I think it is quite possible that the network still works OK in Linux, even after "Phy not found" happens in U-Boot, since 1 second is enough to ensure that LAN 8710A is OK. It could just have another PHY address, e.g. 2 instead of normal 0. In this case, the network would work, even in U-Boot, despite of "Phy not found" shown in console, as I described here <https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/PK6bxAszAkoJ>. We need more experiments. Regards, Alex On Monday, February 9, 2015 at 5:42:16 PM UTC+1, [email protected] wrote: > > > > On Thursday, February 5, 2015 at 11:16:55 AM UTC-7, [email protected] > wrote: > >> After I and my colleagues had fruitlessly tried many things, our hardware >> developer came up with a working solution: delaying the PHY initialization >> performed by the U-Boot we use (v2014.10, git checksum >> c43fd23cf619856b0763a64a6a3bcf3663058c49). This ensured that U-Boot code >> tried to access LAN8710A only after this chip had come out of reset. So, >> inserting "udelay(1000000);" at the beginning of "board_eth_init()" >> function in board/ti/am335x/board.c and recompiling U-Boot worked in our >> experiments. >> >> > Alex, > > I've compiled a boot-loader with the delay in the Ethernet initialization > and have done some quick testing on it. I haven't seen any issues yet > (where I normally would) but have only tested one board so far. To be > exact, I've power cycled a BBB 20 times and confirmed that the Ethernet was > working after each boot. Normally I would have seen at least a few Ethernet > lockups after 20 resets on this board. There may be something to this. > > Regards, > Bill > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
