• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 961 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.

Original question:

AM6442: Linux HSR, PRP & PTP support on PRU-ICSSG CPSW & CPSW3G

AM6442: HSR & PRP support dependency on interface

Chris
Intellectual 301 points
Part Number: AM6442
Other Parts Discussed in Thread: SK-AM64B

Dear TI team,

I was looking on the HSR/PRP offloading version in Linux. I understood that the PRU_ICCSG core shall be used as ethernet driver for offloading. We are planning to use CPSW_RGMII1 & CPSW_RGMII2 (similar to SKAM64B) for connecting the ethernet PHY. Can we use the HSR offloading using this interface configuration?  Should we use PRGx_RGMII1  & PRGx_RGMII2 for enabling the offloading instead CPSW_RGMII1 & CPSW_RGMII2? Any such dependency?

Thank you

Chris

  • +1
    TI__Mastermind 27050 points

    HSR forwarding offload requires using ICSSG see https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/HSR_PRP.html?highlight=offload and look for offload. You need 2 Ethernet RGMII's from the same ICSSG, so with evaluation boards you'll need https://www.ti.com/tool/TMDS64EVM and configure the device tree overlay so you get 2 ports from ICSSG.

      Pekka

  • 0 in reply to Pekka Varis
    Intellectual 301 points

    Thanks Pekka,

    I've come to realize that in order to meet the offload requirement in our hardware design, we should utilize ICSSG Ethernet ports. The SK-AM64B appears to be unsuitable for testing the offloaded version.

    We require support for features like HSR, PRP, STP, and others for Ethernet, but it seems that, as of now, only the HSR offload version has been released for Linux. Therefore, we can use HSR with the offloaded version and PRP with the Linux kernel's available support. If we opt for ICSSG RGMIIs, we have the flexibility to choose between the ICSSG offloaded version or the Linux kernel-supported version. Is my interpretation correct?

    Thank you

  • +1 in reply to Chris
    TI__Mastermind 27050 points
    Chris said:
    Therefore, we can use HSR with the offloaded version and PRP with the Linux kernel's available support. If we opt for ICSSG RGMIIs, we have the flexibility to choose between the ICSSG offloaded version or the Linux kernel-supported version. Is my interpretation correct?

    Yes. With ICSSG based Ethernet you can run standard Ethernet, HSR with forwarding offload as cut-through, and PRP.

    Chris said:
    We require support for features like HSR, PRP, STP, and others for Ethernet, but it seems that, as of now, only the HSR offload version has been released for Linux.

    HSR and PRP both work today in Linux. HSR has the option of having switching at layer 2 hardware in ICSSG using the forwarding offload. For PRP the only offload benefit will be duplicate drop, which should result in a CPU load saving at the endpoint. This duplicate drop offload is identical to HSR duplicate drop and is planned for SDK 9.2. Spanning tree protocol (STP) and the newer rapid version of it (RSTP) is typically used to detect loops in a network, and not something we'd look to offload or implement in a TI specific way. For STP and RSTP I'd suggest you look at https://github.com/mstpd/mstpd .

    Chris said:
    we should utilize ICSSG Ethernet ports. The SK-AM64B appears to be unsuitable for testing the offloaded version.

    To use ICSSG based RGMII you need https://www.ti.com/tool/TMDS64EVM and then modify uEnv.txt in boot partition to contain:

    #ICSSG on GP EVM 9.0 add to uEnv.txt
name_overlays=ti/k3-am642-evm-icssg1-dualemac.dtbo

    By default eth0 and eth1 come from CPSW3G, and only eth2 from ICSSG. With the above tweak eth1 is selected at pin-mux to be from the ICSSG that eth2 is from instead.

      Pekka

  • 0 in reply to Pekka Varis
    Intellectual 301 points

    Thanks Pekka for the detailed comments