iMX6 ENET RCR PADEN sillicon bug
This is just a quick blog post to prevent anybody from having to spend days finding out why your Gbps connection on an iMX6 (or any iMX with a similar or same ENET/FEC module) stops working when stressing the network.
IEEE 802.11 requires all frames to be >= 64 bytes (or even >= 512 bytes on a Gbps network). If a small frame is received, the MAC can remove the padding bytes that make the frame up to 64 bytes. However, if a small frame has 0 data bytes, this can then result in an RxBD with the L and BDU bits NOT set (even though the attached buffer is bigger or equal than the maximum frame size).
If the bug happens, there is NO indication of an error. Nothing in EIR to indicate a problem and nothing in the Enhanced Buffer Descriptors either. Strangely enough, the RxBD's data length is always set to whatever you have set in MRBR[R_BUF_SIZE] and L and BDU are both 0. The ENET module can not recover from this situation. It really seems the uDMA has crashed and is not working properly anymore. Only a full reset of the ENET module allows it to work properly again.
Note that we ONLY see this issue when stress testing using Gigabit link speeds on active networks (where broadcast messages are flowing).
What we think happens is that small packets (usually broadcast packets) with a data size of 0 cause the ENET uDMA to crash if the PADEN bit (12) is set in RCR. This bit enables the MAC to remove padding bytes.
We know small packets are the culprit because stressing the network on an isolated network (witthout small broadcast packets) works perfectly fine. Also setting the BC_REJ bit (4) on a non-isolated active network works without problems (setting this bit results in the ENET MAC to reject all broadcast & multicast packets). Of course rejecting all broadcast and multicast packets is not a solution...
Workaround: DO NOT set bit 12 (PADEN) in RCR.