AM6442: Speeds supported for PRP and HSR using PSDK Linux

Part Number: AM6442
Other Parts Discussed in Thread: TMDS64EVM

Could you please tell me the speeds supported for PRP and HSR using PSDK Linux?

The information in the documents is as follows.

Industrial Communication Protocol Support for Arm®-based Microcontrollers and Processors
www.ti.com/.../sprt769.pdf
DECEMBER 2023

6 PRP Support
"The AM243x SDK includes support for 100Mbps PRP and the AM64x SDK includes support for 1Gbps PRP."

7 HSR Support
"The AM243x SDK includes support for 100Mbps HSR and the AM64x SDK includes support for 1Gbps HSR."

AM64 AM243 Industrial Communications.png

Industrial Communication Protocols Supported on TI Processors and MCUs (Rev. F)
www.ti.com/.../sprach6f.pdf
REVISED SEPTEMBER 2025

2.5 Parallel Redundancy Protocol (PRP)
"The AM64x/AM243x can support 100M/1G PRP"

2.6 High-Availability Seamless Redundancy (HSR)
"The AM64x/AM243x version can support 100M/1G HSR"

Does the latest PSDK Linux support all speeds of 10/100/1Gbps for PRP and HSR with ICSSG?

Does the latest PSDK Linux support all speeds of 10/100/1Gbps for PRP with CPSW?

PROCESSOR-SDK-LINUX-AM64X
www.ti.com/.../PROCESSOR-SDK-LINUX-AM64X
Version: 11.02.08.02
Release date: Dec 15, 2025

Best regards,

