TMDS64EVM: ICSSG switch mode initialization issues

Hi Mateusz,

I tested the scenario below and was unable to reproduce it with Generic Ethernet:

Mateusz Szalkowski said:

configure switch mode and connect eth afterwards - all SMV dropped, PTP and ICMP forwarded properly

Host PC: 

$ ./pack_gen 01:80:8b:77:ce:bf 128 1000 0

1000 packets were sent at 128 bytes each. Are you seeing the following message in the logs once the link is up?

root@am64xx-evm:~# [ 102.823723] icssg-prueth icssg1-eth eth1: Link is Up - 1Gbps/Full - flow control off
[ 102.831985] br0: port 1(eth1) entered blocking state
[ 102.837063] br0: port 1(eth1) entered forwarding state
[ 102.887913] icssg-prueth icssg1-eth eth2: Link is Up - 1Gbps/Full - flow control off
[ 102.895838] br0: port 2(eth2) entered blocking state
[ 102.900904] br0: port 2(eth2) entered forwarding state

BR
JC

Hi JC,

Yes, I can confirm I can see these logs. Attached a few more of dmesg logs in case something interesting is there:

[  151.637636] audit: type=1006 audit(1748545982.709:2): pid=853 uid=0 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=1 res=1
[  151.637669] audit: type=1300 audit(1748545982.709:2): arch=c00000b7 syscall=64 success=yes exit=1 a0=8 a1=ffffe80560d8 a2=1 a3=1 items=0 ppid=1 pid=853 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="(systemd)" exe="/usr/lib/systemd/systemd-executor" key=(null)
[  151.637684] audit: type=1327 audit(1748545982.709:2): proctitle="(systemd)"
[  158.231415] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[  158.261946] br0: port 1(eth1) entered blocking state
[  158.262034] br0: port 1(eth1) entered disabled state
[  158.262101] icssg-prueth icssg1-eth eth1: entered allmulticast mode
[  158.264858] icssg-prueth icssg1-eth eth1: entered promiscuous mode
[  158.265846] audit: type=1700 audit(1748545989.334:3): dev=eth1 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
[  158.270596] audit: type=1300 audit(1748545989.334:3): arch=c00000b7 syscall=211 success=yes exit=40 a0=3 a1=ffffc90627c8 a2=0 a3=1 items=0 ppid=860 pid=871 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS2 ses=4294967295 comm="ip" exe="/usr/sbin/ip.iproute2" key=(null)
[  158.270637] audit: type=1327 audit(1748545989.334:3): proctitle=6970006C696E6B00736574006465760065746831006D617374657200627230
[  158.362098] br0: port 2(eth2) entered blocking state
[  158.362198] br0: port 2(eth2) entered disabled state
[  158.362256] icssg-prueth icssg1-eth eth2: entered allmulticast mode
[  158.364795] remoteproc remoteproc7: stopped remote processor 3008a000.txpru
[  158.364823] remoteproc remoteproc16: stopped remote processor 30084000.rtu
[  158.364832] remoteproc remoteproc13: stopped remote processor 300b4000.pru
[  158.364842] remoteproc remoteproc8: stopped remote processor 3008c000.txpru
[  158.364851] remoteproc remoteproc15: stopped remote processor 30086000.rtu
[  158.364860] remoteproc remoteproc14: stopped remote processor 300b8000.pru
[  158.368691] remoteproc remoteproc13: powering up 300b4000.pru
[  158.374260] remoteproc remoteproc13: Booting fw image ti-pruss/am64x-sr2-pru0-prusw-fw.elf, size 45708
[  158.374308] remoteproc remoteproc13: unsupported resource 5
[  158.374341] remoteproc remoteproc13: remote processor 300b4000.pru is now up
[  158.374389] remoteproc remoteproc16: powering up 30084000.rtu
[  158.378718] remoteproc remoteproc16: Booting fw image ti-pruss/am64x-sr2-rtu0-prusw-fw.elf, size 34188
[  158.378780] remoteproc remoteproc16: remote processor 30084000.rtu is now up
[  158.378827] remoteproc remoteproc7: powering up 3008a000.txpru
[  158.381384] remoteproc remoteproc7: Booting fw image ti-pruss/am64x-sr2-txpru0-prusw-fw.elf, size 39340
[  158.381451] remoteproc remoteproc7: remote processor 3008a000.txpru is now up
[  158.381496] remoteproc remoteproc14: powering up 300b8000.pru
[  158.384651] remoteproc remoteproc14: Booting fw image ti-pruss/am64x-sr2-pru1-prusw-fw.elf, size 45868
[  158.384694] remoteproc remoteproc14: unsupported resource 5
[  158.384727] remoteproc remoteproc14: remote processor 300b8000.pru is now up
[  158.384773] remoteproc remoteproc15: powering up 30086000.rtu
[  158.387637] remoteproc remoteproc15: Booting fw image ti-pruss/am64x-sr2-rtu1-prusw-fw.elf, size 33424
[  158.387693] remoteproc remoteproc15: remote processor 30086000.rtu is now up
[  158.387740] remoteproc remoteproc8: powering up 3008c000.txpru
[  158.390687] remoteproc remoteproc8: Booting fw image ti-pruss/am64x-sr2-txpru1-prusw-fw.elf, size 37828
[  158.390749] remoteproc remoteproc8: remote processor 3008c000.txpru is now up
[  158.394064] icssg-prueth icssg1-eth eth2: entered promiscuous mode
[  158.394660] audit: type=1700 audit(1748545989.434:4): dev=eth2 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
[  158.397225] audit: type=1300 audit(1748545989.434:4): arch=c00000b7 syscall=211 success=yes exit=40 a0=3 a1=ffffe2dda038 a2=0 a3=1 items=0 ppid=860 pid=877 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=ttyS2 ses=4294967295 comm="ip" exe="/usr/sbin/ip.iproute2" key=(null)
[  158.397347] audit: type=1327 audit(1748545989.434:4): proctitle=6970006C696E6B00736574006465760065746832006D617374657200627230
[  165.028985] icssg-prueth icssg1-eth eth1: Link is Up - 100Mbps/Full - flow control off
[  165.029212] br0: port 1(eth1) entered blocking state
[  165.029239] br0: port 1(eth1) entered forwarding state
[  169.188912] icssg-prueth icssg1-eth eth2: Link is Up - 100Mbps/Full - flow control off
[  169.189144] br0: port 2(eth2) entered blocking state
[  169.189197] br0: port 2(eth2) entered forwarding state

