AM6548: SR 2.0 PRU-ICSSG multicast address filter - operation and example/reference code

Ian,

We have the 8.6 release of the Linux SDK with major updates to ICSSG based Ethernet coming in the next couple weeks, currently tracking March 31st. The ICSSG based Ethernet in a sister device 8.6 release (https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU_ICSSG_Ethernet.html ) is a good reference for what will be there. Leveraging HW multicast filtering is not part of that feature set.

For custom drivers using the peripheral you could also look at the freeRTOS drivers of the same sister device https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/ICSS_EMAC.html .

  Pekka

Hello Pekka,

Thanks for your message and the pointers.  Can you comment on why support for this feature is not present or planned in the Linux driver?  Is this a technical limitation, for example, in which case it might be relevant to our driver also?

Ian

For Linux it is just a driver software effort question, not a hardware restriction. As you can see from AM64x documentation the RTOS driver does use multicast filtering. For your custom driver I suggest to look at both.

  Pekka

Pekka,

May I check that I'm looking at the right code, please?  I believe you're referring to ICSS_EMAC_multicastFilterConfig in mcu_plus_sdk_am64x_08_02_00_31/sources/networking/icss_emac/source/icss_emac_local.c - is that correct?  I ask because firstly the name suggests it refers to ICSS rather than ICSSG, and secondly it seems to be using a multicast table in DRAM which suggests it is implemented by the EMAC firmware.  Does the AM65x EMAC firmware implement multicast address filtering in the same way?  I was expecting to see driver code which used the FDB implemented in the ICSSG MII G RT.  Please put me straight either way.

Thanks,

Ian

Sorry, you are correct, I pointed to the 100M capable RTOS implementation using the ICSS_EMAC drivers for RTOS example of using multicast filtering. Not the gigabit capable Enet LLD.

Enet LLD I don't directly see anything utilizing the HW filter in ICSSG, but as you point out the address lookup (FDB and tables), might be able to achieve the same. https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM65X/08_02_00_01/exports/docs/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU_ICSSG_Ethernet.html?highlight=multicast#multicast-add-delete is the Linux documentation.

  Pekka

Thanks Pekka.  The link you pointed me to describes the user-space command to add multicast addresses to an interface.  However, just to be clear, as I understand it the Linux driver for PRU-ICSSG EMAC (delivered with the 08.02.xx.xx SDK) does not implement this using the hardware multicast address filter but instead simply enables receipt of all multicast-addressed frames if the list of multicast addresses bound to the interface is not empty.  That being the case I am back to square one with respect to code to use as a reference/documentation to add "proper" multicast address filtering to our driver.

The architecture is ingress port (where there is a HW accelerator for filtering packets), forwarding database (FDB) lookup, use the lookup decide where the packets should go. Ingress multicast filter configuration is not currently supported in ICSSG software drivers. Adding and deleting multicast addresses, used by the FDB lookup is supported. Closest I can think of is using switch in managed mode and removing multicast addresses you want to filter out.

  Pekka

Pekka,

I have found what appears to be support for multicast filtering using the AM65x SR2.0 FDB in the AM65x RTOS SDK (08.00.00.36), in particular the ioctl command EMAC_IOCTL_FDB_ENTRY_CTRL implemented in packages/ti/drv/emac/src/v5/emac_ioctl.c.

Please would you confirm whether or not this is the correct source code to use as a reference for multicast address filtering on the AM65x SR 2.0 PRU-ICSSG EMAC.

Thanks,

Ian

There is a newer version: 08.02.00.05 available at https://www.ti.com/tool/PROCESSOR-SDK-AM65X#downloads with ICSSG Enet LLD at \ti\pdk_am65xx_08_02_00_21\packages\ti\drv\enet.

https://software-dl.ti.com/processor-sdk-rtos/esd/AM65X/08_02_00_05/exports/docs/pdk_am65xx_08_02_00_21/docs/userguide/am65xx/modules/enet.html has a little bit of an overview.

  Pekka

Looking at the function emac_ioctl_send_mgmt_msg in packages/ti/drv/emac/src/v5/emac_ioctl.c I see it uses MII G RT hardware queues to obtain a free command packet and to issue a filled-in command packet.  (The hardware queue IDs are 56/60 for the free queue and 57/61 for the transmit queue, for slices 0 and 1 respectively.)

Please would you explain exactly what kind of value is to be pushed to/popped from those queues?  The driver seems to use pointers (virtual addresses) truncated to 32-bit values to match the width of the queue registers.  Therefore I infer that the driver assumes a one-to-one correspondence between virtual and physical addresses, and the values in the queue are absolute 32-bit physical addresses (e.g. 0x0b[012]xxxxx for ICSSG #[012]).  Is that correct?

Please would you specify where the buffers for these command packets are located and how that correlates with the values exchanged via the hardware queues.

Also, please would you explain how the values in the free queue are initialised to give a list of available command packet buffers.  I can't see any code in the RTOS SDK EMAC driver to fill the free queue; is this done by the EMAC firmware?  If not, please would you point me to example code which allocates these buffers and populates the free queue.

Thanks,

Ian

To answer my own question: the queues seem to contain offsets from shared RAM.

Ian Willats said:

driver assumes a one-to-one correspondence between virtual and physical addresses, and the values in the queue are absolute 32-bit physical addresses

Generally the RTOS drivers are written for the R5 so 32-bit and the MPU/RAT setting from R5 to get to physical memory.

Multicast filter usage from ICSSG based Ethernet ports is scheduled for SDK 9.1 in November. Prior to that using RTOS drivers is the only path I see.

  Pekka

Having made some progress based on the code in the RTOS SDK (v08.02.00.05), I have some more detailed questions about use of FDB for multicast address filtering, which I hope you or someone else at TI can answer, please.

In particular:

• From the hardware architecture it seems that there can only be one FDB entry per ICSSG referring to a specific multicast address and filter ID; that being the case, how does one support hardware multicast address filtering independently for the two ports on the same ICSSG?  (Meaning, for example, that frames directed to the same multicast address are accepted on one port and rejected on the other.)
• Please would you explain the exact meaning/interpretation of bits [0..2] in the FDB entry (referring to "host", "port 0", and "port 1".  The (minimal) description in the example software suggests that the "host" bit needs to be enabled for a multicast frame to be delivered to the host but that does not correspond to what I see in practice - instead it seems that the "port 0" and/or "port 1" bits must be set to enable receipt of frames from the corresponding input port.
• In my experiments it seems that when peer ports on the same ICSSG are directly connected, inbound multicast frames are filtered differently to what happens if ports on different ICSSGs are directly connected.  In particular it seems that both port 0 and port 1 bits in the FDB entry need to be set in the first case.  Is that correct?  Please can you explain why this is so.

(Incidentally my experiments have been using EMAC firmware v02.02.12.01 as shipped with AM65x Processor SDK v08.06.00.047.)

Please would you also explain exactly the meaning of the following fields in the MII G RT FDB CFG1 register:

• FDB_HASH_SIZE - is this related to the number of broadside slot entries?  does it have to match the mask (e.g. 0x1ff) used to convert the CRC over the multicast address and filter ID to a broadside slot index?  otherwise, what does it refer to?
• FDB_BUCKET_SIZE - does this refer to the number of FDB entries which can be "attached" to the same hash value/broadside slot index?  otherwise, what does it refer to?

In the case where two different combinations of multicast address and filter ID hash to the same value (broadside slot index), how does FDB manage this collision?  Is the same FDB entry applied to all such combinations which hash to the same value?