FEC problem with EMRBR?

[lambtron]

I am using M52233 in a network application for which I have developed my own high performance driver and protocol stack.  Everything works fine except the fec seems to drop all packets that are larger than the value programmed into EMRBR (Receive Buffer Size Register).  I never get a receive interrupt when the received packet size exceeds the EMRBR value, but I always get an interrupt when the size is less than the EMRBR value.

I have verified that when I change the EMRBR value (and make a commensurate change to the buffer size) I can then receive packets up to that size.  Furthermore, I have inspected the Rx BD ring and verified that consecutive BDs have the Empty bit set, so I can find no reason that the fec would drop packets due to, say, insufficient buffer space.

It appears that EMRBR specifies not only the scatter/gather buffer size, but also the maximum packet size that the fec will accept.  Curiously, all reference designs I have seen program EMRBR to large values, on the order of a maximum-sized Ethernet packet.

Here's another curiosity.  All of the reference designs program the Rx BD Data Length fields before releasing the BDs to the dma engine, even though the documentation clearly states that this field is written by the dma engine upon packet receive (and so I assume the dma engine will never read this field).  I'm getting the feeling that the driver is supposed to pass the buffer size to the dma engine via the BD Data Length field instead of through EMRBR.

Is this a bug in the fec or documentation?  If not, would someone please give me some ideas about how I can resolve this?  Thanks!

[lambtron]

Follow-up to this problem:

I contacted Freescale tech support about this. They seem unsure about how this circuit actually operates and I was told that they would look into this, which they consider to be a documentation error. That was long ago and I never heard back anything about this.

Tech support also told me that the rx dma buffer size must be written to the BD's DataLength field before giving it to the dma engine, and the dma engine will get the buffer size info from the BD, rather than from the EMRBR register, as the documentation seems to imply.

To verify this, I tried the following experiment:

• I set aside 2KB ram for some contiguous 128 byte dma buffers.
• I wrote 256 to EMRBR.
• I wrote 128 to the DataLength fields of all BDs in the rx BD ring.

According to tech support, anything larger than a 128 byte rx packet should now get copied into two different data buffers. I sent a 200 byte packet to the FEC and guess what happened? The FEC writes all 200 data bytes to a single 128 byte data buffer, and the first BD in the ring has its LastInFrame flag set! I must conclude that EMRBR not only sets the max permitted size for rx packets, but it also defines the size of all rx dma buffers.

Unless I am missing something here, this is a bug, and it breaks the scatter/gather mechanism.

In summary, I have learned this:

• I must set EMRBR to the size of the largest packet I will be able to receive.
• Don't bother writing dma buffer sizes into the rx BDs; they are ignored by the dma engine.
• The dma buffers must be the same size as the value written to EMRBR.
• Scatter/gather doesn't work on these processors.

[mccPaul]

Hi,

I'm going to try this with a 5282 to see what happens. Can you tell me what value you have set MAX_FL to in the Receive Control Register? Also, do you get any interrupts at all when the received frame is bigger than EMRBR?

Cheers,

Paul.

[lambtron]

Hi Paul,

I've set MAX_FL to several values.  It started off at 1518, but for the above experiment I set it to 384.

Receive frames larger than EMRBR do not generate interrupts.

It seems that there is no way to specify the size of receive dma buffers.  EMRBR is specified to be "the length of all receive buffers."  Apparently, this means that it is both the size of individual dma buffers as well as the max rx packet size.