Daisuke

 

  • Hello Daisuke, 

    Does the latest PSDK Linux support all speeds of 10/100/1Gbps for PRP and HSR with ICSSG?

    Yes, the latest Linux SDK supports up to 1Gbps HSR and PRP with ICSSG.

    Does the latest PSDK Linux support all speeds of 10/100/1Gbps for PRP with CPSW?

    While we don't advertise CPSW for HSR and PRP, in theory HSR and PRP nonoffload mode (up to 1Gbps) can be run on CPSW Ethernet. We have not extensively tested this. 

    -Daolin

  • Daolin-san,

    Thank you for your reply.

    I would recommend that our customer use ICSSG instead of CPSW.

    The customer will test HSR Offload and PRP Offload by referring to the documents below.

    software-dl.ti.com/.../HSR_Offload.html

    software-dl.ti.com/.../PRP_Offload.html

    For HSR/PRP Offload, is the link speed set according to the link partner through auto-negotiation?

    For HSR/PRP Offload, is it possible to forcibly set the local link speed to 10 Mbps or 100 Mbps (for example, using ethtool)?

    software-dl.ti.com/.../PRU_ICSSG_Ethernet.html
    # ethtool -s eth1 duplex full speed 100

    Best regards,

    Daisuke

  • Hello Daisuke,

    For HSR/PRP Offload, is the link speed set according to the link partner through auto-negotiation?

    Yes, the link speed is set with auto-negotiation assuming the Ethernet PHY that is used supports auto-negotiation.

    For HSR/PRP Offload, is it possible to forcibly set the local link speed to 10 Mbps or 100 Mbps (for example, using ethtool)?
    software-dl.ti.com/.../PRU_ICSSG_Ethernet.html
    # ethtool -s eth1 duplex full speed 100

    Yes, it is possible to forcibly set a speed other than the link speed from auto-negotiation. You can so exactly with the command you have specified.

    -Daolin

  • Daolin-san,

    Thank you for your reply.

    Our customer tested HSR/PRP Offload by referring to the documents below.

    software-dl.ti.com/.../HSR_Offload.html

    software-dl.ti.com/.../PRP_Offload.html

    They operate at 1 Gbps by using auto-negotiation or 100 Mbps by forcibly fixing the link speed.

    However, when forcibly fix it at 10 Mbps, they do not operate, and ping does not reach.

    To forcibly fix it at 100 Mbps:
    ethtool -s eth1 speed 100 duplex full autoneg off
    ethtool -s eth2 speed 100 duplex full autoneg off

    To forcibly fix it at 10 Mbps:
    ethtool -s eth1 speed 10 duplex full autoneg off
    ethtool -s eth2 speed 10 duplex full autoneg off

    When communicating as normal Ethernet before executing the HSR/PRP Offload shell script, it operates even when forcibly fixed at 10 Mbps, and ping also succeeds.

    Does HSR/PRP Offload support 10 Mbps?

    Best regards,

    Daisuke

  • Hi Daisuke, 

    Does HSR/PRP Offload support 10 Mbps?

    Is the customer testing on SDK 11.2? Is the customer using RT-Linux SDK or regular Linux SDK?

    While I didn't get a chance to test with SDK 11.2 yet, on my SDK 11.1 setup with 3x AM64x EVM in an HSR ring, using the same "ethtool -s ethX speed 100 duplex full autoneg off" command to set speed to 10Mbps, I see that HSR offload is functional with ping. 

    What is the customer's test topology? (i.e. 3x EVMs or 2x EVMs?, HSR or PRP?)

    -Daolin

  • Daolin-san,

    Thank you for your reply.

    Is the customer testing on SDK 11.2? Is the customer using RT-Linux SDK or regular Linux SDK?

    As I linked in my original post, the customer is using the latest version (v11.02.08.02) of the regular Linux SDK.

    PROCESSOR-SDK-LINUX-AM64X
    www.ti.com/.../PROCESSOR-SDK-LINUX-AM64X
    Version: 11.02.08.02
    Release date: Dec 15, 2025

    What is the customer's test topology? (i.e. 3x EVMs or 2x EVMs?, HSR or PRP?)

    The customer is directly connecting two TMDS64EVM boards and testing both HSR Offload and PRP Offload.

    Best regards,

    Daisuke

  • Hello Daisuke, 

    However, when forcibly fix it at 10 Mbps, they do not operate, and ping does not reach.

    I ran the HSR offload test on SDK 11.2 between two AM64x EVMs connected to each other and noticed that ping was able to reach when both paths are connected. When disconnecting one path/cable at a time, I did see some packet loss. Is the customer disconnecting a cable during their test or just testing if ping is functional when both paths are fully connected?

    I have found some other HSR issues with latest SDK 11.2 that I've created bug reports for the team to look into. In the meantime, I would suggest the customer to continue evaluating HSR and PRP offload on SDK 11.1 since HSR/PRP offload functionality has been extensively tested on SDK 11.1.

    -Daolin

  • Daolin-san,

    Thank you for your reply.

    Does SDK 11.1 support PRP?

    Our customer tested HSR/PRP offload with SDK 11.1, but PRP did not work.

    root@am64xx-evm:~# sh prp_setup.sh prp_hw eth1 eth2 192.168.1.20
    ip=192.168.1.20
    if=prp0
    mac=70:ff:76:1f:3c:8e
    slave-a=eth1
    slave-b=eth2
    Cannot find device "prp0"
    [ 93.167512] icssg-prueth icssg1-eth eth1: Link is Down
    [ 93.194441] icssg-prueth icssg1-eth eth2: Link is Down
    [ 93.202338] remoteproc remoteproc7: stopped remote processor 3008a000.txpru
    [ 93.210562] remoteproc remoteproc14: stopped remote processor 30084000.rtu
    [ 93.217540] remoteproc remoteproc13: stopped remote processor 300b4000.pru
    [ 93.224445] remoteproc remoteproc8: stopped remote processor 3008c000.txpru
    [ 93.231451] remoteproc remoteproc16: stopped remote processor 30086000.rtu
    [ 93.238350] remoteproc remoteproc15: stopped remote processor 300b8000.pru
    Available offload features for eth1:
    hsr-tag-ins-offload: off
    hsr-tag-rm-offload: off
    hsr-fwd-offload: off
    hsr-dup-offload: off
    Actual changes:
    hsr-tag-ins-offload: on [not requested]
    hsr-dup-offload: on
    Enabled offload features for eth1:
    hsr-tag-ins-offload: on
    hsr-tag-rm-offload: on
    hsr-fwd-offload: on
    hsr-dup-offload: on
    Available offload features for eth2:
    hsr-tag-ins-offload: off
    hsr-tag-rm-offload: off
    hsr-fwd-offload: off
    hsr-dup-offload: off
    Actual changes:
    hsr-tag-ins-offload: on [not requested]
    hsr-dup-offload: on
    Enabled offload features for eth2:
    hsr-tag-ins-offload: on
    hsr-tag-rm-offload: on
    hsr-fwd-offload: on
    hsr-dup-offload: on
    [ 94.486747] icssg-prueth icssg1-eth eth1: timeout waiting for command done
    [ 94.503900] icssg-prueth icssg1-eth eth2: timeout waiting for command done
    [ 94.510839] icssg-prueth icssg1-eth: Failed to restart the firmwares, aborting the process
    [ 97.567489] prp0: Slave A (eth1) is not up; please bring it up to get a fully working HSR network
    [ 97.576432] prp0: Slave B (eth2) is not up; please bring it up to get a fully working HSR network
    [ 97.608124] remoteproc remoteproc13: powering up 300b4000.pru
    [ 97.614307] remoteproc remoteproc13: Direct firmware load for ti-pruss/am64x-sr2-pru0-pruprp-fw.elf failed with error -2
    [ 97.625379] remoteproc remoteproc13: request_firmware failed: -2
    [ 97.631523] icssg-prueth icssg1-eth: failed to boot PRU0: -2
    RTNETLINK answers: No such file or directory
    [ 97.654631] remoteproc remoteproc13: powering up 300b4000.pru
    [ 97.660903] remoteproc remoteproc13: Direct firmware load for ti-pruss/am64x-sr2-pru0-pruprp-fw.elf failed with error -2
    [ 97.671844] remoteproc remoteproc13: request_firmware failed: -2
    [ 97.677947] icssg-prueth icssg1-eth: failed to boot PRU0: -2
    RTNETLINK answers: No such file or directory

    It appears that SDK 11.1 does not include the PRUSS firmware for PRP that is included in SDK 11.2.

    am64x-sr2-pru0-pruprp-fw.elf
    am64x-sr2-pru1-pruprp-fw.elf
    am64x-sr2-rtu0-pruprp-fw.elf
    am64x-sr2-rtu1-pruprp-fw.elf
    am64x-sr2-txpru0-pruprp-fw.elf
    am64x-sr2-txpru1-pruprp-fw.elf

    root@am64xx-evm:~# ls /usr/lib/firmware/ti-pruss/
    am335x-pru0-prueth-fw.elf     am64x-sr2-rtu1-prusw-fw.elf
    am335x-pru0-pruhsr-fw.elf     am64x-sr2-txpru0-prueth-fw.elf
    am335x-pru0-prusw-fw.elf      am64x-sr2-txpru0-pruhsr-fw.elf
    am335x-pru1-prueth-fw.elf     am64x-sr2-txpru0-prusw-fw.elf
    am335x-pru1-pruhsr-fw.elf     am64x-sr2-txpru1-prueth-fw.elf
    am335x-pru1-prusw-fw.elf      am64x-sr2-txpru1-pruhsr-fw.elf
    am437x-pru0-prueth-fw.elf     am64x-sr2-txpru1-prusw-fw.elf
    am437x-pru0-pruhsr-fw.elf     am65x-pru0-prueth-fw.elf
    am437x-pru0-prusw-fw.elf      am65x-pru1-prueth-fw.elf
    am437x-pru1-prueth-fw.elf     am65x-rtu0-prueth-fw.elf
    am437x-pru1-pruhsr-fw.elf     am65x-rtu1-prueth-fw.elf
    am437x-pru1-prusw-fw.elf      am65x-sr2-pru0-prueth-fw.elf
    am57xx-pru0-prueth-fw.elf     am65x-sr2-pru0-pruhsr-fw.elf
    am57xx-pru0-pruhsr-fw.elf     am65x-sr2-pru0-prusw-fw.elf
    am57xx-pru0-prusw-fw.elf      am65x-sr2-pru1-prueth-fw.elf
    am57xx-pru1-prueth-fw.elf     am65x-sr2-pru1-pruhsr-fw.elf
    am57xx-pru1-pruhsr-fw.elf     am65x-sr2-pru1-prusw-fw.elf
    am57xx-pru1-prusw-fw.elf      am65x-sr2-rtu0-prueth-fw.elf
    am64x-sr2-pru0-prueth-fw.elf  am65x-sr2-rtu0-pruhsr-fw.elf
    am64x-sr2-pru0-pruhsr-fw.elf  am65x-sr2-rtu0-prusw-fw.elf
    am64x-sr2-pru0-prusw-fw.elf   am65x-sr2-rtu1-prueth-fw.elf
    am64x-sr2-pru1-prueth-fw.elf  am65x-sr2-rtu1-pruhsr-fw.elf
    am64x-sr2-pru1-pruhsr-fw.elf  am65x-sr2-rtu1-prusw-fw.elf
    am64x-sr2-pru1-prusw-fw.elf   am65x-sr2-txpru0-prueth-fw.elf
    am64x-sr2-rtu0-prueth-fw.elf  am65x-sr2-txpru0-pruhsr-fw.elf
    am64x-sr2-rtu0-pruhsr-fw.elf  am65x-sr2-txpru0-prusw-fw.elf
    am64x-sr2-rtu0-prusw-fw.elf   am65x-sr2-txpru1-prueth-fw.elf
    am64x-sr2-rtu1-prueth-fw.elf  am65x-sr2-txpru1-pruhsr-fw.elf
    am64x-sr2-rtu1-pruhsr-fw.elf  am65x-sr2-txpru1-prusw-fw.elf
    
    root@am64xx-evm:~# ls /usr/lib/firmware/ti-pruss/
    am335x-pru0-prueth-fw.elf     am64x-sr2-rtu0-prusw-fw.elf
    am335x-pru0-pruhsr-fw.elf     am64x-sr2-rtu1-prueth-fw.elf
    am335x-pru0-pruprp-fw.elf     am64x-sr2-rtu1-pruhsr-fw.elf
    am335x-pru0-prusw-fw.elf      am64x-sr2-rtu1-pruprp-fw.elf
    am335x-pru1-prueth-fw.elf     am64x-sr2-rtu1-prusw-fw.elf
    am335x-pru1-pruhsr-fw.elf     am64x-sr2-txpru0-prueth-fw.elf
    am335x-pru1-pruprp-fw.elf     am64x-sr2-txpru0-pruhsr-fw.elf
    am335x-pru1-prusw-fw.elf      am64x-sr2-txpru0-pruprp-fw.elf
    am437x-pru0-prueth-fw.elf     am64x-sr2-txpru0-prusw-fw.elf
    am437x-pru0-pruhsr-fw.elf     am64x-sr2-txpru1-prueth-fw.elf
    am437x-pru0-pruprp-fw.elf     am64x-sr2-txpru1-pruhsr-fw.elf
    am437x-pru0-prusw-fw.elf      am64x-sr2-txpru1-pruprp-fw.elf
    am437x-pru1-prueth-fw.elf     am64x-sr2-txpru1-prusw-fw.elf
    am437x-pru1-pruhsr-fw.elf     am65x-pru0-prueth-fw.elf
    am437x-pru1-pruprp-fw.elf     am65x-pru1-prueth-fw.elf
    am437x-pru1-prusw-fw.elf      am65x-rtu0-prueth-fw.elf
    am57xx-pru0-prueth-fw.elf     am65x-rtu1-prueth-fw.elf
    am57xx-pru0-pruhsr-fw.elf     am65x-sr2-pru0-prueth-fw.elf
    am57xx-pru0-pruprp-fw.elf     am65x-sr2-pru0-pruhsr-fw.elf
    am57xx-pru0-prusw-fw.elf      am65x-sr2-pru0-prusw-fw.elf
    am57xx-pru1-prueth-fw.elf     am65x-sr2-pru1-prueth-fw.elf
    am57xx-pru1-pruhsr-fw.elf     am65x-sr2-pru1-pruhsr-fw.elf
    am57xx-pru1-pruprp-fw.elf     am65x-sr2-pru1-prusw-fw.elf
    am57xx-pru1-prusw-fw.elf      am65x-sr2-rtu0-prueth-fw.elf
    am64x-sr2-pru0-prueth-fw.elf  am65x-sr2-rtu0-pruhsr-fw.elf
    am64x-sr2-pru0-pruhsr-fw.elf  am65x-sr2-rtu0-prusw-fw.elf
    am64x-sr2-pru0-pruprp-fw.elf  am65x-sr2-rtu1-prueth-fw.elf
    am64x-sr2-pru0-prusw-fw.elf   am65x-sr2-rtu1-pruhsr-fw.elf
    am64x-sr2-pru1-prueth-fw.elf  am65x-sr2-rtu1-prusw-fw.elf
    am64x-sr2-pru1-pruhsr-fw.elf  am65x-sr2-txpru0-prueth-fw.elf
    am64x-sr2-pru1-pruprp-fw.elf  am65x-sr2-txpru0-pruhsr-fw.elf
    am64x-sr2-pru1-prusw-fw.elf   am65x-sr2-txpru0-prusw-fw.elf
    am64x-sr2-rtu0-prueth-fw.elf  am65x-sr2-txpru1-prueth-fw.elf
    am64x-sr2-rtu0-pruhsr-fw.elf  am65x-sr2-txpru1-pruhsr-fw.elf
    am64x-sr2-rtu0-pruprp-fw.elf  am65x-sr2-txpru1-prusw-fw.elf
    

    I checked the firmware files in the prebuilt image below for SDK 11.1.

    https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX-AM64X/11.01.05.03
    tisdk-default-image-am64xx-evm-11.01.05.03.rootfs.wic.xz

    Best regards,

    Daisuke

  • Hello Daisuke, 

    I ran the HSR offload test on SDK 11.2 between two AM64x EVMs connected to each other and noticed that ping was able to reach when both paths are connected. When disconnecting one path/cable at a time, I did see some packet loss

    I want correct my statement here. I realized that I did not configure eth1 for ICSSG in my test leading to what appeared to be packet loss with cable disconnect. I've corrected this by enabling the ICSSG dtbo as specified in https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU_ICSSG_Ethernet.html#cpsw-pru-ethernet-selection and I do not see ping issues anymore with SDK 11.2. Apologies for the confusion. 

    In regards to the ping connection issue with 10Mbps on SDK 11.2 the customer saw, has the customer verified that eth1 is configured for ICSSG on the AM64x EVM? They can run "ethtool -i eth1" to double check.

    It appears that SDK 11.1 does not include the PRUSS firmware for PRP that is included in SDK 11.2.

    My understanding is that PRP offload should be available for SDK 11.2 but the respective firmwares being missing doesn't align. There might be a chance the firmwares in https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/?h=ti-linux-firmware&id=29d948b63a48ec4ff7883d2e246dfb7b6c8153aa didn't get packaged into the SDK 11.1 by the time SDK 11.1 was released. Let me double check with our team about this. 

    The customer can directly add the PRP firmwares from https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/?h=ti-linux-firmware&id=29d948b63a48ec4ff7883d2e246dfb7b6c8153aa to /usr/lib/firmware/ti-pruss/ and test PRP offload out. 

    -Daolin

  • Hi Daolin-san,

    Thank you for your reply.

    I have created another thread about the gPTP with HSR and PRP.

    e2e.ti.com/.../am6442-gptp-support-using-psdk-linux

    By the way, I tried to test HSR and PRP offload and gPTP on TMDS64EVM, but I have not been able to test them because TMDS64EVM we own was broken due to power issues.

    Best regards,

    Daisuke

  • Hi Daisuke, 

    Apologies for the delayed response. 

    It looks like JC was able to help you in the other thread you created. As JC mentioned, PTP over HSR/PRP is a new feature that is planned to be released next SDK and is not currently available on SDK 11.2.

    While we currently have support for PTP and HSR/PRP separately, supporting both together required some extensive driver, firmware, hsr stack changes. Additionally, the PTP stack/application code that is used should also support HSR/PRP. The example we currently give for Linux SDK uses the linuxptp stack which is open source. TI does not own the PTP stack and we leave that up to the customer to determine if they want to use linuxptp or another PTP stack. It is the responsibility of the customer to determine if the PTP stack they use has support for HSR/PRP.

    Please let me know if there are any further issues regarding the original questions in this thread.

    -Daolin

  • Hi Daolin-san,

    Thank you for your reply.

    Our customer will wait for the release of the next SDK 12.0 and will use it to test HSR/PRP (IEC 62439-3) + PTP (IEEE 1588/IEC 61588).

    Best regards,

    Daisuke