MCU-PLUS-SDK-AM243X: HSR/PRP QoS VLAN PCP to ICSS-EMAC queue number

Any news ?

Hi Andrea,

Apologies for the delay. I will get back on this by friday.

Hi Nilabh,

    I did some tests with PRP firmware and I discovered that:

PORT ONE 

inject packet vlan 0, prio 4 -> rxPktInfo port 1, queue 0
inject packet vlan 0, prio 3 -> rxPktInfo port 1, queue 1

So, for port ONE, the prio values 3 and lower are for NRT traffic (queue 0)
Values higher than prio 4 are for RT traffic (queue 1)

PORT TWO

inject packet vlan 0, prio 7 -> rxPktInfo port 2, queue 3
inject packet vlan 0, prio 4 -> rxPktInfo port 2, queue 3
inject packet vlan 0, prio 3 -> rxPktInfo port 2, queue 3
inject packet vlan 0, prio 1 -> rxPktInfo port 2, queue 3
inject packet vlan 0, prio 0 -> rxPktInfo port 2, queue 3

For port TWO every packet is considered NRT traffic and it is always inserted in queue 3 by PRU FW.

How about queue 2 that should be the RT queue for port TWO ?

Looking forward

  Andrea

Hi Nilabh Anand,

   I read such documentation.

By the way, from my tests I see packets from port 2 always in NRT queue no matter which is the PCP level.

I checked with a breakpoint in ICSS_EMAC_pollPkt.

Packets coming from port 2 are accepted only with VLAN 0 and rxPktInfo.queueNumber is always 3 , so NRT queue.

I tried to add a VLAN filter for VID 1 but packets aren't collcted from port 2 with VID = 1.

vlan_filter_update_vid(prusshandle, 1, ADD_VLAN_VID);

Looking forward

   Andrea

Hi,

The ability to route a packet through the RT queue is crucial for us.

Any suggestion on how we can design a packet to enter such a queue, or how we can instruct the PRU to obtain such a result is greatly appreciated. 

Thank you,

 Marco

Hi Nilabh Anand,

   I would please ask you to double check if there is a work-around we can use to split VLAN traffic from LwIP traffic.

According to our tests, VLAN traffic with vlan-id = 0 is accepted from port 2 and it is sent to queue 3, together with LwIP traffic.

Is there maybe a VLAN filter setting or any FW config settings that can overcome this problem ?

Otherwise the only way we have to test incoming L2 high priority packets from port 2 is to completely remove IP traffic from such port.

Looking forward.

     Andrea

Hi Andrea,

We are currently working on checking the firmware. Once we have the fix, we can give a patch release to you for testing before it comes in next sdk release

Great news ! Thanks

   Andrea

Please allow us time till 16 june to come back on this.

Hi Nilabh Anand,

   we are still waiting for the patch to test.

Looking forward.

   Andrea

Hi Andrea, 

I tried to reproduce it on my side using AM64 EVM from 8.5 release. 

I tried sending VLAN packets to EVM with following configurations and results:

VID: 100
Port 1:
PCP 0: Q1
PCP 7: Q0

Port 2:
PCP 0: Q3
PCP 7: Q2

VID: 001
Port 1:
PCP 0: Q1
PCP 7: Q0

Port 2:
PCP 0: Q3
PCP 7: Q2

I am checking these queue values in rxPktInfo.queueNumber in ICSS_EMAC_pollPkt(icssEmacHandle) function in icss_emac.c.
I am not seeing the issue with Port 2 on my side.

Let me know if this is helpful. I will check it out with AM243 EVM as well in sometime.

Himanshu

Hi Himanshu Mittal,

   I've tested again and the result on my side is the same: VID 100 or VID 1 on port 2 are discarded packets (only VID zero is accepted).

Please check with PRP MII PRU FW on AM243x.

Looking forward

   Andrea

Hi Andrea, 

Can you please share with us the pcap for packets which you are using to test, so that we can test out using the same packets.

Thanks, Himanshu

Hi Himanshu Mittal,

   it isn't possible to "replay" my pcap file, because our MAC addresses are different, so it won't work.

I use python scapy library to inject packets.

I did LwIP interface configuration with static address 192.168.1.10, netmask 255.255.255.0, gateway 192.168.1.1 (my PC)

from scapy.all import *
IFACES.show() # let’s see what interfaces are available. Windows only
iface = IFACES.dev_from_index(7) # 7 is my PC ethernet card
socket = conf.L2socket(iface=iface)
socket.send(Ether()/Dot1Q(vlan=100, prio=0)/IP(dst="192.168.1.10")/Raw(load="data")) # VID = 100 - PCP = 0
socket.send(Ether()/Dot1Q(vlan=1, prio=0)/IP(dst="192.168.1.10")/Raw(load="data")) # VID = 1 - PCP = 0

socket.send(Ether()/Dot1Q(vlan=0, prio=0)/IP(dst="192.168.1.10")/Raw(load="data")) # VID = 0 - PCP = 0, it works

