Good day,
I have several Beaglebone Black Rev C. They are connected to my LAN by using a static IP address. I observed that from time to time connecting to the Beaglebone Black via ethernet is not possible.
I identified the following behavior:
The ethernet port has two LEDs, a Green one and an Orange/Yellow one. If I apply power to the Beaglebone Black I noticed that the green LED immediately starts to blink. However, the yellow LED stays very often dark. It simply never blinks during the whole boot process of the board. In this case ethernet will not be available after booting linux and the board can not be reached via ethernet.
My workaround:
Is this a known respectively a bug? I observed this with several Beaglebone Black Rev-C from Element 14. I also have 2 Rev-B boards and I think (currently not 100% sure since these boards are not used at the moment) that I observed the same behavior.
I found a posting at TIs webbord regarding this problem. There a guy from TI described this as a bug in used PHY. Since the RESET-input of that PHY is not connected to a (switchable) output pin on the BBB, only power of/on helps to workaround this problem. With such a connection a software workaround would have been possible where the PHY is resetted by Ethernet-driver until it reacts as expected.
Could you post the link to the TI thread where this is discussed?
Who is actually involved in choosing parts for the BBB and in adding layout changes? I offer sending one of mine BBBs to someone involved in the BBB developing process for evaluation purposes if requested.
I mean this behavior is pretty annoying, this morning it took me almost 20 attempts to get one BBB running with ethernet. Furthermore I assume that many posts in forums related to non-working BBB ethernet may be related to this problem.
I am. My name and contact information is on the cover page of the System Reference Manual.
Gerald
Gerald,
Is there any known fix for this problem besides a physical reset, and can be done from the command line?
Thanks
If you use the correct SW image, the issue is taken care of. The problem is that the SW assumes a MDIO address. The address can be corrupted by the processor pins changing state on power up and the rPHY cannnot read the strapping options correctly. As long as the SW scans for all address ranges, then it should work.
Gerald
Do you know which sw build specifically by chance? Is this question I should direct to Robert?
This has been discussed many many times on the forum. But Yes, Robert is the one.
Gerald