LocalLink TEMAC Data Corruption

I have a design using the MPMC2 with a PowerPC and a CDMAC w/ LocalLink TEMAC on a Virtex4-FX. On the ppc I have Linux 2.6.22-rc2 running. The system can ping and simple UDP messaging has been working. When I attempted to perform TCP communication, the packets were never being received by another linux system. I took a look at the messages on the write and the 3rd and 4th byte of the ethernet destination are wrong. Added debug messages to the kernel to see the data that was being passed, and it was (of course) correct. After grabbing the physical addresses of the buffers, I once again checked them using xmd and it showed the same result.

The corruption occurs everytime, and different memory locations are being used. Is it possible that the CDMAC is doing some operation on the data and accidentally corrupting it?

TIA,

Mike Koss

Reply to
morphiend
Loading thread data ...

Are your memory buffers properly aligned? The boundary they have to be aligned to depends on the write/read mode used, but I believe it is safe to align them to 128 byte boundary.

/Mikhail

Reply to
MM

Mike,

BTW, did you write the adapter layer LL_TEMAC driver for linux yourself?

Thanks, /Mikhail

Reply to
MM

Yes and no. It was modified from the MontaVista 2.4 GEMAC adapter. I bridged that with the MV 2.6 TEMAC driver to get a driver together. The 2.4 GEMAC driver was previously using the CDMAC.

Reply to
morphiend

This problem is actually a result of the data buffer not being 32-bit aligned. For some reason this is only affecting TCP messages and not UDP or ICMP messages. I have used ChipScope to verify that the data provided to the LL_TEMAC is actually being corrupted by the CDMAC before it reaches the LL_TEMAC.

For now a workaround is to force alignment of the data buffer in the LL_TEMAC driver only for TCP messages. This is basically a memcpy (byte by byte) to force alignment, which could be optimized. This is allows TCP messaging to not have a corrupted Ethernet header. A better solution will be to two buffer descriptors for the message, one for the Ethernet header and one for the payload data.

Reply to
Greg Crocker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.