socket.send(Ether()/Dot1Q(vlan=100, prio=0)/IP(dst="192.168.1.10")/Raw(load="data")) # VID = 100 - PCP = 7
socket.send(Ether()/Dot1Q(vlan=1, prio=0)/IP(dst="192.168.1.10")/Raw(load="data")) # VID = 1 - PCP = 7

Looking forward

 Andrea

Hi Andrea, 

Thanks for the info, still could you please share the Wireshark capture from the sender PC. 

Thanks, Himanshu

Hi Himanshu Mittal,

   here is my debug code to check which packets are sent by PRU FW to ICSS-FWHAL.

I log length for every incoming packet into the array packetLengths

FIRST CASE - Injecting VLAN 0 PCP 0 IP packets

Command:

socket.send(Ether(dst="0a:0b:0b:00:00:02", src="78:24:af:08:4d:9e")/Dot1Q(vlan=0, prio=0)/IP(dst="192.168.1.10", src="192.168.1.1")/Raw(load="dataaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"))

Packets are logged and present with 4 bytes different size (check other packets around for confirmation).

You can see also the reply from the board with "host unreachable"

SECOND CASE -  Injecting VLAN 100 PCP 0 IP packets

Command:

socket.send(Ether(dst="0a:0b:0b:00:00:02", src="78:24:af:08:4d:9e")/Dot1Q(vlan=100, prio=0)/IP(dst="192.168.1.10", src="192.168.1.1")/Raw(load="dataaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"))

Packets are missing (check the packet with length 82 bytes as reference)

THIRD CASE -  Injecting VLAN 100 PCP 7 IP packets

Command:

socket.send(Ether(dst="0a:0b:0b:00:00:02", src="78:24:af:08:4d:9e")/Dot1Q(vlan=100, prio=7)/IP(dst="192.168.1.10", src="192.168.1.1")/Raw(load="dataaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"))

Packets are missing (check packets with length 60 bytes as reference)

Looking forward.

    Andrea

Hi Himanshu Mittal,

   any news about your test with my setup ?

Looking forward

  Andrea

Hi Andrea, 

I tested it on my side by making same changes as yours for checking the issue. But I am still receiving the packets in queues as I mentioned earlier. 

Setup: 
AM243EVM, prp_mii_demo_am243x-evm_r5fss0-0_freertos_ti-arm-clang example, mcu_plus_sdk_am243x_08_06_00_45

For packet generation:

from scapy.all import *

# IFACES.show() # let’s see what interfaces are available. Windows only

iface = IFACES.dev_from_index(23) #23 is my PC ethernet card
socket = conf.L2socket(iface=iface)

# DA_MAC = 70:ff:76:1e:ec:36
socket.send(Ether(dst="70:ff:76:1e:ec:36", src="78:24:af:08:4d:9e")/Dot1Q(vlan=0, prio=0)/IP(dst="192.168.1.11", src="192.168.1.100")/Raw(load="deadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeed"))
socket.send(Ether(dst="70:ff:76:1e:ec:36", src="78:24:af:08:4d:9e")/Dot1Q(vlan=0, prio=7)/IP(dst="192.168.1.11", src="192.168.1.100")/Raw(load="deadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeed"))
socket.send(Ether(dst="70:ff:76:1e:ec:36", src="78:24:af:08:4d:9e")/Dot1Q(vlan=100, prio=0)/IP(dst="192.168.1.11", src="192.168.1.100")/Raw(load="deadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeed"))
socket.send(Ether(dst="70:ff:76:1e:ec:36", src="78:24:af:08:4d:9e")/Dot1Q(vlan=100, prio=7)/IP(dst="192.168.1.11", src="192.168.1.100")/Raw(load="deadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeed"))
socket.send(Ether(dst="70:ff:76:1e:ec:36", src="78:24:af:08:4d:9e")/Dot1Q(vlan=1, prio=0)/IP(dst="192.168.1.11", src="192.168.1.100")/Raw(load="deadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeed"))
socket.send(Ether(dst="70:ff:76:1e:ec:36", src="78:24:af:08:4d:9e")/Dot1Q(vlan=1, prio=7)/IP(dst="192.168.1.11", src="192.168.1.100")/Raw(load="deadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeeddeadfeed"))

Also, I do not see that 4 byte packet length difference between Wireshark capture and pLength as you are seeing. 

Thanks, Himanshu

Hi Himanshu Mittal,

  I have retested your example, adapted to our board and unfortunately I am in the same situation as before.

By the way, I use ICSSG0 instead of ICSSG1 so I had to change some IRQ settings in hsr_prp_soc.c as follow:

/* Pass value to R10 of TX_PRU core for MDIO FW WA Configuration */
CSL_REG32_WR(CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_10, MDIO_MANUAL_MODE_FW_CONFIG_VALUE);
/* Pass value to R12 of TX_PRU core for emulated MDIO Base Address */
CSL_REG32_WR(CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_12, MDIO_MANUAL_MODE_BASE_ADDRESS);

Mainly is CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE instead of CSL_PRU_ICSSG1_DRAM0_SLV_RAM_BASE

I have also added a custom MAC address initializing the field lclMac in hsr_prp_main.c

uint8_t lclMac[6] = {0xA, 0xB, 0xB, 0x0, 0x0, 0x2};