Hi Mateusz,

Can you confirm if this packet structure is fine?

Mateusz Szalkowski said:

• configure switch mode and connect eth afterwards - all SMV dropped, PTP and ICMP forwarded properly

I tried this with above scenario, still the packets are forwarded for me.

BR
JC

Hi JC,

Jayachandran Rameshbabu said:

Can you confirm if this packet structure is fine?

At least destination MAC and packet type look ok.

One thing I now see compared to traffic that I have is VLAN tagging that is present in our testing SMV packages. Could it be that the issue is not multicast type, but actually VLAN tagging? Example:


Also, could you please confirm if this scenario is reproducible, with switch mode enabled and cables connected:

Mateusz Szalkowski said:

first disable both physical interfaces and then bring them back up (which causes ICSSG firmware to reload), I can see that whole traffic including SMV is being forwarded but only from port that was brought up later to the one that was brought up first

Best regards,
Mateusz

Hi Mateusz, 

Mateusz Szalkowski said:

Also worth noticing, I now see that in switch mode PRP supervision packets with MAC 01:15:4E:00:01:00 are forwarded from one port to another while these with SMV multicast MAC (e.g. 01:0C:CD:04:00:03) are not.

Thanks for the details I will try today.

BR
JC

Hi JC,

Waiting for the update.

In the meantime I have one more question, how is it with forwarding PTP packets? I would like to configure the device to work as a switch with PTP Boundary Clock functionality - one port acting as PTP master, another one as PTP slave, not forwarding PTP packets between ports so so quite different compared to the example in switch mode documentation. I'm going through settings in the documentation but can't figure out how to prevent forwarding PTP packets.

Best regards,
Mateusz

Jayachandran Rameshbabu said:

I also attempted to configure VLAN ID 0 using the same command, however, it still does not work. I am currently looking into this internally and the investigation is still ongoing.

Just a note that on CPSW hardware VLAN ID 0 is always reserved and used for priority tagging purposes. I'm unsure if it is the same for ICSSG so worth JC to look into

-Daolin

Hello,

Jayachandran Rameshbabu said:

This behavior is consistent when I run above command - meaning VLAN ID 1 is received and forwarded to other ports as untagged traffic, as defined by the above command.

