512-861-3400Log inCreate Account

Ethernet does not work without active UART session

Forums › Devices › OSD335x-SM › Ethernet does not work without active UART session

Viewing 10 reply threads
  • Author
    Posts
    • September 24, 2019 at 2:40 pm #9151
      Kartik Jangamslisgrinder
      Participant

      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

      • This topic was modified 4 years, 7 months ago by Kartik Jangamslisgrinder. Reason: spelling
    • September 24, 2019 at 2:45 pm #9153
      Kartik Jangamslisgrinder
      Participant

      I could not upload .txt files so here are pastebin links:
      No working ethernet: https://pastebin.com/1EDpUs8S
      Working ethernet: https://pastebin.com/RRdNT6n2

    • September 25, 2019 at 6:25 pm #9162
      Kartik Jangamslisgrinder
      Participant

      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:

      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

      • This reply was modified 4 years, 7 months ago by Kartik Jangamslisgrinder. Reason: incorrect console output
    • September 26, 2019 at 10:28 am #9167
      Kartik Jangamslisgrinder
      Participant

      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

    • October 14, 2019 at 11:30 am #9234
      Eshtaartha Basu
      Moderator

      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.

      Attachments:

      1. Screen-Shot-2019-10-14-at-11.15.12-AM.png

    • October 14, 2019 at 3:20 pm #9237
      Kartik Jangamslisgrinder
      Participant

      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

    • October 21, 2019 at 1:22 pm #9258
      Neeraj Dantu
      Moderator

      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

    • October 22, 2019 at 2:41 pm #9276
      Kartik Jangamslisgrinder
      Participant

      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

    • October 29, 2019 at 1:35 pm #9329
      Neeraj Dantu
      Moderator

      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

    • October 29, 2019 at 2:11 pm #9330
      Kartik Jangamslisgrinder
      Participant

      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

    • October 29, 2019 at 2:42 pm #9331
      Neeraj Dantu
      Moderator

      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

  • Author
    Posts
Viewing 10 reply threads
  • You must be logged in to reply to this topic.

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.