• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 185 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: EOE (Ethernet over Ethercat) support on AM64x

Philippe Schenker
Prodigy 40 points

Part Number: AM6442

Dear Community,

We'd like to implement EOE in a future-proof way. In older TI SDKs, TI provided linux patches with rpmsg_eth as well as patches needed for U-Boot located in <ind_comms_sdk>/networking_tunneling_patches/U-boot. Since "ind_comms_sdk_am64x_2026_00_00_06" these patches are no longer provided, but the documentation for this version still mentions them:
https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am64x/latest/docs/api_guide_am64x/EXAMPLES_INDUSTRIAL_COMMS_ETHERCAT_SUBDEVICE_TUNNELING_DEMO_HOME.html

Also on the linux mailinglist there was a discussion and the outcome was that rpmsg_eth will not get accepted.

What is TI's way of supporting EOE now? How shall we implement it?

Thanks and Best Regards,
Philippe

  • 0
    TI__Guru 51371 points

    Is Linux network stack tunneling a requirement here?  Have you checked EtherCAT SubDevice: Webserver Example

  • 0
    Prodigy 40 points

    Hi Pratheesh,

    Thanks for the fast reply.

    Yes, Linux network stack tunneling is the requirement. Our EtherCAT stack runs on a R5F (FreeRTOS) for the RT process data, the services (web app, SSH, remote management) run on Linux/A53, so we need the EoE frames as a normal virtual interface in Linux. The Webserver Example runs LWIP on the R5F and never reaches Linux, so it does not help here.

    Running the stack on Linux is no option for us: hard RT on the process data, plus a fast-boot requirement (slave must be up long before Linux finished booting). So we are stuck with the split case (stack on R5F, EoE bridged to Linux), which is exactly what rpmsg_eth used to do.

    Question: since rpmsg_eth was rejected upstream as out-of-tree netdev, is the intended replacement a userspace daemon bridging a rpmsg_char endpoint to a TAP device (both already in the Linux SDK)? If yes, is there a reference from TI or do we write it ourself? If no, what is the supported way today?

    Thanks,
    Philippe

  • 0
    TI__Prodigy 560 points

    Hi Philippe, 

    Philippe Schenker said:
    TI provided linux patches with rpmsg_eth as well as patches needed for U-Boot located in <ind_comms_sdk>/networking_tunneling_patches/U-boot. Since "ind_comms_sdk_am64x_2026_00_00_06" these patches are no longer provided

    The network tunneling patches (which includes the U-Boot patch) are not part of the standard Ind Comms SDK available on ti.com, neither is the EoE tunneling example. This is because the tunneling examples are available exclusively on the premium Ind Comms SDK, and is available on request. Please reach out to your TI sales representative to know more about the premium Ind Comms SDK. 

    Philippe Schenker said:
    Also on the linux mailinglist there was a discussion and the outcome was that rpmsg_eth will not get accepted.

    What is TI's way of supporting EOE now? How shall we implement it?

    The EoE tunneling example in the Ind Comms SDK 2026 release was tested with TI Linux kernel 11.0.9.4. Operability is not verified with more recent Linux kernel versions.
    I will have to get back to you regarding the future support for rpmsg_eth after checking internally. 

    Regards,
    Bharath

  • +1 in reply to Bharath Kartha A
    TI__Prodigy 560 points

    Hi Philippe, 

    So as you mentioned, rpmsg_eth wasn't accepted for upstream. The suggested alternative is to use virtio_net instead of rpmsg_eth.
    We're still in the process of planning this fix but unfortunately I cannot comment on a timeline.

    To enable EoE Tunneling (or any other tunneling examples from the ind_comms_sdk), the current solution is to downstream or to use TI Linux kernel.

    Regards,
    Bharath

  • 0 in reply to Bharath Kartha A
    Prodigy 40 points

    HI Bharath

    Thanks for your answer, noted that it's in the premium SDK.

    Bharath Kartha A said:
    I will have to get back to you regarding the future support for rpmsg_eth after checking internally. 

    I would still appreciate if you could check what the plan from TI is how to support this in mainline. 

    Best Regards,
    Philippe

  • 0 in reply to Philippe Schenker
    TI__Prodigy 560 points

    Hi Philippe,

    A solution possibly using virtio_net is being discussed internally and is likely to be upstreamed from TI as a future support. But like I mentioned before - I cannot comment on a timeline for this.

    Regards,
    Bharath

  • 0 in reply to Bharath Kartha A
    Prodigy 40 points

    That's good enough. Thank you very much for your help! Best Regards, Philippe