That's quite a clarification, thanks. Indeed I managed to control forwarding once the traffic used other VLAN ID. So from my understanding every VLAN ID that could be used for SMV traffic from other devices (excluding VLAN ID 0 at this moment) in the network has to be set explicitly configured for on the device in order to forward it without stripping the VLAN tag, is that correct?

Also could you clarify my doubts regarding PTP traffic?

Mateusz Szalkowski said:

I would like to configure the device to work as a switch with PTP Boundary Clock functionality - one port acting as PTP master, another one as PTP slave, not forwarding PTP packets between ports so so quite different compared to the example in switch mode documentation. I'm going through settings in the documentation but can't figure out how to prevent forwarding PTP packets.

Best regards,
Mateusz

Hi Mateusz,

Mateusz Szalkowski said:

I would like to configure the device to work as a switch with PTP Boundary Clock functionality - one port acting as PTP master, another one as PTP slave, not forwarding PTP packets between ports so so quite different compared to the example in switch mode documentation. I'm going through settings in the documentation but can't figure out how to prevent forwarding PTP packets.

Have you tried skipping the configuration steps to enable switch mode? My understanding and from past tests I've ran is that if you run ptp4l on each of the three devices connected in a line, the middle device doesn't necessarily have be enabled in switch mode for PTP boundary clock to work, assuming you have configured the ptp4l config file correctly.

Mateusz Szalkowski said:

So from my understanding every VLAN ID that could be used for SMV traffic from other devices (excluding VLAN ID 0 at this moment) in the network has to be set explicitly configured for on the device in order to forward it without stripping the VLAN tag, is that correct?

If CPSW ethernet is used, yes I believe your understanding is correct. If ICSSG ethernet, JC can most likely validate it performs the same.

-Daolin

Mateusz Szalkowski said:

So from my understanding every VLAN ID that could be used for SMV traffic from other devices (excluding VLAN ID 0 at this moment) in the network has to be set explicitly configured for on the device in order to forward it without stripping the VLAN tag, is that correct?

True.

BR
JC

Hello,

Daolin Qiu said:

Have you tried skipping the configuration steps to enable switch mode? My understanding and from past tests I've ran is that if you run ptp4l on each of the three devices connected in a line, the middle device doesn't necessarily have be enabled in switch mode for PTP boundary clock to work, assuming you have configured the ptp4l config file correctly.

Unfortunately, enabling switch mode is the main functionality that the device would need and ptp4l boundary clock mode is a result of that requirement.

Best regards,
Mateusz

Hi Mateusz,

Run this command in the bridge/BC, then things should work. I verified at my end.

bridge mdb add dev br0 port br0 grp 01:80:c2:00:00:0e  permanent vid 1

BR
JC

> > 01:80:c2:00:00:0e 

Above LLDP multicast MAC address is P2P reserved MAC - this be causing a rogue delay response, Which packets are getting forwarded in your case?

You can also run the same command for the SYNC message MAC address from the Grandmaster (GM).

If you have any further questions, please raise a separate E2E query and attach the relevant BC.cfg and OC.cfg configuration files.

BR
JC

Hello JC,

Jayachandran Rameshbabu said:

Which packets are getting forwarded in your case?

In my case it's Pdelay_Req, Pdelay_Resp and Pdelay_Resp follow up messages (ptp4l running in P2P mode). I now tried both:

bridge mdb add dev br0 port br0 grp 01:80:c2:00:00:0e permanent vid 1
bridge mdb add dev br0 port br0 grp 01:1b:19:00:00:00 permanent vid 1

bridge mdb list

Hi Mateusz, 

Mateusz Szalkowski said:

Should further discussion now be moved to a new thread?

Yes, please

Probably you can verify and close this one

BR
JC

Also please attach the PTP OC and BC config files you are using.

BR
JC

Maybe one more question before closing:

Jayachandran Rameshbabu said:

I also attempted to configure VLAN ID 0 using the same command, however, it still does not work. I am currently looking into this internally and the investigation is still ongoing.

Could I somehow track or be notified with progress of the investigation?

Best regards,
Mateusz

Mateusz Szalkowski said:

I also attempted to configure VLAN ID 0 using the same command, however, it still does not work. I am currently looking into this internally and the investigation is still ongoing.

Okay, you can then leave this thread open until this is addressed

BR
JC