AM5708: Unable to Disable prp-rx-offload on SDK 08.02.01.00 – PRP Not Functioning on PRU-ICSS

Hello Mahesh,

Yes, The support for the offload functionality was broken in SDK 8.2. Unfortunately this SDK is outside of our scope of support now and for the time being HSR\PRP functionality was dropped completely in the latest SDK (9.x). We are working on bringing this back in this years 11.2 SDK release.

I believe another customer might of had a successful fix in the following thread:

PROCESSOR-SDK-AM57X: ti-pruss/am57xx-pru0/1-prusw-fw.elf firmware not loaded into PRUs when creating the bridge between redundant ports

Best, 

Josue

Hi Josue,

Thank you for your reply.

We were quite surprised to learn that PRP functionality was broken in SDK 08.02.01.00 and dropped entirely in SDK 9.x, especially since the release notes for SDK 08.02.01.00 explicitly mention fixes related to HSR and PRP multicast and VLAN filtering issues:

https://software-dl.ti.com/processor-sdk-linux/esd/AM57X/08_02_01_00/exports/docs/devices/AM57X/linux/Release_Specific_Release_Notes.html#release-08-02-01

"Fixed HSR/PRP multicast and VLAN filtering issues in firmware and Linux driver."

This was one of the primary reasons we migrated from SDK 05.03.00.07 to 08.02.01.00, as our system relies on proper multicast and VLAN handling under PRP.

Given this context, could you please clarify the following:

1. Was PRP partially functional in 08.02.01.00, or was its breakage discovered post-release?

2. Is there any known patch, workaround, or firmware source available that would allow us to rebuild or re-enable PRP in SDK 08.02.01.00?

3. Despite the ethtool -K eth2 prp-rx-offload off command failing, we still observe PRP trailers present in Ethernet frames. Does this indicate that PRP is partially active at the firmware or driver level?

We would appreciate any technical guidance or references that can help restore PRP operation in this SDK version 

Best regards,
Mahesh R

Hello Mahesh,

Yes PRP was working and some bugs were discovered post release. Unfortunately these were not reported until after the support window was closed and 9.02 was released. 

The new upcoming SDK 11.2 will restore HSR PRP functionality.

I will see if I can recreate the behavior mentioned above. I am new to testing HSR/PRP so this might take me a little while to get my setup up and running.

I appreciate your patience.

-Josue

Hi Josue,

Thanks for the update.

We tried the same procedure, but unfortunately we see a kernel crash after enabling hsr-fwd-offload and hsr-tag-rm-offload.

Log:
----

root@am57xx-evm:~# ifconfig eth1 down
root@am57xx-evm:~# ifconfig eth2 down
root@am57xx-evm:~# ethtool -K eth1 hsr-fwd-offload on
root@am57xx-evm:~# ethtool -K eth2 hsr-fwd-offload on
root@am57xx-evm:~# ethtool -K eth1 hsr-tag-rm-offload on
root@am57xx-evm:~# ethtool -K eth2 hsr-tag-rm-offload on
root@am57xx-evm:~# ifconfig eth1 hw ether 70:B3:D5:FA:6C:6E
root@am57xx-evm:~# ifconfig eth2 hw ether 70:B3:D5:FA:6C:6E
root@am57xx-evm:~# ip link add name prp0 type hsr slave1 eth1 slave2 eth2 supervision 45 proto 1