I removed the function hsrprp_socgetMACAddress because the MAC address isn't read from EEPROM.

Results are the same as I mentioned before:

- packets with VLAN 0 are accepted but always with NRT priority, no matter which PCP value

- packets with VLAN other than 0 are discarded

Packet length recorded in ICSS_EMAC_pollPkt (icss_emac.c) is 4 bytes shorter than the length logged by Wireshark

Looking forward

   Andrea

Hi Himanshu Mittal,

   we are wondering if it could be possible to send our board to your lab for testing.

Looking forward

   Andrea

Hi Andrea,

Before we take this path, my recommendation would be to try this example out at your end on a TI evm. This will check if it is a software issue or HW issue?

Hi Nilabh,

  I am sure it will work on a TI EVM but I am really wondering how it can work.

Your EVM has RGMII PHYs, so it will run a different PRU FW, compared to our board with MII PHYs.

Second, we use ICSSG0 section instead of ICSSG1 used in your EVM: this force me to change the PRU IRQs configuration in the example.

Could be that I am missing some other configuration change to use ICSSG0 section in the proper way ?

This is why we consider important to check on a board with MII and ICSSG0 (not on the EVM with RGMII and ICSSG1).

Looking forward

  Andrea

Andrea Tessadri said:

Your EVM has RGMII PHYs, so it will run a different PRU FW, compared to our board with MII PHYs.

I believe this is not correct Andrea, as we are testing with prp mii mode.The phy on our board i.e dp 83869 supports MII too along with RGMII.

Andrea Tessadri said:

Second, we use ICSSG0 section instead of ICSSG1 used in your EVM: this force me to change the PRU IRQs configuration in the example.

This may be something we could check, Could you recheck configuration on your end?

Andrea Tessadri said:

This is why we consider important to check on a board with MII and ICSSG0 (not on the EVM with RGMII and ICSSG1).

We should focus on checking the differences between sdk icssg1 vs your icssg1 configuration.

Hi Nilabh,

   what I have changed in your example is already mentioned up in our discussion:

I use ICSSG0 instead of ICSSG1 so I had to change some IRQ settings in hsr_prp_soc.c as follow:

/* Pass value to R10 of TX_PRU core for MDIO FW WA Configuration */
CSL_REG32_WR(CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_10, MDIO_MANUAL_MODE_FW_CONFIG_VALUE);
/* Pass value to R12 of TX_PRU core for emulated MDIO Base Address */
CSL_REG32_WR(CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_12, MDIO_MANUAL_MODE_BASE_ADDRESS);

Mainly is CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE instead of CSL_PRU_ICSSG1_DRAM0_SLV_RAM_BASE

I have also added a custom MAC address initializing the field lclMac in hsr_prp_main.c

uint8_t lclMac[6] = {0xA, 0xB, 0xB, 0x0, 0x0, 0x2};

I removed the function hsrprp_socgetMACAddress because the MAC address isn't read from EEPROM.

Is there any other configuration change you can recommand to use ICSSG0 instead of ICSSG1 ?

Looking forward

  Andrea

Hi Andrea,

Thanks for reiterating the same. Let us check this internally and get back. 

Andrea Tessadri said:

* Pass value to R10 of TX_PRU core for MDIO FW WA Configuration */
CSL_REG32_WR(CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_10, MDIO_MANUAL_MODE_FW_CONFIG_VALUE);
/* Pass value to R12 of TX_PRU core for emulated MDIO Base Address */
CSL_REG32_WR(CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE + CSL_ICSS_G_PR1_PDSP_TX0_IRAM_DEBUG_REGS_BASE + PRU_REG_12, MDIO_MANUAL_MODE_BASE_ADDRESS);

Mainly is CSL_PRU_ICSSG0_DRAM0_SLV_RAM_BASE instead of CSL_PRU_ICSSG1_DRAM0_SLV_RAM_BASE

Hi Himanshu, DO you see any issue with these changes?

Please Nilabh and Himanshu, check if I need more changes to configure PRU FW to work on ICSSG0.

Since I am able to collect packets, I suppose IRQ settings are OK, but what I suspect is that there are some other changes that I don't know and that are missing ... maybe about VLAN

Looking forward

  Andrea

Hi Nilabh,

   in order to speed up the solution of this problem or misconfiguration, do you think it would be possible to have the PRU source code for debugging on our side ?

Looking forward

   Andrea

Hi, 
The changes made seem fine to me.
It should be possible to provide source code for debugging, let me discuss and get back on this. 

Thanks Himanshu, great news.

Hi Andrea,
I will setup a shared folder to provide sources. 

Excellent Himanshu.

Hi Andrea,

We are planning to have a debug call with our SW team and you. Since we are not able to reproduce the issue on our end. 
Mean while could you please share the icssg memory dump.

For taking the memory dump you need to use memory browser in ccs. We need ICSSG0 memory dump as you are using ICSSG0.

Start address is 0x030000000 and end address 0x030080000

Click save and you should see the dump saved at the location mentioned in pop up": /resized-image/__size/320x240/__key/communityserver-discussions-components-files/908/pastedimage1691566719487v3.png

I have also shared a private message for the meeting related query.