AM1808: Enet Multicast packets are received even though MACHASHx are zero

All,

we have not seen any responses to our questions. Has an expert looked at this problem with the EMAC?

Thanks,

--Gunter

There are three ways the specified address could be received<BR>

Setting the Copy-All-Frames (CAF) bit <BR>

Setting the Copy-All-Mac-Frames (CAM) bit<BR>

Setting a hash bit.

Thanks, Mukul.

We are going to clear/reproduce issue/dump all Network Statistics Registers between offset 0x200 and 0x28C, and get back to you as soon as possible.

Please let us know if any additional registers should be dumped.

Thanks,

--Gunter

See attached zero_machash_multicast_rx_stat_regs.xlsx for a dump of the EMAC registers.

I used the following steps to collect the register data:

1. Download code to target, halting at main()
2. Set a breakpoint in the EMAC init logic immediately prior to writing '1' to the C1RXEN bit corresponding to the channel that is configured to receive multicast traffic (channel 2)
3. Set a breakpoint in the receive ISR for the channel that is configured to receive multicast traffic
4. Run target run (still halted at main)
5. When the breakpoint in #2 is reached, run the target and immediately issue the offending multicast traffic from my PC

In #5 I use scapy to send the multicast traffic from my PC:

sendp(Dot3(dst='01:80:c2:00:00:01', src='ff:ff:ff:ff:ff:ff', len=3)/LLC(dsap=0, ssap=1, ctrl=2)/Padding('\x00'*43), iface=IFACES.dev_from_index(6))

I unplugged the Ethernet cable from the device and I captured the register information from the debugger 'Registers' window when the device halts at the breakpoint in the receive ISR (#3). See attached zero_machash_multicast_rx_stat_regs.xlsx.

I can see in RXMBPENABLE that RXCMFEN and RXCAFEN are zero and I also see the MACHASH registers are zero, so the multicast message should not have been received by the EMAC.

The CPGMAC you have contains a type 2 Address mapping table.<BR>

That is, there is a 32 entry table of addresses that can contain any address. Can you dump this table as well?<BR><BR>

2.3.1.2 TYPE 2 Address Matching and Filtering Logic<BR>

The second type of address matching logic contains a 32 by 53-bit two-port ram and provides the

capability to perform address matching and address filtering based on the incoming packet’s destination

address. The ram contains 32 address locations that each contain a single 48-bit receive address plus

valid, channel, and match/filter bits. The host must initialize all ram locations (including locations to be

unused) at system startup and the host is responsible for adding and removing addresses from the ram.

The 53-bits of each address location are written with three consecutive 32-bit VBUS accesses. The host

must write the index into the ram in the MacIndex(4:0) register, followed by the upper 32-bits of address

(which are stored in a holding register), followed by the lower 16-bits of address (with control bits). The

53-bit indexed ram location is written when the low location is written.<BR><BR>

Multicast packet addresses may be contained in the ram, but the associated channel must have the

unicast enable bit set (even though it is a multicast address). The unicast enables and not the multicast

hash enable bit are used with multicast addresses in the ram. Therefore, hash matches can be disabled

and yet specific multicast addresses can be matched (or filtered) in the ram. If a multicast packet hash

matches, the packet may still be filtered in the ram. Each packet can be sent to only a single channel.

Dennis

Thanks for the detailed reply. Here is our code that initializes the MAC addresses:

  get_mac_address(mac_address);

  EMAC->MACINDEX = 0;

  EMAC->MACADDRHI = (*(UINT32 *)mac_address);

  EMAC->MACADDRLO = (*(UINT16 *)&mac_address[4]) | MACADDRLO_VALID | MACADDRLO_MATCHFILT;

  for(i = 1; i < 8; i++)

  {

     EMAC->MACINDEX = i;

     EMAC->MACADDRLO = *((UINT16 *)&mac_address[4]);

  }

You mentioned that there are 32 addresses to configure, but EMAC documentation (sprufu9a) says there are only 8. Also, the documentation only mentions bits 2:0 of MACINDEX. 

I tried revising the code to initialize indexes 1-31 to zero, but I still see an interrupt for the same multicast frame despite the MACHASH registers being set to zero.

Denis
the EMAC userguide for the family is
http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf

Gabriel,

Please try using a different multicast address. The one you are currently using is reserved for bridges.

Gunter
Let me see if i am able to sort the internal design spec vs TRM discrepancy, that might be outside Denis's domain.
Another suggestion from Denis is to try another multicast address as the one that is currently being used seemed to be reserved for bridges.

-DK-,

In response to:

-DK- said:

Gabriel,

Please try using a different multicast address. The one you are currently using is reserved for bridges.

We don't have any control over the data that is present on the network. If another device transmits to the given MAC address (01:80:c2:00:00:01) then the EMAC will receive the frame despite the MACHASH registers being set to zero. We are seeking answers to the following questions:

1. Why does the EMAC receive multicast traffic while the MACHASH registers are zero?
2. Are there other cases where the EMAC will receive frames? (besides broadcast traffic and besides unicast traffic destined to the MAC address configured in the EMAC and besides multicast traffic that matches a hash set in the MACHASH registers)

Hi Gabriel,

the team is looking into the details. There is a need for the following information:

[] Can you confirm the value of the register RXMBPENABLE? We would need you to confirm the value of the RXCMFEN bit as well as the other bits including RXCAFEN.

[] Could you send the buffer descriptor words (all four 32-bit words) that came with the undesired multicast packet?

Thanks,

--Gunter

Gunter

RXMBPENABLE is 0x10002022.

The four buffer descriptor words are (in order):

0x01E20610

0xC1558020

0x0000003C

0xC000003C

The undesired multicast packet is the only packet that was received by the EMAC channel since boot.

To expand on my previous answers:

Although the September 2016 revision of the OMAP-L138 TRM (spruh77c) as well as the September 2016 revision of the AM1808 TRM (spruh82.c) say that the MACINDEX bit field of the MACINDEX register is 2:0, I observed the following behavior when writing to the MACINDEX register:

Therefore the MACINDEX bit field appears to be 4:0 rather than 2:0.

Hmm, this matches what I had mentioned back on Aug-18. The table of addresses is 32 entries long.

Can we dump the address table to see what is in there?

Dennis

Below is a dump of the table. I created this dump by setting the MACINDEX register, then reading the MACADDRLO and MACADDRHI registers. The MACADDRHI register should not be affected by the MACINDEX register, but I see that its value changes for MACINDEX 8-31, which makes me wonder if the TRM was correct about the MACINDEX being 2:0

Hi Gabriel,

assuming there are 32 addresses, can you now write all 32 addresses with the following writing rule (Type2 rule)

The 53-bits of each address location are written with three consecutive 32-bit VBUS accesses.  The host must write the index into the ram in the MacIndex(4:0) register, followed by the upper 32-bits of address (which are stored in a holding register), followed by the lower 16-bits of address (with control bits).  The 53-bit indexed ram location is written when the low location is written.

So writing of each of the 32 MAC addresses has these steps

[] Write the MACINDEX

[] Write the 32bit high part of the MAC address into MACADDRHI

[] Write the 16bit low part of MAC address and control bits into MACADDRLO

For Type2 addresses, there is NO sharing of the MACADDRHI, so they can be unique.

Then if you could retest again, that would be great.

Regards,

--Gunter