root@am57xx-evm:~#
root@am57xx-evm:~# ifconfig eth1 up
[ 1502.910504] pps pps0: new PPS source ptp1
[ 1502.914755] icss-iep 4b2ae000.iep: iep ptp bc clkid 0
[ 1502.920761] remoteproc remoteproc2: powering up 4b2b4000.pru
[ 1502.932932] remoteproc remoteproc2: Booting fw image ti-pruss/am57xx-pru0-pruprp-fw.elf, size 7968
[ 1502.942755] remoteproc remoteproc2: unsupported resource 5
[ 1502.948425] remoteproc remoteproc2: remote processor 4b2b4000.pru is now up
[ 1502.955836] remoteproc remoteproc3: powering up 4b2b8000.pru
[ 1502.962650] remoteproc remoteproc3: Booting fw image ti-pruss/am57xx-pru1-pruprp-fw.elf, size 7848
[ 1502.972024] remoteproc remoteproc3: unsupported resource 5
[ 1502.977739] remoteproc remoteproc3: remote processor 4b2b8000.pru is now up
[ 1502.986250] net eth1: started
root@am57xx-evm:~# [ 1502.991687] prueth pruss2_eth eth1: Link is Up - 100Mbps/Full - flow control off
[ 1503.001165] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 1503.013093] 8<--- cut here ---
[ 1503.016235] Unable to handle kernel NULL pointer dereference at virtual address 0000001f
[ 1503.024375] pgd = 2c8d0cda
[ 1503.027111] [0000001f] *pgd=80000080004003, *pmd=00000000
[ 1503.032552] Internal error: Oops: 207 [#1] PREEMPT SMP ARM
[ 1503.038059] Modules linked in: xt_tcpudp xt_mac arptable_filter arp_tables iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_tables xt_u32 x_tables RflPTP prueth rpmsg_kdrv_switch virtio_rpmsg_bus rpmsg_pru rpmsg_char rpmsg_proto pru_rproc pruss hsr icss_iep irq_pruss_intc RflDsp tps_uart RflNvram RflDelay RflGpio RflLb RflControlBus RflAcid
[ 1503.072085] CPU: 0 PID: 4649 Comm: irq/208-eth_lp_ Not tainted 5.10.100-g7a7a3af903 #16
[ 1503.080121] Hardware name: Generic DRA72X (Flattened Device Tree)
[ 1503.086257] PC is at prueth_lre_emac_rx_packets+0xd0/0x3c0 [prueth]
[ 1503.092549] LR is at 0x1f
[ 1503.095179] pc : [<bf095280>] lr : [<0000001f>] psr: 600e0013
[ 1503.101471] sp : c2c15ea0 ip : c244b8b0 fp : c1204cc8
[ 1503.106717] r10: c1204cc8 r9 : c244bd80 r8 : c244b580
[ 1503.111962] r7 : f1100000 r6 : c2476640 r5 : f11a0000 r4 : c244b800
[ 1503.118516] r3 : 00000000 r2 : 0000001f r1 : bf097e58 r0 : 4d4f67b1
[ 1503.125072] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 1503.132236] Control: 30c5387d Table: 82759540 DAC: fffffffd
[ 1503.138006] Process irq/208-eth_lp_ (pid: 4649, stack limit = 0x1a081454)
[ 1503.144822] Stack: (0xc2c15ea0 to 0xc2c16000)
[ 1503.149200] 5ea0: efc3b7c0 f1191e84 00000018 7fffffff c244b0b0 c244b8b0 bf097e58 bf097e68
[ 1503.157414] 5ec0: c0202914 f1191e8b 0000001f f1191e86 0000001a c1204cc8 c2483400 c0f00b40
[ 1503.165626] 5ee0: c2c15f34 c0b4023c c2c15f28 c0252954 c0202914 60070013 00000004 c0b40690
[ 1503.173838] 5f00: c1204cc8 4d4f67b1 00000004 4d4f67b1 c241bf6c c26ff180 c241bf00 00000001
[ 1503.182051] 5f20: 00000000 c241bf00 c26ff180 c02861d0 c1204cc8 c02861ec ffffe000 c26ff1a4
[ 1503.190262] 5f40: 00000001 c0286510 c12b31ef c0e55ec4 00000000 00000000 c02862f8 4d4f67b1
[ 1503.198475] 5f60: c2c15f74 c26ff100 c2c14000 c26ff1c0 00000000 c02863d0 c26ff180 c27c7c6c
[ 1503.206686] 5f80: c26ff124 c0249790 00000000 c26ff1c0 c0249608 00000000 00000000 00000000
[ 1503.214898] 5fa0: 00000000 00000000 00000000 c0200138 00000000 00000000 00000000 00000000
[ 1503.223111] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1503.231323] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 1503.239563] [<bf095280>] (prueth_lre_emac_rx_packets [prueth]) from [<c02861ec>] (irq_thread_fn+0x1c/0x78)
[ 1503.249264] [<c02861ec>] (irq_thread_fn) from [<c0286510>] (irq_thread+0x140/0x21c)
[ 1503.256961] [<c0286510>] (irq_thread) from [<c0249790>] (kthread+0x188/0x18c)
[ 1503.264133] [<c0249790>] (kthread) from [<c0200138>] (ret_from_fork+0x14/0x3c)
[ 1503.271384] Exception stack(0xc2c15fb0 to 0xc2c15ff8)
[ 1503.276457] 5fa0: 00000000 00000000 00000000 00000000
[ 1503.284670] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1503.292881] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 1503.299527] Code: e5d33000 e6ef3073 f57ff04f e59d2028 (e5d24000)
[ 1503.305767] ---[ end trace 5f06377fcd0f0f23 ]---
[ 1503.310422] genirq: exiting task "irq/208-eth_lp_" (4649) is an active IRQ thread (irq 208)

Thanks,

Mahesh R

Strange. I will try it again locally.

Will report my findings. Are you using a custom board or a TI evm?

Default linux image?

-Josue

Posted by Mahesh:

Hi Josue,

Thanks for checking and for calling out step 2.

Just to clarify, we did configure both slave ports with the same MAC address before creating the HSR/PRP device:

In our setup the slave interfaces don’t have IP addresses assigned, so using ifconfig ethX 0.0.0.0 down is effectively the same as ifconfig ethX down. That said, we can follow your exact sequence if it’s required by the driver.

Despite matching MACs on both ports, we still hit the kernel crash after enabling:

Is there any additional ordering constraint  Also, could the remoteproc ... unsupported resource 5 messages be related?

Thanks,

Mahesh R

Hello Mahesh,

I do not see this on my side as you can see from my log:  RE: AM5708: Unable to Disable prp-rx-offload on SDK 08.02.01.00 – PRP Not Functioning on PRU-ICSS 

I also see the remoteproc messages and I don't think it is related.

Are you doing this on a custom board?

-Josue

Hi Josue,

Yes we are having custom board.

Thanks,

Mahesh R

Mahesh,

Do you have a TI IDK to try this on?

This issue does not occur on AM5718x IDK.

-Josue