Forums › Devices › OSD335x-SM › Ethernet does not work without active UART session
Good afternoon,
I have noticed that our custom board’s ethernet interface does not initialize properly without an active UART0 session. I don’t even know where to begin with this peculiar problem. Our board only has UART0 and UART2 accessible and is based on the OSD RED dev board. I am running the Debian 10 console image from elinux (https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_10_.28Buster.29_-_Weekly) with the OSD RED overlay applied. I have also attached the different dmesg outputs of ethernet “not working” and “working”.
Thanks for your help.
Kartik
I could not upload .txt files so here are pastebin links:
No working ethernet: https://pastebin.com/1EDpUs8S
Working ethernet: https://pastebin.com/RRdNT6n2
To provide more details on the problem,
Interface is brought up but it assigns itself a “random” ip address based on the “/etc/networks” file:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
debian@beaglebone:~$ ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 98:5d:ad:6b:da:61 brd ff:ff:ff:ff:ff:ff inet 169.254.52.156/16 brd 169.254.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::9a5d:adff:fe6b:da61/64 scope link valid_lft forever preferred_lft forever 3: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 98:5d:ad:6b:da:63 brd ff:ff:ff:ff:ff:ff inet 192.168.7.2/30 brd 192.168.7.3 scope global usb0 valid_lft forever preferred_lft forever 4: usb1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 98:5d:ad:6b:da:66 brd ff:ff:ff:ff:ff:ff inet 192.168.6.2/30 brd 192.168.6.3 scope global usb1 valid_lft forever preferred_lft forever 5: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10 link/can 6: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10 link/can |
I’ve tried to manually assign an ip address, changed back to dhcp, enable and disable the interface using connmanctl but with no luck. Ive manually enabled and disabled various services from “/etc/systemd/system/” folder and that still doesn’t help.
Am I missing something super simple that its hiding in plain sight?
Regards,
Kartik
An update of my findings from yesterday:
I double checked the pull-up/down states of UART0 and UART2 pins and they are correct however, if I connect +3v3 to any of the UART0 or UART2 Rx lines, the system boots up fine and ethernet interface sets up and authenticates correctly to the network.
Is there a system service that is watching these lines?
Is there some timing requirement that I am missing?
Regards,
Kartik
Hello slisgrinder,
Based on your observations, it looks like your UARTx_Rx lines are not pulled up (internally or externally). UARTx_Rx lines have to be pulled up to avoid Break Condition (https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter#Break_condition). This is the reason your system is booting up fine when you connect Rx lines to +3v3 externally.
In case of RED board, we have pulled up UART0_RX pin internally by declaring pull up resistor in the RED device tree (screenshot attached). Check your device tree to make sure internal pull up is enabled on the UART0_Rx pin.
Good afternoon Eshtaartha,
I have ensured that the internal pull up is enabled on UART0 Rx as well as an external pull-up on UART2 Rx. I am getting intermittent boots with networking configured correctly. When the in the “failed” state, I checked PHY operation using ethtool and mii-tool, the PHY is operational with an appropriate link configuration. Simply, networking service has configured the eth0 interface to a random address as part of the “link-local” address (169.254.x.x) from /etc/networks file.
– Manually assigning a static address doesn’t yield any results. I just see a second address using ifconfig but nothing on wireshark.
– Using dhclient to issue a dhcp request doesn’t yield any results
– A reset cannot be performed using ethtool “Operation not supported”
– A reset using mii-tool does perform a soft reset but yields no results
What did work was manually hard resetting the PHY (I used tweezers to pull the reset line of the PHY low) and rebooting – without external pull ups.
May be I am interpreting this incorrectly, I wonder if it has something to with the following advisory from the AM335x ERRATA “Advisory 1.0.23 – Ethernet Media Access Controller (EMAC) and Switch Subsystem Reset Isolation Feature is not Supported”. Could it possibly be “looking” at a different interface as part of the dual Gigabit interface?
As a note, I always have wireshark running to sniff the packets and “doesn’t yield any results” is I don’t see any packets on the line.
I appreciate you help,
Kartik
Slisgrinder,
We apologize for the delayed response. Can you compare ‘dmesg’ output logs between a good ethernet configuration and a bad ethernet configuration? Specifically, look at the MDIO address of the PHY detected when the processor probes the MDIO interface and verify whether that address matches with the hardware address being set in the PHY circuit.
Another issue can be the the PHY is being brought out of reset prematurely. You could try and hold the PHY in reset for a longer period of time during boot up and see if that helps.
We would also advise you to compare your design with the known good working RED board(as you are using the same Ethernet PHY:Â https://octavosystems.com/octavo_products/osd3358-sm-red/)
The errata 1.0.23 seems to indicate that the CPSW peripheral reset cannot be isolated from the processor reset. As such, it is unrelated to the issue you are seeing.
Please let us know how the debug is going or if you have additional questions.
Best,
Neeraj
Good afternoon Neeraj,
It seems it is some weird timing issue between the PHY coming out of reset on power-up and the Octavo. I connected the reset line from the PHY to one of the GPIO on the Octavo, configured it as a GPIO with pull-up and assigned it to the MDIO interface definition in the device tree as a reset gpio (see: https://github.com/torvalds/linux/blob/4d88e3d24905eafa98cef0fc29365649ad8977b5/Documentation/devicetree/bindings/net/mdio.txt).
I am now curious to see if there is a software workaround to this hardware jumper mod so that we don’t have to do a design rev nor any modification to our existing inventory.
Thank you for your help!
Regards,
Kartik
Kartik,
Based on the schematics we have, the RESET line for the PHY is pulled up to the 3.3V line. If you have a GPIO pin connection on this pin or a RESET supervisor, it would have been possible to modify software to bring the PHY out of RESET later.
So, unfortunately, we think a design change is necessary. Please let us know if you need any more help from Octavo.
Best,
Neeraj
Good afternoon Neeraj,
Thank you for your help thus far, its really appreciated. We will make the necessary changes to our design and rev it.
Will there be a change/note in the reference design? I only ask this in case someone has a similar problem down the road.
Regards,
Kartik
Kartik,
We have not faced this issue with the RED board. In light of your issue, we will make a note to update the PHY RESET circuit when we Rev the board. Thanks for the inputs.
Best,
Neeraj
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields