AM6442: Offloaded PRP trailers configuration

Mateusz Szalkowski

Part Number: AM6442

Hello,

Our team is implementing offloaded PRP functionality using PRU firmware. There was one issue that we encountered recently. When configuring PRP either using a provided script or using below command directly:

ip link add name $if type hsr slave1 "$ifa" slave2 "$ifb" supervision 45 proto 1

there is a significant difference between offload and non-offload mode. Non-offload mode uses slave1 and slave2 parameters to assign "LAN A" and "LAN B" labels in PRP trailer to "ifa" and "ifb" interfaces respectively. For offloaded mode this is not the case, "LAN A" and "LAN B" labels are assigned based on MII0 and MII1 mapping (earlier confirmed by TI support).

Suggested workaround was to swap RX path and TX path mapping for MII0 and MII1 mapping using RX_MUX_SEL0/1 and TX_MUX_SEL0/1 bits in ICSSG MII_RT_RXCFG0/1 and MII_RT_TXCFG0/1 registers. This initially seemed to work, but after further tests it turned out it interferes at least with PTP operation. Assuming that before registers swap eth3 is MII0 and eth2 is MII1, below can be noticed after swapping:

using tcpdump - packets that are sent from PTP master connected to eth2 are captured on eth3,
ptp4l - master clock is not seen on eth2 until there is any device (also non-PTP) connected to eth3,
once something is connected to both ports, "port 1 (eth3): new foreign master..." logs from ptp4l can be seen but with wrong port (master is connected to eth2),
ptp4l synchronization works before swap, but after swapping timing values are incorrect (~100000 ns instead of ~900 ns for path delay, ~10000 ns insted of ~100 ns for master offset).

Taking these issue into consideration, my question is:
Is there any alternative way to remap "LAN A" and "LAN B" naming that also allows to avoid above issues?

Best regards,
Mateusz

13 days ago

0 Jayachandran Rameshbabu 10 days ago

TI__Expert 8774 points

Hi Mateusz,

Curious, Did you try swapping the software eth interfaces (eth2, eth3) to the PRU slices inside the Linux Device Tree and try reverting the TX/RC MUX CFG?

BR
JC

0 Mateusz Szalkowski 9 days ago in reply to Jayachandran Rameshbabu

Prodigy 220 points

Hi JC,

Thanks for the response.
Depends on what you mean by swapping PRU slices. For now I tried replacing:

icssg0_eth: icssg0-eth {
//...
    ti,prus = <&pru0_0>, <&rtu0_0>, <&tx_pru0_0>, <&pru0_1>, <&rtu0_1>, <&tx_pru0_1>;
//...
}

with

icssg0_eth: icssg0-eth {
//...
    ti,prus = <&pru0_1>, <&rtu0_1>, <&tx_pru0_1>, <&pru0_0>, <&rtu0_0>, <&tx_pru0_0>;
//...
}

but that ended up in either PRU firmware or ICSSG driver crashing. Next try was to also make a swap in firmware-names, so after the change it was:

icssg0_eth: icssg0-eth {
//...
    firmware-name = "ti-pruss/am64x-sr2-pru1-prueth-fw.elf",
                    "ti-pruss/am64x-sr2-rtu1-prueth-fw.elf",
                    "ti-pruss/am64x-sr2-txpru1-prueth-fw.elf",
                    "ti-pruss/am64x-sr2-pru0-prueth-fw.elf",
                    "ti-pruss/am64x-sr2-rtu0-prueth-fw.elf",
                    "ti-pruss/am64x-sr2-txpru0-prueth-fw.elf";
//...
}

That made PRU work again, but still the trailers were assign to the same ports as before, no change.

Please provide some additional info if you meant any particular change in the device tree other than shown above.

Best regards,
Mateusz

0 Jayachandran Rameshbabu 5 days ago in reply to Mateusz Szalkowski

TI__Expert 8774 points

Hi Mateusz,

I see below in specification

"The connectors for each LAN shall be labelled distinctly and permanently as A and B. When connectors are ordered vertically, the port to LAN_A should be the upper connector and the port to LAN_B the lower connector... When connectors are ordered horizontally, the port to LAN_A should be the left connector and the port to LAN_B the right connector."

PRU firmware follows a MII0 = LAN A, MII1 = LAN B across all devices permanently following above clause from specification.

We cannot upstream a dynamic LAN mapping change or swap - it would break our reference design, validation baseline and out of the box experience for users.

Quick Options:

Custom firmware binary fork (Exclusive for you): Swap the PRP trailer LanId only (MII0→0xB, MII1→0xA), temporarily enables you.
Chassis label swap (at your end): Spec-compliant, zero software cost.

Can you share your device tree .dtbo?

BR
JC

0 Mateusz Szalkowski 4 days ago in reply to Jayachandran Rameshbabu

Prodigy 220 points

Hi JC,

Unfortunately chassis label swap is not possible as product is already in production and available to purchase and labeling is done according to the same specification. If possible, firmware binary fork sounds to be enough in this case.

Regarding device tree - is there any specific part that would be useful? I'd like to avoid sharing the whole file on public forum, I'd prefer either share an interesting part of it here or share the whole file separately e.g. via e-mail.

Best regards,
Mateusz

0 Jayachandran Rameshbabu 4 days ago in reply to Mateusz Szalkowski

TI__Expert 8774 points

Hi Mateusz,

Email works for us.

BR
JC

Processors

Processors forum

AM6442: Offloaded PRP trailers configuration